石頭自清潔掃拖機器人G10S評測：多年黑科技集大成之作 懶人終極福音
科技圈經常能看到一個詞叫“縫合怪”，用來形容那些把好多功能或者外觀結合在一起的產品，通常這樣的詞是貶義詞，但如果真的是產品縫合的好、縫合的實用的話，那它就成了中性詞，今
如今，許多數據庫即服務（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還處于預覽模式，所以我們沒有考慮它。）下表總結了這些卷類型的特點。
卷類型
耐久性
（%）
帶寬
（MB/s）
IOPS
（每GB）
成本
說明
gp2
99.8-99.9
250
3，突發式
低
通用卷
gp3
99.8-99.9
125-1000
3000-16000
低
通用卷，有靈活的帶寬
io1
99.8-99.9
多達1000
多達64000
高
高IOPS
io2
99.999
多達1000
多達64000
高
高IOPS，性能最佳
這里可以進行對比。注意在下面圖中，四種類型的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/
本文鏈接：http://www.yifxia.cn/showinfo-119-2333-0.html用Elastic Block Store（EBS）改善性能和數據可用性 譯文
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號