Mongo Changestream 获取更多分析

Question

在调查 Atlas 托管数据库上的性能问题时，我们开始观察到 Atlas 分析器中返回的文档数量很高。如此大量的返回文档是游标的changestream

getMore

调用的结果，我们有时会看到返回文档的数量达到超过5000条记录。我们知道我们没有做出那么多改变，并且想知道什么可以解释返回的大量记录。这个数字是从光标建立起的累计计数吗？

Answer 1

来自评论：

这里唯一的问题是该数字是否是累积的？ 是的，就是这个问题。

不，您屏幕截图中的数字是不是累积的。

您的屏幕截图来自 Atlas profiler。 Atlas 分析器文档 以及您对与

getMore

调用关联的屏幕截图的引用都表明我们正在查看单个操作的结果。

有点相关的是，该屏幕截图中的

Response Length

字段对应于 操作的

reslen

。同样，这是该单个调用传输的数据量。每批次传输的数据有 16MB 的硬上限，因此返回的文档大小会影响单批次发送的文档数量。

但是，经过我自己的研究，这个数字似乎可以累积。我开始监视本地 mongo 数据库，并对集合进行更改，以查看运行 db.currentOp({ns:"{dbname}.$cmd"}); 的结果。会回来的。 nDocsReturned 值似乎正在计算更新的数量。如果不是累积的，你如何解释？

感谢您提供额外的背景信息！您在这里看到的是“不同”的东西，尽管这是混乱和错误结论的根源。

在此界面中，被报告的对象是

光标本身。 cursor 是在执行查询（包括更改流）时创建的对象，并将返回多于一批数据。

正如您所得出的正确结论，该界面中的

nDocsReturned

 指标是针对光标累积的。 

文档证实了这一点：

光标返回的文档累计数量。

紧接着该页面还通知我们有关nBatchesReturned

：

currentOp.cursor.nBatchesReturned

光标返回的累计批次数。

因此，每个

getMore

调用

都会添加到这些累积游标总数中，可以在currentOp

中观察到。但日志文件和分析器只会报告与 

individual getMore

 执行相关的指标（在这些地方报告的速度足够慢）。

我们知道我们没有做出那么多改变

听起来要么正在进行的更改比您预期的要多，要么（重新）打开的更改流比预期更频繁（或者没有适当地使用“之后恢复”功能）。