Блог

Главная - Вопросы по программированию - Как двойная запись в Yaml анализируется ElasticSearch?

Как двойная запись в Yaml анализируется ElasticSearch?

#elasticsearch

#elasticsearch

Вопрос:

Меня попросили исследовать проблемы с производительностью в кластере ElasticSearch, и я столкнулся со следующей конфигурацией:

 indices:
  breaker:
    fielddata:
      limit: 50%
    fielddata:
      cache:
        expire: 15m
        size: 40%
    memory:
      index_buffer_size: 50%

Обратите внимание, что есть две записи fielddata.

Что происходит fielddata.limit fielddata.cache.expire с fielddata.cache.size настройками и в приведенном выше сценарии по сравнению со следующим сценарием, который мне кажется более логичным?

 indices:
  breaker:
    fielddata:
      limit: 50%
      cache:
        expire: 15m
        size: 40%
    memory:
      index_buffer_size: 50%

Например, может fielddata.limit ли поле быть потеряно из-за того, что существует второе объявление fielddata уровня?

Ответ №1:

Соответствующий раздел в спецификации YAML:

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

Следовательно, опубликованный вами YAML просто незаконен, и совместимый загрузчик должен остановиться с ошибкой — однако, поскольку равенство узлов нетривиально, оно не реализовано в реализации YAML, используемой в ElasticSearch (SnakeYaml), которая также имеет открытую проблему, касающуюся дубликатов ключей.

Поскольку ElasticSearch, похоже, допускает дублирование ключей, он не соответствует спецификации YAML. Это плохо, и я советую открыть проблему для этого. Что еще более важно, поведение ElasticSearch не может быть выведено из используемой реализации YAML. У него есть история дубликатов ключей, и есть заявление от одного из разработчиков:

Кроме того, следующая основная версия elasticsearch будет иметь строгий синтаксический анализ настроек и возвращать ошибку при запуске, если это произойдет.

Подводя итог: ElasticSearch, не выдающий ошибку для дубликатов ключей, является известным недостатком и будет исправлен в следующем крупном выпуске. Поэтому текущее поведение является непреднамеренным и не должно использоваться. Согласно связанной ошибке, значения последнего значения для повторяющегося ключа выигрывают, а предыдущие будут отброшены. Слияния дочерних сопоставлений не произойдет.