В базах данных и обработке транзакций (управление транзакциями) изоляция моментальных снимков является гарантией того, что все чтения, сделанные в транзакции, будут видеть согласованный моментальный снимок базы данных (на практике он считывает последние зафиксированные значения, которые существовали на момент ее запуска), и сама транзакция будет успешно зафиксирована только в том случае, если никакие обновления не конфликтуют с какими-либо одновременными обновлениями, сделанными после этого снимка.
Изоляция моментальных снимков была принята в нескольких основных системах управления базами данных , таких как 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]
- Материализовать конфликт
- Добавьте специальную таблицу конфликтов, которую обе транзакции обновляют, чтобы создать прямой конфликт записи-записи.
- Продвижение
- Попросите одну транзакцию «обновить» доступное только для чтения местоположение (заменив значение тем же значением), чтобы создать прямой конфликт записи-записи (или используйте эквивалентное продвижение, например, Oracle SELECT FOR UPDATE).
В приведенном выше примере мы можем материализовать конфликт, добавив новую таблицу, которая делает скрытое ограничение явным, сопоставляя каждого человека с их общим балансом . Фил начинал с общего баланса в 200 долларов, и каждая транзакция пыталась вычесть из него 200 долларов, создавая конфликт записи-записи, который не позволял бы выполнить обе операции одновременно. Однако такой подход нарушает нормальную форму .
В качестве альтернативы мы можем повысить одно из операций чтения транзакции до записи. Например, T2 может установить V1 = V1, создавая искусственный конфликт записи-записи с T1 и, опять же, предотвращая одновременное выполнение двух операций. Это решение не всегда возможно.
Таким образом, в общем случае изоляция моментальных снимков накладывает некоторые проблемы с поддержанием нетривиальных ограничений на пользователя, который может не осознавать ни потенциальных ловушек, ни возможных решений. Плюс к этому переводу - лучшая производительность.
Терминология
Изоляция моментальных снимков называется «сериализуемым» режимом в версиях Oracle [5] [6] [7] и PostgreSQL до 9.1, [8] [9] [10], что может вызвать путаницу с режимом «реальной сериализуемости ». Есть аргументы как за, так и против этого решения; ясно то, что пользователи должны знать об этом различии, чтобы избежать возможного нежелательного аномального поведения в логике их системы баз данных.
История
Изоляция моментальных снимков возникла в результате работы над многоверсионными базами данных управления параллелизмом , где одновременно поддерживается несколько версий базы данных, что позволяет читателям работать без столкновения с писателями. Такая система позволяет естественным образом определить и реализовать такой уровень изоляции. [3] InterBase , позже принадлежащая Borland , была признана обеспечивающей SI, а не полную сериализуемость в версии 4, [3] и, вероятно, допускала аномалии перекоса записи с момента ее первого выпуска в 1985 году [11].
К сожалению, стандарт ANSI SQL-92 был написан с учетом базы данных на основе блокировок и, следовательно, довольно расплывчат в применении к системам MVCC. Беренсон и др. написал статью в 1995 г. [3], критикуя стандарт SQL, и привел изоляцию моментальных снимков в качестве примера уровня изоляции, который не проявлял стандартных аномалий, описанных в стандарте ANSI SQL-92, но все же имел аномальное поведение по сравнению с сериализуемыми транзакциями. .
В 2008 году Кэхилл и др. показали, что аномалии перекоса записи можно предотвратить, обнаруживая и прерывая «опасные» тройки одновременных транзакций. [12] Эта реализация сериализуемости хорошо подходит для мультиверсионных баз данных управления параллелизмом и была принята в PostgreSQL 9.1, [9] [10] [13], где она называется «Serializable Snapshot Isolation», сокращенно SSI. При постоянном использовании это устраняет необходимость в вышеупомянутых обходных решениях. Обратной стороной изоляции моментальных снимков является увеличение количества прерванных транзакций. Это может работать лучше или хуже, чем изоляция моментальных снимков с помощью описанных выше обходных путей, в зависимости от рабочей нагрузки.
В 2011 году Хименес-Перис и др. подала патент [14], где было показано, как можно масштабировать до многих миллионов транзакций обновления в секунду с помощью нового метода достижения изоляции моментальных снимков распределенным образом. Этот метод основан на наблюдении, что становится возможным совершать транзакции полностью параллельно без какой-либо координации и, следовательно, устраняя узкое место традиционных методов обработки транзакций. В этом методе используется секвенсор фиксации, который генерирует временные метки фиксации, и сервер моментальных снимков, который продвигает текущий моментальный снимок вперед по мере заполнения пробелов в порядке сериализации. Этот метод является основой базы данных LeanXcale. [15] Впервые этот метод был реализован в 2010 году в рамках европейского проекта CumuloNimbo. [16]
Рекомендации
- ^ "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
- ^ Фекете, Алан; Лиарокапис, Димитриос; О'Нил, Элизабет ; О'Нил, Патрик ; Шаша, Деннис (2005), "Создание Snapshot Isolation Сериализуемый", ACM Сделки по системам баз данных , 30 (2): 492-528, CiteSeerX 10.1.1.503.3169 , DOI : 10,1145 / 1071610,1071615 , ISSN 0362-5915
- ^ Oracle Database Concepts 10g Release 1 (10.1) Глава 13: Параллелизм и согласованность данных - уровни изоляции Oracle
- ^ Спросите Тома: об уровнях изоляции транзакций
- ^ Спросите Тома: "Сериализуемая транзакция"
- ^ Документация по PostgreSQL 9.0: 13.2.2.1. Сериализуемая изоляция против истинной сериализуемости
- ^ a b Пресс-релиз PostgreSQL 9.1
- ^ a b PostgreSQL 9.1.14 Документация: 13.2.3. Сериализуемый уровень изоляции
- ^ Stuntz, Крейг. «Управление многоверсионным параллелизмом до InterBase» . Проверено 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 . DOI : 10.14778 / 2367502.2367523 .
- ^ [1] , ХИМЕНЕС-ПЕРИС, Рикардо и Марта ПАТИНЬО-МАРТИНЕС, «Система и метод для высокомасштабируемой децентрализованной обработки транзакций с низким уровнем конкуренции»
- ^ «LeanXcale» . Leanxcale.com . Проверено 20 августа 2017 .
- ^ Хименес-Перис, Рикардо; Патиньо-Мартинес, Марта; Магутис, Костас; Билас, Ангелос; Брондино, Иван (апрель 2012). «CumuloNimbo: масштабируемая платформа обработки транзакций как услуга» . Ercim News .
дальнейшее чтение
- Беттина Кемме, Густаво Алонсо, Новый подход к разработке и внедрению протоколов активной репликации баз данных , Транзакции ACM в системах баз данных (TODS), v.25 n.3, p. 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