kv存储引擎索引设计思考

Cassandra自从出了几次大的宕机的情况之后，很少有大公司在用了，我目前知道的，就是twitter的抓取服务使用的Cassandra来存储抓取数据元信息，而且，国内某搜索引擎公司，也是这么做的。我最近的工作之一，就是改进Cassandra，选它一方面是公司的要求，另一方面，学习空间、提速空间性能都比较大。 经过一段时间的调研，确认了三个改进方向（由于公司的原因，现在我只说第一个）。第一个就是索引压缩的改进，往大了说，就是要对Cassandra的索引进行重新设计。重新设计的思路，下面会慢慢讨论。 对于kv存储引擎的索引，根据key是否有序，分为两种：一种是key如果无序，则可以采用hash的方法；另一种是，如果key有序，则可以采用B+树的方法，或者类B+树的方法。目前国外研究领域主要集中在hash方法的改进上，原因不明。但是这两类方法，各有各的优缺点，下面逐一分析，以便指导改进Cassandra的索引结构。

           

上面的图是从淘宝技术博客转过来的，说明了一部分的问题。对于hash的方法，查找（hit），写入的时间复杂度非常低，性能非常高，这意味着，采用hash的方法建索引，写入的性能非常可观，要比采用B+树的方法，快得多。但是，hash的方法，为了处理碰撞，往往空间利用率比较低，占用空间较大。例如， cuckoo hash方法的空间利用率只有50%，所以那些老美的研究，就集中在，如果提高hash方法的空间利用率，减少空间占用。如果细心的同学，可能发现，上文有个括号，里面有一个hit，这个意思是，在miss的情况下，hash方法的查找效率会急剧下降，所以，在使用hash方法做索引的同时，往往会使用bloomfilter类似的结果进行过滤，提高吞吐率。下图，是目前一些hash方法占用空间和每次查找的读磁盘情况：

               

上图中的SILT方法，是hash和trie tree方法的合并。 对于传统B+树而言，相对hash的方法，可以支持范围查找，能够有良好的压缩比，单机可以存储更多的数据。但是索引查找（hit和miss是一样的）、索引创建的性能，都无法于hash方法相比。这就注定了如果采用B+树的方式，数据库的写入性能，不会有hash的方法快，但是支持的数据量会大很多。而且，压缩效果好，可以更多的索引放在内存中，以保证每次查询，小于等于1的读盘次数。有关B+树的详细介绍，可以参考引用中的博文。 综上的两种方法的特点，其实已经得出kv存储引擎设计的基本思路，不同的索引创建、查找的性能不同；压缩效果不同。所以，kv存储引擎必然是多种方法综合的产物，这样才能够应对实际过程中的情况。其核心思想就是：将数据分级存储。我们将数据分为三级，第一级（内存）、第二级（磁盘）、第三级（磁盘）。第一级和第2级采用hash方法索引，第三级采用传统B+树的方法，不过要有好的压缩策略，第一级数据批量写到第二级，第二级批量合并到第三级。保证整体的读写性能。这个思想，并非我独创，而且通过阅读论文，总结出来的。这个确实是一个简单，重要的思想。

【引用】

http://rdc.taobao.com/team/jm/archives/1387 SILT: A Memory-Efficient, High-Performance Key-Value Store

 

转载于:https://www.cnblogs.com/sing1ee/archive/2011/12/25/2764983.html