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

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

為什么要考慮EBS？

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

圖1

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

圖2

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

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

選擇合適的EBS卷類型

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

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

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

圖3

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

圖4

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

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

圖5

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

圖6

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

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

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

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

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

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

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

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

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

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

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

原文標題：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/