我是一些MongoDB概念的新手，比如分配策略。目前我使用的是MongoDB-3.2.2版本，我正在使用 与Windows-32位和64位相同的版本。根据Mongo文档，默认分配策略是“PowerOf2Sizes” 哪个更适合插入/更新/删除操作。我有以下要求： 我将我的日志作为一个文档存储到一个数组中。所以最初我开始在数组中插入一个日志，然后我会更新 具有no.of日志条目的文档中的相同数组。所以我在文档中插入和更新数组。 这里我使用的是32位（MMAPV1）和64位（有线老虎）引擎。
根据我对Mongo文档的理解，我不需要将任何填充因子（通过分配策略）设置为64位以避免文档移动。 我只需要为32位（MMAP v1存储引擎）设置填充因子（通过分配策略）。
任何机构都可以告诉我如何根据上述要求使用分配策略？或者我的理解是否正确？
答案 0 :(得分：0)
答案 1 :(得分：0)
在wiredTiger存储中，没有填充需要存储不是线性的，因为在MMapV1中，由于文档移动到最后（或者可用的空白区域），我们会出现碎片问题。
如果您已经知道您的文档足够大并且您不想要移动，则分配策略是插入具有大垃圾文本字段的文档，然后使用$ unset调用更新文本字段将删除垃圾文本，这样您的文档已经有更大的空间，并且随着数据的进一步增长，它的移动不太可能。
但是每个文档有16MB的限制，这是足够好的，所以为了保持健康的水平，你可以用$ slice调用$ push作为-50（左右），这将确保你的数组只有最后一个50个日志。
如果它是关于日志的，那么封顶集合是一个很好的策略，但是当每个日志都是一个单独的文档时，它就会起作用，而不是你的设计。
答案 2 :(得分：-1)
MongoDB的文件限制为16MB。因此，您的解决方案可能无法在具有良好流量的实时生产设备中运行。因为当一个prouction bug开始快速填充时，文档将会耗尽。
下面的文档将帮助您设计后端并带来可扩展性。
https://docs.mongodb.com/ecosystem/use-cases/storing-log-data/