lightning mdb 源代碼分析系列(3)

     本系列前兩章已經描述了系統架構以及系統構建的基礎內存映射,本章將詳細描述lmdb的核心,外存B+Tree的操作。本文將從基本原理、內存操作方式、外存操作方式以及LMDB中的相關函數等幾方面描述LMDB中關於B+Tree的使用方式。

     介紹

      動態查找樹主要有:二叉查找樹(Binary Search Tree),平衡二叉查找樹(Balanced Binary Search Tree),紅黑樹 (Red-Black Tree ),B-tree/B+-tree/ B*-tree (B~Tree)。前三者是典型的二叉查找樹結構,其查找的時間複雜度O(log2N)與樹的深度相關,那麼降低樹的深度自然對查找效率是有所提高的;在大規模數據存儲前提下,比如有100萬key需要進行比較,二叉樹進行查詢時,需要訪問的磁盤IO次數將有20次,以現有的磁盤隨機訪問性能,對於大型應用程序這是不可接受的性能,基礎的想法就是講多個key或者二叉樹的子樹存放在一起,以頁面爲單位進行訪問,比如組織成下圖形式,100萬key比較時io訪問次數只有兩次,通過進一步的優化,B-Tree應運而生。

B-Tree系列可以認爲是多路平衡查找樹,能有效降低樹的層次以及支持外存數據組織。

     定義

B-tree又叫平衡多路查找樹。一棵m階的B-tree (m叉樹)的特性如下:

(其中ceil(x)是一個取上限的函數)

1)  樹中每個結點至多有m個孩子;

2)  除根結點和葉子結點外,其它每個結點至少有有ceil(m / 2)個孩子;

3)  若根結點不是葉子結點,則至少有2個孩子(特殊情況:沒有孩子的根結點,即根結點爲葉子結點,整棵樹只有一個根節點);

4)  所有葉子結點都出現在同一層,葉子結點不包含任何關鍵字信息(可以看做是外部結點或查詢失敗的結點,實際上這些結點不存在,指向這些結點的指針都爲null);

5)  每個非終端結點中包含有n個關鍵字信息: (n,P0,K1,P1,K2,P2,......,Kn,Pn)。其中:

a)   Ki (i=1...n)爲關鍵字,且關鍵字按順序排序K(i-1)< Ki。

b)   Pi爲指向子樹根的接點,且指針P(i-1)指向子樹種所有結點的關鍵字均小於Ki,但都大於K(i-1)。

c)   關鍵字的個數n必須滿足: ceil(m / 2)-1 <= n <= m-1。

B-tree中的每個結點根據實際情況可以包含大量的關鍵字信息和分支(當然是不能超過磁盤塊的大小,根據磁盤驅動(disk drives)的不同,一般塊的大小在1k~4k左右);這樣樹的深度降低了,這就意味着查找一個元素只要很少結點從外存磁盤中讀入內存,很快訪問到要查找的數據。

爲了簡單,這裏用少量數據構造一棵3叉樹的形式。上面的圖中比如根結點,其中17表示一個磁盤文件的文件名;小紅方塊表示這個17文件的內容在硬盤中的存儲位置;p1表示指向17左子樹的指針。

其結構可以簡單定義爲:

typedef struct {

/*文件數*/

int  file_num;

/*文件名(key)*/

char * file_name[max_file_num];

/*指向子節點的指針*/

     BTNode * BTptr[max_file_num+1];

/*文件在硬盤中的存儲位置*/

     FILE_HARD_ADDR offset[max_file_num];

}BTNode;

假如每個盤塊可以正好存放一個B-tree的結點(正好存放2個文件名)。那麼一個BTNode結點就代表一個盤塊,而子樹指針就是存放另外一個盤塊的地址。

模擬查找文件29的過程:

(1) 根據根結點指針找到文件目錄的根磁盤塊1,將其中的信息導入內存。【磁盤IO操作1次】

(2) 此時內存中有兩個文件名17,35和三個存儲其他磁盤頁面地址的數據。根據算法我們發現17<29<35,因此我們找到指針p2。

(3) 根據p2指針,我們定位到磁盤塊3,並將其中的信息導入內存。【磁盤IO操作2次】

(4) 此時內存中有兩個文件名26,30和三個存儲其他磁盤頁面地址的數據。根據算法我們發現26<29<30,因此我們找到指針p2。

(5) 根據p2指針,我們定位到磁盤塊8,並將其中的信息導入內存。【磁盤IO操作3次】

(6) 此時內存中有兩個文件名28,29。根據算法我們查找到文件29,並定位了該文件內存的磁盤地址。

分析上面的過程,發現需要3次磁盤IO操作和3次內存查找操作。關於內存中的文件名查找,由於是一個有序表結構,可以利用折半查找提高效率。至於3次磁盤IO操作時影響整個B-tree查找效率的決定因素。

當然,如果我們使用平衡二叉樹的磁盤存儲結構來進行查找,磁盤IO操作最少4次,最多5次。而且文件越多,B-tree比平衡二叉樹所用的磁盤IO操作次數將越少,效率也越高。

上面僅僅介紹了對於B-tree這種結構的查找過程,還有樹節點的插入與刪除過程,以及相關的算法和代碼的實現,將在以後的深入學習中給出相應的實例。

上面簡單介紹了利用B-tree這種結構如何訪問外存磁盤中的數據的情況,下面咱們通過另外一個實例來對這棵B-tree的插入(insert),刪除(delete)基本操作進行詳細的介紹:

下面以一棵5階B-tree實例進行講解(如下圖所示):

其滿足上述條件:除根結點和葉子結點外,其它每個結點至少有ceil(5/2)=3個孩子(至少2個關鍵字);當然最多5個孩子(最多4個關鍵字)。下圖中關鍵字爲大寫字母,順序爲字母升序。

結點定義如下:

typedef struct{

int Count;         // 當前節點中關鍵元素數目

   ItemType Key[4];   // 存儲關鍵字元素的數組

long Branch[5];    // 僞指針數組,(記錄數目)方便判斷合併和分裂的情況

} NodeType;

插入(insert)操作:插入一個元素時,首先在B-tree中是否存在,如果不存在,即在葉子結點處結束,然後在葉子結點中插入該新的元素,注意:如果葉子結點空間足夠,這裏需要向右移動該葉子結點中大於新插入關鍵字的元素,如果空間滿了以致沒有足夠的空間去添加新的元素,則將該結點進行“分裂”,將一半數量的關鍵字元素分裂到新的其相鄰右結點中,中間關鍵字元素上移到父結點中(當然,如果父結點空間滿了,也同樣需要“分裂”操作),而且當結點中關鍵元素向右移動了,相關的指針也需要向右移。如果在根結點插入新元素,空間滿了,則進行分裂操作,這樣原來的 根結點中的中間關鍵字元素向上移動到新的根結點中,因此導致樹的高度增加一層。

咱們通過一個實例來逐步講解下。插入以下字符字母到空的5階B-tree中:C N G A H E K Q M F W L T Z D P R X Y S,5序意味着一個結點最多有5個孩子和4個關鍵字,除根結點外其他結點至少有2個關鍵字,首先,結點空間足夠,4個字母插入相同的結點中,如下圖:

當咱們試着插入H時,結點發現空間不夠,以致將其分裂成2個結點,移動中間元素G上移到新的根結點中,在實現過程中,咱們把A和C留在當前結點中,而H和N放置新的其右鄰居結點中。如下圖:

當咱們插入E,K,Q時,不需要任何分裂操作

插入M需要一次分裂,注意M恰好是中間關鍵字元素,以致向上移到父節點中

插入F,W,L,T不需要任何分裂操作

插入Z時,最右的葉子結點空間滿了,需要進行分裂操作,中間元素T上移到父節點中,注意通過上移中間元素,樹最終還是保持平衡,分裂結果的結點存在2個關鍵字元素。

插入D時,導致最左邊的葉子結點被分裂,D恰好也是中間元素,上移到父節點中,然後字母P,R,X,Y陸續插入不需要任何分裂操作。

最後,當插入S時,含有N,P,Q,R的結點需要分裂,把中間元素Q上移到父節點中,但是情況來了,父節點中空間已經滿了,所以也要進行分裂,將父節點中的中間元素M上移到新形成的根結點中,注意以前在父節點中的第三個指針在修改後包括D和G節點中。這樣具體插入操作的完成,下面介紹刪除操作,刪除操作相對於插入操作要考慮的情況多點。

刪除(delete)操作:首先查找B-tree中需刪除的元素,如果該元素在B-tree中存在,則將該元素在其結點中進行刪除,如果刪除該元素後,首先判斷該元素是否有左右孩子結點,如果有,則上移孩子結點中的某相近元素到父節點中,然後是移動之後的情況;如果沒有,直接刪除後,移動之後的情況.。

刪除元素,移動相應元素之後,如果某結點中元素數目小於ceil(m/2)-1,則需要看其某相鄰兄弟結點是否豐滿(結點中元素個數大於ceil(m/2)-1),如果豐滿,則向父節點借一個元素來滿足條件;如果其相鄰兄弟都剛脫貧,即借了之後其結點數目小於ceil(m/2)-1,則該結點與其相鄰的某一兄弟結點進行“合併”成一個結點,以此來滿足條件。那咱們通過下面實例來詳細瞭解吧。

以上述插入操作構造的一棵5階B-tree爲例,依次刪除H,T,R,E。

首先刪除元素H,當然首先查找H,H在一個葉子結點中,且該葉子結點元素數目3大於最小元素數目ceil(m/2)-1=2,則操作很簡單,咱們只需要移動K至原來H的位置,移動L至K的位置(也就是結點中刪除元素後面的元素向前移動)

下一步,刪除T,因爲T沒有在葉子結點中,而是在中間結點中找到,咱們發現他的繼承者W(字母升序的下個元素),將W上移到T的位置,然後將原包含W的孩子結點中的W進行刪除,這裏恰好刪除W後,該孩子結點中元素個數大於2,無需進行合併操作。

下一步刪除R,R在葉子結點中,但是該結點中元素數目爲2,刪除導致只有1個元素,已經小於最小元素數目ceil(5/2)-1=2,如果其某個相鄰兄弟結點中比較豐滿(元素個數大於ceil(5/2)-1=2),則可以向父結點借一個元素,然後將最豐滿的相鄰兄弟結點中上移最後或最前一個元素到父節點中,在這個實例中,右相鄰兄弟結點中比較豐滿(3個元素大於2),所以先向父節點借一個元素W下移到該葉子結點中,代替原來S的位置,S前移;然後X在相鄰右兄弟結點中上移到父結點中,最後在相鄰右兄弟結點中刪除X,後面元素前移。

最後一步刪除E,刪除後會導致很多問題,因爲E所在的結點數目剛好達標,剛好滿足最小元素個數(ceil(5/2)-1=2),而相鄰的兄弟結點也是同樣的情況,刪除一個元素都不能滿足條件,所以需要該節點與某相鄰兄弟結點進行合併操作;首先移動父結點中的元素(該元素在兩個需要合併的兩個結點元素之間)下移到其子結點中,然後將這兩個結點進行合併成一個結點。所以在該實例中,咱們首先將父節點中的元素D下移到已經刪除E而只有F的結點中,然後將含有D和F的結點和含有A,C的相鄰兄弟結點進行合併成一個結點。

也許你認爲這樣刪除操作已經結束了,其實不然,在看看上圖,對於這種特殊情況,你立即會發現父節點只包含一個元素G,沒達標,這是不能夠接受的。如果這個問題結點的相鄰兄弟比較豐滿,則可以向父結點借一個元素。假設這時右兄弟結點(含有Q,X)有一個以上的元素(Q右邊還有元素),然後咱們將M下移到元素很少的子結點中,將Q上移到M的位置,這時,Q的左子樹將變成M的右子樹,也就是含有N,P結點被依附在M的右指針上。所以在這個實例中,咱們沒有辦法去借一個元素,只能與兄弟結點進行合併成一個結點,而根結點中的唯一元素M下移到子結點,這樣,樹的高度減少一層。

爲了進一步詳細討論刪除的情況。再舉另外一個實例:

這裏是一棵不同的5階B-tree,那咱們試着刪除C

於是將刪除元素C的右子結點中的D元素上移到C的位置,但是出現上移元素後,只有一個元素的結點的情況。

又因爲含有E的結點,其相鄰兄弟結點纔剛脫貧(最少元素個數爲2),不可能向父節點借元素,所以只能進行合併操作,於是這裏將含有A,B的左兄弟結點和含有E的結點進行合併成一個結點。

這樣又出現只含有一個元素F結點的情況,這時,其相鄰的兄弟結點是豐滿的(元素個數爲3>最小元素個數2),這樣就可以想父結點借元素了,把父結點中的J下移到該結點中,相應的如果結點中J後有元素則前移,然後相鄰兄弟結點中的第一個元素(或者最後一個元素)上移到父節點中,後面的元素(或者前面的元素)前移(或者後移);注意含有K,L的結點以前依附在M的左邊,現在變爲依附在J的右邊。這樣每個結點都滿足B-tree結構性質。

B+-tree:是應文件系統所需而產生的一種B-tree的變形樹。

一棵m階的B+-tree和m階的B-tree的差異在於:       

1.有n棵子樹的結點中含有n個關鍵字; (B-tree是n棵子樹有n-1個關鍵字)

2.所有的葉子結點中包含了全部關鍵字的信息,及指向含有這些關鍵字記錄的指針,且葉子結點本身依關鍵字的大小自小而大的順序鏈接。 (B-tree的葉子節點並沒有包括全部需要查找的信息)

3.所有的非終端結點可以看成是索引部分,結點中僅含有其子樹根結點中最大(或最小)關鍵字。 (B-tree的非終節點也包含需要查找的有效信息)

a)      爲什麼說B+樹比B-tree更適合實際應用中操作系統的文件索引和數據庫索引?

1) B+-tree的磁盤讀寫代價更低

B+-tree的內部結點並沒有指向關鍵字具體信息的指針。因此其內部結點相對B-tree更小。如果把所有同一內部結點的關鍵字存放在同一盤塊中,那麼盤塊所能容納的關鍵字數量也越多。一次性讀入內存中的需要查找的關鍵字也就越多。相對來說IO讀寫次數也就降低了。

舉個例子,假設磁盤中的一個盤塊容納16bytes,而一個關鍵字2bytes,一個關鍵字具體信息指針2bytes。一棵9階B-tree(一個結點最多8個關鍵字)的內部結點需要2個盤快。而B+-tree內部結點只需要1個盤快。當需要把內部結點讀入內存中的時候,B-tree就比B+-tree多一次盤塊查找時間(在磁盤中就是盤片旋轉的時間)。

2) B+-tree的查詢效率更加穩定

由於非終結點並不是最終指向文件內容的結點,而只是葉子結點中關鍵字的索引。所以任何關鍵字的查找必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同,導致每一個數據的查詢效率相當。

   關於B-Tree/B+-Tree的相關代碼可以見後續參考。後續個人也會再發系列博文詳述。

     外存操作

     前面的理論性介紹都是從別的地方摘抄過來的,詳細描述了B-Tree在內存中的操作步驟以及需要考慮的各種情形以保證B-Tree的結構。從前文中描述可知,此種數據結構是很適合進行持久化保存的,其主要原因就是,每次數據的變化(增加、刪除)導致的樹的形狀變化時影響的節點比較小,這樣在存放到外存時,就不需要更改整個B-Tree,只需修改被影響的節點,從而大大減少了IO次數。

      在真正的系統中(數據庫和文件系統),使用B-Tree存儲時,不會使用以上類似方式存儲數據,而是採取頁的方式管理,頁式內存管理已經在操作系統實現中被證明是一種成熟高效的管理方式。在其他應用系統中使用頁管理數據文件,有如下幾大優點:

     1. 批量化IO操作,避免不必要的IO操作

         通過將相鄰的IO操作歸一化到同一個頁面中進行操作,可以避免多次IO,若操作系統比較繁忙,且同一頁面的隨機IO請求次數較多但時間比較分散時,此時效率最低,系統將不得不每次進行尋道。歸一化到以頁面爲單位,則可以避免類似情形。

     2. 能儘量使用操作系統優勢

       操作系統同樣以頁爲單位,若將B-Tree數據管理的頁面大小設置成系統頁面大小,在進行IO操作時、內存操作時,OS將能以最優方式進行存儲、傳輸,從而提升性能。

     3. 讓B-Tree進入實戰階段

       根據前文描述,B-Tree需要預先定義階數,比如5階,7階等,若實際情況採取類似方式定義,則需要預先評估應用需要存儲的數據個數,這對於類似於數據庫系統、文件系統是不可能任務。以頁爲單位,則用近似的方案避免了此問題,在真正數據庫系統中,採取將索引存儲到一個頁面當中,一個頁面相當於一個節點,一個頁面節點滿了再進行數據插入時則進行頁面分裂。這樣既避免了需要預先定義階數,又避免了因不同節點數據大小不一致導致的內存大小不一致問題。爲什麼使用頁面而不定義階數,使用頁面的管理方式能夠保持B-Tree結構和性質呢?

    LMDB使用

    下面講述LMDB中如何實現B-Tree結構的?

     LMDB中代碼主要分爲兩塊以實現B-Tree結構。

     1. page管理

        page管理實現了上述描述的外存操作方式,具體實現的功能包括

  • 新建、分配、釋放頁面(mdb_page_new,mdb_page_alloc ,mdb_page_mallocmdb_page_free )

          mdb_page_malloc:爲新頁面分配內存

          從操作系統中申請1個或者n個頁面,一般爲一個頁面,n個頁面爲overflow頁面,分默認會在分配時將初始化最後一個頁面爲0。

         mdb_page_free:釋放單個頁面,將它放入可重用頁面列表。

        mdb_page_new::新建頁面

         首先調用mdb_page_alloc分配頁面,然後初始化頁面,新建一個頁面時,認爲這個頁面是一個全新的頁面,因此需要其整個空間可用,初始化設置將體現這點。

        mdb_page_alloc: 分配頁面

        分配一個或n個頁面,若分配n個,則n個頁面是連續頁面。若事務中可用髒空間沒有了,則分配失敗,可用髒空間是指存儲髒頁ID的數組大小,配置爲131071。LMDB中所有可用的髒頁同樣被維護成一顆B-Tree,freeDB中記錄了最後一次放入頁面的事務ID,每次分配時都從freedb中尋找足夠大重用空間,一般分配一個頁面能滿足,連續頁面,可能需要嘗試多次,因此多個頁面一般是overflow 頁面,必須是連續頁面才能滿足要求。FreeDB的構建過程以及存儲格式見本系列其他博文。

  • 複製頁面(mdb_page_copy )

         將頁面內容從一個頁面複製到另外一個頁面,此功能主要用於cow

  • 頁面分裂合併(mdb_page_merge ,mdb_page_split )

        頁面的分裂合併是用於B-Tree插入刪除時,爲滿足平衡子節點需要進行的操作。具體應用條件參見本文前面關於插入、刪除的描述。

       頁面分裂:

        mdb_page_split:實現了上述B-Tree的操作過程,考慮了僅有一個節點時、append模式、braches/leaf/leaf2等不同頁面的處理過程,基本流程就是根據一定的算法確定分裂點,根據B-Tree的定義,在分裂時,不一定需要保證平分,只需要保證頁面節點保持半滿即可。分裂點確定之後,就進行數據的移動並插入導致分裂的數據以及修改指針以維持B-Tree結構,同時再決定是否會導致上層分裂以及root分裂,若會則進行遞歸處理。

      頁面合併:

      mdb_page_merge:同樣是實現了上述因爲節點刪除導致的merge過程。基本過程是,將合併的目標頁面置爲髒頁,然後根據上述理論情況進行節點的一個個複製,或者對於內部節點而言進行頁面指針調整以及進行上下節點的移動,對於本頁完成之後進行平衡操作,其中平衡操作可能會又導致merge操作,直到B-Tree重新滿足定義爲止。

  • 髒頁讀出寫入(mdb_page_spill,mdb_page_unspill,mdb_page_dirty,mdb_page_flush,mdb_page_touch )

          mdb_page_spill:將髒頁寫回磁盤,這是爲了嵌套長事務進行的設計,有些嵌套長事務會使用大量的頁,爲了避免耗光內存,可以將髒頁寫回磁盤,寫回磁盤如同commit一樣,因爲多個進程、線程之間將只會存在一個寫事務,因此在未提交之間前寫回磁盤沒有任何問題。而且只要能有空間,頁面就不會刷入磁盤。在執行時,先計算是否空間足夠,不夠的將id存入idl數組,然後刷入磁盤,再根據環境變量決定是否保留p_dirty標記。

       mdb_page_unspill:將spill的頁面重新讀回,這就不需要進行touch,直接設置dirty標誌就可以了。lmdb支持嵌套事務,因此在查找頁面是否屬於已經被spilled的頁面需要查找整個嵌套路徑,從葉子到跟,找到之後確認midl列表(髒空間)是否有足夠空間,沒有的提示事務空間已滿,否則加載頁面並設置髒頁標記。

       mdb_page_dirty:設置髒頁標記,並將髒頁加入到事務中的髒頁列表當中。

       mdb_page_flush:用在事務提交時,當清除頁面髒頁標記後,將數據更新到磁盤(通過寫文件方式).若使用試驗的特徵(mmap寫),則在清除髒頁就完成工作,因爲寫操作交給系統完成,否則需要計算文件起止地址後將頁面一頁頁的寫入磁盤,最後釋放髒頁內存,特殊原因需要留存內存的頁面不參與flush。

       mdb_page_touch: 實現COW的技術,複製一個頁面,並將更新過B-Tree指針關係的頁面插入到B-Tree當中,這樣意味着在修改時是在複製的頁面上進行修改,別的事務在本事務沒有提交之前看到還是以前的數據,提交之後的新事物看到的纔是修改之後的數據。

  • 頁面查找(mdb_page_search_root ,mdb_page_search ,mdb_page_search_lowest)

          mdb_page_search_root:從B-Tree根節點檢索,根據key的值,從根節點開始遍歷子樹獲取每一層對應的page,在page之內檢索key,再根據B-Tree查找方法確定下一層子節點的page,層層遍歷,從而最終確定key的位置或者判斷B-Tree中沒有對應的key。同時將頁面存放到cursor頁堆棧中。這樣cursor將可以重用對應的頁面,爲後續進行更新等操作提供便利。

        mdb_page_search/mdb_page_search_lowest都將調用mdb_page_search_root以完成檢索

        mdb_page_search,除了完成檢索爲的附加工作是確保所使用的B-Tree在本事務可見範圍內是最新版本,同時在需要時將頁面置爲髒頁。

        mdb_page_search_lowest: 從當前分支頁開始,檢索第一個符合條件的值。

  • 頁面獲取(mdb_page_get,mdb_page_list)

       mdb_page_get:獲取頁面,本來根據MMAP原則,讀取對應的頁面非常簡單,計算下地址即可,但lmdb中,考慮到事務可能使用大量的頁面,事務可用空間滿時,將一部分頁面spill/flush到磁盤中,因此需要在get時判斷是否在spill列表中,在的話從中獲取,否則直接計算獲取。

      mdb_page_list:顯示頁面中的所有key,是個工具方法。

      2. cursor操作

        cursor操作實現了B-Tree節點操作,cursor指向當前需要進行操作的B-Tree節點,然後依據提供的操作方式(insert、del)進行數據操作,然後進行一系列複雜的操作流程以維持B-Tree結構。具體實現的功能包括:

  • 遊標遍歷(mdb_cursor_sibling,mdb_cursor_next,mdb_cursor_prev,mdb_cursor_first
    ,mdb_cursor_last )

        mdb_cursor_first: 將遊標定位至B-Tree的最小葉子節點(第一個),而非根據key查詢時得到第一個結果位置。若支持重複數據,還要特殊處理,移動到重複數據第一個。

        mdb_cursor_last:與first類似,只不過定位至最大葉子節點(最後一個)

        mdb_cursor_next: 遊標移動至下一個節點

        mdb_cursor_prev: 遊標移動至前一個節點

        mdb_cursor_sibling:將遊標移動至兄弟節點,可以是前一個頁面或者下一個頁面。

若當前頁有key,則行爲與next、prev類似,否則移動到下一個頁面的對應key位置。

  • 增刪改查(mdb_cursor_get ,mdb_cursor_set ,mdb_cursor_del ,mdb_cursor_del0 ,mdb_cursor_put ,mdb_cursor_count )

          mdb_cursor_get:根據遊標位置和條件獲取值,最常用:MDB_GET_CURRENT,獲取遊標所指節點的值,基本思路是看頁面中索引是否已經大於key個數,大於則說明遊標已經需要指向下一頁,對於取當前值的不重複key來說,這不可能,因此獲取失敗。然後根據是否爲leaf2頁面(key重複),是根據宏取值,否則判斷葉子值是否有副本(完全重複key和值,有的話初始化xcursor並開始取值,否則話直接讀取對應位置的值。

       mdb_cursor_set :將遊標設置(定位)到指定key位置,假如已經在正確頁面,只需要判斷key是否在頁面key的範圍之內,判斷最大、最小值可以確定。然後根據相應標誌,如同get中所說,進行判斷以及讀取或設置某些變量。否則話進行頁面查找先定位key所在頁面(mdb_page_search),然後定位頁面中位置(mdb_node_search),然後再設置相關變量。

      mdb_cursor_count:返回遊標代表的結果數,唯一key返回一,重複key返回重複個數。

      mdb_cursor_put:將key、value對存放到數據庫中,默認是新增加,若key已經存在則是更新,基本流程是:判斷前提cursor、key非空,確認各種標誌是否合法,比如多個value,但是數據庫不支持重複key這種情形就不合法,標誌合適之後,判斷是否爲空樹,非空時將cursor指向正確的位置,比如append模式指向數據庫最大節點之後,正常指向應該插入的位置。然後touch所有頁面使所有頁面可寫。若爲leaf2類型頁面,說明key、value完全重複,增加key就OK了,然後再判斷value值是否太大,太大則轉換爲子樹進行存儲。轉化爲subdb/subpage時,首先根據各種標誌設置各種變量,包括申請新頁等,然後其餘的就是根據各種標誌完成上述理論描述的節點插入動作,將值放置對應位置、進行分頁等,需要時進行unspill,放置到overflow頁面等,若一次插入多條數據還需要多次重複進行一次一條的插入。

      mdb_cursor_del,mdb_cursor_del0:刪除指定key、value。首先是根據各種標誌設置各種變量,其次設置頁面爲髒頁,其次若刪除之後,subdb/subpage,overflowpage等收到影響,則需要將對應頁面回收到free-list,比如subdb刪除最後一個節點時,需要刪除整棵子樹。真正的key刪除在del0中,它從頁面中刪除對應的key,刪除完成後對整個B-Tree進行rebalance,然後修正所有指向當前刪除頁的同一事務內的其他cursor,通知其他cursor此頁面已經被刪除。

  • 打開、關閉、重用、初始化
    mdb_cursor_touch:將數據庫以及在cursor堆棧中的所有頁面設置爲髒頁。這樣可能會有少量頁面實際不需要設置爲髒頁實際設置爲髒頁的情形,但這樣爲實現COW提供最大的便利,只需要修改root頁面指針即可,否則需要跟蹤很多頁面。
    mdb_cursor_open:打開遊標,首先判斷標誌是否合法,合法就申請內存並調用init初始化
    mdb_cursor_renew:重用遊標,當本遊標已經不再使用,可以renew重用。
    mdb_cursor_close:關閉遊標,從事務的cursor列表中刪除,釋放內存。

          mdb_cursor_copy:複製遊標,將所有內容從一個複製到新遊標。

          mdb_cursor_shadow:備份cursor對應事務的遊標,用於envcopy

          mdb_cursor_init:設置各種變量,若數據庫狀態爲DB_STALE,則需獲取最新的root節點。

  • 頁面
            mdb_cursor_pop:從cursor堆棧中彈出一個頁面
          mdb_cursor_push: 將一個頁面壓入堆棧,一般會將整個search路徑上的所有頁面壓入堆棧。
  • 狀態
    mdb_cursor_chk:檢查cursor是否正確
    mdb_cursor_txn: 獲取cursor對應事務
    mdb_cursor_dbi:獲取cursor對應數據庫

以上內容簡單介紹了lmdb內部使用的B-Tree原理,以及針對B-Tree操作的各種函數的簡單介紹,關於B-Tree存儲subdb,subpage,overflowpage等還未足夠仔細,若有時間將在後續博文中單開一篇詳細描述以上非正常key-value的數據存儲和操作方式。LMDB中的B-Tree實現的是B+-Tree,所有葉子節點都在同一層級。

      本文中不足之處很多,歡迎交流指正。     

參考文獻:

https://en.wikipedia.org/wiki/B-tree

http://blog.csdn.net/hbhhww/article/details/8206846

http://slady.net/java/bt/view.php

計算機程序和藝術

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章