获取桶中物品的准确计数

Question

couchbase管理控制台(我使用的是5.0版本,社区)显示了每个存储桶中的项目数.我想知道这个数字是否只是一个粗略估计而不是桶中物品数量的精确计数.这是我看到的行为导致我这样的推理:

• 当我使用XDCR将存储桶复制到备份节点时,XDCR完成后备份存储桶中的计数将显着高于源存储桶中的文档数量,有时会高达数万个(在包含数百个存储桶的存储桶中)数以百万计的文件).
• 当我使用Java DCP客户端将存储桶克隆到另一个数据库中的表时,另一个数据库会显示已关闭的记录数,但可能甚至几百万(相反,在包含数亿个文档的存储桶中) ).

如何准确计算存储桶中的确切项目数,以便在我的DCP或XDCR流程完成后,我可以确定所有文档都已到达新位置？

Answer 1

好吧，一年多后我在这里回答我自己的问题:)。今天，我们在尝试将包含大约 260 万个项目的存储桶中的项目迁移到 SQL 数据库时进行了大量实验。我们希望在上线之前确保 Couchbase 和新数据库之间的行数匹配。

不幸的是，当我们尝试正常时，select count(*) from <bucket>;我们收到的文档计数超出了我们的预期，仅增加了 1 个，因此我们分解了查询，并在按属性进行查询count时对存储桶中的所有文档group进行了检查，希望找到丢失的文档类型在目标数据库中。每个组的计数总数应该与我们从计数查询中获得的总数相同。不幸的是，他们没有。总数比我们预期的少1 （因此与原始计数查询相比减少了 2）。

我们发现偏离 1 的文档类别，预计 Couchbase 中会有一个额外的文档没有到达目标数据库，但发现总数表明相反，目标数据库有一个额外的文档。这一切看起来都很可疑，所以我们做了一个查询，将该组中的所有 ID 提取到一个 JSON 文件中，并对它们进行了计数。可惜的是，该组中文档的实际计数与目标数据库相匹配，这意味着 Couchbase 的计数在这两种情况下都是不正确的。

我不确定是什么实现细节导致了这种情况的发生，但看起来至少过度计数可能是一个缓存问题。我最终能够通过使用如下查询获得正确的文档计数：

select count(*) from <bucket> where meta(<bucket>).id;

该查询的运行时间比原始计数长得多，这表明用于计数的任何缓存都被跳过，并且它确实得出了正确的数字。

我们对相对较少的文档（大约 50 万份）进行这些测试。在桶满了的情况下，计数在过去最多减少了 15 个，显然随着文档计数的增加而变得不那么准确。

我们刚刚重新同步了整个存储桶。仪表板和原始 N1ql 查询报告的存储桶总数超出预期计数 7。我们运行修改后的查询，等待结果，并获得预期计数。

如果您想知道，我们确实关闭了存储桶的流量，因此在此过程中文档计数不太可能波动，除非文档在 Couchbase 中达到其到期日期并被自动删除。