Вы уже знаете, что реляционные БД — это набор таблиц и связей между ними. Такие БД подходят не для всех задач. Например, данные без структуры невозможно уложить в таблицу. В итоге разработчики создали для нереляционных моделей данных NoSQL (not only SQL) БД.Различия реляционных и нереляционных БД
| Реляционные | Нереляционные | |
|---|---|---|
| Способ хранения данных | В таблицах | По-разному: как документы, как граф из вершин и ребер, как пары «ключ-значение» и т. д. |
| Структура данных | Жесткая: у каждого объекта одни и те же поля | Жестких требований нет — у объектов могут быть разные поля |
| Добавление полей | Потребует изменить структуру таблицы и все объекты в ней | Не потребует ничего менять — можно добавить поля только к новым объектам |
| ACID* | Соответствуют требованиям ACID | ACID могут жертвовать, чтобы увеличить скорость работы или горизонтально масштабировать БД |
| Масштабирование | В основном вертикальное: с помощью увеличения мощности серверов | Вертикальное и горизонтальное: с помощью увеличения мощности серверов или их количества |
| Язык запросов | SQL или близкие к нему диалекты | Разные синтаксисы. Например, в MongoDB используются запросы в формате JSON |
* Требования ACID — это:
- Atomicity — атомарность: транзакция не выполняется, пока не выполнены все ее части;
- Consistency — целостность: когда транзакция завершилась, данные соответствуют схеме БД, а все реплики базы синхронизированы;
- Isolation — изолированность: параллельные транзакции выполняются отдельно друг от друга;
- Durability — надежность: способность восстанавливаться до последнего сохраненного состояния после сбоя.
На этом и следующих уроках вы познакомитесь с документоориентированной БД MongoDB и тем, как с ней работать в Yandex.Cloud.MongoDB — это популярная NoSQL БД, в которой данные хранятся не в строках таблиц, а в документах. Один объект — один документ. Структура каждого документа подобна структуре JSON (JavaScript Object Notation).Так может выглядеть документ из базы данных поликлиники с медицинскими картами пациентов:
Скопировать код{
"Имя":"Сергей",
"Фамилия":"Шишкин",
"Дата рождения":"02.12.1961",
"Номер медицинской карты":23264,
"Посещения врача":[
{
"Дата":"24.02.2021",
"Врач":"Сидорова О.С.",
"Анамнез":"...",
"Назначенные обследования":"Общий анализ крови",
"Диагноз":"ОРВИ",
"Лечение":"Теплый чай с медом перорально до 12 раз в сутки"
},
{
"Дата":"05.03.2021",
"Врач":"Сидорова О.С.",
"Анамнез”":"...",
"Назначенные обследования":"",
"Диагноз":"Здоров"
}
]
}
В отличие от строк в реляционных БД, документы:
- позволяют сохранять объекты со сложной структурой, которая может изменяться;
- могут отличаться друг от друга размером и полями.
Высокоуровнево документы состоят из пар ключ + значение. В примере с медицинской картой имя — это ключ, а Сергей — его значение. Значениями могут быть числа, строки, аудиофайлы, изображения, массивы или другие объекты, даже сложные.Однотипные документы объединяются в коллекции — аналог таблиц в реляционных БД. Например, в БД поликлиники могут входить коллекции «Медицинские карты пациентов», «Результаты лабораторной диагностики» и «Листы нетрудоспособности».MongoDB подойдет, если необходимо:
- Управлять большим объемом данных с заранее неизвестной структурой (каталоги товаров, пользовательские профили, системы управления контентом).Пример: интернет-магазин, где продается множество товаров с разными характеристиками. Чтобы выставить товар на сайт, контент-менеджер выбирает характеристики и их значения из набора. Менеджер также может добавить или удалить любое поле и установленные для него значения.
- Горизонтально масштабироваться.Пример: создание национальной БД медицинских карт. Реляционная БД здесь — не лучшее решение: ее горизонтальное масштабирование сопряжено с трудностями и плохо автоматизируется.
Свежие комментарии