LSM Tree存储引擎的写读性能非对称取舍：适合写多读少，不是万能替代品

LevelDB、RocksDB这类基于LSM Tree（Log-Structured Merge Tree）架构的存储引擎，专门针对高性能SSD存储做了适配，能提供比传统B-tree类存储引擎更高的压缩比、更低的写入放大比例（写入放大指的是应用层写入1单位数据，实际底层要多写多少倍的数据到磁盘，写放大越低意味着SSD的寿命损耗和I/O压力越小）——这些特性让LSM Tree类引擎在写入密集型场景下具备明显优势。但这份优势是有代价的：LSM Tree架构的读性能相对较差（因为一次读取可能需要在多层已排序但未完全合并的数据结构里逐层查找，而不像B-tree那样能直接定位），所以这类引擎真正适合的场景是”写多读少”，而不是一个能全面替代传统存储引擎的万能方案——像Facebook这样的公司会结合RocksDB特性开发出MyRocks这样的开源数据库分支，但即使如此，MyRocks的成熟度相比InnoDB仍有明显差距，更多是给了使用者”以后在存储引擎选型上多一个选择”，而不是”现在就该无条件替换掉InnoDB”。这个案例给出了一条评估新兴存储引擎的重要原则：任何一种存储引擎架构（不局限于LSM Tree）在设计时几乎都要在”写性能”和”读性能”之间做取舍，没有一种架构能同时在两个维度上都做到最优——评估要不要引入一种新的存储引擎，第一步永远是先诚实地识别自己真实的负载特征到底是写多读少、还是读多写少、还是读写均衡，再去判断候选存储引擎的取舍方向是不是和自己的负载特征相匹配；同时也要考虑这个新兴存储引擎围绕它构建的上层产品（这里是MyRocks）本身的成熟度，是否已经达到了可以承载核心业务的可靠性门槛，而不能只看底层存储引擎本身理论上的性能优势就贸然采用。