Проверяемый текст
Гаврилов, Евгений Сергеевич. Модельно-алгоритмическая поддержка анализа транзакционной надежности в системах обработки информации и управления (Диссертация 2006)
[стр. 67]

выполняемых транзакций, производящих изменения, компонент, который отвечает за управление параллельными транзакциями, должен обеспечить согласованность прочитанных данных.
В случае использования алгоритмов планирования без поддержки версий такие долговременные транзакции могут привести к чрезвычайному падению производительности.
Например, при использовании 2PL крайне велика вероятность блокировки транзакций, производящих обновления данных.
В результате у этих транзакций будет очень большое время отклика.
Многоверсионные алгоритмы позволяют избежать подобных проблем благодаря тому, что транзакция, вносящая изменения в базу данных, не конфликтует с транзакциями чтения.
Но в то же время многоверсионные алгоритмы обычно сложны в реализации и запросы к версионным СУБД вызывают заметные накладные расходы.
Протокол ROMV (Multiversion Protocol for Read-Only Transactions, ROMV) — гибридный, он основан на MVTO и 2PL.
Он ориентирован на приложения, для которых наиболее важна скорость выполнения транзакций, не производящих изменений данных.
ROMV-планировщик разделяет все транзакции во время их создания на две группы — запросы и транзакции, изменяющие данные.
Соответственно, транзакции разных типов обрабатываются по-разному.
Такой протокол оказывается проще в реализации и позволяет получить большую часть выгод, предоставляемых чисто версионными протоколами.
Транзакции обрабатываются следующим образом.
Транзакции, модифицирующие данные, выполняются в соответствии с протоколом S2PL — варианте 2PL.
В нем все монопольные блокировки
отпускаются лишь в конце транзакции.
Каждая операция, изменяющая элемент данных, создает новую версию этого элемента.
По завершении транзакции каждая такая версия помечается временной меткой, соответствующей времени завершения транзакции.

67
[стр. 137]

3.4 Многоверсионный протокол для транзакций, не изменяющих данные В работе многих приложений преобладают транзакции, не изменяющие данные (read-only).
Такие приложения считывают и анализируют большие объемы данных.
В случае наличия хотя бы небольшого числа параллельно выполняемых транзакций, производящих изменения, компонент, который отвечает за управление параллельными транзакциями, должен обеспечить согласованность прочитанных данных.
В случае использования алгоритмов планирования без поддержки версий такие долговременные транзакции могут привести к чрезвычайному падению производительности.
Например, при использовании 2PL крайне велика вероятность блокировки транзакций, производящих обновления данных.
В результате у этих транзакций будет очень большое время отклика.
Многоверсионные алгоритмы позволяют избежать подобных проблем благодаря тому, что транзакция, вносящая изменения в базу данных, не конфликтует с транзакциями чтения.
Но в то же время многоверсионные алгоритмы обычно сложны в реализации и запросы к версионным СУБД вызывают заметные накладные расходы.
Протокол ROMV (Multiversion Protocol for Read-Only Transactions, ROMV) — гибридный, он основан на MVTO и 2PL.
Он ориентирован на приложения, для которых наиболее важна скорость выполнения транзакций, не производящих изменений данных.
ROMV-планировщик разделяет все транзакции во время их создания на две группы — запросы и транзакции, изменяющие данные.
Соответственно, транзакции разных типов обрабатываются по-разному.
Такой протокол оказывается проще в реализации и позволяет получить большую часть выгод, предоставляемых чисто версионными протоколами.
Транзакции обрабатываются следующим образом.
Транзакции, модифицирующие данные, выполняются в соответствии с протоколом S2PL — варианте 2PL.
В нем все монопольные блокировки


[стр.,138]

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

Запросы обрабатываются подобно тому, как это происходит в протоколе MVTO.
Каждому запросу также ставится в соответствие временная метка, но в данном случае она соответствует времени начала транзакции.
При выборе версии для чтения запрос выбирает последнюю, завершенную к моменту старта запроса версию.
Несмотря на идейную простоту, этот подход вызывает некоторые сложности при реализации.
Например, он требует создания специального сборщика мусора.
Этот компонент СУБД должен удалять ненужные версии данных.
Простейший сборщик мусора удаляет все версии (кроме текущих), значения временных меток которых меньше времени начала старейшей из активных читающих транзакций.
3.5 MVSG-планировщики Последний рассматриваемый класс многоверсионных алгоритмов планирования обобщает широко известную моноверсионную технику Serialization Graph Testing (SGT).
Основанные на SGT планировщики поддерживают граф конфликтов, в котором вершины и дуги добавляются динамически в зависимости от операций, которые получает на вход планировщик.
При этом конфликтующими называются любые две операции над одним и тем же элементом данных, если хотя бы одна из них является операцией модификации.
Другими словами, для конфликтующих операций важен порядок их выполнения.
Таким образом, планирование конфликтующих операций накладывает ограничение на порядок сериализации транзакций.
Эти ограничения и выражает граф конфликтов.
Рассмотрим, как происходит планирование очередной операции pi(x) с помощью SGT-планировщика.

[Back]