Напишите как расшифровывается акроним acid которым обозначают требования к транзакционной системе

Время на прочтение
6 мин

Количество просмотров 121K

Мне нравятся книги из серии Head First O`Reilly — они рассказывают просто о сложном. И я стараюсь делать также.

Когда речь идёт о базах данных, могут всплыть магические слова «Требования ACID». На собеседовании или в разговоре разработчиков — не суть. В этой статье я расскажу о том, что это такое, как расшифровывается ACID и что означает каждая буква.

Требования ACID — набор требований, которые обеспечивают сохранность ваших данных. Что особенно важно для финансовых операций. Мы же не хотим остаться без денег из-за разрыва соединения или ошибки в ПО, не так ли?

См также:

Что такое транзакция

Что такое База Данных (БД)

Давайте пройдемся по каждой букве ACID и посмотрим на примерах, чем архив лучше 10 разных файлов. И чем транзакция лучше 10 отдельных запросов.

1. Atomicity — Атомарность

2. Consistency — Согласованность

3. Isolation — Изолированность

4. Durability — Надёжность

Atomicity — Атомарность

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

Друг познается в беде, а база данных — в работе с ошибками. О, если бы всё всегда было хорошо и без ошибок! Тогда бы никакие ACID были бы не нужны. Но как только возникает ошибка, атомарность становится очень важна.

Допустим, вы решили отправить маме деньги. Когда вы делаете перевод внутри банка, что происходит:

1. У вас деньги списались

2. Маме поступили

И допустим, что у нас 2 отдельных запроса. А теперь посмотрим, что будет при возникновении ошибок:

1.  У вас на балансе нет нужной суммы — система вывела сообщение об ошибке, но катастрофы не произошло, атомарность тут не нужна.

2.      У мамы заблокирована карточка, истек срок годности — деньги ей не поступили. Запрос отменен. Но минуточку… У вас то они уже списались!

Ошибка на первом этапе никаких проблем в себе не таит. А вот ошибка на втором… Приводит к потере денег, что явно недопустимо.

Если мы отправляем отдельные запросы, система не может связать их между собой. Запрос упал с ошибкой? Система его отменяет. Но только его, ведь она не знает о том, что запрос «у меня деньги спиши» связан с упавшим «сюда положи»!

Транзакция же позволяет сгруппировать запросы, то есть фактически показывает базе на взаимосвязи между ними. База сама о связях ничего не знает! Это знаете только вы =)

И если падает запрос внутри транзакции, база откатывает всю транзакцию. И приходит в состояние «как было до начала транзакции». Даже если там внутри было 10 запросов, вы можете спать спокойно — сломался один, откатятся все.

Consistency — Согласованность

Транзакция, достигающая своего нормального завершения (EOT — end of transaction, завершение транзакции) и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция по определению фиксирует только допустимые результаты ​ wikipedia

Это свойство вытекает из предыдущего. Благодаря тому, что транзакция не допускает промежуточных результатов, база остается консистентной. Есть такое определение транзакции: «Упорядоченное множество операций, переводящих базу данных из одного согласованного состояния в другое». То есть до выполнения операции и после база остается консистентной (в переводе на русский — согласованной).

Например, пользователь в системе заполняет карточку:

• ФИО

• Дата рождения

• ИНН

• Телефон — отдельно код страны, города и номер

• Адрес — тоже разбит на несколько полей

В базе данных у нас есть несколько таблиц:

• client

• phone

• address

Так что когда пользователь заполнил форму и нажал «сохранить», система отправляет в базу данных 3 запроса:

insert into client… -- вставить в таблицу клиентов такие-то данные

insert into phone…

insert into address…

Можно отправить 3 разных запроса, но лучше сделать одну транзакцию, внутри которой будут эти 3 запроса.

Атомарность гарантирует, что не получится такого, что адрес с телефоном сохранились, а сам клиент — нет. Это сделало бы базу неконсистентной, ведь у нас бы появились атрибуты, «висящие в воздухе», никому не принадлежащие. Что, в свою очередь, приведет к ошибкам в системе.

За консистентностью должен следить разработчик. Ведь это вопрос скорее бизнес-логики, чем технологий. Те же атрибуты, «висящие в воздухе» — это разработчик знает, что:

• если есть телефон в таблице phone

• он должен ссылаться на таблицу client

База об этом не знает ничего, если ей не рассказать. И она легко пропустит запрос «добавь в базу телефон без ссылки на клиента», если сам по себе запрос корректный, а разработчик не повесил на таблицу foreign key.

Можно повесить на таблицу constraint. Например, «баланс строго положительный». Тогда сценарий с ошибкой будет выглядеть так:

1.  Пользователь пытается перевести другу 100р, хотя у него самого 10

2.  Система отправляет в базу запрос — «обнови баланс карты, теперь там X – 100».

3.  База пытается выполнить запрос, но ой! Нарушен constraint, в итоге операции баланс стал отрицательным, эту ошибку она и возвращает.

4.  Система обрабатывает ошибку и выводит ее пользователю в читаемом виде.

К сожалению, нет единого механизма рассказать базе о том, какое состояние считается согласованным. Разработчик может использовать foreign ключи, какие-то констрейнты — это БД проверит. Но что с одного счета списалось, а на другой пришло — это БД уже не проверит. Это бизнес-логика.

Разработчик пишет код, пошагово переводящий БД в нужное согласованное состояние и, если где-то посередине возникает ошибка или нежданчик, откатывает всю транзакцию. То есть можно после каждого шага делать запрос, проверяя какое-то поле:

— Эй, баланс, ты ведь положительный остался?

— Ку-ку, тебе деньги пришли?

Если вдруг проверка не прошла, то кидаем ошибку и делаем откат.

Isolation — Изолированность

Во время выполнения транзакции параллельные транзакции не должны оказывать влияния на её результат.

Если у нас система строго для одного человека, проблем не будет. А если пользователей несколько? Тогда транзакции запускают в параллель — для ускорения работы системы. А иначе представьте себе, что вы делаете заказ в интернет-магазине и система вам говорит: «Вы в очереди, перед вами еще 100 человек хотят заказ оформить, подождите». Бред же? Бред!

Вот и приходится распараллеливать запросы. Но к каким эффектам может привести параллельная работа двух транзакций?

1 эффект: «Потерянная запись»

Есть некий счет А, на котором лежит 500 у.е.

Кассир 1 (К1 на рисунке) списал с него 300 у.е. Обозначим его действия рыжими стрелками. Списал 300, на выходе получает 200 = 500 — 300.

Кассир 2 (К2) тоже решил обратиться к этому же счету, и записал туда 300 у.е., пока К1 еще не успел закрыть свою транзакцию. Так как первая транзакция не закрыта, сумма на счете до сих пор 500, получаем 500 + 300 = 800.

Итог — мы «потеряли запись» первого кассира, ведь на выходе у нас А = 800, хотя должно быть 500. «Кто последний вписал результат — того и тапки». Получается так.

2 эффект: «Грязное чтение»

Есть некий счет А, на котором лежит 500 у.е.

Кассир 1 списал с него 300 у.е. Обозначим его действия рыжими стрелками. Списал 300. Потом передумал и сделал откат — на выходе остались те же 500 у.е.

Кассиру 2 (К2) понадобилась информация по этому счету и он ее считал до того, как К1 закрыл свою транзакцию.

Итог — второй кассир считал неверную сумму, построил неверный отчет/отказал в визе платежеспособному гражданину и т.д.

3 эффект: «Повторимое чтение»

Есть некие данные.

Кассир 1 строит отчет. Операции идут последовательно для каждой колонки. Система считала данные, записала в первую колонку (например, взяв минимум от них).

Обозначим получение данных зеленым цветом, а изменение — рыжим.

Кассир 2 влез в эту таблицу данных и изменил некоторые счета в ней.

У кассира 1 продолжается построение отчета. И во вторую колонку система считывает уже новые данные.

Итог — отчет построен на основании разных данных.

4 эффект: «Фантомы»

Есть некие данные.

Кассир 1 строит отчет. Операции идут последовательно для каждой колонки. Система считала данные, записала в первую колонку (например, взяв минимум от них).

Обозначим получение данных зеленым цветом, а изменение — рыжим.

Кассир 2 влез в эту таблицу данных и добавил новые счета/удалил некоторые старые.

У кассира 1 продолжается построение отчета. И во вторую колонку система считывает уже новые данные.

Итог — отчет построен на основании разных данных.

Разница между 3-им и 4-ым эффектами в том, что в одном случае данные изменяются, а во втором — добавляются/удаляются. То есть меняется ещё и их количество.

Как бороться

Как бороться с этими проблемами? Нужно изолировать транзакцию. Способов есть несколько, но основные — блокировки и версии.

Блокировки — это когда мы блокируем данные в базе. Можно заблокировать одну строку в таблице, а можно всю таблицу. Можно заблокировать данные на редактирование, а можно и на чтение тоже.

Подробнее о блокировках можно почитать тут:

• Блокировка (СУБД) — статья из вики

• Режимы блокировки — здесь хорошо описано, в чем отличие эксклюзивной от разделямой блокировки

• Transaction Isolation Levels in DBMS — статья на английском, но хорошо прошлись по разным уровням изоляции базы

Версии — это когда внутри базы при каждом обновлении создается новая версия данных и сохраняется старая. Версионирование скрыто от разработчика, то есть мы не видим в базе никаких номеров версий и данных по ним. Просто пока транзакция, обновляющая запись, не покомитит свое изменение, остальные потребители читают старую версию записи и не блокируются.

Durability — Надёжность

Если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя. Обесточилась система, произошел сбой в оборудовании? На выполненную транзакцию это не повлияет.

См также:

ACID в википедии

Транзакции, ACID, CAP — статья с geekbrains

Разбираем ACID по буквам в NoSQL — а это с Хабра

Ну и напомню ссылку на статьи «Что такое транзакция» и «Что такое База Данных (БД)».

P.S. — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале

В базах данных (далее БД, СУБД), ACID (Atomicity — атомарность, consistency — консистентность, isolation — изолированность, durability — стойкость) это стандартный набор свойств, которые гарантируют, надежность транзакции.

В частности, ACID имеет отношение к тому, как БД может восстанавливаться после ошибок, возникающих в процессе выполнения транзакции.

В базах данных, следующих принципу ACID, данные остаются целостными и консистентными, несмотря на любые ошибки.

Определение ACID

ACID это аббревиатура, означающая Atomicity — атомарность, Consistency — консистентность, Isolation — изолированность, Durability — стойкость. Расшифровка каждого понятия будет дана ниже.

Atomicity (атомарность)

Атомарность гарантирует, что каждый запрос в транзакции будет выполнен успешно, либо вообще никакой, в случае ошибки одного. Не получится так, что часть запросов выполнятся успешно, а часть с ошибкой. Если хоть одна часть транзакции выполнится с ошибкой, вся транзакция не выполнится. Другими словами под атомарностью можно понимать «всё или ничего».

Consistency (консистентность, согласованность)

Это свойство даёт гарантию того, что все данные будут целостны. Данные будут корректны в соотвествии со всеми предопределёнными правилами, ограничениями, каскадами и триггерами, применёнными к БД.

Isolation (изолированность)

Гарантирует, что все транзакции будут выполняться изолированно. Ни одна транзакция не зааффектит на другую транзакцию. Другими словами, одна транзакция не сможет прочитать данные второй транзакции, которая ещё не выполнилась.

Durability (стойкость)

Durability означает, что когда транзакция будет применена, она останется в системе, даже если БД упала сразу после выполнения этой транзакции. Любые изменения, внесённые транзакцией, должны оставаться навсегда. Если БД сообщила об успешном выполнении транзакции, то она должна быть действительно применена.

Когда пригодится ACID?

Свойства ACID спроектированы для transaction-ориентированные баз данных.

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

Транзакция это единая логическая операция, которая может состоять из одного или нескольких шагов. Например, транзакцией может быть перевод денежных средств между банковскими аккаунтами (снятие денег из одного и пополнение другого). Если в середине такой транзакции возникнет ошибка, может возникнуть большая неконсистентность в данных. Деньги будут вычтены с одного счёта, но не зачислены в другой.

Вот тут и должны быть применены принципы ACID.

Следуя принципу ACID, база данных будет целостна тогда и только тогда, когда она будет содержать все результаты успешно выполненных запросов, выполненных в транзакции. Любая ACID совместимая БД гарантирует, что будут применены изменения только успешных транзакций. В случае ошибки в транзакции, данные не будут изменены.

Таким образом, СУБД, совместимые с ACID, дают организациям уверенность в том, что данные в их базе данных будут целостны, даже если произойдёт какой-либо сбой в середине выполнения транзакции.

Типы сбоев

Ошибка транзакции

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

Системный сбой

Системный сбой может быть из-за ошибки в коде СУБД, либо аппаратного сбоя.

Медийные сбои

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

Следование ACID принципам

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

Но с NoSQL базами данных ситуация обстоит немного по-другому. Эти базы данных часто предназначены для обеспечения высокой доступности в кластере, а обычно это означает, что в некоторой степени жертвуют консистентностью и/или стойкостью. Однако большинство NoSQL баз данных в некоторой степени могут обеспечить атомарность.

Но всё же, большинстве NoSQL баз данных заложены основы целостности данных, что означает, что данные могут быть не синхронизированы какое-то время, но в конечном итоге они всё таки будут синхронизированы.

Вдобавок, некоторые разработчики, такие как MarkLogic, OrientDB и Neo4j, предлагают ACID-совместимые системы управления базами данных NoSQL.

Ссылка на оригинал статьи: https://database.guide/what-is-acid-in-databases/

Это тоже база данных, но ручная

Здравствуйте!

Поговорим об базах данных. Сегодня транзакции, ACID и CAP-теорема — теория, которая важна для следующих статей.

Транзакции

Транзакция — это набор действий с данными, объединенный в логическую единицу. Она либо выполняется целиком, либо нет. Классический пример с операцией перевода денег со счета на счет:

Начать транзакцию

прочесть баланс на счету номер 5

уменьшить баланс на 10 денежных единиц

сохранить новый баланс счёта номер 5

прочесть баланс на счету номер 7

увеличить баланс на 10 денежных единиц

сохранить новый баланс счёта номер 7

Окончить транзакцию

Если эти операции выполнять вне транзакции, то ошибка в любой из них оставит оба счета в несогласованном состоянии: например, выйдет так, что деньги снимутся с одного счета, а на другой не придут. С транзакцией таких проблем нет — при ошибке откатятся все операции и для пользователя ничего не изменится.

Все звучит просто, когда с базой данных работает один пользователь: он выполняет транзакции одна за другой и не имеет никаких проблем с тем, что одна транзакция помешает другой. Все меняется, когда пользователей становится много.

Вот что может случиться при параллельном выполнении неизолированных транзакций.

Потерянное обновление
Когда две транзакции записывают разные значения в одну и ту же ячейку, одно из изменений теряется.

Грязное чтение
Когда читаются данные, которые в этот момент изменяются транзакцией, а потом транзакция откатывается и данные исчезают.

Неповторяющееся чтение
Когда несколько раз читаются данные, которые в этот момент изменяются транзакцией — каждый раз данные могут отказаться другими.

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

Изоляция транзакций

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

Чтение неподтверждённых данных (read uncommitted)
Самый низкий уровень изоляции. Можно свободно читать незафиксированные изменения других транзакций, но запись идет строго последовательно. Таким образом, исключается только проблема потерянных обновлений: гарантируется, что в итоге в ячейку запишут нужное значение все транзакции по очереди.

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

Чтение подтверждённых данных (read committed)
Можно свободно читать все изменения своей транзакции и зафиксированные изменения чужих транзакций. Исключаются потерянные обновления и грязное чтение, остаются проблемы неповторяемых чтений и фантомов.

Повторяемое чтение (repeatable read)
Можно читать все изменения только своей транзации. Данные, измененные другими транзакциями, недоступны. Остается только проблема фантомных чтений.

Сериализуемый (serializable)
Транзакции полностью изолируются друг от друга, каждая выполняется так, как будто параллельных транзакций не существует.

ACID

Это набор из четырех требований к транзакционной системе, обеспечивающих максимально надежную и предсказуемую работу. Не все базы данных полностью реализуют ACID.

Атомарность (atomicity)
Атомарность гарантирует, что каждая транзакция будет выполнена полностью или не будет выполнена совсем. Не допускаются промежуточные состояния.

Согласованность (consistency)
Согласованность — это требование, подразумевающее, что в результате работы транзакции данные будут допустимыми. Это вопрос не технологии, а бизнес-логики: например, если количество денег на счете не может быть отрицательным, логика транзакции должна проверять, не выйдет ли в результате отрицательных значений.

Изолированность (isolation)
Гарантия того, что параллельные транзакции не будут оказывать влияния на результат других транзакций. Мы разобрались с изоляцией выше.

Долговечность (durability)
Изменения, получившиеся в результате транзакции, должны оставаться сохраненными вне зависимости от каких-либо сбоев. Иначе говоря, если пользователь получил сигнал о завершении транзакции, он может быть уверен, что данные сохранены.

CAP-теорема

Она гласит, что в распределенной системе можно обеспечить только два свойства из трех: согласованность, доступность и устойчивость к разделению. Помогает понимать, как конкретная распределенная система будет работать и чего от нее ожидать.

Согласованность данных (consistency)
Когда во всех узлах в каждый момент времени данные согласованы друг с другом, то есть не противоречат друг другу. Если в одном из узлов в ячейке базы данных есть данные, такие же данные есть на всех остальных узлах.

Доступность (availability)
Когда любой запрос может быть обработан системой, вне зависимости от ее состояния.

Устойчивость к разделению (partition tolerance)
Когда расщепление системы на несколько изолированных секций не приводит к некорректному отклику от каждой из секций: отвалилась сеть между двумя узлами, но каждый из них может корректно отвечать своим клиентам.

Все распределенные базы данных так или иначе в лучшем случае реализуют два свойства из трех, жертвуя оставшимся.

В следующей статье — о редких базах данных, которых вы не увидите в обычных проектах. Там нам и пригодится вся эта теория.

Введение

Транзакция — достаточно обширное понятие, которое используется в разных сферах жизни. Существует банковская транзакция — это операция, которая состоит в переводе денежных средств с одного счёта на другой. Или бывает банкоматная транзакция – выдача денег либо проведение иной операции с помощью терминала. В юриспруденции понятию «транзакция» придается значение схожее со значением понятия «сделка», а в психологии — это факт коммуникации между людьми (трансакция).

Наконец, для информационных технологий «транзакция» — это последовательность (одна или несколько) операций по работе с данными. Чтобы организовать правильный обмен данными к транзакциям и транзакционным системам применяются некоторые требования, которые легли в основу архитектуры современных баз данных.

Чтобы подробно изучить эти требования, обратимся к простому бытовому примеру.

Атомарность

Предположим, мы переводим средства с одного банковского счета на другой. Эта операция состоит из нескольких действий: первое — начало транзакции в ходе которого устанавливается соединение между счетами, далее идёт снятие определенной суммы (например, 300 рублей) со счёта №1, потом — добавление этой же суммы на счёт №2 и стадия завершения в конце транзакции, которую рассмотрим чуть подробнее ниже. Представим себе ситуацию, по которой зачисление средств не прошло или выполнилось с ошибкой. В таком случае, необходимо вернуть средства на счёт №1. В этом заключается первое требование к транзакционным системам, которое называется атомарностью.

Атомарность (Atomicity) вкратце описывается принципом «всё, или ничего». Это означает, что каждая транзакция должна выполняться полностью или не выполняться совсем.  У транзакции нет промежуточных состояний, т.е. она всегда является завершенной. У завершения транзакции есть 2 сценария: подтверждение (commit) и откат (rollback). Возвращаясь к случаю, когда средства сняты с банковского счета №1 и не поступили на счёт №2, в таком случае завершением транзакции станет rollback транзакции и возврат средств обратно на счёт №1. Если операции, входящие в транзакцию выполнены, происходит commit выполненных изменений.

Консистентность

После того как транзакция зафиксировала результаты и перевод средств с одного счёта на другой осуществлён, мы перевели нашу базу данных из одного состояния, в котором пользователь счета №1 был на 300 рублей богаче, а пользователь счёта №2 на 300 рублей беднее, в обратное состояние. При этом, деньги не появились из ниоткуда, т.е база внутри себя осталась согласованной или консистентной. Требование консистентности (Consistency) является вторым к транзакционным системам и логически вытекает из требования атомарности, т.е. каждая выполненная транзакция фиксирует только допустимые результаты. Если со счёта №1 снято 300 рублей, на счёт №2 не должно прийти 200 или 400 рублей, что также предусматривается требованиями консистентности. В этом смысле, данное требование также схоже с законом сохранения энергии в естественных науках.

Также требование консистентности подразумевает, что данные не будут принимать недопустимых значений. Например, средства на счету не принимают отрицательных значений.

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

Изолированность

При работе со счетами, обозначенными в нашем примере, может быть не один, а сразу несколько пользователей. А что, если таких пользователей будет несколько десятков или даже сотен?

В случае параллельного выполнения транзакций разными пользователями возникают различные проблемы. Например, если с того же счёта №1, на котором лежит 300 рублей, идёт параллельное выполнение 2-ух транзакций. По одной мы списываем 200 рублей, по другой — начисляем 200 рублей. Если во время выполнения начисления 200 рублей, списание не успело пройти, на счёте мы увидим 500 рублей. Первая транзакция в этом случае потеряется. Такая проблема называется потерянным обновлением.

Еще пример, мы списываем все 300 рублей с того же счёта №1. В этот момент другой пользователь запросил данные с этого счёта и увидел, что на нём осталось 0 рублей. Однако, мы откатили транзакцию по снятию 300 рублей и деньги вернулись на счёт. Получается, другой пользователь получил ошибочные данных о состоянии счёта №1. Это называется «грязным» чтением.

Еще варианты возникновения проблем при совместном выполнении транзакций лучше описываются на примере построения отчётов, и возникают, когда идут одновременные транзакции на чтение и обновление данных. Например, если один пользователь будет считать сумму совершенных покупок по счёту №1, а второй, в это же время, обновит данные по покупкам. Тогда результат чтения суммы покупок по счёту №1 будет неправильным, возникнет ошибка, называемая неповторяющимся чтением. В том же случае, если второй пользователь не обновит, а удалит или запишет дополнительные покупки по счёту №1, тогда первый пользователь получит ошибку фантомного чтения.

Чтобы избежать таких проблем с транзакциями, вводится требование на изолированность (Isolation) для других пользователей. Есть несколько уровней изоляции транзакций, но все они сводятся к блокировке действий одного пользователя, при выполнении изменения или чтения данных другим пользователем. Иногда изолированности транзакций добиваются не введением блокировок, а с помощью версифицирования. Проще говоря, пока записывающая транзакция не сделает commit изменений, остальные пользователи читают старую версию записи и не блокируются.

Более высокий уровень изолированности улучшает согласованность системы с одной стороны, но с другой стороны уменьшает количество параллельно выполняемых транзакций, т.е скорость системы. Поэтому соблюдение требования изолированности транзакционной системы всегда является «палкой о двух концах».

Устойчивость

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

Заключение

Таким образом, мы узнали что такое транзакция в разных смыслах значения этого понятия. Мы узнали из каких этапов состоит транзакция, какие сценарии завершения транзакции существуют и чем отличаются. Узнали какие требования к транзакционной системе предъявляют свойства атомарности, консистентности, изолированности и устойчивости транзакций.

Требования ACID являются фундаментальными основами устройства реляционных СУБД и обеспечивают наиболее надёжную и предсказуемую работу с данными.

На одном из модулей курса по BI-аналитике мы рассмотрим эти и другие принципы работы современных баз данных, способы взаимодействия и подключения к ним, а также язык запросов к данным SQL. По ссылке вы сможете более подробно узнать о курсе, а также зарегистрироваться на бесплатный пробный урок.

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

Как правило, говоря о транзакции, имеют в виду операции над базой данных, однако понятие транзакции применимы и для работы с другими источниками информации, например, системой поддержки сообщений.

Основные требования к системе, поддерживающей транзакцию,описываются аббревиатурой ACID (которая расшифровывается как Atomicity, Consistency, Isolation, Durability).

• Atomicity — атомарность. Любые изменения в результате транзакции либо фиксируются (commit), либо откатываются (rollback).

• Consistency — согласованность. Если до начала транзакции данные не противоречили друг другу, то и после окончания транзакции они не должны быть противоречивыми. Например, если в процессе транзакции выполнялся перевод средств с одного счета на другой, то сумма денег на обоих счетах после выполнения транзакции должна оставаться такой же, как и до начала транзакции. (Следует заметить, что внутри транзакции согласованность не требуется. Возвращаясь к примеру перевода денег со счета на счет, списание средств с одного счета и помещение их на другой счет выполняются последовательно и между этими двумя операциями данные оказываются несогласованными.)

• Isolation — изолированность. Работающие одновременно транзакции не влияют друг на друга. Другими словами, результат параллельного выполнения двух транзакций должен быть идентичен результату их последовательного выполнения.

• Durability — надежность. Если транзакция была успешно завершена, никакое внешнее событие (например, аппаратный сбой) не должно привести к потере изменений.

Источники:
Транзакция (информатика) — Википедия
Транзакция — что это такое? Определение, значение, перевод

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

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

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

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

Содержание

• 1 Характеристики
  • 1.1 Атомарность
  • 1.2 Согласованность
  • 1.3 Изоляция
  • 1.4 Долговечность
• 2 Примеры
  • 2.1 Атомарность
  • 2.2 Нарушение согласованности
  • 2.3 Нарушение изоляции
  • 2.4 Нарушение долговечности
• 3 Реализация
  • 3.1 Блокировка и многоверсионность
  • 3.2 Распределенные транзакции
• 4 См. Также
• 5 Ссылки

Характеристики

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

Атомарность

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

Примером атомарной транзакции является денежный перевод с банковского счета 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.

Объединенные, есть четыре действия:

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

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

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

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

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

См. Также

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

Ссылки