Введение
При использовании MySQL в качестве хранилища между таблицами существует множество связей «один-ко-многим», таких как заказы и сведения о заказах, клиенты и адреса клиентов и т. д. Однако, поскольку сама ES имеет плоскую структуру документа, между различными таблицами обычно нет связи. Реляционные индексы. ES не очень хорошо справляется с этими отношениями по сравнению с MySQL, но он также предоставляет несколько способов поддержки этих отношений. Давайте в качестве примера возьмем клиентов и адреса клиентов (один клиент имеет несколько адресов). Преимущества и недостатки различных индексов. типы хранилищ, так уж получилось, что на этой неделе мы перенесем данные клиентов в ES за одну итерацию.
客户基本信息：first、last、code、email
客户地址信息：city、address2. Массив
На самом деле в ES нет выделенного типа массива.По умолчанию любое поле может содержать 0 или более значений, но все значения в массиве должны иметь один и тот же тип данных.
1. Массив базового типа
Примечание: адрес предназначен для хранения по нескольким адресам. Здесь его можно определить как текст. Ключевого слова, позволяющего установить его как тип массива при определении, не существует.
Примечание. Можно хранить 0 или более значений, если типы согласованы или их можно принудительно преобразовать.
Примечание. Этот документ DOC можно найти с помощью нечеткого запроса.
2. Массив объектов
Примечание. На самом деле это основной тип объекта в ES.
Примечание. addr может содержать встроенные объекты.
Примечание. В результатах запроса массива объектов обнаружена проблема с границами. Проверьте city="Brisbane" и
Address="Ngungug" проверит записи. Нет проблем в сценариях, где адрес не является строго обязательным. Но если это список продуктов, встроенный в заказ, я хочу узнать, когда указаны код продукта и цена. Фактически, необходимо строго сопоставлять один объект в массиве, а не сопоставлять весь массив. Это происходит главным образом потому, что ES сжимает хранилище данных объекта JSON.
Фактическое внутреннее хранилище вышеуказанных данных выглядит следующим образом: Таким образом, связь между городом и адресом теряется.
3. Вложение
Вложенный тип — это специальная версия типа данных объекта, которая может вкладывать объекты в объекты или хранить пары ключ-значение в полях.
1. Определите вложенные структуры
Примечание. Вложенные структуры определяются с использованием вложенного типа.
2. Вставьте данные документа
Примечание. Во вложенной структуре можно разместить информацию о нескольких адресах. Кроме того, в ES существует разница между инструкциями put и post. Put необходимо указать идентификатор документа, чтобы действовать с указанным документом. POST не требует указания идентификатор документа. Он действует на коллекцию. Эта концепция. Полученный из протокола HTTP, протокол HTTP определяет, что операция put является идемпотентной, а операция POST - неидемпотентной.
3. Запрос документов на основе вложенного контента
Если запрос изменить на следующий, данные не будут найдены.В этом разница между вложенными структурами и массивами объектов.
Разница между объектными данными и вложенным хранилищем с использованием команд
get _cat/indices?v Просмотр фактического количества документов внутри ES.
Видно, что при использовании вложенной структуры вложенный вложенный документ на самом деле является независимым вложенным документом в ES. Однако, когда мы делаем запросы, ES выполняет внутреннюю обработку соединения для нас, поэтому, условно говоря, производительность вложенного при выполнении запросов не так же хорошо, как и у обычных внутренних объектов. .
4. Документы отца и сына
1. Определите структуру родитель-потомок
Примечание. Используйте соединение для представления структуры ассоциации «родитель-потомок», custmoer в отношениях — это родительский документ, а customerAddr — дочерний документ.
2. Вставьте данные родительского документа.
Примечание: здесь join_field.name указывает, что документ является родительским документом.
3. Вставьте данные вложенного документа.
Примечание. Здесь join_field.name указывает, что документ является вложенным документом, а родительский элемент указывает тип родительского документа. Маршрутизация задается в запросе, чтобы гарантировать, что родительский и дочерний документы находятся в одном сегменте.
4. Запрос
получить customer_parent/_search{}
Примечание. Возвращает два документа: родительский и дочерний.
получить customer_parent/_doc/customer1
Примечание. Возвращаются только данные родительского документа.
Используйте запрос has_child: запросите содержимое родительского документа на основе условий дочернего документа.
Примечание. Возвращается только содержимое родительского документа.
Используйте запрос has_parent: запрашивайте содержимое вложенных документов на основе условий родительского документа.
Примечание. Возвращается только содержимое вложенного документа.
5. Сравнение нескольких типов связей ES один-ко-многим
Примечание. Наши данные о клиентах редко обновляются и в большинстве случаев это запрос, поэтому в конечном итоге используется вложенная структура.