NoSQL перестал быть экзотикой. Когда объём данных растёт быстрее, чем успевает справляться одна машина с реляционной СУБД, на сцену выходят MongoDB, Cassandra и HBase. Все три называют «NoSQL», но решают они разные задачи. Выбор наугад обходится дорого: переезд с одной системы на другую означает переписывание схемы доступа и часто всего прикладного кода. Разберём, под какие сценарии заточена каждая.
Три разные модели данных
MongoDB хранит документы в формате BSON. Структура гибкая, запросы богатые: фильтры по вложенным полям, вторичные индексы, агрегации. Это ближе всего к привычной разработке – особенно когда мы делаем веб-сервис и данные естественно ложатся в документы. Подробнее об этом сценарии мы писали в заметке про NoSQL для веб-приложений.
Cassandra – это распределённая таблица «ключ – колонки» без единой точки отказа. Все узлы равноправны, запись идёт в любой из них. Модель данных приходится проектировать от запросов: сначала вы решаете, как будете читать, и только потом раскладываете данные. Зато линейное масштабирование и предсказуемая запись на сотнях узлов.
HBase живёт поверх Hadoop и HDFS. Это колоночное хранилище для очень больших таблиц, тесно связанное с пакетной обработкой через MapReduce. Если у вас уже есть кластер Hadoop и аналитика на нём, HBase встраивается в этот стек естественно. В одиночку, без Hadoop, его разворачивать смысла мало.
Согласованность и отказоустойчивость
Здесь проходит главная граница выбора. Cassandra и HBase по-разному расставляют акценты теоремы CAP.
Cassandra настраивает уровень согласованности на каждый запрос: можно потребовать кворум, можно довольствоваться одной репликой ради скорости. Система остаётся доступной на запись, даже когда часть узлов недоступна. Это ценно для нагрузок, где терять записи нельзя, а небольшая рассинхронизация допустима.
HBase даёт строгую согласованность по строке: чтение всегда видит последнюю запись. Но координация идёт через мастер-узлы и Zookeeper, и отказ региона приводит к короткой недоступности соответствующих данных. Для финансовых и учётных операций такая модель предсказуемее.
MongoDB в текущих версиях опирается на реплику-сет с одним первичным узлом. Запись идёт в первичный, при его падении происходит автоматический перевыбор. Шардинг есть, но эксплуатировать его сложнее, чем равномерный кластер Cassandra.
Что это значит для корпоративных и государственных проектов
Для госсектора важны предсказуемость, аудит и работа на собственной инфраструктуре. Все три системы – открытый код, разворачиваются в своём ЦОД, без привязки к зарубежному облаку. Это снимает часть вопросов с размещением данных, которые мы уже учитывали в проекте по выпуску УЭК.
Практический ориентир такой. Нужны гибкие документы и быстрый старт сервиса – берите MongoDB. Нужна постоянная запись огромных потоков с геораспределением и без простоев – Cassandra. Нужна аналитика поверх Hadoop и колоночные таблицы на петабайты, как при хранении видеоархивов – HBase.
NoSQL не отменяет реляционные СУБД, а дополняет их там, где те упираются в потолок. Выбор хранилища – это решение об архитектуре доступа к данным на годы вперёд, а не просто смена технологии.
Вывод
Не существует «лучшей» NoSQL-базы – есть подходящая под профиль нагрузки. Сначала определите модель доступа, требования к согласованности и эксплуатационную готовность команды, и только потом выбирайте систему. Выбор хранилища – это первый шаг к построению аналитики и работе с данными, а не отдельная техническая задача.
