Hibernate: hbm2ddl.auto = обновление в производстве?

Question

Можно ли запускать приложения Hibernate, настроенные с hbm2ddl.auto=update, для обновления схемы базы данных в производственной среде?

Answer 1

Это небезопасно, не рекомендуется, но возможно.

У меня есть опыт использования приложения с автоматическим обновлением на рабочем месте.

Итак, основные проблемы и риски, обнаруженные в этом решении:

• Развертывание в неправильной базе данных . Если вы допустите ошибку, чтобы запустить сервер приложений со старой версией приложения (EAR / WAR / etc) в неправильной базе данных ... У вас будет много новых столбцов, таблиц, внешних ключей и ошибок. Та же проблема может возникнуть с простой ошибкой в ​​файле источника данных (скопировать / вставить файл и забыть изменить базу данных). В резюме, ситуация может быть катастрофой в вашей базе данных.
• Запуск сервера приложений занимает слишком много времени . Это происходит потому, что Hibernate пытается найти все созданные таблицы / столбцы / и т. Д. Каждый раз, когда вы запускаете приложение. Он должен знать, что (таблица, столбец и т. Д.) Нужно создать. Эта проблема будет только усугубляться по мере роста таблиц базы данных.
• Инструменты базы данных практически невозможно использовать . Чтобы создать сценарии базы данных для запуска с новой версией, вам нужно подумать о том, что будет создано при автообновлении после запуска сервера приложений. Например, если вам нужно заполнить новый столбец некоторыми данными, вам нужно запустить сервер приложений, подождать, пока Hibernate создаст новый столбец, и только после этого запустить скрипт SQL. Как видите, инструменты миграции баз данных (такие как Flyway, Liquibase и т. Д.) Практически невозможно использовать с включенным автообновлением.
• Изменения базы данных не централизованы . Благодаря возможности Hibernate создавать таблицы и все остальное трудно наблюдать за изменениями в базе данных в каждой версии приложения, поскольку большинство из них выполняются автоматически.
• Стимулирует сбор мусора в базе данных . Из-за простоты автоматического обновления существует вероятность того, что ваша команда пренебрегает удалением старых столбцов и старых таблиц.
• Грядущая катастрофа . Неизбежный риск некоторой катастрофы на производстве (как некоторые люди упоминали в других ответах). Даже если приложение работает и может обновляться годами, я не думаю, что это безопасно. Я никогда не чувствовал себя в безопасности с этой опцией.

Итак, я не буду рекомендовать использовать автообновление в производстве.

Если вы действительно хотите использовать автообновление в производстве, я рекомендую:

• Разделенные сети . Ваша тестовая среда не может получить доступ к среде гомологов. Это помогает предотвратить развертывание, которое должно быть в тестовой среде, изменить базу данных омологации.
• Управление порядком скриптов . Вам необходимо организовать выполнение сценариев перед развертыванием (изменение таблицы структур, удаление таблицы / столбцов) и сценариев после развертывания (заполнение информации для новых столбцов / таблиц).

И, в отличие от других постов, я не думаю, что автообновление включило, это связано с «очень хорошо оплачиваемыми» администраторами баз данных (как упоминалось в других публикациях) ... Администраторы баз данных имеют более важные дела, чем написание SQL операторы для создания / изменения / удаления таблиц и столбцов. Эти простые повседневные задачи могут быть выполнены и автоматизированы разработчиками и переданы только для просмотра администратором БД, не требуя, чтобы Hibernate и администраторы БД «очень хорошо оплачивали» их написание.

Answer 2

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

Answer 3

• Обычно корпоративные приложения в крупных организациях работают с ограниченными привилегиями.

• Имя пользователя базы данных может не иметь права DDL для добавления столбцов, для которых hbm2ddl.auto=update требуется.

Answer 4

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

Наличие всей вашей настойчивости в отображениях Hibernate (или аннотациях) является очень хорошим способом для контроля эволюции схемы.

Следует учитывать, что эволюция схемы имеет несколько аспектов, которые следует учитывать:

1. эволюция схемы базы данных в добавление дополнительных столбцов и таблиц

2. удаление старых столбцов, таблиц и отношения

3. заполнение новых столбцов значениями по умолчанию

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

Точка 3 очень чувствительна в том случае, если вы используете Hibernate, как в случае, если вы вводите новое булево значение или числовое свойство, если Hibernate найдет какое-либо нулевое значение в таких столбцах, если вызовет исключение.

Итак, что бы я сделал: действительно используйте возможности обновления схемы средствами Hibernate, но вы должны добавить к нему некоторые данные и обратный вызов для обслуживания схемы, например, для заполнения значений по умолчанию, отбрасывания больше не используемых столбцов и т. П. Таким образом, вы получаете преимущества (независимые от базы данных сценарии обновления схемы и избегаете дублирования кодирования обновлений, в постоянных и в сценариях), но вы также охватывает все аспекты операции.

Так, например, если обновление версии заключается просто в добавлении свойства со значением varchar (следовательно, столбца), которое может по умолчанию иметь значение null, с автоматическим обновлением все будет готово. Там, где требуется больше сложности, потребуется больше работы.

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

Answer 5

Я согласен с Владимиром. Администраторы в моей компании определенно не оценили бы это, если бы я даже предложил такой курс.

Кроме того, создание сценария SQL вместо слепо доверяющего Hibernate дает возможность удалять поля, которые больше не используются. Hibernate не делает этого.

И я считаю, что сравнение производственной схемы с новой схемой дает вам еще лучшее понимание того, как вы изменились в модели данных. Вы знаете, конечно, потому что вы сделали это, но теперь вы видите все изменения за один раз. Даже те, которые заставляют вас говорить «Какого черта ?!».

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