NoSQL и выбор хранилища за 6 минут

NoSQL это не одна технология, а все базы, которые не построены вокруг реляционной модели и SQL. Вопрос на собесе почти всегда звучит так: «что бы ты выбрал и почему».

Основные семейства

• Key-value: Redis, Memcached, DynamoDB (в простом режиме). Доступ по ключу за O(1). Кеш, сессии, счётчики, rate limiting.
• Документные: MongoDB, Couchbase. Хранят JSON-подобные документы, схема гибкая, связанные данные часто вкладывают в один документ.
• Колоночные (wide-column): Cassandra, ScyllaDB, HBase. Огромные объёмы записи, данные раскладываются по партициям по ключу, запросы проектируют заранее под ключ партиции.
• Аналитические колоночные: ClickHouse. Хранят данные по колонкам, быстро считают агрегаты по миллиардам строк. Плохо подходят для точечных обновлений.
• Поисковые: Elasticsearch, OpenSearch. Обратный индекс, полнотекстовый поиск, фасеты.
• Графовые: Neo4j. Связи как первоклассные объекты, обход на много шагов.
• Time-series: Prometheus, VictoriaMetrics, TimescaleDB (расширение PostgreSQL). Метрики по времени.

Redis подробнее

Хранит данные в памяти, однопоточный по выполнению команд, поэтому каждая команда атомарна. Структуры: строки, хеши, списки, множества, отсортированные множества (лидерборды), стримы. SET key value NX EX 30 атомарно ставит ключ, только если его нет, с TTL 30 секунд: основа простой распределённой блокировки. Персистентность через RDB-снимки и AOF-журнал, но как основную базу для критичных данных его обычно не используют.

SQL против NoSQL: честное сравнение

Реляционная база (PostgreSQL) даёт транзакции на несколько таблиц, JOIN, строгую схему, ограничения целостности, богатый SQL. И jsonb с GIN-индексами закрывает многие случаи «нам нужна гибкая схема».

NoSQL выбирают, когда:

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

Платим обычно ослабленной консистентностью, отсутствием JOIN (денормализация в коде), сложностью смены модели доступа.

Масштабирование

• Репликация: копии данных на нескольких узлах. Leader-follower: пишем в лидера, читаем с реплик, есть задержка репликации. Leaderless (Cassandra): пишем в несколько узлов, кворум R + W > N даёт чтение свежей записи.
• Шардирование: данные делятся между узлами по ключу. Выбор ключа шардирования решает всё: плохой ключ даёт горячий шард. Запросы без ключа шардирования идут во все шарды.

Как выбирать на собесе

1. Какие данные и связи между ними.
2. Какие запросы: по ключу, по диапазону, агрегаты, поиск.
3. Соотношение чтения и записи, объём, рост.
4. Какая консистентность нужна (деньги против ленты лайков).
5. Что команда умеет эксплуатировать.

По умолчанию разумный ответ: PostgreSQL как основная база, Redis как кеш, специализированные хранилища там, где PostgreSQL явно не справляется.

Частые ошибки

• «MongoDB быстрее, потому что NoSQL».
• Выбор Cassandra без понимания, что запросы проектируются под ключ партиции.
• Redis как единственное хранилище денег.
• Игнорировать jsonb в PostgreSQL как альтернативу документной базе.

Что спросят на собесе

• Какие бывают NoSQL-базы, примеры задач для каждой.
• Когда выбрать PostgreSQL, а когда MongoDB или Cassandra.
• Для чего Redis и почему его команды атомарны.
• Что такое репликация и шардирование, как выбрать ключ шардирования.
• Что значит кворум R + W > N.