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

Руководство для начинающих: ACID и транзакции БД

Введение

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

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

По сути транзакции характеризуются следующими четырьмя свойствами (также известными как ACID):

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

Режим неявной транзакции известен так же как режим autocommit.

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

Это очень важно понимать и далее мы обсудим каждое из свойств.

Атомарность

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

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

Консистентность (согласованность)

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

Изоляция

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

Долговечность

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

Для систем сообщений, как JMS, транзакции не являются обязательными. Именно по этой причине в спецификации есть режимы подтверждения вне транзакций.

Операции с файловой системой обычно не контролируются, но если бизнес-требования требуют транзакций для операций с файлами, Вы можете использовать инструмент, такой как XADisk.

В то время как для файловых систем и систем передачи сообщений использование транзакций опционально, то для БД контроль за транзакциями обязателен.

Уровни изолированности

Хотя некоторые СУБД предлагают MVCC, обычно управление параллельным выполнением операций достигается через блокировку. Но, как мы знаем, блокировка увеличивает долю сериализации выполняемого кода, влияя на параллелизацию.

Стандарты SQL определяют 4 уровня изолированности:

Все уровни, кроме SERIALIZABLE уровня подвержены аномалии данных (феномен), которые могут произойти согласно следующей схеме:

Феномены

Давайте обсудим каждую из аномалий.

Dirty Read («Грязное» чтение)

«Грязное» чтение происходит когда транзакция может прочитать незаконченные изменения некоторой другой выполняемой транзакции. Явление случается из-за того что нет блокировки предотвращающей это. На изображении сверху можно увидеть что вторая транзакция использует неконсистентное значение первой транзакции, которая впоследствии подверглась «откату». Так как данный эффект возможен только при минимальном уровне изоляции, а по умолчанию используется более высокий уровень изоляции (READ COMMITTED), то в скрипте чтения данных уровень изоляции будет явно установлен как READ UNCOMMITTED. Если вернуть уровень изоляции по умолчанию (READ COMMITTED) для транзакции 2, то поведение поменяется.

Non-repeatable read (Неповторяющееся чтение)

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

Phantom read (Фантомное чтение)

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

Следовательно, мы используем устравшие данные, который могут оказать негативное влияние на работу системы. Это предотвращается с помощью использования блокировки по диапазону или блокировки предикатами.

Уровни изолированности по умолчанию

Даже если SQL стандарт обязывает использовать уровень изоляции SERIALIZABLE, большинство СУБД используют разный уровень по умолчанию.

Обычно, READ_COMMITED является правильным выбором, поскольку даже SERIALIZABLE не может защитить Вас от потери обновлений во время выполнения чтения/записей в разных транзакций и веб-реквестов. Вы должны принять во внимание эту информацию при принятии решения об уровне изоляции в требованиях enterprise систем.

Источник

Транзакции, ACID, CAP

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

Транзакции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CAP-теорема

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

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

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

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

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

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

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

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

Транзакции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CAP-теорема

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

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

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

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

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

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

Источник

Что такое ACID в базах данных?

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

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

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

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.

Источник