Реляционная база перестаёт справляться раньше, чем заканчивается бюджет на железо. Один мощный сервер с Oracle или PostgreSQL держит ровно столько, сколько влезает в его диски и память, а дальше начинается вертикальное масштабирование – дорогое и конечное. Когда трафик растёт быстрее, чем стойки в дата-центре, инженеры идут в сторону NoSQL: хранилищ, которые с самого начала спроектированы под горизонтальное масштабирование на дешёвых узлах. Ниже – три зрелых решения, каждое под свой класс задач. Выбор СУБД – это уже проектирование платформы данных и BI, и определяется он почти всегда не модой, а профилем нагрузки.

Три инструмента – три сценария

MongoDB хранит документы в формате, близком к JSON. Схема не фиксирована: добавить поле – это просто записать его, без ALTER TABLE и простоя. Это удобно для каталогов, профилей, контента, личных кабинетов – там, где структура записи меняется от объекта к объекту и эволюционирует вместе с продуктом. MongoDB даёт богатый язык запросов, индексы по любым полям и автоматический шардинг. Цена компромисса – отказ от классических транзакций между документами и привыкание команды к денормализации вместо JOIN.

Cassandra, выросшая из разработок Facebook и теперь живущая под крылом Apache, решает другую задачу – запись с очень высокой скоростью и доступность без единой точки отказа. Архитектура без мастера: все узлы равноправны, потеря любого не роняет кластер, репликация настраивается вплоть до нескольких дата-центров. Это выбор под потоки событий, логи, метрики, ленты – там, где пишут постоянно и много, а согласованность допускается «в конечном счёте». За скорость записи платят ограниченной моделью запросов: данные раскладывают под заранее известные обращения, ad-hoc аналитика поверх Cassandra идёт тяжело.

HBase – это база поверх Hadoop и HDFS, повторяющая идеи Google BigTable. Её стихия – таблицы в десятки терабайт и пакетная аналитика через MapReduce рядом с оперативным доступом по ключу. Если у вас уже стоит Hadoop-кластер под обработку больших объёмов, HBase встаёт в ту же экосистему естественно. Порог входа выше остальных: нужны ZooKeeper, понимание HDFS и инженеры, которые с этим работали.

Чем платят за масштаб

NoSQL – не «SQL, только быстрее». Отказ от строгой схемы и транзакций перекладывает часть ответственности на приложение. Целостность данных, которую раньше гарантировала СУБД, теперь обеспечивает код, а значит – растёт цена ошибки и требования к тестированию. Денормализованные данные дублируются по узлам, и логику их согласования пишете вы. Это прямо влияет на процесс: регрессионные сценарии и нагрузочные прогоны становятся обязательными, а не желательными – мы об этом писали в материале про тестирование внутри Agile.

Отдельная тема – эксплуатация и защита. Кластер из десятков узлов расширяет периметр атаки, а многие NoSQL по умолчанию идут с открытой сетевой конфигурацией и без аутентификации. История Stuxnet показала, насколько дорого обходится наивное доверие к «внутренней» сети. Для госсектора это означает: шифрование, разграничение доступа и сегментацию проектируют с первого дня, а не докручивают потом.

Вывод

Реляционные базы никуда не уходят и остаются правильным выбором для учёта, финансов и любых данных, где транзакции критичны. NoSQL – инструмент под конкретный профиль нагрузки: документы и гибкая схема ведут к MongoDB, шквал записи и отказоустойчивость – к Cassandra, петабайты и пакетная аналитика – к HBase. Полигласная архитектура, где под каждую задачу стоит своё хранилище, становится нормой – мы относим её к ключевым технологическим трендам 2011 года. Главное – выбирать по нагрузке и считать стоимость эксплуатации, а не повторять чужие решения.