Когда мы разбирали виды баз данных, то сказали, что они бывают реляционные и все остальные. Реляционные — самые распространённые, вы встретите их под капотом большинства сайтов, чаще всего они управляются через систему MySQL.
Но одно решение не может подходить всем и всегда. Сегодня поговорим обо всех остальных вариантах, которые собраны под единым большим термином NoSQL — это общее название для нереляционных баз данных.
Способ организации данных
В SQL-базах всё просто: есть, условно говоря, таблицы, и есть связи между ними. Все данные хранятся в этих таблицах.
В NoSQL-базах всё иначе — там может не быть таблиц, а вместо них — свои модели данных. Каждая из них подходит под свои задачи, универсальной нет. Вот основные модели:
Ключ-значение
У каждой записи есть название поля и его значение. Например:
name: ‘Миша’
today: ‘9/09/2020’
president: ‘Путин’
writer: ‘Пушкин’
pogoda: ‘ну такая’
Первая часть — это ключ, вторая часть — значение. И можно подсыпать сколько хочешь новых ключей.
Это полезно, например, для словарей или механизмов автозамены: «Если встретилось такое слово — замени на вот такое».
Колонки
Представьте себе одну огромную таблицу, в которой хранятся все данные в базе. Отличие от традиционной схемы в том, что в SQL-базах работа идёт со строками, а здесь — с колонками. Например, если в такую базу занести список из 250 лучших фильмов с названиями, актёрами и режиссёрами, то все названия можно получить с помощью только одного запроса и одного обращения к базе.
Графы
Если ваши данные можно представить в виде графа или дерева, то вам подойдёт и база данных с таким же подходом к хранению и поиску.
Дерево — это когда данные хранятся по системе «родитель — отпрыски». Есть некий родительский кусок данных, у него есть связанные с ним отпрыски. У тех тоже могут быть свои отпрыски и так далее. Каждая единица данных может быть чьим-то отпрыском (но только кого-то одного) и иметь сколько-то собственных отпрысков.
В деревьях удобно хранить данные, например, для поисковых алгоритмов. В «деревьях» также хранятся файлы на вашем компьютере: есть корневой каталог, в нём вложенные папки, в них ещё папки, в них файлы. Один и тот же файл не может храниться одновременно в двух местах.
Графы — это когда данные связаны вообще как хочешь. Один кусок данных может быть связан с любыми другими в любом количестве и в любом направлении. Дерево — частный случай графа.
❤️ Про деревья мы недавно писали: что такое Trie и как работает бустинг
Документы
Вот это космос, смотрите.
Если мы храним данные в таблице, у нас есть столбцы и строки. И если у нас про кого-то есть данные, а про другого нет, — где-то в таблице будут пропуски. А если в таблице нет нужного столбца, а нам нужно положить в неё новый тип данных, нам придётся создавать новый столбец, и он для всех будет пустым:
| Имя | Возраст | Город | Роль |
| Миша | 35 | Брянск | Редактор |
| Женя | Москва | Директор | |
| Родион | Ульяновск |
Реляционная БД заставляет нас заранее придумывать, как будет работать база данных; какие там будут поля; какие допустимы типы данных. Например, в таблицу выше уже не добавишь информацию о том, что Родион носит бороду — точнее, добавить-то её можно, но тогда у нас появится куча пустых ячеек. А если этих столбцов нужно добавлять много? Это крайне нерационально.
Теперь представьте, что есть механизм, который позволяет хранить эти данные в более свободном формате. Например:
name: Миша
age: 35
city: Брянск
job: Редактор
stickerpack: Доктор Хаус
<name>Женя</name> сейчас проживает в <city>Москве</city> и работает <job>директором</job>, а в свободное время <hobby>сплавляется на байдарке</hobby>
Родион.City=Ульяновск
Родион.Boroda=true
Каждая из этих записей (про Мишу, Женю и Родиона) — это три отдельных документа. И база данных настолько умна, что может при необходимости распознать, что там где лежит. Если мы запросим у нее Boroda, то она прошерстит все документы и поищет там разметку со словом «Борода». В первых двух документах этой разметки не будет, а в третьем — будет. Именно этот документ нам база данных и вернёт.
Работа с SQL-запросами
Уже по названию видно, что NoSQL не поддерживает SQL-запросы. Это значит, что у каждой такой базы своя методика работы с данными и общего стандарта нет. Не получится выучить операции в Redis, который работает по принципу «ключ-значение» и быстро освоить MongoDB, где всё основано на документах.
Некоторые NoSQL-базы пытаются поддерживать что-то из SQL, но на практике это работает плохо.
Скорость и масштабируемость
Чтобы реляционная база данных могла работать с большим объёмом данных, нужно поставить железо помощнее или добавить несколько копий такой базы, чтобы можно было быстрее читать из неё.
В NoSQL-подходе базу легко разделить между несколькими компьютерами, связанными по сети. Чем больше компьютеров и чем быстрее сеть — тем больше база и скорость работы. Получается, что железо можно оставить тем же, и просто увеличить количество узлов в базе.
Надёжность и безопасность
Реляционная база данных надёжна как скала, в ней не может случиться ничего плохого, потому что она сама за этим следит. А если такое случается, то всегда можно вернуться на шаг назад и восстановить все данные без потерь. За это приходится платить скоростью работы.
NoSQL-базы относятся к этому иначе: они предлагают максимальную скорость работы, а решение всех конфликтов зависит от программиста. Если одну и ту же ячейку хотят изменить два пользователя, а программист этого не предусмотрел, то кто быстрее записал — тот и прав. Поэтому в таких базах нужно отдельно следить за надёжностью и решением конфликтов.
Применение
Обычные SQL-базы отлично подходят для типовых задач, где надёжность и предсказуемость важнее скорости. Например, для записей о пациентах, перемещениях товаров со склада или школьных оценок.
Но если вам нужна скорость, масштаб и большая мощность — посмотрите на NoSQL. Единственный минус — у каждой базы свои правила работы с данными, поэтому быстро перейти от одной к другой не получится.
