Управление параллелизмом СУБД: отметка времени & Протоколы на основе блокировки

Содержание:

Anonim

Что такое контроль параллелизма?

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

Одновременный доступ довольно прост, если все пользователи просто читают данные. Они никак не могут мешать друг другу. Хотя для любой практической базы данных в ней будут сочетаться операции READ и WRITE, и, следовательно, параллелизм является проблемой.

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

В этом руководстве вы узнаете

  • Что такое контроль параллелизма?
  • Возможные проблемы параллелизма
  • Зачем использовать метод параллелизма?
  • Протоколы управления параллелизмом
  • Протоколы на основе блокировки
  • Протокол двухфазной блокировки (2PL)
  • Протоколы на основе отметок времени
  • Протокол на основе валидации
  • Характеристики протокола хорошего параллелизма

Возможные проблемы параллелизма

Вот некоторые проблемы, с которыми вы, вероятно, столкнетесь при использовании метода управления параллелизмом СУБД:

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

Зачем использовать метод параллелизма?

Причины использования метода управления параллелизмом - СУБД:

  • Чтобы применить изоляцию через взаимное исключение между конфликтующими транзакциями
  • Для решения проблем, связанных с конфликтами чтения-записи и записи-записи
  • Для сохранения согласованности базы данных за счет постоянного устранения препятствий выполнению
  • Система должна контролировать взаимодействие между параллельными транзакциями. Этот контроль достигается с помощью схем параллельного управления.
  • Контроль параллелизма помогает обеспечить сериализуемость

Пример

Предположим, что два человека одновременно ходят в электронные киоски, чтобы купить билет в один и тот же фильм и в одно и то же время сеанса.

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

Протоколы управления параллелизмом

Различные протоколы управления параллелизмом предлагают разные преимущества в зависимости от степени параллелизма, которую они разрешают, и количества накладных расходов, которые они накладывают. Ниже приведены методы управления параллелизмом в СУБД:

  • Протоколы на основе блокировки
  • Протокол двухфазной блокировки
  • Протоколы на основе отметок времени
  • Протоколы на основе валидации

Протоколы на основе блокировки

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

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

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

Двоичные блокировки : двоичная блокировка элемента данных может быть заблокирована или разблокирована.

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

1. Общий замок (S):

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

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

2. Эксклюзивный замок (X):

С эксклюзивной блокировкой элемент данных может быть прочитан, а также записан. Это эксклюзивно и не может выполняться одновременно с одним и тем же элементом данных. X-lock запрашивается с помощью инструкции lock-x. Транзакции могут разблокировать элемент данных после завершения операции «записи».

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

3. Протокол упрощенной блокировки

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

4. Предварительная блокировка

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

Голодание

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

Ниже приведены причины голода:

  • Когда схема ожидания заблокированных предметов не управляется должным образом
  • В случае утечки ресурса
  • Одна и та же транзакция повторно выбирается в качестве жертвы

Тупик

Тупиковая ситуация относится к конкретной ситуации, когда два или более процесса ждут друг друга, чтобы освободить ресурс, или более двух процессов ожидают ресурс в кольцевой цепочке.

Протокол двухфазной блокировки

Протокол двухфазной блокировки, также известный как протокол 2PL, представляет собой метод управления параллелизмом в СУБД, который обеспечивает сериализуемость путем применения блокировки к данным транзакции, которая блокирует одновременный доступ к тем же данным для других транзакций. Протокол Two Phase Locking помогает устранить проблему параллелизма в СУБД.

Этот протокол блокировки разделяет фазу выполнения транзакции на три разные части.

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

Протокол двухфазной блокировки позволяет каждой транзакции выполнять запрос блокировки или разблокировки в два этапа:

  • Фаза роста : на этой фазе транзакция может получать блокировки, но не может снимать блокировки.
  • Фаза сжатия : на этом этапе транзакция может снимать блокировки, но не получать новую блокировку.

Это правда, что протокол 2PL предлагает сериализуемость. Однако это не гарантирует, что тупиковые ситуации не возникнут.

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

Строгий метод двухфазной блокировки

Система строгой двухфазной синхронизации практически аналогична 2PL. Единственная разница в том, что Strict-2PL никогда не снимает блокировку после ее использования. Он удерживает все блокировки до точки фиксации и снимает все блокировки сразу после завершения процесса.

Централизованная 2PL

В Centralized 2 PL за процесс управления блокировками отвечает один сайт. У него только один менеджер блокировок на всю СУБД.

Первичная копия 2PL

Первичный механизм копирования 2PL, многие менеджеры блокировок распределены по разным сайтам. После этого конкретный менеджер блокировок отвечает за управление блокировкой для набора элементов данных. Когда первичная копия обновлена, изменение распространяется на ведомые устройства.

Распределенная 2PL

В этом виде двухфазного механизма блокировки диспетчеры блокировки распределяются по всем сайтам. Они несут ответственность за управление блокировками данных на этом сайте. Если данные не реплицируются, это эквивалентно первичной копии 2PL. Коммуникационные расходы распределенной 2PL значительно выше, чем у первичной копии 2PL.

Протоколы на основе отметок времени

Протокол на основе меток времени в СУБД - это алгоритм, который использует системное время или логический счетчик в качестве метки времени для сериализации выполнения параллельных транзакций. Протокол на основе меток времени гарантирует, что все конфликтующие операции чтения и записи выполняются в порядке меток времени.

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

Протоколы на основе блокировки помогают вам управлять порядком между конфликтующими транзакциями, когда они будут выполняться. Протоколы на основе меток времени управляют конфликтами сразу после создания операции.

Пример:

Suppose there are there transactions T1, T2, and T3.T1 has entered the system at time 0010T2 has entered the system at 0020T3 has entered the system at 0030Priority will be given to transaction T1, then transaction T2 and lastly Transaction T3.

Преимущества :

  • Расписания сериализуемы, как протоколы 2PL
  • Никакого ожидания транзакции, что исключает возможность возникновения тупиковых ситуаций!

Недостатки:

Голодание возможно, если одна и та же транзакция перезапускается и постоянно прерывается.

Протокол на основе валидации

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

Протокол на основе валидации состоит из трех этапов:

  1. Фаза чтения
  2. Фаза валидации
  3. Фаза записи

Фаза чтения

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

Фаза валидации

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

Фаза записи

На этапе записи обновления применяются к базе данных, если проверка прошла успешно, иначе; обновления не применяются, и транзакция откатывается.

Характеристики протокола хорошего параллелизма

Идеальный механизм СУБД управления параллелизмом преследует следующие цели:

  • Должен быть устойчивым к сбоям сайта и связи.
  • Это позволяет параллельное выполнение транзакций для достижения максимального параллелизма.
  • Его механизмы хранения и вычислительные методы должны быть скромными, чтобы минимизировать накладные расходы.
  • Он должен налагать некоторые ограничения на структуру атомарных действий транзакций.

Резюме

  • Контроль параллелизма - это процедура в СУБД для управления одновременными операциями без конфликта друг с другом.
  • Потерянные обновления, грязное чтение, неповторяющееся чтение и неверная сводная проблема - это проблемы, с которыми сталкиваются из-за отсутствия контроля параллелизма.
  • На основе блокировки, двухфазный, на основе отметок времени, на основе проверки - это типы протоколов обработки параллелизма.
  • Блокировка может быть общей (S) или эксклюзивной (X).
  • Протокол двухфазной блокировки, который также известен как протокол 2PL, должен получить блокировку после того, как она освободит одну из своих блокировок. Он имеет 2 фазы роста и сжатия.
  • Алгоритм на основе метки времени использует метку времени для сериализации выполнения параллельных транзакций. Протокол использует системное время или логический счет в качестве отметки времени.