扇出究竟如何影响b+树中的拆分和合并?
如果我有1024字节的页面和8字节的键,也许还有8字节的指针,我可以在一个页面中存储大约64个键。考虑到一个页面将是我的节点,所以如果我有一个80%的扇出,这是否意味着拆分将在节点满80%之后发生,就像插入52个键之后还是仅在节点溢出之后发生。
对于merge,如果我们有大约80%的扇出,当键小于节点大小的一半或80%与之相关时,我们何时合并节点。
最佳答案
所有类型的b树中的拆分和合并通常由基于完整性标准的策略驱动。最好从节点空间利用率而不是键计数的角度考虑满度;固定大小的结构(其中空间利用率是根据键计数来衡量的,因此相当于扇出)往往只出现在学术界和特殊的环境中,如在内存中整数或散列上的B树在实践中,通常会涉及到可变大小的元素,从可变大小的键开始,这些键会通过前缀/后缀截断和压缩等方式进一步改变大小。
拆分几乎总是在更新操作导致节点溢出时发生。策略之间的区别在于它们如何努力将密钥转移到相邻节点以避免拆分(只查看一个兄弟节点或同时查看两个兄弟节点),以及它们尝试卸载多少密钥(一个或多个)。一些锁定策略要求在初始下降期间进行预防性的分离/合并,以确保在返回途中不会发生分离或合并。在这种情况下,决策必须基于最小/最大可能的密钥大小而不是查看实际密钥的大小。
有些策略只有当有两个完全相邻的节点时才会分裂,然后分裂为三个节点,并且只有当有三个相邻的节点处于下溢边缘时才会合并(导致两个完全节点)。最终结果是最低利用率高达2/3,平均利用率为3/4或更高。然而,更新算法的复杂性的增加很少是值得的。
总的来说,可以总结出这样的标准:当一个节点有溢出的危险,并且不可能将密钥卸载到邻居时进行拆分;当一个节点有溢出的危险,并且没有一个邻居可以捐赠密钥时进行合并。
关于algorithm - 扇出B +树,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/32687620/