Изоляция моментальных снимков
В базах данных и обработке транзакций (управлении транзакциями) изоляция снимков является гарантией того, что все операции чтения, выполненные в транзакции, будут видеть согласованный снимок базы данных (на практике он считывает последние зафиксированные значения, существовавшие на момент ее запуска), и сама транзакция будет успешно зафиксирована только в том случае, если никакие сделанные ею обновления не конфликтуют с любыми одновременными обновлениями, сделанными после этого моментального снимка.
Изоляция моментальных снимков была принята несколькими основными системами управления базами данных , такими как InterBase , Firebird , Oracle , MySQL , [1] PostgreSQL , SQL Anywhere , MongoDB [2] и Microsoft SQL Server (2005 и более поздние версии). Основная причина его принятия заключается в том, что он обеспечивает более высокую производительность, чем сериализуемость , но при этом позволяет избежать большинства аномалий параллелизма, которых позволяет избежать сериализуемость (но не все). На практике изоляция моментальных снимков реализуется в рамках управления многоверсионным параллелизмом (MVCC), где сохраняются значения поколений каждого элемента данных (версий): MVCC — это распространенный способ повышения параллелизма и производительности путем создания новой версии объекта базы данных каждый раз, когда объект написан и позволяет транзакциям выполнять операции чтения нескольких последних соответствующих версий (каждого объекта). Использовалась изоляция моментальных снимков [3] критиковать в стандарте ANSI SQL определение уровней изоляции -92 , поскольку оно не демонстрирует ни одной из «аномалий», запрещенных стандартом SQL, но при этом не подлежит сериализации (уровень изоляции без аномалий, определенный ANSI).
иногда называется сериализуемой Несмотря на отличие от сериализуемости, изоляция моментальных снимков в Oracle .
Определение
[ редактировать ]Транзакция, выполняющаяся в режиме изоляции моментального снимка, по-видимому, работает с личным моментальным снимком базы данных, сделанным в начале транзакции. Когда транзакция завершится, она будет успешно зафиксирована только в том случае, если значения, обновленные транзакцией, не были изменены извне с момента создания моментального снимка. Такой конфликт записи-записи приведет к прерыванию транзакции.
При аномалии перекоса записи две транзакции (T1 и T2) одновременно считывают перекрывающийся набор данных (например, значения V1 и V2), одновременно выполняют непересекающиеся обновления (например, T1 обновляет V1, T2 обновляет V2) и, наконец, одновременно фиксируют, ни один из них не видит обновление, выполненное другим. Если бы система была сериализуемой, такая аномалия была бы невозможна, поскольку либо T1, либо T2 должны были бы произойти «первыми» и быть видимыми для других. Напротив, изоляция моментальных снимков допускает аномалии перекоса записи.
В качестве конкретного примера представьте, что V1 и V2 — это два баланса, которыми владеет один человек, Фил. Банк позволит либо V1, либо V2 иметь дефицит при условии, что общая сумма, хранящаяся в обоих банках, никогда не будет отрицательной (т. е. V1 + V2 ≥ 0). Оба баланса в настоящее время составляют 100 долларов США. Фил одновременно инициирует две транзакции: T1 снимает 200 долларов США с V1, а T2 снимает 200 долларов США с V2.
Если база данных гарантирует сериализуемые транзакции, самый простой способ закодировать T1 — вычесть 200 долларов из V1, а затем проверить, что V1 + V2 ≥ 0 все еще сохраняется, и в противном случае прервать операцию. T2 аналогичным образом вычитает 200 долларов из V2, а затем проверяет V1 + V2 ≥ 0. Поскольку транзакции должны сериализоваться, либо T1 происходит первым, оставляя V1 = -100 долларов, V2 = 100 долларов и предотвращая успех T2 (поскольку V1 + (V2 - 200 долларов) теперь составляет −$200), или T2 происходит первым и аналогичным образом предотвращает фиксацию T1.
Однако если база данных находится в режиме изоляции моментальных снимков (MVCC), T1 и T2 работают с частными снимками базы данных: каждый вычитает 200 долларов США из учетной записи, а затем проверяет, что новая сумма равна нулю, используя другое значение учетной записи, которое сохранялось, когда снимок был сделан. Поскольку ни одно из обновлений не конфликтует, оба успешно фиксируются, в результате чего V1 = V2 = −$100 и V1 + V2 = −$200.
Некоторые системы, созданные с использованием многоверсионного управления параллелизмом (MVCC), могут поддерживать (только) изоляцию моментальных снимков, чтобы позволить транзакциям продолжаться, не беспокоясь о параллельных операциях, и, что более важно, без необходимости повторной проверки всех операций чтения, когда транзакция окончательно фиксируется. Это удобно, поскольку MVCC поддерживает ряд согласованных состояний недавней истории. Единственная информация, которая должна храниться во время транзакции, — это список сделанных обновлений, который можно довольно легко проверить на наличие конфликтов перед фиксацией. Однако системы MVCC (такие как MarkLogic) будут использовать блокировки для сериализации записей вместе с MVCC, чтобы получить некоторый прирост производительности и при этом поддерживать более сильный уровень изоляции «сериализуемости».
Обходные пути
[ редактировать ]Потенциальные проблемы несогласованности, возникающие из-за аномалий перекоса записи, можно устранить путем добавления (в противном случае ненужных) обновлений к транзакциям, чтобы обеспечить соблюдение свойства сериализуемости . [4] [5] [6] [7]
- Материализуйте конфликт
- Добавьте специальную таблицу конфликтов, которую обе транзакции обновляют, чтобы создать прямой конфликт записи-записи.
- Повышение
- Попросите одну транзакцию «обновить» местоположение, доступное только для чтения (заменив значение тем же значением), чтобы создать прямой конфликт записи-записи (или использовать эквивалентное продвижение, например Oracle SELECT FOR UPDATE).
В приведенном выше примере мы можем материализовать конфликт, добавив новую таблицу, которая делает скрытое ограничение явным, сопоставляя каждого человека с его общим балансом . Фил начинал с общего баланса в 200 долларов, и каждая транзакция пыталась вычесть из него 200 долларов, создавая конфликт записи и записи, который не позволял им добиться успеха одновременно. Однако такой подход нарушает нормальную форму .
В качестве альтернативы мы можем преобразовать чтение одной из транзакций в запись. Например, T2 может установить V1 = V1, создавая искусственный конфликт записи-записи с T1 и, опять же, препятствуя одновременному успеху этих двух операций. Такое решение не всегда возможно.
Таким образом, в целом изоляция моментальных снимков возлагает некоторые проблемы поддержания нетривиальных ограничений на пользователя, который может не осознавать ни потенциальных ловушек, ни возможных решений. Плюсом этого трансфера является повышение производительности.
Терминология
[ редактировать ]называется «сериализуемым» режимом. Изоляция моментальных снимков в Oracle [8] [9] [10] и версии PostgreSQL до 9.1, [11] [12] [13] что может вызвать путаницу с режимом «реальной сериализуемости ». Есть аргументы как за, так и против этого решения; ясно одно: пользователи должны знать об этом различии, чтобы избежать возможного нежелательного аномального поведения в логике системы базы данных.
История
[ редактировать ]Изоляция моментальных снимков возникла в результате работы над базами данных управления многоверсионным параллелизмом , где несколько версий базы данных поддерживаются одновременно, чтобы позволить читателям выполняться без конфликтов с записывающими устройствами. Такая система позволяет естественным образом определить и реализовать такой уровень изоляции. [3] Было признано, что InterBase , позже принадлежавшая Borland , в версии 4 обеспечивала SI, а не полную сериализуемость. [3] и, вероятно, допускал аномалии перекоса записи с момента его первого выпуска в 1985 году. [14]
К сожалению, стандарт ANSI SQL-92 был написан с учетом баз данных на основе блокировок , и поэтому он довольно расплывчат при применении к системам MVCC. Беренсон и др. написал статью в 1995 году [3] критикуя стандарт SQL и приводя изоляцию моментальных снимков в качестве примера уровня изоляции, который не проявлял стандартных аномалий, описанных в стандарте ANSI SQL-92, но все же имел аномальное поведение по сравнению с сериализуемыми транзакциями.
В 2008 году Кэхилл и др. показали, что аномалии перекоса записи можно предотвратить, обнаруживая и прерывая «опасные» тройки одновременных транзакций. [15] Такая реализация сериализуемости хорошо подходит для баз данных с многоверсионным параллелизмом и была принята в PostgreSQL 9.1. [12] [13] [16] где это известно как изоляция сериализуемых моментальных снимков (SSI). При последовательном использовании это устраняет необходимость в вышеуказанных обходных путях. Обратной стороной изоляции моментальных снимков является увеличение количества прерванных транзакций. Это может работать лучше или хуже, чем изоляция моментальных снимков с помощью описанных выше обходных путей, в зависимости от рабочей нагрузки.
Ссылки
[ редактировать ]- ^ «MySQL :: Справочное руководство MySQL 8.0 :: 15.5.2.3 Согласованное неблокирующее чтение» . dev.mysql.com . Проверено 27 августа 2018 г.
- ^ Управление многоверсионным параллелизмом в MongoDB, технический директор MongoDB: как наш новый механизм хранения WiredTiger заслужит свою популярность
- ^ Перейти обратно: а б с д Беренсон, Хэл; Бернштейн, Фил; Грей, Джим; Мелтон, Джим; О'Нил, Элизабет ; О'Нил, Патрик (1995), «Критика уровней изоляции ANSI SQL», Труды международной конференции ACM SIGMOD 1995 года по управлению данными , стр. 1–10, arXiv : cs/0701157 , doi : 10.1145/223784.223785 , ISBN 978-0897917315 , S2CID 2316540
- ^ Фекете, Алан; Лиарокапис, Димитриос; О'Нил, Элизабет ; О'Нил, Патрик ; Шаша, Деннис (2005), «Сериализация изоляции моментальных снимков», Транзакции ACM в системах баз данных , 30 (2): 492–528, CiteSeerX 10.1.1.503.3169 , doi : 10.1145/1071610.1071615 , ISSN 0362-5915 , S2CID 18 15415
- ^ Майкл Дж. Кэхилл, Уве Рем, Алан Д. Фекете (2008): «Сериализуемая изоляция для баз данных моментальных снимков» , Труды международной конференции ACM SIGMOD 2008 г. по управлению данными , стр. 729-738, Ванкувер, Канада, июнь 2008 г. , ISBN 978-1-60558-102-6 (награда SIGMOD за лучшую бумагу 2008 г.)
- ^ Майкл Дж. Кэхилл, Уве Рем, Алан Д. Фекете (2008): «Сериализуемая изоляция для баз данных моментальных снимков» , Труды международной конференции ACM SIGMOD 2008 г. по управлению данными , стр. 729-738, Ванкувер, Канада, июнь 2008 г. , ISBN 978-1-60558-102-6 (награда SIGMOD за лучшую бумагу 2008 г.)
- ^ Алан Фекете (2009), «Изоляция моментальных снимков и сериализуемое выполнение» , презентация, страница 4, 2009, Сиднейский университет (Австралия). Проверено 16 сентября 2009 г.
- ^ Концепции базы данных Oracle 10g, выпуск 1 (10.1) Глава 13: Параллелизм и согласованность данных — уровни изоляции Oracle
- ^ Спросите Тома: об уровнях изоляции транзакций
- ^ Спросите Тома: «Сериализуемая транзакция»
- ^ Документация PostgreSQL 9.0: 13.2.2.1. Сериализуемая изоляция против истинной сериализуемости
- ^ Перейти обратно: а б Пресс-релиз PostgreSQL 9.1
- ^ Перейти обратно: а б Документация PostgreSQL 9.1.14: 13.2.3. Сериализуемый уровень изоляции
- ^ Станц, Крейг. «Управление многоверсионным параллелизмом до InterBase» . Архивировано из оригинала 23 октября 2007 года . Проверено 30 октября 2014 г.
- ^ Майкл Дж. Кэхилл, Уве Рём, Алан Д. Фекете (2008) «Сериализуемая изоляция для баз данных моментальных снимков» , Материалы международной конференции ACM SIGMOD 2008 года по управлению данными , стр. 729–738, ISBN 978-1-60558-102-6 (награда SIGMOD за лучшую бумагу 2008 г.)
- ^ Портс, Дэн Р.К.; Гриттнер, Кевин (2012). «Изоляция сериализуемых снимков в PostgreSQL» (PDF) . Труды Фонда VLDB . 5 (12): 1850–1861. arXiv : 1208.4179 . CiteSeerX 10.1.1.294.3803 . дои : 10.14778/2367502.2367523 . S2CID 16006111 .
Дальнейшее чтение
[ редактировать ]- Беттина Кемме, Густаво Алонсо, Новый подход к разработке и реализации активных протоколов репликации баз данных , Транзакции ACM в системах баз данных (TODS), v.25 n.3, стр. 333-379, сентябрь 2000 г.
- Герхард Вейкум, Готфрид Воссен, Транзакционные информационные системы: теория, алгоритмы и практика параллельного управления и восстановления , Морган Кауфманн, 2002 г., ISBN 1-55860-508-8
- Йи Линь, Беттина Кемме, Марта Патиньо-Мартинес, Рикардо Хименес-Перис. Репликация данных на основе промежуточного программного обеспечения, обеспечивающая изоляцию моментальных снимков . Материалы международной конференции ACM SIGMOD 2005 г., 2005 г.
- Марта Патиньо-Мартинес, Рикардо Хименес-Перис, Беттина Кемме, Густаво Алонсо. MIDDLE-R: Согласованная репликация базы данных на уровне промежуточного программного обеспечения . Транзакции ACM в компьютерных системах (TOCS). Том 23 Выпуск 4. Страницы 375-423.
- Хузаима Дауджи, Кеннет Салем, Ленивая репликация базы данных с изоляцией моментальных снимков , VLDB 2006: страницы 715–726.