Войти
В базах данных и обработка транзакций (управление транзакциями), моментальный снимок изоляция - это гарантия того, что все чтения, сделанные в транзакции, будут видеть согласованный моментальный снимок базы данных (на практике он считывает последние зафиксированные значения, которые существовали на момент ее запуска), и сама транзакция будет успешно фиксироваться только в том случае, если никакие обновления не конфликтуют с любыми одновременными обновлениями, сделанными после этого снимка.
Изоляция моментальных снимков была принята в нескольких основных системах управления базами данных, таких как InterBase, Firebird, Oracle, MySQL, PostgreSQL, SQL Anywhere, MongoDB и Microsoft SQL Server (2005 и новее). Основная причина его принятия заключается в том, что он обеспечивает лучшую производительность, чем сериализуемость, но все же позволяет избежать большинства аномалий параллелизма, которых избегает сериализуемость (но не всегда всех). На практике изоляция моментальных снимков реализуется в рамках мультиверсионного управления параллелизмом (MVCC), где поддерживаются значения генерации каждого элемента данных (версий): MVCC - это распространенный способ повышения параллелизма и производительности путем создания новой версии объект базы данных каждый раз, когда объект записывается, и позволяет транзакциям выполнять операции чтения нескольких последних соответствующих версий (каждого объекта). Изоляция моментальных снимков использовалась для критики определения уровней изоляции в стандарте 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, чтобы получить некоторый прирост производительности и по-прежнему поддерживать более сильный уровень изоляции «сериализуемости».
Потенциальные проблемы несогласованности, возникающие из-за аномалий перекоса записи, могут быть устранены путем добавления (в противном случае ненужных) обновлений к транзакциям, чтобы обеспечить соблюдение свойства сериализуемости.
В приведенном выше примере мы можем материализовать конфликт путем добавления новой таблицы, которая делает скрытое ограничение явным, сопоставляя каждого человека с их общим балансом. Фил начинал с общего баланса в 200 долларов, и каждая транзакция пыталась вычесть из него 200 долларов, создавая конфликт записи и записи, который не позволял двум одновременно добиться успеха. Однако этот подход нарушает нормальную форму.
. В качестве альтернативы мы можем преобразовать одно из чтений транзакции в запись. Например, T2 может установить V1 = V1, создавая искусственный конфликт записи-записи с T1 и, опять же, предотвращая одновременное выполнение двух операций. Это решение не всегда возможно.
Таким образом, в целом изоляция моментальных снимков ставит некоторые проблемы по поддержанию нетривиальных ограничений на пользователя, который может не осознавать ни потенциальные ловушки, ни возможные решения. Плюс к этому переводу - лучшая производительность.
Изоляция моментальных снимков называется «сериализуемым» режимом в Oracle и PostgreSQL версиях до 9.1, что может вызвать путаницу с «реальным». сериализуемость "режим. Есть аргументы как за, так и против этого решения; ясно то, что пользователи должны знать об этом различии, чтобы избежать возможного нежелательного аномального поведения в логике их системы баз данных.
Изоляция моментальных снимков возникла в результате работы над базами данных с контролем одновременного выполнения нескольких версий, где одновременно поддерживаются несколько версий базы данных, чтобы позволить читателям работать без столкновения с писателями. Такая система допускает естественное определение и реализацию такого уровня изоляции. InterBase, позже принадлежащая Borland, была признана обеспечивающей SI, а не полную сериализуемость в версии 4, и, вероятно, разрешена аномалии записи-перекоса с момента его первого выпуска в 1985 году.
К сожалению, стандарт ANSI SQL-92 был написан с учетом базы данных на основе lock и, следовательно, довольно расплывчато применительно к системам MVCC. Беренсон и др. написал в 1995 году статью, критикуя стандарт SQL, и сослался на изоляцию моментальных снимков в качестве примера уровня изоляции, который не проявлял стандартных аномалий, описанных в стандарте ANSI SQL-92, но все же имел аномальное поведение по сравнению с сериализуемым транзакций.
В 2008 году Cahill et al. показали, что аномалии перекоса записи можно предотвратить, обнаруживая и прерывая «опасные» тройки одновременных транзакций. Эта реализация сериализуемости хорошо подходит для баз данных с управлением многоверсионным параллелизмом и была принята в PostgreSQL 9.1, где она называется «Serializable Snapshot Isolation», сокращенно SSI. При постоянном использовании это устраняет необходимость в вышеупомянутых обходных решениях. Обратной стороной изоляции моментальных снимков является увеличение количества прерванных транзакций. Это может работать лучше или хуже, чем изоляция моментальных снимков с помощью описанных выше обходных путей, в зависимости от рабочей нагрузки.
В 2011 году Хименес-Перис и др. подала патент, в котором было показано, как можно масштабировать до многих миллионов транзакций обновления в секунду с помощью нового метода достижения изоляции моментальных снимков распределенным образом. Этот метод основан на наблюдении, что становится возможным совершать транзакции полностью параллельно без какой-либо координации, что устраняет узкое место традиционных методов обработки транзакций. В этом методе используется секвенсор фиксации, который генерирует временные метки фиксации, и сервер моментальных снимков, который продвигает текущий моментальный снимок вперед по мере заполнения пробелов в порядке сериализации. Этот метод является основой базы данных LeanXcale. Первая реализация этого метода была сделана в 2010 году как часть европейского проекта CumuloNimbo.
