有效使用 MongoDB 分配策略答案

【问题标题】：Use MongoDB Allocation strategy effectively有效使用 MongoDB 分配策略
【发布时间】：2016-09-10 05:33:51
【问题描述】：

我对分配策略等一些 MongoDB 概念不熟悉。目前我使用的是 MongoDB-3.2.2 版本，我使用的是与 Windows 32 位和 64 位的版本相同。根据 Mongo 文档，默认分配策略是“PowerOf2Sizes” 哪个更适合插入/更新/删除操作。我有以下要求：我将我的日志作为一个文档存储到一个数组中。所以最初我开始将一个日志插入到数组中，然后我将更新文档中具有 no.of 日志条目的相同数组。所以我在文档中插入和更新数组。这里我使用的是 32 位（MMAPV1）和 64 位（Wired Tiger）引擎。

根据我对 Mongo 文档的理解，我不需要将任何填充因子（通过分配策略）设置为 64 位以避免文档移动。我只需要为 32 位（MMAP v1 存储引擎）设置填充因子（通过分配策略）。

任何人都可以告诉我如何使用分配策略来满足我的上述要求吗？还是我的理解正确？

【问题讨论】：

请让我知道如果遗漏任何细节然后投反对票，否则没有人知道查询中的问题是什么

标签： mongodb padding allocation mongodb-java

【解决方案1】：

我有一个很好的视频来回答你的问题。这是来自 MongoDb 架构师，将帮助您分析您的需求

https://youtu.be/9nYFnlM4vYw

美好的一天

【讨论】：

【解决方案2】：

在 WiredTiger 存储中，不需要填充，存储不是线性的，因为在 MMapV1 中，由于文档移动到末尾（或任何可用的空白空间），我们会遇到碎片问题。

如果您已经知道您的文档将足够大并且您不希望移动，则分配策略是插入您的文档，该文档具有包含大量垃圾文本的字段，然后在该字段上调用带有 $unset 的更新text 字段将删除垃圾文本，这样您的文档已经有了更大的空间，并且随着数据的进一步增长，它不太可能移动。

但是，每个文档有 16MB 的限制，这已经足够了，所以为了保持健康的水平，您可以调用 $push 并将 $slice 设置为 -50（左右），这将确保您的数组只有最后一个50 条日志。

如果它是关于日志的，封顶收集是一个很好的策略，但是当每个日志都是一个单独的文档时它会起作用，而你的设计不是这样。

【讨论】：

感谢您的回复。我将整个日志存储在一个数组（一个文档）中，最大 10mb。应用程序级别限制存储最多 10MB 的日志条目。但是每当创建文档时，它都会从一个日志条目开始插入，之后它将更新同一个文档，直到达到 10MB。如果是 MMAPV1 存储引擎，我是否需要为此设置填充因子。
我对你的场景有两个答案，如果你的日志块大小很小，最好设置一个明确的填充因子，但看起来你只能设置初始文档大小的 4 倍，所以如果您的初始文档大小是 3kb，那么当您知道它最终会增长到 10MB 时，12kb 的填充因子是没有用的。但初始插入文档大小为 800kb，然后 3200KB 肯定会有助于填充因子，更多内容请参见 groups.google.com/forum/#!topic/mongodb-user/ZubUGYryFnI。
现在第二个是不用担心，MMapV1 在扩展时使用 allocationOf2 大小。这意味着，如果文档的空间为 2mb，并且您的文档超过 2mb，它将被分配 4mb，当超过 4mb 时，它将重新分配 8mb，依此类推，这里的问题是，一旦超过 8mb，分配的空间将是16mb，而您将使用 10mb，因此由于您的应用程序限制，6mb 将未被使用。总之，我会说在集合上放置一个填充因子为 4.0 的 1mb 大小的虚拟字符串，然后取消设置该字符串，它将极大地限制移动
设置填充因子的链接是docs.mongodb.com/manual/reference/command/compact
我会说在收集时放置一个大小为 1mb、填充因子为 4.0 的虚拟字符串，然后取消设置该字符串。如果可以的话，请给我一个例子，如果你能提供一个例子就好了

【解决方案3】：

MongoDB 的限制为 16MB/文档。因此，您的解决方案可能无法在具有良好流量的实时生产服务器中运行。因为当生产错误开始快速填充文档时，文档将被耗尽。

以下文档将帮助您设计后端并带来可扩展性。

https://docs.mongodb.com/ecosystem/use-cases/storing-log-data/

【讨论】：