Да, правильно использовать indices вместо types, поскольку ES устарел, что в версии 7, поэтому мы должны создать несколько индексов для управления этим вариантом использования.
Итак, теперь у нас есть только два варианта:
Вариант 1. Денормализуйте данные и загрузите документы соответствующим образом.
И здесь вы снова можете управлять этим двумя способами:
Значительно денормализуйте, продолжая использовать поле соединения или, скажем, денормализуйте 1-to-n child types в n indexes of to 1-to-1 parent-child type. По сути, у вас будет столько же индексов, сколько отношений родитель-потомок у вас было в более ранней версии, однако родительский элемент будет одинаковым для всех индексов. Нет индексов = Нет родительско-дочерних отношений
Второй способ добиться этого - полностью денормализовать данные таким образом, чтобы у вас был единый индекс со всей информацией обо всех дочерних элементах всех типов, которые у вас были, в одном документе. В этом случае no of index = 1
Я предполагаю, что если у ваших детей есть уникальные поля, в этом случае я думаю, что второе с одним индексом может работать, но опять же вы не упомянули количество документов, которые у вас есть, поэтому вам, вероятно, потребуется найти баланс. Другой метод - использовать и то, и другое.
Недостатками в этом случае будут
- Управление уровнем приема или заданиями
- Сложность в поддержании структуры индекса
- Проблемы с производительностью согласно этой ссылке при использовании типа соединения
- Следите за будущими версиями ES, если они решат изменить родительско-дочернюю функцию, хотя пока это не рассматривается.
Преимущества:
- Вероятно, на уровне обслуживания, который не имеет отношения к Варианту 2, как описано ниже.
- Возможность сопоставлять варианты использования, которые могут возникнуть при использовании интерфейсного приложения.
Варианты 2: Управление объединением на уровне приложения
- Иметь один родительский индекс и несколько дочерних индексов, но управлять объединением на уровне приложения. Если у вас несколько
1-to-n mapping, то количество индексов будет n (parent = 1, child = n-1)
Недостатки:
- Может быть, а может быть, не удастся легко связать с вариантами использования
- Написание отдельной логики соединения на уровне приложения. Не говоря уже о том, что если вы хотите выполнить агрегацию между родительским и дочерним элементами, вам придется написать несколько циклов for с несколькими отдельными запросами агрегации.
Преимущества:
- Простота поддержки заданий или уровня приема
- Управление индексами было бы менее болезненным
В качестве альтернативы вы можете смешивать и сочетать оба вышеуказанных варианта, в зависимости от ваших сценариев использования.
Как видите, у обоих есть свои плюсы и минусы. Если уровень приема является легким в одном, он становится громоздким в другом, если уровень обслуживания легче поддерживать в одном, он становится трудным в другом.
Лучший способ - продолжить с некоторыми фиктивными данными, провести некоторое тестирование производительности и посмотреть, какие факторы вы бы использовали, простота запросов, обслуживание индекса, производительности запросов или агрегирования, простота разработки / управления как заданиями приема, так и уровнем обслуживания и т. Д. .
Возможно, это не совсем то, что вы ищете, но я просто надеюсь, что это поможет!
person
Opster ES Ninja - Kamal
schedule
11.06.2020
