Альтернатива миграции базы данных Liquibase или Flyaway для Elasticsearch

Я новичок в ES. Я пытался долго искать инструмент миграции db, и я не мог его найти. Мне интересно, может ли кто-нибудь помочь мне указать на правильное направление.

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

В прошлом я использовал инструменты для управления версиями баз данных, такие как Flyaway или Liquibase.

Существуют ли какие-либо фреймворки/сценарии или методы, которые я мог бы использовать с ES для достижения чего-то подобного?

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

Спасибо заранее!

ОТВЕТЫ

Ответ 1

С этой точки зрения/потребности ES имеют огромные ограничения:

  • несмотря на динамическое сопоставление, ES не схематически, но с интенсивным использованием схемы. Невозможно изменить сопоставления в случае, если это изменение противоречит существующим документам (практически, если в каком-либо из документов нет нулевого поля, которое влияет на новое сопоставление, это приведет к исключению)
  • документы в ES неизменяемы: как только вы их проиндексировали, вы можете получить/удалить только. Синтаксический сахар вокруг этого является частичным обновлением, которое делает потокобезопасный delete + index (с тем же идентификатором) на стороне ES

Что это значит в контексте вашего вопроса? У вас, в принципе, не может быть классических инструментов миграции для ES. И вот что может сделать вашу работу с ES проще:

  • используйте строковое сопоставление ("dynamic": "strict"и/или index.mapper.dynamic: false, посмотрите сопоставление документов). Это защитит ваши индексы/типы от

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

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

  • вы можете использовать псевдонимы индекса для переноса

Итак, немного опыта. Для меня в настоящее время разумный поток таков:

  • Все структуры данных, описываемые как модели в коде. Эти модели действительно обеспечивают абстракцию ORM тоже.
  • Обращение за созданием индекса/сопоставления - это простой метод модели.
  • Каждый индекс имеет псевдоним (т.е. news), который указывает на фактический индекс (т.е. news_index_{revision}_{date_created}).

Каждый раз, когда разворачивается код, вы

  • Попробуйте установить сопоставление модели (типа). Если это произошло без ошибки, это означает, что у вас есть

    • введите одно и то же отображение
    • put, которое является чистым надмножеством старого (только новые поля были предоставлены, старые остаются нетронутыми)
    • никакие документы не имеют значений в полях, затронутых новым сопоставлением

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

  • Если ES предоставляет исключение о новом сопоставлении, вы
    • создайте новый индекс/тип с новым сопоставлением (называемым name_{revision}_{date}
    • перенаправить ваш псевдоним на новый индекс
    • введите код миграции bulk для быстрого переиндексации Во время этой переиндексации вы можете безопасно индексировать новые документы обычно через псевдоним. Недостатком является то, что исторические данные частично доступны во время переиндексации.

Это тестовое решение. Предостережения вокруг такого подхода:

  • вы не можете сделать этого, если ваши запросы на чтение требуют согласованных исторических данных.
  • вам нужно переиндексировать весь индекс. Если у вас есть 1 тип за индекс (жизнеспособное решение), то его штраф. Но иногда вам нужны многотипные индексы
  • передача данных в оба конца. Иногда бывает боль.

Подводя итог этому:

  • старайтесь иметь хорошую абстракцию в ваших моделях, это всегда помогает
  • попытайтесь сохранить устаревшие исторические данные/поля. Просто создайте свой код с учетом этой идеи, это проще, чем звуки вначале.
  • Я настоятельно рекомендую не полагаться на инструменты миграции, которые используют инструменты экспериментального эксперимента ES. Они могут быть изменены в любое время, например, инструменты river-*.