准确计数桶中的物品

Question

couchbase管理控制台(我正在使用5.0版本，社区)显示了每个桶中的项目计数。我想知道这个计数是否只是粗略的估计，而不是桶中物品数量的准确计数。下面是我所看到的行为，让我得出这样的推论：

• 当我使用XDCR将桶复制到备份节点时，XDCR完成后备份桶中的计数将显著高于源桶中的文档计数，有时会增加数万(在包含数亿个文档的桶中)。
• 当我使用Java客户端将一个桶克隆到另一个数据库的表中时，另一个数据库显示接近的记录数，但可能有几百万条记录(同样，在一个有数亿个文档的桶中)。

如何准确计算桶中项目的确切数量，以便在DCP或XDCR处理完成后，确保所有文档都已到达新位置？

Answer 1

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

不幸的是，当我们尝试普通的select count(*) from <bucket>;时，我们收到的文档计数仅超出了我们预期的1，所以我们对查询进行了分解，并对桶中的所有文档执行了一个count，而group则使用了一个属性，希望找到目标DB中缺少哪种文档。每个组的计数总数应该与从计数查询中得到的总数相同。不幸的是，他们没有。总计比我们预期的少了一个(因此从原始的计数查询中减去了两个)。

我们发现文档类别为1，期望Couchbase中有一个额外的文档，它没有到达目标DB，而是发现总数表示相反，目标DB有一个额外的文档。这一切看起来都很可疑，所以我们执行了一个查询，将该组中的所有did提取到一个JSON文件中，并对它们进行了计数。唉，该组中文档的实际计数与目标DB匹配，这意味着Couchbase的计数在这两种情况下都是不正确的。

我不知道是什么实现细节导致了这种情况的发生，但似乎至少过多的计算可能是一个缓存问题。通过使用这样的查询，我终于能够获得正确的文档计数：

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

这个查询运行的时间比原来的计数要长得多，这表明任何用于计数的缓存都被跳过了，并得到了正确的编号。

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

我们刚刚完成了整桶的同步。仪表板和原始N1ql查询报告的桶总数比预期计数高7。我们运行修改后的查询，等待结果，并得到预期的计数。

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

Answer 2

如果没有更多的细节，可能会有很多不同的原因来解释为什么会有不同的情况。常见的情况是：

couchbase管理控制台(我正在使用5.0版本，社区)显示了每个桶中的项目计数。

管理控制台是准确的，但不自动更新，因此需要刷新。

当我使用Java客户端将一个桶克隆到另一个数据库的表中时，另一个数据库显示接近的记录数，但可能有几百万条记录(同样，在一个有数亿个文档的桶中)。

DCP将包括墓碑(已删除的文档)，并可能包含同一文档的多个突变。这就可以解释为什么DCP计数不存在了。

关于使用N1QL，如果查询是一个简单的SELECT COUNT(*) FROM bucketName，那么取决于Couchbase版本，它将直接使用桶统计数据。

换句话说，如前所述，桶通过REST接口或直接询问数据服务的统计数据将是准确的。

Answer 3

最准确的答案将是直接进入桶信息，类似于

curl http://hostname:8091/pools/default/buckets/beer-sample/ -u user:password | jq '.basicStats | {itemCount: .itemCount }'

其结果是立即不需要编制索引：

{
  "itemCount": 7303
}

或不采用Json格式

curl http://centos:8091/pools/default/buckets/beer-sample/ -u roi:password | jq '.basicStats.itemCount'