Спящий режим:hbm2ddl.auto=обновление в производстве?
https://stackoverflow.com/questions/221379
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Можно ли запускать приложения Hibernate, настроенные с помощью hbm2ddl.auto=update обновить схему базы данных в производственной среде?
Решение
Нет, это небезопасно.
Несмотря на все усилия команды Hibernate, вы просто не можете полагаться на автоматические обновления в производстве . Напишите свои собственные патчи, просмотрите их с помощью администратора баз данных, протестируйте их, а затем примените их вручную.
Теоретически, если обновление hbm2ddl работало в разработке, оно должно работать и в производстве. Но на самом деле это не всегда так.
Даже если все работает нормально, оно может быть неоптимальным. Администраторам платят так много по причине.
Другие советы
Мы делаем это в производстве, хотя с приложением, которое не является критически важным, и без высокооплачиваемых администраторов баз данных. Это всего лишь один меньше ручной процесс, который подвержен человеческим ошибкам - приложение может обнаружить разницу и сделать правильные вещи, плюс вы предположительно протестировали ее в различных средах разработки и тестирования.
Одно предостережение - в кластерной среде вы можете избежать этого, поскольку одновременно могут появляться несколько приложений и пытаться изменить схему, что может быть плохо. Или вставьте какой-нибудь механизм, где только один экземпляр может обновлять схему.
Создатели Hibernate не рекомендуют делать это в производственной среде в своей книге " Сохранение Java с Hibernate " :
ПРЕДУПРЕЖДЕНИЕ. Мы видели, как пользователи Hibernate пытались использовать SchemaUpdate для автоматического обновления схемы производственной базы данных. Это может быстро закончиться катастрофой и не будет разрешено вашим администратором баз данных.
Проверьте LiquiBase XML на наличие журнала изменений. Я никогда не использовал его до этого года, но обнаружил, что его очень легко освоить и сделать управление ревизиями БД / управление миграцией / изменениями очень надежным. Я работаю над проектом Groovy / Grails, и Grails использует Hibernate для всех своих ORM (называемых «GORM»). Мы используем Liquibase для управления всеми изменениями схемы SQL, что мы делаем довольно часто, так как наше приложение развивается с новыми функциями.
По сути, вы храните XML-файл наборов изменений, которые вы продолжаете добавлять по мере развития вашего приложения. Этот файл хранится в git (или как вы используете) с остальной частью вашего проекта. Когда ваше приложение развернуто, Liquibase проверяет его таблицу изменений в БД, к которой вы подключаетесь, чтобы узнать, что уже применено, а затем разумно просто применяет все изменения, которые еще не были применены из файла. На практике он работает великолепно, и если вы используете его для всех изменений схемы, вы можете быть на 100% уверены, что код, который вы извлекаете и разворачиваете, всегда сможет подключиться к полностью совместимой схеме базы данных.
Удивительная вещь в том, что я могу взять на своем ноутбуке совершенно пустую базу данных mysql, запустить приложение и сразу же настроить схему для меня. Это также облегчает тестирование изменений схемы, применяя их сначала к локальной dev-системе или промежуточной базе данных.
Самый простой способ начать работу с ним, вероятно, состоит в том, чтобы взять существующую БД и затем использовать Liquibase для создания исходного файла baseline.xml. Затем в будущем вы можете просто добавить к нему и позволить liquibase взять на себя управление изменениями схемы.
Hibernate должен поставить заявление об отказе от использования автообновлений в prod, чтобы скрыть себя, когда люди, которые не знают, что делают, используют его в ситуациях, когда его не следует использовать.
Разумеется, ситуации, когда его не следует использовать, намного превосходят те, где все в порядке.
Я использовал его в течение многих лет во многих различных проектах, и у меня никогда не было ни одной проблемы. Это не плохой ответ, и это не ковбойское кодирование. Это исторический факт.
Человек, который говорит "никогда не делай этого на производстве" думает о конкретном наборе производственных процессов, а именно о тех, с которыми он знаком (его компания, его отрасль и т. д.).
Вселенная "производственных развертываний" обширный и разнообразный.
Опытный разработчик Hibernate точно знает, что DDL получит в результате данной конфигурации сопоставления. Пока вы тестируете и проверяете, что то, что вы ожидаете, попадает в DDL (в dev, qa, staging и т. Д.), У вас все в порядке.
Когда вы добавляете множество функций, автоматические обновления схемы могут экономить время.
Список автоматических обновлений, которые не будут обрабатываться, бесконечен, но некоторые примеры - миграция данных, добавление необнуляемых столбцов, изменение имени столбца и т. д. и т. д.
Также вам нужно позаботиться в кластерной среде.
Но опять же, если бы вы знали все это, вы бы не задавали этот вопрос. Хм , , Хорошо, если вы задаете этот вопрос, подождите, пока у вас не появится большой опыт работы с Hibernate и автоматическим обновлением схемы, прежде чем подумать об использовании его в prod.
Я бы проголосовал против. Hibernate, кажется, не понимает, когда типы данных для столбцов изменились. Примеры (с использованием MySQL):
String with @Column(length=50) ==> varchar(50)
changed to
String with @Column(length=100) ==> still varchar(50), not changed to varchar(100)
@Temporal(TemporalType.TIMESTAMP,TIME,DATE) will not update the DB columns if changed
Возможно, есть и другие примеры, например, увеличение длины столбца String более чем на 255 и его преобразование в текст, средний текст и т. д. и т. д.
Конечно, я не думаю, что действительно есть способ "преобразовать типы данных" без создания нового столбца, копирования данных и удаления старого столбца. Но в ту минуту, когда в вашей базе данных есть столбцы, которые не отражают текущее отображение Hibernate, вы живете очень опасно ...
Flyway - хороший вариант для решения этой проблемы:
Как я объяснил в Эта статья, это не очень хорошая идея использовать hbm2ddl.auto в производстве.
Единственный способ управлять схемой базы данных — использовать сценарии инкрементной миграции, поскольку:
- сценарии будут находиться в VCS вместе с вашей кодовой базой.Когда вы извлекаете ветку, вы воссоздаете всю схему с нуля.
- инкрементальные сценарии можно протестировать на сервере контроля качества перед применением в производстве.
- нет необходимости во вмешательстве вручную, поскольку сценарии могут запускаться Пролетный путь, следовательно, это снижает вероятность человеческой ошибки, связанной с запуском сценариев вручную.
Даже Руководство пользователя спящего режима советую вам избегать использования hbm2ddl инструмент для производственных сред.
Я бы не стал рисковать, потому что вы можете потерять данные, которые должны были быть сохранены. hbm2ddl.auto = update - это простой способ поддерживать вашу базу данных в актуальном состоянии.
Мы делаем это в проекте, работающем уже несколько месяцев, и у нас до сих пор не было проблем. Имейте в виду 2 ингредиента, необходимые для этого рецепта:
<Ол>Создайте свою объектную модель с подходом обратной совместимости, то есть осуждайте объекты и атрибуты вместо их удаления / изменения. Это означает, что если вам нужно изменить имя объекта или атрибута, оставьте старое как есть, добавьте новое и напишите какой-нибудь скрипт миграции. Если вам нужно изменить связь между объектами, если вы уже находитесь в производстве, это означает, что ваш проект был изначально неправильным, поэтому постарайтесь придумать новый способ выражения новых отношений, не затрагивая старые данные.
Всегда делайте резервную копию базы данных перед развертыванием.
Я чувствую - после прочтения этого поста - что 90% людей, участвующих в этом обсуждении, приходят в ужас от мысли об использовании подобных автоматизаций в производственной среде. Некоторые бросают мяч в DBA. Потратьте немного времени, чтобы учесть, что не все производственные среды предоставляют DBA, и не так много команд разработчиков могут себе их позволить (по крайней мере, для проектов среднего размера). Так что, если мы говорим о командах, где каждый должен делать все, мяч на них.
В таком случае, почему бы просто не попытаться получить лучшее из обоих миров? Такие инструменты, как это, здесь, чтобы протянуть руку помощи, которая - с тщательным дизайном и планом - может помочь во многих ситуациях. И поверьте мне, поначалу администраторов может быть трудно убедить, но если они знают, что мяч не в их руках, им это понравится.
Лично я никогда не вернусь к написанию сценариев вручную для расширения схем любого типа, но это только мое мнение. И после того, как я недавно начал принимать NoSQL-схемы без баз данных, я вижу, что в скором времени все эти операции на основе схем уйдут в прошлое, поэтому вам лучше начать менять свою перспективу и смотреть в будущее.
В моем случае (Hibernate 3.5.2, Postgresql, Ubuntu) настройка
hibernate.hbm2ddl.auto=updateтолько создавал новые таблицы и создавал новые столбцы в уже существующих таблицах.Он не удалял ни таблицы, ни столбцы, ни изменял столбцы.Это можно назвать безопасным вариантом, но что-то вроде
hibernate.hbm2ddl.auto=create_tables add_columnsбыло бы более понятно.
Это небезопасно и не рекомендуется, но возможно.
У меня есть опыт работы с приложением, использующим опцию автоматического обновления в производстве.
Итак, основные проблемы и риски, обнаруженные в этом решении:
- Развертывание в неправильной базе данных.Если вы допустили ошибку и запустили сервер приложений со старой версией приложения (EAR/WAR/и т. д.) в неправильной базе данных...У вас появится много новых столбцов, таблиц, внешних ключей и ошибок.Та же проблема может возникнуть из-за простой ошибки в файле источника данных (скопировать/вставить файл и забыть изменить базу данных).В общем, ситуация может обернуться катастрофой в вашей базе данных.
- Сервер приложений запускается слишком долго.Это происходит потому, что Hibernate пытается найти все созданные таблицы/столбцы/и т. д. каждый раз, когда вы запускаете приложение.Ему нужно знать, что (таблицу, столбец и т. д.) необходимо создать.Эта проблема будет только усугубляться по мере роста таблиц базы данных.
- Инструменты базы данных, которые практически невозможно использовать.Чтобы создать сценарии базы данных для работы с новой версией, необходимо подумать о том, что будет создано автообновлением после запуска сервера приложений.Например, если вам нужно заполнить новый столбец некоторыми данными, вам нужно запустить сервер приложений, дождаться, пока Hibernate создаст новый столбец, и только после этого запустить сценарий SQL.Как видите, инструменты миграции баз данных (такие как Flyway, Liquibase и т. д.) практически невозможно использовать с включенным автоматическим обновлением.
- Изменения в базе данных не централизованы.Учитывая возможность создания таблиц и всего остального в Hibernate, сложно отслеживать изменения в базе данных в каждой версии приложения, поскольку большинство из них происходят автоматически.
- Поощряет мусор в базе данных.Из-за простоты автоматического обновления существует вероятность, что ваша команда забудет удалить старые столбцы и старые таблицы.
- Неизбежная катастрофа.Неизбежный риск возникновения какой-либо катастрофы на производстве (как некоторые люди упоминали в других ответах).Даже если приложение работает и обновляется годами, я не думаю, что это безопасно.Я никогда не чувствовал себя в безопасности с этой опцией.
Так что я не буду рекомендовать использовать автообновление в продакшене.
Если вы действительно хотите использовать автообновление в производстве, я рекомендую:
- Раздельные сети.Ваша тестовая среда не имеет доступа к гомологической среде.Это помогает предотвратить изменение базы данных омологации при развертывании, которое должно было осуществляться в тестовой среде.
- Управлять порядком скриптов.Вам необходимо организовать выполнение сценариев перед развертыванием (изменение структуры таблицы, удаление таблицы/столбцов) и сценариев после развертывания (заполнение информации для новых столбцов/таблиц).
И, в отличие от других сообщений, я не думаю, что автоматическое обновление включено, оно связано с «очень хорошо оплачиваемыми» администраторами баз данных (как упоминалось в других сообщениях)...У администраторов баз данных есть дела поважнее, чем написание операторов SQL для создания/изменения/удаления таблиц и столбцов.Эти простые повседневные задачи могут выполняться и автоматизироваться разработчиками и передаваться только на рассмотрение команде администраторов баз данных, без необходимости использования Hibernate и администраторов баз данных, «очень хорошо оплачиваемых» для их написания.
Нет, никогда не делай этого. Hibernate не обрабатывает миграцию данных. Да, это сделает вашу схему правильно выглядящей, но не гарантирует, что ценные производственные данные не будут потеряны в процессе.
Обычно корпоративные приложения в крупных организациях работают с ограниченными привилегиями.
Имя пользователя базы данных может не иметь
DDLпривилегия на добавление столбцов, которыеhbm2ddl.auto=updateтребует.
Я согласен с Владимиром. Администраторы в моей компании определенно не оценили бы это, если бы я даже предложил такой курс.
Кроме того, создание сценария SQL вместо слепо доверяющего Hibernate дает возможность удалять поля, которые больше не используются. Hibernate не делает этого.
И я считаю, что сравнение производственной схемы с новой схемой дает вам еще лучшее представление о том, как вы изменились в модели данных. Вы знаете, конечно, потому что вы сделали это, но теперь вы видите все изменения за один раз. Даже те, которые заставляют вас идти, как "Какого черта?!".
Существуют инструменты, которые могут сделать дельту схемы для вас, так что это даже не тяжелая работа. И тогда вы точно знаете, что произойдет.
Схема приложений может развиваться со временем; если у вас есть несколько установок, которые могут быть в разных версиях, у вас должен быть какой-то способ убедиться, что ваше приложение, какой-либо инструмент или сценарий способны поэтапно переносить схему и данные из одной версии в любую следующую.
Наличие всей вашей настойчивости в отображениях (или аннотациях) Hibernate - это очень хороший способ контролировать эволюцию схемы.
Следует учитывать, что эволюция схемы имеет несколько аспектов, которые следует учитывать:
<Ол>эволюция схемы базы данных в добавление дополнительных столбцов и таблиц
удаление старых столбцов, таблиц и отношения
заполнение новых столбцов значениями по умолчанию
Инструменты Hibernate важны, в частности, в том случае, если (как показывает мой опыт) у вас разные версии одного и того же приложения в разных типах баз данных.
Точка 3 очень чувствительна в том случае, если вы используете Hibernate, как в случае, если вы вводите новое булево значение или числовое свойство, если Hibernate найдет любое нулевое значение в таких столбцах, если вызовет исключение.
Итак, я бы сделал следующее: действительно используйте возможности обновления схемы средствами Hibernate, но вы должны добавить к нему некоторые данные и обратный вызов для обслуживания схемы, например, для заполнения значений по умолчанию, отбрасывания больше не используемых столбцов и т. п. Таким образом, вы получаете преимущества (независимые от базы данных сценарии обновления схемы и избегаете дублирования кодирования обновлений, в постоянных и в сценариях), но вы также охватите все аспекты операции.
Так, например, если обновление версии состоит просто в добавлении свойства со значением varchar (следовательно, столбца), которое может по умолчанию иметь значение null, с автоматическим обновлением все будет сделано. Там, где требуется больше сложности, потребуется больше работы.
Это предполагает, что приложение при обновлении способно обновить свою схему (это может быть сделано), что также означает, что у него должны быть права пользователя для этого на схеме. Если политика клиента запрещает это (скорее всего, случай с Ящерицей), вам придется предоставить сценарии, специфичные для базы данных.
