LSM-Tree
由Patrick O'Neil等人于1996年提出的数据结构，将随机写转化为顺序写，通过MemTable内存缓冲和分层Compaction机制降低写放大，广泛用于高写入负载存储引擎如RocksDB、LevelDB
时间轴 (近 90 天)
列式存储写入时需要把不同列的值分别落到不同位置，单行插入代价远高于行式存储，因此OLAP系统通常采用批量导入和后台合并（如LSM-Tree的compaction）来摊薄写入成本。
主打写入优化的存储引擎通常采用LSM-Tree（日志结构合并树）作为底层数据结构
LSM-Tree将随机写入转化为顺序写入，数据先写入内存中的MemTable，达到阈值后批量刷盘，再通过后台Compaction逐层整理
LSM-Tree由Patrick O'Neil等人于1996年提出，最初为解决传统B树在高写入负载下的随机IO瓶颈
B+树因频繁页分裂，写放大通常在10倍以上；LSM-Tree的写放大通常在3-30倍之间波动
写放大与读放大之间存在反向权衡，调低Compaction触发阈值可减小读放大但会提高写放大
LSM类引擎在写入上占优，但读取尤其是范围查询可能需要跨多层查找，存在读放大
亲手实现简易LSM-Tree存储引擎有助于理解LevelDB、RocksDB和Cassandra的架构设计
全部知识事实 (8)
列式存储写入时需要把不同列的值分别落到不同位置，单行插入代价远高于行式存储，因此OLAP系统通常采用批量导入和后台合并（如LSM-Tree的compaction）来摊薄写入成本。
50%待验证主打写入优化的存储引擎通常采用LSM-Tree（日志结构合并树）作为底层数据结构
50%待验证LSM-Tree将随机写入转化为顺序写入，数据先写入内存中的MemTable，达到阈值后批量刷盘，再通过后台Compaction逐层整理
50%待验证LSM-Tree由Patrick O'Neil等人于1996年提出，最初为解决传统B树在高写入负载下的随机IO瓶颈
50%待验证B+树因频繁页分裂，写放大通常在10倍以上；LSM-Tree的写放大通常在3-30倍之间波动
50%待验证写放大与读放大之间存在反向权衡，调低Compaction触发阈值可减小读放大但会提高写放大
50%待验证LSM类引擎在写入上占优，但读取尤其是范围查询可能需要跨多层查找，存在读放大
50%待验证亲手实现简易LSM-Tree存储引擎有助于理解LevelDB、RocksDB和Cassandra的架构设计
50%