本文主要是講了一些RocksDB在分布式系統(tǒng)中大規(guī)模應(yīng)用時的經(jīng)驗與教訓。

RocksDB是一個高性能的持久鍵值存儲引擎，由Facebook在2012年創(chuàng)建，基于谷歌的LevelDB代碼。RocksDB是基于LSM的，對SSD進行了優(yōu)化，被多個數(shù)據(jù)庫當做存儲引擎使用，并且被使用在流處理、日志隊列服務(wù)以及索引服務(wù)和SSD緩存之上。

引擎架構(gòu)

MemTable與WAL

RocksDB使用LSM作為主要的存儲數(shù)據(jù)結(jié)構(gòu)，每當數(shù)據(jù)寫入到RocksDB之中，就會被添加到MemTable內(nèi)存的寫緩沖區(qū)，以及一個磁盤上的超前寫入日志（WAL）。數(shù)據(jù)會被寫入到WAL和MemTable，WAL是MemTable的易失性保護機制。

RocksDB中Memtable的數(shù)據(jù)結(jié)構(gòu)有三種，分別是skiplist、hash-skiplist、hash-linklist，跳表的好處在于插入的時候可以保證數(shù)據(jù)的有序，并且支持二分查找、范圍查詢。插入和搜索的代價都是O(log n)。

在達到指定大小之后現(xiàn)有MemTable和WAL鎖定變?yōu)椴豢勺?，新?shù)據(jù)寫入新的MemTable和WAL。

SSTable

SSTable是一種數(shù)據(jù)結(jié)構(gòu)，當MemTable到達一定的上限之后，會flush到硬盤上Sorted String Table (SSTable)，并放置在第0層(L0)，對應(yīng)的WAL空間回收；L0大小達到上限時，L0的SSTable經(jīng)過compaction落到L1；Ln：以此類推完成上述操作。

在每一級中，都會使用二進制搜索；而布隆過濾器會消除SSTable文件中不必要的檢索。

Compaction

Campact可以翻譯成壓縮，也可以被稱為壓實，其作用主要有：清除無效數(shù)據(jù)；對數(shù)據(jù)的排序進行優(yōu)化。而無效數(shù)據(jù)的產(chǎn)生于update：標記覆蓋與delete：標記刪除。使用Compact的好處有：整個文件的批量讀寫，比較高效；可以并行化操作。

比較幾種常見的Compaction策略：

● Leveled：leveldb的方式，SSTable數(shù)量逐層以指數(shù)增長，讀寫放大都比較嚴重，但是空間放大較低；

● Tired/Universal：Cassandra與HBase的方式，空間放大和讀放大嚴重，但是寫放大最??；

● FIFO：刪除舊的過期文件，執(zhí)行輕量級壓縮，適用于那些in-memory緩存應(yīng)用。

大家也可以發(fā)現(xiàn)，并不存在寫放大、讀放大和空間放大都很完美的方案；和計算機世界的其他領(lǐng)域一樣，數(shù)據(jù)庫也沒有銀彈。

資源目標的優(yōu)化

針對于RocksDB的問題，很多團隊也對齊進行了資源目標的優(yōu)化，我們選取了兩點進行資源目標優(yōu)化的討論，分別是寫放大和空間放大。

寫放大

寫放大主要來源于以下幾個層面：

● 固態(tài)硬盤本身會帶來1.1到3的寫入放大；

● 當4kb/8kb/16kb大小的頁面被寫入不到100字節(jié)的變化時，可能會產(chǎn)生100倍的寫入放大；

● 不同的Compaction策略有不同的寫入放大比率。

針對于以上的寫放大，有如下優(yōu)化建議：

● 在寫入速率高時，減少寫放大；

● 在寫入速率低時，積極壓縮；

● Value較大時，可以考慮使用BlobDB分離Key和Value。

空間放大

在使用SSD時，空間利用率比寫入放大率更重要，因為閃存的寫入周期和寫入開銷都不受限制。優(yōu)化空間放大，可以使用動態(tài)分層壓縮，每一層大小根據(jù)上一層實際大小自動調(diào)整，而不是每層都是固定的大小，能夠更有效地利用空間。

大規(guī)模系統(tǒng)的經(jīng)驗

RocksDB應(yīng)用于不同需求的大規(guī)模分布式系統(tǒng)的構(gòu)建，我們也從一下幾點去闡述相關(guān)經(jīng)驗和改進思路。

資源管理

大規(guī)模的分布式系統(tǒng)會將數(shù)據(jù)劃分為Shard，分布在多個服務(wù)器節(jié)點上進行存儲。同時，一臺主機內(nèi)部可能運行多個RocksDB的實例，需要對資源進行管理，包括全局（每臺主機）和局部（每個實例）。

需要管理的資源包括：

● 內(nèi)存：Write buffer、Block cache

● I/O帶寬：Compaction

● 線程：Compaction，最好使用線程池

● 磁盤使用量

● 文件刪除頻率

并且盡量滿足以下要求：每個實例都不能過度使用任何資源；不同實例之間可以設(shè)置資源使用的優(yōu)先級。

WAL

在傳統(tǒng)的數(shù)據(jù)庫中，傾向于進行WAL的操作，以確保持久性。在分布式場景中，數(shù)據(jù)有副本，并且進行一致性的校驗。如果使用Paxos進行副本間的數(shù)據(jù)同步，那么WAL是無用的。同時，可以提供三種不同的WAL策略操作：同步寫；緩沖異步寫；不寫。

限制文件刪除

有些文件系統(tǒng)能夠識別出SSD，比如XFS。進行文件刪除時，文件系統(tǒng)會向SSD發(fā)出TRIM指令，通常情況下可以提高SSD的性能與耐用性，但也可能導致性能問題。TRIM除了更新SSD內(nèi)部內(nèi)存中的地址映射，還會觸發(fā)SSD內(nèi)部的垃圾回收，導致大量的數(shù)據(jù)移動，提高IO延遲。所以文件刪除速率需要被限制，防止Compaction過程中的多個文件同時被刪除。

數(shù)據(jù)格式的兼容性

大規(guī)模分布式系統(tǒng)幾乎必須提供在線的滾動升級與回退的功能，所以從底層的數(shù)據(jù)格式設(shè)計上就必須保證向前和向后的兼容性。那么可以采用以下的相關(guān)策略：

● 所有版本必須能夠理解所有以前寫入磁盤的格式

● 未來的格式也應(yīng)該能夠被理解

● 可以考慮使用ProtocolBuffer和Thrift中的相關(guān)技術(shù)

● 配置文件配置項的前后兼容性設(shè)計

● 做好版本兼容性測試

復制與備份

RocksDB是一個單節(jié)點的存儲引擎，所以無論以任何方式進行復制和備份，RocksDB都要進行相關(guān)的支持。兩種方式可以支持現(xiàn)有的副本復制：

● 邏輯復制：所有的鍵值對都可以被讀出來，寫到數(shù)據(jù)副本中

○ 支持全數(shù)據(jù)掃描操作，并最小化對正常讀寫操作的性能影響

○ 邏輯復制的查詢結(jié)果，不會進行緩存

○ 在目標端支持批量加載，并進行相應(yīng)的優(yōu)化

● 物理復制：直接復制SSTable和其他文件。

○ 物理復制的接口應(yīng)由引擎提供，而不是讓用戶或者其他應(yīng)用程序去直接操作數(shù)據(jù)文件

在邏輯復制的部分是基于既有數(shù)據(jù)文件的復制，基于文件的復制更適合創(chuàng)建新的副本時的全量復制。而物理復制則為全量復制提供了一個速度更快的選擇。

復制的機制還與一致性有關(guān)，同時備份也包括邏輯備份和物理備份，與復制的區(qū)別是，應(yīng)用程序需要多個備份。總體而言備份與復制使用的方法與手段相差不多，但從用戶易用性的角度出發(fā)，存儲引擎應(yīng)當有管理多個備份的功能。

故障的教訓

出于性能方面的考慮，用戶很可能不使用SSD的數(shù)據(jù)保護（DIF、DIX），存儲介質(zhì)的損壞需要由存儲引擎的塊校驗檢測出來。除此之外，復制、備份、數(shù)據(jù)恢復過程中也可能引入損壞的數(shù)據(jù)。

數(shù)據(jù)損壞應(yīng)當盡早被發(fā)現(xiàn)，以減少停機時間和數(shù)據(jù)損失。一份數(shù)據(jù)應(yīng)當在多個主機上進行復制；當檢測到checksum不匹配時，損壞的副本被斷開，并由正確的副本接替；同時，需要至少保證有一個正確的副本。多層校驗包括：

● 塊：每個SSTable塊和WAL塊都有一個附加的校驗和，在數(shù)據(jù)被創(chuàng)建時產(chǎn)生；每次讀取數(shù)據(jù)時都會進行驗證，防止損壞數(shù)據(jù)暴露給用戶；

● 文件：每個SSTable文件有自己的校驗和，校驗和記錄在SSTable的元數(shù)據(jù)中；

● Handoff：這是一種向文件系統(tǒng)寫入數(shù)據(jù)時同時傳下去的校驗和，由文件系統(tǒng)的一些機制來進行校驗；但是不是所有的文件系統(tǒng)都支持這種校驗，所以要提前做好規(guī)劃。

結(jié)語

通過本文，希望大家對RocksDB有更好的認知，同時也可以更好的將RocksDB應(yīng)用于各種大規(guī)模分布式系統(tǒng)。

參考文獻:

RocksDB Github Wiki:https://github.com/facebook/rocksdb/wiki

Evolution of Development Priorities in Key-value Stores Serving Large-scale Applications: The RocksDB Experience: https://www.usenix.org/conference/fast21/presentation/dong

RocksDB原理及應(yīng)用:https://zhuanlan.zhihu.com/p/409334218

CnosDB簡介

CnosDB是一款高性能、高易用性的開源分布式時序數(shù)據(jù)庫，現(xiàn)已正式發(fā)布及全部開源。

歡迎關(guān)注我們的社區(qū)網(wǎng)站：https://cn.cnosdb.com? ?