- оптимізатора 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 (Первинний ключ). p> Даний запит - розподілений, так як зачіпає таблиці, належать різним локальним баз даних. Для його нормального виконання необхідно мати обидві вихідні таблиці на одному вузлі. Отже, одна з таблиць повинна бути передана по мережі. Очевидно, що це повинна бути таблиця меншого розміру, тобто таблиця supplier. Отже, оптимізатор DQ запитів повинен враховувати такі параметри, як, в першу чергу, розмір таблиць, статистику розподілу даних по вузлах, обсяг даних, переданих між вузлами, швидкість комунікаційних ліній, структури зберігання даних, співвідношення продуктивності процесорів на різних вузлах і т.д. Від інтелекту оптимізатора DQ прямо залежить швидкість виконання розподілених запитів.
3 Межоперабельность
У контексті DDB _ежоперабельность означає дві речі. По-перше, - це якість, що дозволяє обмінюватися даними між базами даних різних постачальників. Як, наприклад, тиражувати дані з бази даних Informix в Oracle і навпаки? Відомо, що штатні засоби тиражування в складі даної конкретної СУБД дозволяють переносити дані в однорідну базу. Так, засобами CA-Ingres/Replicator можна тиражувати дані тільки з Ingres в Ingres. Як бути в неоднорідній DDB? Відповіддю стала поява продуктів, виконують тиражування між різнорідними базами даних.
друге, це можливість деякого уніфікованого доступу до даних у DDB з програми. Можливі як універсальні рішення (стандарт ODBC), так і спеціалізовані підходи. Очевидний недолік ODBC - недоступність для програми багатьох корисних механізмів кожної конкретної СУБД, оскільки вони можуть бути використані в більшості випадків тільки через розширення SQL в діалекті мови даної СУБД, але в стандарті ODBC ці розширення не підтримуються. p> Спеціальні підходи - це, наприклад, використання шлюзів, що дозволяє додаткам оперувати над базами даних в В«чужомуВ» форматі так, як ніби це власні бази даних. Взагалі, мета шлюзу - організація доступу до успадкованим (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). Прозоре перенаправлення клієнтів при відмові основного сервера не підтримується, але ...
