sottoЗачем понадобился NoSQL
Реляционные БД десятилетиями были выбором по умолчанию: строгая схема, транзакции, ad-hoc SQL. Проблемы начались при веб-масштабе — когда данных и запросов столько, что один сервер не справляется, а вертикальное масштабирование упирается в потолок и цену.
NoSQL — зонтичный термин для хранилищ, которые жертвуют частью возможностей реляционной модели (богатые join, строгая схема, сильные транзакции) ради горизонтального масштабирования, гибкой схемы и предсказуемой производительности на огромных объёмах.
Поэтому «NoSQL лучше SQL» — неверная рамка. Правильная: какой профиль данных и запросов у задачи, и какое хранилище под него заточено.
Моделирование от access patterns
Главный сдвиг мышления: в реляционной БД сначала нормализуют данные, а запросы пишут потом; в NoSQL сначала фиксируют запросы, а данные раскладывают так, чтобы каждый запрос обслуживался дёшево — часто с денормализацией и дублированием.
Следствие: один и тот же домен в разных хранилищах моделируется по-разному, и поменять access pattern постфактум дорого. Поэтому в NoSQL цена ошибки в модели выше.
Четыре семейства
Document (MongoDB) — данные как самодостаточные документы (JSON/BSON), гибкая схема, удобно читать агрегат целиком. Key-value (Redis, DynamoDB) — простейшая модель «ключ → значение», максимум скорости по ключу. Wide-column (Cassandra, HBase) — таблицы с гибкими колонками, заточены под огромную запись и запросы по ключу партиции. Graph (Neo4j) — узлы и рёбра для сильно связанных данных и обходов.
Отдельно стоят базы временных рядов (InfluxDB, TimescaleDB) и поисковые движки (Elasticsearch) — узкоспециализированные под свои паттерны, каждому посвящён отдельный урок.
BASE против ACID
Многие NoSQL отказываются от строгого ACID в пользу BASE: Basically Available, Soft state, Eventual consistency. Система всегда отвечает, состояние может временно расходиться между репликами, но со временем сходится.
Это осознанный компромисс ради доступности и масштаба. Современные NoSQL часто возвращают часть гарантий (атомарность документа, настраиваемые кворумы, транзакции), поэтому «NoSQL = нет транзакций» — устаревшее упрощение.
Горизонтальное масштабирование
NoSQL изначально рассчитан на sharding (разбиение данных по узлам по ключу) и репликацию (копии для отказоустойчивости и чтения). Выбор ключа шардирования критичен: плохой ключ создаёт «горячие» партиции и перекос нагрузки.
Реляционные БД тоже шардируют, но это сложнее и обычно делается вручную поверх; в NoSQL распределение — встроенное свойство.
Когда NoSQL не нужен
Если данные сильно связаны, нужны произвольные ad-hoc отчёты и сильные транзакции, а объём умеренный — реляционная БД проще и надёжнее. Брать NoSQL «чтобы не думать о схеме» — частая дорогая ошибка: схема всё равно есть, просто она переезжает в код.
Реальные системы часто polyglot: PostgreSQL как источник истины + Redis для кэша + Elasticsearch для поиска, каждый под свой паттерн.
Как отвечать на собеседовании
Сильный ответ: назовите четыре семейства и их профиль, объясните моделирование от access patterns и компромисс BASE/ACID, и подчеркните, что выбор идёт от требований (масштаб, связи, согласованность), а не от моды.
Первым делом сломайте рамку «что лучше, SQL или NoSQL» — это вопрос-ловушка. Правильная постановка: какой профиль данных и запросов у задачи и какое хранилище под него заточено. Кандидат, который отвечает «зависит от» и тут же говорит, ОТ ЧЕГО именно, выигрывает у того, кто выбирает сторону.
Главный содержательный тезис — сдвиг в моделировании: в реляционной БД сначала нормализуют данные, а запросы пишут потом; в NoSQL сначала фиксируют запросы, а данные раскладывают под них, часто с дублированием. И сразу назовите цену: поменять access pattern постфактум дорого, поэтому цена ошибки в модели здесь выше.
Семейства перечисляйте с профилем нагрузки, а не с названиями продуктов: document — самодостаточный агрегат читается целиком; key-value — максимум скорости по ключу; wide-column — огромная запись и чтение по ключу партиции; graph — обходы сильно связанных данных.
Про BASE не ограничивайтесь расшифровкой аббревиатуры: скажите, что это осознанный обмен строгих гарантий на доступность и масштаб, и обязательно добавьте, что «NoSQL = нет транзакций» — устаревшее упрощение (атомарность документа, настраиваемые кворумы, транзакции в современных версиях).
Завершите там, где ответ звучит зрело: назовите, когда NoSQL НЕ нужен — связанные данные, ad-hoc отчёты, сильные транзакции, умеренный объём. И упомяните polyglot-реальность: PostgreSQL как источник истины, Redis для кэша, Elasticsearch для поиска — каждый под свой паттерн.