NoSQL базы данных: типы и когда их брать

Введение

NoSQL это не «без SQL», а «не только SQL»: базы без жёсткой табличной схемы, заточенные под горизонтальное масштабирование и гибкую структуру данных. Реляционные базы вроде PostgreSQL никуда не делись, но для части задач NoSQL проще и быстрее.

Четыре типа NoSQL

Документные (MongoDB): JSON-подобные документы, удобно для каталогов и профилей. Key-value (Redis): сверхбыстрое хранилище по ключу, кэш и сессии. Колоночные (Cassandra): огромные разреженные таблицы и запись миллионами строк. Графовые (Neo4j): связи как данные первого класса, соцграфы и рекомендации.

Когда брать NoSQL

Три честных сигнала: структура данных меняется чаще, чем раз в квартал; нагрузка растёт горизонтально и шардировать реляционную базу больно; записи важнее сложных джойнов (ленты, каталоги, телеметрия).

Отдельный случай это кэш: Redis перед SQL базой снимает до 90 процентов чтений одной строчкой кода.

А когда SQL

Деньги, склад и всё, где нужна транзакция через несколько сущностей, остаются за реляционными базами. ACID, внешние ключи и декларативные запросы это то, за что SQL любят уже пятьдесят лет.

Частый рабочий вариант гибрид: система записи на SQL, витрины чтения на NoSQL, между ними очередь или репликация.

Моделирование без таблиц

Главная ошибка новичков тащить реляционное мышление: нормализовать документы и собирать их джойнами на приложении. Проектируйте от запросов: один экран — один документ, денормализация это норма, а не грех. Дублирование адреса в тысяче заказов дешевле тысячи джойнов при каждом показе.

Версионируйте схему в коде (поле v: 2), чтобы читать старые и новые документы одним ридером, и мигрируйте лениво при записи.

Эксплуатация

Распределённые базы требуют думать о консистентности заранее: eventual consistency означает, что свежезаписанное видно не всем сразу — проектируйте UI с этим допущением. Мониторьте lag репликации и рост компакшенов, а бэкапы снимайте со вторичных узлов, чтобы не душить мастер.