lsm-tree vs B-tree
直觉来看，LSM-tree的优势在于写性能， B-tree的优势在于读性能， 而LSM-tree可能需要检查不同的data structure及SST才能得到.
但是, 你不该这么武断的得出这个结论， 而是应该通过你的具体场景做比较， 在衡量存储引擎性能时， 这里有几个值得思考的东西
-
LSM-tree的优势
B-tree
写数据时， 每条数据至少要写两次： 一次是WAL， 一次是page 自身， 这里有额外开销得注意： 即使一个page 只改了一个字节，写入时候，也要写入整个page， 在一些基于B-tree引擎中，为了避免在断电情况下，page的部分被更新，甚至需要写两次page。
Lsm-tree
由于多次compaction，需要多次重写数据，这就导致对数据库的一次写转换化为磁盘的多次写，这在SSD上就成了隐患，SSD只能进行有限次数的overwrite block在write-heavy application中，性能的瓶颈在database写入磁盘的速率， 在这种情况下， 写放大对性能有直接有影响： 引擎写入磁盘数据越多， 有限带宽下能每秒钟写入的数据越少。
还有，相比B-tree，LSM-tree更能支撑比较高的write throughout， 一部分原因在于他有更低的写放大（虽然这个依赖引擎的配置） ， 一部分原因在于顺序写compact SST file，而不像B-tree那样，需要更新多个page。 这个不同在HDD体现的更加明显（顺序写远高于随机写， 差距在1000）
另外，LSM-tree可以更好的进行压缩，因此可以在磁盘上产生更小的件， 再看B-tree, 由于fragmentation, 有些Disk space不能被使用， 由于LSM-tree不是page-oriented 的并且会不断的做compaction, 因此LSM-tree的磁盘占有更小， 特别是在使用level compaction。
在很多SSDs上， the firmware internally uses a log-structured algorithm to turn ran‐ dom writes into sequential writes on the underlying storage chips, so the impact of the storage engine’s write pattern is less pronounced 。 然而， 在SSDs 上， 更低的写放大/以及reduces fragmentation依然有优势： 在有限的IO带宽下， representing data more compactly allows more read and write requests
-
LSM-tree的劣势
compaction 可能会影响正在进行的read/write, 由于disk have limited resouces, 因此某些读操作必须等到expensive compaction完成之后才能进行， 这种对throughout/average response time 影响一般很小， 但是在at the percentiles，query的response time 有时候很高， 比较而言，B-tree的性能一般是稳定的。
disk 的写入带宽被多个thread共享： logging、flush、compaction, 当database越来越大， 更多的带宽被compaction占用。
如果 compaction的速率低于incoming write，unmerged segments越来越多，导致run out of disk， 而且，在读数据时， 由于需要检查的文件越来越多，read的性能也会降低。
B-tree每个key只存在一个地方，在LSM-tree，同一个key可能会存在多个文件中，这个特性是B-tree特别容易提供强事务特性，
