Почему термин «размер сегмента» влияет на значение doc_count внутренних агрегаций reverse_nested? - PullRequest
0 голосов
/ 30 ноября 2018

Я пытался отследить недостающее количество документов из обратного вложенного агрегата.

Мой запрос

"aggs": {
    "mainGrouping": {
      "nested": {
        "path": "parent.child"
      },
      "aggs": {
        "uniqueCount": {
          "cardinality": {
            "field": "parent.child.id"
          }
        },
        "groupBy": {
          "terms": {
            "field": "parent.child.id",
            "size": 20,  <- If I change this, my doc count for noOfParents changes
            "order": [
              {
                "noOfParents": "desc"
              }
            ]
          },
          "aggs": {
            "noOfParents": {
              "reverse_nested": {}
            }
          }
        }
      }
    }

Итак, я выполнял его на size:20.У меня было одно ведро, которое вернуло noOfParents из 7, когда я знаю, что должно быть 9 совпадений.Я случайно заметил, что если я изменю размер агрегации терминов на 50, noOfParents правильно отображал 9 для этого сегмента.

Почему размер агрегации терминов влияет на doc_count обратной агрегации?Это ожидаемое поведение или ошибка?Я использую эластичный поиск 5.6.

1 Ответ

0 голосов
/ 01 декабря 2018

То, что вы наблюдаете, - это, скорее всего, нормальное поведение агрегации terms, поскольку количество документов приблизительное .Это не относится ни к reverse_nested, ни к nested агрегатам.

Короче говоря, поскольку данные распределяются по осколкам, Elasticsearch делает наилучшие предположения сначала локально для каждого осколка, а затем объединяет результат по осколкам.Для лучшего, более подробного объяснения, пожалуйста, посмотрите этот раздел документации .

Чтобы убедиться, что это действительно так, вы можете добавить агрегацию top_hits с включенным explain:

      "aggs": {
        "noOfParents": {
          "reverse_nested": {},
          "aggs": {
            "top hits": {
              "top_hits": {
                "size": 10,
                "explain": true
              }
            }
          }
        }
      }

Это даст вам список совпавших родительских документов с их идентификационными номерами.Примерно так:

  "aggregations": {
    "mainGrouping": {
      ...
      "groupBy": {
        ...
        "buckets": [
          {
            "key": "1",
            "doc_count": 5,
            "noOfParents": {
              "doc_count": 5,
              "top hits": {
                "hits": {
                  "total": 5,
                  "max_score": 1,
                  "hits": [
                    {
                      "_shard": "[my-index-2018-12][0]", <-- this is the shard
                      "_node": "7JNqOhTtROqzQR9QBUENcg",
                      "_index": "my-index-2018-12",
                      "_type": "doc",
                      "_id": "AWdpyZ4Y3HZjlM-Ibd7O",
                      "_score": 1,
                      "_source": {
                        "parent": "A",
                        "child": {
                          "id": "1"
                        }
                      },
                      "_explanation": ...
                    },

Еще один способ доказать, что это является источником проблемы, - изолировать запрос в пределах одного сегмента.Для этого достаточно добавить маршрутизацию к поисковому запросу: ?routing=0

Это сделает ваши подсчеты terms ведра стабильными в пределах одного шарда.Затем сравните noOfParents с ожидаемым количеством родителей (опять же, в пределах одного и того же шарда).

Надеюсь, это поможет!

...