ACID vs BASE

Введение: Две философии надёжности

Представьте, что вы переводите деньги через банковское приложение. Вы нажимаете “Перевести”. Приложение должно гарантировать: деньги спишутся с одного счёта и зачислятся на другой. Не может быть такого, что списались, но не зачислились. Не может быть такого, что вы видите старый баланс, пока перевод обрабатывается. Банк выбирает ACID — строгую, надёжную, но медленную модель.

Представьте, что вы ставите лайк в Instagram. Лайк появился не у всех друзей мгновенно? Это нормально. Через пару секунд все увидят. Если лайк временно потеряется при сбое? Пользователь поставит снова. Instagram выбирает BASE — быструю, масштабируемую, но с временной несогласованностью.

ACID и BASE — это два подхода к надёжности и согласованности данных. ACID выбирает строгую согласованность в ущерб производительности и масштабируемости. BASE выбирает производительность и масштабируемость в ущерб строгой согласованности.

Для системного аналитика понимание ACID и BASE — это ключ к выбору правильной базы данных. Банк не может использовать BASE. Социальная сеть не может использовать ACID (не выдержит нагрузки). Нужно понимать компромиссы.

ACID: Надежность

ACID — это акроним, описывающий свойства транзакций в реляционных базах данных.

Atomicity (Атомарность)

Что это: Транзакция — это неделимая единица работы. Либо все операции внутри транзакции применяются, либо ни одна.

Пример: Перевод денег.

Транзакция:
  1. Списать 1000 рублей со счёта А
  2. Зачислить 1000 рублей на счёт Б

Атомарность гарантирует:
  - Если списание прошло, а зачисление упало (сбой сети, ошибка) → откат списания
  - Деньги не исчезли и не размножились

Как реализовано: Журнал транзакций (WAL). При сбое система восстанавливается: зафиксированные транзакции применяются, незафиксированные — откатываются.

Consistency (Согласованность)

Что это: Транзакция переводит базу данных из одного согласованного состояния в другое. Все ограничения (уникальность, внешние ключи, CHECK) соблюдаются.

Пример: Баланс не может быть отрицательным.

Ограничение: balance >= 0

Транзакция:
  UPDATE accounts SET balance = balance - 1000 WHERE id = 1

Если balance = 500:
  - Баланс станет -500 → нарушение ограничения
  - Транзакция откатится

Два уровня согласованности:

Isolation (Изоляция)

Что это: Параллельные транзакции не должны влиять друг на друга. Каждая транзакция работает так, как будто она одна в системе.

Проблемы без изоляции:

Уровни изоляции (от слабого к сильному):

Durability (Долговечность)

Что это: После того как транзакция зафиксирована (COMMIT), данные сохраняются навсегда и не теряются при любых сбоях: отключении электричества, падении операционной системы, сбое диска.

Как реализовано:

• WAL (Write-Ahead Logging): сначала запись в журнал, потом на диск
• Репликация: копии данных на нескольких серверах
• Резервное копирование: регулярные бэкапы

Гарантии:

Сценарий:
  1. BEGIN
  2. UPDATE accounts SET balance = balance - 100 WHERE id = 1
  3. COMMIT
  4. Отключение электричества

Результат:
  - При включении система восстанавливает зафиксированную транзакцию
  - Деньги списаны

BASE: Фундамент масштабируемости

BASE — это акроним, описывающий свойства распределённых и нереляционных систем.

Basically Available (Базовая доступность)

Что это: Система всегда отвечает на запросы. Она не может сказать “я сейчас занята, придите позже”. Ответ может содержать устаревшие данные, но он будет.

Пример: Лента новостей в социальной сети.

Запрос: показать ленту
Ответ: лента (может быть не самой свежей, но есть)

Даже при сетевых проблемах сервер отвечает.

Плата: Согласованность. Вы можете получить не самые свежие данные.

Soft state (Мягкое состояние)

Что это: Состояние системы может меняться без внешних воздействий, из-за фоновых процессов синхронизации.

Пример: DNS.

Вы изменили IP сайта:
  - Через 5 минут: одни пользователи видят старый IP, другие — новый
  - Состояние "плавает", пока не распространится

В отличие от ACID: В ACID состояние меняется только транзакциями. В BASE состояние может меняться “само по себе”.

Eventual consistency (Конечная согласованность)

Что это: Если новые данные перестанут поступать, то через некоторое время все узлы системы придут к одному состоянию.

Пример: Лайки в Instagram.

Вы поставили лайк:
  - Сразу: вы видите, что лайк поставлен
  - Через 1 секунду: ваши друзья видят лайк
  - Через 5 секунд: все серверы показывают лайк

Нет гарантии, что через 0.5 секунды лайк увидят все.

Степени согласованности:

Сравнение ACID и BASE

CAP-теорема: Почему ACID и BASE существуют

CAP-теорема гласит: распределённая система может обеспечить только два из трёх свойств:

    graph TD
    A[CAP] --> B[Consistency]
    A --> C[Availability]
    A --> D[Partition Tolerance]
    
    B --> E[CP: HBase, MongoDB]
    C --> F[AP: Cassandra, DynamoDB]
  

ACID тяготеет к CP (Consistency + Partition tolerance), жертвуя доступностью при сетевых проблемах.

BASE тяготеет к AP (Availability + Partition tolerance), жертвуя строгой согласованностью.

Практические примеры

Пример 1: Банковский перевод (ACID)

Требования:
  - Деньги не могут потеряться
  - Деньги не могут размножиться
  - Баланс должен быть точным в любой момент

Выбор: ACID (PostgreSQL)

Почему:
  - Атомарность: перевод либо полностью выполнен, либо откачен
  - Согласованность: баланс не может стать отрицательным
  - Изоляция: другой перевод не увидит промежуточное состояние
  - Долговечность: после COMMIT деньги сохранены

Пример 2: Лайки в социальной сети (BASE)

Требования:
  - 1 миллион лайков в секунду
  - Пользователь не заметит задержку в 1 секунду
  - Потеря одного лайка при сбое не критична

Выбор: BASE (Cassandra)

Почему:
  - Basically Available: всегда отвечает
  - Eventual consistency: лайк появится у всех через секунду
  - Масштабируемость: горизонтальная, миллионы запросов

Пример 3: Корзина покупок (гибрид)

Требования:
  - Товар не должен быть продан дважды (ACID)
  - Корзина может быть временной (BASE)

Решение:
  - Заказы и остатки: PostgreSQL (ACID)
  - Корзина: Redis (BASE)

Компромиссы

Цена ACID

Цена BASE

Гибридный подход

Современные системы часто используют оба подхода.

Архитектура:
  - PostgreSQL (ACID): заказы, платежи, пользователи
  - Redis (BASE): корзина, сессии, кеш
  - Cassandra (BASE): логи, метрики, события

Результат:
  - Где нужна строгая согласованность → ACID
  - Где нужна скорость и масштаб → BASE

Распространённые ошибки

Ошибка 1: ACID везде

Используют PostgreSQL для логов (миллионы записей в секунду). Не выдерживает.

Решение: Cassandra или ClickHouse.

Ошибка 2: BASE для финансов

Хранят деньги в MongoDB без транзакций. Деньги теряются.

Решение: PostgreSQL.

Ошибка 3: Игнорирование eventual consistency

Читают с реплики сразу после записи. Получают старые данные.

Решение: Читать с мастера для критичных операций.

Ошибка 4: Ожидание строгой согласованности в BASE

Думают, что Cassandra даст strong consistency. Она даёт eventual.

Решение: Выбирать базу данных под требования.

Ошибка 5: ACID в распределённой системе

Пытаются сделать ACID-транзакцию на 10 серверах. Сложно, медленно, дорого.

Решение: Saga, компенсирующие транзакции.

Резюме

1. ACID — строгая согласованность, целостность, надёжность. Для финансов, бронирования, учёта.

2. BASE — доступность, масштабируемость, скорость. Для социальных сетей, логов, кешей, метрик.

3. Ключевые различия: согласованность (сильная vs eventual), доступность (может быть недоступна vs всегда доступна), масштабирование (вертикальное vs горизонтальное).

4. CAP-теорема объясняет компромисс: при сетевых проблемах выбираем между согласованностью и доступностью.

5. Нет “лучшего” — есть “подходящий”. ACID для критичных данных. BASE для масштаба и скорости.

6. Гибридные архитектуры — норма. Используйте ACID там, где нужна строгая согласованность, и BASE там, где нужна скорость.