Кратко — определения и ключевые компромиссы, затем рекомендации по выбору.
Определения
- ACID: атомарность, согласованность, изолированность, долговечность — транзакции дают сильную (обычно линейную/сильную) согласованность.
- BASE: “быть доступным, мягко согласованным, в конечном итоге согласуется” — допускает временную рассогласованность ради доступности и масштабируемости (eventual/тunable consistency).
CAP-контекст
- В распределённых системах при наличии разрыва связи (partition) нельзя одновременно иметь и сильную согласованность и высокую доступность: выбирают между $C$ и $A$ при наличии $P$.
Компромиссы (чего стоит ожидать)
- Согласованность:
- ACID: сильная, немедленная согласованность (линейная/сериализуемая или другие строгие уровни).
- BASE: слабая/временная (eventual) или настраиваемая (tunable): чтение может быть устаревшим.
- Доступность:
- ACID: при сетевых разрывах или распределённых транзакциях доступность часто жертвуется (блокировки, отказоустойчивые протоколы).
- BASE: сделана для высокой доступности даже при частичных отказах (репликация с асинхронным обновлением).
- Задержка:
- ACID: выше из‑за синхронной репликации, двухфазного коммита и блокировок (например, минимум $2$ сетевых раунда для двухфазного коммита).
- BASE: ниже при чтениях/записях за счёт асинхронности и локальных ответов (иногда можно читать с одного узла — низкая задержка).
- Масштабирование и пропускная способность:
- ACID: вертикальное масштабирование и сложнее горизонтальное (распределённые транзакции дороже).
- BASE: хорошо масштабируется горизонтально (шардирование, простой репликационный дизайн).
- Сложность разработки и эксплуатации:
- ACID: проще моделировать корректность бизнес‑логики (транзакции гарантируют инварианты).
- BASE: разработчик обязан обрабатывать конфликты, компенсации, идемпотентность, CRDT или стратегии разрешения конфликтов.
- Надёжность и восстановление:
- ACID: сильные гарантии о сохранности данных после подтверждения транзакции.
- BASE: возможна потеря последних неконсистентных состояний до сходимости; требуется механизмы репликации и восстановления.
Когда выбирать ACID
- Критически важная корректность данных: банковские системы, расчёты платежей, бухгалтерия, биллинг, бронирование мест, системы учета запасов, медицинские записи.
- Нужны сложные многоресурсные транзакции и жёсткие инварианты.
- Допустимы более высокие задержки и/или менее простое масштабирование.
Когда выбирать BASE (NoSQL)
- Высокая нагрузка и требование к низкой задержке/высокой доступности: социальные ленты, кэш/сессии, системы аналитики в реальном времени, IoT сбор телеметрии, рекомендательные системы, веб-ретейл (часть функций).
- Допускается временная рассогласованность; есть механизмы компенсации/слияния.
- Нужна лёгкая горизонтальная масштабируемость и устойчивость к частичным отказам.
Практические замечания
- Гибридный подход (polyglot): критичные данные — ACID (RDBMS), менее критичные — BASE (NoSQL).
- Многие NoSQL системы предлагают «настраиваемую» согласованность (например, параметры чтения/записи: ONE, QUORUM, ALL) — выбор между задержкой и согласованностью.
- Для BASE можно использовать CRDT, конфликто‑разрешение на уровне приложения, идемпотентные операции и компенсационные транзакции, чтобы снизить риск ошибок.
Краткая сводка
- ACID = сильная согласованность, меньшая доступность и выше задержка/сложность при масштабировании — выбирайте для критичных транзакций.
- BASE = высокая доступность и масштабируемость, низкая задержка, допускается временная рассогласованность — выбирайте там, где это приемлемо.