链上账本数据写入慢？试试LSM

导 读
首先问大家一个小问题？区块链的账本数据存储格式主要是什么类型的？

相信聪明的你一定知道是Key-Value类型存储。

下一个问题，这些Key-Value数据在底层数据库如何高效组织？

答案就是我们本期介绍的内容：LSM[1]。

LSM是一种被广泛采用的持久化Key-Value存储方案，如LevelDB, RocksDB, Cassandra等数据库均采用LSM作为其底层存储引擎。

据公开数据调研，LSM是当前市面上写密集应用的最佳解决方案，也是区块链领域被应用最多的一种存储模式，今天我们将对LSM基本概念和性能进行介绍和分析。

LSM-Tree背景：追本溯源

LSM-Tree的设计思想来自于一个计算机领域一个老生常谈的话题——对存储介质的顺序操作效率远高于随机操作。

如图1所示，对磁盘的顺序操作甚至可以快过对内存的随机操作，而对同一类磁盘，其顺序操作的速度比随机操作高出三个数量级以上[2]，因此我们可以得出一个非常直观的结论：应当充分利用顺序读写而尽可能避免随机读写。

Figure 1 Random access vs. Sequential access
考虑到这一点，如果我们想尽可能提高写操作的吞吐量，那么最好的方法一定是不断地将数据追加到文件末尾，该方法可将写入吞吐量提高至磁盘的理论水平，然而也有显而易见的弊端，即读效率极低（这也是许多数据库避免数据意外丢失的手段，因通常不需要对其进行读取，称为Journaling或WAL），我们称这种数据更新是非原地的（Out-of-place），与之相对的是原地更新（In-place）。

为了提高读取效率，一种常用的方法是增加索引信息，如B+树, ISAM等，对这类数据结构进行数据（或索引）的更新是原地进行的，这将不可避免地引入随机IO。

LSM-Tree与传统多叉树的数据组织形式完全不同，可以认为LSM-Tree是完全以磁盘为中心（Disk-Centric）的一种数据结构，其只需要少量的内存来提升效率，而可以尽可能地通过上文提到的Journaling方式来提高写入吞吐量。当然ÿ