分布式存储引擎（B树、LSM树）原理

分布式存储引擎（B树、LSM树）原理

B+树结构 Update-in-place

常见于传统关系型数据库（MySQL、Oracle），按key维护B+树，数据存放在叶子结点（每个页对应的节点可以有更高的度，减小树的深度），且叶子结点之间有指针相连，可以实现高效的key-value查询和区间查询。

底层的存储以页（4K）为基本单位，可以利用操作系统的磁盘预读机制，将节点的size设置为页的大小，这样每个节点只需要一次IO就可以完全载入。

局限性在于，随着数据不断插入，叶子结点会不断分裂，

• 写入的方式如果是覆盖写，插入的数据后的数据都重新刷写，如果正好跨页，会导致更大的写放大问题；
• 如果是追加写，就会导致逻辑上原本连续的数据实际上存放在不同的物理磁盘块的位置上（导致更多的随机写操作），在做范围查询的时候会出现比较高的磁盘IO。

总的来说，B+/B-树更适合短范围查询和给定值查询的应用场景。此外，由于B+树可以做到原地更新和删除，对数据库事务支持更加友好；相比较之下，LSM只能在Compaction时才真正的更新和删除，Segment间存在重叠，事务支持较差。

LSM树结构 Log-Structed Merged Tree

常见于LevelDB、HBase、BigTable（让LSM结构声名鹊起的契机）等NoSQL数据库，使用memtable（存储在内存，通常使用自平衡的二叉排序树——红黑树）来接收新的数据插入、更新以及读请求，并直接在内存中对数据进行排序；在内存中达到上限设置的Size后，刷入磁盘，使用SSTable格式（Sorted String Table，由多个Segment组成，每个Segement都是按key有序存储key-value数据对的string结构）将数据存储到磁盘，主要提供读操作，保持有序且不可被更改。

【写操作/更新操作/删除】

• 遵循WAL（Write Ahead Log）原则，数据会先写入日志文件（如HBase的HLog，当memtable出问题（如系统重启或宕机等），可以根据日志文件和SSTable恢复memetable的数据），然后再写入Memtable；
• 当内存中的Memtable达到一定条件时（如强制Flush，或数据量到达某个阈值时）数据会从memtable刷写到SSTable中（Minor Compaction），注意，为了避免刷写过程阻塞用户的写操作，会新建一个Memtable；
• 当磁盘中SSTable的数量超过某个阈值时，或者是周期性地进行合并（Major Compaction），清除无效数据，缩短读取路径。这个阶段才会真正得清除掉被标记为删除的数据，以及多版本数据的合并，避免空间的浪费。（注意，考虑到性能，尽量只在系统低峰期定期触发Major Compaction）

【读操作】

查询Memtable，如果查询不到再查询SSTable，效率低下。可以有几种策略进行优化：

• 正常情况下，一个读操作是需要读取所有的 SSTable， 将结果合并后返回的，但是对于某些 key 而言，有些 SSTable 是根本不包含对应数据的，因此，我们可以对每一个 SSTable 添加 Bloom Filter，因为布隆过滤器在判断一个SSTable不存在某个key的时候，那么就一定不会存在，利用这个特性可以减少不必要的磁盘扫描。
• 在SSTable中扫描每个Segement直到数据匹配为止，这个过程可以通过建立稀疏索引来提高效率（直观举例：每个Segement第一个key ： offset，那么可以通过二分查找定位到目标数据在哪个Segment内）

总的来说，LSM牺牲了部分读操作的性能，通过批量顺序写来换取高吞吐的写操作性能，更适用于高并发写入的场景。