导言
在第一篇博文中，我们学习了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/