mongodb - 在 MongoDB 中，最大化每日日志文档写入性能的策略

Question

我们有一个日志数据集合，其中集合中的每个文档都由一个 MAC 地址和一个日历日标识。基本上:

{
  _id: <generated>,
  mac: <string>,
  day: <date>,
  data: [ "value1", "value2" ]
}

每五分钟，我们将一个新的日志条目附加到当天文档中的数据数组中。当我们为每个 MAC 创建一个新文档时，该文档会在 UTC 午夜翻转。

我们注意到，以写入字节数衡量的 IO 全天都在增加，然后在 UTC 午夜回落。这不应该发生，因为日志消息的速率是恒定的。我们认为意外行为是由于 Mongo 移动了文档，而不是更新了它们的日志数组。对于它的值(value)，stats() 显示 paddingFactor 是 1.0299999997858227。

几个问题:

1. 有没有办法确认 Mongo 是在原地更新还是在移动？我们在慢查询日志中看到了一些 Action ，但这似乎是轶事证据。我知道我可以db.setProfilingLevel(2)，然后db.system.profile.find()，最后寻找"moved:true"，但我不确定是否可以在繁忙的生产系统上执行此操作。
2. 每个文档的大小都非常可预测且有规律。假设 mongo 做了很多 Action ，那么找出为什么 Mongo 不能更准确地预置大小的最佳方法是什么？还是让 Mongo 更准确地预置大小？假设上面对问题的描述是正确的，调整填充因子似乎并不能解决问题。
3. 对我来说，预先调整文档大小并消除 Mongo 的任何猜测应该很容易。 (我知道 padding factor 文档说我不应该这样做，但我只需要把这个问题抛在脑后。)预置文档大小的最佳方法是什么？用垃圾字节数组字段编写文档似乎很简单，然后立即从文档中删除该字段，但有什么我应该注意的问题吗？例如，我可以想象在删除垃圾字段之前必须在服务器上等待写入操作(即执行安全写入)。
4. 我担心会同时预分配一天中的所有文档，因为当时这似乎会使磁盘饱和。这是一个有效的担忧吗？我是否应该尝试将预分配成本分摊到前一天？

Answer 1

以下组合似乎会导致写入性能一落千丈:

1. 日记功能已开启。
2. 将附加条目写入构成较大文档主体的数组

大概 I/O 变得饱和。改变这些因素中的任何一个似乎都可以防止这种情况发生:

1. 关闭日记功能。改为使用更多副本。
2. 使用较小的文档。请注意，此处的文档大小以字节为单位，而不是文档中任何数组的长度。
3. 独立文件系统上的日志。

此外，这里还有一些其他提高写入吞吐量的技巧。除了分片，我们发现改进是渐进式的，而我们试图解决“这根本不起作用”的问题，但我将它们包括在这里，以防你正在寻找渐进式改进. 10 代人 did some testing and got similar results :

1. 分片。
2. 将长数组分解为多个数组，使您的整体结构看起来更像一棵嵌套树。如果使用一天中的小时作为键，则每日日志文档变为:
   {"0":[...], "1":[...],..., "23":[...]}.
3. 尝试手动预分配。 (这对我们没有帮助。Mongo 的填充似乎像宣传的那样工作。我最初的问题被误导了。)
4. 尝试不同的 --syncdelay 值。 (这对我们没有帮助。)
5. 尝试不使用安全写入。 (我们已经为日志数据这样做了，在很多情况下这是不可能的。而且，这似乎有点作弊。)

您会注意到，我在这里复制了 10Gen 的一些建议，只是为了完整起见。希望我做得很准确!如果他们发布食谱示例，那么我将在此处发布链接。