关于在MongoDB中重用deleteList策略

Question

我有一个关于从MongoDB中的deleteList arrays-list为新记录分配空间的问题。我查看了__stdAlloc和namespace_details.h中的namespace_details.cpp功能代码。 Mongodb的alloc策略是尝试五次最佳匹配DeletedRecord。我不明白为什么我们不将DeletedRecord-size排序为列表。分类列表很快用于分配记录空间。为什么不按大小排序deleteList后退列表的deletedRecord？

注意：

1. namespace_details.h，namespace_details.cpp;
2. MongoDB源代码版本为2.6.12。

Answer 1

这主要是一个历史考虑因素：分配策略和存储引擎自MongoDB 2.6（2016年10月reached end-of-life）以来发生了变化。 MongoDB 3.0引入了一个存储引擎API和WiredTiger存储引擎，从MongoDB 3.2开始，它现在是新部署的默认设置。从MongoDB 3.4开始，MMAPv1存储引擎仍然可用，但新功能和支持的开发重点已转移到WiredTiger存储引擎。

一般的MMAP记录分配策略是尝试快速找到“足够好”的记录分配，而不必找到理想的分配来最大化存储重用。免费列表分为unsorted linked list "buckets" grouping records of similar sizes。对于从未排序的链表中插入和删除，维护排序列表的成本与O（1）相比是昂贵的：MMAP实现非常简单且持续快速。

最初的MMAP分配策略是根据当前集合的历史文档增长为具有可变填充量的文档分配记录空间。根据应用程序的使用情况，这种方法可以在每个空闲列表桶中产生大量的记录大小。使用此分配策略，排序的免费列表将有助于确保有效的存储重用，但整体性能影响和在不比较实际实现和用例的情况下，收益是不确定的。

MongoDB 2.2添加了一个新的Power of 2分配策略（在MongoDB 3.0中成为MMAP的默认值）。 Power of 2策略将记录分配量化为预定大小（例如，32,64,128字节......），这简化了空闲空间的重用并确保所有分配都是O（1）。这解决了原始填充策略中存储重用的挑战，同时仍提供可预测的性能。鉴于固定的记录大小，我认为排序的免费列表可能不会在当前MMAP实施的复杂性与性能之间进行权衡。

由于MongoDB是开源的，您可以始终fork the repo on Github并尝试制作＆amp;测试实施变化。有关详细信息，请参阅Contributing to the MongoDB Server指南。