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

Введение

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

Четыре типа NoSQL

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

Когда брать NoSQL

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

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

А когда SQL

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

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

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

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

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

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

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

Автор статьи: Клавдия Кондакова