Лекція 4.
Розподілена обробка даних
Режимы работы с базой данных
Архитектура «клиент-сервер»
Модели «клиент-сервер»
Управление распределенными данными
Режими роботи з базой даних
В залежності від характеру вирішуваних завдань, оброблюваної інформації, використовуваної СУБД, робота з базами даних може бути організована різними способами (рис. 7):
|
|
|
|
Рис. 7. Режимы работы с базами данных [ 4 ]
Якщо з база даних, розміщена автономномно, або входить до складу локальної обчислювальної мережі комп'ютері, і на неї протягом одного або декількох сеансів працює лише одна людина, такий режим називається одно користувальницьким (монопольним).
В рамках послідовного багатокористувацького режиму до бази даних мають доступ кілька людей, які змінюють один одного в процесі роботи.
Паралельні режими роботи з базою даних припускають, що з однієї і тієї ж базою даних одночасно працюють кілька користувачів.
Незважаючи на очевидну простоту розглянутих понять, студенти часто неправильно їх інтерпретують, вважаючи, що сам факт одночасного виконання завдань за допомогою СУБД MS Access під час лабораторних занять на комп'ютерах, включених в локальну обчислювальну мережу, забезпечує паралельний режим роботи. При цьому забувається, що кожен користувач працює зі своєю локальною базою даних, що зберігається під унікальним ім'ям.
Для забезпечення надійної і якісної роботи з базою даних в монопольному і послідовному багатокористувацькому режимах зазвичай не потрібні складні спеціальні методи і технології. Необхідний результат може бути досягнутий за допомогою простих організаційних заходів: регламентації дій і обмеження повноважень окремих користувачів, впровадження детально розроблених інструкцій про характер і послідовності виконуваних дій і т. д.
Монопольний та послідовний багатокористувацький режими в основному застосовуються для роботи з невеликими, локальними базами даних (облік надходження товарів в окремий магазин, рішення нескладного науково-дослідного завдання і т. д.). Якщо база даних призначена для забезпечення діяльності навіть невеликих організацій, фірм, установ, з високим ступенем ймовірності можна чекати, що вона буде експлуатуватися в паралельному режимі.
Для розуміння особливостей паралельного режиму роботи з базою даних попередньо розглянемо фундаментальні поняття клієнт і сервер. Архітектура "клієнт-сервер»
Терміни «клієнт» і «сервер» спочатку застосовувалися для архітектури програмного забезпечення, яке можна було розділити на два обчислювальних процеси. Клієнтський процес запитує деякі послуги у сервера, серверний процес надає ці послуги клієнту. Один сервер може обслуговувати декілька клієнтів.
Надалі, у зв'язку з розвитком обчислювальних мереж, виникла можливість розподілу зазначених завдань між окремими комп'ютерами. Тому в даний час під клієнтом і сервером зазвичай розуміють різні комп'ютери, що виконують ці завдання. На думку К. Дж. Дейта, таке розуміння термінів «клієнт» і «сервер» є недбалим, але дуже поширеним [2].
З позицій теорії баз даних сервер - це власне СУБД. Сервер забезпечує зберігання і обробку даних, їх захист і цілісність і т.д.
Клієнти являють собою різні додатки, виконувані «над» СУБД. Вони можуть бути написані безпосередньо користувачами в процесі роботи з базою даних на одній з мов програмування (С + +, Pascal і т.д.) або бути вбудованими додатками, що поставляються виробниками СУБД або іншими організаціями (процесори мов запитів, генератори звітів і додатків, графічні бізнес-системи і т. д.) [2].
Виходячи з розглянутих положень, архітектуру «клієнт-сервер» можна представити в наступному загальному вигляді [2]:
|
|
|
|
Пользователи
|
|
|
|
Клиенты
|
|
|
|
Сервер
|
|
|
|
База данных
Рис. 8. Архитектура «клиент-сервер» [ 2 ]
Архітектура "клієнт-сервер» має ряд переваг:
БД може використовуватися одночасно декількома клієнтами.
Робота з даними клієнтом і сервером виконується паралельно. В результаті процес обробки даних істотно прискорюється.
Комп'ютер сервера може мати великі обчислювальні можливості, що забезпечує високу продуктивність системи.
Комп'ютер клієнта можна адаптувати до вимог конкретного кінцевого користувача.
Грунтуючись на архітектурі «клієнт-сервер», розглянемо особливості режимів роботи з централізованою і розподіленою базами даних.
Централізована база даних
Централізоване зберігання баз даних застосовується вже кілька десятиліть. База даних зберігається на зовнішніх пристроях центральної ЕОМ, що працює під управлінням багатозадачної операційної системи. Користувачі звертаються до бази даних з віддалених терміналів, часто не мають власних обчислювальних ресурсів - процесора і пам'яті (рис. 9):
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
||
Пользователи
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
Клиенты
|
|
|
|
Сервер
База данных
Рис. 9. Централизованная база данных
Достоїнствами цього режиму є простота експлуатації системи та її відносна дешевизна. Недоліки - велика залежність від якості роботи центрального вузла і підвищені вимоги до його продуктивності. Система паралельного доступу до бази даних, розташованої на одному комп'ютері, декількох користувачів називається системою розподіленого опрацювання даних.
Розподілена база даних
В рамках цього режиму окремі частини бази даних розподіляються між різними комп'ютерами. При цьому доступ до даних на будь-якому комп'ютері підтримується всіма клієнтами через телекомунікаційну обчислювальну мережу (рис. 10):
|
Пользователи |
|
Пользователи |
|
|
|
|
|
|
|
|
Клиенты |
|
Клиенты |
|
|
|
|
|
|
|
Сервер Сервер
|
База данных (часть 1) |
|
База данных (часть 2) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Пользователь
|
|
|
|
База данных
(часть
3)
Клиенты
Сервер
|
|
|
|
Рис. 10. Распределенная база данных [ 2 ]
У кожному вузлі системи функціонують власні СУБД і програмне забезпечення. Отже, розподілену СУБД можна інтерпретувати як спосіб організації спільної роботи окремих локальних СУБД, розташованих в різних вузлах. При цьому СУБД кожного вузла повинна мати засоби, що забезпечують користувачам і додаткам можливість роботи з усією базою даних.
Класифікують гомогенні і гетерогенні розподілені бази даних [12]. В гомогенних розподілених базах даних у вузлах системи використовуються СУБД одного типу, в гетерогенних - різних типів.
Раціонально зберігати в кожному вузлі системи частину бази даних, логічно пов'язану з цим вузлом. Наприклад, база даних, створена для великого виробничого об'єднання, може складатися з фрагментів, кожен з яких містить інформацію про роботу окремого підрозділу, цеху і т. д.
При такій організації робіт збільшується продуктивність обробки інформації, так як відомості, необхідні для забезпечення діяльності підрозділу чи філії підприємства, які добувають із бази даних найбільш часто, зберігаються у зв'язаному з ним вузлі системи. Це дозволяє економити ресурси, оскільки звернення за даними до віддалених вузлів відбувається значно рідше. Ліквідується залежність від центрального вузла - при збої в окремому вузлі системи цілісність більшої частини бази даних зберігається.
При роботі з розподіленою базою даних кожен комп'ютер є клієнтом для одних комп'ютерів і сервером для інших. Клієнт може отримати доступ до будь-якої кількості серверів. Цей доступ може бути одночасним до декількох серверів або реалізовуватися послідовно від сервера до сервера.
Оптимальною є така організація роботи, коли від виконуваного застосування приховані механізми функціонування системи і створюється враження, що обробка даних здійснюється однією СУБД, працюючої на одному комп'ютері. Користувачі і додатки повинні отримувати доступ до необхідних їм даним, не маючи інформації про місце розташування цих даних.
Система розподілу бази даних по декількох комп'ютерах, розташованих в мережі, із забезпеченням можливості паралельного доступу до неї декількох користувачів, називається системою розподілених баз даних.
При використанні в роботі архітектури «клієнт-сервер» часто необхідно вирішувати проблему уніфікованого доступу до даних, створеним різними СУБД. Ця проблема вирішується за допомогою стандартного інтерфейсу ODBC (Open Database Connectivity).
На комп'ютері клієнті повинна бути встановлена операційна система з інтерфейсом ODBC. СУБД або додаток, які звертаються до даних, створеним в іншому середовищі, отримують до них доступ за допомогою виклику на мові SQL стандартних функцій інтерфейсу ODBC. При цьому підключається необхідний драйвер, відповідний формату даних СУБД [15].
Моделі «клієнт-сервер» Технології роботи з базами даних передбачають виконання таких основних функцій: 1. Введення та відображення даних. 2. Рішення прикладних задач. 3. Управління інформаційними ресурсами (реалізується СУБД).
В залежності від розподілу перерахованих функцій між клієнтом і сервером виділяють кілька різних моделей «клієнт-сервер».
Модель віддаленого управління даними (файлового сервера File Server, FS) У цій моделі всі основні функції, включаючи управління інформаційними ресурсами, виконуються клієнтом, сервер забезпечує тільки доступ до файлів бази даних (рис. 11):
Клиент Сервер База данных
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
Файловые команды
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Блоки данных
Рис. 11. Модель файлового сервера
У ситуаціях, коли додатку необхідні дані для вирішення виконуваного ним завдання, воно звертається із запитом до системи управління базами даних. СУБД переводить надійшовший запит в файлові команди. Система управління файлами згідно з цими командами витягує з бази даних блоки інформації і передає їх для обробки клієнтові. Якщо в отриманому блоці даних немає потрібних для додатка відомостей, розглянута процедура повторюється до тих пір, поки проблема не буде вирішена.
Модель файлового сервера може бути реалізована за допомогою мережевої (призначеної для роботи в локальній обчислювальній мережі, ЛВС) або немережевої СУБД.
Коли комп'ютер не підключений до мережі, процес обробки бази даних не відрізняється від звичайного режиму роботи на автономному комп'ютері. При роботі в ЛВС з немережевою СУБД, клієнтові (в даній ситуації робочої станції) з сервера передаються один або декілька файлів бази даних для їх подальшої обробки. По закінченні роботи файли бази даних повертаються на сервер для узгодження зберігаємої в них інформації. Очевидно, що при спільній роботі з базою даних декількох користувачів можливе порушення цілісності даних [15].
При використанні мережевих СУБД безпосередньо їх засобами здійснюється контроль над не протиріччям змін в базі даних. Це досягається застосуванням механізму блокувань, що обмежує можливості доступу користувачів до об'єктів бази даних (див. п. 4.4).
Основний недолік моделі файлового сервера полягає у великому обсязі даних, переданих по телекомунікаційній обчислювальної мережі. При цьому частка інформації, необхідної для роботи програми, в цьому обсязі може бути досить незначною.
Незважаючи на зазначені недоліки, модель файлового сервера покладена в основу архітектури більшості настільних СУБД: MS Access, Paradox, FoxPro і т. д.
Модель віддаленого доступу до даних (Remote Data Access, RDA)
У цій моделі функції СУБД та вибірки даних реалізуються сервером, клієнт виконує операції введення і відображення даних і вирішує прикладні задачі (рис. 12):
Клиент Сервер База данных
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
SQL запросы
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
||
Результаты запросов
Рис. 12. Модель удаленного доступа
У процесі роботи клієнт звертається до сервера із запитами на мові SQL (Structured Query Language - мова структурованих запитів). Відповіді на ці запити являють собою не блоки даних великого об'єму, що часто включають зайву інформацію, а конкретні дані, необхідні додатку для розв'язання прикладної задачі.
У моделі віддаленого доступу до даних обсяги інформації, що передаються по мережі, істотно менші, ніж у моделі файлового сервера. Тим не менше вони можуть залишатися досить значними.
Іншими недоліками розглянутої моделі є складність розробки, модернізації та обслуговування системи, а також відносна пасивність сервера [4].
Модель сервера баз даних (DataBase Server, DBS)
У цій моделі, на відміну від моделі віддаленого доступу до даних, клієнт виконує тільки функції введення і відображення даних, прикладні функції реалізуються сервером за допомогою збережених процедур (див. рис. 13):
Клиент Сервер База данных
|
Вызов
|
хранимых процедур
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Результаты выполнения процедур
Рис. 13. Модель сервера баз данных
Збережені процедури являють собою програми, які зберігаються в базі даних (зазвичай в її словнику) і управляються СУБД. Одна процедура може бути затребувана декількома клієнтами. У процесі роботи клієнт звертається до сервера, викликаючи необхідну процедуру. Сервер виконує процедуру і фіксує всі виниклі при цьому зміни в базі даних, а також повертає клієнту отримані результати. Така технологія суттєво зменшує обсяг інформації, переданої між клієнтом і сервером. У розглянутій моделі сервер є активним, через механізм тригерів (дій, що виконуються автоматично при виникненні певних подій чи ситуацій в БД) він може самостійно ініціювати обробку інформації в базі даних [4].
Модель сервера баз даних застосовується в СУБД MS SQL Server, Oracle, Informix, Ingress і т. д.
Основними недоліками даної моделі є велике завантаження сервера і залежність збережених процедур від СУБД, для якої вони розроблені.
Модель сервера додатків (Application Server, AS)
Ця модель дозволяє зменшити навантаження на сервер. На відміну від розглянутих дворівневих моделей вона є трирівневою (рис. 14):
Клиент Сервер приложений Сервер БД База данных
Запуск
|
|
|
процедур
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|||||
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
Результаты выполнения процедур
Рис. 14. Модель сервера приложений
Сервер додатків надає деякі загальні послуги клієнтам. Сервер баз даних забезпечує виконання тільки безпосередніх функцій СУБД: створення, ведення, зберігання, підтримки цілісності баз даних і т. д.
Достоїнствами моделі сервера додатків є її гнучкість і універсальність. Основний недолік - високі витрати ресурсів серверів.
В якості прикладів програм, що підтримують роботу серверів додатків, можна навести BEA WebLogic Server, Inprise Application Server і IBM WebSphere Application Server [15].
Управління розподіленими даними
При роботі з розподіленими базами даних необхідно вирішувати дві проблеми: 1) збереження узгодженості БД при одночасних змінах збережених даних в декількох вузлах системи; 2) забезпечення спільного доступу декількох користувачів до загальної інформації.
Для організації розподіленої бази даних можуть бути використані дві стратегії.
Фрагментація БД
У рамках цієї стратегії база даних ділиться на фрагменти, які розміщуються в різних вузлах системи. У повністю фрагментованої системи дані не повинні дублюватися (на практиці реалізувати цю вимогу практично неможливо). Відомості про місце розташування та інших характеристиках кожного фрагмента зберігаються в глобальному словнику даних, який може розподілятися між декількома вузлами або міститися тільки в одному з них.
Достоїнствами фрагментації БД є економне використання зовнішньої пам'яті (зменшується дублювання інформації) і постійне підтримання бази даних в актуальному стані. Недолік - високі вимоги до пропускної здатності і надійності каналів зв'язку, по яких практично безперервно передаються команди і дані.
Реплікація (тиражування) БД
Ця стратегія допускає зберігання однакових даних у декількох вузлах системи. В ідеальній розподіленій базі даних такого дублювання інформації не повинно бути, тим не менше на практиці воно використовується досить часто для забезпечення вимог продуктивності, доступності та безпеки. Реплікація є обгрунтованою, наприклад, якщо одні й ті ж дані регулярно використовуються в різних вузлах.
Кожна копія даних обробляється (в тому числі і змінюється) користувачами автономно, незалежно один від одного. Ідентичність копій забезпечується передачею зроблених змін між вузлами за допомогою компонента системи, званого реплікатором. Передача змін виконується асинхронно, тому аналогічні дані, що зберігаються в різних вузлах, деякий час можуть різнитися між собою (це є основним недоліком методу). Інший недолік - великі витрати зовнішньої пам'яті для зберігання інформації.
У порівнянні зі стратегією фрагментації БД, реплікація забезпечує більш високу швидкість звернення користувачів до даних; зменшення обсягу інформації, що передається по мережі; меншу залежність якості роботи системи від використовуваних каналів зв'язку.
Відомості про місце розташування та інші характеристики кожного об'єкта розподіленої бази даних зберігаються в глобальному словнику даних (каталозі). Зберігання глобального словника даних і управління ним можуть реалізовуватися різними способами [2, 12]:
Повністю розподілений підхід - в кожному вузлі системи міститься частина глобального каталогу, що характеризує тільки об'єкти бази даних, що зберігаються в цьому вузлі. Робота системи не залежить від деякого центру управління, при необхідності доступу з одного вузла до даними, розміщеним у іншому вузлі, потрібно перегляд всіх локальних каталогів, поки не буде знайдена необхідна інформація.
Повністю реплікований підхід - повна копія глобального каталогу даних зберігається в кожному вузлі системи. При цьому прискорюється пошук потрібних даних, але при зміні об'єкта бази даних в одному вузлі потрібне оновлення каталогів, що зберігаються у всіх вузлах.
Централізований підхід - глобальний каталог даних зберігається тільки в одному вузлі системи. Забезпечення роботи системи вимагає більш простих засобів, ніж при реалізації інших підходів, але якість роботи системи багато в чому залежить від надійності функціонування вузла, в якому знаходиться каталог. Крім того, цей підхід висуває підвищені вимоги до ресурсів системи.
Комбінований підхід - в кожному вузлі системи міститься локальний каталог, що включає відомості про частини бази даних, розміщеної в цьому вузлі, в одному з вузлів зберігається і глобальний каталог даних. Цей підхід ефективніший, ніж централізований, але також вимагає високої надійності роботи вузла, в якому зберігається глобальний каталог даних.
На практиці перераховані підходи не використовуються, в основному застосовується метод перманентних ідентифікаторів [2, 12]. Ідея методу полягає в тому, що кожен об'єкт бази даних має логічне ім'я (на яке при роботі посилаються користувачі) і системне ім'я, яке включає ідентифікатори вузла, в якому був створений об'єкт, і вузла, в якому в даний час зберігається об'єкт. Після створення об'єкта його системне ім'я заноситься в каталоги даних всіх інших вузлів.
У каталозі кожного вузла зберігаються відомості про кожен об'єкт, створений або доглянутий в цьому вузлі. Переміщення об'єкта бази даних між вузлами відстежуються локальним каталогом вузла, в якому був створений об'єкт. Якщо якому-небудь вузлу системи необхідний цей об'єкт, він попередньо звертається до вузла, де об'єкт був створений, і визначає по каталогу цього вузла нове місце зберігання об'єкта.
При спільній роботі декількох користувачів із загальною інформацією можуть застосовуватися монопольний і колективний методи доступу до розподілених даних.
Монопольний доступ організовується за допомогою повних блокувань, реалізованих безпосередньо СУБД або прикладними програмами. Монопольний доступ до даних зазвичай застосовується при роботі з конфіденційною інформацією або при виконанні фундаментальних перетворень БД (наприклад, зміни її структури), коли потрібно повністю виключити роботу з даними інших користувачів [15].
У режимі колективного доступу до даних повне блокування не допускається. Застосовується механізм тимчасових блокувань, що обмежують або забороняють роботу користувача або додатки з об'єктами бази даних, коли ці об'єкти використовуються іншими користувачем або додатком.
Наприклад, якщо реплікувані дані змінюються в одному вузлі системи, в інших вузлах вони блокуються. Після фіксації зроблених оновлень у вузлі, де вони були виконані, інші вузли намагаються змінити свої репліковані дані і зафіксувати отримані результати. Дані у вихідному вузлі залишаються заблокованими до тих пір, поки оновлення не будуть зафіксовані у всіх вузлах. Якщо в одному або декількох вузлах реалізувати поновлення даних не вдалося, проводиться відміна (відкат) виконаних дій в масштабах всієї системи.
Розширенням розглянутої технології є метод двофазної фіксації транзакцій (поняття транзакції буде розглянуто в п. 5) [15].
На першому етапі реєструються всі зміни, що відбуваються в окремих вузлах системи. При цьому тимчасово зберігається можливість їх скасування. Інформація про зроблені зміни пересилається керуючому компоненту системи, контролюючому даний процес.
На другому етапі, після отримання від усіх вузлів системи підтвердження про правильність і несуперечність виконаних операцій, керуючий компонент системи передає всім вузлам команду остаточно зафіксувати зроблені зміни.