B+ 鍵的樹數據結構

Question

在 B+ 樹中，我認為對於任何給定節點最多可以有 M（B+樹的順序）- 1 個鍵。

現在，當您想以 4 的順序將值為 7 的鍵插入此樹時：

10, 12

然后它會變成這樣：

7, 10, 12

如果一個節點的結構是這樣的：

struct Node {
    int keys[MAX_SIZE];
    ...
};

那么這意味着如果要在節點的開頭插入，則最多必須向右移動MAX_SIZE個元素。 這不是最理想的。 我想知道是否有更好的存儲keys的地方。 如果將每個鍵存儲為鏈表，這將提供更好的插入，但會花費更多空間。

存儲keys的最佳方式是什么？ 在我的場景中，這個B+Tree將純粹用於 memory 。

Answer 1

恕我直言，將鍵與指向子樹的指針配對比擁有一個鍵容器和一個指針容器更好。

struct Node;

struct Key_Subtree
{
    int key;
    Node * p_subtree;
};

struct Node
{
   std::vector<Key_Subtree> keys;
   Node * p_lesser_subtree;
};

與並行 arrays（向量）相比，上述結構允許鍵和指向子樹的指針之間更好的同步。

Answer 2

我喜歡 SQL 服務器所做的，在每個塊的末尾有一個記錄偏移數組，然后是塊 header 之后的數據區域。

實際的數據記錄不必按順序排列，只有偏移數組中的順序很重要。

基本上（盡管由於布局可變而不是實際的結構類型）： struct block { blockk_header header; // 包括記錄偏移量數組的偏移量 ( // 包括記錄計數或記錄偏移量數組的偏移量 /* 可變大小的記錄數據//可變大小的記錄偏移量數組 */ };

請注意，偏移數組的末尾始終與塊的末尾齊平。 我想如果你在代碼中確切地知道你的密鑰類型總是這樣的游戲就不需要了，但是上面的方案允許在處理塊時不關心密鑰數據是什么。 這樣做還允許對 B+ 樹節點和數據記錄使用相同的代碼（前者只是簡單地剝離了數據記錄加上指向下一個塊的指針）。

Answer 3

當您的 B+樹僅在 memory 中時，您使節點比您為由磁盤支持的 B+樹所做的小得多。

x86 上的 2 個緩存行或 128 個字節是一個好的大小。 一個這樣的大小，在開頭插入並不太昂貴，並且使節點更大不會使您的搜索速度顯着加快。