平衡的树木和空间和时间的权衡答案

【问题标题】：Balanced trees and space and time trade-offs平衡的树木和空间和时间的权衡
【发布时间】：2016-09-11 14:27:14
【问题描述】：

当输入大小从一百万增加到十亿甚至更多时，我想知道可扩展性问题。例如考虑一个整数流（大小：4 字节）和大小为 10 亿的输入，在内存中存储整数所需的空间约为 3GB！当您考虑其他数据类型（例如浮点数和字符串）时，问题会变得更糟，而输入大小是正在考虑的数量级。

因此，我得出的结论是，我需要辅助存储来存储所有这些数字和指向 AVL 树的子节点的指针。我正在考虑将左右子节点存储为单独的文件，但后来我意识到这将是太多的文件，并且打开和关闭文件将需要昂贵的系统调用和耗时的磁盘访问，因此此时我意识到 AVL 树行不通。

接下来我想到了 B-Tree 及其提供的优势，因为每个节点可以有“n”个子节点，从而减少磁盘上的文件数量，同时在每个级别打包更多键。我正在考虑为节点创建单独的文件，并在生成文件时将密钥插入文件中。

1) 我想问一下我的方法和思维过程是否正确，并且
2）我是否使用了正确的数据结构，如果 B-Trees 是正确的数据结构，那么应该如何使应用程序高效？什么样的 B 树会产生最大的效率。对不起，很长的帖子！提前感谢您的回复！

【问题讨论】：

【解决方案1】：

是的，你的推理是正确的，尽管可能有比每个文件存储一个节点更聪明的方案。事实上，出于多种原因，B(+)-Tree 在实践中通常优于二叉搜索树（尤其是对于非常大的集合），这就是为什么几乎每个主要数据库系统都将其用作其主要索引结构的原因。二叉搜索树表现不佳的一些原因是：

具有高阶的 B(+)-Tree 总是相对较浅（高度为 3-5），这会减少磁盘访问次数。对于范围查询，您可以从内存中连续读取，而在二叉树中您会跳来跳去。在节点中搜索可能需要更长的时间，但实际上你会受到内存访问的限制，而不是 CPU 时间。

那么，问题仍然是使用什么顺序？通常，节点大小选择为等于页面大小 (4-64KB)，因为优化磁盘访问是最重要的。页面大小是您的计算机可以从磁盘加载到主内存的最小连续内存块。根据您的键的大小，这将导致每个节点的元素数量不同。

对于实现的一些帮助，看看B+-Trees是如何在数据库系统中实现的。

【讨论】：

不错的总结！高度为 20 的完全平衡 BST 仅包含一百万个元素，而不是 10^9，对于具有宽松平衡标准（即 AVL、红黑）的真正 BST 而言，它甚至更少。 BST 最严重的罪过是 CPU 缓存的使用不当 - 它们在每次比较时都会命中一个新的缓存行（子链接 deref），而 B+树可以从每个缓存行中挤出最大数量的比较，但需要一点小心。当涉及二级存储时，差异会变得更大。
事实上，BST 的性能非常差，如果性能很重要，它们绝不是一个好的选择。哈希容器在内存中击败了它们，并且随着排序容器的运行，它们在低端的排序向量和其他任何地方的 B-树（或 B+树）都优于它们。 BST 的利基是应用程序，它们的低劣性能无关紧要，并且无法证明高性能解决方案的工程是合理的。
对，2^30 大约是十亿，而不是 2^20。我编辑了这个。
您好，感谢您的回复！我理解为什么 B+ 树用于可扩展性。我想知道 B+ 树是如何被索引的，如果我必须编写一个程序，如果我的每个节点一个文件的方案有点慢，我可以通过什么方式将 B+ 树存储在磁盘上！非常感谢！！