Теорема CAP (также известная как теорема Бревера) утверждает, что распределенная система баз данных может гарантировать только два из трех свойств одновременно:
- C – Консистентность (Consistency)
- A – Доступность (Availability)
- P – Устойчивость к разделению (Partition Tolerance)
📌 Невозможно иметь все три свойства одновременно!
💡 В распределенной базе данных вам необходимо пожертвовать либо консистентностью, либо доступностью при возникновении разделения сети.
1. Треугольник теоремы CAP
📌 Теорема CAP заставляет делать компромиссы при проектировании распределенных баз данных.
2. Свойства теоремы CAP
1️⃣ Консистентность (C)
✅ Все узлы всегда возвращают одинаковые актуальные данные.
✅ Если один узел получает запись, все узлы должны отразить это изменение до выполнения операции чтения.
🔹 Пример:
Пользователь обновляет свою фотографию профиля.
Все узлы должны немедленно вернуть новую фотографию при запросе.
🚨 Проблема: Это может замедлить систему из-за необходимости синхронизации.
2️⃣ Доступность (A)
✅ Каждый запрос получает ответ, даже если данные устарели.
✅ Система всегда работает, но данные могут не быть на 100% синхронизированы.
🔹 Пример:
Корзина покупок доступна, даже если один из узлов базы данных не работает.
Некоторые последние транзакции могут быть пропущены, но сервис доступен.
🚨 Проблема: Клиенты могут получать устаревшие данные.
3️⃣ Устойчивость к разделению (P)
✅ Система продолжает работать несмотря на сбои в сети.
✅ Даже если некоторые узлы базы данных не могут обмениваться данными, система остается работоспособной.
🔹 Пример:
Глобальное приложение (например, Netflix, Amazon) работает на нескольких дата-центрах.
Если один регион теряет связь, приложение продолжает обслуживать пользователей из других регионов.
🚨 Проблема: Необходимо выбирать между консистентностью и доступностью.
3. Как теорема CAP применяется к базам данных
| Тип базы данных | Выбор CAP | Примеры |
|---|---|---|
| CP (Консистентность + Устойчивость к разделению) | Обеспечивает консистентность данных, даже если узлы выходят из строя, но может жертвовать доступностью. | Bigtable, HBase, MongoDB (режим сильной консистентности), Google Spanner |
| AP (Доступность + Устойчивость к разделению) | Всегда отвечает, даже с устаревшими данными, но жертвует консистентностью. | Cassandra, DynamoDB, CouchDB, Riak |
| CA (Консистентность + Доступность) | Работает только в базах данных с одним узлом (не распределенные). | Традиционные SQL базы данных (PostgreSQL, MySQL, Oracle в автономном режиме) |
4. Теорема CAP в реальных системах
| Сценарий | Что важнее? | Выбор CAP |
|---|---|---|
| Банковская система | Транзакции должны всегда быть правильными | CP (Сильная консистентность) |
| Лента социальных сетей | Ничего страшного, если пользователи увидят слегка устаревшие посты | AP (Высокая доступность) |
| Инвентаризация в электронной коммерции | Консистентность важна, но доступность имеет приоритет | AP (Высокая доступность, Ожидаемая консистентность) |
5. Компромиссы теоремы CAP
💡 В распределенной системе вам нужно выбрать:
- CP (Консистентность + Устойчивость к разделению) → Сильная целостность данных, но может замедлить доступность.
- AP (Доступность + Устойчивость к разделению) → Быстрый отклик, но может вернуть устаревшие данные.
- CA невозможен в распределенных системах, потому что сети могут выйти из строя в любой момент.
6. Заключительные выводы
✅ Теорема CAP применима только к распределенным базам данных.
✅ Большинство современных NoSQL баз данных жертвуют строгой консистентностью в пользу доступности и устойчивости к разделению.
✅ SQL базы данных, совместимые с ACID, обычно предпочитают CP.
✅ Базы данных, основанные на модели BASE (Ожидаемая консистентность), предпочитают AP.