Hibernate: hbm2ddl.auto = оновлення у виробництві?

Чи добре запускати програми зимування, налаштовані hbm2ddl.auto=updateна оновлення схеми бази даних у виробничому середовищі?

Ні, це небезпечно.

Незважаючи на всі зусилля зі сплячої групи, ви просто не можете розраховувати на автоматичні оновлення у виробництві . Напишіть власні патчі, огляньте їх за допомогою DBA, протестуйте їх, а потім застосуйте вручну.

Теоретично, якщо оновлення hbm2ddl працювало в розробці, воно повинно працювати і у виробництві. Але насправді це не завжди так.

Навіть якщо це спрацювало нормально, це може бути недостатньо оптимальним. DBA виплачуються стільки ж просто так.

Ми робимо це у виробництві, хоча і з додатком, який не є критичним завданням, і не має високооплачуваних DBA на персонал. Це лише один менш ручний процес, який піддається людській помилці - додаток може виявити різницю і зробити все правильно, плюс ви, ймовірно, ви протестували її в різних середовищах розробки та тестування.

Одне застереження - у кластерному середовищі ви можете уникати цього, оскільки одночасно можуть з’являтися кілька додатків і намагатися змінити схему, яка може бути поганою. Або ввести в якийсь механізм, де для оновлення схеми дозволено лише одному екземпляру.

Творці сплячки відмовляють це робити у виробничому середовищі у своїй книзі "Наполегливість Яви із сплячим режимом" :

ПОПЕРЕДЖЕННЯ. Ми бачили користувачів сплячого режиму, які намагаються використовувати SchemaUpdate для автоматичного оновлення схеми виробничої бази даних. Це може швидко закінчитися катастрофою, і ваша DBA не дозволить.

Ознайомтеся з LiquiBase XML щодо збереження журналу змін. Я ніколи не використовував його до цього року, але я виявив, що це дуже легко навчитися і зробити управління переглядом / переходом / зміною / зміною управління дуже нерозумним. Я працюю над проектом Groovy / Grails, і Grails використовує Hibernate під ним для всіх своїх ORM (званих "GORM"). Ми використовуємо Liquibase для управління всіма змінами схеми SQL, що ми робимо досить часто, коли наше додаток розвивається з новими можливостями.

В основному ви зберігаєте XML-файл наборів змін, до яких ви продовжуєте додавати по мірі розвитку вашої програми. Цей файл зберігається в git (або тому, що ви використовуєте) з рештою проекту. Коли ваш додаток розгорнуто, Liquibase перевіряє таблицю змін у БД, до якої ви підключаєтесь, щоб він знав, що вже застосовано, то він розумно застосовує всі набори змін, які ще не застосовані з файлу. Практично це працює на практиці, і якщо ви використовуєте його для всіх змін схеми, ви можете бути на 100% впевнені, що код, який ви оформили на замовлення та розгорне, завжди зможе підключитися до повністю сумісної схеми бази даних.

Дивовижна річ у тому, що я можу взяти повністю пусту базу даних mysql на своєму ноутбуку, запустити додаток, і тут же схема для мене створена. Це також полегшує тестування змін схеми, застосувавши їх до локального розробника або інсценізації db спочатку.

Найпростіший спосіб почати з цього, ймовірно, буде взяти наявний БД, а потім використовувати Liquibase для створення початкового файлу baseline.xml. Тоді в майбутньому ви можете просто додати його і дозволити liquidibase взяти на себе управління змінами схеми.

http://www.liquibase.org/

Я б проголосував «за». 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 і перетворення її в текст, середній текст тощо, тощо.

Зрозуміло, я не думаю, що існує дійсно спосіб "перетворити типи даних" без створення нового стовпця, копіювання даних і видування старого стовпця. Але в ту хвилину, де у вашій базі даних є стовпці, які не відображають поточне відображення в сплячому режимі, ви живете дуже небезпечно ...

Flyway - це хороший варіант вирішення цієї проблеми:

http://flywaydb.org

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

Зазначені ситуації, коли його не слід використовувати набагато більше, ніж ті, де це нормально.

Я використовував її протягом багатьох років у багатьох проектах і ніколи не мав жодного випуску. Це не кульгава відповідь, і це не ковбойське кодування. Це історичний факт.

Людина, яка каже, що "ніколи цього не роби у виробництві", думає про конкретний набір виробничих розгортань, а саме про ті, з якими він знайомий (його компанія, його галузь тощо).

Всесвіт "виробничих розгортань" величезний і різноманітний.

Досвідчений розробник Hibernate точно знає, що DDL буде отримано в результаті заданої конфігурації відображення. Поки ви перевірите і підтвердите, що те, що ви очікуєте, закінчиться в DDL (у програмах dev, qa, інсценуванні тощо), у вас все добре.

Додаючи безліч функцій, автоматичне оновлення схем може бути економією в реальному часі.

Перелік автоматичних оновлень матеріалів не обробляється нескінченним, але деякі приклади - це міграція даних, додавання стовпців, що не змінюються, зміни назви стовпців тощо, тощо.

Також потрібно дбати про кластеризовані середовища.

Але знову ж таки, якби ви знали все це, ви б не ставили цього питання. Хм. . . Гаразд, якщо ви задаєте це питання, вам слід зачекати, поки у вас буде багато досвіду роботи зі сплячим режимом сплячки та автоматичної схеми, перш ніж задуматися про його використання у продажі.

Як я пояснив у цій статті , використовувати це hbm2ddl.autoу виробництві не дуже добре .

Єдиний спосіб управління схемою бази даних - це використання поступових сценаріїв міграції, оскільки:

• сценарії будуть розміщуватися в VCS уздовж вашої бази коду. Оглядаючи відділення, ви відтворюєте всю схему з нуля.
• додаткові сценарії можуть бути протестовані на QA-сервері перед застосуванням у виробництві
• немає необхідності вручну втручатися, оскільки сценарії можуть управляти Flyway , отже, це зменшує можливість людських помилок, пов’язаних із запуском скриптів вручну.

Навіть посібник зі сну гібернації радить уникати використання hbm2ddlінструменту у виробничих середовищах.

Ми робимо це в проекті, що працює місяцями у виробництві і ніколи до цього не виникало проблем. Майте на увазі 2 інгредієнта, необхідні для цього рецепту:

1. Створіть свою об'єктну модель за допомогою підходу, сумісного з зворотною сумісністю, тобто знецінення об'єктів та атрибутів, а не видалення / зміни їх. Це означає, що якщо вам потрібно змінити назву об'єкта чи атрибута, залиште старий таким, яким він є, додайте новий та напишіть якийсь сценарій міграції. Якщо вам потрібно змінити асоціацію між об'єктами, якщо ви вже перебуваєте у виробництві, це означає, що ваш дизайн в першу чергу був неправильним, тому спробуйте продумати новий спосіб вираження нових відносин, не впливаючи на старі дані.

2. Завжди створюйте резервну копію бази даних перед розгортанням.

Моє відчуття - після прочитання цього допису - 90% людей, які беруть участь у цій дискусії, жахнулися лише думкою про використання подібних автоматизацій у виробничих умовах. Деякі кидають м'яч у DBA. Хоч трохи подумайте, що не всі виробничі середовища надають DBA і не багато команд розробників можуть собі дозволити (принаймні, для проектів середнього розміру). Отже, якщо ми говоримо про команди, де всі повинні робити все, м'яч на них.

У цьому випадку чому б просто не намагатися мати найкраще з обох світів? Такі інструменти є тут, щоб допомогти допомогти, який - при ретельному дизайні та плані - може допомогти у багатьох ситуаціях. І повірте, адміністраторам спочатку може бути важко переконати, але якщо вони знають, що м'яч не на їх руках, їм це сподобається.

Особисто я ніколи не повертаюся до написання сценаріїв вручну для розширення будь-якого типу схем, але це лише моя думка. І після того, як нещодавно почав приймати бази даних без схем NoSQL, я можу побачити, що швидше всі ці операції, засновані на схемі, належатимуть минулому, тож краще почати змінювати свою точку зору і дивитися вперед.

Я б не ризикував, тому що ви, можливо, втратите дані, які повинні були зберегтись. hbm2ddl.auto = оновлення - це просто простий спосіб оновити свою базу даних розробників.

• У моєму випадку (Hibernate 3.5.2, Postgresql, Ubuntu), встановивши hibernate.hbm2ddl.auto=updateлише створені нові таблиці та створивши нові стовпці у вже існуючих таблицях.

• Він не робив ані скидання таблиць, ані стовпців, ані змінних стовпців. Це можна назвати безпечним варіантом, але щось подібне hibernate.hbm2ddl.auto=create_tables add_columnsбуло б більш зрозумілим.

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

У мене є досвід роботи програми, яка використовує опцію автоматичного оновлення у виробництві.

Що ж, основні проблеми та ризики, знайдені в цьому рішенні:

• Розгортання в неправильній базі даних . Якщо ви допустили помилку запустити сервер додатків зі старою версією програми (EAR / WAR / тощо) в неправильній базі даних ... У вас буде багато нових стовпців, таблиць, зовнішніх ключів та помилок. Ця ж проблема може виникнути і з простою помилкою у файлі джерела даних (скопіювати / вставити файл і забути змінити базу даних). Якщо резюме, ситуація може стати катастрофою у вашій базі даних.
• Сервер додатків займає занадто багато часу для запуску . Це трапляється тому, що сплячка намагається знаходити всі створені таблиці / стовпці / тощо при кожному запуску програми. Він повинен знати, що (таблиця, стовпець тощо) потрібно створити. Ця проблема погіршується лише у міру зростання таблиць баз даних.
• Інструменти бази даних використовувати майже неможливо . Щоб створити сценарії DDL або DML баз даних для запуску з новою версією, потрібно подумати про те, що буде створено автоматичним оновленням після запуску сервера додатків. Наприклад, якщо вам потрібно заповнити новий стовпець деякими даними, вам потрібно запустити сервер додатків, дочекатися, коли Hibernate створить новий стовпець і запустіть сценарій SQL лише після цього. Як ви бачите, інструменти міграції баз даних (наприклад, Flyway, Liquibase тощо) використовувати майже неможливо з увімкненим автоматичним оновленням.
• Зміни бази даних не є централізованими . З можливістю Hibernate створювати таблиці та все інше, важко спостерігати за змінами в базі даних у кожній версії програми, оскільки більшість з них виробляються автоматично.
• Заохочує сміття в базі даних . Через "просте" використання автоматичного оновлення є ймовірність, що ваша команда нехтуватиме старі стовпці та старі таблиці, тому що спляче автоматичне оновлення не може цього зробити.
• Неминуча катастрофа . Неминучий ризик виникнення катастрофи у виробництві (як деякі люди, згадані в інших відповідях). Навіть якщо програма працює і оновлюється протягом багатьох років, я не думаю, що це безпечний вибір. Я ніколи не відчував себе в безпеці при використанні цього варіанту.

Тож я не рекомендую використовувати автоматичне оновлення у виробництві.

Якщо ви дійсно хочете використовувати автоматичне оновлення у виробництві, рекомендую:

• Відокремлені мережі . Ваше тестове середовище не може отримати доступ до середовища гомологів. Це допомагає запобігти розгортанню, яке повинно бути в тестовому середовищі, змінити базу даних Homologation.
• Керуйте порядком сценаріїв . Потрібно організувати свої сценарії до запуску до розгортання (зміна структури таблиці, випадіння таблиці / стовпців) та сценарій після розгортання (заповніть інформацію для нових стовпців / таблиць).

І, на відміну від інших дописів, я не думаю, що автоматичне оновлення ввімкнуло це, пов’язане з "дуже добре оплаченими" DBA (як згадувалося в інших публікаціях). У DBA важливіші речі, ніж писати SQL-оператори для створення / зміни / видалення таблиць і стовпців. Ці прості повсякденні завдання розробники можуть виконувати та автоматизувати, і лише для того, щоб команда DBA переглянула їх, не потребуючи «Зимового режиму» та DBA, щоб вони їх написали.

Ні, ніколи цього не роби. Спячий режим не обробляє міграцію даних. Так, це дозволить вашій схемі виглядати правильно, але це не гарантує, що цінні виробничі дані не будуть втрачені в процесі.

• Зазвичай корпоративні програми у великих організаціях працюють із обмеженими привілеями.

• Ім'я користувача бази даних може не мати DDLпривілею для додавання стовпців, що hbm2ddl.auto=updateвимагає.

Я згоден з Володимиром. Адміністратори моєї компанії точно б не оцінили це, якби я навіть запропонував такий курс.

Крім того, створення сценарію SQL замість сліпо довіреного режиму hibernate дає можливість видалити поля, які вже не використовуються. Зимовий режим не робить цього.

Я вважаю, що порівняння виробничої схеми з новою схемою дає вам ще краще розуміння того, як Ви змінили модель даних. Ви знаєте, звичайно, тому, що ви це зробили, але тепер ви бачите всі зміни за один раз. Навіть ті, які змушують тебе йти на кшталт "Що за чорт ?!".

Є інструменти, які можуть зробити для вас дельту схеми, тому це навіть не важка робота. І тоді ви точно знаєте, що буде.

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

Маючи всю свою наполегливість у сплячому зібранні (або анотаціях) - це дуже хороший спосіб тримати еволюцію схеми під контролем.

Вам слід врахувати, що еволюція схеми має враховувати кілька аспектів:

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

2. скидання старих стовпців, таблиць та відносин

3. заповнення нових стовпців за замовчуванням

Засоби сплячого режиму важливі, зокрема, у випадку, якщо у вас є різні версії одного і того ж додатка для багатьох різних типів баз даних.

Пункт 3 дуже чутливий у випадку, коли ви використовуєте Hibernate, як у випадку, якщо ви введете нове булеве значення з властивістю чи числовим значенням, якщо Hibernate знайде будь-яке нульове значення в таких стовпцях, якщо підніме виняток.

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

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

Це припускає, що додаток під час оновлення здатне оновити свою схему (це можна зробити), що також означає, що він повинен мати права користувача на це на схемі. Якщо політика замовника перешкоджає цьому (ймовірно, випадок "Ящірка мозку"), вам доведеться надати конкретні сценарії для бази даних.