|
|
|
|
公众号矩阵

阿里面试官:我们为什么常用B+树来做索引?

面试中经常被问到索引相关的问题,其实索引这个概念非常好理解,我们在上学的时候都肯定用过字典吧。

作者:码上Java来源:码上Java|2021-07-04 15:16

本文转载自微信公众号「码上Java」,作者码上Java。转载本文请联系码上Java公众号。  

前言

面试中经常被问到索引相关的问题,其实索引这个概念非常好理解,我们在上学的时候都肯定用过字典吧。索引就像字典的那个目录,我们可以借助目录快速检索到我们所需要的字的解释。同样的道理,在数据库中,索引也可以帮助我们快速检索到我们所需要的数据,而且查询的效率非常高。

总的来说,索引就是一种数据结构,我们今天一起来探究一下索引到底什么什么样的?为什么我们常用B+树最为索引的数据结构呢?

为什么有了索引查询就会变快?

我们都知道数据库存储有两种存储介质,一个是内存,另一个是硬盘。内存是一种临时性存储介质,而且容量也非常有限,如果服务器断电的话,会导致数据丢失。硬盘是一种永久性存储介质(如果不损坏的话),所以说我们需要把数据存放在硬盘里面才安全。

但是有个问题?如果我们把数据放在硬盘里面的话,我们对其中数据进行查询的时候,就会产生硬盘的I/O操作。相比于内存存取来说的话,硬盘在存取时I/O消耗的时间要高很多。而索引的作用就是尽量减少硬盘的I/O操作,从而降低花费的时间。你可以对比查字典的操作,目录(索引)可以帮你减少翻页的动作,一个道理。

先聊聊二叉树

二叉树,顾名思义,每个节点最多有两个“叉”,也就是两个子节点,分别是左子节点和右子节点。不过,二叉树并不要求每个节点都有两个子节点,有的节点只有左子节点,有的节点只有右子节点。

我们先来看下一个最基础的二叉搜索树(Binary Search Tree),搜索某个节点和插入节点的规则一样,我们假设搜索插入的数值为 key:

  • 如果 key 大于根节点,则在右子树中进行查找;
  • 如果 key 小于根节点,则在左子树中进行查找;
  • 如果 key 等于根节点,也就是找到了这个节点,返回根节点即可。

我们举个例子,创建数列{30,25,36,32,40,20,28},同样的数据,不同的插入顺序,树的结果是不一样的,如下图所示:

但是存在极端的情况,当二叉树的深度非常大可能会退化成链表。上图中能看出来第一个树的深度是 3,也就是说最多只需 3 次比较,就可以找到节点,而第二个树的深度是 7,最多需要 7 次比较才能找到节点。

图中的右边也属于二分查找树,但是性能方面已经退化成了链表,查找数据的时间复杂度变成了 O(n)。这个问题怎么解决呢?,人们提出了平衡二叉搜索树(AVL 树),它在二分搜索树的基础上增加了约束,保证每个节点的左子树和右子树的高度差不能超过 1,也就是说节点的左子树和右子树仍然为平衡二叉树。

这里说一下,常见的平衡二叉树有很多种,包括了平衡二叉搜索树、红黑树、数堆、伸展树。平衡二叉搜索树是最早提出来的自平衡二叉搜索树,当我们提到平衡二叉树时一般指的就是平衡二叉搜索树。事实上,第一棵树就属于平衡二叉搜索树,搜索时间复杂度就是 O(log2n)。

上文中我们提到过查询时间的多少主要取决于硬盘的I/O操作,如果我们采用二叉树的形式,即使通过平衡二叉搜索树进行了改良,树的深度也是 O(log2n),当 n 比较大时,深度也是比较高的,比如下图的情况:

每访问一次节点就需要进行一次磁盘 I/O 操作,对于上面的树来说,我们需要进行 5 次 I/O 操作。虽然平衡二叉树比较的效率高,但是树的深度也同样高,这就意味着磁盘 I/O 操作次数多,会影响整体数据查询的效率。

再看看什么是 B 树

在上文中,我们知道了如果二叉树作为索引会导致树变的很高,增加硬盘的 I/O 次数,影响数据查询的时间。B 树的出现就是为了解决这个问题,B 树的英文是 Balance Tree,也就是平衡的多路搜索树,它的高度远小于平衡二叉树的高度。在文件系统和数据库系统中的索引结构经常采用 B 树来实现。

我们来看看B树结构示意图,如下图所示:

B 树作为平衡的多路搜索树,它的每一个节点最多可以包括 M 个子节点,M 称为 B 树的阶。在图中你可以看到,每个磁盘块中包括了关键字和子节点的指针。如果一个磁盘块中包括了 x 个关键字,那么指针数就是 x+1。对于一个 100 阶的 B 树来说,如果有 3 层的话最多可以存储约 100 万的索引数据。对于大量的索引数据来说,采用 B 树的结构是非常适合的,因为树的高度要远小于二叉树的高度。

结合B树结构示意图,我们来一起看看B树是如何进行搜索的,假设我们想要查找的关键字是 9,那么步骤可以分为以下几步:

  • 我们与根节点的关键字 (17,35)进行比较,9 小于 17 那么得到指针 P1;
  • 按照指针 P1 找到磁盘块 2,关键字为(8,12),因为 9 在 8 和 12 之间,所以我们得到指针 P2;
  • 按照指针 P2 找到磁盘块 6,关键字为(9,10),然后我们找到了关键字 9。

你能看出来在 B 树的搜索过程中,我们比较的次数并不少,但如果把数据读取出来然后在内存中进行比较,这个时间就是可以忽略不计的。而读取磁盘块本身需要进行 I/O 操作,消耗的时间比在内存中进行比较所需要的时间要多,是数据查找用时的重要因素,B 树相比于平衡二叉树来说磁盘 I/O 操作要少,在数据查询中比平衡二叉树效率要高。

B树Plus(B+ 树)

  1. B+ 树是基于B 树改良过来的,目前主流的数据库都支持B+ 树作为索引方式,我们以MySQL为例,对比一下B+ 树和B树有哪些区别:
  2. B+ 树中,有 k 个孩子的节点就有 k 个关键字。也就是孩子数量 = 关键字数,而 B 树中,孩子数量 = 关键字数 +1。
  3. 非叶子节点的关键字也会同时存在在子节点中,并且是在子节点中所有关键字的最大(或最小)。
  4. B+ 树中,非叶子节点仅用于索引,不保存数据记录,跟记录有关的信息都放在叶子节点中。而 B 树中,非叶子节点既保存索引,也保存数据记录。

所有关键字都在叶子节点出现,叶子节点构成一个有序链表,而且叶子节点本身按照关键字的大小从小到大顺序链接。

下图就是一棵 B+ 树,阶数为 3,根节点中的关键字 1、18、35 分别是子节点(1,8,14),(18,24,31)和(35,41,53)中的最小值。每一层父节点的关键字都会出现在下一层的子节点的关键字中,因此在叶子节点中包括了所有的关键字信息,并且每一个叶子节点都有一个指向下一个节点的指针,这样就形成了一个链表。

比如,我们想要查找关键字 16,B+ 树会自顶向下逐层进行查找:

  1. 与根节点的关键字 (1,18,35) 进行比较,16 在 1 和 18 之间,得到指针 P1(指向磁盘块 2)
  2. 找到磁盘块 2,关键字为(1,8,14),因为 16 大于 14,所以得到指针 P3(指向磁盘块 7)
  3. 找到磁盘块 7,关键字为(14,16,17),然后我们找到了关键字 16,所以可以找到关键字 16 所对应的数据。

整个过程一共进行了 3 次 I/O 操作,看起来 B+ 树和 B 树的查询过程差不多,但是 B+ 树和 B 树有个根本的差异在于,B+ 树的中间节点并不直接存储数据。这样的好处都有什么呢?

首先,B+ 树查询效率更稳定。因为 B+ 树每次只有访问到叶子节点才能找到对应的数据,而在 B 树中,非叶子节点也会存储数据,这样就会造成查询效率不稳定的情况,有时候访问到了非叶子节点就可以找到关键字,而有时需要访问到叶子节点才能找到关键字。

其次,B+ 树的查询效率更高,这是因为通常 B+ 树比 B 树更矮胖(阶数更大,深度更低),查询所需要的磁盘 I/O 也会更少。同样的磁盘页大小,B+ 树可以存储更多的节点关键字。

不仅是对单个关键字的查询上,在查询范围上,B+ 树的效率也比 B 树高。这是因为所有关键字都出现在 B+ 树的叶子节点中,并通过有序链表进行了链接。而在 B 树中则需要通过中序遍历才能完成查询范围的查找,效率要低很多。

总结

磁盘的 I/O 操作次数对索引的使用效率至关重要。虽然传统的二叉树数据结构查找数据的效率高,但很容易增加磁盘 I/O 操作的次数,影响索引使用的效率。因此在构造索引的时候,我们更倾向于采用“矮胖”的数据结构。

B 树和 B+ 树都可以作为索引的数据结构,在 MySQL 中采用的是 B+ 树,B+ 树在查询性能上更稳定,在磁盘页大小相同的情况下,树的构造更加矮胖,所需要进行的磁盘 I/O 次数更少,更适合进行关键字的范围查询。

【编辑推荐】

  1. 鸿蒙官方战略合作共建——HarmonyOS技术社区
  2. 售前工程师的职业生态索引
  3. 创建索引,六个小细节必须了解
  4. Solr企业级搜索引擎入门与提升含项目案例
  5. 手把手教你使用Flask搭建ES搜索引擎(预备篇)
  6. 同事问我,SQL 语句明明命中了索引,为什么执行很慢?
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

带你轻松入门 RabbitMQ

带你轻松入门 RabbitMQ

轻松入门RabbitMQ
共4章 | loong576

20人订阅学习

数据湖与数据仓库的分析实践攻略

数据湖与数据仓库的分析实践攻略

助力现代化数据管理:数据湖与数据仓库的分析实践攻略
共3章 | 创世达人

11人订阅学习

云原生架构实践

云原生架构实践

新技术引领移动互联网进入急速赛道
共3章 | KaliArch

40人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微