Mysql InnoDB B+树索引和哈希索引的区别?MongoDB 为什么使用B-树?

2018/04/04 MySQL

B-树和B+树最重要的一个区别就是B+树只有叶节点存放数据,其余节点用来索引,而B-树是每个索引节点都会有Data域。

B+树

B+树是为磁盘及其他存储辅助设备而设计一种平衡查找树(不是二叉树)。B+树中,所有记录的节点按大小顺序存放在同一层的叶节点中,各叶节点用指针进行连接。

数据库中B+树索引分为聚集索引(clustered index)和非聚集索引(secondary index).这两种索引的共同点是内部都是B+树,高度都是平衡的,叶节点存放着所有数据。不同点是叶节点是否存放着一整行数据。

B+树有如下特点:

  • B+树每个节点可以包含更多的节点,这样做有两个原因,一个是降低树的高度。另外一个是将数据范围变为多个区间,区间越多,数据检索越快。
  • 每个节点不再只是存储一个key了,可以存储多个key。
  • 非叶子节点存储key,叶子节点存储key和数据。
  • 叶子节点两两指针相互链接,顺序查询性能更高。

通俗的讲

  • B+树的非叶子节点只是存储key,占用空间非常小,因此每一层的节点能索引到的数据范围更加的广。换句话说,每次IO操作可以搜索更多的数据。
  • 叶子节点两两相连,符合磁盘的预读特性。比如叶子节点存储50和55,它有个指针指向了60和62这个叶子节点,那么当我们从磁盘读取50和55对应的数据的时候,由于磁盘的预读特性,会顺便把60和62对应的数据读取出来。这个时候属于顺序读取,而不是磁盘寻道了,加快了速度。
  • 支持范围查询,而且部分范围查询非常高效,每个节点能索引的范围更大更精确,也意味着 B+树单次磁盘IO的信息量大于B-树,I/O效率更高。

原因是数据都是存储在叶子节点这一层,并且有指针指向其他叶子节点,这样范围查询只需要遍历叶子节点这一层,无需整棵树遍历。

局部性原理与磁盘预读

由于磁盘的存取速度与内存之间鸿沟,为了提高效率,要尽量减少磁盘I/O.磁盘往往不是严格按需读取,而是每次都会预读,磁盘读取完需要的数据,会顺序向后读一定长度的数据放入内存。而这样做的理论依据是计算机科学中著名的局部性原理:

当一个数据被用到时,其附近的数据也通常会马上被使用,程序运行期间所需要的数据通常比较集中

B-树

B-树,这里的 B 表示 balance( 平衡的意思),B-树是一种多路自平衡的搜索树 它类似普通的平衡二叉树,不同的一点是B-树允许每个节点有更多的子节点。

B-树有如下特点

  • 所有键值分布在整颗树中。
  • 任何一个关键字出现且只出现在一个结点中。
  • 搜索有可能在非叶子结点结束。
  • 在关键字全集内做一次查找,性能逼近二分查找。

B-树和B+树的区别

  • B+树内节点不存储数据,所有数据存储在叶节点导致查询时间复杂度固定为 log n。
  • B-树查询时间复杂度不固定,与 key 在树中的位置有关,最好为O(1)。
  • B+树叶节点两两相连可大大增加区间访问性,可使用在范围查询等。
  • B-树每个节点 key 和 data 在一起,则无法区间查找。
  • B+树更适合外部存储(存储磁盘数据)。由于内节点无 data 域,每个节点能索引的范围更大更精确。

MongoDB 为什么使用B-树?

B+树内节点不存储数据,所有 data 存储在叶节点导致查询时间复杂度固定为 log n。而B-树查询时间复杂度不固定,与 key 在树中的位置有关,最好为O(1)

我们说过,尽可能少的磁盘 IO 是提高性能的有效手段。MongoDB 是聚合型数据库,而 B-树恰好 key 和 data 域聚合在一起

至于MongoDB为什么使用B-树而不是B+树,可以从它的设计角度来考虑,它并不是传统的关系性数据库,而是以Json格式作为存储的nosql,目的就是高性能,高可用,易扩展。首先它摆脱了关系模型,上面所述的优点2需求就没那么强烈了,其次Mysql由于使用B+树,数据都在叶节点上,每次查询都需要访问到叶节点,而MongoDB使用B-树,所有节点都有Data域,只要找到指定索引就可以进行访问,无疑单次查询平均快于Mysql

哈希索引

简单地说,哈希索引就是采用一定的哈希算法,把键值换算成新的哈希值,检索时不需要类似B+树那样从根节点到叶子节点逐级查找,只需一次哈希算法即可立刻定位到相应的位置,速度非常快。

B+树索引和哈希索引的区别

  • 如果是等值查询,那么哈希索引明显有绝对优势,因为只需要经过一次算法即可找到相应的键值;当然了,这个前提是,键值都是唯一的。如果键值不是唯一的,就需要先找到该键所在位置,然后再根据链表往后扫描,直到找到相应的数据。
  • 如果是范围查询检索,这时候哈希索引就毫无用武之地了,因为原先是有序的键值,经过哈希算法后,有可能变成不连续的了,就没办法再利用索引完成范围查询检索。
  • 同理,哈希索引也没办法利用索引完成排序,以及like ‘xxx%’ 这样的部分模糊查询(这种部分模糊查询,其实本质上也是范围查询)。
  • 哈希索引也不支持多列联合索引的最左匹配规则
  • B+树索引的关键字检索效率比较平均,不像B树那样波动幅度大,在有大量重复键值情况下,哈希索引的效率也是极低的,因为存在所谓的哈希碰撞问题
  • 解决Hash碰撞冲突方法总结 https://blog.csdn.net/zeb_perfect/article/details/52574915

备注:以上内容均摘抄自网络,并非原创,仅供个人学习交流使用,望各路大牛,发现不对的地方,不吝赐教,留言即可

参考

  • https://blog.csdn.net/wwh578867817/article/details/50493940
  • https://segmentfault.com/a/1190000004690721
  • http://www.cnblogs.com/heiming/p/5865101.html

推荐阅读

关注微信公众号福利

关注微信公众号「搜云库」获取最新文章

福利】公众号后台回复 “进群
福利】邀请您进微信 “技术分享群
福利】群里有很多技术大佬,免费提问,互相学习 关注公众号-搜云库

Show Disqus Comments

Search

    Table of Contents