微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

键的 B+ 树数据结构

如何解决键的 B+ 树数据结构

在 B+ 树中,我认为对于任何给定节点,最多可以有 M(B+树的顺序)- 1 个键。

现在,当你想以 4 的顺序将一个值为 7 的键插入到这棵树中时:

10,12

然后就会变成这样:

7,10,12

如果一个节点的结构是这样的:

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

那么这意味着如果要在节点的开头插入,则最多必须向右移动 MAX_SIZE 个元素。这不是最理想的。我想知道是否有更好的地方来存储 keys。如果您将每个键存储为一个链表,这会提供更好的插入效果,但会花费更多空间。

存储 keys 的最佳方式是什么?在我的场景中,此 B+Tree仅在内存中使用

解决方法

恕我直言,将密钥与指向子树的指针配对比拥有一个密钥容器和一个指针容器更好。

struct Node;

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

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

与并行数组(向量)相比,上述结构允许键和指向子树的指针之间更好地同步。

,

我喜欢 SQL Server 所做的,在每个块的末尾有一个记录偏移数组,然后在块头后面有一个数据区。

实际的数据记录不需要是有序的,重要的是偏移数组中的顺序。

基本上(尽管由于可变布局而不是实际的结构类型): 结构块 { blockk_header 标头; // 包括记录偏移量数组的偏移量( // 包括记录计数或偏移量以记录偏移量数组 /* 可变大小的记录数据 / // 可变大小的记录偏移数组 */ };

注意偏移数组的结尾总是与块的结尾齐平。我想如果你在代码中确切地知道你的密钥类型总是会是什么,那么不需要这样的游戏,但上述方案允许在处理块时不关心关键数据是什么。这样做还允许对 B+ 树节点和数据记录使用相同的代码(前者只是简单地剥离数据记录加上指向下一个块的指针)。

,

当您的 B+树仅在内存中时,您使节点比磁盘支持的 B+树小得多。

一个合适的大小是 2 个缓存行,或者 x86 上的 128 字节。这么大,一开始就插入不算太贵,把节点变大也不会让你的搜索速度明显加快。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。