使用Elasticsearch计算文档数量

时间:2014-09-09 08:26:31

标签: elasticsearch

如果想要计算索引(Elasticsearch)中的文档数量,那么(至少?)有两种可能性:

  • 直接count

    POST my_index / _count

    应返回my_index

  • 中的文档数量
  • 使用search

    此处可以使用count作为search_type或其他类型。在任何一种情况下,总计数都可以从字段['hits']['total']

  • 中提取

我的问题是:

  • 不同方法有什么区别?哪一个 我应该更喜欢吗?

  • 我提出这个问题是因为我遇到了不同的结果 取决于所选择的方法。我现在正在调试过程中 这个问题,这个问题突然出现了。

5 个答案:

答案 0 :(得分:30)

可能_count有点快,因为它不必执行带有排名和结果获取的完整查询,并且可以简单地返回大小。

了解更多关于如何设法获得不同结果的信息会很有趣。为此,我需要更多信息,例如您发送的确切查询以及索引上是否正在进行索引。

但假设您执行以下操作

  1. 索引一些文件
  2. 刷新索引
  3. _search_count(匹配所有查询)应返回相同的总数。如果没有,那就非常奇怪了。

答案 1 :(得分:10)

如果必须使用_search而不是_count,并且您使用的是Elasticsearch 7.0+,则设置size: 0track_total_hits: true将提供与{{1 }}

_count

请参见Elasticsearch 7.0 Breaking changes

答案 2 :(得分:6)

古老的问题,因为在ElasticSearch版本> 7.0上才出现:

  1. _search:返回搜索查询的命中数小于或等于结果窗口大小(通常为10,000)的文档。例如:

    {“ took”:3,“ timed_out”:false,“ _ shards”:{“ total”:1,“ successful”:1,“ skipped”:0,“ failed”:0},“ hits”: {“ total”:{“ value”:10000,“ relation”:“ gte”},“ max_score”:0.34027478,“ hits”:[...]}}

  2. _count:无论结果窗口大小如何,都返回搜索查询的总点击数。没有文件退回,例如:

    {“ count”:5703899,“ _ shards”:{“ total”:1,“ successful”:1,“ skipped”:0:“ failed”:0}}}

因此,_search可能返回的总匹配数为10,000(如果这是您配置的结果窗口大小),而_count将返回相同查询的实际计数。

答案 3 :(得分:4)

curl http://localhost:9200/_cat/indices?v以表格形式为您提供计数和其他信息

health status index                              uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   logstash-2019.10.09-000001         IS7HBUgRRzO7Rn1puBFUIQ   1   1          0            0       283b           283b
green  open   .kibana_task_manager_1             e4zZcF9wSQGFHB_lzTszrg   1   0          2            0     12.5kb         12.5kb
yellow open   metricbeat-7.4.0-2019.10.09-000001 h_CWzZHcRsakxgyC36-HTg   1   1       6118            0      2.2mb          2.2mb
green  open   .apm-agent-configuration           J6wkUr2CQAC5kF8-eX30jw   1   0          0            0       283b           283b
green  open   .kibana_2                          W2ZETPygS8a83-Xcd6t44Q   1   0       1836           23      1.1mb          1.1mb
green  open   .kibana_1                          IrBlKqO0Swa6_HnVRYEwkQ   1   0          8            0    208.8kb        208.8kb
yellow open   filebeat-7.4.0-2019.10.09-000001   xSd2JdwVR1C9Ahz2SQV9NA   1   1          0            0       283b           283b
green  open   .tasks                             0ZzzrOq0RguMhyIbYH_JKw   1   0          1            0      6.3kb          6.3kb

答案 4 :(得分:2)

这两个查询提供相同的结果,但是: - count消耗较少的资源/带宽,因为不需要获取文档,评分和其他内部优化。将搜索大小设置为0,可能非常相似。

如果要计算索引中的所有记录,还可以在“_type”字段上执行聚合术语。

结果应该是一样的。在比较结果之前,请务必执行索引刷新。