Почему оптимистическая блокировка быстрее, чем пессимистическая?


9

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

Но оба приводят к зависанию второго процесса. Поэтому я спрашиваю: почему оптимистическая блокировка обычно считается быстрее / лучше, чем пессимистическая блокировка? И есть ли случаи использования, когда пессимистический предпочтительнее, чем оптимистичный? Заранее спасибо!


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

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

Ответы:


8

Двойной вопрос от:

/programming/129329/optimistic-vs-pessimistic-locking

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

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

Если запись грязная (т. Е. Версия отличается от вашей), вы прерываете транзакцию, и пользователь может перезапустить ее.

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

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

В последнем случае вы открываете транзакцию с TxID, а затем повторно подключаетесь с использованием этого идентификатора. СУБД поддерживает блокировки и позволяет вам забрать сеанс обратно через TxID. Именно так работают распределенные транзакции, использующие протоколы двухфазной фиксации (такие как транзакции XA или COM +).

Изменить (добавив больше информации для решения вопроса производительности):

Производительность зависит от вашей среды. Примите во внимание следующие факторы:

вы найдете оптимизм лучше из-за параллелизма в большинстве ситуаций. Однако в зависимости от СУБД и среды это может быть менее или более производительным. Как правило, с Оптимистической блокировкой вы обнаружите, что значение должно быть где-то версировано.

Например, в MS SQL Server он перемещается в TempDB, и в конце столбца добавляется что-то между 12-14 байтами. Включение оптимистической блокировки с уровнем изоляции, таким как изоляция моментальных снимков, может привести к фрагментации, и необходимо будет скорректировать коэффициент заполнения, так как строки теперь имеют дополнительные данные в конце, что может привести к тому, что страница почти заполнится, что приведет к разделению страницы, что приведет к снижению ваше выступление. Если ваша TempDB недостаточно оптимизирована, это будет не так быстро.

Итак, я думаю, контрольный список:

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

Это мои мысли по этому вопросу, открытые для получения дополнительной информации от сообщества.


Спасибо @Ali Razeghi (+1) - я думаю, что dba.se является более подходящим местом для этого вопроса. Кроме того, хотя это превосходный ответ, он не отвечает на мой вопрос производительности (когда один быстрее другого). Еще раз спасибо!
Мара

Привет Мара, это хороший момент. Я расширил ответ. Спасибо.
Али Разеги

11

Вы неправильно понимаете оптимистическую блокировку.

Оптимистическая блокировка не заставляет транзакции ждать друг друга.

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


1

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

При оптимистичной стратегии блокировки «зависание» происходит на стороне клиента и не влияет на других.

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

Я не согласен с превосходством любого подхода; оба они могут быть использованы неправильно. Pessimistic более подвержен ошибкам только потому, что он более опасен: блокировка происходит на уровне базы данных, зависит от RDMS, у вас может не быть контроля над тем, что заблокировано (эскалация блокировки), вам нужно позаботиться о порядке блокировки вручную.


Интересный момент a1ex07, optimsitic блокировка все еще включает блокировку, однако, поскольку записи всегда будут блокировать другие записи, правильно?
Али Разеги

Нет, это не так. Вот почему это «быстрее».
Эрвин Смут

Это может иметь место для Oracle, но для MS SQL Server, так как он по умолчанию использует уровень изоляции «зафиксировано для чтения», оптимистическая блокировка позволит одновременно работать считывателям и потокам записи, но записи блокируют записи до фиксации потока блокировки.
Али Разеги

@ Али Разеги: Я не уверен, что следую вашей точке зрения. В SQLServer с записанными на чтение авторами блокируются читатели по умолчанию, если не включено `READ_COMMITTED_SNAPSHOT`. Оптимистическая блокировка - это не блокировка ресурса базы данных (строка / страница / таблица), а своего рода соглашение между всеми приложениями, которые используют базу данных, чтобы не обновлять запись, если версия не соответствует ожидаемой.
a1ex07

1
@ Eamon Nerbonne: Я сказал о «писатели не блокируют читателей» ... Где вы видели, что я упоминал о «писатели блокируют / не блокируют писателей»?
a1ex07

0

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

Пессимистическая блокировка предполагает, что параллельные транзакции будут конфликтовать друг с другом, поэтому она требует блокировки, это делается путем указания уровня ИЗОЛЯЦИИ (Чтение незафиксированного, Чтение зафиксированного, Повторяемое чтение и Сериализуемый) управления транзакциями. Он устраняет проблемы параллелизма путем получения блокировки. блокировки служат для защиты общих ресурсов или объектов (таблиц, строк данных, блоков данных, кэшированных элементов, соединений и целых систем). У нас есть много типов блокировок, таких как общие блокировки, блокировки обновлений, блокировки вставок, эксклюзивные блокировки, блокировки транзакций, блокировки DML, блокировки схемы и блокировки резервного копирования и восстановления.

чтобы получить больше идеи


-3

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

SELECT COUNT(*) FROM atable

Вы увидите, что в СУБД, которые поддерживают нативно-оптимистический подход, время, затрачиваемое на этот запрос, значительно значительнее, чем у тех, кто имеет изначально пессимистическую блокировку.

Например, на моем ПК тот же запрос занимает 27 мс на SQL Server и 109 мс на PostGreSQL ...

Дополнительные затраты, необходимые для чтения мертвых версий строк MVCC и не учитывающие записи о привидениях в совокупности, увеличивают затраты, которых нет у пессимиста!


4
Подход управления параллелизмом СУБД ортогональн к оптимистической / пессимистической блокировке, а сравнение времени выполнения запросов в двух разных СУБД вводит в заблуждение.
mustaccio

Поскольку SQL Server может выполнять два режима блокировки, вы можете легко сравнить это, выполнив реальный результат в подходе параллелизма пользователей.
user7370003
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.