我是新来的一些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，否则没有人知道什么是在查询中的问题 –