В системах баз данных изоляция определяет, насколько целостность транзакций видна другим пользователям и системам. Более низкий уровень изоляции увеличивает возможность многих пользователей одновременно получать доступ к одним и тем же данным, но также увеличивает количество эффектов параллелизма (таких как некорректное чтение или потеря обновлений), с которыми могут столкнуться пользователи. И наоборот, более высокий уровень изоляции уменьшает количество эффектов параллелизма, с которыми могут столкнуться пользователи, но требует больше системных ресурсов и увеличивает вероятность того, что одна транзакция заблокирует другую. [1]
Изоляция обычно определяется на уровне базы данных как свойство, которое определяет, как и когда изменения, внесенные одной операцией, становятся видимыми для других. В старых системах это можно реализовать системно, например, с помощью временных таблиц. В двухуровневых системах для поддержания изоляции требуется менеджер обработки транзакций (TP). В многоуровневых системах (таких как несколько веб-сайтов, пытающихся забронировать последнее место на рейс) для подтверждения бронирования и отправки подтверждения клиенту требуется сочетание хранимых процедур и управления транзакциями. [2]
Изоляция — одно из четырёх свойств ACID , наряду с атомарностью , согласованностью и долговечностью .
Управление параллелизмом включает в себя базовые механизмы СУБД , которые обеспечивают изоляцию и гарантируют соответствующую корректность. Он активно используется базой данных и механизмами хранения как для обеспечения правильного выполнения параллельных транзакций, так и (посредством различных механизмов) для корректности других процессов СУБД. Механизмы, связанные с транзакциями, обычно ограничивают время операций доступа к данным базы данных ( расписания транзакций ) определенными порядками, характеризуемыми как свойства расписания сериализуемости и возможности восстановления . Ограничение выполнения операций доступа к базе данных обычно означает снижение производительности (измеряемой скоростью выполнения), и поэтому механизмы управления параллелизмом обычно разрабатываются так, чтобы обеспечить максимально возможную производительность в условиях ограничений. Часто, если это возможно без ущерба для корректности, свойство сериализуемости подвергается риску ради повышения производительности. Однако возможность восстановления не может быть поставлена под угрозу, поскольку это обычно приводит к быстрому нарушению целостности базы данных.
Двухфазная блокировка — наиболее распространенный метод управления параллелизмом транзакций в СУБД, используемый для обеспечения как сериализуемости, так и возможности восстановления корректности. Чтобы получить доступ к объекту базы данных, транзакция сначала должна получить блокировку для этого объекта. В зависимости от типа операции доступа (например, чтение или запись объекта) и типа блокировки получение блокировки может быть заблокировано и отложено, если другая транзакция удерживает блокировку для этого объекта.
Стандарт ANSI/ISO SQL 92 относится к трем различным явлениям чтения , когда транзакция извлекает данные, которые могли быть обновлены другой транзакцией.
В следующих примерах имеют место две транзакции. В транзакции 1 выполняется запрос, затем в транзакции 2 выполняется обновление и, наконец, в транзакции 1 снова выполняется тот же запрос.
В примерах используется следующее соотношение:
Основная статья: Конфликт записи и чтения
Грязное чтение (так называемая незафиксированная зависимость ) происходит, когда транзакция извлекает строку, которая была обновлена другой транзакцией, которая еще не зафиксирована.
В этом примере транзакция 1 извлекает строку с идентификатором 1, затем транзакция 2 обновляет строку с идентификатором 1 и, наконец, транзакция 1 снова получает строку с идентификатором 1. Теперь, если транзакция 2 откатывает свое обновление (уже полученное транзакцией 1) или выполняет другие обновления, то представление строки может быть неверным в транзакции 1. На уровне изоляции READ UNCOMMITTED второй SELECT в транзакции 1 извлекает обновленную строку. : это грязное чтение. На уровнях изоляции READ COMMITTED, REPEATABLE READ и SERIALIZABLE второй запрос SELECT в транзакции 1 извлекает начальную строку.
Неповторяющееся чтение происходит, когда транзакция дважды извлекает строку, и эта строка обновляется другой транзакцией, которая фиксируется между ними.
В этом примере транзакция 1 извлекает строку с идентификатором 1, затем транзакция 2 обновляет строку с идентификатором 1 и фиксируется, и, наконец, транзакция 1 снова получает строку с идентификатором 1. На уровнях изоляции READ UNCOMMITTED и READ COMMITTED второй запрос SELECT в транзакции 1 извлекает обновленную строку: это неповторяемое чтение. На уровнях изоляции REPEATABLE READ и SERIALIZABLE второй SELECT в транзакции 1 извлекает начальную строку.
Фантомное чтение происходит, когда транзакция дважды извлекает набор строк, а новые строки вставляются в этот набор или удаляются из него другой транзакцией, которая фиксируется между ними.
В этом примере транзакция 1 извлекает набор строк с возрастом больше 17, затем транзакция 2 вставляет строку с возрастом 26 и фиксируется, и, наконец, транзакция 1 снова извлекает набор строк с возрастом больше 17. На уровнях изоляции READ UNCOMMITTED, READ COMMITTED и REPEATABLE READ второй запрос SELECT в транзакции 1 извлекает новый набор строк, включающий вставленную строку: это фантомное чтение. На уровне изоляции SERIALIZABLE второй SELECT в транзакции 1 извлекает исходный набор строк.
Существует две основные стратегии, используемые для предотвращения неповторяющегося чтения и фантомного чтения. В первой стратегии, управлении параллелизмом на основе блокировок , транзакция 2 фиксируется после фиксации или отката транзакции 1. Он создает серийный график T1, T2 . В другой стратегии, многоверсионном управлении параллелизмом , транзакция 2 фиксируется немедленно, в то время как транзакция 1, которая началась до транзакции 2, продолжает работать со старым снимком базы данных, сделанным в начале транзакции 1, и когда транзакция 1 в конечном итоге пытается зафиксировать , если результат фиксации будет эквивалентен последовательному расписанию T1, T2 , то транзакция 1 фиксируется; в противном случае возникает конфликт фиксации, и транзакция 1 откатывается с ошибкой сериализации.
При управлении параллелизмом на основе блокировок неповторяющиеся чтения и фантомные чтения могут возникать, когда блокировки чтения не устанавливаются при выполнении SELECT или когда полученные блокировки на затронутых строках снимаются, как только выполняется SELECT. При управлении многоверсионным параллелизмом неповторяемые чтения и фантомные чтения могут возникать, когда требование о том, что транзакция, затронутая конфликтом фиксации, должна быть откатана, ослаблено.
Из четырех свойств ACID в СУБД (системе управления базами данных) свойство изоляции чаще всего ослабляется. Пытаясь поддерживать самый высокий уровень изоляции, СУБД обычно блокирует данные , что может привести к потере параллелизма , или реализует управление многоверсионным параллелизмом . Это требует добавления логики для правильной работы приложения .
Большинство СУБД предлагают несколько уровней изоляции транзакций , которые контролируют степень блокировки, возникающей при выборе данных. Для многих приложений баз данных большинство транзакций базы данных можно сконструировать так, чтобы избежать необходимости высоких уровней изоляции (например, уровня SERIALIZABLE), что снижает накладные расходы на блокировку в системе. Программист должен тщательно проанализировать код доступа к базе данных, чтобы гарантировать, что любое ослабление изоляции не приведет к ошибкам в программном обеспечении, которые трудно обнаружить. И наоборот, если используются более высокие уровни изоляции, вероятность взаимоблокировки увеличивается, что также требует тщательного анализа и методов программирования, чтобы избежать этого.
Поскольку каждый уровень изоляции сильнее, чем те, что ниже, и ни один более высокий уровень изоляции не допускает действия, запрещенного более низким, стандарт разрешает СУБД запускать транзакцию на более высоком уровне изоляции, чем запрошенный (например, «Чтение зафиксировано»). транзакция может фактически выполняться на уровне изоляции «Повторяемое чтение»).
Уровни изоляции, определенные стандартом ANSI / ISO SQL , перечислены ниже.
Это высший уровень изоляции.
При реализации СУБД управления параллелизмом на основе блокировок сериализуемость требует снятия блокировок чтения и записи (полученных для выбранных данных) в конце транзакции. Также необходимо получить блокировки диапазона , когда запрос SELECT использует предложение WHERE с диапазоном , особенно во избежание явления фантомного чтения .
При использовании управления параллелизмом без блокировки блокировки не устанавливаются; однако, если система обнаруживает конфликт записи среди нескольких одновременных транзакций, только одной из них разрешается зафиксировать. Дополнительные сведения по этой теме см. в разделе Изоляция снимков .
Из: (Второй неофициальный обзорный проект) ISO/IEC 9075:1992, Язык баз данных SQL – 30 июля 1992 г.: Выполнение параллельных SQL-транзакций на уровне изоляции SERIALIZABLE гарантированно будет сериализуемым. Сериализуемое выполнение определяется как выполнение операций одновременного выполнения SQL-транзакций, дающее тот же эффект, что и некоторое последовательное выполнение тех же самых SQL-транзакций. Последовательное выполнение — это выполнение, при котором каждая SQL-транзакция выполняется до завершения до начала следующей SQL-транзакции.
На этом уровне изоляции реализация СУБД с управлением параллелизмом на основе блокировок сохраняет блокировки чтения и записи (полученные для выбранных данных) до конца транзакции. Однако блокировки диапазона не управляются, поэтому может произойти фантомное чтение .
В некоторых системах на этом уровне изоляции возможен перекос записи. Перекос записи — это явление, когда две записи разрешены в один и тот же столбец(ы) таблицы двумя разными авторами (которые ранее читали обновляемые столбцы), в результате чего столбец содержит данные, представляющие собой смесь двух транзакций. . [3] [4]
На этом уровне изоляции реализация СУБД с управлением параллелизмом на основе блокировки сохраняет блокировки записи (полученные для выбранных данных) до конца транзакции, но блокировки чтения снимаются, как только выполняется операция SELECT (так что явление неповторяющегося чтения может произойти на этом уровне изоляции). Как и на предыдущем уровне, блокировки диапазона не управляются.
Проще говоря, чтение зафиксировано — это уровень изоляции, который гарантирует, что любые прочитанные данные будут зафиксированы в момент их чтения. Это просто не позволяет читателю видеть промежуточное, незафиксированное, «грязное» чтение. Он не дает никаких обещаний, что если транзакция повторно выполнит операцию чтения, она найдет те же данные; данные могут быть изменены после прочтения.
Это самый низкий уровень изоляции. На этом уровне разрешены «грязные» чтения , поэтому одна транзакция может видеть еще не зафиксированные изменения, внесенные другими транзакциями.
Уровень изоляции по умолчанию для разных СУБД варьируется в широких пределах. Большинство баз данных, содержащих транзакции, позволяют пользователю устанавливать любой уровень изоляции. Некоторые СУБД также требуют дополнительного синтаксиса при выполнении оператора SELECT для получения блокировок (например, SELECT … FOR UPDATE для получения эксклюзивных блокировок записи для строк, к которым осуществляется доступ).
Однако приведенные выше определения подверглись критике как двусмысленные и неточно отражающие изоляцию, обеспечиваемую многими базами данных:
Есть и другие критические замечания в отношении определения изоляции ANSI SQL, поскольку оно побуждает разработчиков делать «плохие вещи»:
Сериализуемая аномалия — это не то же самое, что сериализуемая. То есть необходимо, но недостаточно, чтобы сериализуемый график был свободен от всех трех типов явлений. [5]
(см. выше примерно на 13:30 минуте трансляции!)