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

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

為什么要考慮EBS？

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

圖1

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

圖2

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

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

選擇合適的EBS卷類型

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

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

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

圖3

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

圖4

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

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

圖5

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

圖6

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

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

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

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

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

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

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

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

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

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

最后，我們選擇gp3作為EBS類型。EBS卷io2并不在我們的考慮范圍之內(nèi)，因?yàn)樵诋?dāng)初設(shè)計(jì)和實(shí)現(xiàn)TiDB Cloud時(shí)，r5b實(shí)例無法使用它。此外，當(dāng)時(shí)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/