Комментарии 11
У этих тулзовин есть недостаток, который может кто-то и не сочтет недостатком. Нет возможности при выполнении changeset выбрать подключение к бд. Если бд содержит несколько схем/пользователей и накатывать надо согласованно от владельцев объектов - тогда ой. Есть костыль - воспользоваться пользователем с правами dba(create any/alter any). Но это дыра, которую надо грамотно закрыть суметь архитектору
К сожалению, тема миграции для БД раскрыта очень поверхностно. Ни один из указанных инструментов не позволяет мигрировать данные (а это необходимо для обеспечения совместимости при выкладки без останова), нет описания безопасных миграций (а очень немногие из реальных операций на СУБД безопасны), нет связи с поведением в системе (а это также нужно для обновления без останова).
В серьезных проектах использование liquibase крайне неудобно, flyway с миграциями на java может использоваться, если добавить довольно много собственного кода. Но, обычно, нужно делать собственное решение.
Ликвибейз позволяет проводить любые манипуляции с данными. Но! Для этого надо писать правильные sql-скрипты. Можно смешивать скрипты на sql и xml. Но чем серьезнее и увесистее бд, тем грамотнее должен быть разработчик.
Эээ, ты не можешь одним sql запросом безопасно обновить миллион записей, увы. Для этого нужна сложная логика обновления небольшими батчами, с отслеживанием процесса, возможностью повтора после падения сервиса, учетом нагрузки и так далее.
А уж как сложно на liquibase работать с миграций данных в json/jsonb полей... Увы, в современных подходах работы с СУБД миграция - это просто код на языке высокого уровня.
Почему я не могу одним dml обновить миллион записей? бд не знает, кто к ней стучится с того конца - liquibase или sqlplus. Про миллион я даже и задумуваться не буду. Про логику никто и не спорит. Мой коммент выше про грамотного разработчика именно поэтому
Смотря что за данные, потому что блокировки, нехватка места под rollback сегмент и прочее.
Э, а что такое "грамотный разработчик"? Вот обновлять одним update t set c1=c2 на таблице больше 100k записей - неграмотно, но многие ли это знают?
Даже alter table add column часто опасно вызывать - но это вообще мало кто знает.
О, как интересно! А почему неграмотно? Слишком большая транзакция получится, блокирующая всю таблицу на длительное время? Или есть ещё какие-то подводные камни? Просто обновлять таблицу кусками и получать постоянно неконсистентное состояние мне кажется гораздо более рискованным мероприятием. Насколько я представляю, если таблица реально большая и блокировать её даже на секунду чревато, то в ход идут сложные мероприятия типа создания нового экземпляра БД, настройка репликации на него, переключения всех пользователей на него, отключение первого экземпляра, его модификация, а потом обратный процесс. Но это пипец как сложно и опасно и мало где нужно.
А с добавлением колонки какие проблемы? Вообще, почитать бы статьи на эту тему...
Во-первых, блокировка всей таблицы и совсем не на секунды, а на гораздо дольше (вплоть до минут, если в таблице миллиарды записей)
Во-вторых, можно вылезти за размер сегмента отката или размера WAL
В-третьих, там с репликацией могут быть проблемы (но тут лучше с DBA обсудить, там все сильно зависит от конкретной СУБД и настроек).
Непонятно, почему при обновлении может быть неконсистентное состояние? При обновлении структуры СУБД нормально иметь разные записи в разных "версиях схемы" и сервисы приложений должен уметь с этим работать. Обычно достаточно иметь поле schema-version в каждой записи.
Копировать БД - это очень дорогое развлечение, которое для действительно крупных СУБД просто невозможно.
Добавление колонки требует эксклюзивной блокировки. Так что если у тебя идет длинный отчет по этой таблице и куча мелких транзакций, то они все начнут ждать конца отчета. Так что можно на пустом месте получить простой в минуты и больше.
Вообще, я про все это рассказывал на последнем SHL:
Enterprise deploy: почему это больно / Филипп Дельгядо (lekton io) - YouTube
В задаче обновления данных много всяких нюансов. И стандартные решения, увы, работают только на домашних проектах, не в приличном продакшене.
Нужна помощь в тестировании приложения на Android - самым активным бесплатная подписка на год! Написал в посте
Переписывая историю: от инструментов версионирования БД к практике