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有几个“更干净”的线程，它们将幸存的记录重新附加到日志中，但保留了随机顺序。 结果，新的“干净”记录已经创建了充满垃圾的日志文件。 系统的整体性能降低到唯一运行的是清洁器，它占用了所有系统资源。

基于日志的格式非常有吸引力，因为可以快速实现强大的数据库。 阿喀琉斯之踵是清洁工，非常重要。 为了做到正确，缓存策略也很棘手。