Необходимость моделирования

Когда вы индексируете документы в новый индекс, Elasticsearch динамически создает для вас сопоставление (mapping). Если вы проверите сопоставление, созданное для индексов блогов и журналов, вы заметите, что большинство полей сопоставлены с текстом и ключевым словом.

Немного подробнее про сопоставление можно почитать тут и тут.

Комплексные исправления

При некоторых ситуациях стоит задуматься о правильном дизайне вашего индекса. Например поле "location": "KZ,Almaty" будет проиндексировано как строка. Но для быстрого и легкого поиска правильней было бы его разбить на массив.

Или допустим у вас существует поле с типом строка, где у вас записано множество информации о запросе клиента через браузер, например, версия ос, версия браузера, ip адрес и т.д. Наличие всей этой разной информации в одном и том же поле затрудняет поиск. Вам нужно разложить эту строку на более гранулярные поля (granular fields).

Для примера правильного использования гранулярные полей рассмотрим пример с полем, в котором указывается версия ОС os_version: "5.4.13". Теперь представим, что вам нужно найти все документы с версией ОС 5.3.х. Скорее всего вы используете регулярные выражения и это не самый простой выход.

Проще всего было бы разбить это поле на 3 поля: major, minor, bugfix.

PUT my-index
{
  "mappings": {
    "properties": {
      "version":{
        "properties": {
          "display_version": {
            "type": "keyword"
          },
          "major": {
            "type": "byte"
          },
          "minor": {
            "type": "byte"
          },
          "bugfix": {
            "type": "byte"
          }
        }
      }
    }
  }
}

Теперь благодаря такому mapping мы можем упростить получение документов:

PUT my-index/_doc/1 
{
  "version": {
    "display_version": "5.3.23",
    "major": 5,
    "minor": 3,
    "bugfix": 23
  }
}

GET my-index/_search
{
  "query": {
    "bool": {
      "filter": [
        { "match": { "version.major": 5 } },
        { "match": { "version.minor": 3 } }
      ]
    }
  }
}

Общая схема (Common Schema)

Elastic Common Schema (ECS) - это спецификация с открытым исходным кодом, которая определяет общий набор полей документа для данных, загружаемых в Elasticsearch. ECS разработан для поддержки единообразного моделирования данных, что позволяет централизованно анализировать данные из различных источников с помощью как интерактивных, так и автоматизированных методов, обеспечивая при этом большую гибкость для добавления настраиваемых полей при необходимости.

Спецификация ECS определяет два уровня полей:

  1. Поля ECS Core - представляют поля, которые наиболее распространены во всех случаях использования, и вам следует сосредоточиться на заполнении этих полей в первую очередь
  2. Поля ECS Extended - представляет любые поля, которые не являются частью основных полей, и они используются гораздо реже

Набор полей

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

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

Следуйте данным рекомендациям при создании индексов:

  • В документе должно быть поле @timestamp.
  • Вам необходимо сопоставить как можно больше полей с правилами ECS
  • Убедитесь, что имена полей в нижнем регистре
  • Вам нужно использовать подчеркивание, если вы хотите комбинировать слова (os_version)
  • Не используйте другие специальные символы, кроме подчеркивания, в названиях полей.
  • Используйте префиксы для всех полей (<fieldset> .fieldname), кроме базовых полей
  • Избегайте повторения слов (os.os_version -> os.version)
  • По возможности избегайте сокращений

Следуйте этим рекомендациям при определении типа ваших полей:

  • Целые числа обычно определяются как длинные (long)
  • Несмотря на то, что идентификаторы и большинство кодов часто являются целыми числами, это не всегда так O_O.

Использование псевдонимов (alias)

Может случится так что документы, которые были ранее проиндексированы, и новые документы будут иметь разные поля (например user_id,user-id,ids). Поэтому у вас возникнут проблемы с созданием визуализаций и информационных панелей для всех ваших документов. Одним из решений может быть переиндексация ваших старых документов, но это может занять много времени. Другое решение - использовать псевдоним типа данных (alias).

Тип данных псевдонима определяет альтернативное имя для поля в индексе, которое помогает создавать запросы или агрегаты для одного имени поля.

Создание псевдонима должно соответствовать следующим требованиям:

  • Это должно быть конкретное поле (не объект или псевдоним)
  • Поле должно существовать на момент создания псевдонима.

Поле псевдонима (alias) невозможно удалить.

Пример использования:

POST my-index/_mapping
{
  "properties": {
      "version":{
        "properties": {
          "d_v": {
            "type": "alias",
            "path": "version.display_version"
          }
        }
      }
  }
}

GET my-index/_search
{
  "query": {
    "bool": {
      "filter": [
        { "match": { "version.d_v": "5.3.23" } }
      ]
    }
  }
}

В итоге

  • Тщательное моделирование данных позволяет получить от них максимальную отдачу
  • ECS разработан для поддержки единообразного моделирования данных и определяет имена полей и типы данных
  • Псевдоним (alias) позволяет вам определить альтернативное имя для поля в индексе.