Кратко и по сути — сравнение по свойствам, типичным задачам и компромиссам.
Основные характеристики
- Реляционные СУБД (RDBMS)
- Модель: строгая схема, таблицы, нормализация, связи (JOIN).
- Гарантии: транзакции и сильная консистентность (ACID).
- Масштабирование: обычно вертикальное или сложное горизонтальное (sharding/partitioning).
- Поддержка запросов: сложные SQL‑запросы, агрегаты, индексы, аналитика.
- Ограничения: жёсткая схема, сложнее масштабировать на очень большие распределённые нагрузки, медленнее при массовых распределённых записях.
- Нереляционные (NoSQL)
- Типы: key–value, document, wide‑column, graph.
- Модель: гибкая/без схемы, часто денормализованные документы/строки.
- Гарантии: обычно weaker/BASE — eventual или настраиваемая консистентность; транзакции ограничены или распределённые с оговорками.
- Масштабирование: горизонтальное, проектированы для шардирования и репликации.
- Поддержка запросов: простые ключевые операции, агрегация зависит от движка; сложные многотабличные JOIN’ы неэффективны.
- Ограничения: сложнее обеспечить строгую согласованность и сложные аналитические запросы; операции обновления множества денормализованных копий усложняют логику.
CAP и выбор компромиссов
- CAP: одновременно нельзя гарантировать все три свойства $C,A,P$. При сетевых разрывах приходится выбирать между консистентностью и доступностью.
- RDBMS обычно проектируются в сторону сильной консистентности (CP): при partition‑событии предпочитают сохранить согласованность, падает доступность.
- Многие NoSQL‑системы делают упор на доступность и отказоустойчивость (AP) с eventual consistency; некоторые дают настраиваемую/кворумную консистентность (т.е. компромисс: на чтение/запись можно выбирать уровень).
- Репликация/архитектуры:
- Лидер‑реплика (primary‑secondary) даёт сильную консистентность для мастера, но при падении лидера возможна недоступность или сложный failover.
- Leaderless (Dynamo/Cassandra) использует кворумы для гибкой настройки консистентности/доступности.
Типовые сценарии и рекомендации
- Использовать RDBMS если:
- Нужна строгая корректность данных и транзакции (банковские операции, бухгалтерия).
- Требуются сложные запросы/отчёты и связи между сущностями.
- Нагрузка укладывается в вертикальное или управляемое горизонтальное масштабирование.
- Использовать NoSQL если:
- Нужна высокая пропускная способность и линейное горизонтальное масштабирование (лог событий, телеметрия, большой поток записей).
- Данные полуструктурированы и схема изменяется часто (профили пользователей, документы).
- Требуется геораспределённость и низкая задержка глобальных чтений/записей.
- Можно допустить eventual consistency или реализовать компенсирующую логику.
Дополнительные замечания
- Денормализация в NoSQL улучшает чтение, усложняет обновления; в RDBMS нормализация упрощает согласованность, но может снижать скорость чтения.
- Современные системы (NewSQL, распределённые SQL: Spanner, CockroachDB) стараются сочетать горизонтальное масштабирование с транзакциями и сильной консистентностью.
- Часто применяется полиглотное хранение: RDBMS для критичных транзакций, NoSQL для масштабируемых частей приложения.
Выбор зависит от требований по консистентности, латентности, объёму данных и типу запросов: строгая целостность → RDBMS; масштаб и гибкость схемы → NoSQL; если нужно и то и другое — рассмотреть распределённые SQL или гибридный подход.