在叶子节点的所有键数据都在内存中的情况下，B + tree搜索的性能是否比Binary Search Tree搜索更好？

Question

假设我们正在内存中实现一个B +树，键在内部节点上，而键数据对在叶节点上。 如果B + tree的扇出为f，则表示B +树的高度为log_f N，其中N为键的数量，而相应的BST的高度为log_2N。如果我们不进行任何磁盘读取并写入，B + tree搜索性能能否优于Binary Search Tree搜索性能？ 怎么样？ 由于对于每个内部节点的B + tree，我们对F做出了很多选择，而对于BST，是否选择1？

Answer 1

至少与高速缓存相比，主内存具有许多与磁盘驱动器相同的特性-它具有相当高的带宽，但延迟比高速缓存高得多。 它具有相当大的最小读取大小，并且在可预测的读取时（例如，当您读取多个连续地址处的多个高速缓存行时），其带宽要大得多。 因此，它受益于相同的一般优化（尽管细节经常有所不同）。

B树（以及B *和B +树之类的变体）经过明确设计，可以与磁盘驱动器很好地支持的访问模式一起使用。 由于无论如何都必须读取相当大量的数据，因此最好将数据打包以最大程度地从必须读取的内存中完成数据。 在这两种情况下，通过以可预测的模式读取最小读取数的某些倍数（尤其是在连续地址处的多个连续读取数），您也经常会获得可观的带宽增益。 因此，将单个页面的大小增加到甚至大于一次读取的最小大小通常很有意义。

同样，在这两种情况下，我们都可以计划在找到我们真正关心的数据之前，通过树中的多个节点层次进行下降。 就像从磁盘读取数据一样，我们可以从最大化读取数据中密钥的密度中受益，直到我们真正找到了我们关心的数据为止。 使用典型的二叉树：

template <class T, class U>
struct node {
    T key;
    U data;
    node *left;
    node *right;
};

...我们最终读取了一些我们没有实际用途的数据项。 仅当我们找到了需要/想要获取关联数据的正确密钥时。 公平地说，我们也可以使用二叉树来做到这一点，只需对节点结构进行相当小的修改即可：

template <class T, class U>
struct node {
    T key;
    U    *data;
    node *left;
    node *right;
};

现在，该节点仅包含指向数据的指针，而不包含数据本身。 如果data很小，这将无法完成任何工作，但是如果data很大，则可以完成很多工作。

简介：从CPU的角度来看，从主存储器中进行读取与从磁盘中进行读取具有相同的基本特征； 磁盘只是显示了这些特性的更极端的版本。 因此，导致B树（和变体）设计的大多数设计注意事项现在都类似地应用于存储在主存储器中的数据。

B树很好用，并且在用于内存中存储时通常会带来很多好处。