LSM-Tree关键技术.docx

LSM-Tree关键技术1.0、哪里用到了LSM-Tree? ? 最初看到LSM-Tree这个树结构，是从友情站点NoSQLFan上一篇介绍有着高性能key-value的数据库nessDB的文章内了解到的。nessDB是一个小巧、高性能、可嵌入式的key/value存储引擎，使用标准C开发，支持Linux,?*BSD,?OS?X?and?Solaris等系统，无第三方库依赖。同时nessDB还提供一个服务端，支持Redis的?PING,?SET,?MSET,?GET,?MGET,?DEL,?EXISTS,?INFO,?SHUTDOWN?命令，你可以使用任何一款Redis客户端来连接和操作nessDB。????而整个引擎基于LSM-Tree思想开发，对随机写非常友好。为提高随机读，nessDB使用了Level?LRU和Bloom?Filter策略。我们知道，现在一般主流的数据库索引一般都是用的B/B+树系列，包括MySQL及NoSQL中的MongoDB。而这个nessDB为何例外，LSM-Tree有何特别呢？抱着对它的好奇，便研究学习了下此LSM-Tree。? ? 甚至包括现在另一种比较火/流行的数据库Cassandra 以及与众多类BigTable存储一样，都采用的是LSM-Tree?结构来存储数据，简单来说就是将原来的直接维护索引树变为增量写的方式，这样能够保证对磁盘的操作是顺序的。????再后来，看到了一篇论文：The?Log-Structured?Merge-Tree，这篇论文原英文有30多页，看了两个下午。下面，本文第一部分就结合这篇论文及星星的译作，从最基本的LSM-Tree的C0C1两组件算法，谈到多组件算法，让读者对LSM-Tree这个树结构的原理有个充分的认识与理解。1.1、什么是LSM-Tree? ? 相信随着NoSQL据库，尤其是类BigTable系统的流行，LSM-Tree这个树结构，大家很快就不会再如此时这般陌生了。blog内已经详细阐述过B/B+树，那么这个LSM跟B树系列相比，有什么不同呢，它的优势在哪，适用于何种情况？一切，请听我慢慢道来。????此处的Log-Structured这个词源于Ousterhout和Rosenblum在1991年发表的经典论文The?Design?and?Implementation?of?a?Log-Structured?File?System?，这篇论文提出了一种新的磁盘存储管理方式，在这种结构下，针对磁盘内容的所有更新将会被顺序地写入一个类日志的结构中，从而加速文件写入和回收速度。该日志包含了一些索引信息以保证文件可以快速地读出。日志会被划分为多个段来进行管理。这种方式非常适合于存在大量小文件写入的场景。????LSM-Tree具体是一种什么样的树结构呢，具体来说，LSM-Tree通过使用某种算法(两组件C0C1及多组件算法)，对索引变更进行延迟及批量处理，并通过一种类似于归并排序的方式高效地将更新迁移到磁盘。它使得我们可以使用更少的磁盘运动来执行在Acct-ID||Timestamp上的频繁插入操作。????将索引节点放置到磁盘上的这一过程进行延迟处理，是最根本的，LSM-Tree结构通常就是包含了一系列延迟放置机制。LSM-Tree结构也支持其他的操作，比如删除，更新，甚至是那些具有long?latency的查询操作。只有那些需要立即响应的查询会具有相对昂贵的开销。LSM-Tree的主要应用场景就是，查询频率远低于插入频率的情况(大多数人不会像开支票或存款那样经常查看自己的账号活动信息)。在这种情况下，最重要的是降低索引插入开销；与此同时，也必须要维护一个某种形式的索引，因为顺序搜索所有记录是不可能的。? ? 因此，LSM-Tree最适用于那些索引插入频率远大于查询频率的情况，比如，对于历史记录表和日志文件来说，就属于这种情况。OK，接下来，咱们就来截杀这个两组件C0C1算法，以及多组件算法。1.2、LSM-Tree之两组件C0C1算法? 1.2.1、LSM-Tree两组件COC1????由上文，我们已经知道，LSM-Tree通过使用某种算法(两组件C0C1及多组件算法)，对索引变更进行延迟及批量处理，并通过一种类似于归并排序的方式高效地将更新迁移到磁盘。更进一步，LSM-Tree由两个或多个类树的数据结构组件构成。我们先考虑简单的两个组件的情况，如下图所示：????如上，便是LSM-Tree之两组件C0C1算法的示意图。C1树在左边，存在于磁盘Disk上，C0树在右边，存在于内存Memory上。?????在每条历史记录表中的记录生成时，会首先向一个日志文件中写入一个用于恢复该插入操作的日志记录。然后针对该历史记录表的实际索引节点会被插入到驻留在内存中的C0