B樹的進化版----B+樹

C++爲何叫C plus plus?
這是因爲C++至關於繼承C的語法後,增長了各方面的能力,所擴展出的一種新語法。
在軟件領域中 plus 有增長的味道。在這裏B +樹也同樣,是B樹的加強版。
在學習B+樹以前,最好是對B樹有必定的瞭解。不瞭解的各位也沒有關係,能夠花費5分鐘的時間讀個人上一篇文章《數據庫索引的基石----B樹》。
我在上篇文章的最後,專門提到,因爲B樹的設計,致使它存在一種自然的劣勢,致使典型的B樹在不少方面受到了限制。
      這個劣勢是什麼呢?(自問)
      先想下,爲啥咱們在類磁盤的數據查找系統中,並無使用高效的平衡二叉查找樹,而設計出了B樹?這是因爲B樹是考慮到了加載硬盤數據到內存是系統瓶頸,因此讓節點變重,承載更多的關鍵字。可是B樹在設計時,爲了查找方便,節點信息除了包含關鍵字,還包含了data信息,這就致使每一個節點所能包含的最大關鍵字個數被壓縮了。(防盜鏈接:本文首發自http://www.cnblogs.com/jilodream/ )這就致使最終並無達到每次次加載,加載的關鍵字是最大數目的最優方案。(自答)
基於這個緣由,有人對B樹進行了改良,提出了B+樹(B plus tree)。
也就是下邊這個樣子html


根據B+樹的圖,咱們能夠輕易總結出如下幾個不一樣點:
一、 在B+樹中,若是一個節點包含n個關鍵字,那麼他就有n個分支。
在B樹中,含有n個關鍵字的節點有n+1個分支。
也就是說B+樹是一個關鍵字對應一個分支,B樹是一個關鍵字的空位置對應一個分支。
二、 B+樹中節點的關鍵字個數範圍比對應的B樹多1。
三、 B+樹的葉子節點包含所有關鍵字,葉子節點的指針指向關鍵字對應的數據。
四、 B+樹的全部非葉子節點僅僅起到一個索引的做用,即節點中的每一個索引項只含有對應子樹的最大關鍵字和指向該子樹的指針。不含有該關鍵字的所對應的數據。
在B樹中,每一個節點還會額外記錄關鍵字所對應的數據。
五、 B+樹中存在一個額外的指針,這個指針指向於包含最小關鍵字的節點。而後全部的葉子節點從小到大的串聯起來,造成一個線性的鏈表。
最主要的不一樣點是四、5兩點,這裏着重解釋下第4點:
父節點中關鍵字的位置是其子節點中全部的關鍵字中的最大值。
如圖中62是子節點(56,62)的最大值96是子節點(62,78,96)的最大值。
96存在於三個節點中,可是它對應的數據只存儲在葉子節點中。
而B樹若是是相同數據的話,96只會存在一個節點中,而這個節點直接就包含了96對應的數據。
正是因爲第4點致使了B+樹的查找,系統每次能夠從磁盤中加載的數據量更大,調用的IO耗時更少。
而因爲第5點的存在,致使B+樹在範圍查找等方面有了極大的優點。
下邊結合上邊的B+樹,咱們來舉幾個例子:
(1) 查找15
首先加載根節點(50,96),依次比較,發現15≤ 50,匹配成功。
加載50對應的子節點(15,50)。依次比較,發現15=15,匹配成功。
加載15對應的子節點(3,8,15)。依次比較,發現15=15,匹配成功。
因爲(3,8,15)是葉子節點,因此能夠直接取出對應數據。mysql

(2)查找14
前邊都相同,直至加載葉子節點(3,8,15)。
依次比較3,8,不匹配,比較15,發現14<15,而且當前節點是葉子節點,因此匹配失敗,B+樹不包含14關鍵字。面試

(3)查找知足14≤x≤57條件的全部x
同(2)場景,發現14不存在,15是知足條件的最小值,存儲15。
加載下一個葉子節點(20,26,27,50),依次比較發現都知足,所有存儲。
加載下一個葉子節點(56,62),依次比較發現56知足條件,62超出範圍,存儲56。
最終得出知足條件的全部數據是{15,20,26,27,50,56}。sql

       因爲B+樹的種種優點,使得其被普遍應用於各類文件查找系統中,如mysql、MongoDB。在mysql中,你在創建索引所選取的B樹,其底層的實現正是B+樹。另外值得注意的是,在MongoDB的官方文檔中描述,其索引使用B樹,因而不少文章甚至面試官就想固然的提問,爲何MongoDB沒使用B+樹,而是使用的B樹。其實做者曾經就已做出澄清,底層的實現使用的是B+樹。(防盜鏈接:本文首發自http://www.cnblogs.com/jilodream/ )而文檔寫爲B樹,咱們能夠理解爲B+樹是B樹的一個加強版。(此處可參考https://q.cnblogs.com/q/127244/)因此當有人問你,爲何mysql使用B+樹,而MongoDB使用B樹時,你能夠給他一個驚喜。數據庫

相關文章
相關標籤/搜索