4.3. Схеми тиражування даних
Використовуючи названі вище моделі тиражування даних можна побудувати такі основні схеми тиражування даних, які безпосередньо реалізовуються в сучасних СУБД: розподіл навантаження, розповсюдження, об’єднання (консолідація), динамічного права власності на дані, розподіленого права власності на дані, рівний з рівним, гаряче резервування.
Розподіл навантаження. Ця схема передбачає розподіл навантаження між кількома серверами і підтримку копій даних на одному чи більше серверах. Позитивним є те, що в такій системі інформація захищена від втрат за рахунок наявності резервної копії. Крім того, є можливість продовжувати роботу в разі виходу з ладу окремих серверів. Схему розподілу навантаження унаочнено на рис. 4.1.
Рис. 4.1. Схема розподілу навантаження
Розповсюдження (централізація). Ця схема підтримує розсилання інформації з центральних офісів у філіали. Дані оновлюються на центральному вузлі (сервері) і тиражуються у вигляді миттєвого знімка даних, зокрема й системних, у філіали. Наприклад, мережа магазинів з продажу побутової техніки має необхідність розіслати додаткові прайс-листи на побутову техніку до початку відкриття магазинів. Щоб гарантувати узгодженість даних, магазини мають доступ до них лише в режимі читання, тоді як центральний офіс має можливість як читати записи, так і редагувати їх.
Явним обмеженням цієї схеми тиражування є необхідність здійснення операцій лише через центральний офіс, що потребує від філіалів зв’язку з центральним офісом у момент здійснення тиражування. У разі, коли даних, що тиражуються, багато, а операцій над ними здійснюється мало, то краще скористатися іншим процесом тиражування, де по мережі передаються не дані, а операції з ними. Такий процес тиражування називається тиражуванням трансакцій. У цьому разі тиражуються не окремі операції, а їх логічні групи — транзакції. При цьому періодично необхідно здійснювати і цілковиту синхронізацію даних, яка виконується за методом тиражування миттєвого знімка даних. Трансакції, які підтверджені центральним офісом, збираються дистриб’ютором і копіюються далі у філіали, де ці операції виконуються з заздалегідь розповсюдженими знімками центральної бази даних. Якщо філіалу (клієнту) необхідно змінити деякі дані в основній базі, він повинен провести транзакцію з центральним офісом. Схему розповсюдження подано на рис. 4.2.
Рис. 4.2. Схема розповсюдження: ЦБД — центральна база даних; ЛБД — локальна база даних; n — номер локальної БД
Об’єднання (консолідація). Це схема тиражування, що забезпечує максимальну автономію віддаленої бази даних. Набори даних можуть оновлюватись на регіональних вузлах, а потім тиражуватися на центральний вузол у доступному лише для читання режимі. Сутність цієї схеми в тому, що всі операції виконуються на віддаленому комп’ютері, який може бути повністю відключений від комп’ютерної мережі. Автономна СУБД записує всі операції з даними у відповідну послідовність, а потім у визначений час тиражує їх до центрального офісу. При цьому процес оновлення даних ініціює автономна СУБД. Оновлення може виконуватися як за визначеним графіком, так і ручним способом (наприклад, тільки-но з’явився зв’язок між автономною СУБД і дистриб’ютором). До того ж є два способи отримати оновлення — копіювати миттєвий знімок локальної бази даних або чергу підтверджених центральною СУБД транзакцій. Передачу транзакцій можна використати лише в тому разі, коли в автономній БД вже зберігається копія основної. Зауважимо, що миттєвий знімок бази даних містить також і додаткову службову інформацію, наприклад ідентифікатори стовпців і рядків.
Використання схеми об’єднання дає змогу клієнтам (філіалам) системи працювати самостійно, а потім об’єднувати дані в єдиному центрі. Ця схема тиражування вдало підходить для мобільних працівників, які виїжджають на місця замовлення товарів для проведення переговорів і укладення договорів. Після укладення договору співробітник може передати нові відомості до центральної бази даних. Для цього прикладу конфліктна ситуація може виникнути, якщо договір укладено на вже проданий товар. На цей випадок у системі мають бути передбачені відповідні алгоритми автоматичного розв’язання конфліктів. Тиражування за схемою об’єднання показано на рис. 4.3.
Рис. 4.3. Схема об’єднання
Схема динамічного права власності на дані. Схема динамічного права власності на дані (або схема належності даних під час розподілу робочого навантаження) дає змогу запобігти конфліктам під час оновлення даних і являє собою його динамічну техніку. Дані, що модифікуються, послідовно просуваються від одного вузла до іншого. Право власності на дані під час розподілу робочого навантаження дає можливість модифікувати дані, що тиражуються, у міру їх просування від вузла до вузла. Тому в будь-який момент лише один вузол може оновлювати дані. У цій схемі кожен вузол залежить від даних, які надійшли з поперед-нього вузла, і може оновити запис лише відповідно до своєї робочої функції. Наприкінці кожного кроку інформація оновлюється та тиражується на наступний вузол. Наприклад, у системі оброблення замовлень на закупівлю товарів процес тиражування може відбуватися так. Замовлення спочатку вводиться в ПК у відділі приймання замовлень (АРМ замовлень). Після цього воно пересилається до відділу обліку для затвердження кредиту та виписування рахунка на оплату товару (АРМ з обліку), потім у відділ збуту для отримання дозволу на відправлення товару (АРМ збуту). І нарешті — у відділ доставки продукції для її пакування і доставки споживачу (АРМ доставки).
Схему динамічного права власності на дані ілюструє рис. 4.4.
Рис. 4.4. Схема динамічного права власності на дані
Схема розподіленого права власності на дані. Ця схема реалізує децентралізоване вирішення завдань, за якого кожен вузол обробляє свої дані. Вона надає адміністраторам гнучкий механізм для встановлення належності даних на рівні таблиць розподілення.
Наприклад, локальна комп’ютерна мережа філіалу комерційного банку володіє даними свого відділення і, відповідно, може коригувати дані, які стосуються того чи іншого розділу діяльності свого відділення. Внесені зміни потім передаються в головний офіс та інші регіональні відділення банку. Комп’ютер даного регіонального відділення може посилати запити та читати дані інших відділень, але не може вносити в них зміни. Така сама схема дій і для інших відділень банку. Схему розподіленого права власності на дані наведено на рис. 4.5.
Рис. 4.5. Схема розподіленого права власності на дані
Схема рівний з рівним. За такої схеми створюється середовище з рівноправними вузлами, що мають однакові можливості оновлювати дані. Оновлювати дані можна на будь-якому вузлі за принципом рівний до рівного. Така схема дає змогу локальним користувачам працювати навіть тоді, коли інші системи недосяжні. Для вирішення конфліктних ситуацій схема рівний з рівним повинна мати великий діапазон алгоритмів та процедур для автоматизованого визначення та розв’язання конфліктів. Схему тиражування рівний з рівним ілюструє на рис. 4.6.
Рис. 4.6. Схема тиражування рівний з рівним
Схема гарячого резервування. Ця схема здійснює підтримку дзеркальних копій баз даних з можливістю модифікації даних лише на центральному вузлі. Схему гарячого резервування даних унаочнено на рис. 4.7.
Рис. 4.7. Схема гарячого резервування даних
Наведені схеми тиражування даних дають змогу підтримувати копії даних із вихідної бази в потрібних користувачу місцях. Тиражувати можна як усю базу, так і її окремі об’єкти, наприклад, таблиці, множину рядків таблиць, окремі колонки або комбінації колонок і рядків тощо. Повний набір копій даних, що тиражуються, в усіх базах даних має назву CDDS (Consistent Distributed Data Set) — узгоджений розподілений набір даних. Він має задовольняти умову, що ті самі копії даних не можуть належати до різних CDDS. Другим головним поняттям тиражування є DРР (Data Propagation Path) — шлях розповсюдження змін, який визначає геометричну конфігурацію тиражування, що задовольняється зазначеними вище схемами. Сам процес тиражування при цьому може виконуватися як за схемою «рівний з рівним» (peer to peer), коли всі зміни в одному вузлі передаються на другий і, навпаки, з контролем конфліктних ситуацій, так і за схемою односторонньої передачі з доступом лише для читання. Цей процес непомітний для користувача, реплікатор отримує всю необхідну інформацію від сервера. Наприклад, у Microsoft SQL Server робота з тиражування даних реалізується за допомогою чотирьох агентів:
1. Агент підготовки миттєвого знімка бази даних (snapshot agent), який виконує всю підготовчу роботу для передачі миттєвого знімка даних від центральної БД на сервер дистриб’ютора.
2. Агент читання системного журналу (log reader agent), який запускається на дистриб’юторі та перевіряє зміни в базі даних центрального вузла.
3. Агент розповсюдження тиражу (distribution agent), який запускається на дистриб’юторі та керує розповсюдженням інформації до файлів (клієнтів).
4. Агент злиття (merge agent), який відповідає за послідовне об’єднання даних між центральною БД і автономними БД.
Для настройки сумісної роботи цих агентів у SQL Server є спеціальні майстри, які дозволяють адміністратору СУБД швидко перетворити SQL Server в один із компонентів системи. Майстер настройки дистриб’ютора й центральної БД (configure publishing and distribution) і майстер вилучення дистриб’ютора і центральної БД (disable publishing and distribution) дають змогу легко визначити для SQL-сервера відповідну роль: центральної БД, дистри-б’ютора або клієнта, а також виконати деякі додаткові настройки. Майстер формування публікацій (create publication) допомагає адміністратору визначити, які елементи даних повинні бути об’єднані в публікації для подальшого їх тиражування. Майстер примусового тиражування (push subscription) і розповсюдження за запитом (pull subscription) дають можливість адміністратору настроїти відповідну схему тиражування публікацій від дистриб’ютора до клієнтів. Майстер настройки алгоритму розв’язан-ня конфліктних ситуацій (replication conflict reconciler) допомагає настроїти агент злиття (об’єднання) даних на відповідний алгоритм розв’язання конфліктів у процесі злиття трансакцій. SQL дає можливість будь-якому розробнику створювати свій власний алгоритм розв’язання конфліктів за допомогою спеціального АРІ-інтерфейсу.
Для контролю процесу тиражування баз даних у SQL Server передбачені спеціальні контрольні програми-монітори (monitor). Один із моніторів дозволяє керувати роботою сервера центральної БД і клієнтів, а також створенням і розповсюдженням публікацій. За його допомогою адміністратор може отримати детальну інформацію про центральні БД, публікації та клієнтів. Монітор агента тиражування (replication agents) дає можливість адміністратору за допомогою графічного інтерфейсу контролювати й налагоджувати дії всіх чотирьох агентів, які відповідають за процес тиражування.
Монітор подій, які виникають у процесі тиражування (replication alerts), дозволяє настроїти механізми інформування адміністратора про різні ситуації, які проходять у БД, а також окремі з них записати в стандартний системний журнал.