b树
这是在blog迁移后,将原blog的部分文章重新进行迁移。回头看以前写的东西,很多原来写的东西都变得理所当然,无需赘言;也有很多幼稚的错误,读起来感觉很傻。
btree的特点
btree最大的特点在于是一个绝对平衡的多路搜索树。能够保证所有叶子节点在同一层。同时由于每层的节点很多,所以树的深度很小。能够保证即使btree的下层节点不在内存里,也可以在最短的跳跃后找到。
btree能够保证这个特性的方法就是在保证树的度数超过阈值后,采用分裂的方法,而不是继续向下插入。
这个方法的具体描述就是。btree中对所有非根节点的所含的数据数量有这样一个要求,最少不能少于t-1,最大不能超过2t-1。根节点可以少于t-1但不能超过2t-1。t >=2
插入的时候一旦要超过这个数量,就把树分裂。删除的时候一旦要少于这个数量,要么从兄弟节点借一个节点来充数,如果兄弟节点也不够,就把子树合并。
这样,保证了btree节点最多数据的时候数据的数是一个奇数。因为2t-1==2(t-1)+1,所以一个满节点可以分裂成一个至少有一个数据的根,外加2个最小的节点。
多说无益,上代码
|
|
b+树
在之前,我一直只把b+tree当成是btree的一种变形,或者说是在某种情况下的一种优化,另外一些情况可能还是btree好些。但是做完之后才发现,b+tree在各种情况都可以完全取代btree,并能够让索引性能得到比btree更好的优化。因为b+tree设计的核心要点,是为了弥补btree最大的缺陷。
btree最大的缺陷是什么?
首先,我们知道对于btree和b+tree这种多路搜索树来说,一个很重要的特点就是树的度数非常大。因为只有这样才能够降低树的深度,减少磁盘读取的次数。而树的度数越大,叶子节点在树中的比例就越大。假设度数为1000,那么叶子节点比他上一层内部节点的数量至少要多1000倍,在上一层就更加可以忽略不计了。可以说树种99.9%的节点都是叶子节点。 但是对于btree来说,所有节点都是一样的结构,都含有一定数量的数据和指向节点的指针。这两项数据占据btree节点的几乎全部的空间。一个节点内的数据的数量比硬盘指针的数量少一,可以说和指针的数量几乎相等。对于python这种动态类型语言感觉不出来,但是对于C这种固定类型语言来说,即使这个children list数组为空,这个数组的空间也都是预留出去的。导致的结果就是占绝大多数的叶子节点的children list指针数组所占的磁盘空间完全浪费。
一个数据的大小和硬盘指针的大小取决于key-value中key和value大小的比值。假如说这个比值是2:1。那么btree浪费了几乎1/3的空间。
b+tree针对这个问题的,把叶子节点和内节点的数据结构分开设计,让叶子节点不存放指针。因此同样大小的叶子节点,b+tree所能包含数据数量要比btree大。按照上面的假设就是大1/2。数的深度很可能比btree矮,大范围搜索或遍历所需要的载入磁盘的次数也少。
另外,b+tree还有一个特点是所有数据都存放在叶子节点,这些叶子节点也可以组成一个链表,并把这个链表的表头拿出来,方便直访问数据。有些文章认为这对于范围搜索来说是个巨大的优化。但是就我的看法,这个特性最大的作用仅仅是让代码更容易一些,性能上,只会比树的遍历差,而不会比树的遍历好。因为不管是用指向叶子节点的指针搜,还是用树的遍历搜,所搜索的节点的数量都是几乎相同的。在相同大小的范围搜索的性能,只取决于访问顺序的连续性。从树根向下遍历,那么一次可以取得大量的子节点的范围,并针对这些节点做访问排序,得到更好的访问连续性。如果是沿着指向兄弟节点的指针搜索,一是兄弟节点也许是后插入的,存放并不一定和自己是连续的,二是只有每次从硬盘中将该节点载入到内存,才知道兄弟节点放在硬盘哪个位置,这又变成了对硬盘的一个随机的同步操作,性能的下降可想而知。
说b+tree因为有指向兄弟节点的指针方便数据库扫库这种结论,是不正确的。
老规矩,不废话
|
|
总结
实现过程和btree很像,不过有几点显著不同。
- 内节点不存储key-value,只存放key
- 沿着内节点搜索的时候,查到索引相等的数要向树的右边走。所以二分查找要选择bisect_right
- 在叶子节点满的时候,并不是先分裂再插入而是先插入再分裂。因为b+tree无法保证分裂的两个节点的大小都是相等的。在奇数大小的数据分裂的时候右边的子节点会比左边的大。如果先分裂再插入无法保证插入的节点一定会插在数量更少的子节点上,满足节点数量平衡的条件。
- 在删除数据的时候,b+tree的左右子节点借数据的方式比btree更加简单有效,只把子节点的子树直接剪切过来,再把索引变一下就行了,而且叶子节点的兄弟指针也不用动。