🔵 BASE
BASE (Basically Available, Soft state, Eventually consistent) — подход к проектированию распределённых систем
Жертвует строгой согласованностью (ACID) ради доступности, масштабируемости и гибкости
Когда используют
💠NoSQL-системы (Cassandra, MongoDB)
💠высоконагруженные сервисы (соцсети, аналитика)
💠системы, где важнее скорость ответа и отказоустойчивость, чем мгновенная актуальность данных
Три принципа BASE
😃asically Available (базовая доступность)
Система всегда отвечает, даже при частичных сбоях
Данные могут быть неактуальными, но запросы не блокируются
✏️ Как достигается
✨репликация (копирование данных на несколько узлов)
✨шардирование (данные делятся между кластерами)
✨кэширование
😓oft State (гибкое состояние)
Данные могут меняться со временем без внешних запросов
И могут временно находиться в несогласованном состоянии из-за асинхронных обновлений
✏️ Как достигается
✨асинхронная синхронизация
✨TTL (время жизни данных, например, обновление кэша раз в 5 мин)
✨фоновые процессы согласования
😶🌫️ventually Consistent (окончательная согласованность)
Система придет к согласованности, но не мгновенно
✏️ Как достигается
✨конфликт-разрешающие алгоритмы (например, CRDT, LWW)
✨подтверждение записи от большинства узлов (в Cassandra)
✨Read-Repair (исправление устаревших данных при следующих чтениях)
✨Kafka или RabbitMQ с отложенной синхронизацией
BASE vs ACID vs CAP
⭐ACID — как банковский перевод: либо деньги ушли и пришли полностью, либо операция отменена. Для систем, где важна точность (платежи, бухгалтерия)
⭐BASE — как почта: письмо точно ушло, но когда дойдёт — неизвестно
БД не может быть и ACID и BASE одновременно
Это противоположные подходы
Но некоторые гибридные СУБД (например, MongoDB) позволяют гибко настраивать уровень согласованности
⭐CAP — определяет фундаментальные ограничения распределённых систем
⭐BASE — практический подход в рамках этих ограничений
CAP-теорема: система может гарантировать только 2 из 3 свойств:
💠 cогласованность
💠 доступность
💠 устойчивость к разделению
✔ ACID выбирает CP (согласованность + устойчивость)
✔ BASE - AP (доступность + устойчивость)
✔ CA-системы (консистентность и доступность) возможны только в нераспределенных системах
Пример реализации BASE
Онлайн-магазин с высокой нагрузкой
😃: пользователь добавляет товар в корзину → система сразу подтверждает действие, даже если часть серверов перегружена
Товар появляется в корзине, но остатки на складе могут обновиться с небольшой задержкой
➡️ отправка запроса → API сразу возвращает успех (202 Accepted)
😓: данные о корзине и об остатках лежат в разных сервисах
Если два покупателя одновременно добавляют последний товар → оба увидят его в корзине, но физически доступен только 1
➡️ сервис корзин (Redis) временно сохраняет изменения
Сервис склада (Kafka + PostgreSQL) асинхронно проверяет остатки
😶🌫️: через несколько сек система проверяет остатки и синхронизирует данные
➡️ если товара нет, система убирает из корзины и отправляет уведомление
😃В ACID система заблокировала бы остатки при добавлении в корзину → очереди и ошибки под нагрузкой
BASE позволяет сначала принять действие, потом проверить ограничения
Это критично для высоконагруженных сценариев
📎 Материалы
1. BASE
2. Как бы я сейчас объяснил молодому себе… зачем существуют требования ACID для баз данных?
3. Требования ACID. BASE модель. CAP теорема
4. БАЗОВАЯ модель разработки БД
5. NoSQL: что это такое, отличие от других баз данных, BASE
📚Базы данных. Инжиниринг надежности - Кэмпбелл Лейн, Мейджорс Черити (Глава 11. BASE)
#бд
➿➿➿➿➿➿➿➿
🧑🎓 Больше полезного в базе знаний по системному анализу
BASE (Basically Available, Soft state, Eventually consistent) — подход к проектированию распределённых систем
Жертвует строгой согласованностью (ACID) ради доступности, масштабируемости и гибкости
Когда используют
💠NoSQL-системы (Cassandra, MongoDB)
💠высоконагруженные сервисы (соцсети, аналитика)
💠системы, где важнее скорость ответа и отказоустойчивость, чем мгновенная актуальность данных
Три принципа BASE
😃asically Available (базовая доступность)
Система всегда отвечает, даже при частичных сбоях
Данные могут быть неактуальными, но запросы не блокируются
✏️ Как достигается
✨репликация (копирование данных на несколько узлов)
✨шардирование (данные делятся между кластерами)
✨кэширование
😓oft State (гибкое состояние)
Данные могут меняться со временем без внешних запросов
И могут временно находиться в несогласованном состоянии из-за асинхронных обновлений
✏️ Как достигается
✨асинхронная синхронизация
✨TTL (время жизни данных, например, обновление кэша раз в 5 мин)
✨фоновые процессы согласования
😶🌫️ventually Consistent (окончательная согласованность)
Система придет к согласованности, но не мгновенно
✏️ Как достигается
✨конфликт-разрешающие алгоритмы (например, CRDT, LWW)
✨подтверждение записи от большинства узлов (в Cassandra)
✨Read-Repair (исправление устаревших данных при следующих чтениях)
✨Kafka или RabbitMQ с отложенной синхронизацией
BASE vs ACID vs CAP
⭐ACID — как банковский перевод: либо деньги ушли и пришли полностью, либо операция отменена. Для систем, где важна точность (платежи, бухгалтерия)
⭐BASE — как почта: письмо точно ушло, но когда дойдёт — неизвестно
БД не может быть и ACID и BASE одновременно
Это противоположные подходы
Но некоторые гибридные СУБД (например, MongoDB) позволяют гибко настраивать уровень согласованности
⭐CAP — определяет фундаментальные ограничения распределённых систем
⭐BASE — практический подход в рамках этих ограничений
CAP-теорема: система может гарантировать только 2 из 3 свойств:
💠 cогласованность
💠 доступность
💠 устойчивость к разделению
✔ ACID выбирает CP (согласованность + устойчивость)
✔ BASE - AP (доступность + устойчивость)
✔ CA-системы (консистентность и доступность) возможны только в нераспределенных системах
Пример реализации BASE
Онлайн-магазин с высокой нагрузкой
😃: пользователь добавляет товар в корзину → система сразу подтверждает действие, даже если часть серверов перегружена
Товар появляется в корзине, но остатки на складе могут обновиться с небольшой задержкой
➡️ отправка запроса → API сразу возвращает успех (202 Accepted)
😓: данные о корзине и об остатках лежат в разных сервисах
Если два покупателя одновременно добавляют последний товар → оба увидят его в корзине, но физически доступен только 1
➡️ сервис корзин (Redis) временно сохраняет изменения
Сервис склада (Kafka + PostgreSQL) асинхронно проверяет остатки
😶🌫️: через несколько сек система проверяет остатки и синхронизирует данные
➡️ если товара нет, система убирает из корзины и отправляет уведомление
😃В ACID система заблокировала бы остатки при добавлении в корзину → очереди и ошибки под нагрузкой
BASE позволяет сначала принять действие, потом проверить ограничения
Это критично для высоконагруженных сценариев
📎 Материалы
1. BASE
2. Как бы я сейчас объяснил молодому себе… зачем существуют требования ACID для баз данных?
3. Требования ACID. BASE модель. CAP теорема
4. БАЗОВАЯ модель разработки БД
5. NoSQL: что это такое, отличие от других баз данных, BASE
📚Базы данных. Инжиниринг надежности - Кэмпбелл Лейн, Мейджорс Черити (Глава 11. BASE)
#бд
➿➿➿➿➿➿➿➿
🧑🎓 Больше полезного в базе знаний по системному анализу