Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

В 1983 году [1] Андреас Рейтер и Тео Хердер придумали аббревиатуру ACID , основываясь на более ранней работе Джима Грея [2], который при характеристике концепции транзакции назвал атомарность, согласованность и долговечность, но не изоляцию. Эти четыре свойства являются основными гарантиями парадигмы транзакций, которая повлияла на многие аспекты разработки систем баз данных.

Согласно Грею и Рейтеру, система управления информацией IBM поддерживала транзакции ACID еще в 1973 году (хотя аббревиатура была создана позже). [3]

Характеристики [ править ]

Характеристики этих четырех объектов недвижимости, по определению Рейтер и Хердера, следующие:

Атомарность [ править ]

Транзакции часто состоят из нескольких операторов . Атомарность гарантирует, что каждая транзакция рассматривается как единая «единица», которая либо завершается успешно, либо полностью терпит неудачу: если какой-либо из операторов, составляющих транзакцию, не может быть завершен, вся транзакция терпит неудачу, а база данных остается неизменной. Атомарная система должна гарантировать атомарность в каждой ситуации, включая сбои питания, ошибки и сбои. [4]Гарантия атомарности предотвращает частичное обновление базы данных, что может вызвать более серьезные проблемы, чем полный отказ от всей серии. Как следствие, другой клиент базы данных не может наблюдать за выполнением транзакции. В какой-то момент этого еще не произошло, а в следующий уже произошло полностью (или ничего не произошло, если транзакция была отменена в процессе).

Примером атомарной транзакции является денежный перевод с банковского счета A на счет B. Он состоит из двух операций: снятие денег со счета A и сохранение их на счет B. Выполнение этих операций в атомарной транзакции гарантирует, что база данных останется в последовательное состояние , то есть, деньги не является ни списаны , ни кредитом , если любой из этих двух операций терпят неудачу. [5]

Последовательность [ править ]

Согласованность гарантирует, что транзакция может только перевести базу данных из одного допустимого состояния в другое, поддерживая инварианты базы данных : любые данные, записанные в базу данных, должны быть действительными в соответствии со всеми определенными правилами, включая ограничения , каскады , триггеры и любую их комбинацию. Это предотвращает повреждение базы данных в результате незаконной транзакции, но не гарантирует правильность транзакции . Ссылочная целостность гарантирует связь первичный ключ - внешний ключ . [6]

Изоляция [ править ]

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

Прочность [ править ]

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

Примеры [ править ]

Следующие ниже примеры дополнительно иллюстрируют свойства ACID. В этих примерах таблица базы данных имеет два столбца, A и B. Ограничение целостности требует, чтобы сумма значения в A и значения в B равнялась 100. Следующий код SQL создает таблицу, как описано выше:

CREATE  TABLE  acidtest  ( A  INTEGER ,  B  INTEGER ,  ПРОВЕРКА  ( A  +  B  =  100 ));

Атомарность [ править ]

Атомарность - это гарантия того, что серия операций с базой данных в атомарной транзакции либо будет выполнена (успешная операция), либо ничего не произойдет (неудачная операция). Серии операций нельзя разделить, выполняя только некоторые из них, что делает серию операций «неделимой». Гарантия атомарности предотвращает частичное обновление базы данных, что может вызвать более серьезные проблемы, чем полный отказ от всей серии. Другими словами, атомарность означает неделимость и несводимость. [8]В качестве альтернативы мы можем сказать, что логическая транзакция может состоять из одной или нескольких (нескольких) физических транзакций или состоять из них. Если и до тех пор, пока не будут выполнены все компоненты физических транзакций, логическая транзакция не произойдет - это будет сказываться на базе данных. Скажем, наша логическая транзакция состоит из перевода средств со счета A на счет B. Эта логическая транзакция может состоять из нескольких физических транзакций, состоящих из сначала удаления суммы со счета A в качестве первой физической транзакции, а затем, в качестве второй транзакции, внесения указанной суммы. в счете B. Мы не хотели бы, чтобы сумма была удалена со счета A, пока мы не убедимся, что она была переведена на счет B. Затем, если и пока не произошли обе транзакции и сумма не была переведена на счет B, перевод будет нет,к эффектам базы данных, произошло.

Ошибка согласованности [ править ]

Согласованность - это очень общий термин, который требует, чтобы данные соответствовали всем правилам проверки. В предыдущем примере для проверки требуется, чтобы A + B = 100 . Все правила проверки должны быть проверены для обеспечения согласованности. Предположим , что попытки транзакции вычесть 10 из A , не изменяя B . Поскольку согласованность проверяется после каждой транзакции, известно, что A + B = 100 до начала транзакции. Если транзакция удаляет 10 из A успешно, атомарность будет достигнута. Однако проверка покажет, что A + B = 90., что не соответствует правилам базы данных. Вся транзакция должна быть отменена, а затронутые строки откатятся до состояния до транзакции. Если бы были другие ограничения, триггеры или каскады, каждая отдельная операция изменения проверялась бы так же, как указано выше, до того, как транзакция была бы зафиксирована. Подобные проблемы могут возникнуть и с другими ограничениями. Возможно, нам потребовалось, чтобы типы данных A и B были целыми числами. Если бы мы тогда ввели, скажем, значение 13,5 для A, транзакция будет отменена, или система может вызвать предупреждение в виде триггера (если / когда триггер был написан для этого). Другой пример - ограничения целостности, которые не позволят нам удалить строку в одной таблице, первичный ключ которой упоминается хотя бы одним внешним ключом в других таблицах.

Нарушение изоляции [ править ]

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

Рассмотрим две транзакции: T 1 передает 10 от A к B. T 2 передает 20 от B к A.

В совокупности есть четыре действия:

  1. T 1 вычитает 10 из A.
  2. T 1 добавляет 10 к B.
  3. T 2 вычитает 20 из B.
  4. T 2 добавляет 20 к A.

Если эти операции выполняются по порядку, изоляция сохраняется, хотя Т 2 должен ждать. Подумайте, что произойдет, если T 1 выйдет из строя на полпути. База данных исключает эффекты T 1 , а T 2 видит только достоверные данные.

Посредством чередования транзакций фактический порядок действий может быть следующим:

  1. T 1 вычитает 10 из A.
  2. T 2 вычитает 20 из B.
  3. T 2 добавляет 20 к A.
  4. T 1 добавляет 10 к B.

Снова рассмотрим, что произойдет, если T 1 выйдет из строя при изменении B на шаге 4. К тому времени, когда T 1 выйдет из строя, T 2 уже изменил A; его нельзя восстановить до значения, которое было до T 1, не оставив недействительной базы данных. Это известно как конфликт записи записи , [ править ] , потому что две операции пытались написать на одном поле данных. В типичной системе проблема может быть решена путем возврата к последнему известному рабочему состоянию, отмены неудачной транзакции T 1 и перезапуска прерванной транзакции T 2 из хорошего состояния.

Нарушение прочности [ править ]

Рассмотрим транзакцию, которая передает 10 из A в B. Сначала она удаляет 10 из A, затем добавляет 10 к B. На этом этапе пользователю сообщается, что транзакция прошла успешно. Однако изменения все еще находятся в очереди в дисковом буфере, ожидая фиксации на диске. Сбой питания и изменения теряются, но пользователь предполагает (понятно), что изменения сохраняются.

Реализация [ править ]

Обработка транзакции часто требует последовательности операций, которая может выйти из строя по ряду причин. Например, в системе может не осталось места на дисках или она израсходовала выделенное время ЦП. Существует два популярных семейства методов: ведение журнала с упреждающей записью и теневая подкачка . В обоих случаях должны быть установлены блокировки для всей обновляемой информации и, в зависимости от уровня изоляции, возможно, для всех данных, которые также могут быть прочитаны. При ведении журнала с упреждающей записью надежность гарантируется путем копирования исходных (неизмененных) данных в журнал перед изменением базы данных. [ сомнительно ]Это позволяет базе данных вернуться в согласованное состояние в случае сбоя. При теневом копировании обновления применяются к частичной копии базы данных, и новая копия активируется при фиксации транзакции.

Блокировка и многоверсионность [ править ]

Многие базы данных полагаются на блокировку для обеспечения возможностей ACID. Блокировка означает, что транзакция помечает данные, к которым она обращается, чтобы СУБД знала, что нельзя разрешать другим транзакциям изменять их, пока первая транзакция не завершится успешно или не завершится неудачно. Блокировка всегда должна быть получена перед обработкой данных, включая данные, которые читаются, но не изменяются. Нетривиальные транзакции обычно требуют большого количества блокировок, что приводит к значительным накладным расходам, а также к блокировке других транзакций. Например, если пользователь A выполняет транзакцию, которая должна прочитать строку данных, которые пользователь B хочет изменить, пользователь B должен дождаться завершения транзакции пользователя A. Двухфазная синхронизация часто применяется для гарантии полной изоляции.

Альтернативой блокировке является мультиверсионное управление параллелизмом , при котором база данных предоставляет каждой транзакции чтения предыдущую, неизмененную версию данных, которые изменяются другой активной транзакцией. Это позволяет считывающим устройствам работать без получения блокировок, т. Е. Транзакции записи не блокируют транзакции чтения, а считыватели не блокируют средства записи. Возвращаясь к примеру, когда транзакция пользователя A запрашивает данные, которые изменяет пользователь B, база данных предоставляет A версию этих данных, которые существовали, когда пользователь B начал свою транзакцию. Пользователь А получает согласованное представление о базе данных, даже если другие пользователи меняют данные. Одна из реализаций, а именно изоляция моментальных снимков , ослабляет свойство изоляции.

Распределенные транзакции [ править ]

Обеспечение свойств ACID в распределенной транзакции в распределенной базе данных , где ни один узел не отвечает за все данные, влияющие на транзакцию, представляет дополнительные сложности. Сетевые подключения могут не работать, или один узел может успешно завершить свою часть транзакции, а затем от него потребуется откатить свои изменения из-за сбоя на другом узле. Протокол двухфазной фиксации (не путать с двухфазной блокировкой ) обеспечивает атомарность для распределенных транзакций, чтобы гарантировать, что каждый участник транзакции согласен с тем, следует ли транзакцию фиксировать или нет. [9] Вкратце, на первом этапе один узел (координатор) опрашивает другие узлы (участников), и только когда все ответы, которые они подготовили, координатор на втором этапе формализует транзакцию.

См. Также [ править ]

  • Конечная согласованность (BASE)
  • CAP теорема
  • Контроль параллелизма
  • API транзакций Java
  • Взаимодействие открытых систем
  • Транзакционная NTFS
  • Протокол двухфазной фиксации
  • CRUD

Ссылки [ править ]

  1. ^ Haerder, T .; Рейтер, А. (1983). «Принципы транзакционно-ориентированного восстановления баз данных». ACM Computing Surveys . 15 (4): 287. CiteSeerX  10.1.1.115.8124 . DOI : 10.1145 / 289.291 . S2CID  207235758 .
  2. ^ Грей, Джим (сентябрь 1981). «Концепция сделки: достоинства и ограничения» (PDF) . Труды 7-й Международной конференции по очень большим базам данных . Купертино, Калифорния: Тандемные компьютеры . С. 144–154 . Проверено 27 марта 2015 года .
  3. ^ Грей, Джим ; Рейтер, Андреас (1993). Распределенная обработка транзакций: концепции и методы . Морган Кауфманн . ISBN 1-55860-190-2.
  4. ^ "Атомная операция" . webopedia.com . Вебопедия . Проверено 23 марта 2011 . Операция, во время которой процессор может одновременно считывать местоположение и записывать его в той же операции шины. Это предотвращает запись или чтение памяти любым другим процессором или устройством ввода-вывода до завершения операции.
  5. ^ Амстердам, Джонатан. «Атомарные файловые транзакции, часть 1» . О'Рейли . Архивировано из оригинала на 2016-03-03 . Проверено 28 февраля 2016 .
  6. ^ CJ Date, «SQL и теория отношений: как писать точный код SQL, 2-е издание», O'reilly Media, Inc. , 2012, стр. 180.
  7. ^ «Уровни изоляции в ядре СУБД», Technet, Microsoft, https://technet.microsoft.com/en-us/library/ms189122(v=SQL.105).aspx
  8. ^ «Атомарность» . docs.oracle.com . Проверено 13 декабря 2016 .
  9. ^ Бернштейн, Филип А .; Новичок, Эрик (2009). «Глава 8». Принципы обработки транзакций (2-е изд.). Морган Кауфманн (Эльзевьер). ISBN 978-1-55860-623-4. Архивировано из оригинала на 2010-08-07.