Сериализуемость - Википедия - Serializability

Эта статья посвящена сериализуемости транзакций базы данных. Для сериализации объектов в объектно-ориентированных языках см. сериализация.

В контроль параллелизма из базы данных,[1][2] обработка транзакции (управление транзакциями) и различные транзакционный приложения (например, транзакционная память[3] и программная транзакционная память ), как централизованные, так и распределен, сделка график является сериализуемый если его результат (например, результирующее состояние базы данных) равен результату его транзакций, выполняемых последовательно, то есть без перекрытия во времени. Транзакции обычно выполняются одновременно (они перекрываются), поскольку это наиболее эффективный способ. Сериализуемость - главный критерий корректности одновременного выполнения транзакций.[нужна цитата ]. Считается высшим уровнем изоляция между сделки, и играет важную роль в контроль параллелизма. Таким образом, он поддерживается во всех системах баз данных общего назначения. Сильная строгая двухфазная блокировка (SS2PL) - популярный механизм сериализуемости, используемый в большинстве систем баз данных (в различных вариантах) с момента их появления в 1970-х годах.

Теория сериализуемости предоставляет формальную основу для анализа и анализа сериализуемости и ее методов. Хотя это математический в природе, его основы неформально (без математических обозначений) вводятся ниже.

Правильность

Сериализуемость

Сериализуемость используется для сохранения данных в элементе данных в согласованном состоянии. Сериализуемость - это свойство транзакции график (история). Это относится к изоляция собственность транзакция базы данных.

Сериализуемость расписания означает эквивалентность (в результате, состоянии базы данных, значениях данных) расписание серий (т.е.последовательно без перекрытия транзакций во времени) с одними и теми же транзакциями. Это главный критерий правильности расписания параллельных транзакций, поэтому он поддерживается во всех системах баз данных общего назначения.[нужна цитата ]
Обоснование сериализуемости следующее:
Если каждая транзакция правильна сама по себе, т. Е. Соответствует определенным условиям целостности, то расписание, включающее любые серийный выполнение этих транзакций правильное (транзакции по-прежнему соответствуют их условиям): "Последовательный" означает, что транзакции не перекрываются во времени и не могут мешать друг другу, т.е. изоляция между собой существует. Любой порядок транзакций является законным, если между ними нет зависимостей, что предполагается (см. Комментарий ниже). В результате расписание, которое включает любое выполнение (не обязательно последовательное), эквивалентное (по своему результату) любому последовательному выполнению этих транзакций, является правильным.

Расписания, которые нельзя сериализовать, могут привести к ошибочным результатам. Хорошо известные примеры - транзакции, которые дебетуют и кредитуют счета деньгами: если связанные расписания не сериализуемы, то общая сумма денег может не сохраниться. Деньги могут исчезнуть или появиться из ниоткуда. Это и нарушения возможно необходимых других инвариантный Сохранение вызывается записью одной транзакции, а также "наступлением" и стиранием того, что было записано другой транзакцией, прежде чем это станет постоянным в базе данных. Этого не происходит, если сохраняется сериализуемость.

Если какой-либо конкретный порядок между некоторыми транзакциями запрашивается приложением, то он применяется независимо от базовых механизмов сериализуемости. Эти механизмы обычно безразличны к какому-либо конкретному порядку и порождают некоторые непредсказуемые частичный заказ это обычно совместимо с несколькими последовательными заказами этих транзакций. Этот частичный порядок является следствием порядка планирования операций доступа к данным параллельных транзакций, которые зависят от многих факторов.

Основная характеристика транзакции базы данных: атомарность, что означает, что либо совершает, т.е. результаты всех его операций вступают в силу в базе данных, или прерывание (откат), результаты всех его операций не влияют на базу данных (семантика транзакции «все или ничего»). Во всех реальных системах транзакции могут прерваться по многим причинам, и сама по себе сериализуемость недостаточна для корректности. Расписания также должны обладать восстанавливаемость (от прерывания) свойство. Восстанавливаемость означает, что подтвержденные транзакции не читали данные, записанные прерванными транзакциями (чьи эффекты не существуют в результирующих состояниях базы данных). В то время как сериализуемость в настоящее время намеренно скомпрометирована во многих приложениях для повышения производительности (только в тех случаях, когда корректность приложения не нарушается), нарушение восстанавливаемости быстро нарушит целостность базы данных, а также результаты транзакций, внешних по отношению к базе данных. Расписание со свойством восстанавливаемости (a восстанавливаемый schedule) "восстанавливается" после прерывания самостоятельно, то есть прерывания не нарушают целостность зафиксированных транзакций и результирующей базы данных. Это неверно без возможности восстановления, когда вероятные нарушения целостности (приводящие к неверным данным базы данных) требуют специальных, обычно ручных корректирующих действий в базе данных.

Реализация восстанавливаемости в ее общей форме может привести к каскадные прерывания: Прерывание одной транзакции может привести к необходимости прервать вторую транзакцию, затем третью и т. Д. Это приводит к потере уже частично выполненных транзакций и может также привести к снижению производительности. Как избежать каскадных прерываний (ACA, или безкаскадность) - это особый случай восстанавливаемости, который точно предотвращает такие явления. Часто на практике используется особый случай ACA: Строгость. Строгость позволяет эффективно восстанавливать базу данных после сбоя.

Обратите внимание, что восстанавливаемость свойство необходимо, даже если не происходит сбоя базы данных и нет базы данных восстановление от неудач нужен. Скорее, это необходимо для правильной автоматической обработки прерываний, которые могут быть не связаны с отказом базы данных и восстановлением после сбоя.

Расслабляющая сериализуемость

Во многих приложениях, в отличие от финансов, абсолютная корректность не нужна. Например, при получении списка продуктов в соответствии со спецификацией в большинстве случаев не имеет большого значения, если продукт, данные которого были обновлены недавно, не отображается в списке, даже если он соответствует спецификации. Обычно он появляется в таком списке при повторной попытке через некоторое время. Коммерческие базы данных обеспечивают контроль параллелизма с целым рядом уровни изоляции которые на самом деле являются (управляемыми) нарушениями сериализуемости для достижения более высокой производительности. Более высокая производительность означает лучшую скорость выполнения транзакций и меньшее среднее время отклика транзакции (продолжительность транзакции). Изоляция снимков является примером популярного, широко используемого эффективного метода расслабленной сериализуемости со многими характеристиками полной сериализуемости, но по-прежнему не хватает некоторых и непригоден во многих ситуациях.

Еще одна распространенная причина в наши дни распределенная сериализуемость релаксация (см. ниже) является требованием доступность из Интернет продукты и Сервисы. На это требование обычно отвечают крупномасштабные данные. репликация. Простое решение для синхронизации обновлений реплик одного и того же объекта базы данных - это включение всех этих обновлений в один атомарный распределенная транзакция. Однако для многих реплик такая транзакция очень велика и может охватывать достаточно нескольких реплик. компьютеры и сети что некоторые из них, вероятно, будут недоступны. Таким образом, такая транзакция, скорее всего, завершится прерыванием и не достигнет своей цели.[4]Как следствие, Оптимистичная репликация (Ленивая репликация) часто используется (например, во многих продуктах и ​​услугах Google, Amazon, Yahoo и т.п.), в то время как сериализуемость ослаблена и скомпрометирована для возможная последовательность. Опять же, в этом случае релаксация выполняется только для приложений, которые, как ожидается, не пострадают от этой техники.

Классы расписаний, определенные ослабленная сериализуемость свойства либо содержат класс сериализуемости, либо несовместимы с ним.

Просмотр и сериализуемость конфликтов

Механизмы, обеспечивающие сериализуемость, должны выполняться в реальное время, или почти в реальном времени, когда транзакции выполняются с высокой скоростью. Чтобы удовлетворить это требование, используются особые случаи сериализуемости, достаточные условия сериализуемости, которые могут быть эффективно реализованы.

Существуют два основных типа сериализуемости: возможность сериализации представлений, и конфликт-сериализуемость. Сериализуемость представления соответствует общему определению сериализуемости, данному выше. Сериализуемость конфликтов - это широкий частный случай, то есть любое расписание, которое сериализуемо конфликтами, также может сериализоваться по просмотру, но не обязательно наоборот. Конфликт-сериализуемость широко используется, потому что ее легче определить и она охватывает значительную часть сериализуемых представлений расписаний. Определение возможности сериализации представлений расписания - это НП-полный проблема (класс задач, для которых известны только трудные для вычисления и требующие слишком много времени решения).

Сериализуемость представлений расписания определяется эквивалентностью последовательного расписания (без перекрывающихся транзакций) с одними и теми же транзакциями, так что соответствующие транзакции в двух расписаниях читают и записывают одни и те же значения данных («просматривают» одни и те же значения данных).
Конфликт-сериализуемость определяется эквивалентностью последовательного расписания (без перекрывающихся транзакций) с одними и теми же транзакциями, так что оба расписания имеют одинаковые наборы соответствующих хронологически упорядоченных пар конфликтующих операций (одинаковые отношения приоритета соответствующих конфликтующих операций).

Операции над данными читать или же записывать (написать: либо вставлять или же модифицировать или же Удалить). Две операции противоречивый если они относятся к разным транзакциям, к одному и тому же элементу данных (элемент данных), и хотя бы одна из них является записывать. Каждая такая пара конфликтующих операций имеет тип конфликта: это либо читай пиши, или же писать – читать, или написать – написать конфликт. Транзакция второй операции в паре называется в конфликте при сделке первой операции. Более общее определение конфликтующих операций (также для сложных операций, каждая из которых может состоять из нескольких «простых» операций чтения / записи) требует, чтобы они были некоммутативный (изменение их порядка также изменяет их общий результат). Каждая такая операция должна быть атомарной сама по себе (с использованием надлежащей системной поддержки), чтобы считаться операцией для проверки коммутативности. Например, операции чтения-чтения являются коммутативными (в отличие от чтения-записи и других возможностей), и поэтому чтение-чтение не является конфликтом. Другой более сложный пример: операции приращение и декремент из прилавок оба записывать операции (оба изменяют счетчик), но не должны считаться конфликтующими (тип конфликта записи-записи), поскольку они коммутативны (таким образом, приращение – декремент не является конфликтом; например, уже поддерживалось в старом IMS IBM "быстрый путь" ). Только приоритет (временной порядок) в парах конфликтующих (некоммутативных) операций важен при проверке эквивалентности последовательному расписанию, поскольку разные расписания, состоящие из одних и тех же транзакций, могут быть преобразованы из одного в другой, изменяя порядок между операциями разных транзакций ( чередование различных транзакций), и поскольку изменение порядка коммутативных операций (неконфликтных) не меняет общий результат последовательности операций, то есть результат расписания (результат сохраняется за счет изменения порядка между неконфликтными операциями, но обычно не когда порядок изменения конфликтующих операций). Это означает, что если расписание может быть преобразовано в любое последовательное расписание без изменения порядков конфликтующих операций (но с изменением порядков неконфликтных операций с сохранением порядка операций внутри каждой транзакции), то результат обоих расписаний будет одинаковым, и расписание по определению сериализуемо конфликтно.

Конфликты являются причиной блокировки транзакций и задержек (нематериализованные конфликты) или отмены транзакций из-за предотвращения нарушения сериализуемости. Обе возможности снижают производительность. Таким образом, уменьшение количества конфликтов, например, за счет коммутативности (когда это возможно), является способом повышения производительности.

Транзакция может вызвать / запросить конфликтующую операцию и быть в конфликте с другой транзакцией, в то время как ее конфликтующая операция задерживается и не выполняется (например, заблокирована замок ). Только выполнено (материализованный) конфликтующие операции относятся к сериализуемость конфликта (подробнее см. ниже).

Обеспечение сериализуемости конфликтов

Тестирование сериализуемости конфликтов

Соответствие расписанию с сериализуемостью конфликтов можно проверить с помощью граф приоритета (граф сериализуемости, граф сериализации, граф конфликтов) для совершенных транзакций расписания. Это ориентированный граф представляет приоритет транзакций в расписании, что отражается в приоритете конфликтующих операций в транзакциях.

в граф приоритета транзакции - это узлы, а отношения предшествования - это направленные ребра. Существует переход от первой транзакции ко второй транзакции, если вторая транзакция в конфликте с первым (см. Сериализуемость конфликтов выше), а конфликт материализованный (т.е. если запрошенная конфликтующая операция действительно выполняется: во многих случаях запрошенная / выданная конфликтующая операция транзакцией задерживается и даже никогда не выполняется, обычно замок на объекте операции, удерживаемом другой транзакцией, или при записи во временную частную рабочую область транзакции и материализации, копировании в саму базу данных при фиксации; до тех пор, пока запрашиваемая / выданная конфликтующая операция не выполняется в самой базе данных, конфликт нематериализованный; нематериализованные конфликты не представлены ребром в графе приоритета).
Комментарий: Только во многих учебниках совершенные транзакции включены в граф приоритета. Здесь все транзакции включены для удобства в последующих обсуждениях.

Следующее наблюдение является ключевая характеристика сериализуемости конфликта:

График конфликт-сериализуемый если и только если его граф приоритета совершенные транзакции (когда только преданный идее сделки считаются) ациклический. Это означает, что цикл, состоящий только из зафиксированных транзакций, генерируется в (общем) графе приоритета тогда и только тогда, когда нарушается конфликт-сериализуемость.

Циклы зафиксированных транзакций можно предотвратить, прервав нерешительный транзакция (ни зафиксированная, ни прерванная) в каждом цикле в графе приоритета всех транзакций, которые в противном случае могут превратиться в цикл зафиксированных транзакций (и зафиксированная транзакция не может быть прервана). Одна транзакция, прерванная за цикл, и требуется, и ее достаточно, чтобы прервать и исключить цикл (возможны и другие прерывания, которые могут произойти при некоторых механизмах, но не требуются для сериализуемости). Вероятность генерации цикла обычно невелика, но, тем не менее, такая ситуация тщательно обрабатывается, как правило, со значительными накладными расходами, поскольку требуется правильность. Транзакции, прерванные из-за предотвращения нарушения сериализуемости: перезапущен и немедленно выполнен снова.

Механизмы обеспечения сериализуемости обычно не поддерживают граф приоритета как структуру данных, а скорее неявно предотвращают или прерывают циклы (например, SS2PL ниже).

Общий механизм - SS2PL

Основная статья: Двухфазная блокировка

Сильная строгая двухфазная блокировка (SS2PL) - распространенный механизм, используемый в системах баз данных с момента их появления в 1970-х годах (хотя «SS» в имени SS2PL новее) для обеспечения как сериализуемости конфликтов, так и строгость (особый случай возможности восстановления, который позволяет эффективно восстанавливать базу данных после сбоя) расписания. Согласно этому механизму, каждая база данных блокируется транзакцией до того, как она получит к ней доступ (в любой операции чтения или записи): элемент помечается и ассоциируется с замок определенного типа в зависимости от выполняемой операции (и конкретной реализации транзакции; существуют различные модели с разными типами блокировки; в некоторых моделях блокировки могут изменять тип в течение жизни транзакции). В результате доступ другой транзакции может быть заблокирован, как правило, при конфликте (блокировка задерживает или полностью предотвращает материализацию конфликта и отражается в графе приоритета путем блокировки конфликтующей операции), в зависимости от типа блокировки и другой транзакции. тип операции доступа. Использование механизма SS2PL означает, что все блокировки данных от имени транзакции снимаются только после того, как транзакция завершилась (зафиксирована или прервана).

SS2PL - это также имя результирующего свойства расписания, которое также называется строгость. SS2PL - это особый случай (правильное подмножество ) из Двухфазная блокировка (2PL)

Взаимная блокировка транзакций приводит к тупик, где выполнение этих транзакций останавливается и не может быть достигнуто до завершения. Таким образом, необходимо разрешить тупиковые ситуации, чтобы завершить выполнение этих транзакций и освободить связанные вычислительные ресурсы. Тупиковая ситуация - это отражение потенциального цикла в графе приоритета, который произошел бы без блокировки при материализации конфликтов. Тупиковая ситуация разрешается путем прерывания транзакции, связанной с таким потенциальным циклом, и разрыва цикла. Это часто обнаруживается с помощью график ожидания (граф конфликтов, заблокированных блокировками от материализации; его также можно определить как граф нематериализованных конфликтов; не материализованные конфликты не отражаются в графе приоритета и не влияют на сериализуемость), который указывает, какая транзакция «ожидает» для "снятия одной или нескольких блокировок, посредством которых другая транзакция или транзакции, и цикл в этом графе означает тупик. Прервать одну транзакцию за цикл достаточно, чтобы разорвать цикл. Транзакции, прерванные из-за разрешения тупиковой ситуации, перезапущен и немедленно выполнен снова.

Другие методы принуждения

Другие известные механизмы включают:

Вышеупомянутые (конфликтующие) методы сериализуемости в их общей форме не обеспечивают возможности восстановления. Для повышения восстанавливаемости необходимы специальные улучшения.

Оптимистические и пессимистические методы

Техники управления параллелизмом бывают трех основных типов:

  1. Пессимистичный: В пессимистическом управлении параллелизмом транзакция блокирует операции доступа к данным других транзакций при конфликтах, и конфликты нематериализованный пока блокировка не будет снята. Это сделано для того, чтобы гарантировать, что операции, которые могут нарушить сериализуемость (а на практике также восстанавливаемость), не выполняются.
  2. Оптимистичный: В Оптимистичный контроль параллелизма, операции доступа к данным других транзакций не блокируются при конфликтах, и конфликты немедленно материализованный. Когда транзакция достигает готовы состояние, т.е. его Бег состояние было завершено, проверяется возможное нарушение сериализуемости (а на практике также восстанавливаемости) операциями транзакции (относительно других запущенных транзакций): если нарушение произошло, транзакция обычно прерванный (иногда прерывание еще один транзакция для обработки нарушения сериализуемости является предпочтительной). В противном случае это преданный идее.
  3. Полуоптимистичный: Механизмы, которые сочетают блокировку в определенных ситуациях с блокировкой в ​​других ситуациях и используют как материализованные, так и нематериальные конфликты.

Основные различия между типами техники - это типы конфликтов, которые они порождают. Пессимистический метод блокирует операцию транзакции при конфликте и генерирует нематериализованный конфликт, тогда как оптимистический метод не блокирует и порождает материализованный конфликт. Полуоптимистический метод порождает оба типа конфликтов. Оба типа конфликта генерируются хронологическим порядком, в котором вызываются операции транзакции, независимо от типа конфликта. Цикл совершенных транзакций (с материализованными конфликтами) в граф приоритета (граф конфликта) представляет собой нарушение сериализуемости, и его следует избегать для сохранения сериализуемости. Цикл (нематериализованных) конфликтов в график ожидания представляет собой тупиковую ситуацию, которую следует разрешить путем разрыва цикла. Оба типа цикла являются результатом конфликтов и должны быть прерваны. При любом типе техники конфликты следует обнаруживать и учитывать с аналогичными накладными расходами как для материализованных, так и для нематериализованных конфликтов (обычно с использованием таких механизмов, как блокировка, при этом либо блокировка для блокировок, либо не блокировка, а запись конфликта для материализованных конфликтов). В методе блокировки обычно переключение контекста возникает при конфликте с (дополнительными) накладными расходами. В противном случае вычислительные ресурсы, связанные с заблокированными транзакциями, останутся простаивающими, неиспользованными, что может быть худшей альтернативой. Когда конфликты случаются не часто, оптимистические методы обычно имеют преимущество. При разных нагрузках транзакций (смешение типов транзакций) один тип техники (т. Е. Оптимистичный или пессимистический) может обеспечить лучшую производительность, чем другой.

Если только расписание занятий не по сути блокирующий (т.е. они не могут быть реализованы без блокировки операций доступа к данным; например, 2PL, SS2PL и SCO выше; см. диаграмму), они также могут быть реализованы с использованием оптимистических методов (например, сериализуемость, возможность восстановления).

Сериализуемый мультиверсионный контроль параллелизма

Смотрите также Многоверсионный контроль параллелизма (частичное покрытие) и Изоляция сериализуемых снимков в Изоляция снимков

Многоверсионный контроль параллелизма (MVCC) - это распространенный сегодня способ повысить параллелизм и производительность путем создания новой версии объекта базы данных каждый раз, когда объект записывается, и разрешения операций чтения транзакций нескольких последних соответствующих версий (каждого объекта) в зависимости от метода планирования. MVCC можно комбинировать со всеми перечисленными выше методами сериализуемости (кроме SerializableSI, который изначально основан на MVCC). Он используется в большинстве продуктов СУБД общего назначения.

MVCC особенно популярен в настоящее время благодаря ослабленная сериализуемость (см. выше) метод Изоляция снимков (SI), который обеспечивает лучшую производительность, чем большинство известных механизмов сериализуемости (за счет возможного нарушения сериализуемости в некоторых случаях). СериализуемыйSI, который является эффективным усовершенствованием SI, чтобы сделать его сериализуемым, призван обеспечить эффективное сериализуемое решение. SerializableSI был проанализирован[5][6] через общую теорию MVCC

Распределенная сериализуемость

Обзор

Распределенная сериализуемость сериализуемость расписания транзакционного распределенная система (например, распределенная база данных система). Такая система характеризуется: распределенные транзакции (также называемый глобальные транзакции), то есть транзакции, которые охватывают компьютерные процессы (абстракция процесса в общем смысле, в зависимости от вычислительной среды; например, Операционная система с нить ) и, возможно, сетевые узлы. Распределенная транзакция включает более одного из нескольких локальные суб-транзакции что у каждого есть состояния, описанные выше для транзакция базы данных. Локальная суб-транзакция состоит из одного процесса или нескольких процессов, которые обычно терпят неудачу вместе (например, в одном ядро процессора ). Распределенные транзакции подразумевают необходимость в атомарная фиксация протокол для достижения консенсуса среди своих локальных суб-транзакций о том, следует ли совершать или прервать. Такие протоколы могут варьироваться от простого (однофазного) установления связи между процессами, которые не работают вместе, до более сложных протоколов, таких как двухфазная фиксация для обработки более сложных случаев сбоя (например, сбоя процесса, узла, связи и т. д.). Распределенная сериализуемость - главная цель распределенный контроль параллелизма для правильности. С распространением Интернет, облачные вычисления, сеточные вычисления, а также небольшие портативные мощные вычислительные устройства (например, смартфоны,) потребность в эффективных методах распределенной сериализуемости для обеспечения корректности в распределенных приложениях и между ними, похоже, возрастает.

Распределенная сериализуемость достигается за счет реализации распределенных версий известных централизованных методов.[1][2] Как правило, все такие распределенные версии требуют использования информации о конфликте (материализованных или нематериализованных конфликтов или, что то же самое, о приоритете транзакции или информации о блокировании; обычно используется сериализуемость конфликтов), которая генерируется не локально, а скорее в разных процессах, и удаленная локации. Таким образом, необходимо распространение информации (например, отношения приоритета, информация о блокировках, временные метки или билеты). Когда распределенная система имеет относительно небольшой масштаб и задержки сообщений в системе невелики, методы централизованного управления параллелизмом можно использовать без изменений, в то время как определенные процессы или узлы в системе управляют соответствующими алгоритмами. Однако в крупномасштабной системе (например, сетка и облако), из-за распространения такой информации, как правило, происходит существенное снижение производительности, даже когда используются распределенные версии методов (по сравнению с централизованными), в первую очередь из-за компьютера и связи. задержка. Кроме того, когда такая информация распространяется, связанные методы обычно плохо масштабируются. Хорошо известным примером проблемы масштабируемости является распределенный менеджер блокировок, который распределяет информацию о блокировках (нематериализованных конфликтах) по распределенной системе для реализации методов блокировки.

Смотрите также

Примечания

  1. ^ а б Филип А. Бернштейн, Вассос Хадзилакос, Натан Гудман (1987): Контроль параллелизма и восстановление в системах баз данных (бесплатная загрузка PDF), издательство Addison Wesley Publishing Company, ISBN  0-201-10715-5
  2. ^ а б Герхард Вейкум, Готфрид Фоссен (2001): Системы транзакционной информации, Эльзевьер, ISBN  1-55860-508-8
  3. ^ Морис Херлихи и Дж. Элиот Б. Мосс. Транзакционная память: архитектурная поддержка структур данных без блокировки. Материалы 20-го ежегодного международного симпозиума по компьютерной архитектуре (ISCA '93). Том 21, выпуск 2, май 1993 г.
  4. ^ Грей, Дж.; Helland, P .; О’Нил, П.; Шаша, Д. (1996). Опасности репликации и решение (PDF). Труды 1996 г. ACM SIGMOD Международная конференция по управлению данными. С. 173–182. Дои:10.1145/233269.233330.[постоянная мертвая ссылка ]
  5. ^ а б c Майкл Дж. Кэхилл, Уве Рем, Алан Д. Фекете (2008): «Сериализуемая изоляция для баз данных моментальных снимков», Материалы международной конференции ACM SIGMOD 2008 г. по управлению данными, стр. 729-738, Ванкувер, Канада, июнь 2008 г., ISBN  978-1-60558-102-6 (Премия SIGMOD 2008 за лучшую работу)
  6. ^ Алан Фекете (2009), «Изоляция моментальных снимков и сериализуемое выполнение», Презентация, страница 4, 2009 г., Сиднейский университет (Австралия). Проверено 16 сентября 2009 г.

Рекомендации