Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску
Для использования в других целях, см Кислота (значения) .

В информатике , 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 начал свою транзакцию. Пользователь A получает согласованное представление о базе данных, даже если другие пользователи меняют данные. Одна реализация, а именно изоляция моментальных снимков , ослабляет свойство изоляции.

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

Основная статья: Распределенная транзакция

Обеспечение свойств 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.