【问题标题】:Analyze Mongo oplog for "biggest" queries分析 Mongo oplog 的“最大”查询
【发布时间】:2018-12-23 19:35:27
【问题描述】:

问题:有没有办法知道集合中样本文档的实际大小(即 oplog)?

我的 oplog 对于数据来说似乎太小了。我知道哪些查询可能是最大的贡献者,但我想在这样做之前评估减少查询的影响。

这里有一些上下文:

> rs.printReplicationInfo()
configured oplog size:   990MB
log length start to end: 280secs (0.08hrs)
oplog first event time:  Mon Jul 16 2018 09:18:16 GMT+0000 (GMT)
oplog last event time:   Mon Jul 16 2018 09:22:56 GMT+0000 (GMT)
now:                     Mon Jul 16 2018 09:22:56 GMT+0000 (GMT)

> db.getCollection('oplog.rs').stats()
count: 4374

PS:平均每个文档 250kb 似乎太多了,不是吗?

提前谢谢你!

【问题讨论】:

  • Hardik,它提供的信息似乎与rs.printReplicationInfo() 提供的信息有些相似。找到here 一个例子,并挑选了一个我感兴趣的操作文档。我想它回答了这个问题,文档大约是3M ......哎呀!他们 mongo 数组更新...
  • OpLog 不包括查询! OpLog 中只有添加、更改或删除数据的 DML 操作。要查看查询的大小,您需要使用命令db.setProfilingLevel(0,-1) 启用对 mongod.log 的分析
  • JJussi,我对 oplog 文档的大小(DML 操作或其他任何内容)非常感兴趣。它们本身不是查询,因为它们是写入操作,而不是读取,可能使用了错误的词,但我希望现在这个想法很清楚。我需要知道这些操作占用了多少空间才能找到可以优化的操作(例如,由于 oplog 的幂等性,推送到 60k 长度的数组在这方面真的很糟糕)

标签: mongodb replicaset mongodb-oplog


【解决方案1】:

SO answer 基本上涵盖了如何获取文档的大小。

我根据自己的推测挑选了一个文档,发现它的大小约为 3Mb。

不幸的是,只有对要查找的内容有任何线索,这才足够好。足以解决我的问题和主题中的问题。

不过,如果可以从集合中获取最大的文档,那就太好了。

【讨论】:

    猜你喜欢
    • 2017-08-07
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-03-04
    • 2017-07-17
    • 1970-01-01
    • 2023-03-20
    • 1970-01-01
    相关资源
    最近更新 更多