SQLite中B-tree、B+tree初步探秘(欢迎指正,共同进步)

前端之家收集整理的这篇文章主要介绍了SQLite中B-tree、B+tree初步探秘(欢迎指正,共同进步)前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

最近半年实验室一直在fedora下用Qt做ARM平台的火灾自动报警方面的开发,用的是sqlite数据库。作为一个嵌入式的数据库,确实有好多过人之处,个人蛮喜欢。于是找来

《The Definitive Guide to sqlite》深入探究一下,这本书1/3将怎么契合sql使用,1/3讲C API接口实现,剩下的一直在讲述sqlite内部实现机制。从前到后,一直强调数据库文件格式:表用B-tree,索引用B+tree,本科数据结构(严蔚敏版)讲到B tree,但是只是理论说教,屁用没有。不废话了,直入主题

在进一步探究sqlite之前,先预热一下,说说B tree、B-tree和B+tree。

参考:http://www.jb51.cc/article/p-mvymaale-bk.html

(1)B tree

即二叉搜索树:

1.所有非叶子结点至多拥有两个儿子(Left和Right);

2.所有结点存储一个关键字;

3.非叶子结点的左指针指向小于其关键字的子树,右指针指向大于其关键字的子树;



B树的搜索,从根结点开始,如果查询的关键字与结点的关键字相等,那么就命中;

否则,如果查询关键字比结点关键字小,就进入左儿子;如果比结点关键字大,就进入

右儿子;如果左儿子或右儿子的指针为空,则报告找不到相应的关键字;

如果B树的所有非叶子结点的左右子树的结点数目均保持差不多(平衡),那么B树的搜索性能逼近二分查找;但它比连续内存空间的二分查找的优点是,改变B树结构(插入与删除结点)不需要移动大段的内存数据,甚至通常是常数开销;

如:




但B树在经过多次插入与删除后,有可能导致不同的结构:


右边也是一个B树,但它的搜索性能已经是线性的了;同样的关键字集合有可能导致不同的

树结构索引;所以,使用B树还要考虑尽可能让B树保持左图的结构,和避免右图的结构,也就是所谓的“平衡”问题;

实际使用的B树都是在原B树的基础上加上平衡算法,即“平衡二叉树”(binary balanced tree,又称AVL树);如何保持B树结点分布均匀的平衡算法是平衡二叉树的关键;平衡算法是一种在B树中插入和删除结点的策略;

(2)B-tree

是一种多路搜索树(并不是二叉的):

1.定义任意非叶子结点最多只有M个儿子;且M>2;

2.根结点的儿子数为[2,M];

3.除根结点以外的非叶子结点的儿子数为[M/2,M];

4.每个结点存放至少M/2-1(取上整)和至多M-1个关键字;(至少2个关键字)

5.非叶子结点的关键字个数=指向儿子的指针个数-1;

6.非叶子结点的关键字:K[1],K[2],…,K[M-1];且K[i] < K[i+1];

7.非叶子结点的指针:P[1],P[2],P[M];其中P[1]指向关键字小于K[1]的

子树,P[M]指向关键字大于K[M-1]的子树,其它P[i]指向关键字属于(K[i-1],K[i])的子树;

8.所有叶子结点位于同一层;


B-树的搜索,从根结点开始,对结点内的关键字(有序)序列进行二分查找,如果

命中则结束,否则进入查询关键字所属范围的儿子结点;重复,直到所对应的儿子指针为

空,或已经是叶子结点;

B-树的特性:

1.关键字集合分布在整颗树中;

2.任何一个关键字出现且只出现在一个结点中;

3.搜索有可能在非叶子结点结束;

4.其搜索性能等价于在关键字全集内做一次二分查找;

5.自动层次控制;

由于限制了除根结点以外的非叶子结点,至少含有M/2个儿子,确保了结点的至少

利用率,其最底搜索性能为:


其中,M为设定的非叶子结点最多子树个数,N为关键字总数;

所以B-树的性能总是等价于二分查找(与M值无关),也就没有B树平衡的问题;

由于M/2的限制,在插入结点时,如果结点已满,需要将结点分裂为两个各占

M/2的结点;删除结点时,需将两个不足M/2的兄弟结点合并;

(3)B+tree

B+树是B-树的变体,也是一种多路搜索树:

1.其定义基本与B-树同,除了:

2.非叶子结点的子树指针与关键字个数相同;

3.非叶子结点的子树指针P[i],指向关键字值属于[K[i],K[i+1])的子树

(B-树是开区间);

5.为所有叶子结点增加一个链指针;

6.所有关键字都在叶子结点出现;

如:(M=3)

B+的搜索与B-树也基本相同,区别是B+树只有达到叶子结点才命中(B-树可以在

非叶子结点命中),其性能也等价于在关键字全集做一次二分查找;

B+的特性:

1.所有关键字都出现在叶子结点的链表中(稠密索引),且链表中的关键字恰好

是有序的;

2.不可能在非叶子结点命中;

3.非叶子结点相当于是叶子结点的索引(稀疏索引),叶子结点相当于是存储

(关键字)数据的数据层;

4.更适合文件索引系统;

进入主题

由于操作系统内存按照分页机制管理,大一点数据库文件不可能全部存放在内存中,只能用一部风从硬盘中调取一部分放到内存中。所以数据库的存储和索引也是分页的,即paper。

sqlite中,每一个表(含多字段)都用一个唯一的B-tree存储,数据库有多个表就有多个B-tree。前面说到sqlite数据库分页存储的,对,sqlite把一个paper当做B-tree的一个结点(包含根结点、中间结点和叶子结点),中间结点和叶子结点在B-tree中不作区分,一个表的根结点最特殊:根结点是一张表的第一个paper分页,其前100 Byte包含了用以说明库版本、模式版本、页大小、编码方式和是否启用自动清理等信息的头文件(该头文件在btree.c中定义)。

《The Definitive Guide to sqlite》中提到,B-tree中的paper(即B-tree结点)由一系列的b-treepayload(有效载荷)组成。怎么理解这个b-tree payload呢,我的理解是:一个paper中包含至少M/2-1(取上整)和至多M-1个关键字(至少2个关键字),B-tree在建立时首先对关键字排序,具体规则是在新建表时约束的,每一个关键字(即ROWID或主键)都用一个B-tree来存储关键字相同的数据。也就是说,这里的b-tree payload 也是b-tree,只不过它的键值域是相同的,而数值域是可以存放任意格式的数据,在sqlite中有一种针对所有存储格式数据排序的算法(中文版《The Definitive Guide to sqlite》116页),这样b-treepayload的数值域也可按照一定算法构成b-tree。

综上,每一个paper多个关键字就对应多个b-tree payload;paper大小事固定的,而b-tree payload是受数据域大小决定的,所以会有页面溢出的问题出现。针对这种情况,B-tree会根据需要创建一到多个溢出页。

可以理解sqlite B-tree机制了吧,(*^__^*) 嘻嘻……

对于B+tree,简单一些:

sqlite是根据关键值建立索引表的,在创建时会按照一定顺序排序。B+tree的根结点、中间结点和叶子结点也和B-tree一样,对应一个paper,只不过根结点和中间结点的键值域已经排好序,而且数值域不再存储数据啦,而是存储指向下一层paper的指针。这样就会出现这种情况:较早出现的关键字会按照指针的指向一直到达叶子结点,叶子结点的关键字也是排好序的。最后,所有数据都保存在叶子结点的数据域。叶子结点的数据域中的数据由VDBE控制,采用一种特殊的格式记录数据:

VDBE

逻辑头段 数据段

hsize

T1

T2

T3

TN

D1

D2

D3

DN

hsize: 记录逻辑头段大小,一般为64 bit的整数倍的整数

T1、T2...:描述对应D1、D2...的存储类型和长度(类型+长度可以确定D1、D2...的内容啦),一般为64bit整数倍大小的数组。

注意:书上画的图显示,叶子结点的每一个关键字就对应一个VDBE,有一点疑问:怎么处理类似页溢出的问题呢?

原文链接:https://www.f2er.com/sqlite/200855.html

猜你在找的Sqlite相关文章