Реляционная СУБД – рабочая лошадь корпоративных систем, и в большинстве проектов она остаётся правильным выбором. Но мы регулярно видим один и тот же сценарий: система росла на PostgreSQL или Oracle, нагрузка выросла на порядок, и теперь каждая новая фича упирается в схему, блокировки и стоимость вертикального масштабирования. NoSQL – не модный ярлык, а инструмент под конкретный профиль нагрузки. Разберём, когда он реально снимает ограничение, а когда добавляет проблем.
Где реляционная модель упирается в потолок
Три симптома, по которым мы рекомендуем смотреть в сторону NoSQL.
Первый – объём записи, который не помещается в один сервер. Логи событий, телеметрия устройств, потоки от фронтенда госуслуг: десятки тысяч вставок в секунду, при которых индексы и журнал транзакций становятся узким местом. Шардирование реляционной базы вручную – это самописный слой, который потом некому сопровождать.
Второй – схема, которая меняется быстрее релизного цикла. Когда продукт перебирает структуру записи раз в спринт, миграции ALTER TABLE на таблице в сотни миллионов строк блокируют систему. Документная модель снимает этот класс проблем: структуру задаёт приложение, а не DDL.
Третий – модель данных, которая по природе не табличная. Граф связей абонентов, дерево вложенных каталогов, разреженные атрибуты товаров в маркетплейсе. Уложить такое в третью нормальную форму можно, но каждый запрос превращается в каскад джойнов.
Какой класс NoSQL под какую задачу
«NoSQL» – это четыре разных семейства, и выбор внутри них важнее самого факта отказа от SQL.
Ключ-значение (Redis, Riak) – кэши, сессии, счётчики, очереди. Минимальная латентность, но вся логика выборки на стороне приложения. Хорошо ложится поверх существующей реляционной базы как слой ускорения, не заменяя её.
Документные (MongoDB, CouchDB) – каталоги, профили, контент с переменной структурой. Запись и чтение одного агрегата за одну операцию, без джойнов. Цена – отказ от транзакций между документами, поэтому границы агрегата надо проектировать заранее.
Колоночные (Cassandra, HBase) – большие объёмы записи с предсказуемыми запросами по ключу. Линейное горизонтальное масштабирование, но модель данных проектируют от запросов, а не от сущностей. На этом классе хранилищ строятся аналитические платформы и витрины данных под высокую нагрузку, в том числе под задачи предсказательной аналитики.
Графовые (Neo4j) – антифрод, рекомендации, анализ связей. Если ядро задачи – обход графа, реляционная база проигрывает на порядки.
Чего стоит переход в эксплуатации
Главная ошибка – считать NoSQL заменой реляционной СУБД «один в один». В реальности это почти всегда полиглот-персистенс: транзакционное ядро остаётся в SQL, а отдельные нагруженные сценарии выносятся в специализированное хранилище. Это значит два контура согласованности данных и интеграцию между ними. Здесь критична зрелая шина обмена – мы подробно разбирали, почему ESB лучше прямых точечных интеграций, когда источников данных становится больше двух.
Второй риск – эксплуатация. Распределённое хранилище без транзакций требует другой культуры: продуманного бэкапа, мониторинга реплик, отработки сетевых разрывов. Менять схему хранения в продакшене без отлаженного пайплайна развёртывания опасно, поэтому переход мы начинаем только на проектах с настроенной непрерывной поставкой.
Вывод
NoSQL решает конкретные проблемы масштаба и гибкости, но не отменяет реляционную базу. Начинайте с профиля нагрузки и одного болезненного сценария, выносите его в подходящий класс хранилища и оставляйте транзакционное ядро на SQL. Технология, выбранная под задачу, снимает ограничение роста – выбранная под моду, добавляет ещё одну систему в эксплуатацию.
