текст перекладу
Реляційні бази даних
Реляційні бази даних є методом зберігання та керування даними, заснованим на реляційній моделі.
Ця база даних використовує стандартизований мову, SQL, для взаємодії з даними. SQL зазвичай використовується в системах управління реляційними базами даних (СУРБД) таких, як Oracle, Microsoft SQL Server, MySQL, Microsoft Access тощо.
MongoDB
MongoDB — це база даних NoSQL, яка стала альтернативою традиційним реляційним базам даних та іншим NoSQL базам, особливо для сучасних і динамічних застосунків.
MongoDB відома, перш за все:
- своїм моделлю даних, орієнтованою на документи,
- горизонтальною масштабованістю,
- і гнучкістю.
Розглянемо основні відмінності між MongoDB та реляційними базами даних.
Модель даних
MongoDB
{
"_id": 16432,
"firstName": "Dupont",
"lastName": "Julien",
"city": "Marseille"
}
MongoDB зберігає дані у вигляді документів, схожих на JSON або BSON. Ця модель, орієнтована на документи, є більш гнучкою, ніж реляційні таблиці, оскільки вона дозволяє вбудовувати ієрархічні структури та вкладені об'єкти без потреби у фіксованій схемі.
Реляційні бази даних
Реляційні бази даних використовують табличну модель, де дані зберігаються в рядках і стовпцях таблиць із фіксованою і структурованою схемою. Кожна таблиця повинна визначати типи даних, зв'язки та обмеження. Ця структура ідеальна для забезпечення цілісності даних і складних запитів, які потребують об'єднання таблиць.
Масштабованість
MongoDB
MongoDB розроблена для горизонтальної масштабованості (horizontal scaling) через sharding, техніку, що дозволяє розподіляти дані між кількома серверами або кластерами. Ця можливість дозволяє MongoDB ефективно працювати з великими обсягами даних та забезпечувати високу доступність.
Реляційні бази даних
Більшість реляційних баз даних здебільшого підтримують вертикальну масштабованість (vertical scaling), техніку, що дозволяє збільшувати потужність одного сервера шляхом додавання RAM або використання більш потужних процесорів. Хоча деякі сучасні реляційні бази даних пропонують sharding для горизонтальної масштабованості, ця опція зазвичай є більш складною та дорогою порівняно з NoSQL базами.
Керування даними
Керування даними базується на двох ключових підходах:
- нормалізація
- та денормалізація.
Ці підходи впливають на структуру даних, продуктивність та варіанти використання.
Нормалізація
Нормалізація даних є систематичним методом, який використовується для зменшення надмірності даних і покращення їхньої цілісності. Це означає організацію та структурування даних шляхом розподілу сутностей між різними таблицями та усунення надлишкових даних.
текст перекладу
Реляційні бази даних
Зв'язки між даними в реляційних базах даних управляються за допомогою первинних ключів та зовнішніх ключів.
Переваги:
- Зменшення розміру даних: кожна інформація зберігається лише один раз у відповідній таблиці, що усуває дублювання даних.
- Оптимізація запитів: написання запитів спрощується завдяки тому, що дані розбиті на частини.
- Легкість оновлення: оновлення даних простіше, оскільки зміни локалізовані і мають менший вплив на інші частини.
Недоліки:
- Жорсткість: додавання нової таблиці або видалення таблиці потребує складних змін у базі даних.
- Знижена швидкість читання: для з'єднання таблиць і отримання необхідних даних необхідні операції об'єднання (join). Це може бути складно і дорого, особливо при великих обсягах даних: чим більше даних, тим довше триває обробка.
Реляційні бази даних базуються на нормалізації, щоб забезпечити організацію даних оптимальним, узгодженим та ефективним способом.
Денормалізація
Денормалізація даних — це систематичний метод, що використовується для об'єднання пов'язаних даних в одному документі.
Переваги:
- Гнучкість: завдяки документам, в яких можна вільно додавати або змінювати поля, не впливаючи на інші дані.
- Покращена швидкість читання: дані вбудовані в один документ, що дозволяє отримувати їх за одну операцію без необхідності в об'єднаннях. Це спрощує процес читання даних.
Недоліки:
- Надмірність даних: інформація, що повторюється між документами, може бути дубльована, що збільшує розмір бази даних.
- Складність оновлення: потрібно оновлювати всі документи, що містять дубльовані дані, якщо ці дані змінюються.
MongoDB віддає перевагу денормалізації даних, що покращує продуктивність читання даних і забезпечує більшу гнучкість моделі даних.
Гнучкість
MongoDB
MongoDB не нав'язує фіксовану схему, що означає, що кожен документ може мати унікальну структуру. Ця гнучкість є перевагою для застосунків, що швидко розвиваються, або для випадків, коли модель даних на початку не визначена чітко. Це дозволяє змінювати та додавати поля на ходу без міграцій бази даних і легко управляти гетерогенними даними.
Реляційні бази даних
В реляційних базах даних схема має бути визначена з самого початку, що означає, що всі дані в таблиці повинні відповідати одній структурі. Будь-яка структурна зміна часто вимагає міграції даних, що може бути довгим і дорогим процесом для великих баз. Така жорстка модель краще підходить для застосунків, де зв'язки між даними стабільні.
Однак варто зазначити, що деякі "сучасні" бази даних, такі як PostgreSQL, MySQL, Oracle тощо, підтримують JSON-формат, який дозволяє:
- зберігати дані в таблиці,
- уникати міграції даних при додаванні нових властивостей (наприклад, зміна типу),
- виконувати складні запити безпосередньо по полях JSON.
Ця функція дозволяє отримати переваги як реляційних баз даних, так і баз, орієнтованих на документи. Це відкриває шлях до гібридного керування даними, що забезпечує більшу гнучкість.
Висновок
MongoDB і реляційні бази даних мають як свої переваги, так і недоліки, свої сильні і слабкі сторони. Тому вони є корисними в різних випадках.
MongoDB є універсальним вибором для сучасних застосунків, які потребують гнучкості та масштабованості.
текст перекладу
Він пропонує гнучку модель даних, легку для адаптації, з нативною підтримкою горизонтального шардінгу. MongoDB став популярним вибором для веб-застосунків, мобільних додатків і великих даних.
SQL база даних є найкращим вибором для проєкту, який не потребує змін у схемі даних. Вона також забезпечує легку настройку та обслуговування.
Подяка
Я дякую своїм колегам Christophe Vaudry та Thomas VERHOKEN за уважне прочитання та їхні зауваження щодо цього допису.
Перекладено з: MongoDB versus Base de données relationnelle