B +樹節點大小調整

Question

我打算用一個類似於CouchDB的文件架構編寫一個簡單的鍵/值存儲，即一個僅附加的b +樹。

我已經閱讀了我在B +樹上可以找到的所有內容以及我在CouchDB內部可以找到的所有內容，但是我沒有時間通過​​源代碼工作（使用非常不同的語言使它成為一個特殊項目它自己的權利）。

所以我對B +樹節點的大小有一個問題，即： 給定的密​​鑰長度是可變的，保持節點長度（以字節為單位）更好，或者給它們相同數量的密鑰更好/兒童指針無論它們有多大？

我意識到在傳統數據庫中，B +樹節點以字節（例如8K）保持固定長度，因為數據文件中的空間是在固定大小的頁面中管理的。 但是在僅附加文件方案中，文檔可以是任意長度並且更新后的樹節點被寫入，具有固定大小的節點似乎沒有優勢。

Answer 1

b樹的目標是最小化磁盤訪問次數。 如果文件系統簇大小為4k，則節點的理想大小為4k。 此外，節點應正確對齊。 未對齊的節點將導致讀取兩個群集，從而降低性能。

使用基於日志的存儲方案，選擇4k節點大小可能是最差的選擇，除非在日志中創建間隙以改善對齊。 否則，99.98％的時間將一個節點存儲在兩個集群上。 如果節點大小為2k，則發生這種情況的可能性不到50％。 但是，小節點大小存在問題：b樹的平均高度增加，並且未充分利用讀取磁盤簇所花費的時間。

較大的節點大小會降低樹的高度，但它們也會增加磁盤訪問次數。 較大的節點還會增加維護節點內條目的開銷。 想象一下b樹，其中節點大小足以封裝整個數據庫。 你必須在節點本身內嵌入一個更好的數據結構，也許是另一個b樹？

我花了一些時間在僅附加日志格式上對b樹實現進行原型設計，並最終完全拒絕了這個概念。 為了補償由於節點/群集未對齊而導致的性能損失，您需要具有非常大的緩存。 更傳統的存儲方法可以更好地利用RAM。

最后一擊是我評估隨機排序刀片的性能。 這會破壞任何磁盤支持的存儲系統的性能，但基於日志的格式會受到更多影響。 寫入甚至最小的條目會強制將幾個節點寫入日志，並且內部節點在寫入后不久就會失效。 結果，日志迅速填滿了垃圾。

BerkeleyDB-JE（BDB-JE）也是基於日志的，我也研究了它的性能特征。 它遇到了我的原型所遇到的同樣問題 - 垃圾的快速積累。 BDB-JE有幾個“更干凈”的線程，它們將幸存的記錄重新附加到日志中，但保留了隨機順序。 結果，新的“干凈”記錄已經創建了充滿垃圾的日志文件。 系統的整體性能降低到唯一運行的是清潔器，它占用了所有系統資源。

基於日志的格式非常有吸引力，因為可以快速實現強大的數據庫。 阿喀琉斯之踵是清潔工，非常重要。 為了做到正確，緩存策略也很棘手。