Оптимистичный контроль параллелизма - Optimistic concurrency control

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

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

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

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

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

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

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

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

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

Примеры

• MediaWiki Страницы редактирования используют OCC.^[4]
• Bugzilla использует OCC; редактировать конфликты называются «столкновения в воздухе».^[5]
• В Рубин на рельсах framework имеет API для OCC.^[6]
• В Грааль framework использует OCC по умолчанию.^[7]
• В GT.M ядро базы данных использует OCC для управления транзакциями^[8] (даже единичные обновления рассматриваются как мини-транзакции).
• Microsoft с Entity Framework (включая Code-First) имеет встроенную поддержку OCC на основе двоичного значения временной метки.^[9]
• Mimer SQL это СУБД это только реализует оптимистичный контроль параллелизма.^[10]
• Google App Engine хранилище данных использует OCC.^[11]
• В Apache Solr поисковая система поддерживает OCC через поле _version_.^[12]
• В Elasticsearch поисковая система поддерживает OCC через атрибут версии.^[13]
• CouchDB реализует OCC через редактирование документов.^[14]
• В MonetDB столбчатый система управления базами данных Схема управления транзакциями в России основана на OCC.^[15]
• Большинство реализаций программная транзакционная память используйте OCC.^{[нужна цитата ]}
• Redis обеспечивает OCC через команду WATCH.^[16]
• MySQL реализует OCC в конфигурации групповой репликации.^{[нужна цитата ]}
• Жар-птица использует Архитектура нескольких поколений как реализация OCC для управления данными.^{[нужна цитата ]}
• DynamoDB использует условное обновление как реализацию OCC.^[17]
• Kubernetes использует OCC при обновлении ресурсов.^[18].

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

• Блок сообщения сервера № Оппортунистическая блокировка

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

1. Джонсон, Рохит (2003). «Общие проблемы доступа к данным». Индивидуальное проектирование и разработка J2EE для экспертов. Wrox Press. ISBN  978-0-7645-4385-2. Архивировано из оригинал 8 октября 2011 г.
2. Х. Т. Кунг, Дж. Т. Робинсон (1981). «Об оптимистических методах управления параллелизмом» (PDF). ACM-транзакции в системах баз данных.
3. «Редактирование Интернета - обнаружение проблемы с утерянным обновлением с помощью незарезервированной проверки». Примечание W3C. 10 мая 1999 г.
4. Справка: редактировать конфликт
5. "Bugzilla: FAQ: административные вопросы". MozillaWiki. 11 апреля 2012 г.
6. «Модуль ActiveRecord :: Locking». Документация по Rails Framework.
7. «Объектно-реляционное отображение (GORM)». Документация по Grails Framework. Архивировано из оригинал на 2014-08-15.
8. "Обработка транзакции". Руководство программиста GT.M UNIX Edition.
9. «Совет 19 - Как использовать оптимистичный параллелизм с Entity Framework». Блоги MSDN. 19 мая 2009 г.
   • Наиболее контроль версий системы поддерживают модель «слияния» для параллелизма, которая называется OCC.
10. «Параллелизм транзакций - оптимистичное управление параллелизмом». Разработчики Mimer - Особенности. 26 февраля 2010. Архивировано с оригинал 21 марта 2013 г.. Получено 6 мая 2013.
11. "Хранилище данных". Что такое Google App Engine?. 27 августа 2010 г.
12. «Обновление частей документов». Получено 2018-06-28.
13. «Elasticsearch - Руководство - Index API». Руководство по Elasticsearch. 22 марта 2012 г.
14. "Couchdb Wiki - Document_revisions". Архивировано из оригинал 4 февраля 2017 г.
15. «Сделки - MonetDB». 16 января 2013 г.
16. «Транзакции в Redis».
17. «Работа с элементами и атрибутами - условные записи». Получено 2 ноября 2020.
18. «Обзор API - операции с ресурсами». Получено 3 ноября 2020.

внешняя ссылка

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