Автор оригинала: Vlad Mihalcea.
Транзакции вездесущи в современных корпоративных системах, обеспечивая целостность данных даже в очень параллельных средах. Итак, давайте начнем с определения термина и контекста, в котором вы обычно его используете.
Транзакция-это набор операций чтения/записи, которые выполняются успешно только в том случае, если все содержащиеся в них операции выполняются успешно.
По своей сути транзакция характеризуется четырьмя свойствами (обычно называемыми кислотными).:
- Атомарность
- Консистенция
- Изоляция
- Долговечность
В реляционной базе данных каждая инструкция SQL должна выполняться в области транзакции. Без явного определения границ транзакций база данных будет использовать неявную транзакцию, которая обертывается вокруг каждого отдельного оператора. Неявная транзакция начинается до выполнения инструкции и заканчивается (фиксация или откат) после выполнения инструкции. In a relational database, every SQL statement must execute in the scope of a transaction. Without defining the transaction boundaries explicitly, the database is going to use an implicit transaction which is wraps around every individual statement. The implicit transaction begins before the statement is executed and end (commit or rollback) after the statement is executed. The implicit transaction mode is commonly known as autocommit . Режим неявной транзакции обычно известен как
Для корпоративного приложения режим автоматической фиксации-это то, чего обычно следует избегать, поскольку он имеет серьезные проблемы с производительностью и не позволяет включать несколько операций DML в одну атомарную единицу работы.
Очень важно понять их, поэтому мы обсудим каждый из них следующим образом.
Атомарность берет отдельные операции и превращает их в единицу работы “все или ничего”, успешную тогда и только тогда, когда все содержащиеся в ней операции успешны.
Транзакция может инкапсулировать изменение состояния (если только она не предназначена только для чтения). Транзакция всегда должна оставлять систему в согласованном состоянии, независимо от того, сколько одновременных транзакций чередуется в любой момент времени.
Согласованность означает, что ограничения применяются для каждой зафиксированной транзакции. Это означает, что все Ключи, типы данных, Проверки и Триггеры выполнены успешно и нарушение ограничений не инициируется.
Транзакции требуют механизмов контроля параллелизма, и они гарантируют правильность даже при чередовании. Изоляция дает нам преимущество в сокрытии незафиксированных изменений состояния от внешнего мира, поскольку неудачные транзакции никогда не должны портить состояние системы. Изоляция достигается за счет управления параллелизмом с использованием пессимистичных или оптимистичных механизмов блокировки.
Успешная транзакция должна навсегда изменить состояние системы, и перед ее завершением изменения состояния записываются в сохраняемый журнал транзакций . Если наша система внезапно пострадает от сбоя системы или отключения электроэнергии, то все незавершенные совершенные транзакции могут быть воспроизведены повторно.
Для систем обмена сообщениями , таких как JMS , транзакции не являются обязательными. Вот почему у нас нет транзакций режимы подтверждения .
Операции с файловой системой обычно не управляются, но если ваши бизнес-требования требуют операций с файлами транзакций, вы можете использовать такой инструмент, как XADisk.
В то время как системы обмена сообщениями и файловые системы используют транзакции необязательно, для систем управления базами данных транзакции являются обязательными.
КИСЛОТА-это старая школа. ACID is old school. Jim Gray described atomicity, consistency and durability long before I was even born. But that particular paper doesn’t mention anything about isolation. This is understandable if we think of the production systems of the late ’70s, which according to Jim Gray: Джим Грей
“At present, the largest airlines and banks have about 10,000 terminals and about 100 active transactions at any instant”. В настоящее время крупнейшие авиакомпании и банки имеют около 10 000 терминалов и около 100 активных транзакций в любой момент”.
Таким образом, все усилия были потрачены на обеспечение корректности, а не параллелизма. С тех пор все кардинально изменилось, и в настоящее время даже скромные настройки способны работать на скорости 1000 Т/с.
С точки зрения базы данных атомарность является фиксированным свойством, но все остальное может быть продано по соображениям производительности/масштабируемости.
Если система базы данных состоит из нескольких узлов, согласованность распределенной системы (C в Теореме CAP не C в ACID) требует, чтобы все изменения распространялись на все узлы ( репликация с несколькими мастерами ). Если узлы реплики обновляются асинхронно, мы нарушаем правило согласованности, и система становится ” в конечном итоге согласованной “.
У Питера Бейлиса есть очень хорошая статья , объясняющая разницу между согласованностью в теореме CAP и согласованностью в КИСЛОТЕ.
Транзакция – это переход в состояние данных, поэтому система должна работать так, как если бы все транзакции выполнялись последовательно, даже если они выполняются одновременно. A transaction is a data state transition, so the system must operate as if all transactions occur in a serial form even if those are concurrently executed. If there would be only one connection running at all times, then serializability wouldn’t impose any concurrency control cost. In reality, all transactional systems must accommodate concurrent requests, hence serialization has its toll on scalability. The Amdahl’s law describes the relation between serial execution and concurrency: Если бы все время работало только одно соединение, то сериализуемость не накладывала бы никаких затрат на управление параллелизмом. На самом деле все транзакционные системы должны учитывать одновременные запросы, поэтому сериализация влияет на масштабируемость. Закон
“The speedup of a program using multiple processors in parallel computing is limited by the time needed for the sequential fraction of the program.” Ускорение программы, использующей несколько процессоров при параллельных вычислениях, ограничено временем, необходимым для последовательной части программы”.
Как вы увидите позже, большинство систем управления базами данных выбирают (по умолчанию) ослабление гарантий корректности для достижения лучшего параллелизма.
Игра с долговечностью имеет смысл для высокопроизводительных кластеризованных баз данных , если бизнес-требования корпоративной системы не требуют длительных транзакций. Но чаще всего долговечность лучше не трогать.
Хотя некоторые системы управления базами данных предлагают MVCC , обычно контроль параллелизма достигается за счет блокировки. Но, как мы все знаем, блокировка увеличивает сериализуемую часть выполняемого кода, влияя на распараллеливание .
Стандарт SQL определяет четыре уровня изоляции:
- READ_UNCOMMITTED
- READ_COMMITTED
- REPEATABLE_READ
- СЕРИАЛИЗУЕМЫЙ
Все, кроме СЕРИАЛИЗУЕМОГО уровня, подвержены аномалиям данных (явлениям), которые могут происходить по следующей схеме:
| разрешено | разрешено | READ_UNCOMMITTED | разрешено |
| предотвращено | разрешено | READ_COMMITTED | разрешено |
| предотвращено | разрешено | REPEATABLE_READ | предотвращено |
| предотвращено | предотвращено | СЕРИАЛИЗУЕМЫЙ | предотвращено |
Но что это за явления, которые мы только что перечислили? Давайте обсудим каждый из них.
Грязное чтение
Грязное чтение происходит, когда транзакции разрешено считывать незафиксированные изменения какой-либо другой выполняемой транзакции. Это происходит потому, что этому не препятствует блокировка. На рисунке выше вы можете видеть, что вторая транзакция использует несогласованное значение, так как первая транзакция откатилась.
Для получения дополнительной информации об аномалии грязного чтения ознакомьтесь с этой статьей .
Неповторяемое чтение
Неповторяемое чтение проявляется, когда последовательные чтения дают разные результаты из-за совпадающей транзакции, которая только что обновила запись, которую мы читаем. Это нежелательно, так как в конечном итоге мы используем устаревшие данные. Это предотвращается путем удержания общей блокировки (блокировки чтения) на записи чтения в течение всего срока текущей транзакции.
Для получения дополнительной информации о неповторяемой аномалии чтения ознакомьтесь с этой статьей .
Фантом прочитал
Фантомное чтение происходит, когда последующая транзакция вставляет строку, соответствующую критериям фильтрации предыдущего запроса, выполненного параллельной транзакцией. Поэтому мы в конечном итоге используем устаревшие данные, которые могут повлиять на нашу деловую деятельность. Это предотвращается с помощью блокировок диапазона или блокировки предикатов .
Для получения дополнительной информации об аномалии чтения Фантома ознакомьтесь с этой статьей .
Еще больше явлений
Даже если это не упоминается в стандарте SQL, есть еще больше явлений, о которых вы должны знать, например:
- Потерянные Обновления
- Читать Косо
- Пишите Косо
Знание того, когда могут произойти эти явления, может надлежащим образом их устранить-вот в чем заключается целостность данных.
Уровни Изоляции По Умолчанию
Даже если стандарт SQL предписывает использование уровня СЕРИАЛИЗУЕМОЙ изоляции, большинство систем управления базами данных используют другой уровень по умолчанию.
| Оракул | READ_COMMITTED |
| MySQL | REPEATABLE_READ |
| Microsoft SQL Server | READ_COMMITTED |
| PostgreSQL | READ_COMMITTED |
| DB2 | СТАБИЛЬНОСТЬ КУРСОРА |
Вывод
Обычно ФИКСАЦИЯ ЧТЕНИЯ является правильным выбором, так как даже СЕРИАЛИЗУЕМОЕ не может защитить вас от потерянного обновления, когда чтение/запись происходят в разных транзакциях (и веб-запросах) . Вы должны принять во внимание требования к корпоративной системе и настроить тесты, чтобы решить, какой уровень изоляции лучше всего соответствует вашим потребностям.