Транзакции

В этот зимний понедельник предлагаю продолжить разбирать «кабанчика» («Высоконагруженные приложения» Мартина Клепманна). 7-я глава посвящена транзакциям. Ссылки на предыдущие главы собрала в закрепе.

В первой части главы рассматривается концепция транзакций.

Транзакции были придуманы для упрощения разработки приложений, работающих с базами данных. Благодаря транзакциям приложение может игнорировать определенные сценарии ошибок и вопросы конкурентного доступа, поскольку вместо него этим занимается база.

Обеспечиваемые транзакциями гарантии часто описываются известной аббревиатурой, придуманной еще в 1983 году —ACID:
✔️ Atomicity
✔️ Consistency
✅ Isolation
✔️ Durability

На практике реализации ACID в разных базах отличаются друг от друга, особенно в части «изоляции». К сожалению, ACID стал скорее термином из области маркетинга.

Транзакции нужны не каждому приложению.

Системы, не соответствующие критериям ACID, иногда называются BASE:
*️⃣ Basically Available (как правило, доступна)
*️⃣ Soft state (гибкое состояние)
*️⃣ Eventual consistency (конечная согласованность)
Однако понятие BASE довольно расплывчатое.

✅Атомарность

Атомарность в ACID относится к ситуации, в которой клиент выполняет несколько операций записи, и в момент, когда выполнена лишь часть операций, возникает сбой (разрыв сетевого соединения, переполнение диска или нарушение одного из ограничений целостности). Если операции записи сгруппированы в атомарную транзакцию, то она прерывается, и база данных откатывает все уже выполненные в рамках этой транзакции операции записи.

Без атомарности при возникновении ошибки сложно понять, какие из операций успели примениться. Если приложение попытается выполнить набор операций снова, то это может привести к дублированию или другим ошибкам.

Атомарность упрощает задачу: если транзакция была прервана, то приложение может быть уверено, что ничего не было изменено, и можно безопасно повторить изменения.

✅Согласованность (консистентность)

Клепманн отмечает, что слово «согласованность» сильно перегружено. Оно используется и при разговоре о репликах, и в консистентном хэшировании, и в теореме CAP и в ACID.

В контексте ACID под согласованностью понимается то, что база данных находится в «правильном» состоянии. То есть данные в ней удовлетворяют каким-то условиям: например, в БД бухгалтерского приложения дебет должен сходиться с кредитом.

Однако формулировать транзакции так, чтобы сохранялась согласованность — это обязанность приложения. База данных не в состоянии это гарантировать, так как не может помешать записать «плохие» данные, наруша­ющие условия. БД способна проверять некоторые правила с помощью ограничений внешних ключей или ограничений уникальности. Но в целом согласованность данных определяется приложением — БД только обеспечивает хранение.

Клепманн замечает, что букве C на самом деле не место в аббревиатуре ACID. В подтверждение этой мысли приводится сноска, что буква C была добавлена в ACID для красоты аббревиатуры и не считалась в то время чем-то важным.

✅Изоляция

Если несколько клиентов одновременно обращаются к одним и тем же записям базы, то могут возникнуть проблемы конкурентного доступа (состояния гонки). Изоляция в смысле ACID означает, что конкурентно выполняемые транзакции изолированы друг от друга — не могут помешать друг другу.

Подробнее изоляция рассматривается в следующем разделе.

✅Сохраняемость (долговечность)

Сохраняемость — обязательство базы не терять успешно зафиксированных транзакцией данных, даже в случае сбоя.

В одноузловой базе сохраняемость обычно означает запись данных на энергонезависимый носитель (HDD или SSD), а также наличие журнала упреждающей записи или чего-то аналогичного, что позволит восстановить данные.

В реплицируемой БД сохраняемость может означать, что данные были успешно скопированы на одну или несколько реплик.

На практике не существует ни одного метода, дающего абсолютную гарантию сохраняемости данных. Существуют только методики снижения рисков (запись на диск, репликация, резервное копирование), которые нужно комбинировать.

#кабанчик #сисдиз