在葉子節點的所有鍵數據都在內存中的情況下，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樹很好用，並且在用於內存中存儲時通常會帶來很多好處。