Введення
Загальна тенденція розвитку систем управління базами даних показує, що розподілені системи отримують все більший розвиток і поширення. Цьому сприяє як світова глобалізація, яка призводить до прискорення процесів централізації і децентралізації інформаційних систем, так і технічний прогрес в галузі збереження і передачі даних. Зростають обсяги і швидкодію накопичувачів інформації. Все більшою стає частка оптоволоконних каналів зв'язку, які дозволяють передавати величезні масиви даних з небаченою досі швидкістю. Крім того, шириться випуск персональних домашніх комп'ютерів і ноутбуків. Все це вкупі з прогресуючим зниженням вартості комунікаційних послуг веде до зростання кількості віддалених робочих груп (офісів), а також розширенню числа працівників, які виконують свої функції поза свого офісу або основного робочого місця. Ці фактори і сприяють розвитку розподілених систем і, відповідно, розподілених баз даних.
Розподілені бази даних
На загальну думку, Росія та інші країни СНД, володіючи великою територією, просто приречені на створення і розвиток інформаційних систем на основі розподілених баз даних. Не секрет, що практично всі процвітаючі середні і великі регіональні компанії мають свої представництва в Москві та / або Петербурзі. Тому при управлінні такими підприємствами не обійтися без складних корпоративних розподілених інформаційних систем. Яскравим прикладом розподіленої бази даних є система DNS:
Практика показує, що зазвичай вирішення питання створення корпоративної ІС шукається у вже досить освоєної і всім знайомою площині клієнт-сервер на базі локальної мережі з централізованою базою даних.
Обирається одна з популярних багатокористувацьких СУБД і доступні засоби для швидкої розробки додатків (як правило, це пара Interbase / Delphi). Створюється система, що включає в себе одну або декілька баз даних, а також набір звертаються до неї (до них) додатків, що реалізують прикладні функції, необхідні кінцевому користувачеві. Дана технологія дуже непогано працює в обмеженому масштабі, наприклад, в рамках одного офісу або декількох віддалених робочих груп-філій, пов'язаних з головним підприємством. Проте час не стоїть на місці, компанія розширюється і виходить на той рівень, коли нові завдання вимагають децентралізації зберігання та обробки даних і, відповідно, якісного стрибка в розвитку інформаційної системи. У цьому випадку технологія клієнт-сервер, реалізована на основі централізованої бази даних, вже не може задовольнити нових потреб. Інформаційна система стає непрацездатною і її доводиться фактично створювати заново. Очевидно, що звичайні системи "клієнт-сервер" можуть розвиватися тільки по еволюційному екстенсивному шляху в обмеженому масштабі і стають неефективними, коли екстенсивних шляхів розвитку вичерпують свої можливості. Витрати на модифікацію і супровід такої системи в критичний момент стають порівнянними з витратами на створення нової системи. Виходом з глухого кута може бути застосування розподілених баз даних (БД).
У залежності від архітектури, можна виділити локальні та розподілені БД. Всі частини локальної БД розміщуються на одному комп'ютері, а розподіленої - на кількох. Історично, розвиток баз даних, як локальних, так і розподілених, йшло від ієрархічних моделей до мережевих і реляційною.
Перші ієрархічні та мережні СУБД були створені на початку 60-х років минулого століття. Причиною послужила необхідність управління великою кількістю записів, пов'язаних один з одним, як правило, ієрархічним чином (обслуговування виборів, переписів населення, моделювання ядерних випробувань, погодних та геологічних явищ, інформаційне забезпечення космічних польотів і т. д.). Причиною вибору ієрархічної моделі багато в чому стало її подобу що вже були і добре відпрацьованим і освоєним на практиці численним масивів інформації на неелектронних носіях (банки даних, картотеки, досьє, довідники). Серед реалізованих на практиці СУБД цього типу слід відзначити системи IMS (Information Management System) компанії IBM, а також TDMS (Time-Shared Date Management System) компанії Development Corporation; Mark IV Multi - Access Retrieval System компанії Control Data Corporation; System - 2000 розробки SAS-Institute.
Відносини в ієрархічній моделі даних організовані у вигляді сукупностей дерев, де дерево - структура даних, в якій тип сегмента нащадка пов'язаний тільки з одним типом сегмента предка (рис. 1.1).
Рис. 1.1. Ієрархічна модель БД
У термінології баз даних, це адекватно наявності жорстких зв'язків «один - до - одного» або «один - до - багатьох» між записами. До недоліків і обмежень ієрархічної моделі даних можна віднести: відсутність явного поділу логічних і фізичних характеристик моделі, що виражається в жорсткій прив'язці БД до носія-інформації, потреба в додаткових витратах і хитрощах для опису неієрархічних зв'язків, що обумовлює низьку гнучкість моделі, що не дозволяє їй еволюціонувати в умовах, що змінюються.
Мережева модель даних - це подання мережевими структурами типу запис даних, пов'язаних відносинами «один - до - одного» або «один - до - багатьох» (рис. 1.2). Основна ідеологія і стандартні вимоги до цієї моделі були розроблені комітетом Database Task Group (DTBG) на рубежі 60-70-х років. Вперше мережева архітектура була реалізована в СУБД Integrated Data Store (IDS) компанії General Electric і IDMS компанії Computer Associates.
Рис. 1.2. Мережева модель БД
На відміну від ієрархічної моделі, в мережевій допускається наявність декількох зв'язків від сегмента-нащадка до сегментів-предкам.
Мережева модель допускає також використання в базах даних зв'язків «багато - до - багатьох». Це дозволяє усунути багато недоліків ієрархічної моделі, такі як: низьку пристосованість до опису даних неієрархічному структури і слабку гнучкість при розвитку системи.
Реляційна модель була описана в 1970-1971 роках у роботах Є. Ф. Кодда. Вона заснована на процедурному мовою обробки таблиць даних і мовою запитів. У мережевої та ієрархічної моделях використовувалися жорсткі фізичні підходи до зв'язування записів з різних файлів шляхом застосування фізичних покажчиків або адреси на диску. Такі бази істотно ускладнюють і обмежують операції над даними. Крім того, є очевидним, що ієрархічні і мережеві бази даних вельми чутливі до апаратних змін. Перенесення даних з одного накопичувача на інший, або взагалі Зміна числа призводить до необхідності уважно і ретельно змінювати адреси у зв'язках записів на нові. Також такі моделі чутливі до реструктуризації самої бази (додавання або видалення нових полів призводить до зміни фізичних адрес записів). Всі ці проблеми подолала реляційна модель, заснована на логічних відносинах даних. Саме реляційна модель породила всі сучасні відомі СУБД, її дітищем є SQL, завдяки використанню реляційної моделі можливе створення розподілених баз даних.
Під розподіленої БД (Distributed DataBase - DDB) зазвичай мають на увазі базу даних, що включає фрагменти з декількох баз даних, які розташовуються на різних вузлах мережі комп'ютерів, і, можливо, управляються різними СУБД. Розподілена база даних виглядає з точки зору користувачів і прикладних програм як звичайна локальна база даних. У цьому сенсі слово «розподілена» відображає спосіб організації бази даних, але не її зовнішню характеристику.
Згідно з принципами, викладеними в працях відомого вченого Дейта, можна виділити:
12 основних вимог до розподіленої базі даних (вони ж є основними ознаками)
* Локальна автономія (local autonomy);
* Децентралізація (no reliance on central site);
* Безперервність операцій (continuous operation);
* Прозорість розташування (location independence);
* Незалежна фрагментація (fragmentation independence);
* Незалежне тиражування (replication independence);
* Обробка розподілених запитів (distributed query processing);
* Обробка розподілених транзакцій (distributed transaction processing);
* Незалежність від устаткування (hardware independence);
* Незалежність від операційних систем (operationg system independence);
* Прозорість мережі (network independence);
* Незалежність від СУБД (database independence).
Розглянемо кожне з цих вимог докладніше.
Локальна автономія
Це якість означає, що управління даними на кожному з вузлів розподіленої системи виконується локально. База даних, розташована на одному з вузлів, є невід'ємним компонентом розподіленої системи. Будучи фрагментом загального простору даних, вона, в той же час, функціонує як повноцінна локальна база даних. Управління нею виконується локально і незалежно від інших вузлів системи.
Децентралізація
Випливає з властивості локальної автономії. В ідеальній системі всі вузли рівноправні і незалежні, а розташовані на них бази є рівноправними постачальниками інформації в загальний простір даних. База даних на кожному з вузлів самодостатня і може функціонувати при відсутності інших вузлів. Вона включає власний повний словник даних і повністю захищена від несанкціонованого доступу.
У розподілених БД підтримка цілісності та узгодженості даних, в світлі попередніх вимог, являє собою досить складну проблему. Синхронне і узгоджене зміна даних в декількох локальних БД, складових розподілену базу даних, досягається, як правило, застосуванням протоколу двофазної фіксації транзакцій. Крім узгодження та верифікації даних, цей протокол може виконувати захист від збоїв в системі в критичних випадках (обрив зв'язку, наприклад). Якщо розподілена БД однорідна - т. Е. на всіх вузлах дані зберігаються у форматі однієї бази і на всіх вузлах функціонує одна і та ж СУБД, то використовується механізм двофазної фіксації транзакцій для конкретної СУБД. У разі ж неоднорідності розподіленої БД, для забезпечення узгоджених змін в декількох базах даних, використовують менеджери розподілених транзакцій. Це, однак, можливо, якщо учасники обробки розподіленої транзакції (СУБД, що функціонують на вузлах системи), підтримують ХА-інтерфейс, визначений у специфікації DTP консорціуму Х / Ореn. ХА - інтерфейс мають, наприклад, Informix, Microsoft SQL Server, Oracle, Sybase, CA-Openlngres.
Якщо в розподіленій БД передбачено тиражування (реплікація) даних, то це відразу пред'являє додаткові жорсткі вимоги до дисципліни підтримки цілісності даних на вузлах, куди спрямовані тиражовані потоки. Проблема полягає в тому, що зміни в даних можуть ініціюватися як локально - на даному сайті, так і ззовні, за допомогою тиражування. Неминуче виникають конфлікти щодо змін, які необхідно відстежувати і вирішувати.
Безперервність операцій
Це якість можна трактувати як можливість безперервного доступу (формат 24x7 - доступ 24 години на добу 7 днів на тиждень) у рамках розподіленої БД до даних незалежно від їх розташування та операцій, які виконуються на локальних вузлах. Одним словом, дані доступні завжди, а операції над ними можуть виконуватися безперервно.
Прозорість розташування
Це властивість означає повну прозорість розташування даних. Користувач, який звертається до розподіленої БД, нічого не повинен знати про реальний (фізичному) розміщення даних у вузлах інформаційної системи. Всі операції над даними виконуються без урахування їх місцезнаходження. Передача та обробка запитів до баз даних здійснюється вбудованими системними засобами.
Прозорість розташування в реальних продуктах повинна підтримуватися відповідними механізмами, реалізованими в рамках конкретної СУБД чи проекту в цілому. При цьому розробники СУБД дотримуються різних підходів. Типовим рішенням даної задачі є використання так званих синонімів (Alias) баз даних.
Незалежна фрагментація
Це властивість трактується як можливість розподіленого (т. Е. на різних вузлах, а не в одному місці) розміщення даних, логічно що становлять єдине ціле. Існує фрагментація двох типів: горизонтальна і вертикальна. Перша означає зберігання рядків однієї таблиці на різних вузлах (фактично, зберігання рядків однієї логічної таблиці в декількох ідентичних фізичних таблицях на різних вузлах). Друга означає розподіл стовпців логічної таблиці по декількох вузлів (типовий приклад реалізації - SQL-запит з декількох фізично відокремлених таблиць).
Незалежне тиражування
Тиражування даних - це асинхронний (у загальному випадку) процес переносу змін об'єктів вихідної бази даних в бази, розташовані на інших вузлах розподіленої системи. У даному контексті незалежність тиражування означає можливість перенесення змін між базами даних засобами, невидимими користувачеві розподіленої системи. Дана властивість означає, що тиражування можливо і досягається внутрішньосистемні засобами.
Принципова характеристика тиражування даних (Data Replication - DR) полягає у відмові від фізичного розподілу, прив'язки даних. Суть реплікації полягає в тому, що будь-яка база даних (як для СУБД, так і для працюючих з неї користувачів) завжди є локальною; дані розміщуються локально на тому вузлі мережі, де вони обробляються; всі транзакції в системі завершуються локально.
Тиражування даних - це асинхронний перенесення змін об'єктів вихідної бази даних в бази, що належать різним вузлам розподіленої системи. Функції тиражування виконує, як правило, спеціальний модуль СУБД - сервер тиражування даних, званий реплікатором (СУБД CA-Openlngres і Sybase). В інших СУБД (Informix-OnLine Dynamic Server) регашкатор вбудований в сервер або постачається опціонально (Oracle). Специфіка механізмів реплікації даних залежить від використовуваної СУБД. Один з найпростіших варіантів реплікації - використання так званих «моментальних знімків» (Snapshot) - збереження на різних вузлах копій тієї чи іншої таблиці в певний момент часу; дані копії періодично (раз на тиждень, наприклад) підлягають відновленню.
Деталі тиражування даних повністю приховані від прикладної програми; її функціонування ніяк не залежить від роботи помножувача, який повністю знаходиться у веденні адміністратора бази даних. Отже, для перенесення програми на розподілену середу з тиражованими даними не потрібно її модифікація.
Синхронне оновлення розподілених БД і технологія реплікації даних - у певному сенсі, антиподи. Наріжний камінь першої - синхронне завершення транзакцій одночасно на декількох вузлах розподіленої системи, т. Е. синхронна фіксація змін до розподіленої БД. Її «ахіллесова п'ята» - жорсткі вимоги до продуктивності і надійності каналів зв'язку. Якщо база даних розподілена по декількох територіально віддалених вузлів, об'єднаним повільними і ненадійними каналами зв'язку, а число одночасно працюючих користувачів складає сотні і вище, то ймовірність того, що розподілена транзакція буде зафіксована в осяжному часовому інтервалі, стає надзвичайно малою. У таких умовах (характерних, до речі, для більшості вітчизняних організацій) обробка розподілених даних практично неможлива.
Технологія реплікації даних не вимагає синхронної фіксації змін, що є, безсумнівно, її сильною стороною. Насправді далеко не у всіх завданнях вимагається забезпечення ідентичності БД на різних вузлах у будь-який час. Досить підтримувати тотожність даних лише в певні критичні моменти часу (генерація добового, тижневого, місячного, річного звіту). Можна накопичувати зміни в даних у вигляді транзакцій в одному вузлі і періодично копіювати ці зміни на інші вузли.
У наявності переваги розподіленої технології. По-перше, дані завжди розташовані там, де вони обробляються - отже, швидкість доступу до них істотно збільшується. По-друге, передача тільки операцій, що змінюють дані (а не всіх операцій доступу до віддалених даних), та ще й до того ж в асинхронному режимі дозволяє значно зменшити трафік. По-третє, з боку вихідної бази для приймаючих баз реплікатор виступає як процес, ініційований одним користувачем, в той час як у фізично розподіленої середовищі з кожним локальним сервером працюють всі користувачі розподіленої системи, що конкурують за ресурси один з одним. Нарешті, по-четверте, ніякої тривалий збій зв'язку не в змозі порушити передачу змін. Справа в тому, що тиражування передбачає буферизацію потоку змін (транзакцій); тому після відновлення зв'язку передача поновлюється з тієї транзакції, на якій тиражування було перервано.
У той же час технологія реплікації даних не позбавлена недоліків. Наприклад, неможливо повністю виключити конфлікти між двома версіями однієї і тієї ж записи. Такий конфлікт може виникнути, коли, внаслідок все тієї ж асинхронності, два користувача на різних вузлах виправлять одну і ту ж запис у той момент, поки зміни до даних з першої бази ще не були перенесені в другу. При проектуванні розподіленого середовища з використанням реплікації даних необхідно передбачити можливість виникнення конфліктних ситуацій і запрограмувати реплікатор на який-небудь варіант їх вирішення. У цьому сенсі застосування DR-технології - найбільш сильна загроза цілісності розподілених баз даних.
При використанні механізмів реплікації даних також гостро стоїть питання сумісності різнорідних локальних баз даних, що становлять вихідну БД. Найчастіше штатні засоби тиражування у складі даної конкретної БД дозволяють переносити дані в однорідну базу. Відповіддю стала поява продуктів, що виконують тиражування між різнорідними базами даних. Тут розвиток технологій пішов по двох шляхах. Перший - створення засобів уніфікованого доступу до даних (стандарт ODBC - Open DataBase Connectivity). Очевидний недолік ODBC - недоступність для програми багатьох корисних механізмів кожної конкретної СУБД, оскільки вони можуть бути використані в більшості випадків тільки через розширення SQL в діалекті мови даної СУБД, але в стандарті ODBC ці розширення можуть не підтримуватися. Інший підхід - це створення шлюзів, що дозволяють програмам оперувати над базами даних в іншому форматі так, як ніби це власні бази даних. Завдання шлюзу - організація доступу до успадкованих БД і служить для вирішення завдань узгодження форматів баз даних при переході до якої-небудь однієї СУБД. Шлюзи можна розглядати як засіб, що полегшує міграцію, але не як універсальний засіб межоперабельності в розподіленій системі. Взагалі, універсального рецепту вирішення завдання межоперабельності в цьому контексті не існує - все визначається конкретною ситуацією, історією інформаційної системи і масою інших факторів.
Обробка розподілених запитів
Це властивість розподіленої БД трактується як можливість виконання операцій вибірки, сформульованих в рамках звичайного запиту на мові SQL. To є операцію вибірки з розподіленої бази даних можна сформулювати за допомогою тих же мовних засобів, що і операцію над локальною базою даних.
Обробка розподілених запитів - завдання, більш складна, ніж обробка локальних запитів, і вона вимагає інтелектуального вирішення за допомогою особливого компонента - оптимізатора розподілених запитів. Припустимо, у нас є розподілена база даних, розміщена на двох вузлах. Нехай, таблиця detail зберігається на одному вузлі, а таблиця main - на іншому. Розмір першої таблиці - 2000 рядків, розмір другої - 200 рядків (безліч товарів поставляється невеликим числом постачальників). Припустимо, що виконується запит:
SELECT detail_name, main_name, main _address
FROM detail, main WHERE detail, main _number = main, main _number;
Тоді результуюча таблиця являє собою об'єднання таблиць
detail і main, виконане за стовпцем detail.main_number (зовнішній ключ) І main.main _number (первинний ключ).
Даний запит є розподіленим, т. К. зачіпає таблиці, що належать різним локальних баз даних. Для його нормального виконання необхідно мати обидві вихідні таблиці на одному вузлі. Отже, одна з таблиць повинна бути передана по мережі. Очевидно, що це повинна бути таблиця меншого розміру, т. Е. таблиця main. Таким чином, оптимізатор розподілених запитів повинен враховувати такі параметри, як розмір таблиць, статистику розподілу даних по вузлах, обсяг даних, переданих між вузлами, швидкість комунікаційних ліній, структури зберігання даних, співвідношення продуктивності процесорів на різних вузлах і т. Д. Від алгоритмів роботи оптимізатора розподілених запитів прямо залежить швидкість роботи бази даних з такими запитами.
Обробка розподілених транзакцій
Це якість розподілених баз даних можна трактувати як можливість виконання операцій оновлення БД, не руйнує цілісність і узгодженість даних. Ця мета досягається застосуванням двофазного протоколу фіксації транзакцій, що став фактичним стандартом обробки розподілених транзакцій. Його застосування гарантує узгоджене зміна даних на декількох вузлах у рамках розподіленої (або, як її ще називають, глобальної) транзакції.
Незалежність від обладнання
Це властивість означає, що в якості вузлів розподіленої системи можуть виступати комп'ютери будь-яких моделей та виробників - від мейнфреймів до персональних комп'ютерів і навіть ноутбуків.
Незалежність від операційних систем
Це якість випливає з попереднього і означає розмаїття операційних систем, керуючих вузлами розподіленої системи.
Прозорість мережі
Доступ до будь-яких баз даних може здійснюватися по мережі. Спектр підтримуваних конкретної СУБД мережевих протоколів не повинен бути обмеженням системи з розподіленими базами даних. Це якість формулюється максимально широко - в розподіленій системі можливі будь-які мережеві протоколи.
Незалежність від баз даних
Це якість означає, що в розподіленій системі можуть мирно співіснувати СУБД різних виробників, і можливі операції пошуку і оновлення в базах даних різних моделей і форматів. Локальні бази даних, що становлять розподілену БД, автономні, незалежні і самовизначені; доступ до них забезпечується СУБД, в загальному випадку від різних постачальників. Зв'язки між вузлами - це потоки тиражованих даних. Топологія розподілених БД може варіюватися в широкому діапазоні. У цілому топологія БД визначається географією інформаційної системи і спрямованістю потоків тиражування даних.
Не всі з перерахованих вище вимог можуть виконуватися одночасно. Усім вимогам відразу може задовольнити, мабуть, тільки достатньо ідеалізована, а тому і практично даремна база даних. Особливо це стосується останнього пункту - незалежності від програмного забезпечення БД. Не всі СУБД різних виробників можуть мирно співіснувати в рамках одного проекту. Тому при виборі засобів реалізації необхідно достатню увагу приділяти питанням сумісності. Останнім часом з розвитком нових програмних засобів створення БД (Delphi, наприклад) або розвитку нових технологій (CORBA), це питання стає менш гострим.
1 Цілісність даних
У DDB підтримка цілісності та узгодженості даних, зважаючи властивостей 1-2, являє собою складну проблему. Її рішення - синхронне і узгоджене зміна даних в декількох локальних базах даних, що становлять DDB - досягається застосуванням протоколу двофазної фіксації транзакцій. Якщо DDB однорідна - тобто на всіх вузлах дані зберігаються у форматі однієї бази і на всіх вузлах функціонує одна і та ж СУБД, то використовується механізм двофазної фіксації транзакцій даної СУБД. У разі ж неоднорідності DDB для забезпечення узгоджених змін в декількох базах даних використовують менеджери розподілених транзакцій. Це, однак, можливо, якщо учасники обробки розподіленої транзакції - СУБД, що функціонують на вузлах системи, підтримують XA-інтерфейс, визначений у специфікації DTP консорціуму X / Open. В даний час XA-інтерфейс мають CA-OpenIngres, Informix, Microsoft SQL Server, Oracle, Sybase.
Якщо в DDB передбачено тиражування даних, то це відразу пред'являє додаткові жорсткі вимоги до дисципліни підтримки цілісності даних на вузлах, куди спрямовані потоки тиражованих даних. Проблема в тому, що зміни в даних ініціюються як локально - на даному сайті - так і ззовні, за допомогою тиражування. Неминуче виникають конфлікти щодо змін, які необхідно відстежувати і вирішувати.
2 Обробка розподілених запитів
Вище вже згадувалося це якість DDB. Обробка розподілених запитів (Distributed Query-DQ) - завдання, більш складна, ніж обробка локальних і вона вимагає інтелектуального вирішення за допомогою особливого компонента - оптимізатора DQ. Звернемося до бази даних, розподіленої по двох вузлів мережі. Таблиця detail зберігається на одному вузлі, таблиця supplier - на іншому. Розмір першої таблиці - 10000 рядків, розмір другої - 100 рядків (безліч деталей поставляється невеликим числом постачальників). Припустимо, що виконується запит:
- SELECT detail_name, supplier_name, supplier_address
- FROM detail, supplier
- WHERE detail.supplier_number = supplier.supplier_number;
Результуюча таблиця являє собою об'єднання таблиць detail і supplier, виконане по стовпцю detail.supplier_number (зовнішній ключ) і supplier.supplier_number (первинний ключ).
Даний запит - розподілений, оскільки торкається таблиці, що належать різним локальних баз даних. Для його нормального виконання необхідно мати обидві вихідні таблиці на одному вузлі. Отже, одна з таблиць повинна бути передана по мережі. Очевидно, що це повинна бути таблиця меншого розміру, тобто таблиця supplier. Отже, оптимізатор DQ запитів повинен враховувати такі параметри, як, в першу чергу, розмір таблиць, статистику розподілу даних по вузлах, обсяг даних, переданих між вузлами, швидкість комунікаційних ліній, структури зберігання даних, співвідношення продуктивності процесорів на різних вузлах і т.д . Від інтелекту оптимізатора DQ прямо залежить швидкість виконання розподілених запитів.
3 Межоперабельность
У контексті DDB _ежоперабельность означає дві речі. По-перше, - це якість, що дозволяє обмінюватися даними між базами даних різних постачальників. Як, наприклад, тиражувати дані з бази даних Informix в Oracle і навпаки? Відомо, що штатні засоби тиражування у складі даної конкретної СУБД дозволяють переносити дані в однорідну базу. Так, засобами CA-Ingres/Replicator можна тиражувати дані тільки з Ingres в Ingres. Як бути в неоднорідному DDB? Відповіддю стала поява продуктів, що виконують тиражування між різнорідними базами даних.
По-друге, це можливість деякого уніфікованого доступу до даних в DDB з програми. Можливі як універсальні рішення (стандарт ODBC), так і спеціалізовані підходи. Очевидний недолік ODBC - недоступність для програми багатьох корисних механізмів кожної конкретної СУБД, оскільки вони можуть бути використані в більшості випадків тільки через розширення SQL в діалекті мови даної СУБД, але в стандарті ODBC ці розширення не підтримуються.
Спеціальні підходи - це, наприклад, використання шлюзів, що дозволяє додаткам оперувати над базами даних в «чужому» форматі так, як ніби це власні бази даних. Взагалі, мета шлюзу - організація доступу до успадкованих (legacy) баз даних і служить для вирішення завдань узгодження форматів баз даних при переході до якої-небудь однієї СУБД. Так, якщо компанія довгий час працювала на СУБД IMS і потім вирішила перейти на Oracle, то їй очевидно буде потрібно шлюз в IMS. Отже, шлюзи можна розглядати як засіб, що полегшує міграцію, але не як універсальний засіб межоперабельності в розподіленій системі. Взагалі, універсального рецепту вирішення завдання межоперабельності в цьому контексті не існує - все визначається конкретною ситуацією, історією інформаційної системи і масою інших факторів. DDB конструює архітектор, який має у своєму арсеналі відпрацьовані інтеграційні кошти, яких на ринку зараз дуже багато.
4 Технологія тиражування даних
Принципова характеристика тиражування даних (Data Replication - DR) полягає у відмові від фізичного розподілу даних. Суть DR полягає в тому, що будь-яка база даних (як для СУБД, так і для працюючих з неї користувачів) завжди є локальною; дані розміщуються локально на тому вузлі мережі, де вони обробляються; всі транзакції в системі завершуються локально.
Тиражування даних - це асинхронний перенесення змін об'єктів вихідної бази даних в бази, що належить різним вузлам розподіленої системи. Функції DR виконує, як правило, спеціальний модуль СУБД - сервер тиражування даних, званий реплікатором (так влаштовані СУБД CA-OpenIngres і Sybase). У Informix-OnLine Dynamic Server реплікатор вбудований в сервер:
У Informix-OnLine DS 7.1 підтримується тільки одна модель тиражування - повне відображення даних з основного сервера на вторинний для забезпечення високої доступності даних. У наступних версіях серверних продуктів Informix планується реалізація більш розвинених засобів, які дозволять вирішувати широке коло завдань розподіленої обробки даних.
У конфігурації серверів Informix-OnLine DS з тиражуванням виділяється один основний та один вторинний сервер. На основному сервері виконується і читання, і оновлення даних, а всі зміни передаються на вторинний сервер, який доступний тільки на читання (Мал. 2). У разі відмови основного сервера вторинний автоматично або вручну переводиться в режим доступу на читання та запис (Мал. 3). Прозоре перенаправлення клієнтів при відмові основного сервера не підтримується, але воно може бути реалізовано в рамках додатків.
Тиражування. Основний сервер доступний на читання і запис, вторинний - тільки на читання.
Коли основний сервер виходить з ладу, вторинний переводиться в режим доступу на читання, і на запис.
Oracle 7 для використання DR необхідно придбати додатково до Oracle7 DBMS опцію Replication Option.
Специфіка механізмів DR залежить від використовуваної СУБД. Найпростіший варіант DR - використання "моментальних знімків" (snapshot). Розглянемо приклад з Oracle:
- CREATE SNAPSHOT unfilled_orders
- REFRASH COMPLETE
- START WITH TO_DATE ('DD-MON-YY HH23: MI: 55')
- NEXT SYSDATE + 7
- AS SELECT customer_name, customer_address, order_date
- FROM customer @ paris, order @ london
- WHERE customer.cust_name = order.customer_number AND
- order_complete_flag = "N";
«Моментальний знімок» у вигляді горизонтальної проекції об'єднання таблиць customer і order буде виконаний о 23:55 і буде повторяться кожні 7 днів. Кожного разу будуть вибиратися тільки завершені замовлення.
Реальні схеми тиражування, зрозуміло, влаштовані складніше. В якості базису для тиражування виступає транзакція до бази даних. У той же час можливе перенесення змін групами транзакцій, періодично або в деякий момент часу, що дає можливість досліджувати стан приймаючої бази на певний момент часу.
Деталі тиражування даних повністю приховані від прикладної програми; її функціонування ніяк не залежать від роботи помножувача, який повністю знаходиться у веденні адміністратора бази даних. Отже, для перенесення програми на розподілену середу з тиражованими даними не потрібно її модифікації. У цьому, власне, складається якість 6 у визначенні Дейта.
Синхронне оновлення DDB і DR-технологія - у певному сенсі антиподи. Наріжний камінь першої - синхронне завершення транзакцій одночасно на декількох вузлах розподіленої системи, тобто синхронна фіксація змін в DDB. Ee "Ахіллесова п'ята" - жорсткі вимоги до продуктивності і надійності каналів зв'язку. Якщо база даних розподілена по декількох територіально віддалених вузлів, об'єднаним повільними і ненадійними каналами зв'язку, а число одночасно працюючих користувачів складає сотні і вище, то ймовірність того, що розподілена транзакція буде зафіксована в осяжному часовому інтервалі, стає надзвичайно малою. У таких умовах (характерних, до речі, для більшості вітчизняних організацій) обробка розподілених даних практично неможлива.
DR-технологія не вимагає синхронної фіксації змін, і в цьому її сильна сторона. Насправді далеко не у всіх завданнях вимагається забезпечення ідентичності БД на різних вузлах у будь-який час. Досить підтримувати тотожність даних лише в певні критичні моменти часу. Можна накопичувати зміни в даних у вигляді транзакцій в одному вузлі і періодично копіювати ці зміни на інші вузли.
У наявності переваги DR-технології. По-перше, дані завжди розташовані там, де вони обробляються - отже, швидкість доступу до них істотно збільшується. По-друге, передача тільки операцій, що змінюють дані (а не всіх операцій доступу до віддалених даних), і до того ж в асинхронному режимі дозволяє значно зменшити трафік. По-третє, з боку вихідної бази для приймаючих баз реплікатор виступає як процес, ініційований одним користувачем, в той час як у фізично розподіленої середовищі з кожним локальним сервером працюють всі користувачі розподіленої системи, що конкурують за ресурси один з одним. Нарешті, по-четверте, ніякої тривалий збій зв'язку не в змозі порушити передачу змін. Справа в тому, що тиражування передбачає буферизацію потоку змін (транзакцій); після відновлення зв'язку передача поновлюється з тієї транзакції, на якій тиражування було перервано.
DR-технологія даних не позбавлена недоліків. Наприклад, неможливо повністю виключити конфлікти між двома версіями однієї і тієї ж записи. Він може виникнути, коли внаслідок все тієї ж асинхронності два користувачі на різних вузлах виправлять одну і ту ж запис у той момент, поки зміни до даних з першої бази даних ще не були перенесені в другу. При проектуванні розподіленого середовища з використанням DR-технології необхідно передбачити конфліктні ситуації і запрограмувати реплікатор на який-небудь варіант їх вирішення. У цьому сенсі застосування DR-технології - найбільш сильна загроза цілісності DDB. На мій погляд, DR-технологію потрібно застосовувати дуже обережно, тільки для вирішення завдань з жорстко обмеженими умовами і за ретельно продуманою схемою, що включає осмислений алгоритм вирішення конфліктів.
5 Багатоланкова архітектура
Архітектура клієнт-сервер
Розподілені системи - це системи клієнт-сервер. Існує, щонайменше, три моделі клієнт-сервер:
* Модель доступу до віддалених даних (RDA-модель);
* Модель сервера бази даних (DBS-модель);
* Модель сервера додатків (AS-модель).
Перші дві моделі є двухзвенних і не можуть розглядатися в якості базової моделі розподіленої системи. Третя модель - трехзвенная. Вона (як і всі багатоланкові моделі) хороша тим, що в ній інтерфейс роботи з користувачем повністю незалежний від компонента обробки даних. Власне, триланкової її можна вважати остільки, оскільки в ній явно виділені:
* Компонент інтерфейсу з користувачем;
* Програмне забезпечення проміжного шару (middleware);
* Компонент управління даними.
Middleware - це головний компонент триланкових розподілених систем. Він виконує функції управління транзакціями і комунікаціями, транспортування запитів, управління іменами і інші функції.
Існує фундаментальна відмінність між технологією типу «сервер запитів-клієнт запитів» і триланковий технологіями. У першому випадку клієнт явно запитує дані, знаючи структуру бази даних (має місце так звана «постачання даних» клієнту). Клієнт передає СУБД, наприклад, SQL-запит, а у відповідь отримує дані. Здійснюється жорсткий зв'язок типів, для реалізації якої всі СУБД використовують закритий SQL-канал. Він будується двома процесами: SQL / Net на комп'ютері-клієнті і SQL / Net на комп'ютері-сервері і породжується з ініціативи клієнта оператором connect. Канал називається закритим в тому сенсі, що неможливо, наприклад, написати програму, яка буде шифрувати SQL-запити за спеціальним алгоритмом або іншим чином буде втручатися у процес передачі даних між клієнтським і серверним додатком.
У разі триланкової схеми клієнт явно запитує один із сервісів (надаються прикладним компонентом), наприклад, передаючи йому деяке повідомлення, і отримує відповідь також у вигляді повідомлення. Клієнт направляє запит в зовнішнє середовище, нічого не знаючи про місце розташування сервісу. Має місце так звана «поставка функцій» клієнту.
Для клієнта сама база даних видно виключно за допомогою набору сервісів. Більш того, він взагалі нічого не знає про її існування, тому що всі операції над базою даних виконуються всередині сервісів.
Таким чином, мова йде про два принципово різних підходах до побудови інформаційних систем клієнт-сервер. Двухзвенная архітектура на сьогоднішній день може вважатися досить застарілою і, у зв'язку з розвитком розподілених інформаційних систем, поступово відходить на другий план. І якщо для швидкого створення нескладних додатків з невеликим числом користувачів цей метод підходить як не можна краще, то при побудові корпоративних розподілених інформаційних систем він абсолютно непридатний в силу перерахованих вище причин.
Висновок
Сьогодні можна вважати, що розподілені бази даних - тема досить локальна і далеко не так актуальна, як архітектура розподілених систем. У DDB-технології за останні 2-3 роки не було будь-яких істотних новацій (за винятком, можливо, технології тиражування даних). Можна вважати, що в цій сфері інформатики все більш-менш устоялося і яких-небудь революційних кроків не передбачається. Більш цікавий напрямок (яке включає DDB) - архітектура, проектування і реалізація розподілених інформаційних систем. "Гарячі" теми в цьому напрямку - системи з триланкової архітектурою, продукти класу middleware, об'єктно-орієнтовані засоби розробки розподілених додатків в стандарті CORBA. Їх активне застосування буде домінувати у вітчизняній інформатики в найближчі 3-5 років і стане технологічною базою реальних інтеграційних проектів.
Мені здається, що революція відбудеться в архітектурі корпоративних інформаційних систем. Технологічний вибух у Intertet, створення і супербурное розвиток Всесвітньої павутини, технологія Java, неминуче відіб'ються на організації інфраструктури корпорацій. На мій погляд, очевидні переваги гіпертекстової організації даних (гнучкість, відкритість, простота розвитку та розширення) перед жорсткими структурами реляційних баз даних, за своєю природою погано пристосованими для розширення, зумовлюють використання HTML в якості одного з основних засобів створення інформаційного простору компанії. Підхід, що спирається на гіпертексти, дозволяє без особливих проблем інтегрувати вже існуючі інформаційні масиви, що зберігаються в базах даних. Те, що зараз називають Intranet - це прообраз майбутньої корпоративної інформаційної системи.
Список літератури
http://www.zeiss.net.ru/docs/dbms/oracle/oraclepr_03.htm
http://jonni3.narod.ru/I_Progr/gl4/gl4.html
http://www.citforum.ru/database/kbd96/45.shtml
Посилання (links):