В дискусіях про бази даних NoSQL проти SQL я іноді чую, що компанії вважають за краще використовувати безшовні бази даних NoSQL, оскільки перенести схему на нову версію проблематично. Але чи справді це велика проблема під час оновлення? Чи погані реляційні бази даних для таких операцій?
Я читав цю публікацію в блозі MongoDB: Чому без схеми?
Відповіді:
Тільки тому, що у вашій базі даних NoSql немає схеми в традиційному розумінні, це не означає, що не існує логічної схеми, з якою вам потрібно мати справу при її зміні. У випадку типового додатка, що використовує MongoDb, швидше за все, ваш код очікує, що певні поля об’єкта json поводяться певним чином. Якщо ви зміните поведінку, це може призвести до оновлення вже наявних даних у базі даних. Тепер, з традиційними RDBMS, це була значною мірою вирішена проблема - ви просто повинні були ВИНИКНУТИ основні таблиці. Але з цими новомодними базами даних NoSQL у вас є рішення - ви пишете сценарій, щоб об'єднати та оновити всі свої об'єкти? Або ви додаєте код для перетворення між версіями на льоту? Якщо так, то як довго ви підтримуєте v1 об’єкти? Назавжди? До v3?
Додам, що приклад, використаний у дописі в блозі MongoDb, є дещо спрощеним та дуже простим у справі, якщо у вас є гідний процес оновлення незалежно від того, що таке RDBMS; додавання поля рідко шкодить. Саме тоді, коли ви вирішили розділити своє Nameполе, FirstNameі LastNameце стає цікавим.
Але чи справді це велика проблема під час оновлення?
Це може бути.
Деякі організації - добре неорганізовані та виконують дуже погану роботу з міграції схем.
"Міграційний вихідний". Зупиніть сервери. Створіть резервну копію та експортуйте всі дані. Побудуйте нову схему (часто, змінюючи існуючу схему). Перезавантажте дані або спробуйте реструктурувати на місці.
"Безперервне налаштування". Змінюйте таблиці в межах, дозволених SQL. Без відстеження послідовності ALTER's виконується. Не маючи змоги повернутися до попередньої версії схеми. За необхідності створіть нові таблиці з існуючих таблиць, сподіваємось коригувати всі програми для використання нових таблиць. Але - не вистачає хорошої якості - залишаючи старі таблиці «на всякий випадок».
"Повна паніка". Просто запобігайте модифікаціям схеми. Робіть великий смерд. Стверджуйте, що ризик занадто високий. Блокуйте всі зусилля в цьому напрямку. Візьміть схему в заручники, поки не змушені використовувати якийсь більш розумний підхід.
Чи погані реляційні бази даних для таких операцій?
Будь-яка схема - це біль для міграції.
Найбільше питання - не технічне.
Це смислово.
Однією з причин зміни схеми є те, що попередня схема не дуже добре відповідає проблемній області. Оскільки семантика змінилася, базу даних (та програми) потрібно змінити. Іноді це глибокі зміни, які потребують переосмислення способів роботи програм із даними.
Перегляд семантики бази даних може бути дуже важким.
Що люди роблять замість змін схеми, це просто неправильне використання фізичної схеми. Вони починають завантажувати неправильні дані в існуючі поля, тому що можуть. Поле "коментар" раптом починає містити важливу інформацію про управління клієнтами, а потім "//", а потім реальний коментар. Це зростає, щоб мати фрагменти даних "поле 1 - поле 2 // коментар". Користувачі мають електронну таблицю, яка витягує ці додаткові дані з поля коментарів, оскільки "справжнє" прикладне програмне забезпечення було важко змінити, що ІТ відмовилося його змінити.
Ми без проблем модернізуємо виробничі бази даних, додаючи таблиці та (нульові) стовпці. Попередні версії програми відмінно працюють з оновленою базою даних, вони просто не посилаються на нові речі. Ми уникаємо видалення таблиць або стовпців або зміни способу зберігання існуючих даних, хоча, коли це необхідно, ми створюємо відповідні сценарії перетворення. Незалежно від того, чи має ваша база даних оголошену безпечну схему чи ні, зміни структури даних вимагають перетворення даних та оновлення додатків для взаємодії з новою структурою.
Це залежить.
По-перше, якщо у вас дійсно велика база даних, що охоплює декілька машин, то все (не лише оновлення бази даних) буде болем. (скільки б ви не планували достроково).
По-друге, оновлення бази даних НЕ є лише справою бази даних - це також залежить від більшої системи, до складу якої входить БД. Сюди також входить розгортання бази даних (безліч серверів баз даних, кілька центрів обробки даних, налаштування ведучих-ведених тощо)
Біль можна полегшити, побудувавши системні компоненти таким чином, що всі вони мають певне «пізнання» події зміни схеми БД. Це означає, що вся система повинна бути толерантною до змін схеми і може реагувати на неї «розумним» способом.
Ви можете перевірити утиліту, розроблену Facebook для вирішення проблем оновлень схеми MySQL.
Крім того, існують стандартні найкращі практики, такі як перетворення основного режиму на читання, внесення змін до рабів або копії розробки тощо.
У будь-якому випадку, ОБОВ'ЯЗКОВЕ резервне копіювання та обширний тестовий набір . Тільки тоді ви зможете робити будь-які зміни впевнено та безпечно.