Это может быть связано с тем, что ваши данные разбиты на несколько узлов (настройка кластера с несколькими узлами) без replicas
, и, возможно, один из узлов не работает во время выполнения поисковых запросов.
Например,
Если у меня есть кластер только с одним узлом, а узел имеет 1 index
с 4
documents
, я получу следующий вывод при проверке indices
,
health status index pri rep docs.count docs.deleted store.size pri.store.size
yellow open blog 5 1 4 0 10.9kb 10.9kb
Теперь, если я выполню match_all
запрос,
{
"query": {
"match_all": {}
}
}
Я получу,
{
"took": 3,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 4,
"max_score": 1,
"hits": [........
Обратите внимание, что docs.count
равно hits
count. В приведенном выше выводе обратите внимание на количество осколков, равное 5
. Все эти осколки назначены одному узлу.
Но если бы у меня была настройка нескольких узлов с replicas
, а не , эти сегменты будут распределены между несколькими узлами.
Предположим, что у меня есть кластер из двух узлов, имеющий Узел 1 и Узел 2 , всего 5 осколков, из этих 5 осколков осколок 0, 1, 3 были назначены на Узел 2 , и этот узел отключен для технического обслуживания или недоступен по какой-либо причине. В этом сценарии у вас есть только черепки 2
и 4
, доступные через Узел 1 . Теперь, если вы попытаетесь получить или найти данные, что произойдет? Elasticsearch предоставит вам результаты поиска с оставшегося в живых узла, то есть Node 1 .
Количество попаданий в этом случае всегда будет меньше значения docs.count
.
Такого рода неопределенности можно избежать с помощью реплик