КИСЛОТА
 | Эта статья нуждается в дополнительных цитатах для проверки . ( май 2018 г. ) |
В информатике , призванных гарантировать достоверность данных , ACID ( атомарность , согласованность , изоляция , долговечность ) — это набор свойств транзакций базы данных несмотря на ошибки, сбои питания и другие сбои. В контексте баз данных последовательность операций с базами данных, удовлетворяющая свойствам ACID (которая может восприниматься как одна логическая операция над данными), называется транзакцией . Например, перевод средств с одного банковского счета на другой, даже включающий несколько изменений, таких как дебетование одного счета и кредитование другого, представляет собой одну транзакцию.
В 1983 году [1] Андреас Ройтер и Тео Хэрдер придумали аббревиатуру ACID , основываясь на более ранней работе Джима Грея. [2] который назвал атомарность, последовательность и долговечность, но не изоляцию, характеризуя концепцию транзакции. Эти четыре свойства являются основными гарантиями парадигмы транзакций, которая повлияла на многие аспекты разработки систем баз данных .
По словам Грея и Рейтера, IBM Information Management System поддерживала транзакции ACID еще в 1973 году (хотя аббревиатура была создана позже). [3]
Характеристики
[ редактировать ]Характеристики этих четырех свойств, определенные Рейтером и Хэрдером, следующие:
атомарность
[ редактировать ]Транзакции часто состоят из нескольких операторов . Атомарность гарантирует, что каждая транзакция рассматривается как единая «единица», которая либо полностью завершается успешно, либо полностью завершается неудачно: если какой-либо из операторов, составляющих транзакцию, не завершается, вся транзакция завершается неудачно, и база данных остается неизменной. Атомная система должна гарантировать атомарность в любой ситуации, включая сбои в подаче электроэнергии, ошибки и сбои. [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 , транзакция будет отменена, или система может выдать предупреждение в виде триггера (если/когда триггер был написан для этого). Другим примером могут быть ограничения целостности, которые не позволяют нам удалить строку в одной таблице, на первичный ключ которой ссылается хотя бы один внешний ключ в других таблицах.
Нарушение изоляции
[ редактировать ]Чтобы продемонстрировать изоляцию, мы предполагаем, что одновременно выполняются две транзакции, каждая из которых пытается изменить одни и те же данные. Один из двух должен дождаться завершения другого, чтобы сохранить изоляцию.
Рассмотрим две транзакции:
- Т 1 передает 10 из А в Б.
- Т 2 передает 20 из В в А.
В совокупности существует четыре действия:
- Т 1 вычитает 10 из А.
- T 1 добавляет 10 к B.
- Т 2 вычитает 20 из В.
- Т 2 добавляет 20 к А.
Если эти операции выполняются по порядку, изоляция сохраняется, хотя T 2 должен ждать. Рассмотрим, что произойдет, если Т 1 выйдет из строя на полпути. База данных исключает видит влияние T1, и T2 только действительные данные.
При чередовании транзакций фактический порядок действий может быть таким:
- Т 1 вычитает 10 из А.
- Т 2 вычитает 20 из В.
- Т 2 добавляет 20 к А.
- T 1 добавляет 10 к B.
Опять же, рассмотрим, что произойдет, если T 1 потерпит неудачу при модификации B на шаге 4. К тому времени, когда T 1 потерпит неудачу, T 2 уже модифицирует A; его нельзя восстановить до значения, которое оно имело до T 1, не оставив базу данных недействительной. Это известно как конфликт записи-записи . [10] потому что две транзакции попытались записать одно и то же поле данных. В типичной системе проблема может быть решена путем возврата к последнему известному хорошему состоянию, отмены неудачной транзакции Т 1 и перезапуска прерванной транзакции Т 2 из хорошего состояния.
Нарушение долговечности
[ редактировать ]Рассмотрим транзакцию, которая передает 10 из A в B. Сначала она удаляет 10 из A, затем добавляет 10 в B. На этом этапе пользователю сообщают, что транзакция прошла успешно. Однако изменения все еще находятся в очереди в дисковом буфере, ожидая фиксации на диске. Отключается питание, и изменения теряются, но пользователь предполагает (по понятным причинам), что изменения сохраняются.
Выполнение
[ редактировать ]Обработка транзакции часто требует выполнения последовательности операций, которая может привести к сбою по ряду причин. Например, в системе может не хватить места на дисках или она израсходовала выделенное процессорное время. Существует два популярных семейства методов: упреждающая запись в журнал и теневая подкачка . В обоих случаях необходимо установить блокировки для всей обновляемой информации и, в зависимости от уровня изоляции, возможно, для всех данных, которые могут быть прочитаны. При журналировании с упреждающей записью надежность гарантируется за счет записи предполагаемых изменений в постоянный журнал перед изменением базы данных. Это позволяет базе данных вернуться в согласованное состояние в случае сбоя. При теневом обновлении применяются к частичной копии базы данных, а новая копия активируется при фиксации транзакции.
Блокировка против многоверсионности
[ редактировать ]Многие базы данных полагаются на блокировку для обеспечения возможностей ACID. Блокировка означает, что транзакция помечает данные, к которым она обращается, чтобы СУБД знала, что другим транзакциям нельзя изменять их до тех пор, пока первая транзакция не завершится успешно или не завершится неудачно. Блокировку всегда необходимо получать перед обработкой данных, включая данные, которые читаются, но не изменяются. Нетривиальные транзакции обычно требуют большого количества блокировок, что приводит к значительным накладным расходам, а также к блокировке других транзакций. Например, если пользователь А выполняет транзакцию, которая должна прочитать строку данных, которую пользователь Б хочет изменить, пользователь Б должен дождаться завершения транзакции пользователя А. Двухфазная блокировка часто применяется для обеспечения полной изоляции.
Альтернативой блокировке является многоверсионное управление параллелизмом , при котором база данных предоставляет каждой транзакции чтения предыдущую, немодифицированную версию данных, которая модифицируется другой активной транзакцией. Это позволяет читателям работать без установки блокировок, т. е. транзакции записи не блокируют транзакции чтения, а читатели не блокируют записи. Возвращаясь к примеру, когда транзакция пользователя A запрашивает данные, которые изменяет пользователь B, база данных предоставляет A версию этих данных, которая существовала, когда пользователь B начал свою транзакцию. Пользователь А получает единообразное представление базы данных, даже если другие пользователи меняют данные. Одна из реализаций, а именно изоляция моментальных снимков , ослабляет свойство изоляции.
Распределенные транзакции
[ редактировать ]Гарантирование свойств ACID в распределенной транзакции в распределенной базе данных , где ни один узел не несет ответственности за все данные, влияющие на транзакцию, представляет дополнительные сложности. Сетевые соединения могут выйти из строя, или один узел может успешно завершить свою часть транзакции, а затем ему придется откатить свои изменения из-за сбоя на другом узле. Протокол двухфазной фиксации (не путать с двухфазной блокировкой ) обеспечивает атомарность распределенных транзакций , чтобы гарантировать, что каждый участник транзакции согласен с тем, следует ли фиксировать транзакцию или нет. [11] Вкратце, на первом этапе один узел (координатор) опрашивает другие узлы (участники), и только когда все отвечают, что они готовы, координатор на втором этапе формализует транзакцию.
См. также
[ редактировать ]- Окончательная согласованность (BASE)
- Теорема CAP
- Управление параллелизмом
- API транзакций Java
- Взаимосвязь открытых систем
- Транзакционная NTFS
- Протокол двухфазной фиксации
- CRUD
Ссылки
[ редактировать ]- ^ Хердер, Т .; Рейтер, А. (1983). «Принципы транзакционно-ориентированного восстановления баз данных». Обзоры вычислительной техники ACM . 15 (4): 287. дои : 10.1145/289.291 . S2CID 207235758 .
- ^ Грей, Джим (сентябрь 1981 г.). «Концепция транзакции: преимущества и ограничения» (PDF) . Материалы 7-й Международной конференции по очень большим базам данных . Купертино, Калифорния: Тандемные компьютеры . стр. 144–154 . Проверено 27 марта 2015 г.
- ^ Грей, Джим ; Рейтер, Андреас (1993). Распределенная обработка транзакций: концепции и методы . Морган Кауфманн . ISBN 1-55860-190-2 .
- ^ «Атомная операция» . webopedia.com . Вебопедия. 25 ноября 2003 года . Проверено 23 марта 2011 г.
Операция, во время которой процессор может одновременно читать и записывать ячейку в одной и той же операции шины. Это предотвращает запись или чтение памяти любым другим процессором или устройством ввода-вывода до завершения операции.
- ^ CJ Date, «SQL и реляционная теория: как написать точный код SQL, 2-е издание», O'reilly Media, Inc. , 2012, стр. 180.
- ^ Архив документов (04.10.2012). «Уровни изоляции в ядре базы данных» . Learn.microsoft.com . Проверено 14 июля 2023 г.
- ^ Зильбершац, Авраам; Корт, Генри Ф.; Сударшан, С. (2011). «Транзакции». Концепции системы баз данных (6-е изд.). Нью-Йорк: МакГроу-Хилл. п. 631. ИСБН 978-0-07-352332-3 . OCLC 436031093 .
- ^ «Атомность» . docs.oracle.com . Проверено 13 декабря 2016 г.
- ^ Амстердам, Джонатан. «Атомарные файловые транзакции, часть 1» . О'Рейли . Архивировано из оригинала 3 марта 2016 г. Проверено 28 февраля 2016 г.
- ^ Зильбершац, Авраам; Корт, Генри Ф.; Сударшан, С. (2011). «Продвинутая разработка приложений». Концепции системы баз данных (6-е изд.). Нью-Йорк: МакГроу-Хилл. п. 1042. ИСБН 978-0-07-352332-3 . OCLC 436031093 .
- ^ Бернштейн, Филип А .; Новичок, Эрик (2009). «Глава 8». Принципы обработки транзакций (2-е изд.). Морган Кауфманн (Elsevier). ISBN 978-1-55860-623-4 . Архивировано из оригинала 7 августа 2010 г.
| Типы | |
|---|---|
| Концепции | |
| Объекты | |
| Компоненты | |
| Функции | |
| Связанные темы | |
