在MongoDB中,最大化日常日志文件写入性能的策略

我们收集了日志数据,集合中的每个文档都通过MAC地址和日历日标识.基本上:

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

每五分钟,我们在当天的文档中附加一个新的日志条目到数据数组.当我们为每个MAC创建一个新的文档时,文档在UTC的午夜翻滚.

我们注意到,以字节为单位测量的IO全天增加,然后在UTC的午夜时间下降.这不应该发生,因为日志消息的速率是不变的.我们认为意外的行为是由于Mongo移动的文档,而不是更新它们的日志数组.为什么值得,stats()显示paddingFactor是1.0299999997858227.

几个问题:

有没有办法确认Mongo是在更新到位还是移动?我们在慢查询日志中看到一些动作,但这似乎是一个轶事.我知道我可以db.setProfilingLevel(2),然后db.system.profile.find(),最后找到“moved:true”,但我不知道在繁忙的生产系统上这样做是否可以.
>每个文件的大小是非常可预测和规则的.假设mongo正在做很多动作,最好的办法是弄清楚为什么Mongo不能准确地预测呢?还是让蒙古更准确地预告?假设上述问题的描述是正确的,调整填充因子似乎不会这样做.
>我应该很容易地预定文件,并从Mongo中删除任何猜测. (我知道padding factor文档说我不应该这样做,但我只需要把这个问题放在我的身后.)什么是最好的方式来预定一个文件?用垃圾字节数组字段写一个文档看起来很简单,然后立即从文档中删除该字段,但是我有什么需要注意的问题?例如,我可以想象,在删除垃圾字段之前,必须等待服务器进行写入操作(即进行安全写入).
>我担心大约在同一时间内预分配一天的文件,因为这样会使磁盘饱和.这是一个有效的关注点吗?我应该尝试在前一天分散预先分配费用吗?

以下组合似乎会导致写入性能落在悬崖上:

>日记功能开启
>将附加条目附加到构成较大文档大部分的数组中

推测I / O饱和.改变这些因素似乎阻止这种情况发生:

>关闭日记帐.使用更多的副本代替.
>使用较小的文件.请注意,这里的文档大小以字节为单位,而不是文档中任何数组的长度.
>日志在一个单独的文件系统.

另外,这里还有一些提高写入吞吐量的技巧.除了分片之外,我们发现改进是增量的,而我们试图解决一个“这根本不起作用”的问题,但是我将它们包括在这里,以防您在寻求增量改进. 10Gen人did some testing and got similar results

>碎片
将长阵列分解成几个数组,使整体结构看起来更像一个嵌套树.如果你使用一天中的小时作为关键,那么每日日志文件将变为:{“0”:[…],“1”:[…],…,“23”:[.. ]}.
>尝试手动预分配. (这没有帮助我们,Mongo的填充似乎像广告一样工作,我原来的问题被误导了.)
>尝试不同的–syncdelay值. (这没有帮助我们.)
>尝试没有安全的写入. (我们已经在做这个日志数据了,在许多情况下是不可能的,而且这似乎是一个骗子.)

你会注意到,我已经从10Gen中复制了一些建议,只是为了完整.希望我做得如此准确!如果他们发布食谱示例,那么我将在这里发布一个链接.

相关文章
相关标签/搜索