Давай зададимся любимым вопросом с собеседований: «А зачем нам вообще ставить тяжелую БД, если мы можем просто сохранять данные пользователей в обычный .txt или .json файл на сервере?»
Ответ кроется в проблемах, которые неизбежно возникают, как только твой сервис начинает расти:
- Конкурентный доступ: Что будет, если два потока приложения попытаются одновременно обновить баланс одного пользователя в файле? Случится состояние гонки, и один запишет поверх другого. Файл будет поврежден.
- Восстановление после сбоев: Представь, что мы успели записать в файл списание денег, начали писать зачисление, и тут сервер перезагрузился (выдернули шнур). Деньги исчезли в никуда. В файловой системе нет механизма отката наполовину записанного куска.
- Скорость работы: Чтобы найти конкретный лог в терабайтном файле, тебе придется прочитать его целиком за O(N). Это убьет любые SLA по времени ответа.
Именно поэтому нам нужна СУБД (система управления базами данных) — специализированный софт, который берет на себя всю эту головную боль с блокировками, индексами и восстановлением, предоставляя тебе удобный SQL-интерфейс.
Минутка терминологии
СУБД — это общий термин. И PostgreSQL, и MongoDB, и Valkey, и CockroachDB — это всё СУБД, просто разных классов (реляционные, NoSQL, In-Memory, NewSQL).
Мы начинаем разбор гарантий ACID на примере классических реляционных баз (PostgreSQL, MySQL), так как они являются основой. В будущих модулях мы увидим, как NoSQL-решения сознательно отказываются от части этих гарантий ради масштабирования, а NewSQL — пытаются сохранить строгий ACID в распределенной среде.
Гарантии СУБД (ACID)
СУБД не просто хранят данные, реляционные базы дают нам строгие математические гарантии того, что наши данные не превратятся в тыкву. Эти гарантии упакованы в аббревиатуру ACID:
| Гарантия | Что означает | Почему важно в продакшене |
|---|---|---|
| Atomicity (Атомарность) | Все операции транзакции завершаются единым блоком — «всё или ничего». | Перевод денег: если списали со счёта, но не смогли зачислить на другой, БД откатит списание. Финансового разрыва не будет. |
| Consistency (Согласованность) | Переход из одного валидного состояния в другое, соблюдение всех Constraints (ограничений), Foreign Keys и триггеров. | В интернет-магазине баланс товара не может уйти в минус, а у заказа всегда должен быть существующий user_id. |
| Isolation (Изолированность) | Параллельные транзакции не мешают друг другу. Транзакция не видит промежуточных результатов других транзакций. | Конкурентные заказы в чёрную пятницу не «расталкивают» данные и корректно списывают остатки со склада. |
| Durability (Надежность/Долговечность) | Если БД ответила клиенту COMMIT (успех), данные переживут сбой питания сервера или падение процесса. | Лог об успешной оплате билета не потеряется при рестарте контейнера с Postgres (спасибо WAL-журналам, о которых поговорим позже). |
Частая путаница на собеседованиях: Consistency в ACID ≠ «Согласованность» из CAP-теоремы.
Первая (ACID) говорит про целостность внутри одной БД (правила, ограничения, связи). Вторая (CAP) — про одинаковое значение на разных узлах распределенного кластера (репликах).