В базах данных и обработке транзакций (управлении транзакциями) изоляция моментальных снимков гарантирует, что все чтения, выполненные в транзакции, будут видеть согласованный моментальный снимок базы данных (на практике считываются последние зафиксированные значения, существовавшие на момент ее запуска), а сама транзакция будет успешно зафиксирована только в том случае, если никакие выполненные ею обновления не конфликтуют с какими-либо параллельными обновлениями, выполненными с момента этого моментального снимка.
Изоляция моментальных снимков была принята несколькими основными системами управления базами данных , такими как 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 и, опять же, не дав им обоим успешно завершиться одновременно. Это решение не всегда возможно.
В общем, поэтому изоляция моментального снимка перекладывает часть проблем поддержания нетривиальных ограничений на пользователя, который может не оценить ни потенциальных ловушек, ни возможных решений. Преимущество этой передачи заключается в лучшей производительности.
Изоляция моментального снимка называется режимом "serializable" в Oracle [8] [9] [10] и PostgreSQL до версий 9.1, [11] [12] [13] , что может привести к путанице с режимом "real serializability ". Существуют аргументы как за, так и против этого решения; ясно одно: пользователи должны знать об этом различии, чтобы избежать возможного нежелательного аномального поведения в логике своей системы базы данных.
Изоляция моментального снимка возникла из работы над многоверсионными базами данных с параллельным управлением , где несколько версий базы данных поддерживаются одновременно, чтобы позволить читателям выполняться без столкновений с писателями. Такая система допускает естественное определение и реализацию такого уровня изоляции. [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). При последовательном использовании это устраняет необходимость в вышеуказанных обходных путях. Недостатком изоляции моментальных снимков является увеличение количества прерванных транзакций. Это может работать лучше или хуже, чем изоляция моментальных снимков с вышеуказанными обходными путями, в зависимости от рабочей нагрузки.