Изоляция (системы баз данных)

В баз данных системах изоляция является одним из ACID ( атомарность, согласованность , изоляция , долговечность ) свойств транзакции . Он определяет, насколько целостность транзакции видна другим пользователям и системам. Более низкий уровень изоляции увеличивает возможность многих пользователей одновременно получать доступ к одним и тем же данным, но также увеличивает количество эффектов параллелизма (таких как некорректное чтение или потеря обновлений), с которыми могут столкнуться пользователи. И наоборот, более высокий уровень изоляции уменьшает количество эффектов параллелизма, с которыми могут столкнуться пользователи, но требует больше системных ресурсов и увеличивает вероятность того, что одна транзакция заблокирует другую. ^[1]

Управление параллелизмом СУБД [ править ]

Управление параллелизмом включает в себя базовые механизмы СУБД, которые обеспечивают изоляцию и гарантируют соответствующую корректность. Он активно используется базой данных и механизмами хранения как для обеспечения правильного выполнения параллельных транзакций, так и (посредством различных механизмов) для корректности других процессов СУБД. Механизмы, связанные с транзакциями, обычно ограничивают время операций доступа к данным базы данных ( расписания транзакций ) определенными порядками, характеризуемыми как свойства расписания сериализуемости и возможности восстановления . Ограничение выполнения операций доступа к базе данных обычно означает снижение производительности (измеряемой скоростью выполнения), и поэтому механизмы управления параллелизмом обычно разрабатываются так, чтобы обеспечить максимально возможную производительность в условиях ограничений. Часто, если это возможно без ущерба для корректности, свойство сериализуемости подвергается риску ради повышения производительности. Однако возможность восстановления не может быть поставлена под угрозу, поскольку это обычно приводит к быстрому нарушению целостности базы данных. . ^{[ нужна цитата ]}

Двухфазная блокировка — наиболее распространенный метод управления параллелизмом транзакций в СУБД, используемый для обеспечения как сериализуемости, так и возможности восстановления корректности. Чтобы получить доступ к объекту базы данных, транзакция сначала должна получить блокировку для этого объекта. В зависимости от типа операции доступа (например, чтение или запись объекта) и типа блокировки получение блокировки может быть заблокировано и отложено, если другая транзакция удерживает блокировку для этого объекта. ^{[ нужна цитата ]}

Изоляция на стороне клиента [ править ]

Изоляция обычно обеспечивается на уровне базы данных. Однако также можно использовать различные клиентские системы. Им можно управлять в средах приложений или контейнерах времени выполнения, таких как J2EE Entity Beans. ^[2] В старых системах это может быть реализовано системно (разработчиками приложений), например, с помощью временных таблиц. ^{[ не удалось пройти проверку ]}В двухуровневых, трехуровневых или n-уровневых веб-приложениях диспетчер транзакций для поддержания изоляции можно использовать . Менеджер транзакций — это промежуточное программное обеспечение , которое находится между службой приложений (внутренней службой приложений) и операционной системой. Менеджер транзакций может обеспечить глобальную изоляцию и атомарность. Он отслеживает, когда новые серверы присоединяются к транзакции, и координирует протокол атомарной фиксации между серверами. Детали абстрагируются от приложения, что упрощает кодирование транзакций. Монитор обработки транзакций (TPM) — это набор промежуточного программного обеспечения, включающий менеджер транзакций. TPM может обеспечить локальную изоляцию приложения с помощью диспетчера блокировок. ^[2]

Читать Феномены [ править ]

Стандарт ANSI/ISO SQL 92 относится к трем различным явлениям чтения, когда транзакция извлекает данные, которые могли быть обновлены другой транзакцией.

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

В примерах используется следующее соотношение:

пользователи
идентификатор	имя	возраст
1	Алиса	20
2	Боб	25

Грязное чтение [ править ]

Основная статья: Конфликт записи и чтения

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

В этом примере транзакция 1 извлекает строку с идентификатором 1, затем транзакция 2 обновляет строку с идентификатором 1 и, наконец, транзакция 1 снова получает строку с идентификатором 1. Теперь, если транзакция 2 откатывает свое обновление (уже полученное транзакцией 1) или выполняет другие обновления, то представление строки может быть неверным в транзакции 1. На уровне изоляции READ UNCOMMITTED второй SELECT в транзакции 1 извлекает обновленную строку. : это грязное чтение. На уровнях изоляции READ COMMITTED, REPEATABLE READ и SERIALIZABLE второй запрос SELECT в транзакции 1 извлекает начальную строку.

Транзакция 1	Транзакция 2
НАЧИНАТЬ ; ВЫБЕРИТЕ возраст ИЗ пользователей ГДЕ id = 1 ; -- извлекает 20
	НАЧИНАТЬ ; ОБНОВЛЕНИЕ пользователей SET age = 21 WHERE id = 1 ; -- здесь нет фиксации
ВЫБЕРИТЕ возраст ИЗ пользователей ГДЕ id = 1 ; -- READ UNCOMMITTED извлекает 21 (грязное чтение) -- READ COMMITTED извлекает 20 (грязное чтение удалось избежать) -- REPEATABLE READ извлекает 20 (грязное чтение удалось избежать) -- SERIALIZABLE извлекает 20 (грязное чтение удалось избежать) COMMIT ;
	ОТКАТ ;

Неповторяющееся чтение [ править ]

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

В этом примере транзакция 1 извлекает строку с идентификатором 1, затем транзакция 2 обновляет строку с идентификатором 1 и фиксируется, и, наконец, транзакция 1 снова получает строку с идентификатором 1. На уровнях изоляции READ UNCOMMITTED и READ COMMITTED второй запрос SELECT в транзакции 1 извлекает обновленную строку: это неповторяемое чтение. На уровнях изоляции REPEATABLE READ и SERIALIZABLE второй SELECT в транзакции 1 извлекает начальную строку.

Транзакция 1

Транзакция 2

НАЧИНАТЬ  ; 
  ВЫБЕРИТЕ   возраст   ИЗ   пользователей   ГДЕ   id   =   1  ; 
  -- извлекает 20

НАЧИНАТЬ  ; 
  ОБНОВЛЕНИЕ   пользователей   SET   age   =   21   WHERE   id   =   1  ; 
  СОВЕРШИТЬ  ;

ВЫБЕРИТЕ   возраст   ИЗ   пользователей   ГДЕ   id   =   1  ; 
  -- READ UNCOMMITTED извлекает 21 (неповторяемое чтение) 
 -- READ COMMITTED извлекает 21 (неповторяемое чтение) 
 -- REPEATABLE READ извлекает 20 (неповторяемое чтение было исключено) 
 -- SERIALIZABLE извлекает 20 (неповторяемое чтение имеет удалось избежать) 
 COMMIT  ;

Призрак читает [ править ]

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

В этом примере транзакция 1 извлекает набор строк с возрастом больше 17, затем транзакция 2 вставляет строку с возрастом 26 и фиксируется, и, наконец, транзакция 1 снова извлекает набор строк с возрастом больше 17. На уровнях изоляции READ UNCOMMITTED, READ COMMITTED и REPEATABLE READ второй запрос SELECT в транзакции 1 извлекает новый набор строк, включающий вставленную строку: это фантомное чтение. На уровне изоляции SERIALIZABLE второй SELECT в транзакции 1 извлекает исходный набор строк.

Транзакция 1

Транзакция 2

НАЧИНАТЬ  ; 
  ВЫБЕРИТЕ   имя   ИЗ   пользователей   ГДЕ   возраст   >   17  ; 
  -- извлекает Алису и Боба

НАЧИНАТЬ  ; 
  ВСТАВИТЬ   В   пользователей   ЗНАЧЕНИЯ   (  3  ,   'Кэрол'  ,   26  ); 
  СОВЕРШИТЬ  ;

ВЫБЕРИТЕ   имя   ИЗ   пользователей   ГДЕ   возраст   >   17  ; 
  -- READ UNCOMMITTED извлекает Алису, Боба и Кэрол (фантомное чтение) 
 -- READ COMMITTED извлекает Алису, Боба и Кэрол (фантомное чтение) 
 -- REPEATABLE READ извлекает Алису, Боба и Кэрол (фантомное чтение) 
 -- SERIALIZABLE извлекает Алису и Боб ( фантомное чтение удалось избежать) 
 COMMIT  ;

Существует две основные стратегии, используемые для предотвращения неповторяющегося чтения и фантомного чтения. В первой стратегии, управлении параллелизмом на основе блокировок , транзакция 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 неоднозначны, и даже в самых расплывчатых интерпретациях не исключают некоторого аномального поведения… Это приводит к некоторым противоречивым результатам. В частности, уровни изоляции на основе блокировки имеют характеристики, отличные от их эквивалентов ANSI. Это сбивает с толку, поскольку коммерческие системы баз данных обычно используют реализации блокировок. Кроме того, явления ANSI не различают ряд типов поведения уровня изоляции, которые популярны в коммерческих системах. ^[5]

Существуют и другие критические замечания в отношении определения изоляции ANSI SQL, поскольку оно побуждает разработчиков делать «плохие вещи»:

... он тонким образом опирается на предположение, что для управления параллелизмом используется схема блокировки, в отличие от оптимистической или многоверсионной схемы параллелизма. Это означает, что предлагаемая семантика неопределенна . ^[6]

Уровни изоляции и явления чтения [ править ]

Читать феномен Уровень изоляции	Грязное чтение	Неповторяемое чтение	Фантомное чтение
Сериализуемый	нет	нет	нет
Повторяемое чтение	нет	нет	да
Читать зафиксировано	нет	да	да
Читать незафиксированные	да	да	да

Сериализуемая аномалия — это не то же самое, что сериализуемая. То есть необходимо, но недостаточно, чтобы сериализуемый график был свободен от всех трех типов явлений. ^[5]

См. также [ править ]

Ссылки [ править ]

^ «Уровни изоляции в ядре базы данных», TechNet, Microsoft, https://technet.microsoft.com/en-us/library/ms189122(v=SQL.105).aspx
^ Перейти обратно: ^а ^б «Архитектура систем обработки транзакций», глава 23, «Эволюция систем обработки», факультет компьютерных наук, Университет Стоуни-Брук, получено 20 марта 2014 г., http://www.cs.sunysb.edu/~liu/cse315/23. PDF
^ Влад Михалча (20 октября 2015 г.). «Руководство для начинающих по чтению и написанию асимметрических явлений» .
^ «Postgresql вики — SSI» .
^ Перейти обратно: ^а ^б «Критика уровней изоляции SQL ANSI» (PDF) . Проверено 29 июля 2012 г.
^ Продавцы (06 декабря 2010 г.). «Отзывы клиентов (SimpleGeo, CLOUDSTOCK 2010)» . www.DataStax.com: DataStax . Проверено 9 марта 2010 г. (см. выше примерно на 13:30 минуте трансляции!)

Внешние ссылки [ править ]

[1] «Уровни изоляции в ядре базы данных», TechNet, Microsoft, https://technet.microsoft.com/en-us/library/ms189122(v=SQL.105).aspx

[Stony_Brook-2] Перейти обратно: ^а ^б «Архитектура систем обработки транзакций», глава 23, «Эволюция систем обработки», факультет компьютерных наук, Университет Стоуни-Брук, получено 20 марта 2014 г., http://www.cs.sunysb.edu/~liu/cse315/23. PDF

[3] Влад Михалча (20 октября 2015 г.). «Руководство для начинающих по чтению и написанию асимметрических явлений» .

[4] «Postgresql вики — SSI» .

[sql-isolation-5] Перейти обратно: ^а ^б «Критика уровней изоляции SQL ANSI» (PDF) . Проверено 29 июля 2012 г.

[6] Продавцы (06 декабря 2010 г.). «Отзывы клиентов (SimpleGeo, CLOUDSTOCK 2010)» . www.DataStax.com: DataStax . Проверено 9 марта 2010 г. (см. выше примерно на 13:30 минуте трансляции!)

[1]

[2]

[3]

[4]

[5]

[6]