如何將數組索引（整數）存儲為 B+樹中的鍵？

Question

我已經查看了 GitHub 上 JavaScript 中B+樹的每個示例，並嘗試將其中的一個簡化為半可讀代碼。 但是我仍然不明白每個內部節點的keys數組的結構是什么。 鑰匙長什么樣？ 您如何在 get/insert/remove 算法中使用它們？ 特別是對於這個問題，我想將 B+tree 視為外部數組或排序列表。 所以我希望“鍵”是 integer （數組中項目的索引）。 我該怎么做呢？ 什么是示例 JSON 演示，展示了在這種情況下簡單的 B+樹會是什么樣子？

{
  type: 'tree',
  keys: [?],
  children: [
    {
      type: 'internal',
      keys: [?],
      children: [
        {
          type: 'leaf',
          value: { foo: '123' }
        },
        {
          type: 'leaf',
          value: { foo: '234' }
        }
      ]
    },
    {
      type: 'internal',
      keys: [?],
      children: [
        {
          type: 'leaf',
          value: { foo: '345' }
        },
        {
          type: 'leaf',
          value: { foo: '456' }
        }
      ]
    }
  ]
}

鑰匙還能做什么？ 我知道它們以某種方式用於查找，但是如何？

假設基地有 32 個內部節點，每個內部節點都有 32 個內部節點，每個內部節點都有一堆葉子。 內部節點中的鍵是什么？

我想在 JavaScript 中實現一個健壯的 B+樹，目前很難理解 B+樹的基礎知識。

Answer 1

所以我希望“鍵”是 integer （數組中項目的索引）。 我該怎么做呢？

不，你不能使用整個結構中項目的絕對索引作為鍵。 這意味着在數組的前面插入/刪除時，整個樹中的所有節點都需要更新它們的索引。

相反，您需要存儲子樹的大小，以便在遍歷樹時將它們累積到相對索引中 - 您已在如何在樹節點具有子樹大小時按索引返回樹節點中完成此操作？ 已經。 除非節點本身（或其子節點之一）發生變化，否則這些大小永遠不會改變，因此您將始終只需要更新O(log n)個節點。

什么是示例 JSON 演示，展示了在這種情況下簡單的 B+樹會是什么樣子？

{ type: 'internal',
  // size: 8,
  // childSizes: [2, 3, 3],
  keys: [2, 5],
  children: [
    { type: 'leaf',
      // size: 2
      // childSizes: [1, 1]
      keys: [1],
      values: [ {…}, {…} ]
    },
    { type: 'leaf',
      // size: 3,
      // childSizes: [1, 1, 1],
      keys: [1, 2],
      values: [ {…}, {…}, {…} ]
    },
    { type: 'internal',
      // size: 3
      // childSizes: [1, 2]
      keys: [1],
      chilren: [
        { type: 'leaf',
          // size: 1
          // childSizes: [1]
          keys: [],
          values: [ {…} ]
        },
        { type: 'leaf',
          // size: 2
          // childSizes: [1, 1]
          keys: [1],
          values: [ {…}, {…} ]
        },
      ]
    },
  ]
}

如果每個節點在一個字段中只有它的size就足夠了，但這需要將一個節點的所有子節點加載到 memory 中，僅用於累積大小以找到在查找/插入/刪除操作中選擇哪個子節點，所以它是通常不做。 您可以將節點大小存儲在其父節點中（作為childSizes ）。 或者您可能已經將累積的大小存儲在 B+ 樹的keys數組中，這樣您就不需要在搜索期間計算總和（但是如果只有一個條目發生更改，則必須更新整個數組 - 這是一種權衡） . 與只存儲 k 個子節點之間的k k-1 “邊界”鍵的經典 B+ 樹不同，將完整的總和（= 節點的大小）存儲在最后一個數組索引中可能是個好主意。