EEPW论坛

数据存储在实际应用中，就是怎么用数据库把我们的业务数据保存起来。从宏观角度看，大致包含三大类技术：B-TREE，LSM&SSTable，列式存储。虽然主流的关系型数据库，如Oracle、MySQL（innodb）都是采用B-TREE，但是两者其实并没有绑定关系，比如TokuDB，作为MySQL的存储引擎之一也是使用LSM作为其核心思想；NewSQL中的TIDB虽然也是基于关系模型的，但是底层的存储引擎使用RocksDB，也是基于LSM&SSTable。底层技术处于互相学习和融合之中。

B-TREE

B-TREE和关系模型同步出现于70年代，到90年几乎占领了所有的数据库市场。B-TREE简单的理解就是多叶节点的树，每个叶节点并非是每行数据，而是数据库的的数据块。这么设计的原因是树的层次影响着搜索性能，而且磁盘的读写是基于块（BLOCK）的，使用块可以大大减少节点数量，进而减少树的层次。

B-TREE的特点在于读写性能比较稳定，响应时间和磁盘随机读写的时间成正比（10ms）。并且由于B-TREE对应到数据库的每条记录，可以很容易的实现事务、行锁和隔离级别。读性能略高于LSM算法。而且B-TREE基于块的存储方式，可以很容易的把内存中的块和磁盘上的块一一对应起来，很容易的实现缓存。在实际应用中，前2-3级节点内都可以在缓存中读取，由此大大提高了访问效率。

而不足在于真正面对海量数据时（如数据量进入到百亿级别时），由于树层数和缓存比率的减少，会导致性能逐步下降。此外由于B-TREE在写入时也需要通过搜索定位到叶节点，因此相对于LSM，其写入时开销较大。PS：其实现在已经出现了分布式的B-TREE，比如oracle的localeindex。

LSM&SSTable

目前主流的存储架构还是磁盘+内存，磁盘顺序读写的性能高于随机读写三个数量级，而在内存中进行随机读写的的性能也大于磁盘的三个数量级，可以得出用磁盘当做磁带一样只做顺序读写，而把内存当做磁盘，提供所有的随机读写访问的总体思想，这也就是出LSM-Tree的算法。

简单说就是在内存中维护一张MemTable，把所有最新的数据都写到其中，所有数据依据key值进行排序（随机读写）。当MemTable的大小到大阈值之后，把它写到磁盘上，形成一个个的SSTable（顺序写）。每个SSTable构造一个索引，由于SSTable中的数据都是排好序的，所以索引较小，可以保存在内存里面，所以所有的索引搜索动作都是在内存进行的（随机读）。

每次查找的过程如下：首先在MemTable中搜索（内存随机查找），如果没有依次在每个SSTable的索引中查找（内存随机查找）。把查找从磁盘随机动作变成了基于内存的随机动作。随着SSTable的增多，搜索的次数会增加，为了提高性能，后台会把多个SSTable合并为一个（如HBase、LevelDB等等）。并且提供布隆过滤器（BloomFilter）来过滤掉不需要的SSTable。从总体效果上看，写入的效率大大高于基于B-Tree的存储引擎，而读取性能接近于B-Tree。

LSM&SSTable在写入密集型应用中有较大优势，同时在读取方面也有不错的表现。不足之处在于上面提到的，不定期对增加的SSTable进行合并时，对于数据库会产生一定压力。

由于这些特点，LSM&SSTable大量应用于许多组件中，比如HBase、LevelDB等KeyValue数据库中，同时也在消息引擎Kafka和搜索引擎Solr使用。

列式存储

以上两种存储引擎主要适合于联机场景，如有大量的基于客户各类行为数据的批量计算的推荐系统中，以及预计客户的流动性缺口等等。在这些场景中，列式存储在性能上有非常明显的优势。随着各类大数据应用的扩展，列式存储从和Hive共生的ORC，到和Spark共生的Parquet也被应用到了各个数据分析应用中。

从传统的数据分析类应用，到人工智能应用，都需要遍历整个数据集，上面也提到磁盘在顺序读写和随机读写性能方面的巨大差距，所以所有的数据仓库都会在全表遍历中采用磁盘顺序遍历。所以遍历的文件空间越小，性能越高。列式存储按列对数据进行保存，以减少数据库每次访问的文件尺寸。

首先，分析应用一般局限于对于表中的部分字段都分析，列是存储可以让引擎只访问部分字段，减少吞吐量。其次，列式存储数据压缩能力更强。因为行级别的存储方式压缩是基于数据块，压缩比大致为50%-70%左右，而且压缩比越大，解压缩对于CPU的占用也越大。由于单列内的数据非常类似，尤其是各种码值类的数据，比如性别（男、女、其他），行数越多，压缩比越大。10亿客户的性别，也可以简单的表达为如下这样：“连续100个男性、连续50个女性、又连续80个男性、连续70个女性”，按照每行的位置依次表达下去。

再次，同样由于列内数据的取值范围有限，也可通过位图来表达，比如10表示男，01表示女，因此只用2个bit就可以表示出来，从而进一步增加压缩比。在在许多场景中能够把以前数G的数据压缩为几百K。由此可以显著降低批量计算时对于存储的吞吐压力和提升计算效率。

当然列式存储也并非完美，在更新时列式存储相对行式存储，很难直接做到就地修改的效果，往往需要把整列锁住，重新计算，重新生成整个列。所以列式存储更多的适合于数据分析时需要全表遍历的场景。

数据存储总结

综合考虑上面三种存储方式的优势和不足。推荐系统根据应用访问数据的特点把数据分布到了不同的存储机制中。

对于需要提供事务、锁，数据量不特别大的场景中，采用基于B-TREE的存储机制，例如合约签订，合约执行等业务需要数据库提供多行的事物处理，而且数据量和交易量不是特别大，把数据保持在传统关系型数据库中，也正好利用了B-TREE的优点。

对于访问数据量，以及每日新增、修改量特别大的场景，采用LSM&SSTable作为存储引擎，例如客户的标签数据，数据量达到百亿级，每日增量也可达上亿记录，数据保存在HBase数据库中，可以较为轻松，在数十分钟之内就可完成批量更新，而查询响应时间也没有随着数据量的增加而变慢，仍然保证在几毫秒以内。

最后是列式存储，它适合于数据分析类场景，如进行客户流动性预测、客户投资方案生成这类分析场景中，需要对于数据进行反复遍历的操作，最终采用的方案是把数据从原来的产品数据库中导出后存到Hadoop集群的HDFS中采用Parquet格式存储数据，后继采用Spark来访问时，遍历数据的时间可以控制在数分钟级别。