Оптимистическая vs Multi Version Concurrency Контроль - Различия?

Я пытаюсь выяснить, какова разница между оптимистичным управлением concurrency (OCC) и несколькими версиями concurrency (MVCC)?

До сих пор я знаю, что оба они основаны на проверке версий для обновлений.

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

В MVCC это в основном то же самое или нет? Где разница?

Ответ 1

Я думаю, что они иногда используются взаимозаменяемо, и если транзакция включает только один объект, то они по существу одинаковы, но MVCC является расширением оптимистического concurrency (или его версии), который обеспечивает гарантии, когда более одного объект. Скажем, что у вас есть два объекта: A и B, которые должны поддерживать некоторый инвариант между ними, например. они представляют собой два числа, сумма которых постоянна. Теперь транзакция T1 вычитает 10 из A и добавляет ее в B, в то время как другая транзакция T2 считывает два числа. Даже если вы оптимистично обновляете A и B независимо (CAS them), T2 может получить несогласованный вид двух чисел (например, если он читает A до его изменения, но читает B после его изменения). MVCC обеспечит, чтобы T2 читал согласованное представление A и B, возможно возвращая их старые значения, то есть он должен сохранять старые версии.

Подводя итог, оптимистичная блокировка (или оптимистичное управление concurrency) является общим принципом синхронизации без блокировок. MVCC - это оптимистичный метод, который позволяет изолировать транзакции, охватывающие несколько объектов.

Ответ 2

Чтобы напрямую ответить на вопрос, multi version concurrency control (MVCC) - это метод управления concurrency, относящийся к категории оптимистического concurrency управления (OCC).

Существует два основных подхода к управлению concurrency:

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

Одним из широко известных алгоритмов пессимистического управления concurrency является двухфазная блокировка.

Двумя широко известными алгоритмами оптимистического управления concurrency являются:

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

Ответ 3

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