NoSQL

Термин закрепился в конце 2000-х, когда крупные веб-сервисы упёрлись в пределы одной реляционной базы: данных стало слишком много, а структура менялась быстрее, чем успевали писать миграции. Появились системы, которые проще распределить по многим серверам и которые не требуют заранее описывать схему. Название читают как «not only SQL» — «не только SQL»: многие такие базы со временем получили свои языки запросов, а реляционные научились хранить JSON.

Четыре основных семейства

• Документные (MongoDB, CouchDB) хранят объекты, похожие на JSON. У каждого документа может быть свой набор полей.
• Ключ — значение (Redis, Memcached) работают как огромный словарь: по ключу мгновенно отдают значение. Их используют для сессий, очередей и кеша.
• Колоночные (Cassandra, HBase) рассчитаны на огромные объёмы записи: журналы, метрики, события.
• Графовые (Neo4j) хранят узлы и связи между ними: соцсети, рекомендации, маршруты.

Пример документа и запроса

Карточка товара с разным набором характеристик ложится в документ естественно, без десятка вспомогательных таблиц:

{
  "sku": "SOFA-204",
  "name": "Диван угловой",
  "price": 48900,
  "attrs": { "color": "серый", "mechanism": "дельфин" }
}

db.products.find({ "attrs.color": "серый" })

Вторая строка — запрос в оболочке MongoDB: найти все серые товары, даже если у части из них поля цвета нет вовсе.

Когда реляционная база всё же лучше

Заказы, оплаты, остатки — данные, где важны связи и целостность. Здесь нужны транзакции и ограничения, которые не дадут списать товар дважды. Реляционные СУБД с языком SQL делают это давно и надёжно. Поэтому на практике базы сочетают: MySQL или MariaDB хранит основное, а Redis рядом ускоряет сайт. Именно так устроен объектный кеш в WordPress: плагин складывает результаты запросов в Redis, а данные остаются в MySQL. Выбирать NoSQL только потому, что «так модно», — частая ошибка: потом приходится вручную писать проверки, которые реляционная база дала бы бесплатно.