Надпись

С листингом Elastic ELK Stack не только быстро развивался в крупных компаниях BAT, но и широко использовался в различных малых и средних компаниях, и даже «свадебные веб-сайты» начали использовать Elasticsearch. Далее следует, что статьи о развертывании, фреймворках и оптимизации производительности, связанные с Elasticsearch, уже давно перегружены.

У новичков даже возникнут галлюцинации: «Развертывание в один клик, импорт данных, извлечение и агрегирование, динамическое масштабирование, так просто, маме больше не нужно беспокоиться о моем обучении Elastic»!

Но на самом деле? Только для дизайна индекса Elasticsearch ответьте на следующие вопросы:

Как спроектировать терабайты или даже петабайты больших индексов с сотнями ГБ инкрементных данных в реальном времени каждый день?
Как спроектировать количество сегментов и реплик для повышения производительности кластера ES?
Как должен быть разработан картографический сервис ES, чтобы обеспечить эффективный поиск?
Есть так много типов поисковых типов / совпадение / совпадение / QueryString / Match_Phrase _Prefix / Fuzzy, как выбрать тип на этапе проектирования?
Как разработать сегментацию слов для удовлетворения потребностей сложных бизнес-сценариев?
Как многотабличные ассоциации в традиционных базах данных спроектированы в ES? ......

С этой точки зрения это не так просто, и яму все равно придется шаг за шагом вышагивать.

Как сказал Дядюшка ВУД, архитектор Ctrip: «Провести поиск легко, но сделать хороший поиск довольно сложно!»,

По словам архитектора поисковой системы VIVO, «знание ES — это далеко не успех в поиске!».

В этой статье, основанной на почти десятимиллионном опыте разработки автора, мы подробно обсудим структуру индекса Elasticsearch...

Важность дизайна индекса

Инженеры американской группы написали десять принципов, подчеркивающих сложный «приоритет дизайна». Многочисленные факты доказали, что игнорирование предварительного проектирования обычно сопряжено с большим риском расширения. А без оценки плохой проект принесет огромные затраты на техническое обслуживание, последнее должно было выделить время на оптимизацию и реконструкцию.

Elasticsearch все чаще становится предпочтительным решением для неструктурированных баз данных.Хороший дизайн и проверка на ранней стадии проекта являются обязательными, что может принести пользу всему проекту.

Дизайн на уровне индекса играет относительно легкую роль на этапе проектирования продуктов и проектов, связанных с Elasticsearch.

Хороший дизайн индекса играет ключевую роль во всем планировании кластера, а дизайн индекса напрямую влияет на качество и сложность дизайна кластера.
Хороший дизайн индекса должен быть спроектирован с полным рассмотрением временных и космических измерений бизнес-сценариев и полного рассмотрения сложения, удаления, модификации и поиска в сочетании с бизнес-сценариями.
Хороший дизайн индекса полностью основан на принципе "сначала дизайн, потом кодирование". На ранней стадии потребуется много времени, чтобы сделать дальнейшую работу более гладкой и избежать ненужных переделок.

1. Как разработать большой индекс на уровне PB?

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

Наша обычная операция:

Шаг 1: Создайте индекс;
Шаг 2: Импортируйте или запишите данные;
Шаг 3: Предоставьте доступ к запросу или службу запросов.

1.1 Дефекты больших индексов

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

1.1.1 Предельные размеры хранилища

Один сегмент (Shard) на самом деле является индексом Lucene. Максимальное количество документов, которое может храниться в одном сегменте, составляет: 2 147 483 519 (= Integer.MAX_VALUE - 128). Следующая команда может просмотреть размер документа сегментов с разделителями для всех индексов:

GET _cat/shardsapp_index                       2 p STARTED      9443   2.8mb 127.0.0.1 Hk9wFwUapp_index                       2 r UNASSIGNED                          app_index                       3 p STARTED      9462   2.7mb 127.0.0.1 Hk9wFwUapp_index                       3 r UNASSIGNED                          app_index                       4 p STARTED      9520   3.5mb 127.0.0.1 Hk9wFwUapp_index                       4 r UNASSIGNED                          app_index                       1 p STARTED      9453   2.4mb 127.0.0.1 Hk9wFwUapp_index                       1 r UNASSIGNED                          app_index                       0 p STARTED      9365   2.3mb 127.0.0.1 Hk9wFwUapp_index                       0 r UNASSIGNED

1.1.2 Параметр производительности

Конечно, если индекс большой, производительность записи данных и запросов ухудшится.

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

Например, поиск: данные «2019-02-01», предыдущий поиск будет осуществляться через месяц или даже больший индекс.

Теперь индекс эффективности прямого поиска "index_2019-02-01" увеличивается в несколько раз.

1.1.3 Аспект риска

При сбое большого индекса затрагиваются связанные данные. Если он разделен на скользящие индексы, это эквивалентно физической изоляции.

1.2 Дизайн и реализация индекса на уровне PB

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

index_2019-01-01-000001index_2019-01-02-000002index_2019-01-03-000003index_2019-01-04-000004index_2019-01-05-000005

1.2.1 Используйте шаблоны для единообразной настройки индексов

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

1.2.2 Индекс управления Rollver Delta

Цель: обновить индекс в соответствии с тремя параметрами даты, количества документов и размера хранилища документов. Пример использования:

POST /logs_write/_rollover {  "conditions": {    "max_age":   "7d",    "max_docs":  1000,    "max_size":  "5gb"  }}

1.2.3 Принцип инкрементного обновления индекса

Одна картинка стоит тысячи слов.

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

На этапе разработки шаблона индекса шаблон определяет глобальный псевдоним: цель — глобальный поиск, как показано в псевдониме: indexall. После каждого обновления нового индекса новый индекс указывает на псевдоним для записи новых данных в реальном времени, как показано на рисунке: indexlatest. Также удалите псевдоним index_latest старого индекса.

Псевдоним удален и новый Пример:

POST /_aliases{  "actions" : [      { "remove" : { "index" : "index_2019-01-01-000001", "alias" : "index_latest" } },      { "add" : { "index" : "index_2019-01-02-000002", "alias" : "index_latest" } }  ]}

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

1.2.4 Используйте куратор для эффективной очистки исторических данных

Цель: Периодически удалять и архивировать исторические данные по дате.

Метод удаления данных большого индекса может использовать только delete_by_query, потому что ES использует механизм обновления версии. После удаления индекса, поскольку физического удаления нет, информация, хранящаяся на диске, будет увеличиваться, а не уменьшаться. Некоторые студенты сообщили, что индекс delete_by_query размером более 500 ГБ вызвал увеличение нагрузки.

После индексации по дате ненужные исторические данные можно обработать следующим образом.

Удалить - соответствует операции удаления индекса.
Сжатие - соответствует операции сжатия.
Слияние сегментов — соответствует операции force_merge.

И всего этого можно добиться с помощью инструмента куратора через простой файл конфигурации в сочетании с определенной задачей crontab.

Примечание. Более позднюю версию 7.X проще реализовать с помощью iLM.

Например, удалить исторические данные 30 дней назад одним щелчком мыши:

  [root@localhost .curator]# cat action.yml   actions:      1:        action: delete_indices        description: >-          Delete indices older than 30 days (based on index name), for logstash-          prefixed indices. Ignore the error if the filter does not result in an          actionable list of indices (ignore_empty_list) and exit cleanly.        options:          ignore_empty_list: True          disable_action: False        filters:        - filtertype: pattern          kind: prefix          value: logs_        - filtertype: age          source: name          direction: older          timestring: '%Y.%m.%d'          unit: days          unit_count: 30

2. Как спроектировать количество шардов и реплик?

2.1 Сплит / Копировать познание

1. Разделение. Сам сегмент представляет собой полнофункциональный и независимый «индекс», который можно разместить на любом узле кластера.

Основная цель шардинга данных:

(1) Горизонтальное разделение/масштабирование содержимого.

(2) Распределяйте и распараллеливайте операции между сегментами (возможно, на нескольких узлах), повышая производительность/пропускную способность.

Примечание. После создания сегмента его размер изменить нельзя.

2. Реплика: обеспечивает высокую доступность в случае сбоя сегмента/узла.

Преимущество реплик: поскольку поиск можно выполнять на всех репликах параллельно, что позволяет масштабировать объем поиска/пропускную способность.

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

2.2 Шардинг и дизайн реплик на практике

Наиболее часто задаваемые вопросы

2.2.1 Вопрос 1. Сколько осколков задает индекс?

Официально рекомендуемое значение размера шарда 20-40 ГБ, по какому принципу? Медкл, сотрудник Elasticsearch, однажды обсудил следующее:

Для нижнего слоя Lucene такого ограничения по размеру нет.Диапазон 20-40 ГБ сам по себе относительно велик.Значение опыта иногда просто выстрел в голову, не обязательно простой в использовании.

Elasticsearch из изоляции и миграции данных нарезан в единицы фрагментации, увеличит стоимость миграции.

Сегмент — это библиотека Lucene. Каталог Lucene содержит множество сегментов. Каждый сегмент имеет верхний предел количества документов. Идентификатор документа внутри сегмента в настоящее время использует целое число Java, равное 2 в 31-й степени, поэтому его можно Общее количество представленных документов равно Integer.MAXVALUE - 128 = 2^31 - 128 = 2 147 483 647 - 1 = 2 147 483 519, что составляет 2,14 миллиарда.

Кроме того, если вы не объединитесь в сегмент принудительно, количество документов в одном сегменте может превысить это число.

Чем больше один Lucene, тем больше индекс, тем выше стоимость операции запроса и больше нагрузка на ввод-вывод, что, естественно, повлияет на работу с запросом.

Сколько данных подходит для сегмента, все еще необходимо проверить в сочетании с фактическими бизнес-данными и фактическими запросами для оценки.

Всеобъемлющий реальный бой + разнообразный онлайн-обмен опытом, отсортированный следующим образом:

Первый шаг: предполагаемое количество данных о шкале. В общей сложности, как долго вы хотите хранить данные, количество новых данных каждый день? Результаты в продукте - это общий объем данных.
Шаг 2: Оцените, сколько индексов нужно сохранить. Разделение индексов может основываться на потребностях бизнеса.
Шаг 3. Рассмотрите и измерьте масштабируемость, а также оцените необходимость создания кластера из нескольких машин. Хранилище в основном зависит от дискового пространства, при условии, что каждая машина имеет 2 ТБ, доступно: 2 ТБ 0,85 (фактическое использование диска) 0,85 (водяной знак предупреждения ES).
Шаг 4. Рекомендуется установить размер одного сегмента не более 30 ГБ. Если это добавочный индекс, его можно планировать вместе с реализацией проектной части большого индекса.

Первые три шага дают размер индекса. Количество осколков учитывает размерность:

1) Число разделения = размер индекса / значение опыта размера фрагмента 30 ГБ.
2) Количество осколков рекомендуется быть таким же, как число узлов. При проектировании 1), 2) двое считаются компромиссом для рассмотрения комбинации + индекса динамического обновления + Rollover.

Каждый размер сегмента является эмпирическим значением в соответствии с 30G 50G, поскольку в этом диапазоне производительность запросов и записи выше.

Рекомендуемая литература для изучения ценности опыта:

Сколько осколков нужно установить Elasticsearch?

Исследуйте | Основная логика масштабирования кластера Elasticsearch и планирования емкости

2.2.2 Вопрос 2. Сколько реплик устанавливает индекс?

В сочетании с масштабом кластера для сценария узлов данных кластера >=2: рекомендуется установить для реплики значение не менее 1.

Некоторые студенты появились раньше: копия установлена в 0, и она появится в долгосрочной перспективе - ситуация, когда запись данных перекошена на указанную машину.

Уведомление:

Одноузловая машина с набором реплик не вступит в силу. Количество реплик разработано в соответствии с потребностями безопасности данных. Для бизнес-сценариев с очень высокими требованиями к безопасности данных рекомендуется сделать хорошую работу: Расширенное резервное копирование (в сочетании с официальным решением ES для резервного копирования).

3. Как разработать карту?

3.1 Когнитивное картирование

Сопоставление — это процесс определения того, как документы и содержащиеся в них поля хранятся и индексируются. Например, используйте карту для определения:

Что должно быть строковое поле определяется как полнотекстовое поле поиска;
какие поля содержат числа, даты или географические местоположения;
Определите формат значения даты (временная метка или тип даты и т. д.);
Пользовательские правила для управления сопоставлением динамически добавляемых полей.

3.2 Примечания по проектированию отображения

ES поддерживает добавление полей //Добавить поля

PUT new_index  {    "mappings": {      "_doc": {        "properties": {          "status_code": {            "type":       "keyword"          }        }      }    }  }

ES не поддерживает прямое удаление полей
ES не поддерживает прямую модификацию полей
ES не поддерживает прямое изменение типа поля, если конструкция негибкая, есть другие программы ES, которые можно заменить с помощью переиндексации. Но большой объем данных будет иметь проблемы с производительностью, предложенный этап проектирования всеобъемлющих компромиссов.

3.3 Процесс настройки поля отображения

Индекс разделен на статическое отображение (настраиваемое поле) + динамическое отображение (ES автоматически адаптируется в соответствии с импортированными данными).

Рекомендации для реальных бизнес-сценариев: выберите статическое сопоставление и определите типы полей в соответствии с типом бизнеса.

выгода:

Контроль;
Сохранить место для хранения (строка по умолчанию - это текстовое + ключевое слово, которое не обязательно требуется по фактическому бизнесу).

При настройке полей обязательно выполните процесс, показанный ниже. В соответствии с фактическими потребностями бизнеса основное внимание уделяется:

выбор типа данных;
искать ли;
Требуется ли анализ сортировки + агрегации;
Нужно ли хранить отдельно.

Основное значение параметров, следующее сортировка:

3.4 Отображение рекомендуется сочетать с определениями шаблонов

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

Примечание. Шаблоны применяются только во время создания индекса. Изменение шаблона не влияет на существующие индексы.

В части 1 также говорится, что для больших индексов использование шаблонов является обязательным. Основные настройки, которые необходимо установить (перечислены только наиболее часто используемые, которые можно динамически изменять в реальном бою), следующие:

index.numberofreplicas Количество реплик, которые есть у каждого основного сегмента. По умолчанию 1 (версия 7.X, 5 ниже 7.X).
index.maxresultwindow Максимальное значение ПЗУ + размер глубокого подкачки — по умолчанию 10000.
index.refresh_interval Значение по умолчанию — 1 с: это означает, что отображается самый быстрый поиск 1 с;

Рекомендуется установить его на -1 при записи, чтобы улучшить производительность записи;

Если реальный бизнес-бизнес не требует высокой производительности в реальном времени, рекомендуется установить его на 30 с или выше.

3.5 Универсальный шаблон дизайна шаблона, включая отображение

Следующие шаблоны были проверены в версии 7.2 и могут быть напрямую скопированы и изменены для использования в реальных боевых проектах.

PUT _template/test_template{  "index_patterns": [    "test_index_*",    "test_*"  ],  "settings": {    "number_of_shards": 1,    "number_of_replicas": 1,    "max_result_window": 100000,    "refresh_interval": "30s"  },  "mappings": {    "properties": {      "id": {        "type": "long"      },      "title": {        "type": "keyword"      },      "content": {        "analyzer": "ik_max_word",        "type": "text",        "fields": {          "keyword": {            "ignore_above": 256,            "type": "keyword"          }        }      },      "available": {        "type": "boolean"      },      "review": {        "type": "nested",        "properties": {          "nickname": {            "type": "text"          },          "text": {            "type": "text"          },          "stars": {            "type": "integer"          }        }      },      "publish_time": {        "type": "date",        "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"      },      "expected_attendees": {        "type": "integer_range"      },      "ip_addr": {        "type": "ip"      },      "suggest": {        "type": "completion"      }    }  }}

4. Выбор слов сегментации

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

4.1 Яма 1: выбор сегментации слов

В реальном бизнесе: рекомендуется использовать сегментацию ik_max_word + поиск фраз match_phrase.

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

4.2 Яма 2: хочет ли ik установить все машины в кластере?

Рекомендация: Установить на все узлы кластера.

4.3 Яма 3: Что делать, если ik не совпадает?

Сценарий 1: Расширение открытого исходного кода.

Тезаурус динамически обновляется: обновление тезауруса может быть объединено mysql + ik, несущим динамически обновляемый лексикон.

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

Вариант 2. Используйте метод гибридного индексирования, чтобы избежать сценариев «очевидно существующих, но не извлеченных».

Разведка | Он явно существует, почему его нельзя найти?

5. Как выбрать тип поиска?

Предпосылка: После версии 5.X строковый тип больше не существует, он заменен текстовым и ключевым словом.

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

Применимо к: содержимому электронной почты, описанию продукта и другим полям, требующим сегментации слов полнотекстового поиска;

Неприменимо: сортировка или агрегация (за исключением агрегации важных терминов).

Тип ключевого слова: нет необходимости сегментации слов, полное и точное совпадение всего абзаца.

Применимо к: адресу электронной почты, адресу, коду статуса, тегам категорий.

Чтобы проиллюстрировать на практическом примере:

    PUT zz_test    {      "mappings": {              "doc": {        "properties": {            "title": {              "type": "text",              "analyzer":"ik_max_word",              "fields": {                "keyword": {                  "type": "keyword",                  "ignore_above": 256                }              }            }          }        }      }    }GET zz_test/_mapping
PUT zz_test/doc/1{  "title":"锤子加湿器官方致歉,难产后临时推迟一个月发货遭diss耍流氓"}

POST zz_test/_analyze{  "text": "锤子加湿器官方致歉,难产后临时推迟一个月发货遭diss耍流氓",  "analyzer": "ik_max_word"}

Результаты сегментации слов ik_max_word следующие:

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

5.1 термин точное соответствие

Основная функция: не зависит от токенизатора и относится к полному точному совпадению.
Сценарии применения: точное и точное соответствие.
Применимый тип: ключевое слово.
Пример: TERM является наиболее подходящим типом соответствия для ключевого слова, как показано ниже: Точное и полное совпадение:

    POST zz_test/_search    {      "query": {        "term": {          "title.keyword": "锤子加湿器官方致歉,难产后临时推迟一个月发货遭diss耍流氓"        }      }    }

Примечание. Ниже приведен результат не совпадения.

POST zz_test/_search{  "query": {    "term": {      "title": "锤子加湿器"    }  }}

Причина: термин «молотковый увлажнитель» в названии не соответствует сегментации слова. И в причастии ik_max_word тоже нет ключевого слова "молотковый увлажнитель".

5.2 соответствие префикса префиксу

Основные функции: соответствие префикса.
Сценарий: префикс автоматически полный бизнес-сценарий.
Применимый тип: ключевое слово.

Сопоставьте идентификатор документа до 1.

POST zz_test/_search{  "query": {    "prefix": {      "title.keyword": "锤子加湿器"    }  }}

5.3 нечеткое сопоставление с подстановочными знаками

Основная функциональность: сопоставление документов с ключевым словом типа, которое соответствует выражениям с подстановочными знаками. Поддерживаемые подстановочные знаки: *, который соответствует любой последовательности символов (включая последовательность нулевых символов); ? , который соответствует любому одиночному символу.
Сценарий применения: Обратите внимание, что выбор должен быть тщательным! Этот запрос может быть медленным со многими наборами ключевых моментов времени и может привести к простою, поскольку ему необходимо пройти несколько терминов. Чтобы предотвратить очень медленные запросы с подстановочными знаками, перед ними нельзя использовать подстановочный знак * или ? начало.
Применимый тип: ключевое слово.

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

POST zz_test/_search{  "query": {    "wildcard": {      "title.keyword": "*加湿器*"    }  }}

5.4 сопоставление слов

Основная функция: полнотекстовый поиск, слово слово сопоставление элемента.
Сценарий применения: Редко используется в реальном бизнесе Причина: Диапазон соответствия слишком широк и недостаточно точен.
Применимый тип: текст.
В следующем примере будут извлечены заголовки, содержащие «молоток» и «увлажнитель».

POST zz_test/_search{  "profile": true,   "query": {    "match": {      "title": "锤子加湿器"    }  }}

5.5 сопоставление фраз match_phrase

Основные функциональные возможности: Score_Phrase Query Parse Parses использует строку запросов в список терминов, а затем поиск этих терминов; сохранение только тех документов, которые содержат все условия поиска, а также положение «положение» чьи «положение» такое же, как условия поиска.
Сцена приложения: 90% из 90% + в развитии бизнеса будут использовать тип match_phrase или query_string вместо match.
Применимый тип: текст.
Уведомление:

POST zz_test/_analyze{  "text": "锤子加湿器",  "analyzer": "ik_max_word"}

Результат сегментации слова:

Молоток, молоток, суб, увлажнитель, увлажнитель. И: результат сегментации слова документа с id 1: молоток, молоток, саб, увлажнитель, мокрый, орган. Таким образом, следующий поиск не будет соответствовать результатам.

POST zz_test/_search{"query": {  "match_phrase": {    "title": "锤子加湿器"  }}}

Что делать, если вы хотите соответствовать? Это может быть в виде указателя словосочетаний.

Рекомендуемое чтение:

Разведка | Он явно существует, почему его нельзя найти?

5.6 multi_match Сопоставление нескольких групп

Основная функция: обновленная версия запроса соответствия для нескольких полей.
Сценарий приложения: поиск по нескольким полям.
Применимый тип: текст.
Пример

POST zz_test/_search{  "query": {    "multi_match": {      "query": "加湿器",      "fields": [        "title",        "content"      ]    }  }}

5.7 тип query_string

Основная функция: поддержка и или невыражение + другие n несколько параметров конфигурации.
Сценарий приложения: бизнес-система должна поддерживать извлечение пользовательских выражений.
Применимый тип: текст

POST zz_test/_search{  "query": {    "query_string": {      "default_field": "title",      "query": "(锤子 AND 加湿器) OR (官方 AND 道歉)"    }  }}

5.8 сопоставление логических комбинаций

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

{   "bool" : {      "must" :     [],      "should" :   [],      "must_not" : [],      "filter":    []   }}

must - все операторы должны (должны) совпадать и эквивалентны.
must_not — все операторы не должны совпадать, что эквивалентно NOT.
должен - по крайней мере одно выражение для сопоставления, эквивалентное ИЛИ.
фильтр - должен совпадать, работает в режиме без подсчета очков и фильтрации.

резюме:

6. Как спроектировать многотабличную ассоциацию?

6.1 Зачем нужна ассоциация нескольких таблиц

Объединение нескольких таблиц — один из наиболее часто задаваемых вопросов. Спрашивал почти каждую неделю.

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

6.2 Как реализовать ассоциацию нескольких таблиц

Вариант 1: представление, связанное с несколькими таблицами, синхронизация представлений ES

Широкая таблица MySQL импортируется в ES, и используется ES query + retrieval. Применимые сценарии: основной бизнес в MySQL, есть десятки или даже сотни таблиц, готовых к синхронизации с ES, а ES используется для полнотекстового поиска.

Интегрируйте данные в широкую таблицу и запишите ее в ES.Реализация широкой таблицы может быть реализована через представление реляционной базы данных.

Обработка широких таблиц При работе с отношениями «один ко многим» и «многие ко многим» возникнут проблемы с избыточностью полей.Если вы используете: logstash_input_jdbc, каждое поле в реляционной базе данных, такой как MySQL, автоматически преобразует его в соответствующий индекс в ES для вас Данные под одним из тех же полей под документом.

Шаг 1: Хорошо, впереди связанных данных, установит хороший вид на связанную таблицу, индекс, соответствующий одному из ваших просмотров и подтвердить правильность представления данных.
Шаг 2: ES подходит для имени индекса и сопоставления для каждого определения представления.
Шаг 3: Синхронизируйте с ES через logstash_input_jdbc в единицах просмотра.

Вариант 2: синхронная ES 1-к-1

Комбинация MySQL+ES и каждая из них имеют свои сильные стороны. Применимые сценарии: реляционные базы данных полностью синхронизируются с хранилищем ES без избыточных ассоциаций представлений.

ES хорош в поиске, а MySQL хорош в управлении отношениями.

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

Вариант третий: используйте вложенную хорошую ассоциацию

Применимая сцена: от 1 до небольшого количества сцен.

Пример: имеется документ, описывающий пост, и внутренний комментарий объекта, который содержит все комментарии к посту. Этого можно достичь с помощью Nested.

Выбор вложенного типа. Если вам нужно проиндексировать массив объектов и сохранить независимость каждого объекта в массиве, вы должны использовать тип данных Nested вместо типа данных Object Oject.

При использовании вложенных документов нельзя использовать общий метод запроса. Необходимо использовать соответствующие методы запроса (вложенный запрос, вложенный фильтр, вложенный фасет и т. д.) Во многих сценариях сложность использования вложенных документов заключается в этапе индексации Организация и сборка ассоциативных отношений.

Вариант 4. Использовать отношения родитель-потомок ES6.X+. Присоединиться для ассоциации.

Применимая сцена: 1 пара многих сцен.

Пример: Между продуктом и поставщиком существует связь 1-к-N.

Тип соединения: Тип данных Join - это специальное поле, которое создает отношения родителей / детей в документации того же индекса. Раздел «Отношения» определяет группу возможных отношений в документе, каждая связь является родительским именем и именем ребенка.

При использовании документов родитель-потомок используйте has_child или has_parent для запросов, связанных с родителем-потомком.

Сравнение схемы 3 и схемы 4 выбора:

Примечание. Вариант 3 и вариант 4 должны учитывать проблемы с производительностью. Документы должны пытаться повысить эффективность поиска за счет разумного моделирования.

Типов соединения следует избегать, насколько это возможно. Извлечение вложенного типа снижает эффективность извлечения в несколько раз, а извлечение типа соединение родитель-потомок снижает эффективность извлечения в сотни раз.

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

Галантерея | О важности моделирования данных Elasticsearch

Галантерея | Руководство по дизайну многотабличных ассоциаций Elasticsearch

резюме

7. Ямы, встречающиеся в реальном бою

Если бы я мог сделать это снова и снова, как бы я разработал систему Elasticsearch?

Думая о дизайне почти 10 миллионов реальных боевых проектов.

Яма 1: Очистка данных должна произойти перед написанием es! Вместо того, чтобы запрашивать постобработку данных, это неизбежно снизит скорость и эффективность запроса.
Яма 2: Подсветка Колеса не повторять, использовать родные.
Яма 3: Пусть делает то, в чем он хорош, поиск + несложная агрегация, иначе объем данных + сложная бизнес-логика будут иметь проблемы с производительностью.
Яма 4: Дизайнерские работы нельзя экономить! Быстро значит медленно, иначе бесконечные ошибки, вызванные недостатками дизайна, усилят чувство неудачи у команды!
Яма 5: В условиях заданного времени идеального дизайна никогда не будет.Только относительно разумный дизайн + рефакторинг должны сочетаться, чтобы иметь относительно надежную систему.
Яма 6: SSD может повысить производительность, но если бизнес-логика системы очень ответственная, замена SSD может не оправдать ожиданий.
PIT 7: в качестве эластично-исследовательских свойств транзакции транзакций не поддерживаются, база данных в реальном времени в качестве дополнительных данных, данные в реальном времени для требовательной сцены, должны сопровождаться письменными или двойными синхронными способами. Таким образом, после несоответствия данных в реальном времени вы можете синхронизировать инкрементное обновление базы данных.

Оригинальная ссылка:Мир Йи