|
размещением этих «старых» данных. Учитывая, что количество версий заранее не известно, сложно придумать эффективную структуру их хранения, которая бы не вызывала заметных накладных расходов. И, наконец, такая система слишком сложна в реализации. Именно из-за этих проблем предлагается использовать протокол 2V2PL. В этом протоколе возможно одновременное существование двух версий элемента данных: одной текущей версии данных и не более одной незавершенной. Такая организация версий выгодна прежде всего для транзакций, выполняющих операцию чтения. В 2V2PL используются три типа блокировок; каждая блокировка удерживается до конца транзакции. • Блокировка rl (read lock) устанавливается на текущую версию элемента данных х непосредственно перед ее прочтением. • Блокировка wl (write lock) устанавливается перед тем, как создать новую (незавершенную) версию элемента х. • Блокировка cl (commit lock) устанавливается перед выполнением последней операции транзакции (обычно перед операцией завершения) по отношению к каждому элементу данных, который она записала. Эта блокировка играет роль монопольной блокировки для обычного протокола 2PL. Она необходима для корректной смены версий. Блокировки rl совместимы между собой, а также с блокировками wl. Поэтому использование блокировок rl и wl обеспечивает выполнение правил (1а) и (lb) алгоритма MV2PL (с учетом того, что одновременно позволяется поддерживать не более одной незавершенной версии). Блокировка cl, в свою очередь, обеспечивает выполнение правил (2а) и (2Ь). 2.4. Многоверсионный протокол для транзакций, не изменяющих данные В работе многих приложений преобладают транзакции, не изменяющие данные (read-only). Такие приложения считывают и анализируют большие объемы данных. В случае наличия хотя бы небольшого числа параллельно 66 |
Как видно, этот алгоритм ничего не говорит о количестве версий одного и того же элемента, которые могут одновременно существовать в базе данных, что вызывает проблемы с хранением версий. Во-первых, они могут занимать слишком много места. Во-вторых, возникают трудности с размещением этих «старых» данных. Учитывая, что количество версий заранее не известно, сложно придумать эффективную структуру их хранения, которая бы не вызывала заметных накладных расходов. И, наконец, такая система слишком сложна в реализации. Именно из-за этих проблем предлагается использовать протокол 2V2PL. В этом протоколе возможно одновременное существование двух версий элемента данных: одной текущей версии данных и не более одной незавершенной. Такая организация версий выгодна прежде всего для транзакций, выполняющих операцию чтения. В 2V2PL используются три типа блокировок; каждая блокировка удерживается до конца транзакции. • Блокировка г/ (read lock) устанавливается на текущую версию элемента данных х непосредственно перед ее прочтением. • Блокировка wl (write lock) устанавливается перед тем, как создать новую (незавершенную) версию элемента х. • Блокировка с/ (commit lock) устанавливается перед выполнением последней операции транзакции (обычно перед операцией завершения) по отношению к каждому элементу данных, который она записала. Эта блокировка играет роль монопольной блокировки для обычного протокола 2PL. Она необходима для корректной смены версий. Блокировки rl совместимы между собой, а также с блокировками wl. Поэтому использование блокировок rl и wl обеспечивает выполнение правил (1а) и (lb) алгоритма MV2PL (с учетом того, что одновременно позволяется поддерживать не более одной незавершенной версии). Блокировка с/, в свою очередь, обеспечивает выполнение правил (2а) и (2Ь). 3.4 Многоверсионный протокол для транзакций, не изменяющих данные В работе многих приложений преобладают транзакции, не изменяющие данные (read-only). Такие приложения считывают и анализируют большие объемы данных. В случае наличия хотя бы небольшого числа параллельно выполняемых транзакций, производящих изменения, компонент, который отвечает за управление параллельными транзакциями, должен обеспечить согласованность прочитанных данных. В случае использования алгоритмов планирования без поддержки версий такие долговременные транзакции могут привести к чрезвычайному падению производительности. Например, при использовании 2PL крайне велика вероятность блокировки транзакций, производящих обновления данных. В результате у этих транзакций будет очень большое время отклика. Многоверсионные алгоритмы позволяют избежать подобных проблем благодаря тому, что транзакция, вносящая изменения в базу данных, не конфликтует с транзакциями чтения. Но в то же время многоверсионные алгоритмы обычно сложны в реализации и запросы к версионным СУБД вызывают заметные накладные расходы. Протокол ROMV (Multiversion Protocol for Read-Only Transactions, ROMV) — гибридный, он основан на MVTO и 2PL. Он ориентирован на приложения, для которых наиболее важна скорость выполнения транзакций, не производящих изменений данных. ROMV-планировщик разделяет все транзакции во время их создания на две группы — запросы и транзакции, изменяющие данные. Соответственно, транзакции разных типов обрабатываются по-разному. Такой протокол оказывается проще в реализации и позволяет получить большую часть выгод, предоставляемых чисто версионными протоколами. Транзакции обрабатываются следующим образом. Транзакции, модифицирующие данные, выполняются в соответствии с протоколом S2PL — варианте 2PL. В нем все монопольные блокировки |