Материал для канала Мы ж программист
Изменение данных в БД производят с помощью транзакций. Каждая транзакция – это набор операций, последовательность которых имеет конкретный бизнес-смысл. Например, чтобы перечислить деньги со счета на счет в банке, нужно уменьшить баланс счета-источника и увеличить баланс счета-получателя – две связанные операции, не имеющие смысла по-отдельности.
Но транзакции могут быть “тяжелыми” и их может быть очень много. Поэтому от того, как мы реализуем работу с базой, зависит стабильность и актуальность системы в целом. Одним из применимых подходов является ACID.
ACID означает, что каждая транзакция БД должна соответствовать следующим требованиям:
- Atomicity – атомарность. Транзакция может включать несколько связанных операций, все они должны выполниться только полным комплектом. Либо изменения откатываются так же целиком. Например, при переводе денег со счета на счет одинаково важны вывод с первого счета и начисление на второй, нельзя зафиксировать только часть операции, получим несогласованные данные.
- Consistency – согласованность. Данные, которыми оперирует транзакция, должны всегда сохранять целостность и удовлетворять правилам и ограничениям БД. То есть, если транзакция завершилась успешно, то мы можем быть уверены, что, например, финансовый баланс соответствует приходам и расходам, а записи, ссылающиеся на другие, не “осиротели”.
- Isolation – изолированность. Транзакции, затрагивающие одни и те же данные, не должны мешать друг другу, то есть как бы выполняться последовательно. Существует несколько уровней изоляции, но об этом в другой раз.
- Durability – надежность. Даже в случае отказа системы уже зафиксированные транзакции должны остаться в БД.
Модель ACID чаще применима к реляционным БД, где несогласованность данных может быть критичной для работы системы. Пример: финансовые приложения.
Однако, существует еще один архитектурный подход – BASE. Это тоже акроним, состоит из:
- Basically Available – базовая доступность. Означает, что система всегда готова обработать запрос, данные доступны всегда и всем, независимо от того, производятся ли на них сейчас какие-то действия. То есть при запросе к базе мы можем увидеть устаревшие данные, но база все равно ответит вовремя.
- Soft state – мягкое состояние. Данные могут находиться в некоем неокончательном состоянии, когда их меняют несколько процессов одновременно. То есть быть временно несогласованными. Но постепенно они придут к окончательной форме.
- Eventually consistent – согласованность в конечном счёте. Если несколько процессов вносят правки в запись, то она придет в согласованное состояние со временем, когда все правки будут гарантированно применены. При этом нет строгих временных рамок для этого процесса.
BASE больше применима для NoSQL-баз и распределенных систем, где масштабируемость и скорость обработки данных важнее согласованности. Пример: соцсети.