Question

couchbase管理控制台（我使用的是5.0版社区）显示每个存储桶中的项目数。我想知道该计数是否只是一个粗略的估计，而不是存储桶中物品数量的准确计数。这是我所看到的行为，这导致我进行以下推理：

当我使用XDCR将存储桶复制到备份节点时，XDCR完成后，备份存储桶中的计数将显着高于源存储桶中的文档数，有时会成千上万（在存储桶中）包含数亿个文档）。
当我使用Java DCP客户端将存储桶克隆到其他数据库中的表时，另一个数据库显示的记录数量接近，但可能相差几百万（同样，在具有数百个存储桶的存储桶中）数百万个文档）。

如何准确计算存储桶中的确切项目数，以确保在完成DCP或XDCR流程后，所有文档都已移至新位置？

Answer 1

There can be a number of different reasons why the count could be different without more details it would be hard to say. The common cases are:

The couchbase admin console (I'm using version 5.0, community) shows a count of items in each bucket.

The Admin console is accurate but does not auto updated, so a refresh is required.

When I use the Java DCP client to clone a bucket to a table in a different database, the other database shows numbers of records that are close, but off by possibly even a few million (again, in a bucket with hundreds of millions of documents).

DCP will include tombstones (deleted documents) and possibly multiple mutations for the same document. Which could explain why the DCP count is out.

With regards to using N1QL, if the query is a simple SELECT COUNT(*) FROM bucketName then depending on the Couchbase Server version it will use the bucket stats directly.

In other words as mentioned previously the bucket stats via the REST interface or by asking the Data service directly will be accurate.

Answer 2

最准确的答案是直接转到存储桶信息像

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'

Answer 3

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

不幸的是，当我们尝试正常的select count(*) from <bucket>;时，我们收到的文档数仅比我们预期的多1，因此我们中断了查询，并对存储桶中的所有文档进行了count的搜索，而{ {1}}通过属性，希望找到目标数据库中缺少哪种类型的文档。每一组的计数总计应与从计数查询中获得的总数相加。不幸的是，他们没有。总数总计比我们预期的要少1个（因此与原始计数查询相比减少了2个）。

我们发现文档类别减少了1，期望在Couchbase中有一个额外的文档没有到达目标数据库，但是发现总数却相反，目标数据库只有一个文档额外文件这一切似乎都很混乱，因此我们进行了查询，以将该组中的所有ID提取到单个JSON文件中，并对它们进行了计数。 las，该组中的实际文档数与目标数据库匹配，这意味着在两种情况下Couchbase的计数都是不正确。

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

group

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

我们正在对相对少量的文档（大约一百万个）进行这些测试。在整个存储桶中，过去的计数减少了多达15个，随着文件计数的增加，准确性显然下降了。

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

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

Answer 4

要获得准确的计数，可以运行N1QL查询。这将使您获得Couchbase能够产生的准确数字。

SELECT COUNT(*) FROM bucketName

使用REQUEST_PLUS一致性来确保索引已收到最新更新。

https://developer.couchbase.com/documentation/server/current/indexes/performance-consistency.html

不过，您将需要一个查询节点。

获取桶中物品的准确计数

4 个答案: