由Rocksdb状态后端引出的Tree的应用

1.前言

　　本节主要是由于Rocksdb的数据结构LSM树，所以介绍一下常见的树结构在不同场景下的应用，更好的理解一下常见的数据库，KV存储系统都是如何设计，以及为什么这样设计的。

2. 二叉树

　　二叉树：每个节点至多有两个子节点。可以计算高度为N(从0开始计数)的二叉树，最后一层最多有2^N个节点，全部节点数是2^(N+1) - 1个节点

　　完全二叉树：除最后一层，其他层的节点数达到最大，最后一层所有节点集中在左边

　　满二叉树：这个国内和国外定义好像不太一样，这里按照国内定义：所有的层节点都满了，即是满二叉树：其节点数就是二叉树说的2^(N+1) - 1个

　　二叉查找树：上面的二叉树都是一些简单的定义，二叉搜索树则是具有实际使用用途的，定义也很简单：对于任何节点来说，其左子节点的值< 当前节点的值 < 其右子节点的值 (左右节点存在)

　　　　　　　　利用上面的性质，就可以从根节点开始，判断大小选择左右分支，找到数据是否存在了。

　　AVL树(平衡二叉树)：二叉查找树的问题在于构建的树可能比较极端，全部节点都在一侧，导致查找效率不高。平衡二叉树就是用来解决这个问题的：其构建保证任何节点的两个子树的高度最大差别为1。

　　　　　　　　　　　  AVL树保证了效率为O(logn)，要保证AVL树的特点，增加删除节点都会破坏AVL树的定义，所以需要进行旋转，旋转分成LL,LR,RL,RR。

　　　　　　　　　　　  具体操作看文章：https://www.cnblogs.com/skywang12345/p/3576969.html

3.红黑树

　　上面介绍了AVL树，从AVL树的定义上来看是一种优势巨大的二叉树了，但是为什么还会有红黑树呢？

　　原因在于AVL树虽然可以保证高效的查询，但是保证不了高效的插入删除。因为为了维持任何节点的两个子树高度最大差别为1带来的旋转代价是巨大的，简而言之就是AVL树适合查找多而插入删除少，而实际运用中这种场景还是不多的。红黑树是AVL树的一种变体，其是一种弱平衡二叉树，妥协解决了插入和删除频繁旋转的问题，所以像Java高版本的hashmap冲突构建的是红黑树，TreeMap也是一个红黑树。

　　红黑树的名称来源，其将所有节点划分成红节点和黑节点，其要求：1.根和叶子节点（NULL节点）必须是黑的，2.每个红节点的子节点都是黑色，3.从任一节点到每个叶子节点的路径包含的黑节点数量一致。

　　其定义约束了最长路径和最短路径差距最多两倍长（最短全是黑节点，最长红黑相间），红黑在查询中没有实际意义，但是在旋转平衡的时候就有特殊的指导意义了。

　　https://www.cnblogs.com/xrq730/p/6867924.html

　　红黑树平衡分成修改颜色，以及左旋和右旋，参考文章：https://www.cnblogs.com/CarpenterLee/p/5503882.html。讲的比较详细。

　　本文想表达的也不是红黑树，所以与之相关的内容就到此为止。

4.磁盘上的树

　　从这里开始是本文的核心内容。我们都知道内存比磁盘快很多，但是内存容量小且断电数据就会丢失，磁盘虽然保存了就不易丢失，但是查询速度慢，那么海量数据无法加载到内存中，又是如何做到令人可以接受的查询插入速度呢？这就是索引的魅力，索引使用较小的数据空间，可以快速定位数据位置，达到目标，上面所说的AVL和红黑树都可以作为索引，但是对于磁盘而言并不会使用二叉树。原因很简单，二叉树只有两个子节点，很容易树的高度变得无法接受。

　　首先回顾一下磁盘的特性，才好针对特性设计合适的数据结构。磁盘是以扇区为基本单位，一个扇区512字节（存在4kb的），磁盘可以保证单个扇区的原子性，要不写入成功，要不失败。磁盘有很多个柱面，每个柱面有不同的磁道，每个磁道又被划分成扇区，读取数据要三个坐标定位一个扇区，之前的磁盘都是单臂操作，只有一个磁头在工作，目前好像有双臂操作的机械盘。这篇文章介绍了更详细的磁盘知识：https://blog.csdn.net/u012184539/article/details/84257877 ，http://c.biancheng.net/view/879.html。磁盘操作的时间有：寻道，旋转和数据传输。数据传输一般不考虑，所以优化都集中在寻道和旋转上，寻道一般在10ms左右，所以1秒也只能操作100次，旋转取决于转速。固态硬盘则是完全不同的存储结构，容量小且贵，目前而言用作大数据存储成本过高，不做考虑。

　　简单而言，磁盘的寻道和旋转会是性能瓶颈，所以需要减少这个次数，另外顺序写的速度是很高的，而且顺序操作也变相的解决了寻道和旋转的效率问题。

　　既然都知道顺序写是很好的解决方法，那顺序写不就完了吗? 问题在于做不到啊。不考虑其他应用程序对磁盘的随机使用，单单说数据库本身，数据在不断的修改，插入删除，从根本上就无法保证数据在磁盘上是简单的连续的。所以我们需要作出妥协，充分利用磁盘特性实现目的。下面介绍B+树和LSM树是如何适应磁盘的。

4.1 B+树

　　B+树是由B树引申而来，可以参考一下这篇文章：https://blog.csdn.net/u013400245/article/details/52824744，https://www.jianshu.com/p/71700a464e97

　　这里总结一下B树性质，一个M阶的B树：

1. 每个节点最多有M个子节点 (M>=2)
2. 每个节点最少有ceil(M/2)个子节点，向上取整
3. 所有叶子节点都在同一层，且不包含任何关键字信息
4. 有x个孩子节点的节点包含x-1个关键字，从小到大排列

　　B+树相比于B树的区别：

1. 有k个子结点的结点必然有k个关键码
2. 非叶子节点只有索引作用，不含数据
3. 叶子节点包含数据，而且用双向链表连接

　　一棵含有N个总关键字数的m阶的B树的最大高度是多少？https://blog.csdn.net/ASJBFJSB/article/details/100114403

　　logm(n+1)<= h <=log(ceil(m/2)) (n+1)/2 + 1

　　关于树的特性说明就到这里，下面结合mysql说明一下为什么使用这种结构，并详细说明mysql中二次写，redo日志等操作的原因。

　　首先mysql选择了B+树而不是B树，原因可能如下：1.非叶子节点都是索引，没有数据，所以索引里面可以存更多的关键字。2.叶子节点都是数据，而且是双向链表，范围查询更方便

　　接下来就是详细分析，先说结论：B+树在磁盘的应用就是减少了磁盘寻道时间，但是不是无限制的提升：https://blog.csdn.net/csdnlijingran/article/details/102309593 mysql一般到了千万级性能就会下降了，B+树的高度一般在3层。mysql具体操作步骤如下，这里会混合着mysql本身的知识点进行说明：

　　mysql是以页来管理数据的，一页16kb.

　　1.查询一条数据：select * from table1 where id = 5 (假设id是聚集索引). 从B+树根节点出发，读取根节点页，放入缓存，进行二分查找，找到下一个索引位置页，读入内存，继续查找直到数据页。

　　　所以一次查找由树的高度决定，一般3层高度，结果就是执行3次IO，寻道和旋转，所以大概几十毫秒就够了。而且由于有缓存，后续命中缓存速度会更快。

　　　这也就是上面说的为什么二叉树不能这么操作的原因了，树的层级过高，磁盘操作次数会变多。mysql保证单个数据页是连续存储，所以B+树的单个节点可以看成一个单元，但是不同的节点在磁盘上并不是顺序的，这部分寻道是无法节省的。第二个问题是为什么4层5层就不行了呢？多加一层按照上面计算逻辑，可以容纳的记录数是惊人的，按照我的理解原因是由多方面造成的：首先是B+树的分裂合并造成在磁盘上的位置更加随机，不连续，寻道旋转耗时更久。第二个是数据量过多，缓冲区可能容纳不了，导致磁盘查询更加频繁。
　　2.插入更新数据：这一块mysql对性能和安全性做了大量的设计优化。更新数据，事务提交主要做了两件事情：第一是将事务写入日志缓冲，再将日志缓冲刷入事务日志(redo log)。第二是将事务写入缓冲池。这两个步骤都提交成功了，事务就成功了。因为插入都是随机的，对于磁盘而言就是随机写，这在上面我们说过对磁盘而言这并不友好，所以mysql先用顺序写，写入事务日志，然后写入缓冲池。这个时候可以看见随机写没有发生，只是写了事务日志，宕机时从事务日志恢复就可以了。被修改的缓冲区的页被称为脏页，还没有被写入磁盘，会通过一定规则写入磁盘。写入的时候并不是直接将脏页刷入磁盘，这是因为闪断的时候页数据会被破坏(历史上发生过)，而数据页本身损坏了，事务日志记录的是物理修改，也就没法恢复整个页。所以现在的mysql都使用double write方式，先按顺序写入double write区域（也是顺序写），然后修改磁盘的数据，闪断的时候还能通过double write数据进行修复。所以整个发生了2次顺序写，一次随机写。写入事务日志可以配置规则，因为我们知道只有flush才算成功写入磁盘，否则都在磁盘的缓冲中，flush会影响写入性能，所以mysql让用户决定什么时候flush。https://blog.csdn.net/zhaoliang831214/article/details/82711350

　　这篇文章详细介绍了redo log和undo log：https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html

　　总结一下：mysql是以页为单位进行管理的，每次都会将页读取到内存中进行操作，由于B+树的高度原因，查找一个页的位置是可以预估到次数的。由于buffer pool还会缓存页，所以实际磁盘操作比想象中要少，如果数据量超过缓存大小，性能势必下降了，没有绝对的数值，都是根据内存有多大决定表的记录数达到多少有性能瓶颈。写入由于不可能顺序写，一定会产生随机写，原本应该存在性能问题。但是mysql采取了redo log的方式，将数据临时顺序写入磁盘，认为是数据保存成功，所以将随机写变成了顺序写，提升了写性能。后面由于实际修改页怕损坏，采取double write机制，先写共享表的一个2MB数据空间，这个也是顺序的，再随机写修改页。由于是异步线程操作，而在顺序写redo log就可以认为数据实际上已经不会丢失，所以这个速度不影响mysql的正常查询修改删除。

4.2 LSM树

　　在Hbase权威指南一书中就讨论过B+树和LSM树的区别，主要在于如何利用磁盘。B+树利用磁盘的随机查找能力，涉及上尽量避免随机写以及多次IO，结果是随机读取优势很大。LSM树利用的是磁盘的连续传输能力，并排序和合并文件。文中假设10MB/s带宽，10ms的磁盘寻道时间，每条数据100字节（100亿条数据），每页10KB（10亿页），更新1%的数据需要多久? 随机B树需要1000天，批量100天，排序和合并只需要1天。

　　从上面的描述可以看出，LSM在写入上存在优势，当然是建立在牺牲了部分读取性能的基础之上。原论文地址：https://www.cs.umb.edu/~poneil/lsmtree.pdf。下面简单说下LSM树的思想。

　　首先，LSM树不是一棵树，也不一定是树形结构，也有使用跳表的（Hbase C0树）。LSM树有几个重要概念：

1. 具有很多层级，从C0  - CN。
2. C0一般都是在内存中，不同应用的称呼不一样，rocksdb中为MemTable。
3. 读写一般都是操作MemTable，这个是内存操作，根据局部性原理，一般命中概率会大。写入很好理解，读取没读到会查询C1层的文件。
4. 满足一定条件后，C0的MemTable会变成ImmuTable，然后刷入磁盘变成SST文件，SST文件都是不可变文件，所以这种做法可以充分利用顺序写性能。

　　上面的结构和优缺点可以参考文章：https://www.cnblogs.com/cobbliu/articles/9553271.html

　　简单来说，只有C0级内存树可以进行修改，ImmuTable开始到文件后都不允许修改了，所以没有B+树那种删除添加的问题。同时内存是有限的，所以需要读取磁盘获取数据，这部分就是读取的瓶颈。

　　所以LSM树的优化集中在对数据的查询上。第一点优化就是随着SST文件的不断生成，小文件会越来越多，需要将小文件进行合并，这就是所说的compact操作，将小文件合并成大文件，由于之前要求单个文件中数据有序，这样可以增快合并速度。第二点优化就是由于不知道数据落在哪个文件上，需要查询所有的文件，所以在每个文件上引入了bloomFilter，更快的定位数据可能出现的文件，搜索更少的文件。https://www.jianshu.com/p/f911cb9e42de，https://blog.csdn.net/varyall/article/details/79980915这两篇文章配合图片更易理解。

　　一句话总结，LSM牺牲读取，利用磁盘连续传输能力提升性能，通过compact和bloomFilter提升读取性能，局部性原理：如果一个数据最近被使用，那么它被再次使用的可能性就更大了，所以多层级的结构，可以认为历史很久之前的数据被访问的概率更小。

　　https://blog.csdn.net/f1550804/article/details/88382750

5. RocksDB

　　上面介绍了不同的树结构在磁盘上的运用，这里主要介绍一下compact策略，以及相关问题和参数调优。

　　这篇文章介绍了RocksDB的compact策略 https://www.jianshu.com/p/e89cd503c9ae

　　总结一下：compact策略一般有两种：

1. size-tiered compaction：思路就是每个文件有固定阈值，每层有固定文件数量，到达后就开始合并，放入更高层。存在的问题是空间放大：因为LSM的文件是不可修改的，所以对数据的增删改都会生成新的记录，查询的时候按照文件生成的顺序，逆序找到最新的一条记录就是当前记录了。其他的数据都是多余的，另外在compact操作的时候，执行完之前原文件也是不可删除的，所以单个sst可能放大2倍。
2. leveled compaction：思路是同一层级的sst文件包含不同范围的key值，比如1文件范围0-10，2文件范围11-20，前面层级的包含范围更大，影响下游部分文件，比如前层级的包含键值是0-100，对应下游就是0-10，11-20等等10个文件，所以0层级的是全部的key的集合。这样在单个文件compact时，只会影响到该层一个文件和下游若干文件，而不是所有，可以有效缓解空间放大问题（这种结构就像B+树的索引节点）。但是与之而来的问题更麻烦了，其会造成写入放大，原因也很好理解，就是会造成逐层影响，直到最后层级。size-tiered只会影响一层，因为其阈值是确定的，该层全部合并走向下游。但是leveled具有上下游紧密联系，第一层刷到第二层可能触发第二层的compact，第二层会造成第三层的合并，最后造成大量的无意义的磁盘操作。

　　RocksDB采取了混合模式，详细看上面的文章。

　　接下来是Flink运用时的一些参数调优，参考文章：https://cloud.tencent.com/developer/article/1592441

　　首先，Flink使用时keystate禁用了WAL，WAL会有性能问题，而Flink有自己的容错机制，不太需要。内存中有memTable和ImmuTable，这上面已经说明了，还有一种就是Block Cache，不可能每次都去查找磁盘，查找到后肯定会cache下来。

1. 毫无疑问，缓存大小肯定直接影响读写性能。block size(state.backend.rocksdb.block.blocksize)，block cache size(state.backend.rocksdb.block.cache-size)。block的大小是sst文件的基本单位，和mysql的页差不多，一般是4KB，生产中调整到16-32kb，固态可以达到128KB。增加block size会造成读放大，原因是cache没变，block增大，能放入的block数量就会变少，所以命中缓存率会降低，磁盘IO增多。所以改变这个值需要同步修改block cache size，如果内存吃紧，就不要变动了。block cache size默认是8MB，可以设置成32MB-256MB。开启state.backend.rocksdb.metrics.block-cache-usage观察cache使用情况，进行调优
2. 最大可以打开的文件句柄(state.backend.rocksdb.files.open)。这个也较容易理解，最好让rocksdb保持所有管理的文件都可以读取状态。没有开启cache_index_and_filter_blocks，该值表示内存中可以容纳的index和filter数量，建议操作系统和程序都改成-1.
3. cache_index_and_filter_blocks默认是false,不再内存中存放index和filter，用到才加载，用完舍弃。true表示运行放入block cache中，可以提升局部读取性能，开启需要同步开启pin_l0_filter_and_index_blocks_in_cache，防止操作系统换页操作造成的性能抖动。由于放入cache中会占用空间，所以除非你内存有多，或者存在局部键值热点，可以加速，否则会减少能容纳的缓存，导致性能变差。
4. optimize_filters_for_hits设置成true，L0不会生成bloom filter,可以减少90%的filter开销。同样只适合有局部热点和基本不会cache miss的场景
5. Flink中每个State对应了一个ColumnFamily，每个ColumnFamily都有一个memTable，1.10可以共享。需要计算自己的状态可能的大小值进行设置。
6. write buffer size（state.backend.rocksdb.writebuffer.size），就是memTable的大小，默认64mb.调整这个参数还需要调整以下内容：1.state.backend.rocksdb.compaction.level.max-size-level-base 一定需要增大level1层的阈值，该值太小会造成能存放的SST文件过少，层级变多造成查找困难，太大会造成文件过多，合并困难。2.max_bytes_for_level_multiplier是leveled下的一个倍数设置。3.state.backend.rocksdb.writebuffer.count 内存中可以存放的memTable个数，超过这个值会被flush到磁盘，内存足够可以调整到5。4.state.backend.rocksdb.writebuffer.number-to-merge，合并的最小阈值，调大调小都有很大影响，最好是3
7. 其他是一些compact和flush的控制，不再展开

　　最后附上文章：https://cloud.tencent.com/developer/news/643334  快手基于hbase开发了一个slimbase做为状态后端，解决rocksdb的部分问题。

　　最后一个小问题，hbase的存储结构也是LSM，学习了上面的都应该知道KV存储，LSM是不能删除修改的，每次都是读取最近文件命中的数据，所以一个key只会认同一条记录。那么hbase的column数据是具有版本概念的，这个是怎么实现的呢？......  这个其实也很简单，我们一般在表象上看见hbase的键是rowkey，但存储的时候肯定不是存的rowkey，否则值存哪个column的数据呢？所以在HFile中存储的键是由rowkey, columnFamily,column和timestamp组成的，所以这个就是表象上的column的多版本了。键值设计参考：https://blog.csdn.net/ping_hu/article/details/77115998