關於在MongoDB中重複使用deleteList策略

Question

我有一個關於從MongoDB中的deleteList數組列表中爲新記錄分配空間的問題。我查看了namespace_details.h和namespace_details.cpp中的__stdAlloc功能代碼。 Mongodb的分配策略是爲bestmatch DeletedRecord嘗試五次。我不明白爲什麼我們不會爲列表排序DeletedRecord-size。排序列表很快用於分配記錄空間。 mongodb爲什麼不按大小排序deleteList的deletedRecord後退列表？

注：

1. namespace_details.h，namespace_details.cpp;
2. MongoDB源代碼版本是2.6.12。

Answer 1

這主要是一個歷史考慮：自MongoDB 2.6（其中reached end-of-life 2016年10月）以來，分配策略和存儲引擎發生了變化。 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分配策略（這成爲MMAP的默認值MongoDB 3.0）。 Power Of 2策略將記錄分配量化爲預定大小（例如32,64,128字節，...），這簡化了空閒空間的重用並確保所有分配都是O（1）。這解決了原始填充策略中存儲重用的挑戰，同時仍提供可預測的性能。鑑於固定的記錄大小，我認爲排序的自由列表可能不會在當前MMAP實現的複雜性與性能之間進行有意義的折衷。

由於MongoDB是開源的，您可以隨時fork the repo on Github並嘗試使&測試實施更改。欲瞭解更多信息，請參閱Contributing to the MongoDB Server指南。