如果想要计算索引(Elasticsearch)中的文档数量,那么(至少?)有两种可能性:
直接count
POST my_index / _count
应返回my_index
。
使用search
此处可以使用count
作为search_type
或其他类型。在任何一种情况下,总计数都可以从字段['hits']['total']
我的问题是:
不同方法有什么区别?哪一个 我应该更喜欢吗?
我提出这个问题是因为我遇到了不同的结果 取决于所选择的方法。我现在正在调试过程中 这个问题,这个问题突然出现了。
答案 0 :(得分:30)
可能_count
有点快,因为它不必执行带有排名和结果获取的完整查询,并且可以简单地返回大小。
了解更多关于如何设法获得不同结果的信息会很有趣。为此,我需要更多信息,例如您发送的确切查询以及索引上是否正在进行索引。
但假设您执行以下操作
_search
和_count
(匹配所有查询)应返回相同的总数。如果没有,那就非常奇怪了。
答案 1 :(得分:10)
如果必须使用_search
而不是_count
,并且您使用的是Elasticsearch 7.0+,则设置size: 0
和track_total_hits: true
将提供与{{1 }}
_count
答案 2 :(得分:6)
古老的问题,因为在ElasticSearch版本> 7.0上才出现:
_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”:[...]}}
_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”字段上执行聚合术语。
结果应该是一样的。在比较结果之前,请务必执行索引刷新。