В информатике ACID ( атомарность , согласованность , изоляция , долговечность ) — это набор свойств транзакций базы данных , призванных гарантировать достоверность данных, несмотря на ошибки, сбои питания и другие сбои . [1] В контексте баз данных последовательность операций с базами данных, удовлетворяющая свойствам ACID (которая может восприниматься как одна логическая операция над данными), называется транзакцией . Например, перевод средств с одного банковского счета на другой, даже включающий несколько изменений, таких как дебетование одного счета и кредитование другого, представляет собой одну транзакцию.
В 1983 году [2] Андреас Ройтер и Тео Хэрдер придумали аббревиатуру ACID , основываясь на более ранней работе Джима Грея [3] , который при описании концепции транзакции называл атомарность, согласованность и долговечность, но не изоляцию. Эти четыре свойства являются основными гарантиями парадигмы транзакций, которая повлияла на многие аспекты разработки систем баз данных .
По словам Грея и Рейтера, IBM Information Management System поддерживала транзакции ACID еще в 1973 году (хотя аббревиатура была создана позже). [4]
Характеристики этих четырех свойств, определенные Рейтером и Хэрдером, следующие:
Транзакции часто состоят из нескольких операторов . Атомарность гарантирует, что каждая транзакция рассматривается как единая «единица», которая либо полностью завершается успешно, либо полностью завершается неудачей: если какой-либо из операторов, составляющих транзакцию, не завершается, вся транзакция завершается неудачно, и база данных остается неизменной. Атомная система должна гарантировать атомарность в любой ситуации, включая сбои в подаче электроэнергии, ошибки и сбои. [5] Гарантия атомарности предотвращает лишь частичное обновление базы данных, что может вызвать более серьезные проблемы, чем полный отказ от всей серии. Как следствие, другой клиент базы данных не может наблюдать за выполнением транзакции. В один момент времени это еще не произошло, а в следующий уже произошло полностью (или ничего не произошло, если транзакция была отменена в процессе).
Согласованность гарантирует, что транзакция может перевести базу данных только из одного согласованного состояния в другое, сохраняя инварианты базы данных : любые данные, записанные в базу данных, должны быть действительными в соответствии со всеми определенными правилами, включая ограничения , каскады , триггеры и любую их комбинацию. Это предотвращает повреждение базы данных в результате незаконной транзакции. Ссылочная целостность гарантирует связь между первичным ключом и внешним ключом . [6]
Транзакции часто выполняются одновременно (например, одновременное чтение и запись нескольких транзакций в таблицу). Изоляция гарантирует, что одновременное выполнение транзакций оставляет базу данных в том же состоянии, которое было бы получено, если бы транзакции выполнялись последовательно. Изоляция является основной целью управления параллелизмом ; в зависимости от используемого уровня изоляции последствия незавершенной транзакции могут быть не видны другим транзакциям. [7]
Долговечность гарантирует, что после фиксации транзакции она останется зафиксированной даже в случае сбоя системы (например, отключения электроэнергии или сбоя ). Обычно это означает, что завершенные транзакции (или их последствия) записываются в энергонезависимую память . [ нужна цитата ]
Следующие примеры дополнительно иллюстрируют свойства ACID. В этих примерах таблица базы данных имеет два столбца: A и B. Ограничение целостности требует, чтобы сумма значений в A и B была равна 100. Следующий код SQL создает таблицу, как описано выше:
CREATE TABLE acidtest ( A INTEGER , B INTEGER , CHECK ( A + B = 100 )); Атомарность — это гарантия того, что ряд операций с базой данных в атомарной транзакции либо произойдет полностью (успешная операция), либо не произойдет ни одного (неудачная операция). Серию операций нельзя разделить, при этом выполняются только некоторые из них, что делает серию операций «неделимой». Гарантия атомарности предотвращает лишь частичное обновление базы данных, что может вызвать более серьезные проблемы, чем полный отказ от всей серии. Другими словами, атомарность означает неделимость и несократимость. [8] Альтернативно мы можем сказать, что логическая транзакция может состоять из нескольких физических транзакций. До тех пор, пока не будут выполнены все физические транзакции компонентов, логическая транзакция не произойдет.
Примером атомарной транзакции является денежный перевод с банковского счета А на счет Б. Он состоит из двух операций: снятия денег со счета А и сохранения их на счет Б. Нам бы не хотелось, чтобы сумма была удалена со счета А раньше. мы уверены, что они также были переведены на счет B. Выполнение этих операций в рамках атомарной транзакции гарантирует, что база данных останется в согласованном состоянии , то есть деньги не будут ни списаны, ни зачислены, если какая-либо из этих двух операций завершится неудачно. [9]
Согласованность — это очень общий термин, который требует, чтобы данные соответствовали всем правилам проверки. В предыдущем примере проверка представляет собой требование A + B = 100 . Все правила проверки должны быть проверены на предмет согласованности. Предположим , что транзакция пытается вычесть 10 из A , не изменяя B. Поскольку согласованность проверяется после каждой транзакции, известно, что A + B = 100 до начала транзакции. Если транзакция успешно удалит 10 из A , атомарность будет достигнута. Однако проверка валидации покажет, что A + B = 90 , что не соответствует правилам базы данных. Необходимо отменить всю транзакцию и вернуть затронутые строки в состояние, в котором они находились до транзакции. Если бы существовали другие ограничения, триггеры или каскады, каждая операция изменения была бы проверена таким же образом, как указано выше, перед фиксацией транзакции. Аналогичные проблемы могут возникнуть и с другими ограничениями. Возможно, нам потребовалось, чтобы типы данных A и B были целыми числами. Если бы мы затем ввели, скажем, значение 13,5 для A , транзакция будет отменена или система может выдать предупреждение в форме триггера (если/когда триггер был записан для этого). Другим примером могут быть ограничения целостности, которые не позволяют нам удалить строку в одной таблице, на первичный ключ которой ссылается хотя бы один внешний ключ в других таблицах.
Чтобы продемонстрировать изоляцию, мы предполагаем, что одновременно выполняются две транзакции, каждая из которых пытается изменить одни и те же данные. Один из двух должен дождаться завершения другого, чтобы сохранить изоляцию.
Рассмотрим две транзакции:
В совокупности существует четыре действия:
Если эти операции выполняются по порядку, изоляция сохраняется, хотя T 2 должен ждать. Рассмотрим, что произойдет, если Т 1 выйдет из строя на полпути. База данных исключает влияние T1, и T2 видит только действительные данные.
При чередовании транзакций фактический порядок действий может быть таким:
Опять же, рассмотрим, что произойдет, если T 1 потерпит неудачу при модификации B на шаге 4. К тому времени, когда T 1 потерпит неудачу, T 2 уже модифицирует A; его нельзя восстановить до значения, которое оно имело до T 1 , не оставив базу данных недействительной. Это известно как конфликт записи-записи , [ нужна цитация ] , потому что две транзакции пытались записать в одно и то же поле данных. В типичной системе проблема может быть решена путем возврата к последнему известному хорошему состоянию, отмены неудачной транзакции Т 1 и перезапуска прерванной транзакции Т 2 из хорошего состояния.
Рассмотрим транзакцию, которая передает 10 из A в B. Сначала она удаляет 10 из A, затем добавляет 10 в B. На этом этапе пользователю сообщают, что транзакция прошла успешно. Однако изменения все еще находятся в очереди в дисковом буфере , ожидая фиксации на диске. Отключается питание, и изменения теряются, но пользователь предполагает (по понятным причинам), что изменения сохраняются.
Обработка транзакции часто требует выполнения последовательности операций, которая может привести к сбою по ряду причин. Например, в системе может не хватить места на дисках или она израсходовала выделенное процессорное время. Существует два популярных семейства методов: упреждающая запись в журнал и теневая подкачка . В обоих случаях необходимо установить блокировки для всей обновляемой информации и, в зависимости от уровня изоляции, возможно, для всех данных, которые могут быть прочитаны. При журналировании с упреждающей записью надежность гарантируется за счет записи предполагаемых изменений в постоянный журнал перед изменением базы данных. Это позволяет базе данных вернуться в согласованное состояние в случае сбоя. При теневом обновлении применяются к частичной копии базы данных, а новая копия активируется при фиксации транзакции.
Многие базы данных полагаются на блокировку для обеспечения возможностей ACID. Блокировка означает, что транзакция помечает данные, к которым она обращается, чтобы СУБД знала, что другим транзакциям нельзя изменять их до тех пор, пока первая транзакция не завершится успешно или не завершится неудачно. Блокировку всегда необходимо получать перед обработкой данных, включая данные, которые читаются, но не изменяются. Нетривиальные транзакции обычно требуют большого количества блокировок, что приводит к значительным накладным расходам, а также к блокировке других транзакций. Например, если пользователь А выполняет транзакцию, которая должна прочитать строку данных, которую пользователь Б хочет изменить, пользователь Б должен дождаться завершения транзакции пользователя А. Двухфазная блокировка часто применяется для обеспечения полной изоляции.
Альтернативой блокировке является многоверсионное управление параллелизмом , при котором база данных предоставляет каждой транзакции чтения предыдущую, немодифицированную версию данных, которая модифицируется другой активной транзакцией. Это позволяет читателям работать без установки блокировок, т. е. транзакции записи не блокируют транзакции чтения, а читатели не блокируют записи. Возвращаясь к примеру, когда транзакция пользователя А запрашивает данные, которые изменяет пользователь Б, база данных предоставляет А версию этих данных, которая существовала, когда пользователь Б начал свою транзакцию. Пользователь А получает согласованное представление базы данных, даже если другие пользователи меняют данные. Одна из реализаций, а именно изоляция моментальных снимков , ослабляет свойство изоляции.
Гарантирование свойств ACID в распределенной транзакции в распределенной базе данных , где ни один узел не несет ответственности за все данные, влияющие на транзакцию, представляет дополнительные сложности. Сетевые соединения могут выйти из строя, или один узел может успешно завершить свою часть транзакции, а затем ему придется откатить свои изменения из-за сбоя на другом узле. Протокол двухфазной фиксации (не путать с двухфазной блокировкой ) обеспечивает атомарность распределенных транзакций , чтобы гарантировать, что каждый участник транзакции согласен с тем, следует ли фиксировать транзакцию или нет. [10] Вкратце, на первом этапе один узел (координатор) опрашивает другие узлы (участники), и только когда все отвечают, что они готовы, координатор на втором этапе формализует транзакцию.
Операция, во время которой процессор может одновременно читать и записывать ячейку в одной и той же операции шины.
Это предотвращает запись или чтение памяти любым другим процессором или устройством ввода-вывода до завершения операции.