将数据批量加载到 b+tree答案

【问题标题】：bulk loading data into a b+tree将数据批量加载到 b+tree
【发布时间】：2011-11-29 14:07:39
【问题描述】：

我已经建立了一个我自己的 b+tree 索引，包括插入/删除/搜索索引的所有操作。为了加速大型数据集的插入，我还想实现批量加载，以便能够对大型数据集进行试验。

我一直在尝试做的是对数据进行排序并开始在叶级别填充页面。必要时在上层复制或推送密钥。我总是在不同的高度跟踪指数的前沿。例如，如果我的索引高度为 3（根，一层包含内部节点和叶子层），我只在内存中保留 3 页，一旦它们满了，或者没有更多数据，我将它们写入磁盘。

问题是要向每个页面写入多少数据才能维持所有单个节点的页面限制。这些限制可以在 here 找到。我找不到任何有用的资源，其中包含有关批量加载实施的详细信息或决定使用什么填充率以保证节点限制的好策略。

有什么想法吗？

【问题讨论】：

为什么不把所有的页面都填满呢？只要树不退化为病态病例，理论上的限制在实践中并不重要。
如果我在很多情况下继续将每个页面都填满，我最终会得到一个不平衡的 B+树。键需要在水平和垂直方向上大致均匀地分布在索引中，这就是存在理论限制的原因。
您提供的链接说任何节点的最大容量是b，这意味着它最大程度地满了。我无法提出一个数据集，其中仅填充叶子直到它们充满会导致不平衡的树。能举个例子吗？
这很容易想出。当 b=4 时，每个叶子的容量是 3 个键。如果 B+树有 4 个键，用 3 个键填充第一个叶子，最后一个键只有 1 个键，树不平衡。此外，每个节点的最小键数不能少于 2。

【解决方案1】：

从问题下的 cmets 可以看出，您担心的是最后一页（或最后一页，如果考虑树中较高的页面）可能未达到最小填充数。

由于此类页面的数量受 log2(n)（树的高度）的限制，我怀疑理论上的性能保证不会受到影响。

无论如何，您链接到的保证不是正确性所必需的。它们足以保证运行时间的界限。但是，它们对于保证运行时间并不是必要的（例如：在 b 树的末尾添加一页和一行 - 您仍然可以获得相同的保证运行时间）。

如果你想知道真正的 b-trees 是如何运作的，你可能想看看你最喜欢的 RDBMS（作为一个 SQL Server 用户，我知道 SQL Server 在没有实际操作的情况下很高兴地低于 50% 的页面填充度保证影响）。我想你会发现理论问题被认为没有多大意义。

【讨论】：

没错！如果你能设法让你的树保持平衡，那么 %50 的填充率就不会是一个非常大的问题。特别是，如果你有一个大的分支因子。但问题最初是关于如何使用批量加载来构建平衡的 B+树。好吧，我从头开始编写了一个 B+树，并以一种方式解决了这个问题，计算我在每个级别中的存储桶数量，并将我的密钥均匀地分布在存储桶中，但仍然很好奇标准做法是什么。