Berkeley DB 如何管理其文件？
我使用 Berkeley DB (BDB) 作為 JMS 隊列的持久儲存。當我使用隊列中的條目時，底層 BDB 文件不會立即收縮，但最終會收縮。我遇到了 BDB 文件在文件系統上佔用大量空間而檢索性能下降的問題。
我的條目大小變化很大，但在持久隊列中有 400,000 條大約 32kb 的消息並不少見。
我想了解 BDB 如何管理文件，以便我可以限製文件大小/檢索性能的條目數。或者，我可以排除 BDB 作為我的持久儲存機制。
我可能正在搜尋錯誤的術語，但沒有在Oracle 文件或The Berkeley DB Book中找到我要查找的內容。如果 BDB 不希望我弄亂它的內部結構，我不會感到驚訝，但如果（至少）沒有關於它如何處理其內部結構的概述，我會感到驚訝。
基本上，哲學似乎是，如果它會再次增長，那麼在壓縮數據庫上投入太多精力是不值得的。BDB 引擎的工作方式使得很難真正回收具有大量插入/更新活動的工作負載上的任何釋放空間，我認為 JMS 持久性很可能就是這樣的工作負載。當然，這種理念的好處是，在新消息爆發時，數據庫不需要分配更多頁面，而是可以以最有效的方式直接將數據寫入現有頁面。但是，如果對檢索性能的影響很大，那麼 BDB 可能確實不是您工作負載的正確選擇。
我想知道 Oracle 論壇中這些文章中提供的答案是否為這個謎團提供了任何線索（引用來自第二個連結）。
在頁面重用開始之前，數據庫沒有必須達到的特定最大大小。此外，您無需關閉並重新打開數據庫句柄以影響頁面重用。BDB 在清空頁面時重用它們，並且它不執行任何類型的自動鍵/頁面平衡（因為它會導致死鎖）。您應該研究的因素是插入、更新和刪除率、事務是否長期存在、死鎖檢測策略、數據庫頁面大小和頁面填充因子等。
一個可以解釋您所看到的行為的範例是，當嘗試刪除在該頁面上找到的鍵時，刪除程序/執行緒“遲到”到該頁面。當它在該頁面上獲得寫鎖時，那裡不再有連續的鍵，並且刪除程序/執行緒最多只能刪除這些鍵的一部分（其他鍵是具有更高值的鍵，因為插入並且更新程序/執行緒遙遙領先），因此該頁面不會被清空，因此可以將其放置到空閒列表中以供重用。如果插入和更新過程非常活躍，這可能會導致快速的頁面拆分（或新頁面分配），因此鍵集被移動到新頁面上。此外，插入的新鍵可能會落在已經填充的頁面上，從而使刪除過程變得更加困難。如果插入的新鍵可以根據它們的值分配到已經填充的有空間的頁面，那麼空閒列表上的頁面（如果有的話）將不會被重用。