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

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

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

Фазы оптимистического управления параллелизмом

Транзакции управления оптимистичным параллелизмом включают следующие этапы: ^[2]

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

Использование Интернета

Природа состояния HTTP без сохранения делает блокировку для пользовательских веб-интерфейсов невозможной. Обычно пользователь начинает редактировать запись, а затем уходит, не перейдя по ссылке «отмена» или «выход». Если используется блокировка, другие пользователи, пытающиеся редактировать ту же запись, должны дождаться истечения времени блокировки первого пользователя.

HTTP предоставляет форму встроенного OCC. Ответ на первоначальный запрос GET может включать ETag для последующих запросов PUT для использования в заголовке If-Match. Любые запросы PUT с устаревшим ETag в заголовке If-Match могут быть отклонены. ^[3]

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

Примеры

. Страницы редактирования MediaWiki используют OCC ^[4]
Bugzilla использует OCC; Конфликты редактирования называются «столкновениями в воздухе». ^[5]
Фреймворк Ruby on Rails имеет API для OCC. ^[6]
Платформа Grails использует OCC в своих соглашениях по умолчанию. ^[7]
Ядро базы данных GT.M использует OCC для управления транзакциями. ^[8] (даже отдельные обновления рассматриваются как мини-транзакции).
Microsoft Entity Framework (включая Code-First) имеет встроенную поддержку OCC на основе двоичного значения временной метки. ^[9]
Большинство систем контроля версий поддерживают модель «слияния» для параллелизма, то есть OCC. ^{[ нужна ссылка ]}
Mimer SQL — это СУБД , реализующая только оптимистический контроль параллелизма. ^[10]
Хранилище данных Google App Engine использует OCC. ^[11]
Поисковая система Apache Solr поддерживает OCC через поле _version_. ^[12]
обновляет Поисковая система Elasticsearch свои документы через OCC. Каждой версии документа присваивается порядковый номер, а более новые версии получают более высокие порядковые номера. Поскольку изменения в документе поступают асинхронно, программное обеспечение может использовать порядковый номер, чтобы избежать замены более новой версии старой. ^[13]
CouchDB реализует OCC посредством изменений в документах. ^[14]
OCC Схема управления транзакциями системы управления базами данных MonetDB основана на . ^[15]
Большинство реализаций программной транзакционной памяти используют OCC. ^{[ нужна ссылка ]}
Redis предоставляет OCC через команду WATCH. ^[16]
Firebird использует архитектуру нескольких поколений как реализацию OCC для управления данными. ^{[ нужна ссылка ]}
DynamoDB использует условное обновление как реализацию OCC. ^[17]
Kubernetes использует OCC при обновлении ресурсов. ^[18]
YugabyteDB — это облачная база данных, которая в основном использует OCC. ^[19]
Firestore — это база данных NoSQL от Firebase , которая использует OCC в своих транзакциях.

См. также

Блок сообщений сервера # Уступающая блокировка

Ссылки

^ Джонсон, Рохит (2003). «Общие проблемы доступа к данным» . Экспертное индивидуальное проектирование и разработка J2EE . Врокс Пресс. ISBN 978-0-7645-4385-2 . Архивировано из оригинала 8 октября 2011 года.
^ Перейти обратно: ^а ^б HT Кунг, Дж. Т. Робинсон (1981). «Об оптимистических методах управления параллелизмом» (PDF) . Транзакции ACM в системах баз данных. Архивировано (PDF) из оригинала 31 августа 2019 г.
^ «Редактирование в Интернете: обнаружение проблемы с потерянным обновлением с помощью незарезервированного извлечения» . Примечание W3C . 10 мая 1999 г.
^ Справка:Редактировать конфликт.
^ «Bugzilla: Часто задаваемые вопросы: административные вопросы» . МозиллаВики . 11 апреля 2012 г.
^ «Модуль ActiveRecord::Locking» . Документация Rails Framework .
^ «Реляционное сопоставление объектов (GORM)» . Документация по платформе Grails . Архивировано из оригинала 15 августа 2014 г.
^ «Обработка транзакций» . Руководство программиста GT.M для UNIX Edition .
^ «Обработка конфликтов параллелизма» . Центр документации Entity Framework . 5 июля 2023 г.
^ «Параллелизм транзакций — оптимистическое управление параллелизмом» . Разработчики Mimer — Возможности . Проверено 22 декабря 2023 г.
^ «Хранилище данных» . Что такое Google App Engine? . 27 августа 2010 г.
^ «Обновление частей документов» . Проверено 28 июня 2018 г.
^ «Оптимистическое управление параллелизмом» . Эластичный . Проверено 5 февраля 2024 г.
^ «Технический обзор» . Документация Apache CouchDB . Проверено 6 февраля 2024 г.
^ «Транзакции — MonetDB» . 16 января 2013 г.
^ «Транзакции в Redis» .
^ «Работа с элементами и атрибутами — условная запись» . Проверено 2 ноября 2020 г.
^ «Обзор API — операции с ресурсами» . Проверено 3 ноября 2020 г. .
^ Югабайт, Команда. «Явная блокировка | Документы YugabyteDB» . docs.yugabyte.com . Проверено 4 января 2022 г.

Внешние ссылки

Кунг, ХТ; Джон Т. Робинсон (июнь 1981 г.). «Об оптимистических методах управления параллелизмом». Транзакции ACM в системах баз данных . 6 (2): 213–226. CiteSeerX 10.1.1.101.8988 . дои : 10.1145/319566.319567 . S2CID 61600099 .
Enterprise JavaBeans, 3.0, Билл Берк, Ричард Монсон-Хафель, Глава 16. Транзакции, Раздел 16.3.5. Оптимистическая блокировка, Издательство: O'Reilly, Дата публикации: 16 мая 2006 г., Печать ISBN 0-596-00978-X ,
Холлманн, Андреас (май 2009 г.). «Мультиизоляция: преимущества и ограничения» (PDF) . Мультиизоляция (что находится между пессимистической и оптимистической блокировкой) . 01069 Гуцковстр. 30/F301.2, Дрезден: Happy-Guys Software GbR. п. 8 . Проверено 16 мая 2013 г. {{cite conference}}: CS1 maint: местоположение ( ссылка ) ^{[ постоянная мертвая ссылка ]}

[1] Джонсон, Рохит (2003). «Общие проблемы доступа к данным» . Экспертное индивидуальное проектирование и разработка J2EE . Врокс Пресс. ISBN 978-0-7645-4385-2 . Архивировано из оригинала 8 октября 2011 года.

[KungRobinson1981-2] Перейти обратно: ^а ^б HT Кунг, Дж. Т. Робинсон (1981). «Об оптимистических методах управления параллелизмом» (PDF) . Транзакции ACM в системах баз данных. Архивировано (PDF) из оригинала 31 августа 2019 г.

[3] «Редактирование в Интернете: обнаружение проблемы с потерянным обновлением с помощью незарезервированного извлечения» . Примечание W3C . 10 мая 1999 г.

[4] Справка:Редактировать конфликт.

[5] «Bugzilla: Часто задаваемые вопросы: административные вопросы» . МозиллаВики . 11 апреля 2012 г.

[6] «Модуль ActiveRecord::Locking» . Документация Rails Framework .

[7] «Реляционное сопоставление объектов (GORM)» . Документация по платформе Grails . Архивировано из оригинала 15 августа 2014 г.

[8] «Обработка транзакций» . Руководство программиста GT.M для UNIX Edition .

[9] «Обработка конфликтов параллелизма» . Центр документации Entity Framework . 5 июля 2023 г.

[10] «Параллелизм транзакций — оптимистическое управление параллелизмом» . Разработчики Mimer — Возможности . Проверено 22 декабря 2023 г.

[11] «Хранилище данных» . Что такое Google App Engine? . 27 августа 2010 г.

[12] «Обновление частей документов» . Проверено 28 июня 2018 г.

[13] «Оптимистическое управление параллелизмом» . Эластичный . Проверено 5 февраля 2024 г.

[14] «Технический обзор» . Документация Apache CouchDB . Проверено 6 февраля 2024 г.

[15] «Транзакции — MonetDB» . 16 января 2013 г.

[16] «Транзакции в Redis» .

[17] «Работа с элементами и атрибутами — условная запись» . Проверено 2 ноября 2020 г.

[18] «Обзор API — операции с ресурсами» . Проверено 3 ноября 2020 г. .

[19] Югабайт, Команда. «Явная блокировка | Документы YugabyteDB» . docs.yugabyte.com . Проверено 4 января 2022 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]