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

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

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

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

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

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

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

19
elasticsearch flyway java liquibase migration

1 ответов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

в сумме вверх:

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