Прозорість — це досить поширене поняття незалежності даних у розподілених системах, яке передбачає, що користувач у цій системі працює з розподіленою базою даних як з логічно цілісною сукупністю даних, тобто на його роботу не повинно впливати те, як дані розподілені між вузлами мережі. Отже, в розподіленій системі користувачеві надається логічно цілісне подання фізично розподіленої бази даних.
Основною задачею розподіленої СУБД є забезпечення управління доступом до даних багатьох споживачів і цілісності й узгодженості даних в умовах використання мережі комп’ютерів.
Тобто основна функція таких СУБД – це координування спільної роботи багатьох користувачів з розподіленою інформацією.
Розв'язання проблеми автономності роботи користувачів розподіленої системи створює багато специфічних проблем в організації баз даних, оскільки різні користувачі можуть працювати паралельно з одними й тими самими даними, виконуючи з ними різні перетворення.
Переваги централізованої стратегії.
Якщо дані зберігаються в одному місці, то значно простіше реалізувати проблему забезпечення цілісності та захисту інформації.
При централізованій стратегії спрощується технологія створення та ведення файлів БД, оскільки можна скористатися єдиними стандартними процедурами та методами ведення і підтримування БД в актуальному стані.
Проектування такої розподіленої бази даних також досить просте порівняно з іншими стратегіями.
Недоліки.
За такої стратегії можуть виникати черги, що призводить до різкого збільшення часу реакції системи.
Крім того, витрачається певний час і на процедури пов'язані з передаванням інформації.
Обсяг бази даних обмежений пам'яттю однієї ЕОМ для зберігання даних.
Ключовим фактором, який впливає на надійність і доступність бази даних, є так звана локалізація посилань.
Якщо база даних розподілена так, що дані, які розміщені в цьому вузлі, викликаються винятково його користувачем, то це свідчить про високий ступінь локалізації посилань.
Якщо подібне розчленування даних здійснити неможливо і для виконання запитів користувача потрібно звертатись за інформацією до інших вузлів, то це свідчить про невисокий ступінь локалізації посилань.
Розглянута стратегія підходить для тих предметних областей, в яких практично немає дублювання даних у різних вузлах мережі і потрібна мінімальна кількість логічних посилань для виконання інформаційних взаємозв'язків вузлів одного з одним. Тобто користувач кожного вузла працює зі своїми файлами і досить рідко використовує дані інших вузлів мережі.
Розглянемо особливості технології роботи з розподіленою базою даних в умовах використання локальної обчислювальної мережі.
Комп'ютерна мережа може мати складну конфігурацію (топологію). Додатково в мережу можуть входити зовнішні пристрої, які використовуються колективно, наприклад сітковий принтер.
блокувати одразу всі ресурси, необхідні для виконання трансакцій;
якщо деякий ресурс не можна захопити, то необхідно відмовитись від виконання трансакції.
Проте ці технології мають суттєву відмінність, яка полягає в тому, що у файл–серверній технології на сервері розміщується лише програмне забезпечення, яке підтримує роботу мережі, та файли бази даних, а все прикладне програмне забезпечення знаходиться на комп'ютерах користувачів, тобто на робочих станціях.
Особливості технології клієнт–сервер полягають у тому, що прикладне програмне забезпечення зберігається не лише на робочій станції, певні його компоненти можуть зберігатися на сервері.
Найбільш популярною зараз є архітектура клієнт–сервер, і більшість сучасних розподілених СУБД орієнтовані саме на цю технологію розподіленої обробки даних.
У системах другого типу (багато-клієнтів/багато-серверів) база даних може розміщуватися на кількох серверах і для виконання запитів користувачів потрібна взаємодія серверів одного з одним. Кожна клієнтська машина має свій сервер і на нього направляє запити користувача – нібито працює з централізованою базою. Взаємодії серверів при виконанні запиту прозорі для користувача. У більшості існуючих СУБД реалізовано один із двох типів архітектури клієнт–сервер.
Наприклад, при паралельному внесенні змін в один і той самий запис один користувач може стерти зміни іншого користувача.
Для вирішення таких колізій використовується блокування або інакше – накладання замків (захватів). Блокування виконуються за правилами сумісності блокувань, що виключає виникнення конфліктів типу читання–запис, запис–читання або запис–запис. Існують три методи блокування: централізоване блокування, блокування первинної копії і розподілене блокування .
Недоліки:
По-перше, недостатня надійність, яка при відмові чи недоступності центрального вузла блокувань може призвести до виходу з ладу всієї системи.
По-друге, центральний вузол може стати вузьким місцем у системі через великі обсяги обробки даних на ньому і через генерованість навколо нього інтенсивного трафіку мережі.
Загальний побічний ефект усіх розглянутих алгоритмів управління паралельним доступом за допомогою блокувань – це можливість виникнення тупікових ситуацій. Тупік, глухий кут – це така ситуація, коло багато запитів створюють цикл, очікуючи зняття захватів іншими запитами з цієї самої множини. Виявлення та усунення тупиків – це одна з найскладніших задач у розподілених системах.
Трансакція – це певна сукупність операцій над файлами БД, яка поєднує певний набір команд, що змінюють зміст файлів бази даних, але при цьому ці зміни вносять не одразу, а відкладають до закриття трансакції.
Неможливою є проміжна ситуація, щоб при виконанні трансакції частину змін заносили до бази даних, а частину – відміняли.
Для кожної трансакції при її закритті всі зміни заносять до бази даних або відміняють і здійснюють відкат трансакції, тобто повинна виконуватись вимога до атомарності трансакцій – виконання всіх дій або ж невиконання жодної з них.
Другою важливою ознакою трансакції є її довговічність, яка полягає в тому, що коли трансакція зафіксована, то її результат не повинен втратитися навіть в разі зруйнування системи.
Важливою вимогою до трансакцій є так звана їх серіалізація, яка полягає в тому, щоб різні трансакції не мали випадкового впливу одна на одну.
Трансакції також повинні мати властивості ізольованості, тобто результат трансакції не повинен залежати (тобто бути ізольованим) від інших трансакцій, виконуваних паралельно.
Проілюструємо дію цього механізму на прикладі.
Нехай необхідно перевести деяку суму одного розрахункового рахунку в банку на інший. Ця операція складається з двох кроків:
1) зняти суму з одного розрахункового рахунку (модифікація запису 1);
2) добавити суму на другий рахунок (модифікація запису 2).
Зазначимо, що після виконання першого кроку файли бази даних перебуватимуть у неузгодженому стані (рахунки будуть балансуватись на величину суми, знятої з першого рахунку).
При паралельній роботі кількох користувачів такий стан файлу буде помилковим, оскільки інші користувачі бачать файли з неузгодженою інформацією.
Крім того, другий крок операції може завершитися тупиком (наприклад, другий запис 6уде заблокований іншим користувачем) або аварійним збоєм системи.
Апаратний збій між виконанням першого і другого кроків взагалі може призвести до втрати контролю над цілісністю та узгодженістю бази даних.
Спроба розв’язати задачу блокуванням файлів на період виконання операції дуже уповільнить роботу інших користувачів мережі і не зможе забезпечити відновлення файлів у результаті апаратних збоїв системи.
Для підтримання цілісності бази даних при різного роду збоях використовують протоколи журналізації, які вміщують інформацію про всі зміни, які вносяться до бази даних під час виконання трансакції.
В одну трансакцію доцільно об'єднувати операції, які виконують логічно зв'язані між собою зміни файлів бази даних.
У сучасних розподілених СУБД підтримку трансакцій можна виконувати за допомогою двох методів: двофазною фіксацією трансакцій та дублюванням даних.
Ці два методи відрізняються тим, що в першому випадку багато трансакцій працюють одночасно з однією розподіленою базою даних.
У другому випадку кожна трансакція має змогу копіювати необхідні для її виконання дані з розподіленої бази даних і працювати з нею як зі своєю особистою базою даних, модифікувати ці дані, а потім після виконання трансакції повертати їх у розподілену базу даних.
При використанні цього методу трансакцію виконують у два етапи (фази).
Перший етап, (перша фаза), полягає в тому, що на вузлі, де виконуватимуть трансакцію, створюють процес-координатор, а на всіх інших вузлах – процеси-учасники.
Двофазна фіксація трансакцій спирається на такі правила:
Учасники, готові завершити трансакцію, надсилають повідомлення на вузол–координатор про свою готовність до завершення трансакції. Учасники, які не можуть зафіксувати свою частину трансакції, надсилають повідомлення про те, що трансакцію буде перервано.
Координатор, зібравши повідомлення учасників, вирішує долю трансакції згідно з правилами.
Якщо всі учасники надіслали згоду, координатор надсилає повідомлення про глобальну фіксацію трансакції, згідно з яким вносяться зміни на всіх серверах.
При відмові хоча б одного з учасників процес-координатор приймає рішення про припинення виконання трансакції і надсилає повідомлення про глобальне припинення тим учасникам, які надіслали згоду на виконання трансакції.
Тим учасникам, які надіслали відмову на виконання трансакції, повідомлення можна не надсилати, оскільки вони самі в змозі прийняти рішення згідно з правилами двофазної фіксації трансакцій.
Ця ситуація називається одностороннім припиненням виконання трансакції.
В результаті на всіх серверах трансакція завершується однаково (фіксується або переривається).
Протоколом обслуговування трансакцій передбачається обмін повідомленнями між координатором і учасниками двічі, тому цей механізм отримав назву двофазної фіксації трансакцій.
Недоліки двофазної трансакції:
одночасний захват всіх ресурсів може надовго заблокувати доступ до даних;
вихід з ладу під час виконання трансакції того вузла мережі, який заблокував ресурси, призведе до блокування деяких даних усієї мережі доти, поки не буде відновлено його роботу.
Проблеми:
забезпечення коректної поведінки системи в разі виходу з ладу сервера або пошкодження ліній зв’язку. Тому організація розподіленої системи в даному варіанті потребує надійних і швидких ліній зв'язку.
вирішення конфліктів, коли одна трансакція вступає в конфлікт з іншою трансакцією з приводу доступу до певних даних. Тому системи, що базуються на двофазній фіксації трансакцій, повинні мати деякий механізм вирішення конфліктів, пов'язаних з одночасним доступом.
Після успішного завершення трансакції зміни вносять на всі сервери у відповідні файли, які брали участь у виконанні трансакції.
При цьому виникає потреба забезпечити синхронізацію процесу тиражування змін на різних серверах, щоб база даних не втратила своєї цілісності
Можливі два режими тиражування змін: синхронний і асинхронний.
Найпростіший варіант архітектури, який виключає можливість виникнення конфліктів, полягає в тому, що серед усіх вузлів, які зберігають одну і ту саму копію деяких даних, вибирають один, що має право на внесення змін, інші вузли лише мають доступ до цієї копії без права внесення змін. Цей варіант можуть вибрати банк і його філії, коли останнім дозволяється переглянути певні дані головної контори без права внесення змін.
Другим варіантом архітектури, який також гарантує, що конфлікти не виникнуть, є динамічна передача права модифікації від сервера до сервера.
При цій архітектурі кожний елемент даних має спеціальний додатковий атрибут, у якому можна вказати дозвіл на внесення змін при передаванні даних між серверами.
Цей варіант можна проілюструвати на прикладі бази даних торговельної організації. Наприклад, замовлення на товар було виконано, і він надійшов на склад; інформацію про це можна передати на сервер відділу продажу з правом внесення змін у ці дані.
Если не удалось найти и скачать доклад-презентацию, Вы можете заказать его на нашем сайте. Мы постараемся найти нужный Вам материал и отправим по электронной почте. Не стесняйтесь обращаться к нам, если у вас возникли вопросы или пожелания:
Email: Нажмите что бы посмотреть