我是新來的一些MongoDB概念，如分配策略。目前我正在使用MongoDB-3.2.2版本，我正在使用與Windows-32位和64位相同版本的 。根據Mongo文檔，默認分配策略是「PowerOf2Sizes」 ，這對插入/更新/刪除操作更好。我有以下要求： 我將我的日誌作爲一個文檔存儲到數組中。所以最初我開始在數組中插入一個日誌，然後我將更新文檔中相同數組的 ，但不記錄日誌條目。所以我插入並更新文檔中的數組。 這裏我使用32位（MMAPV1）和64位（有線老虎）引擎。有效地使用MongoDB分配策略
根據我對Mongo文檔的理解，我不需要將任何填充因子（通過分配策略）設置爲64位以避免文檔移動。 我只需要爲32位（MMAP v1存儲引擎）設置填充因子（通過分配策略）。
任何機構能告訴我如何使用分配策略滿足上述要求？或者我的理解是否正確？
MongoDB的限制爲16MB /文件。因此，您的解決方案可能無法實現具有良好流量的實時生產系統。當缺陷開始快速填充時，文檔將會枯竭。
以下文檔將幫助您設計後端並帶來可擴展性。
https://docs.mongodb.com/ecosystem/use-cases/storing-log-data/
在wiredTiger存儲我們由於文檔移動到最後（或可用的空白空間），導致碎片問題。
如果您已經知道您的文檔將足夠大並且您不想移動，則分配策略是插入包含大量垃圾文本的字段的文檔，然後使用$ unset調用更新該文本字段將刪除垃圾文本，這樣，您的文檔已經有了更大的空間，並且它的移動不太可能隨着數據的進一步增長。
然而，每個文檔有16MB的限制，這足夠好，所以要保持健康的級別，您可以使用$ slice調用$ push，如-50（或者這樣），這將確保您的數組只有最後50個日誌。
如果是關於日誌，封頂收集是一個很好的策略，但是當每個日誌都是一個單獨的文檔，而不是您的設計的情況下，它將起作用。
感謝您的答覆。我將日誌條目存儲在一個數組（一個文檔）中，最多爲10MB。應用程序級別有一個限制，用於存儲高達 10 MB的日誌條目。但是每當創建文檔時，它將開始插入一個日誌條目，之後它將更新同一文檔 ，直到達到10MB。在MMAPV1存儲引擎的情況下，是否需要爲此設置填充因子？ –
對於您的場景，我有兩個答案，如果您的日誌塊大小很小，最好設置明確的填充因子，但它看起來像只能設置初始文檔大小的4倍，因此如果您的初始文檔大小爲3kb那麼當你知道它最終將增長到10MB時，12kb的填充因子是無用的。但是初始插入文件大小爲800kb，那麼3200KB一定會有助於填充因子，更多的在這裏https://groups.google.com/forum/#!topic/mongodb-user/ZubUGYryFnI。 –
現在第二個是不用擔心，MMapV1在擴展時會使用allocationOf2大小。這意味着，如果文檔的空間是2mb，並且您的文檔跨越2mb，則它將被分配4mb，當它跨過4mb時，將重新分配8mb等等，這裏的抓取一旦穿過8mb，分配的空間將會是16mb，而您將使用10mb，所以6mb由於您的應用程序限制而未使用。 總而言之，我會說在集合中放置一個大小爲1mb的虛擬字符串，填充因子爲4.0，然後取消設置該字符串，這會極大地限制移動 –
請讓我知道如果有任何細節，然後downvote，否則沒有人知道什麼是在查詢中的問題 –