Понятие ACID и зачем это нужно

Рано ли поздно, когда вы сталкиваетесь с тестированием баз данных, перед вами может всплыть такая аббревиатура, как ACID.

Что это такое и зачем это нужно?

Далее как раз и постараемся в этом разобраться.

Что такое ACID?

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

Подобная отличительная черта крайне важна для финансовых операций и других сфер деятельности, где внутрь систем «загоняют» большие массивы персональной информации/финансовых ресурсов, и это является востребованным процессом проверки работоспособности во многих компаниях по тестированию.

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

Atomicity — Атомарность

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

Например, вы решили отправить своему другу денежные средства. Когда осуществляется перевод внутри онлайн-банкинга, происходит следующее:

• Ваши деньги списались с вашего счета;
• Другу на счет зачислись.

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

1. У пользователя нет достаточной суммы на счету — система показала сообщение об ошибке, атомарность не нужна;
2. У получателя заблокирована карта/срок годности истек — запрос отменен.

И если ошибка на первом этапе не приводит ни к чему плохому, то ошибка на втором может грозить потерей денежных средств.

Атомарность позволяет группировать запросы и показывать взаимосвязь между ними. И если происходит ошибка по одному из них, назад откатываются все.

Consistency — Согласованность

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

Например, есть пользователь, и он заполняет персональную карточку в системе:

• ФИО;
• Дата рождения;
• Телефон;
• Адрес.

База в ПО содержит несколько взаимосвязанных таблиц:

1. Клиент;
2. Телефон;
3. Адрес.

То есть, при заполнении клиентом карточки, в систему отправляется сразу три запроса с данными.

Наличие атомарности гарантирует, что все введенные данные будут сохранены (не будет такого, что телефон сохранится, а инициалы — нет).

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

За корректностью консистентности отвечает программист. Так как это вопрос, в большей степени, бизнес-логики, чем технологий.

Isolation — Изолированность

При выполнении одной транзакции все остальные параллельные транзакции не должны оказывать на нее никакого результата.

Если система рассчитана на одного пользователя — все будет хорошо, а если пользователей много?

Тогда операции необходимо запускать на параллельной основе, чтобы система могла работать в ускоренном режиме.

Но тут могут скрываться крайне неприятные подводные камни:

• Проблема №1 — Потерянная запись;
• Проблема № 2 — Повторяемое чтение;
• Проблема №3 — Грязное чтение;
• Проблема №4 — Фантом.

Решение всех этих проблем основано на использовании как раз изолированной транзакции.

Как этого достичь?

Например, использовать блокировку версий.

Данная манипуляция подразумевает под собой блокирование определенной строки в таблице (можно заблокировать данные как на добавление, так и на редактирование).

Durability — Надежность

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

Пропал свет, проблемы с Интернет-соединением?

На совершенную операцию это не должно повлиять никаким образом.