Навігація
Головна
 
Головна arrow Інформатика arrow Бази даних
< Попередня   ЗМІСТ   Наступна >

Одночасний доступ

Особливістю РБД є багатокористувацький розподілений доступ до даних [11].

Складність її для РБД складається н тому, що механізм управління в одному вузлі не може в загальному випадку знати в кожен момент часу про взаємодію з іншими вузлами. До того ж у вузлах можуть знаходитися і копії даних інших локальних БД.

Взаємодія елементів в РБД раніше здійснюється за допомогою транзакції, яка стає розподіленої (рис. 12.4) і, впливаючи на цілісну БД, після свого завершення залишає БД цілісною. У транзакції виділяють дві команди: читати (R) і писати-оновлювати (W).

Тут як і раніше справедливі ті ж поняття, що використовуються в централізованих БД: синхронізація, розклад, послідовно-подібне розклад (ППР), конфлікт, рестарт. Нагадаємо, що дві транзакції вступають у конфлікт, якщо вони працюють з одним і тим же загальним елементом даних і принаймні одна з них реалізується операцією "писати" (запис).

У СУРБД в кожному вузлі ведеться свій розклад. Вектор розкладів всіх вузлів назвемо розподіленим розкладом (РР).

Розподілена модель транзакції

Рис. 12.4. Розподілена модель транзакції:

Ti - субтранзакціі; I - породжують транзакції; 2 - передача даних

Послідовне РР (ПРР) - це РР, в якому кожна складова послідовна. Послідовно-подібне РР (ППРР) еквівалентно ПРР.

Існує кілька методів синхронізації.

  • 1. Блокування, яка може бути: а) з головним вузлом; б) із завданням блокування за допомогою предикатів; в) з головною копією.
  • 2. Голосування по більшості.
  • 3. Метод попереднього аналізу конфліктів.

Блокування

1. Виділений вузол стає пріоритетним і управляє іншими вузлами як в централізованій БД. Відомо, що блокування в централізованій БД передбачає монопольний режим для запису і колективний режим для читання. Ці режими використовуються і в блокуванні з головним вузлом, який керує процесом синхронізації.

Застосовують двох- і трифазну транзакції. У двофазної транзакції виділяють:

  • • розширення (блокування ресурсу);
  • • стиск (повернення ресурсу та розблокування).

Тільки головний вузол видає запит на блокування, який проходить по всій мережі.

Дії по зміні даних допускаються тільки над попередньо заблокованими даними, при цьому спочатку має бути проведено оновлення всіх копій. У такому режимі можливі тупики, які можуть усуватися зняттям "молодших" (пізніше надійшли) транзакцій.

2. Будь кортеж t відносини г зі схемою R, для якого предикат P (t) = true, не може бути вставлений в R, видалений або змінений інший транзакцією до зняття блокування.

Двофазна блокування працює тут наступним чином.

У фазі розширення (підготовки) транзакція повинна зажадати предикат-блокування. Вузол-координатор веде таблицю блокувань. Блокування здійснюється, якщо вона не вступає в конфлікт з іншими блокуваннями. В іншому випадку транзакція переводиться в режим очікування або їй дозволяється здійснити перехоплення ресурсу.

У фазі стиснення (розблокування) здійснюється видалення рядки з таблиці блокувань: перша ж розблокування говорить про початок фази стиснення.

Встановлення факту конфлікту тут як і раніше проблематично: показано, що в загальному випадку проблема рекурсивно нерозв'язна.

Процедура встановлення факту конфлікту визначена математично для предикатів виду [атрибут] F [константа], де в якості F використовуються операції з безлічі (<, =,>, ¹).

Тупикові ситуації можуть бути усунені в трифазній транзакції (блокування, виконання, розблокування).

Блокування з головним вузлом і з використанням предикатів зводяться до централізації процедури синхронізації. У цьому випадку продуктивність БД обмежена можливостями своєрідного центру.

У світлі сказаного подальший розвиток синхронізації пішло в напрямку децентралізації.

3. У даному випадку для будь-якого елементу даних одна копія є головною, яку і блокує транзакція в кожному вузлі. Очевидно, що мається надмірність інформації і жоден вузол не є головним (децентралізоване управління).

Голосування по більшості

У загальному випадку передбачається надмірність РБД: в будь-якому вузлі є копія будь-якого елементу.

Транзакція виконується лише в одному вузлі:

  • • команда читання у своєму вузлі працює без блокувань і синхронізації;
  • • Під час запису ім'я елемента і його нове значення заноситься в список оновлення.

Після завершення транзакції список розноситься по всіх вузлах і вузол голосує за цей список (рис. 12.5).

Алгоритм голосування по більшості

Рис. 12.5. Алгоритм голосування по більшості:

А - конфлікт є; Б - поточна транзакція отримує більшу временною мітку, ніж очікує транзакція; BP, ТР - тимчасове мітки останньої зміни і поточної транзакції

Якщо більшість - "за", транзакція приймається і оновлення проводиться в усіх вузлах.

Вузол голосує "за", якщо:

  • 1) елемент даних, прочитаних транзакцією, не був змінений після читання;
  • 2) транзакція Т не конфліктує з іншого транзакцією Τ ', яка очікує рішення (якщо даний вузол проголосував "за", але T' еше не була прийнята або загалом відкинута) в даному вузлі.

У позиції 1 використовуються тимчасові мітки (мітки часу). Мітка присвоюється транзакції і кожному елементу даних (останньої транзакції, яка його оновила).

Коли вузол приймає список оновлення, він порівнює тимчасові мітки і визначає виконання умов I і 2. Якщо умова 1 не виконується, вузол відкидає транзакцію, яка рестарту (рис. 12.5). Якщо умова 1 задовольняється, а 2 - ні, то вузол не може голосувати "за" цю транзакцію, яка очікує рішення, поки його не отримає. При виконанні обох умов вузол голосує "за".

Оскільки різні вузли отримують списки поновлення в різному порядку, вони і голосують в різному порядку, що може призводити до тупикам. Щоб їх уникнути, вузол голосує "проти", якщо умова 1 виконується, а 2 - немає і транзакція отримує більшу часову мітку (мітку часу), ніж очікує транзакція.

Метод попереднього аналізу конфліктів

Дотепер синхронізувалися всі конфліктуючі операції запису і читання. Однак не всі конфлікти можуть знищити послідовно подобу.

Визначаються конфлікти, які дійсно вимагають синхронізації. Для цього виділяють класи, які визначаються множинами записів і читання транзакцій. Транзакція відноситься до даного класу, якщо множини читання і запису її належать цьому класу. З будь-яким класом пов'язаний модуль транзакції (МТ) - компонента СУРБД, яка послідовно виконує транзакції з цього класу. Тоді можуть конфліктувати тільки транзакції різних класів, і їх потрібно синхронізувати. Конфлікт класів моделюється графом конфліктів (рис. 12.6), вершини якого відповідають множинам читання і запису класу, а ребра являють собою конфлікти. Транзакції, що не входять в цикл, завжди послідовно подібні і не вимагають синхронізації.

Граф конфліктів створюється і аналізується статично, коли визначені БД і класи. Класи, що не входять в цикл, позначаються як МТ і їм повідомляється про непотрібність синхронізації.

Решта МТ повинні синхронізувати свої транзакції.

Граф конфліктів

Рис. 12.6. Граф конфліктів

 
Якщо Ви помітили помилку в тексті позначте слово та натисніть Shift + Enter
< Попередня   ЗМІСТ   Наступна >
 
Дисципліни
Агропромисловість
Аудит та Бухоблік
Банківська справа
БЖД
Географія
Документознавство
Екологія
Економіка
Етика та Естетика
Журналістика
Інвестування
Інформатика
Історія
Культурологія
Література
Логіка
Логістика
Маркетинг
Медицина
Нерухомість
Менеджмент
Педагогіка
Політологія
Політекономія
Право
Природознавство
Психологія
Релігієзнавство
Риторика
Соціологія
Статистика
Техніка
Страхова справа
Товарознавство
Туризм
Філософія
Фінанси
Пошук