› › ›

Агрегация Cardinality

Агрегация метрик, которая рассчитывает приблизительное количество уникальных значений.

Представьте, что вы индексируете продажи магазинов и хотите подсчитать количество уникальных проданных продуктов, соответствующих запросу:

POST /sales/_search?size=0
{
  "aggs": {
    "type_count": {
      "cardinality": {
        "field": "type"
      }
    }
  }
}

Ответ:

{
  ...
  "aggregations": {
    "type_count": {
      "value": 3
    }
  }
}

Управление точностью

Эта агрегация также поддерживает параметр precision_threshold:

POST /sales/_search?size=0
{
  "aggs": {
    "type_count": {
      "cardinality": {
        "field": "type",
        "precision_threshold": 100 
      }
    }
  }
}

Параметр precision_threshold позволяет обменять память на точность и определяет количество уникальных значений, ниже которого подсчеты ожидаются точными. Выше этого значения подсчеты могут быть несколько приближенными. Максимально поддерживаемое значение — 40000; пороги выше этого числа будут иметь тот же эффект, что и порог 40000. Значение по умолчанию — 3000.

Подсчеты являются приблизительными

Вычисление точных значений требует загрузки значений в набор хешей и возвращения его размера. Это не масштабируется при работе с наборами высокой кратности и/или большими значениями, поскольку требуемое использование памяти и необходимость обмена этими наборами между узлами будут потреблять слишком много ресурсов кластера.

Эта агрегация основана на алгоритме HyperLogLog++, который считает значения на основе хешей с некоторыми интересными свойствами:

настраиваемая точность, которая определяет, как обменивать память на точность,
отличная точность на наборах с низкой кратностью,
фиксированное использование памяти: независимо от того, десятки или миллиарды уникальных значений, использование памяти зависит только от настроенной точности.

Для порога точности c реализация, которую мы используем, требует около c * 8 байт.

На следующем графике показано, как изменяется ошибка до и после порога:

cardinality error

Для всех 3 порогов подсчеты были точными до настроенного порога. Хотя это не гарантируется, это, вероятно, так. Точность на практике зависит от набора данных. В целом, большинство наборов данных демонстрируют последовательно хорошую точность. Также обратите внимание, что даже при пороге 100 ошибка остается очень низкой (1-6%, как показано на графике выше) даже при подсчете миллионов элементов.

Алгоритм HyperLogLog++ зависит от ведущих нулей хешированных значений, точные распределения хешей в наборе данных могут влиять на точность подсчета кратности.

Предварительно вычисленные хеши

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

Предварительный расчет хешей обычно полезен только для очень больших и/или полей высокой кратности, так как он экономит ЦП и память. Однако для числовых полей хеширование очень быстро, а хранение исходных значений требует столько же или меньше памяти, чем хранение хешей. Это также справедливо для строковых полей с низкой кратностью, особенно учитывая оптимизацию, которая гарантирует, что хеши вычисляются не более одного раза на уникальное значение в каждом сегменте.

Скрипт

Если вам нужна кратность сочетания двух полей, создайте поле runtime, комбинирующее их, и агрегируйте его.

POST /sales/_search?size=0
{
  "runtime_mappings": {
    "type_and_promoted": {
      "type": "keyword",
      "script": "emit(doc['type'].value + ' ' + doc['promoted'].value)"
    }
  },
  "aggs": {
    "type_promoted_count": {
      "cardinality": {
        "field": "type_and_promoted"
      }
    }
  }
}

Пропущенное значение

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

POST /sales/_search?size=0
{
  "aggs": {
    "tag_cardinality": {
      "cardinality": {
        "field": "tag",
        "missing": "N/A" 
      }
    }
  }
}

Документы без значения в поле tag попадут в тот же бакет, что и документы со значением N/A.

© 2023-2025 Elasticsearch
As of September 2024, Elasticsearch is available under a choice of three licenses: the Server Side Public License (SSPL), the Elastic License, or the AGPLv3 (OSI approved).
Elasticsearch and the Elasticsearch logo are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries.
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/search-aggregations-metrics-cardinality-aggregation.html