寫給大忙人看的數據庫存儲引擎-高級話題

導言
在第一篇博文中，咱們學習了b-tree和lsm-tree的索引管理方式，索引算法也在選擇存儲引擎類型時候起到了關鍵做用，
下述大標題也同等重要須要考慮

1 一致性，事務和併發控制
單體數據庫，一般指的是關係型/SQL,支持強一致性和ACID事務，分佈式數據庫必須聽從cap理論，當出現故障的時候，選擇一致性或者可用性，
NoSql數據庫內在的分佈式特色使得第一代NoSQl數據庫(包括Apache Cassandra, AWS DynamoDB, Couchbase)更喜歡可用性而不是一致性。換句話說，他們遵循最終一致性。
最終一致性的數據庫不遵循acid事務而是限制於base操做，下一代數據庫像YugaByte DB，FoundationDB，MS Azure Cosmos DB 在nosql世界中帶來了強一致性打破了長期的設計
選擇。

這些如何影響了存儲引擎的設計？最大的影響是存儲引擎處理併發請求，這取決於隔離級別（例如ACID）的支持。SQL數據庫從前是使用行級鎖的強一致性形式的併發控制，
然而，爲了提供更好的吞吐量引入多版本併發控制(MVCC),經過建立用於進行讀和寫的行的不一樣版原本較少對鎖的需求。例如在下表中，當會話2在version1
上讀記錄的時候會話1在version2上寫記錄，按期刪除，也叫垃圾回收用來刪除不使用的版本。

無鎖的MVCC一般意味着快照隔離級別，可序列化，最嚴格的隔離級別，知足的有兩階段鎖（Oracle方式）或者序列化證實器(PostgreSQL方式)，
單體數據庫一般同時支持快照和可序列化的隔離級別。

在傳統的NoSQL方面，MVCC不多被實現，Apache Cassandra沒有MVCC，意味着多併發寫入時不會中止寫入衝突-最後客戶端時間戳將獲勝， AWS DynamoDB
容許應用實現樂觀併發控制當知足特定條件時候，在全局表中，AWS DynamoDB甚至失去了這種保證，對於全部操做，都回到了與Apache Cassandra相同的最後寫入者獲勝的語義
一個值得提醒的特例是 MongoDB WiredTiger實現了文檔級別併發的MVCC。

事務型Nosql數據庫像YugaByte DB和FoundationDB都有MVCC實現，YugaByte DB實現依賴於原生時間戳方式，而FoundationDB使用讀和寫時樂觀控制的mvcc方式

2 合併
LSM引擎按期合併數據，在這個過程當中，從新組織數據格式從寫優化到讀優化轉換，而且垃圾回收舊數據。他們提供了多合併策略所以用戶能夠根據負載不一樣而配置。例如
Apache Casssandra提供了Size(頻繁寫負載)，Leveled (頻繁讀負載)，和TimeWindow（時間序列負載）
合併在B-Tree引擎有着徹底不一樣於LSM-TREE的含義，B-Tree合併一般指的是經過移除舊數據和索引值以減小磁盤空間的過程，對於寫頻繁的負載，當新數據持續進入引擎
的時候，減小磁盤空間很重要，合併數據和索引要麼串行(低CPU/磁盤 IO負載)要麼並行(高CPU/磁盤 IO負載)。

3 壓縮
壓縮本質上是讓磁盤數據更小以減小存儲消耗和備份時間的過程，當須要壓縮和解壓的時候CPU消耗會增長，通用壓縮數據塊的算法有：Prefix，Snappy，LZO，LZ4，ZLib，和
LZMA，和合並相似，大多數數據庫提供了多種壓縮算法使得用戶能夠根據需求來配置。注意到BTree容易受到浪費空間的碎片致使壓縮不是很好，LSM則不會遇到這樣的問題所以有更好的
壓縮性。

4 總結
核心是數據庫存儲引擎專門優化讀性能(B-Tree)或者寫性能(LSM),其餘方面例如一致性，事務，併發，合併，壓縮也應該考慮。這樣能夠完整的理解引擎。
在過去十年，數據量顯著增加，LSM引擎已經成爲了標準。相比於調優B-Tree引擎的更高的寫性能，LSM引擎能夠很方便的對讀性能進行調優（例如使用布隆過濾器和多種合併策略）
數據模型（關係VS非關係）和相關數據庫客戶端api（SQL Vs NoSQL）不是直接和存儲引擎設計緊密結合。
SQL和NoSQL數據庫都是基於B-Tree和LSM引擎構建的。

原文連接：
https://blog.yugabyte.com/a-busy-developers-guide-to-database-storage-engines-advanced-topics/