Кратко и по делу — критерии выбора и компромиссы для трёх типов систем.
Общие критерии (применяются при оценке каждого варианта)
- Требование целостности/атомарности операций (транзакции, двойные записи, баланс счёта).
- Точки согласованности (сколько и как быстро можно допустить рассинхронизацию).
- Объём и характер нагрузки: write-heavy vs read-heavy, TPS, пиковые нагрузки.
- Топология: одна зона vs географически распределённые клиенты.
- Запросы и модель данных: сложные агрегаты/джоины ↔ реляционная модель; простые ключ‑значение / документоориентированные паттерны ↔ NoSQL.
- Латентность и требуемое SLA на отклик.
- Требования к архивированию, аудиту и соответствию (регуляторы, чек-листы).
- Операционная сложность и стоимость (шкалирование, резервирование, разработка).
- Устойчивость к разрывам сети (partition tolerance) и поведение в таких случаях.
1) Интернет-банкинг — рекомендуем: реляционная СУБД с ACID (или распределённая strongly-consistent БД)
- Почему: критичны точность балансов, атомарность переводов, сильный аудит, антимошенничество, регуляторные требования.
- Когда можно рассмотреть NoSQL: только для не критичных вспомогательных сервисов (кеши, аналитика, ленты уведомлений).
- Конкретные критерии выбора RDBMS: транзакции уровня ACID, консистентные реплики, детерминированные корректные откаты, сложные запросы/отчёты.
- Компромиссы (CAP/шкала):
- В условиях сетевых разделений выбираем C+P (Consistency + Partition tolerance) — жертвуем доступностью: в разделениях операции могут блокироваться/отклоняться, чтобы не нарушить консистентность.
- Масштабируемость: вертикальное/шардинг с сложной логикой; сложнее достичь линейной горизонтальной масштабируемости по сравнению с eventual-consistent NoSQL.
- Итог: сильная согласованность, низкая допустимая рассинхронизация, более жёсткие требования к доступности в экстремальных условиях.
2) Социальная сеть — рекомендуем: распределённое NoSQL с eventual consistency для основной ленты; RDBMS/TC для критичных ролей
- Почему: большая распределённость, очень высокая пропускная способность, допускается кратковременное «устаревание» данных (например, ленты, лайки), гибкая схема.
- Когда нужен RDBMS: транзакции с деньгами/платными функциями, управление доступом/безопасность — части, где нужна сильная консистентность.
- Критерии выбора NoSQL: высокая запись/чтение, горизонтальная масштабируемость, репликация по регионам, низкая латентность, упрощённая модель данных.
- Компромиссы (CAP/шкала):
- Для основной ленты обычно выбирают A+P (Availability + Partition tolerance) с eventual consistency — система остаётся доступной при разделе, но данные могут быть временно рассинхронизированы.
- Последовательность/упорядоченность событий и строгие транзакции сложны; некоторые операции придётся реализовывать компенсирующими механиками.
- Итог: отдаём приоритет доступности и масштабируемости, принимая допустимое рассогласование и компликации в коде.
3) IoT‑платформа — гибридный подход: NoSQL для телеметрии/информационного потока, strong-consistency для команд управления и биллинга
- Почему: миллионы устройств генерируют большой объём временных рядов (требуется высокая пропускная способность и хранение), но команды управления/конфигурации требует согласованности.
- Критерии:
- Для телеметрии: write-heavy, append-only, большие объёмы, геораспределённость, допустима eventual consistency и потеря небольшого объёма данных (в отдельных сценариях) → NoSQL/TSDB.
- Для управления/контроля/платежей: низкая толерантность к рассинхронизации, требуются подтверждения и транзакции → ACID-хранилище или strongly-consistent ключ‑значение.
- Требования к офлайн‑устройствам: буферизация на устройстве, повторная доставка, conflict-resolution.
- Компромиссы (CAP/шкала):
- Телеметрия: A+P — высокая доступность и масштабируемость, согласованность eventual.
- Управляющий канал: C+P — консистентность важнее доступности (команды могут требовать подтверждения, блокировка при разделениях).
- Итог: разделение по функциональности — масштабируемое NoSQL для данных наблюдения, строгая согласованность для критичных операций.
Короткое резюме компромиссов (универсально)
- ACID/RDBMS: сильная согласованность, удобные транзакции и сложные запросы, сложнее горизонтально масштабировать, в условиях сетевых разделений обычно жертвует доступностью.
- Eventual‑consistent NoSQL: высокая доступность и простая горизонтальная масштабируемость, упрощённая модель данных, допустимая временная рассинхронизация и дополнительная сложность в логике разрешения конфликтов.
- Практика: для больших систем часто используют гибрид — критичные операции на консистентном хранилище, аналитика/логи/телеметрия на eventual‑consistent кластерах.