Войти
В информатике, ACID(атомарность, согласованность, изоляция, долговечность ) - это набор свойств транзакций базы данных, предназначенных для гарантии достоверности данных, несмотря на ошибки, сбои питания и другие неполадки. В контексте баз данных последовательность операций с базой данных, удовлетворяющая свойствам ACID (которые могут восприниматься как единственная логическая операция с данными), называется транзакцией. Например, перевод средств с одного банковского счета на другой, даже если он включает в себя несколько изменений, таких как дебетование одного счета и кредитование другого, является одной транзакцией.
В 1983 году Андреас Рейтер и Тео Хердер придумали аббревиатуру ACID, основываясь на более ранней работе Джима Грея, который назвал атомарность, последовательность, и долговечность, но не изоляция, при характеристике концепции транзакции. Эти четыре свойства являются основными гарантиями парадигмы транзакций, которая повлияла на многие аспекты разработки систем баз данных.
Согласно Грею и Рейтеру, IBM Information Management System поддерживала транзакции ACID еще в 1973 году (хотя аббревиатура была создана позже).
Характеристики этих четырех свойств, определенные Рейтер и Хердер, следующие :
Транзакции часто состоят из нескольких операторов . Атомарность гарантирует, что каждая транзакция рассматривается как единая «единица», которая либо полностью завершается успешно, либо полностью терпит неудачу: если какой-либо из операторов, составляющих транзакцию, не может быть завершен, вся транзакция завершается неудачно, и база данных остается без изменений. Атомарная система должна гарантировать атомарность в каждой ситуации, включая сбои питания, ошибки и сбои. Гарантия атомарности предотвращает частичное обновление базы данных, что может вызвать более серьезные проблемы, чем полный отказ от всей серии. Как следствие, другой клиент базы данных не может наблюдать за выполнением транзакции. В какой-то момент этого еще не произошло, а в следующий уже произошло полностью (или ничего не произошло, если транзакция была отменена в процессе).
Примером атомарной транзакции является денежный перевод с банковского счета A на счет B. Он состоит из двух операций: снятия денег со счета A и сохранения их на счет B. Выполнение этих операций в атомарной транзакции гарантирует, что база данных остается в согласованном состоянии, то есть деньги не списываются и не зачисляются, если одна из этих двух операций завершается неудачно.
Согласованность гарантирует, что транзакция может только перевести базу данных из одного допустимого состояния в другое, поддерживая инварианты базы данных : любые данные, записанные в базу данных, должны быть действительными согласно всем определенным правилам, включая ограничения, каскады, запускают и любую их комбинацию. Это предотвращает повреждение базы данных в результате незаконной транзакции, но не гарантирует правильность транзакции. Ссылочная целостность гарантирует связь первичный ключ - внешний ключ.
Транзакции часто выполняются одновременно (например, несколько транзакций читают и записывают в таблицу одновременно). Изоляция гарантирует, что одновременное выполнение транзакций оставляет базу данных в том же состоянии, которое было бы получено, если бы транзакции выполнялись последовательно. Изоляция - основная цель контроля параллелизма ; в зависимости от используемого метода эффекты незавершенной транзакции могут даже быть невидимы для других транзакций.
Долговечность гарантирует, что после того, как транзакция была зафиксирована, она останется зафиксированной даже в случае сбоя системы (например, отключения электроэнергии или сбоя ). Обычно это означает, что завершенные транзакции (или их эффекты) записываются в энергонезависимую память.
Следующие ниже примеры дополнительно иллюстрируют свойства ACID. В этих примерах таблица базы данных имеет два столбца: A и B. Ограничение целостности требует, чтобы сумма значения в A и значения в B равнялась 100. Следующий код SQL создает таблицу, как описано выше:
CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));
Атомарность - это гарантия того, что все серии операций с базой данных в атомарной транзакции либо будут выполнены (успешная операция), либо не произойдет (неудачная операция). Серии операций нельзя разделить, выполняя только некоторые из них, что делает серию операций «неделимой». Гарантия атомарности предотвращает частичное обновление базы данных, что может вызвать более серьезные проблемы, чем полный отказ от всей серии. Другими словами, атомарность означает неделимость и несводимость. В качестве альтернативы мы можем сказать, что логическая транзакция может состоять из одной или нескольких (нескольких) физических транзакций или состоять из них. Если и до тех пор, пока не будут выполнены все компоненты физических транзакций, логическая транзакция не произойдет - это будет сказываться на базе данных. Скажем, наша логическая транзакция состоит из перевода средств со счета 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.
Объединенные, есть четыре действия:
Если эти операции выполняются по порядку, изоляция сохраняется, хотя T 2 должен ждать. Рассмотрим, что произойдет, если T 1 выйдет из строя на полпути. База данных исключает эффекты T 1 , а T 2 видит только действительные данные.
Посредством чередования транзакций фактический порядок действий может быть следующим:
Опять же, рассмотрим, что произойдет, если T 1 выйдет из строя при изменении B на шаге 4. К тому времени, когда T 1 выйдет из строя, T 2 уже изменился А; его нельзя восстановить до значения, которое было до T 1 , не оставив недействительной базы данных. Это известно как сбой записи-записи, поскольку две транзакции пытались выполнить запись в одно и то же поле данных. В типичной системе проблема может быть решена путем возврата к последнему известному рабочему состоянию, отмены неудачной транзакции T 1 и перезапуска прерванной транзакции T 2 из хорошего состояния.
Рассмотрим транзакцию, которая передает 10 из A в B. Сначала она удаляет 10 из A, затем добавляет 10 к B. На этом этапе пользователю сообщается, что транзакция была успех. Однако изменения все еще находятся в очереди в дисковом буфере, ожидая фиксации на диске. Сбой питания, и изменения теряются. Пользователь предполагает (по понятным причинам), что изменения сохраняются.
Обработка транзакции часто требует последовательности операций, которая может быть неудачной по ряду причин. Например, в системе может не осталось места на дисках или она израсходовала выделенное время ЦП. Существует два популярных семейства методов: ведение журнала с упреждающей записью и теневая подкачка. В обоих случаях блокировки должны быть получены для всей информации, подлежащей обновлению, и, в зависимости от уровня изоляции, возможно, для всех данных, которые также могут быть прочитаны. При ведении журнала с упреждающей записью надежность гарантируется путем копирования исходных (неизмененных) данных в журнал перед изменением базы данных. Это позволяет базе данных вернуться в согласованное состояние в случае сбоя. При теневом копировании обновления применяются к частичной копии базы данных, и новая копия активируется при фиксации транзакции.
Многие базы данных полагаются на блокировку для обеспечения возможностей ACID. Блокировка означает, что транзакция помечает данные, к которым она обращается, чтобы СУБД знала, что не разрешает другим транзакциям изменять их, пока первая транзакция не завершится успешно или не завершится неудачно. Блокировка всегда должна быть получена перед обработкой данных, включая данные, которые читаются, но не изменяются. Нетривиальные транзакции обычно требуют большого количества блокировок, что приводит к значительным накладным расходам, а также к блокировке других транзакций. Например, если пользователь A выполняет транзакцию, которая должна прочитать строку данных, которые пользователь B хочет изменить, пользователь B должен дождаться завершения транзакции пользователя A. Двухфазная синхронизация часто применяется для гарантии полной изоляции.
Альтернативой блокировке является управление многоверсионным параллелизмом, при котором база данных предоставляет каждой транзакции чтения предыдущую неизмененную версию данных, которые изменяются другой активной транзакцией. Это позволяет считывающим устройствам работать без получения блокировок, то есть транзакции записи не блокируют транзакции чтения, а считыватели не блокируют средства записи. Возвращаясь к примеру, когда транзакция пользователя A запрашивает данные, которые изменяет пользователь B, база данных предоставляет A версию этих данных, которые существовали, когда пользователь B начал свою транзакцию. Пользователь А получает согласованное представление о базе данных, даже если другие пользователи меняют данные. Одна реализация, а именно изоляция моментального снимка, ослабляет свойство изоляции.
Гарантия свойств ACID в распределенной транзакции в распределенной базе данных, где ни один узел не отвечает за все данные, влияющие на транзакцию , представляет дополнительные сложности. Сетевые подключения могут не работать, или один узел может успешно завершить свою часть транзакции, а затем от него потребуется откатить свои изменения из-за сбоя на другом узле. протокол двухфазной фиксации (не путать с двухфазной блокировкой ) обеспечивает атомарность для распределенных транзакций, чтобы гарантировать, что каждый участник транзакции согласен с следует ли совершать транзакцию или нет. Вкратце, на первом этапе один узел (координатор) опрашивает другие узлы (участников), и только когда все ответы, которые они подготовили, координатор на втором этапе формализует транзакцию.
