導言
在第一篇博文中，我們學習了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/