В настоящее время я работаю над планом обновления для кластера 5.6 до версии 7.5 и подумываю об общем изменении дизайна в рамках этого обновления. Текущее общее описание кластера:
- Кластер построен с ежемесячными индексами, в среднем около 200 ГБ и около 600 млн. Документов (на индекс). Срок хранения 13 месяцев назад. Большинство запросов за последний месяц.
- Индекс основан на модели «родитель-потомок». Картография была построена с более чем 40 различными типами (которые, конечно, не рекомендуется в последних версиях).
- Существует один «родительский» тип, который содержит поля, относящиеся к определенному состоянию (открытие / закрытие). Это do c обновляется только один раз, когда состояние изменяется с «открыто» на «закрыто», и дополнительные поля добавляются, когда это происходит. Распределение родительских документов составляет около 1% от индекса.
- Более 40 других типов - это детские документы. Эти документы вообще не обновляются, и у каждого родителя могут быть сотни / тысячи родственных детей. Два типа из них состоят из 45% документов (более масштабных событий).
- Все запросы относятся к родителям с has_child, которые отвечают на определенный фильтр.
Моя главная мысль - это вопрос о том, следует ли полностью отказаться от модели «родитель-ребенок» и перейти к другому подходу, если он вообще существует. Как задокументировано, запросы типа «родители-потомки» могут быть в 5–10 раз медленнее, чем другие запросы, но компромисс в нашем случае будет означать, что нам придется реализовать какой-то сервис обогащения, чтобы «объединить» родительские поля с каждым из его дочерних полей. и переиндексировать каждого потомка, как только изменится состояние родителя (прежде чем мы просто выполнили бы обновление родителя).
Стоит ли этот компромисс? Размер индекса удваивает его размер, и каждый раз, когда родитель изменяет свое состояние, он вызывает относительно большой объемный индекс. API требует интенсивного поиска, индексирование может выполняться медленнее и практически в реальном времени, что означает, что было бы лучше улучшить производительность поиска за счет времени индексации. Есть ли какое-либо преимущество в продолжении модели «родитель-потомок», как описано выше (мы должны были бы сгладить сопоставления, поскольку типы, конечно, не рекомендуется)? Учитывая общее описание кластера и размер компромиссов переключения.
Я знаю, что это очень общий вопрос, и есть много других переменных, связанных с измерением производительности, но было бы полезно, если бы ответ на этот вопрос был «определенный» решающий да / нет - так как разработка и внедрение таких изменений потребует довольно много времени, даже для целей тестирования в среде тестирования.