如今，許多數(shù)據(jù)庫即服務(wù)（DBaaS）解決方案將計算層和存儲層分開來，比如包括Amazon Aurora和Google BigQuery。由于數(shù)據(jù)存儲和數(shù)據(jù)復(fù)制可以由現(xiàn)有服務(wù)來處理，DBaaS無需擔(dān)心這種復(fù)雜性，這種解決方案很有吸引力。然而，這種設(shè)計的性能有時可能不如傳統(tǒng)方式：使用本地磁盤作為存儲。

本文將介紹如何認真選擇彈性塊存儲（EBS）類型，輔以巧妙的優(yōu)化，在EBS上部署DBaaS可以獲得比在本地磁盤上更好的性能。

為什么要考慮EBS？

為了解釋我們使用EBS的動機，先簡單介紹一下TiDB。TiDB是一種與MySQL兼容的分布式數(shù)據(jù)庫。TiDB Server是處理SQL請求的計算節(jié)點。Placement Driver（PD）則是TiDB的大腦，負責(zé)配置負載均衡，并提供元數(shù)據(jù)服務(wù)。TiKV是一種面向行的鍵值存儲系統(tǒng)，處理事務(wù)查詢。TiFlash是處理分析查詢的列存儲擴展。本文主要介紹TiKV。

圖1

TiKV提供分布式鍵值服務(wù)。首先它將數(shù)據(jù)拆分成幾個Region，這是用于復(fù)制和負載均衡的最小數(shù)據(jù)單元。為了實現(xiàn)高可用性（HA），每個Region被復(fù)制三次，然后分布在不同的TiKV節(jié)點中。一個Region的副本構(gòu)成一個Raft組。TiDB可以接受這種情形：失去一個節(jié)點，從而在一些Region中失去一個副本。但是，同時失去兩個副本會導(dǎo)致問題，因為Raft組的大多數(shù)成員都失去了。因此Region不可用，無法再訪問其數(shù)據(jù)。需要人為干預(yù)來解決這類問題。

圖2

在部署TiDB Cloud時，我們有放置規(guī)則，保證一個Region的副本會分布在多個可用區(qū)（AZ）。失去一個可用區(qū)（AZ）不會對TiDB Cloud產(chǎn)生巨大影響。然而，如果出現(xiàn)AZ + 1故障（即一個可用區(qū)和另一個可用區(qū)中的至少一個節(jié)點同時出現(xiàn)故障），該Region將變得不可用。我們在生產(chǎn)環(huán)境中遇到過這樣的故障，花了好大的精力才讓TiDB集群恢復(fù)正常。為了避免再次遭遇這種痛苦的經(jīng)歷，EBS進入了我們的視線。

AWS Elastic Block Store（EBS）是AWS提供的一種塊存儲服務(wù)，可以附加到EC2實例上。然而，EBS上的數(shù)據(jù)獨立于EC2實例，因此當(dāng)EC2實例出現(xiàn)故障時，數(shù)據(jù)持續(xù)存在。當(dāng)EC2實例出現(xiàn)故障時，可以使用Kubernetes，將EBS自動重新掛載到正常工作的EC2實例。此外，EBS卷是為關(guān)鍵任務(wù)系統(tǒng)設(shè)計的，因此它們可以在AZ內(nèi)復(fù)制。這意味著EBS不太可能出故障，因此我們就放心了。

選擇合適的EBS卷類型

基于SSD的EBS卷通常有四種類型：gp2、gp3、io1和io2。（我們在設(shè)計和實現(xiàn)TiDBCloud時，io2 Block Express還處于預(yù)覽模式，所以我們沒有考慮它。）下表總結(jié)了這些卷類型的特點。

這里可以進行對比。注意在下面圖中，四種類型的EBS卷附加到了r5b實例，而本地磁盤上的一番測量是在i3實例上進行的。這是由于r5b實例只能使用EBS。我們使用i3作為相仿的替代選擇。每個圖顯示了所有操作的平均延遲和第 99個百分位延遲。

我們從讀寫延遲開始橫向比較。第一個工作負載很簡單。它有1000 IOPS，每個I/O為4 KB。以下兩張圖顯示了平均延遲和第99個百分位延遲。

圖3

只有一個線程的簡單工作負載的寫延遲。（數(shù)字越小越好）

圖4

只有一個線程的簡單工作負載的讀延遲。（數(shù)字越小越好）

我們使用類似的設(shè)置設(shè)計了類似的工作負載。這次我們使用8個線程為磁盤提供總共3000個IOPS，每個I/O仍然是4 KB。同樣，我們概述了平均延遲和第99個百分比延遲，并繪制成以下兩圖。

圖5

有八個線程的簡單工作負載的寫延遲。（數(shù)字越小越好）

圖6

有八個線程的簡單工作負載的讀延遲。（數(shù)字越小越好）

從前面兩個實驗來看，本地磁盤似乎更勝一籌。真是這樣嗎？這是另一個基準(zhǔn)測試，顯示的情況略有不同。我們設(shè)計了混合工作負載來模擬TiKV IO的使用：有小的順序?qū)懭雭砟M前臺預(yù)寫式日志（WAL）寫入，還有大量的順序?qū)懭雭砟M壓縮寫入。回想一下，TiDB使用RocksDB作為存儲引擎。RocksDB基于日志結(jié)構(gòu)化合并樹（LSM 樹），它定期壓縮最近寫入的數(shù)據(jù)。我們也有小的隨機讀取來模擬前臺讀取。

我們發(fā)現(xiàn)，當(dāng)后臺I/O變得更密集時，前臺延遲增加，本地磁盤和EBS之間的延遲差距會變小，見下圖。

圖7. 一些綜合工作負載的平均操作延遲。（數(shù)字越小越好）

我們針對TiDB運行TPC-C工作負載（這是更全面的基準(zhǔn)測試）后，EBS 和本地磁盤之間的性能差距變得更小了。下圖顯示了結(jié)果。使用的TiDB版本是v5.0.0。我們在EBS卷類型不一的r5b.2xlarge實例上或使用本地nvme磁盤的i3.2xlarge實例上部署了三個TiKV節(jié)點。TiDB 節(jié)點、Placement Driver（PD）和TPC-C客戶端部署在c5.4xlarge實例上。我們在實驗環(huán)境中使用了5000個倉庫（大約350 GB數(shù)據(jù)），分別有50個、200個和800個客戶端。結(jié)果顯示在以下三個圖中。第一個圖顯示了TPC-C工作負載中的每分鐘事務(wù)數(shù)（TPMC）。第二個圖顯示了事務(wù)的平均延遲，以毫秒為單位。第三個圖顯示了第99個百分位延遲，以毫秒為單位。

圖8. TPC-C工作負載中的每分鐘事務(wù)（TPMC）。（數(shù)字越大越好）

圖9. TPC-C 工作負載中的平均操作延遲（ms）。（數(shù)字越小越好）

圖10. TPC-C 工作負載中的第99個百分位操作延遲（ms）。（數(shù)字越小越好）

通常來說，我們可以看到使用EBS的實例可以達到與使用本地磁盤的實例相仿的性能，有時甚至更好。這是由于TiKV在這個工作負載中是CPU受限的，在我們嘗試過的其他許多基準(zhǔn)測試中也是如此。I/O性能不是瓶頸。由于帶EBS的實例類型是r5b，它的CPU比帶本地磁盤的實例類型i3更好，性能結(jié)果看起來相仿，甚至更好。

此外，在第三個圖中（TPC-C工作負載中的第99個百分位操作延遲），有800個線程時，EBS卷類型gp2的第99個百分位延遲飆升。這是由于就gp2而言，帶寬達到了極限。

最后，我們選擇gp3作為EBS類型。EBS卷io2并不在我們的考慮范圍之內(nèi)，因為在當(dāng)初設(shè)計和實現(xiàn)TiDB Cloud時，r5b實例無法使用它。此外，當(dāng)時io2 block express仍處于預(yù)覽模式。EBS卷io1的延遲整體上與gp2相當(dāng)，io1提供了更高的帶寬IOPS限制。然而，io1有基于預(yù)置IOPS的額外成本。EBS卷gp2的帶寬和IOPS有限，而且無法配置。這給TiDB帶來了額外的限制。因而，我們選擇了gp3。

原文標(biāo)題：Improve Performance and Data Availability with Elastic Block Store (EBS)，作者：Bokang Zhang

鏈接：

https://www.datasciencecentral.com/improve-performance-and-data-availability-with-elastic-block-store-ebs/