Вопрос о распределении меток времени в оптимизированном параллельном управлении? - PullRequest
0 голосов
/ 12 октября 2018

Есть статья о MVOCC (MVCC + Оптимизированный параллельный контроль)

3.2 Оптимистичный параллельный контроль (MVOCC)Следующий протокол основан на схеме оптимистического управления параллелизмом (OCC), предложенной в 1981 году [26].Мотивация OCC заключается в том, что СУБД предполагает, что транзакции вряд ли будут конфликтовать, и, таким образом, транзакция не должна получать блокировки на кортежи, когда она читает или обновляет их.Это уменьшает количество времени, в течение которого транзакция удерживает блокировки.Существуют изменения в оригинальном протоколе OCC, чтобы адаптировать его для мультиверинга [27].Прежде всего, СУБД не поддерживает частную рабочую область для транзакций, поскольку информация о версиях кортежей уже запрещает транзакциям читать или обновлять версии, которые не должны быть для них видимы.Протокол MVOCC разделяет транзакцию на три этапа.Когда транзакция начинается, она находится в фазе чтения.Здесь транзакция вызывает операции чтения и обновления в базе данных.Как и MVTO, для выполнения операции чтения на кортеже A СУБД сначала ищет видимую версию Ax на основе полей begin-ts и end-ts.T разрешено обновлять версию Ax, если не получена блокировка записи.Если в версии с несколькими версиями транзакция обновляет версию Bx, то СУБД создает версию Bx + 1 с ее txn-id, установленным в Tid.Когда транзакция инструктирует СУБД, что она хочет зафиксировать, она входит в фазу проверки.Сначала СУБД назначает транзакции другую временную метку (Tcommit) для определения порядка сериализации транзакций.Затем СУБД определяет, были ли кортежи в наборе чтения транзакции обновлены транзакцией, которая уже зафиксирована.Если транзакция проходит эти проверки, она входит в фазу записи, где СУБД устанавливает все новые версии и устанавливает их начальные значения в Tcommit и конечные значения в INF.Транзакции могут обновлять только последнюю версию кортежа.Но транзакция не может прочитать новую версию, пока другая транзакция, которая ее создала, не зафиксирует.Транзакция, которая читает устаревшую версию, обнаружит, что она должна прерваться на этапе проверки.

Так что мой вопрос заключается в том, почему вместо второй метки фиксации времени выделять вторую метку времени вместо ее первой?В чем преимущество выделения второго?

...