我正計劃編寫一個簡單的鍵/值存儲，其文件體系結構與CouchDB類似，即僅附加b +樹。B +樹節點大小
我已經閱讀了所有可以在B +樹上找到的所有內容，以及我可以在CouchDB的內部找到的所有內容，但是我沒有時間按照源代碼工作（使用非常不同的語言一個獨特的項目）。
所以我有一個關於B +樹節點的大小的問題，它是：給定的密鑰長度是可變的，保持節點的長度是相同的（以字節爲單位）還是更好地給它們不管他們變得多大，相同數量的鍵/子指針？
我知道在傳統的數據庫中，B +樹節點保持固定長度的字節（例如8K），因爲數據文件中的空間是以固定大小的頁面管理的。但是在只有文件的附加文件中，文件可以是任意長度的，並且更新後的樹節點是在後面寫入的，似乎沒有固定大小節點的優勢。
b-tree的目標是儘量減少磁盤訪問次數。如果文件系統簇大小爲4k，則節點的理想大小爲4k。另外，節點應該正確對齊。未對齊的節點將導致讀取兩個羣集，從而降低性能。
對於基於日誌的存儲方案，選擇4k節點大小可能是最糟糕的選擇，除非在日誌中創建間隙以提高對齊。否則，一個節點存儲在兩個羣集上的時間的99.98％。節點大小爲2k時，發生這種情況的機率不到50％。但是，小節點大小存在問題：b樹的平均高度增加，讀取磁盤簇花費的時間未充分利用。
較大的節點尺寸會減小樹的高度，但它們也會增加磁盤訪問的次數。較大的節點也會增加維護節點內的條目的開銷。設想一個B樹，其中節點大小足以封裝整個數據庫。你必須在節點本身嵌入一個更好的數據結構，也許是另一個B-樹？
我花了一些時間在僅追加日誌格式上構建B樹實現的原型，並最終完全拒絕了這個概念。爲了彌補由於節點/集羣錯位導致的性能損失，您需要有一個非常大的緩存。更傳統的存儲方法可以更好地使用RAM。
最後的打擊是當我評估隨機排序插入的性能。這會殺死任何磁盤備份存儲系統的性能，但基於日誌的格式會遭受更多的損失。即使寫入最小的條目也會強制將幾個節點寫入日誌，並且內部節點在寫入後立即失效。結果，日誌迅速填滿垃圾。 BerkeleyDB-JE（BDB-JE）也是基於對數的，我也研究了它的性能特徵。它遭受了我的原型所造成的同樣的問題 - 快速積累垃圾。 BDB-JE有幾個「更乾淨」的線程，將倖存的記錄重新附加到日誌中，但隨機順序被保留。因此，新的「乾淨」記錄已經創建了充滿垃圾的日誌文件。系統的整體性能降低到唯一運行的就是更清潔，並佔用了所有系統資源。
基於日誌的格式非常有吸引力，因爲可以快速實現強大的數據庫。阿喀琉斯腳跟是清潔劑，這是不平凡的。緩存策略也很難得到正確的結果。