В базах данных и обработке транзакций (управлении транзакциями) изоляция моментальных снимков является гарантией того, что все операции чтения, выполненные в транзакции, будут видеть согласованный снимок базы данных (на практике он считывает последние зафиксированные значения, существовавшие на момент ее запуска), и сама транзакция будет успешно зафиксирована только в том случае, если никакие сделанные ею обновления не конфликтуют с любыми одновременными обновлениями, сделанными после этого моментального снимка.
Изоляция моментальных снимков была принята несколькими основными системами управления базами данных , такими как 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]
В приведенном выше примере мы можем материализовать конфликт, добавив новую таблицу, которая делает скрытое ограничение явным, сопоставляя каждого человека с его общим балансом . Фил начинал с общего баланса в 200 долларов, и каждая транзакция пыталась вычесть из него 200 долларов, создавая конфликт записи и записи, который не позволял им добиться успеха одновременно. Однако такой подход нарушает нормальную форму .
В качестве альтернативы мы можем преобразовать чтение одной из транзакций в запись. Например, T2 может установить V1 = V1, создавая искусственный конфликт записи-записи с T1 и, опять же, препятствуя одновременному успеху этих двух операций. Такое решение не всегда возможно.
Таким образом, в целом изоляция моментальных снимков возлагает некоторые проблемы поддержания нетривиальных ограничений на пользователя, который может не осознавать ни потенциальных ловушек, ни возможных решений. Плюсом этого трансфера является повышение производительности.
Изоляция моментальных снимков называется «сериализуемым» режимом в Oracle [8] [9] [10] и версиях PostgreSQL до 9.1, [11] [12] [13] , что может привести к путанице с режимом «реальной сериализуемости ». Есть аргументы как за, так и против этого решения; ясно одно: пользователи должны знать об этом различии, чтобы избежать возможного нежелательного аномального поведения в логике системы базы данных.
Изоляция моментальных снимков возникла в результате работы над базами данных с многоверсионным управлением параллелизмом , где несколько версий базы данных поддерживаются одновременно, чтобы позволить читателям выполняться без конфликтов с записывающими устройствами. Такая система позволяет естественным образом определить и реализовать такой уровень изоляции. [3] InterBase , позже принадлежавшая Borland , была признана обеспечивающей SI, а не полную сериализуемость в версии 4, [3] и, вероятно, допускала аномалии перекоса записи с момента ее первого выпуска в 1985 году. [14]
К сожалению, стандарт ANSI SQL-92 был написан с учетом баз данных на основе блокировок , и поэтому он довольно расплывчат при применении к системам MVCC. Беренсон и др. написал в 1995 году статью [3] с критикой стандарта SQL и привел изоляцию моментальных снимков в качестве примера уровня изоляции, который не проявлял стандартных аномалий, описанных в стандарте ANSI SQL-92, но все же имел аномальное поведение по сравнению с сериализуемыми транзакциями . .
В 2008 году Кэхилл и др. показали, что аномалии перекоса записи можно предотвратить путем обнаружения и прерывания «опасных» троек параллельных транзакций. [15] Эта реализация сериализуемости хорошо подходит для баз данных с многоверсионным параллелизмом и была принята в PostgreSQL 9.1, [12] [13] [16] , где она известна как сериализуемая изоляция моментальных снимков (SSI). При последовательном использовании это устраняет необходимость в вышеуказанных обходных путях. Обратной стороной изоляции моментальных снимков является увеличение количества прерванных транзакций. Это может работать лучше или хуже, чем изоляция моментальных снимков с помощью описанных выше обходных решений, в зависимости от рабочей нагрузки.