LSM树原理、应用与优化

0.766字数 2048阅读 3978

前言:为什么传统数据库使用B树较多,而大数据存储使用LSM树较多?kudu为什么比hbase更适合支持OLAP查询?

上一篇场景和挑战 提到数据系统最基本的需求就是数据存取,多数情况下数据是一条条记录,每条记录包含key和value。为了提高存取记录的效率,我们知道传统数据库多使用B树作为索引结构。而在大数据场景下,hbase、kudu等存储引擎为什么选择LSM树呢?本文首先介绍什么是LSM树;然后与B树简单对比,分析其优势和缺点;最后再看一下hbase和kudu对LSM的实现和优化以及它们之间的对比。

LSM树


上图引用自BigTable论文,我们直接来看采用LSM树的存储引擎读写数据时的流程,就能比较直观的理解LSM树了。
插入/更新数据:
  当有记录要插入时,按key在memtable中找到相应位置,如果已存在此key值,那就直接更新。memtable是内存中存数据的地方,这些数据按key值排序,为了快速查找,会有红黑树之类的数据结构作为索引。当memtable大小到一定阈值,就把它连同索引一起存到一个文件,这个文件就是一个SSTable。这样SSTable会越来越多。后台compaction线程会按一定策略被触发,去对SSTable文件进行合并。由于数据在每个SSTable中是排好序的,合并的过程就是归并排序。
  在把记录按key排序写到memtable的同时,会写到一个log文件中。这个log文件不用排序,它是为了容错,当memtable数据丢失的时候可以由此重建。当memtable写入文件后,这个log文件的内容就不再需要了。而新的memtable会有新的log文件对应。
读数据:
  首先在memtable中查找,没找到的话,再按时间顺序在SSTable文件中查找。当读数据的时候,如果某个记录不存在,需要读取所有的SSTable才能确定。所以一般每个SSTable文件生成的时候会带一个bloom filter,对这一点进行优化。

LSM VS B树
  B树被广泛应用于各种传统数据库。采用了B树的存储系统,所有数据都是排序的,并将这些数据分成一个个page。而B树就是指向这些page的索引组成的m阶树。每次读写数据的过程就是顺着B树查找或更新各个page的过程。B树相对于AVL、红黑树等的优点在于可以减少文件读写次数。
  对比LSM和B树之前,我们先来考虑一下它们为什么会设计成这样。要设计一个系统,我们可以从最简单的设计出发。对于存储系统,最简单的就是把记录直接写到记录文件的末尾,这样的做法写效率是最高的。然而要查询某一条记录,需要遍历整个文件,这是无法接受的。为了快速查询,一个办法是建立hash索引,但是hash索引有其自己的问题,比如数据量大的时候,索引在内存中就放不下了。另一个办法就是事先对数据进行排序。从排好序的文件中查找记录有一箱的数据结构可以用,平衡二叉树、堆、红黑树等等,还有今天的主角B树(啊,不,B树只是被来出来陪衬的,今天的主角是LSM)。
  这里的关键是“事先”是什么时候。首先会想到的思路是在写入的时候。在计算机系统中真正foundmental的创新是很不容易的。大多数的优化其实都是tradeoff,也就是牺牲一点A,得到一点B。在这里,一共两种操作,写入或者读取,为了提高读取效率,我们就要在写入的时候多做一些事情。对于B树,这多做的事情首先是找到正确的位置,其次还会有page的分裂等。
  大多数时候,B树的表现是很优秀的,他也一直很努力的提高自己,不断增加新技能,进化出了B+\B*树等进化体。然而当系统同时服务的客户越来越来多,对吞吐量的要求越来越高。B树表示在大并发写操作的时候,压力有点大,因为要做的事情有点多。那怎么办,为了读取数据的时候轻松一点,这些事情不得不做啊。
  当B树不堪重负的时候,主角LSM树登场了。他说,想要有高的写吞吐,就给我减负,我可管不了那么多,我可是主角。作者也很无奈,想想也是,哪个主角没几个挂呢,给他开挂吧。本来都是写入的时候要做的事,就少做一点吧,给你几个后台线程,剩下的事情用它们做吧。有了这几个后台线程帮忙,LSM树处理大量写入的能力一下就上来了。LSM由此直接拿下Hbase、Cassandra、kudu等大量地盘。老大哥B树表示,他有挂,我很慌。
  到这里就比较清楚了,B树把所有的压力都放到了写操作的时候,从根节点索引到数据存储的位置,可能需要多次读文件;真正插入的时候,又可能会引起page的分裂,多次写文件。而LSM树在插入的时候,直接写入内存,只要利用红黑树保持内存中的数据有序即可,所以可以提供更高的写吞吐。不过,把compaction交给后台线程来做,意味着有时间差,读取的时候,通常不止一个SSTable,要么逐个扫描,要么先merge,所以会影响到读效率。另外,当后台线程做compaction的时候,占用了IO带宽,这时也会影响到写吞吐。所以B树还不会被LSM取代。

Hbase VS kudu
  Hbase 的存储实现是LSM的典型应用,适合大规模在线读写。然而,除了这种OLTP的访问模式,正如我在大数据场景与挑战中提到的,还有一种OLAP的数据访问模式,Hbase其实是不合适的。对此,最常见的做法是定期把数据导出到专门针对OLAP场景的存储系统。这个做法一点都不优雅,因为一份同样的数据同时存在两个不同的地方,而且还会有一个不一致的时间窗口。Kudu就是为了解决这个问题而诞生的。我最早看到kudu就很有兴趣,也很好奇,一个存储系统能同时满足OLTP和OLAP两种场景,那是厉害的。不过现在kudu由于运维成本等其他问题还没有被广泛采用,挺可惜的。
  扯远了,我们来看为了更好的支持OLAP,kudu对LSM做了哪些优化。OLAP经常会做列选择,所有的OLAP存储引擎都是以列式存储的。kudu也想到了这一点。kudu的memtable(在kudu中叫MemRowSet)还是同之前一样,只是SSTable(在kudu中叫DiskRowSet)改成了列式存储。对于列式存储,读取一个记录需要分别读每个字段,因此kudu精心设计了RowSet中的索引(针对并发访问等改进过的B树),加速这个过程。
  除了列式存储,kudu保证一个key只可能出现在一个RowSet中,并记录了每个RowSet中key的最大值和最小值,加速数据的范围查找。这也意味着,对于数据更新,不能再像之前一样直接插入memtable即可。需要找到对应的RowSet去更新,为了保持写吞吐,kudu并不直接更新RowSet,而是又新建一个DeltaStore,专门记录数据的更新。所以,后台除了RowSet的compaction线程,还要对DeltaStore进行merge和apply。从权衡的角度考虑,kudu其实是牺牲了一点写效率,单记录查询效率,换取了批量查询效率。

这样看来,从B树到LSM,到kudu对LSM的优化,其实都是针对不同场景不同的访问需求做出的各种权衡而已。了解了这些,我们在选择这些技术的时候心里就有底了。另外,权衡并不是那么容易的事。怎么样牺牲A去补偿B,可能有不同的策略。研究现有系统的一些思想,有助于当我们自己面临问题的时候,有更多思路。

推荐阅读更多精彩内容