2011-10-02 28 views
2

我已经构建了一个我自己的b +树索引,包含对索引进行插入/删除/搜索的所有操作。为了加速插入一个巨大的数据集,我想实现批量加载以及能够实验大数据集。将数据批量加载到b +树中

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

问题是要向每个页面写入多少数据才能维护所有单个节点的页面限制。这些限制可以在 here找到。我无法找到任何有用的资源,详细说明批量加载的实施情况,或者确定使用哪种填充比率以确保节点限制的好策略。

任何想法?

+0

为什么你不填满所有的网页,直到他们满了?只要树不退化成病理性病例,理论上的限制在实践中并不重要。 – usr

+0

如果我在很多情况下将每个页面填充到最大容量,我最终会得到一个不平衡的B +树。密钥需要在水平和垂直方向上大致均匀地分布在索引上,这就是为什么存在理论极限。 – Pirooz

+0

您提供的链接表示任何节点的最大容量为b,这意味着它最大满。我不能拿出一个数据集来填充树叶,直到它们满了会导致树不平衡。你能给个例子吗? – usr

回答

0

从问题的评论我可以告诉你的关注是最后一页(或最后一页,如果考虑在树上更高)可能无法达到最小填充计数。

由于这些页面的数量以log2(n)(树的高度)为界,我怀疑理论性能保证不受影响。

无论如何,您链接到的保证不是正确性所必需的。它们足以保证运行时间的界限。他们不是必要虽然保证运行时间(例如:一行添加一行到b-tree的末尾 - 你仍然得到相同的保证运行时间)。

如果你想知道真实的B树是如何操作的,你可能想看看你最喜欢的RDBMS(作为一个SQL Server用户,我知道SQL Server高兴地低于50%的页面填充保证没有实际影响)。我认为你会发现理论上的担忧被认为不是很有意义。

+0

没错!如果您可以设法保持树木平衡,那么%50填充率不会是一个非常大的问题。特别是,如果你有一个很大的分支因子。但问题最初是如何建立一个平衡的B +树,首先使用批量加载。那么,我已经从头开始编写了一个B +树,并且已经用一种方法解决了这个问题,计算了每个级别的桶的数量并将这些密钥均匀分布在桶中,但仍然对标准做法感到好奇。 – Pirooz

相关问题