Дослідження автоматизованого об'єднання розподілених баз даних різних інформаційних систем

Корнієнко, Артем Дмитрович

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6475

Full metadata record

DC Field	Value	Language
dc.contributor.advisor	Міценко, Сергій Анатолійович	-
dc.contributor.author	Корнієнко, Артем Дмитрович	-
dc.date.accessioned	2023-01-22T13:04:59Z	-
dc.date.available	2023-01-22T13:04:59Z	-
dc.date.issued	2023-01	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/6475	-
dc.description.abstract	В результаті досліджень вирішена важлива проблема розробки моделей та методів, які забезпечують підвищення ефективності управління розподіленою базою даних в комп’ютерних системах з динамічною структурою. Ця проблематика має суттєве значення для проектування та модернізації існуючих розподілених систем обробки даних з метою забезпечення їх високої ефективності при обробці запитів в розподілених базах даних. Перспективними шляхами подальших досліджень у розглянутому напрямку може бути широке коло питань щодо розробки нових та удосконалених існуючих методів підвищення ефективності часу обробки запитів в розподілених комп’ютерних мережах з використанням мережецентричного підходу, які мають бути застосовані в умовах впливу зовнішніх та внутрішніх дестабілізуючих факторів.	uk_UA
dc.language.iso	uk	uk_UA
dc.title	Дослідження автоматизованого об'єднання розподілених баз даних різних інформаційних систем	uk_UA
dc.type	Master Thesis	uk_UA
Appears in Collections:	123 Комп’ютерна інженерія (Спеціалізовані комп’ютерні системи)

Files in This Item:

File	Description	Size	Format
М_123_2022_Корнієнко+.pdf Restricted Access		1.09 MB	Adobe PDF	View/Open Request a copy

Show simple item record

Extracted text

ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ КОМП’ЮТЕРНИХ
СИСТЕМ

Пояснювальна записка
до кваліфікаційної роботи
освітнього ступеню «магістр»

на тему: ДОСЛІДЖЕННЯ АВТОМАТИЗОВАНОГО ОБ'ЄДНАННЯ
РОЗПОДІЛЕНИХ БАЗ ДАНИХ РІЗНИХ ІНФОРМАЦІЙНИХ СИСТЕМ

Виконав: студент 2 курсу, групи МСКС-2107
спеціальності 123 Комп’ютерна
інженерія,
освітня програма «Спеціалізовані
комп’ютерні системи»
Корнієнко А.М.
(прізвище та ініціали)

Керівник Міценко С.А.
( прізвище та ініціали)

Рецензент
(прізвище та ініціали)

Черкаси 2022 року
2
ЗМІСТ

ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ ........................................................................ 4
ВСТУП ......................................................................................................................... 5
РОЗДІЛ 1 АНАЛІЗ ПРОБЛЕМИ ПІДВИЩЕННЯ ЕФЕКТИВНОСТІ
ФУНКЦІОНУВАННЯ РОЗПОДІЛЕНОЇ БАЗИ ДАНИХ В КОМП’ЮТЕРНИХ
СИСТЕМАХ ................................................................................................................ 9
1.1. Дослідження організації, обробки та зберігання даних в сучасних
розподілених реляційних базах даних .................................................................. 9
1.2. Дослідження особливостей побудови сучасних розподілених систем з
використанням баз даних ..................................................................................... 13
1.3. Аналіз організації розподілених баз даних ................................................. 20
1.4. Дослідження існуючих підходів до вирішення задач управління
розподіленими базами даних ............................................................................... 28
Висновки ................................................................................................................ 33
РОЗДІЛ 2 МОДЕЛЬ ЗАБЕЗПЕЧЕННЯ АВТОМАТИЗОВАНОЇ РОБОТИ
РОЗПОДІЛЕНИХ БАЗ ДАНИХ .............................................................................. 35
2.1. Механізм обробки запитів в розподіленій системі обробки запитів ........ 35
2.2. Формальне представлення розподіленої системи обробки даних ............ 40
2.3. Модель оцінки часу обробки запитів в розподіленій системі обробки даних
з використанням розподілених баз даних ........................................................... 47
Висновки ................................................................................................................ 58
РОЗДІЛ 3 РЕАЛІЗАЦІЯ МЕХАНІЗМІВ УПРАВЛІННЯ РОЗПОДІЛЕНИМИ
БАЗАМИ ДАНИХ З ДИНАМІЧНОЮ СТРУКТУРОЮ ........................................ 60
3.1. Розробка середовища для дослідження параметрів розподілених баз даних
................................................................................................................................. 60
3.2. Визначення кількості вузлів бази даних в залежності від розмірності
розподіленої системи ............................................................................................ 64
3
3.3. Порівняльний аналіз роботи методики синтезу розподіленої системи
обробки даних ........................................................................................................ 69
Висновки ................................................................................................................ 72
ЗАГАЛЬНІ ВИСНОВКИ .......................................................................................... 74
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................. 76
4
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ

QL – Query Language
SMTP – Simple Mail Transfer Protocol
SOP – Standard Operating Procedure
SPARQL – Protocol and RDF Query Language
SQL – Structured Query Language
SQLIA – Structured Query Language Injection Attack
UML – Unified Modeling Language
БД – База даних
ГБД – Гетерогенні бази даних
КВ – Керуючий вузол
МЦК – Мережецентричне керування;
ООСУБД – Об'єктно-орієнтована система управління базами даних
РБД – Розподілені бази даних
РКС – Розподілена компютерна система
РСОБ – Розподілена система обробки даних
РСУБД – Розподілена система управління базою даних
СПД – Система передачі даних;
СТС – Складна технічна система;
СУБД – Система управління базами даних
5
ВСТУП

Актуальність. В наш час розподілені інформаційні системи виконують
різні функції обробки та зберігання даних. Однією із них є забезпечення
користувачів баз даних можливістю доступу до великих масивів інформації, при
умові підтримки високої швидкості запису та вивантаження даних в умовах
постійного масштабування обсягу оброблюваних даних, а також, доступ до
даних незалежно від пристрою та типу підключення. Всі інші вимоги, такі як
продуктивність, сумісність, керованість, захищеність, розширюваність і
масштабованість пов'язані з якістю виконання цієї основної задачі.
На даний час розподілені бази даних розвиваються швидкими темпами та
забезпечуються все більшою кількістю нових можливостей та технологій.
Збільшилась кількість також і сфер застосування розподілених баз даних. За
останні три роки кількість інформації розташованої в глобальних мережах,
збільшилася в кілька разів і досягла трильйонів гігабайт. З цієї інформації на
сьогоднішній день тільки 15% зберігається у «хмарах», а інша частина на
серверах та персональних комп’ютерах різних сфер діяльності людини в
промисловій інфраструктурі, автоматиці, охороні здоров'я, транспорті,
військовій техніці і багатьох інших.
На сьогоднішній день розподілені бази даних вважаються однією з
найбільш важливих технологій XXI століття. Технологія побудови розподілених
баз даних дозволяє здійснювати обробку великих масивів інформації при
відповідних параметрах надійності та безпеки у рамках усього промислового
процесу.
Питання обробки даних в розподілених базах даних в роботах
В.А. Машкова [25], Ю.М. Коростіля [5], В.А. Савченка []10, M. Eltabakh [29],
P. Tomar [36], V. Goebel [36] та інших вчених. Питання стійкості розподілених
систем щодо зовнішніх інформаційних впливів досліджувалось Д.В. Ланде [14],
Ю.В. Журавським [33], І.В. Рубаном [42].
6
Таким чином, на даний час в практиці і теорії побудови та експлуатації
існуючих розподілених баз даних в мережах загострилося протиріччя між
необхідністю стійкого функціонування розподілених баз даних в умовах дії
внутрішніх та зовнішніх дестабілізуючих впливів і можливостями існуючих
методів забезпечення обробки інформації в мережах в динамічному середовищі
передачі даних.
Тому, тематика роботи, яка направлена на підвищення ефективності
функціонування розподілених баз даних шляхом розробки та реалізації моделей
та методів забезпечення заданих параметрів функціонування баз даних являється
актуальною і представляє науковий та практичний інтерес.
Мета роботи – підвищення ефективності функціонування розподілених
баз даних шляхом розробки та реалізації моделей і методів обробки даних в
розподілених комп’ютерних системах.
Для досягнення поставленої мети необхідно вирішити такі завдання:
– провести аналіз і оцінку параметрів функціонування розподілених
систем з динамічною структурою середовища обробки даних;
– розробити засоби забезпечення функціонування розподілених баз
даних в динамічному середовищі передачі даних;
– розробити механізми підвищення ефективності обробки даних в
розподілених базах даних;
– розробити узагальнену методику оцінки ефективності функціонування
розподілених баз даних на основі динамічної структури середовища
передачі даних;
Об’єкт дослідження – процес управління розподіленими базами даних
Предмет дослідження – автоматизоване об'єднання розподілених баз
даних різних інформаційних систем.
Методи дослідження. Для досягнення поставленої мети в роботі
використовується математичний апарат теорії реляційних баз даних, теорії
складних систем із застосуванням математичних моделей і методів дискретної
математики. Теоретичні основи функціонування розподілених баз даних
7
будуються з використанням теорії графів, комбінаторної теорії, аналітичного
моделювання та дискретної оптимізації. Основні положення і теоретичні оцінки
підтверджено аналізом результатів моделювання та дослідження засобів обробки
пакетів в розподілених системах.
Наукова новизна даної кваліфікаційної роботи полягає в наступному:
– розроблено модель оцінювання параметрів обробки інформації в
розподілених системах з динамічною структурою в яких реалізовано
розподілені бази даних наукова новизна якої полягає в тому, що вона
ґрунтується на виборі кортежу параметрів розподіленої системи та
врахуванні обмежень, що дозволяє формалізувати структуру
управління обробки запитів в розподілених базах даних.
– розроблено метод визначення необхідної кількості вузлів бази даних
наукова новизна якого полягає в тому, що він ґрунтується на
застосуванні механізму визначення вагових коефіцієнтів видів запитів,
що дозволяє отримати потрібну кількість вузлів баз даних в
розподіленій системі для забезпечення відповідних вимог до
параметрів обробки запитів та підвищення швидкості їх обробки.
– удосконалено модель для аналізу та прогнозування функціональних
параметрів розподілених систем обробки даних, яка відрізняється від
існуючих тим, що вона ґрунтується на застосуванні механізму на основі
фрактального підходу, що дозволяє розрахувати для фрагмента
розподіленої системи з динамічною структурою в якій реалізовано
розподілені бази даних.
Практичне значення одержаних результатів. Розроблена модель
оцінювання параметрів обробки інформації в розподілених системах дозволяє
побудувати систему зберігання даних з заданими характеристиками. Розроблено
методи, які забезпечують вибір вузлів баз даних та керування для ефективної
обробки даних баз даних. Розроблена узагальнена методика синтезу розподіленої
системи обробки даних дозволяє організувати розподілену систему для обробки
запитів до баз даних з урахуванням параметрів.
8
Апробація результатів роботи. Результати кваліфікаційної роботи
доповідалися й обговорювалися на студентських і наукових конференціях:
− дні студентської науки ЧДТУ, 20-21 квітня, м. Черкаси, 2021;
− дні студентської науки ЧДТУ, 19-20 квітня, м. Черкаси, 2022;
− «Проблеми інформатизації»: Тези доповідей десятої міжнародної
науково-технічної конференції: (24-25 листопада 2022 р., Черкаси),
2022. – С. 43.
Публікації. Результати досліджень опубліковані в:
1. Архітектури побудови автоматизованих систем аналізу великих даних/
Міценко С.А., Комісаренко Н.А., Корнієнко А.Д. // «Проблеми
інформатизації»: Тези доповідей десятої міжнародної науково-
технічної конференції: (24-25 листопада 2022 р., Черкаси), 2022. –
С. 43.
Структура та обсяг кваліфікаційної роботи. Кваліфікаційна робота
складається із списку умовних скорочень, вступу, трьох розділів, висновку та
списку використаних джерел. Загальний обсяг роботи складає 80 сторінок,
17 рисунків, 5 таблиць. Список використаних джерел містить 53 найменування.

9
РОЗДІЛ 1
АНАЛІЗ ПРОБЛЕМИ ПІДВИЩЕННЯ ЕФЕКТИВНОСТІ
ФУНКЦІОНУВАННЯ РОЗПОДІЛЕНОЇ БАЗИ ДАНИХ В
КОМП’ЮТЕРНИХ СИСТЕМАХ

1.1. Дослідження організації, обробки та зберігання даних в сучасних
розподілених реляційних базах даних
Сучасні підходи щодо організації розподіленої обробки реляційних баз
даних
Сьогодні без використання баз даних не обходиться жодна галузь,
виробництва та організації; всі вони використовують формати баз даних для
зберігання інформації, реалізуючи надважливу функцію організації
промислових, дослідницьких, а також інструментальних систем. Для цього
необхідне створення системи управління базою даних (СУБД). Розроблені
спеціальними компаніями різноманітні типи СУБД підтримуються сучасними
інформаційними системами.[45].
Важливими задачами для всіх без винятку організацій, що використовують
зростаючі бази даних, можна назвати збільшення продуктивності пошуку,
запису, захисту інформації у розподілених БД, заповнених значними обсягами
конфіденційної інформації.[14]. Одна з найважливіших задач – пошук даних.
Наведемо три причини цього твердження[18]:
1 Щодня інтернет-сервери зберігають гігантські масиви даних.
2 Відомі технології пошуку діють неефективно при застосуванні у
великих масивах даних та видають багато хибних, невідповідних
запиту, результатів.
3 Зростання, особливо останнім часом, можливостей комп’ютерної
техніки - швидкості обробки інформації і об’єму дискового простору.
Тому на різних серверах розміщують гігантські інформаційні масиви,
що вимагає швидкісного пошуку навіть у таких розподілених БД [17].
10
Розглянемо двоетапний підхід до пошуку, використаний для підвищення
ефективності[12]:
− 1-й етап – підготовчий пошук інформації та проведення індексування в
окремих БД;
− 2-й етап – проведення пошуку безпосередніми користувачами у
локальних індексованих БД.
Відомі корпорації, такі, як Google, досягли високих успіхів у вирішенні
завдання пошукової оптимізації шляхом використання апаратної бази на основі
єдиних пошукових систем, сформованих на потужних серверах [21].
У подальшому можуть бути створені пошукові системи, орієнтовані на
пошук даних у розподілених БД та на семантичний аналіз інформації.
Застосування паралельних систем, побудованих з багатьма зв’язками аналогічно
до будови нейронних мереж і необхідне для підтримки механізму штучного
інтелекту [23]. Використання такої системи збільшує швидкість пошуку на
декілька порядків [17].
Сьогодні у сучасних розподілених БД формування індексів викликає деякі
проблеми. Якщо індексування базується на слабо заповнених деревах, то
збільшення висоти дерева призводить до зростання часу пошуку даних у базі
[22]. При застосуванні ж рівних індексів різних таблиць додатково час
витрачається на пошук за обома рівними індексами, це вимагає створення
уніфікованого індексу для пошуку за обома таблицями [19].
Зараз використовують такий підхід до завантаження індексів до
оперативної пам’яті: виконуючи запити до таблиці БД, завантажують індекси
даних до оперативної пам’яті по мірі їх появи. В цьому випадку з пам’яті
витісняються індекси, що використовуються частіше, тими індексами, які
потрапляють до пошукових запитів порівняно рідко[27].
Виконуючи алгоритм запису та зміни інформації у БД, одержуємо надто
часте додавання ключів до відповідних вузлів дерева та перетворення індексів.
При цьому відчутно знижується швидкість запису даних у базу, коли зростає
число запитів на запис чи зміну інформації у БД [13].
11
Обробка інформації у БД із дотриманням достатнього рівня безпеки
інформації відбувається при використанні системи моніторингу безпеки.
Використання загальноприйнятих підходів та алгоритмів є недостатнім у даному
випадку, бо вони дозволяють застосувати тільки основні підходи і не здійснюють
контроль за роботою БД в умовах постійного модифікування апаратного і
програмного забезпечення. З метою покращення захисту інформації в БД
необхідні виняткові підходи до моніторингу, націлені на використання у
розподілених БД [19].
Для підтримання високої швидкості обробки даних на серверах і зростання
вірогідності фіксації та попередження несанкціонованих операцій зловмисників
є необхідним розробка нових методів запису й пошуку інформації в БД та
моделей для моніторингу безпеки.
Для дієвого захисту своєї інформації підприємства і організації повинні
виконати 5 важливих умов [13]:
− Відокремити вразливі БД: вести реєстр усіх БД, використовуваних в
усій організації та контролювати усю конфіденційну інформацію, яку
містять БД.
− Зняти вразливості: знаходження та виключення помилок та
вразливостей.
− Обмеження доступу користувачів до найменшої кількості необхідної
для роботи інформації.
− Спостереження за відхиленнями: стежити за діяльністю користувачів,
що відхиляється від нормальної статутної роботи.41
− Реакція на сумнівну поведінку: повідомлення і реагування на підозрілі
дії для зниження ризику нападу.
Класифікація методів розподіленої обробки реляційних баз даних
Концепція будови БД складається із принципів та методів. Вимоги до БД
та СУБД, на них побудованих, такі: короткий час відгуку на запит, простота
відновлення інформації, незалежність від характеру запису інформації,
програмного та технічного забезпечення; користування БД багатьма
12
користувачами; захист інформації; вимоги до побудови та використання БД;
точність інтерпретації інформації; інтуїтивно зрозумілий інтерфейс[19].
Є два аспекти щодо створення БД: перший аспект – щодо автоматизації
обігу документів, а другий пов’язаний із автоматизацією управління. В першому
випадку створюється універсальна база даних, застосовна із різними
алгоритмами. В другому проводиться спочатку знаходження стандартних
алгоритмів програм із визначенням під них даних. Другий – об’єктно-
орієнтовний підхід - значно більш поширений[8].
Створюється будь-яка база даних за чотири кроки:
− створення та розгляд вимог,
− створення концепції,
− логічне проєктування,
− фізичне проєктування.
Першим кроком є встановлення цілей і вимог до бази даних, другий крок
– описання і формулювання інформаційних вимог користувачів у проєкт бази
даних. На кроці логічного проєктування структура СУБД формується шляхом
високорівневої інтерпретації даних. На кроці фізичного проєктування
розв’язується задача продуктивності бази даних, формується методика доступу
до інформації та структура запису інформації у базі даних[12].
Основні завдання проєктування БД [5]:
1 Забезпечення збереження в БД всіх потрібних даних;
2 Забезпечення видачі інформації за всіма потрібними запитами;
3 Зниження надлишку та кількості дублів даних;
4 Забезпечення цілісності і правильності інформації: відхилення
суперечливої інформації, виключення втрачання даних.
Концептуальне, логічне та фізичне – 3 види проєктування баз даних. Певна
картина і значення концептуальної моделі БД описується підібраним для цього
формальним апаратом. Застосовуються графічні нотації, схожі до ER-діаграм [5].
Часто концептуальна модель БД містить:
1 Характеристику інформаційних об'єктів і їхніх зв'язків.
13
2 Характеристику меж цілісності, тобто вимог до дозволених значень
даних і до їхніх зв'язків.
Логічне проектування формування схеми БД на базі певної моделі.
Реляційної моделі БД, тощо. Для неї логічною моделлю є сукупність схем
відношень із вказаними первісними ключами та зовнішніми ключами, що
зв’язують відношення[7].
За формальними правилами переходять від концептуальної моделі до
логічної. Цей перехід є можливість частково автоматизувати. Проводячи логічне
проєктування, враховують певну модель представлення інформації та не
враховують конкретний тип СУБД [18].
Фізичне проектування формування схеми БД для певної СУБД. В СУБД
існують обмеження на підтримувані типи даних та іменування об’єктів БД.
Також до функцій СУБД відноситься визначення рішень, обумовлених
фізичними умовами зберігання інформації – керування дисковим простором,
пам’яттю, створення індексів, методи доступу до інформації. Нормалізацію
проводять для покращення проєктування реляційної БД [12].
Концептуальна модель модель предметної сфери, що використовується
для представлення семантики області на найвищому рівні абстракції. Тобто
відсутня або знижена потреба застосовувати низькорівневі поняття, що
означають фізичне представлення та запис інформації. Модель «сутність-
зв'язок», або ER-модель - це найвідоміший приклад класу семантичних моделей.

1.2. Дослідження особливостей побудови сучасних розподілених
систем з використанням баз даних
Фундаментальні принципи побудови РКС
Високоефективні підрахунки необхідні для успішного розв’язання
складних наукових і прикладних завдань. Для провадження цих підрахунків
можуть бути застосовані різноманітні технологічні підходи; одним з яких є
розподілені комп’ютерні системи. РКС – це система незалежних комп’ютерів,
яка виглядає для користувача цілісною узгодженою системою [7]. Уявлення про
14
різних комп’ютери як цілісну систему існує завдяки присутності додаткового
рівня програмного забезпечення, що називається програмним забезпеченням
проміжного рівня (middleware) та яке встановлене на всіх комп’ютерах системи
(рис. 1.1) [12].
Для забезпечення спільного контрольованого та ефективного доступу
додатків (applications), а також користувачів до територіально віддалених вузлів
застосовують розподілені системи обробки даних. В цьому випадку
територіальна віддаленість вузлів для кінцевого користувача не грає ролі.
До поняття вузла включають при цьому не тільки комп’ютерну техніку, а
й встановлене сервісне програмне забезпечення [8]. При спільному користуванні
одним вузлом кінцевих користувачів та програмних додатків виникає
конкуренція за одночасний доступ до ресурсу.

Рис. 1.1. Схематичне зображення розподіленої системи обробки даних

Розподілені сучасні системи обробки даних володіють гетерогенним
характером з таких причин:
− Обмінювання даними проходить через декілька різноманітних мереж;
− Існує різноманітність у внутрішніх типах даних різних процесорів;
− Використання різних операційних систем з властивими їм
інтерфейсами програм для однакових сервісів;
15
− Для різного програмного забезпечення властиве різне представлення
типів даних та сервісів взаємодії.
Розподілені системи обробки даних мають забезпечувати відкритість,
прозорість, масштабованість та надійність – стійкість до виникнення збоїв [5].
Прозорість розподілених систем (таблиця 1.1.) є основною
характеристикою їх роботи та важлива з різних сторін. Однак при формуванні та
реалізації подібних розподілених систем має зберігатися баланс прозорості і
продуктивності системи [15].

Таблиця 1.1
Форми прозорості в розподілених комп’ютерних системах
Прозорість Опис
Щодо доступу до вузла: Непомітність для кінцевого користувача різниці
в представленнях типів даних та механізмах
Access transparency доступу до них
Щодо місця розміщення Реалізація доступу до вузла без прив’язки до
вузла Location transparency його територіального розміщення
Щодо мобільності вузла Спроможність перенесення вузла разом з
Mobility transparency програмними додатками та користувачами без
впливу на їх роботу
Щодо паралелізму Взаємодія кожного користувача та програмного
використання забезпечення вузла одночасно без взаємодії з
Concurrency transparency іншими користувачами
Означає неважливість збоїв у роботі вузла
Щодо збоїв в роботі апаратного чи програмного компоненту для
Failure transparency кінцевого користувача через обов’язковість
одержання кінцевого результату від системи
Щодо реплікації Реплікація проводиться непомітно для
Replication transparency користувача
Щодо масштабування Спроможність системи до розширення в межах
Scaling transparency тієї ж структури та із застосуванням тих же
програмних додатків
Щодо продуктивності Передбачає непомітний для користувача
Performance transparency розподіл навантаження на вузли для
прискорення продуктивності
16
Розподілені системи надають доступ до вузлів шляхом використання
засобів із чітко встановленими синтаксисом і семантикою; це забезпечує
відкритість розподілених систем. Застосування загальноприйнятого механізму
комунікації та стандартних протоколів є ознаками відкритості розподілених
систем. Також розподілені системи повинні володіти певною гнучкістю щодо
можливостей розширення системи і додавання до неї складових частин без змін
в складі інших частин системи.
Основною характеристикою розподілених систем є можливість до
масштабування. Зміни в системі можуть відбуватись у трьох вимірах [17]:
− розмір системи – збільшення кількості приєднаних до системи нових
клієнтів та вузлів;
− географічна протяжність - користувачі та вузли системи просторово
віддалені один від одного;
− керованість - простота керування системою при адмініструванні
декількома організаціями.
Збільшення масштабування системи за одним з цих параметрів водночас
знижує продуктивність системи [12].
Надійність роботи при наявності збоїв в розподіленій системі є базовою
характеристикою. Збої в розподілених системах частково зачіпають роботу
системи, при виході з ладу частини обладнання решта продовжує працювати. Це
ускладнює пошук проблемних місць в системі і викликає необхідність пошуку
відмов у вузлах системи та механізмів відновлення роботи системи для
одержання заданих результатів виконання запитів. Розподілені комп’ютерні
системи будують з метою моделювання складних процесів, проведення складних
обчислень, обробки мультимедійних даних.
Сучасні тенденції розвитку РКС
В науці, бізнесі, щоденному житті – швидкий розвиток розподілених
систем та широке їх розповсюдження легко завойовують нові грані людської
діяльності. Впливовою частиною комп'ютерного середовища від різноманітних
локальних комп'ютерних та мережевих архітектур і додатків все більше
17
зсувається до масових мереж і програмних продуктів глобального застосування,
що включені в великий інформаційний простір [9].
Важливими в цьому розумінні є Інтернет речей (IoT , Internet of Things) [8]
та мобільні хмарні обчислення (MCC, Mobile Cloud Computing) [11]. Підхід,
названий IoT, полягає в об’єднанні фізичних та цифрових об’єктів реальної
дійсності в одне загальне середовище за допомогою засобів вбудованих
технологій взаємодії з навколишнім середовищем, при цьому Інтернет бере на
себе функцію передачі і розповсюдження даних по світовій мережі [9].
Використання мобільних хмарних обчислень дозволяє запис даних, та процес їх
обробки за межі мобільного телефона і зберігання їх у хмарах. При цьому
безпосередньо з мобільного пристрою відбувається доступ до системи через веб-
браузер [6].
Характеризуючи сучасні розподілені системи, говорять про:
− гетерогенність вузлів і зв’язків між ними;
− просторову віддаленість;
− глобальність;
− структурно-динамічну складність [5];
− високий попит через масовість залучення користувачів [16].
Керувати ресурсами таких розподілених систем є складним завданням, яке
потребує розробки та реалізації нових алгоритмів керування ресурсами [51].
Важливим моментом у застосуванні розподілених систем є комерційне їх
використання, що викликає потреби якісного сервісу, який надається
користувачам. В той же час постачальники послуги повинні визначати
необхідний рівень оплат послуг, що додає вимоги до керування вузлами
розподіленої системи [43].
Управління ресурсами як основа функціонування РКС
В розподіленій системі обробки даних, в якій є програмні та машинні
ресурси, метою керування є вирішення порядку вирішення завдань, що
поставлені перед системою, та розподіл наявних ресурсів. Керуючи ресурсами в
розподіленій системі, варто не забувати, що доступні лише ресурси, розподілені
18
на рівні системи прозоро, і всі користувачі можуть мати до них доступ. Кожний
ресурс, або вузол, може бути використаний для вирішення місцевих задач, і
підлягає постійним змінам.
Зараз буває часто, що декілька компаній об’єднують системи заради
паралельної роботи. Тоді виникає необхідність управління об’єднаною
розподіленою системою на рівні власника кожної компанії для рівномірного
паралельного використання ресурсів у часі задля проведення коректної спільної
роботи[11].
Ефективний розподіл ресурсів є однією з основних вимог до
високопродуктивних обчислювальних систем, а механізм розподілу ресурсів
вважається центральною темою високопродуктивних обчислень [11].
Для вищої ефективності роботи використання ресурсів розподіленої
системи, якісного обслуговування користувачів (QoS) [9] керування ресурсами
проводять в залежності від особливостей вхідних завдань та роботи системи в
цілому [28]. Незручністю планування роботи розподілених систем обробки
даних є швидка зміна даних про ресурси.
Керування ресурсами включає в себе керування такими процесами [8]:
− пошуком ресурсів;
− плануванням виконання послідовності завдань;
− передаванням запитів у вузли;
− завантаженням системи.
Процес передаванням запитів у вузли складається з чотирьох основних
етапів [6]:
− планування виконання запиту;
− передача коду;
− передача даних;
− перевірка виконання запиту.
Поділ на три основні етапи процесу планування завдання [16]:
− пошук доступних на цей момент ресурсів;
19
− виконання завдання.
− вибір ресурсів, які є найбільш підходящими відповідно до вимог
завдання.
Важливою базовою частиною системи керування ресурсами розподіленої
системи обробки даних є планувальник, у завдання якого входить координація
виконання запитів, які надходять для виконання розподіленою системою,
шляхом запису їх на доступні обчислювальні ресурси системи [11]. Тут має
значення задовольнити вимоги користувача, так і виключити простою
обчислювальних ресурсів.
Як приклад можна зобразити логічну архітектуру підсистеми планування
у GRID (рис. 1.2), представлену у [29]. У [22] показано такі основні особливості
роботи планувальника розподіленої системи обробки даних: час вирішення
задачі, пропускна здатність та час відклику системи. Проте слід пам’ятати, що ці
параметри залежать не лише від конфігурації СУР розподіленої комп’ютерної
системи, а й від характеристик вхідного списку завдань [27], таких як
інтенсивність поступання задач, обчислювальна складність задач і таке ін.
Для правильної роботи планувальник повинен мати інформацію щодо
стану, в якому перебуває ресурс, задля утворення певного розкладу запуску
задач, а надто - в гетерогенному та динамічному середовищі розподіленої
комп’ютерної системи [12]. Враховуючи сказане вище, має сенс також знати
параметри задачі: складність обчислень, заповненість пам’яті, вимоги до
програмного додатку, об’єм вхідних та вихідних даних, зв'язок між підзадачами
у задачі, оскільки від цього також залежить якість складеного розкладу задач.
Розробка вирішення завдань може здійснюватись за різними алгоритмами,
декотрі із них для правильної роботи повинні мати певні дані щодо завдань. У
[17, 18] показані різні класифікації алгоритмів розробки для паралельних та
розподілених обчислювальних систем. Так само в цій роботі було зроблено
описання певних алгоритмів планування. Розробка завдань для певних видів
розподілених систем має свої характеристики через різницю в архітектурі систем
та їхніми функціональними властивостями.
20

Рис. 1.2. Логічна архітектура системи планування в GRID

Отже, у роботі [16] показано 3 види високопродуктивних обчислювальних
систем, а саме кластери, Grid та Cloud системи, і показано розробку задач у
кожні. Ще наводиться порівняння деяких видів розподілених систем обробки
даних, в тому числі і з питань керування вузлами, показана в роботах [9].
Отже, у роботі [21] впорядковано інформацію про різні алгоритми до
розподілу ресурсів Grid-системи, вказано на характеристики всіх із них. Як
вказано авторами, незважаючи на наявність великої кількості робіт, присвячених
механізмам управління ресурсами Grid-системи, до цих пір ці механізми
потребують в поліпшенні.

1.3. Аналіз організації розподілених баз даних
Широке поширення використання розподілених баз даних спричиняє
обернений перехід від застосування централізованої обробки даних до
розподіленої. Винайдення технологій систем управління розподіленими базами
даних є серйозним досягненням у сфері застосування баз даних. Приводом
21
створення інформаційної системи для використання бази даних є необхідність
об’єднання всієї оброблюваної в компанії інформації у єдине ціле із
контрольованим доступом до інформації [44].
Утворення інформаційних мереж спричинює децентралізацію обробки
інформації. Децентралізований підхід в цьому випадку є відображенням
організаційної структури компанії, яка складається із філіалів, департаментів,
відділів, просторово розміщених у різних приміщеннях, причому кожний
підрозділ працює із власним набором даних. Формування розподілених баз
даних, що відображають організаційні структури підприємств, дає можливість
використовувати компанії всю інформацію, що вноситься всіма окремими
філіями, при цьому забезпечується записування даних у місцях.
Де вони найчастіше потрібні. Такі підходи до організації розподілених баз
даних покращують можливість спільного користування даними та ефективність
доступу [16]. Проблему островів допомагають вирішувати розподілені системи.
Розподілену базу даних можна уявити собі у вигляді якихось електронних
островів інформації, з погіршеним доступом, як відокремлені частини цілого. Це
становище є наслідком територіального положення, несумісності архітектури
комп’ютерів, несумісності використаних протоколів комутації. Об’єднання
відокремлених баз даних в єдину цілу частину може змінити цю ситуацію [19].
Розподілена база даних – це сукупність пов’язаних між собою логічно
подільних даних та їх описів, що розміщені фізично у певній комп’ютерній
мережі. Розподілена система керування базою даних (РСУБД) – це програмна
система, керуюча розподіленими базами даних та яка робить можливим розподіл
інформації прозорим для користувача бази даних. Розподілена система
керування базою даних являє собою єдину логічну базу даних, подільну на
декілька частин. Кожна частина бази записується у своєму вузлі мережі, всі вузли
об’єднані комунікаційною мережею і кожен керований своєю СУБД. Всі кінцеві
користувачі бази виконують операції над даними кожен у своєму вузлі окремо,
незалежно від іншої частини системи, тобто існує певна локальна автономія. У
22
той же час кожен користувач може звертатись до інших вузлів та обробляти
розміщені на інших комп’ютерах мережі дані [14].
Користувачі взаємодіють із розподіленою базою даних через додатки.
Локальні додатки не мають доступу до даних на інших вузлах, глобальні додатки
потребують повний доступ. Розподілена база даних зазвичай має один
глобальний додаток, із-за чого РСУБД володіє такими властивостями: збережена
інформація розбита на певну кількість частин, між якими проводиться реплікація
даних. Частини та їхні репліки розміщені у різних вузлах. Вузли поєднані у
мережу. Робота з інформацією у певному вузлі управляється СУБД, СУБД
певного вузла підтримує автономну роботу локальних додатків. Реплікація
полягає у підтриманні актуальності репліки, тобто копії, певної частини бази у
кількох окремих вузлах. Немає потреби створювати окремі повноцінні бази
даних у кожному вузлі, що пояснено на основі РСУБД [18].
Із означення РСУБД випливає, що кінцевий користувач бази не повинен
відчувати розподіленість бази, тобто система має бути повністю прозора, або
невидима, тобто мати вигляд нерозподіленої системи. Інколи цю властивість
називають базовим принципом будови розподілених СУБД [15].
Покажемо, яка різниця існує між розподіленою обробкою інформації та
розподіленими СУБД. Розподілена обробка – це обробка із застосуванням
центральної бази даних, доступ до якої може реалізуватися за допомогою будь-
якого комп'ютера мережі. Базовим поняттям визначення розподіленої бази даних
є твердження, що система оперує фізично розподіленими по мережі даними. У
випадку централізованого зберігання інформації, навіть тоді, коли доступ має
будь-який користувач мережі, ця система підтримує розподілену обробку
інформації, але при цьому не є розподіленою СУБД. Таку структуру взаємодії
часто називають «клієнт-сервер» [14].
Система «клієнт-сервер» є такою системою, коли в ній є вузли-клієнти та
вузли-сервери. Уся інформація записується на серверних вузлах, а додатки
виконуються на вузлах-клієнтах і локальної автономії не існує. Клієнт – процес,
який надсилає запит на обслуговування. Структура клієнт-сервер надає додаткам
23
доступ до інформації, розміщеної на сервері. Це основна функція такої будови;
при цьому декілька клієнтів користуються одним сервером [6].
Наведемо декілька прикладів реалізації основної схеми:
− декілька клієнтів разом користуються одним сервером;
− певний клієнт використовує декілька серверів.
Така можливість, у свою чергу, ділиться на два випадки [11]:
1) Клієнт має доступ до одного сервера за один раз, тобто кожний окремий
запит до бази даних повинен бути спрямований на один сервер. В межах одного
запиту не можна одержати інформацію із двох або більше різних серверів. Крім
того, користувачу необхідно знати, на якому саме сервері зберігається та чи інша
інформація.
2) Клієнт може мати одночасний доступ до декількох серверів, тобто
окремий запит може з’єднати дані з декількох серверів. А це означає, що кілька
серверів взаємодіють із клієнтом так, начебто це насправді один сервер.
Користувач не повинен знати, які частини даних записані на певних серверах.
Але у другому випадку по суті описано принцип роботи системи розподіленої
бази даних. Це не те, що мають на увазі під терміном «клієнтсервер».
Паралельна СУБД – це система керування базою даних, що працює з
використанням кількох процесорів і пристроїв жорстких дисків, а це допомагає
їй розпаралелити забезпечення виконання певних операцій з метою покращення
загальної продуктивності обробки. Використання паралельних СУБД дозволяє
об'єднати кілька малопотужних комп’ютерів для одержання такої ж
продуктивності, що й у випадку одного, але потужнішого комп’ютера [12].
Спільний доступ кільком процесорам до однієї і тієї ж бази даних паралельна
СУБД має забезпечити керуванням спільним доступом до ресурсів. Спосіб
поділу ресурсів на практиці чинить вплив на характеристики системи [19].
Основні типи архітектури паралельних СУБД (рис.1.3) такі:
− системи із поділами пам'яті;
− системи із поділами дисків;
− системи без поділів.
24

Рис.1.3. Архітектура з паралельною обробкою (а – з розподілом пам’яті,
б – з розподілом дисків, в – без розподілу)

Систему без поділів інколи вважають розподіленою СУБД. В паралельних
системах розміщують інформацію виключно з міркувань ефективності. За звичай
розділені територіально вузли керуються незалежно один від одного та
сполучені між собою малопотужними мережними зв’язками. Вузли ж
паралельних СУБД часто розміщені на одній машині чи в одному й тому ж вузлі
[12].
В системі із поділом пам’яті міститься декілька процесорів, і вони
розділюють системну пам’ять (рис. 1.3, а). Цю архітектуру називають також
симетричною багатопроцесорної обробкою. Її використовують у різноманітних
обчислювальних платформах, від персональних ПК, включаючих невелику
25
кількість паралельно працюючих мікропроцесорів, до потужніших RISC-систем
і до мейнфреймів. Така архітектура реалізує швидкий доступ до інформації для
певної кількості процесорів, що не перевищує 64. При зростанні кількості
процесорів мережні взаємозв’язки обмежують продуктивність системи.
Системи без поділу інакше називають системами із масовою паралельною
обробкою (рис.1.3, в). У таких системах кожний процесор має свою власну
оперативну й дискову пам'ять. База даних розділяється між усіма дисковими
пристроями обчислювальних підсистем, зв'язаних із цією базою даних. Тому тут
усі дані прозоро доступні користувачам кожної із обчислювальних підсистем.
Така архітектура забезпечує вищу масштабованість, ніж системи з поділом
пам'яті, і дозволяє легко організувати підтримку роботи великої кількості
процесорів. Однак лише у випадку, коли необхідні дані записуються локально, є
можливість досягти максимальної продуктивності.
У системах із поділом дисків кожен процесор має безпосередній доступ до
всіх спільно використовуваних дискових пристроїв, але має власну оперативну
пам'ять (рис.1.3,б). Ці системи підходять для додатків із високоцентралізованим
управлінням та якісно надають можливості щодо доступу і продуктивності
роботи. У цих системах, як і у системах з архітектурою без поділу, немає
недоліків із-за поділу пам’яті без додаткового навантаження системи процесами
фізичного розподілу даних на різних машинах. Подільні дискові системи
називають кластерами. Паралельні технології зазвичай застосовують в системах,
що повинні забезпечувати проходження тисяч транзакцій за секунду, чи – у
випадку набагато більших баз даних – 1-2 терабайти. Ці системи мають
підтримувати короткий час реагування на запит до бази даних і повинні мати
доступ до величезної кількості інформації [51].
Розподілені СУБД поділяють на гомогенні і гетерогенні. В гомогенній
системі всі вузли використовують один і той же тип СУБД. Якщо ж у вузлах
використовуються різні типи СУБД із різними моделями даних – реляційні,
мережні, ієрархічні – то ця система називається гетерогенною. Простими у
проектування та супроводженні є гомогенні системи. Ці РСУБД дають
26
можливість покроково збільшувати розмір системи, додаючи вузли до існуючої
системи. У випадку ж організації в різних вузлах паралельної обробки даних
підвищується продуктивність всієї системи [45].
Гетерогенні системи утворюються приєднанням до існуючої розподіленої
системи незалежних вузлів із своїми власними системами керування баз даних.
В гетерогенній системі для ефективної взаємодії різних вузлів з різними типами
СУБД необхідно реалізувати транслювання переданих повідомлень. Кінцевий
користувач будь-якого вузла може мати можливість створювати свої запити
мовою СУБД, що застосовується у цьому вузлі. Це називається прозорістю по
відношенню до використаної СУБД.
Система має забезпечувати розміщення інформації та виконання
трансляції запитів. В загальному випадку інформація може бути затребувана з
вузла, що має інший тип обладнання, або інший тип СУБД, або і те, й інше [24].
Якщо використано інший тип обладнання, але така ж СУБД, то для
трансляції необхідна заміна кодів та зміна довжини слова. Коли ж СУБД різні,
то потрібно відображення структури даних однієї бази перетворити в структуру
іншої. Наприклад, відношення у реляційній моделі даних мають бути переведені
в типові записи і набори. Також потрібно перетворити текст запитів із однієї
мови оперування даними на іншу. У випадку, коли різні і тип обладнання, і тип
застосованої СУБД, треба використати два види перетворення [155, 201].
Інші проблеми з’являються у випадку створення єдиної концептуальної
схеми. Утвореної шляхом об’єднання незалежних локальних концептуальних
схем. Прийнятним вирішенням, яке застосовують у певних реляційних системах
для прозорості щодо застосування СУБД, є у використанні шлюзів. До складу
різних вузлів гетерогенних розподілених систем повинні бути включені шлюзи,
що виконують трансформацію мови і моделі даних кожного з типів СУБД у мову
та модель даних реляційної системи. Цей підхід має ряд проблем. Бо шлюзи не
дозволяють створити систему керування транзакціями для окремих пар систем.
Тобто шлюз між однією парою систем є транслятором запитів. І не дозволяє
розв’язати проблеми, створені однорідністю структур в різних системах .
27
Сформована робоча група - Specification Working Group - SWG має навести
специфікації, що регламентують інфраструктуру середовища бази даних:
− уніфікований і потужний інтерфейс мови SQL (SQL API), на якому
формуються клієнтські додатки так, щоб вони не були прив'язані до
конкретного типу використовуваної СУБД;
− уніфікований протокол доступу до бази даних, що дозволяє СУБД
одного типу безпосередньо взаємодіяти із СУБД іншого типу, без
необхідності використання якого-небудь шлюзу;
− уніфікований мережний протокол, дозволяє здійснювати взаємодії
СУБД різних типів.
Найважливішою є задача знаходження способів за одну транзакцію
здійснювати обробку даних, записаних у кількох базах, які керуються СУБД
інших типів, без застосування шлюзу.
Різновидом розподіленої СУБД можна вважати мультибазові системи.
Мультибазова система – розподілена система керування базами даних, у
якій керування кожним з вузлів проходить зовсім автономно. В таких системах
проводиться об’єднання таких розподілених систем баз даних, в яких керування
окремими локальними системами у повній мірі виконується операторами. Повна
автономія вузлів дозволяє не проводити які-небудь зміни в локальних СУБД.
Отже, мультибазові СУБД вимагають створення на існуючих локальних
системах ще одного рівня програмного забезпечення, який призначено для
виконання необхідної функціональності. Мультибазові системи дозволяють
кінцевому користувачу різних вузлів мати доступ і спільно використати дані без
необхідності фізичного об’єднання існуючих баз даних [19].
Вони надають користувачеві можливість керувати базами даних їхніх
власних вузлів без якого-небудь централізованого управління, що завжди є
присутнім у звичайних типах РСУБД. Адміністратор локальної бази даних може
реалізувати доступ до деяких частин своєї бази даних за допомогою створення
схеми експорту, яка визначає, до яких елементів локальної бази даних зможуть
одержувати доступ зовнішні користувачі [18].
28
Мультибазова СУБД прозорим образом розташовується над існуючими
базами даних і файлових системах, представляючи їх своїм користувачам як
певну єдину базу даних. Таке оперування глобальною схемою дозволяє
користувачам на базі цієї схеми формувати запити й змінювати дані.
Мультибазова СУБД працює тільки із глобальною схемою, тоді як
локальні СУБД за допомогою власних засобів забезпечують підтримку даних
всіх користувачів. Глобальна схема формується за допомогою об’єднання схем
локальних баз даних. Програмне забезпечення мультибазової СУБД спочатку
транслює глобальні запити й перетворює їх у запити й оператори модифікації
даних відповідних локальних СУБД. Отримані після виконання локальних
запитів результати об’єднуються в один спільний результат, що надається
користувачеві [16].
Крім того, мультибазова СУБД здійснює управління за виконанням
фіксації або відкоту окремих операцій глобальних транзакцій локальних СУБД,
а також проводить збереження цілісності інформації у всіх локальних базах
даних. Програми мультибазової СУБД керують різними шлюзами, за допомогою
яких управляють роботою локальних СУБД [6].
Будь-яке відношення може бути поділено на частини або фрагменти при
організації фізичного зберігання цього відношення. Фрагменти розподіляють у
різних вузлах. Якщо у фрагмент виділяється підмножина кортежів відношення,
то він називається горизонтальним фрагментом. Фрагмент називається
вертикальним, якщо в ньому використовується підмножина атрибутів
відношення. Визначення і розміщення фрагментів повинні проводитися на
основі аналізу найбільш важливих застосунків, що визначають особливості
використання бази даних [46].

1.4. Дослідження існуючих підходів до вирішення задач управління
розподіленими базами даних
Децентралізоване керування розподіленими системами передбачає
наявність кількох елементів системи, які мають відповідають за керування
29
обробкою пакетів у всій розподіленій системі обробки даних і є рівноправними
між собою. При цьому керуванні обробкою пакетів черга задач, відповідно, теж
є розподіленою і не повинна контролюватися одним елементом розподіленої
комп’ютерної системи. Таким чином, при децентралізованому керуванні такі
процеси визначення відповідних вузлів, планування маршруту та інші
розподілені між компонентами розподілених систем обробки даних таким
чином, що якщо один з вузлів керування комп’ютерної мережі виходить з ладу,
то інший бере на себе його функції керування [15]. Необхідно зауважити те, що
розподілені системи обробки даних з децентралізованим керування вузлами є
дуже масштабованими, оскільки у них легко додаються або видаляються
компоненти. Звідси, децентралізація керування розподіленими системами
обробки даних, реалізована з використанням моделі однорангової мережі (P2P),
яка може замінити обмеження централізованого та ієрархічного керування
вузлами по відношенню до масштабованості, відмов вузлів баз даних та
автономності, але загальний децентралізований характер комп’ютерної системи
виникають й інші проблеми при пошуку вузлів, плануванні передачі пакетів,
розміщенні запитів на вузли, координації виконання запитів тощо [19].
Іншими проблемами при децентралізованому керуванні є застосування в
області керування розподіленими базами даних, забезпечення загального
керування функціонування системи, забезпечення елементів безпеки та
автентичності користувачів системи, врахування неоднорідності політики
розподіленої системи обробки даних [14].
При децентралізовану керуванні ресурсами планування виконання запитів
може проходити двома способами: планування з використанням координації та
без неї. У цьому випадку компоненти розподіленої системи обробки даних,
відповідальні за планування, обробляють пакети незалежно один від одного. Як
показано в [19], у такому разі виникають проблеми з покладанням навантаження
на вузли та використанням спільних вузлів баз даних. При плануванні з
координацією потрібно робити узгодження використання вузлів між тими
30
компонентами комп’ютерної системи, які беруть участь у процесі необхідного
планування.
Ефективність розподіленої системи обробки даних з децентралізованим
керуванням залежить від необхідного рівня координації і робота між
компонентами, які приймають участь в керуванні ресурсами розподіленої
системи [19]. Координація проводиться між учасниками та реалізується з метою
підвищення швидкості обробки даних в розподіленій системі і може базуватися
на різних механізмах та методах. Досить часто для роботи такої координації
потрібно використовувати велику кількість моделей. При чому, процес
координації проводить динамічний обмін даними між компонентами
комп’ютерної системи. Відповідно [10] потрібно виділити різні методи для
обміну інформацією, а саме: загальнодоступна трансляція необхідних даних,
вибіркова трансляція розподілених даних. Необхідно враховувати те, що будь-
яка обробка пакетів обов’язково збільшує навантаження на канали зв’язку
розподіленої системи обробки даних, а це призводить до погіршення відповідних
показників функціонування комп’ютерної системи, особливо коли вона
розміщена на великій кількості вузлів.
Іншим видом проблем при роботі розподіленої системи обробки даних з
децентралізованим керуванням є задачі в областях безпеки та довірчого
керування. Як показано у [107], при використанні безпечної децентралізованої
розподіленої комп’ютерної системи повинні бути вирішені такі питання
виконання безпеки системи:
− збереження конфіденційності користувачів;
− забезпечення автентичності користувачів;
− забезпечення виконання надійної авторизації;
− забезпечення виконання надійної передачі даних між розподіленими
системами.
Оцінка функціонування розподілених систем обробки даних проводиться
за різними параметрами в залежності від поставленої мети функціонування
розподіленої системи. З точки зору керування розподіленою комп’ютерною
31
системою з використанням баз даних є такі параметри, як продуктивність,
захищеність, надійність та швидкість передачі даних в каналах зв’язку. Оцінка
функціонування розподілених систем обробки даних проводиться за кількома
параметрами, які розглядаються в комплексі з питаннями керування. Розглянемо
оцінку функціонування розподіленої системи обробки даних в якій
використовуються бази даних по кожному з цих параметрів окремо [18].
Продуктивність розподіленої системи обробки даних визначається як
кількість «обчислювальної роботи», яку виконує розподілена система обробки
даних за одиницю часу або за відповідний проміжок часу.
Відповідно до факторів, які впливають на такий параметр, як
продуктивність розподіленої системи, є: склад вузлів, розмір даних, часові
характеристики обробки в пам’яті, структура та пропускна спроможність
розподіленої системи, програмне забезпечення розподіленої системи обробки
даних [197].
Відповідно є різні параметри оцінки продуктивності системи, наприклад,
прискорення відповідних обчислень, пікова продуктивність та ефективність
застосування комп’ютерної системи. Також, науковці розробляють нові
механізми в оцінці параметрів продуктивності розподілених систем обробки
даних, наприклад, в [19] запропоновано метод для оптимальної оцінки
продуктивності розподіленого середовища для інфраструктури типу сервіс
(IaaS), платформи типу сервіс (PaaS) та системного програмного забезпечення
(SaaS) типу сервіс з використанням на різних рівнях абстракції.
Найважливішим показником функціонування розподіленої комп’ютерної
системи є надійність. Вона визначається, як комплексна властивість розподіленої
системи, яка полягає в здатності обробляти пакети з даними відповідно до
функцій, при цьому повинні зберігатися всі основні параметри у визначених
межах [50]. Відповідно, до показників надійності слід віднести ймовірність
безвідмовної роботи та визначення середнього напрацювання на відмову. В
сучасних розподілених системах крім традиційних показників надійності
можуть бути застосовані і нові аспекти функціональної стійкості, а саме:
32
адаптивність, живучість та відмовостійкість. [66], відповідно виникає проблема
живучості розподілених комп’ютерних систем, так як живучість комп’ютерних
систем є більш широким поняттям, чим визначення надійності комп’ютерних
систем [14].
В останні роки появилося безліч наукових робіт, які присвячені
дослідженню живучості розподілених систем обробки даних [33]. Як зазначають
науковці, відповідно до класу розподілених систем, їх складності,
організованості та відповідного рівня проведення аналізу, властивість живучості
може бути оцінена як стійкість, адаптивність, надійність, відмовостійкість [60].
Під час створення розподілених систем обробки даних на базі
комп’ютерних мереж потрібно враховувати велику кількість параметрів, у тому
числі швидкість обробки даних в вузлах та передачі по каналах зв’язку [68]. У
розподіленій системі обробки даних по каналах зв’язку проходить передавання
вхідних даних для обробки в вузлах баз даних та відповідно передача відповідей
назад по каналу. Крім того, розширюється застосування спільного використання
розподілених систем та розподіленої обробки, що призводить до використання
розподілених систем обробки даних, таки як Grid-систем та Cloud-систем, а
також сховищ даних [13]. Відповідно до цього у комп’ютерній системі
обробляються великі об’єми даних та виникає необхідність швидкої передачі їх
каналами зв’язку між вузлами, а також виконання реплікацій, які також
передаються по комп’ютерній мережі. У роботі [15] було досліджено вплив
затримок пакетів при передачі даних в розподілених системах обробки даних
таких як Grid-система. Отже, при дослідженні розподілених систем обробки
даних виникає необхідність отримувати параметри для каналів зв’язку між
вузлами.
Об’єднання багатьох географічно розміщених вузлів комп’ютерної
системи у єдину розподілену мережу через відкриті канали зв’язку повинно
накладати необхідні вимоги для забезпечення безпеки розподілених ресурсів
таких систем [18]. Захищеність розподілених систем обробки даних є мірою
безпечності комп’ютерної системи та базується, відповідно, на використанні
33
захисту ресурсів від загроз, які повинні бути прокласифіковані із врахуванням
будь яких порушень безпеки системи [19]. Рівень захищеності системи буде
оцінюватися в межах від 0 – це буде не захищений ресурс до 1 – це буде
абсолютно захищений ресурс. Відповідно до оцінки захищеності розподілених
систем обробки даних потрібно враховувати безпечність внутрішнього
середовища, так як воно є середовищем передачі пакетів з даними між
ресурсами. Забезпечення відповідного захисту ресурсів розподілених систем
обробки даних здійснюється шляхом використання організаційно-технічних
засобів.
Часто при виборі вузлів потрібно враховувати багато параметрів
функціонування розподілених систем обробки даних в комплексі, тому важливо
розробити відповідні механізми, які б могли забезпечити таку можливість [17].

Висновки
Проаналізовано недоліки, які виникають в процесі реалізації та
функціонування сучасних систем управління розподіленими базами даних та в
самих базах даних при обробці великих обсягів даних. Показано, що для
підвищення ефективності процесів запису та пошуку даних в базах даних
необхідно застосовувати спеціальні механізми управління та розподілення
вузлів баз даних.
Досліджено загальну концепцію побудови розподілених реляційних бази
даних. Показано, що на етапі логічного проектування повинна враховуватися не
тільки специфіка конкретної моделі даних, а і галузь в які застосовуватиметься
дана база даних. Запропоновано розширену класифікацію баз даних, яка
дозволяє в повній мірі віднести базу даних до відповідної області. Розглянуто
особливості організації побудови розподілених систем управління базами даних.
Показано, що існуючі СУБД різного типу, не забезпечують необхідний набір
функцій для підтримки розподілених баз даних.
Розглянуто сучасний стан розподілених баз даних, які використовують
різні механізми керування ресурсами розподілених систем обробки даних.
34
Основна увага була приділена децентралізованому керуванню вузлами
розподіленої системи. Перевагами децентралізовано керування ресурсами є
високий рівень автономності вузлів, стійкість до відмов системи, доступність та
масштабованість комп’ютерної системи, а основними недоліками – відсутність
інформації про систему обробки даних та жодного з її компонентів, що значно
ускладнює прийняття рішень керування щодо розподілу запитів між вузлами,
контроль виконання запитів та забезепечення роботи системи без відмов, а також
складність реалізації.
35
РОЗДІЛ 2
МОДЕЛЬ ЗАБЕЗПЕЧЕННЯ АВТОМАТИЗОВАНОЇ РОБОТИ
РОЗПОДІЛЕНИХ БАЗ ДАНИХ

2.1. Механізм обробки запитів в розподіленій системі обробки запитів
Обробка запитів в розподіленій системі обробки даних, що складається з
вузлів та каналів зв’язку між ними, проводиться за рахунок вузлів в яких
розміщені бази даних. Кількість даних вузлів залежить від периметру
розподіленої системи та кількість каналів між вузлами залежить від технічних
характеристик обладнання та способів його з’єднання.

Рис. 2.1. Приклад розподіленої системи обробки даних з десяти вузлів

На рисунку 2.1 представлено приклад розподіленої системи, яка
складається з десяти вузлів. На схемі чорним кружком зображено вузол, який в
даний момент часу здійснює керування системою, сірий кружок – вузол, в якому
встановлене відповідне програмне забезпечення та який в любий момент часу
може стати керуючим замість першого. Вузли з сірим ободком та білою
серединою – це вузли в яких встановлено систему управління базами даних та
розміщено відповідні таблиці з даними, а в вузлах з сірим ободком та білою
36
сірою серединою – це вузли в яких встановлено систему управління базами
даних та розміщено відповідні таблиці з даними, але які є реплікаціями. В пустих
кружках розміщені проміжні вузли, які виконують функції маршрутизації.
Дана формальна система забезпечує доступ до даних шляхом передачі
пакетів по мережі, яка зображена лініями. Канал з якої надходять та
повертаються пакети – запити до розподіленої системи позначається стрілкою. В
кожного вузла є своя продуктивність , а в кожного каналу зв’язку є своя
швидкість передачі даних . Від цих двох параметрів залежить швидкість обробки
та доставки пакету запиту до бази даних та пакетувідповіді до користувача.
Опишемо загальний механізм обробки запиту в розподіленій системі.
Як показано на рисунку 2.2 користувач формує запит до бази даних та
відправляє його через мережу, при цьому пакет проходить через проміжні вузли
та попадає на вузол керування. Вузол керування здійснює функції розподілу
пакету – запиту на множину пакетів, у яких містяться підзапити до різних вузлів
бази даних та здійснює формування маршруту для кожного підзапиту до
відповідного вузла бази даних. При проходженні пакетів з підзапитами до вузлів
бази даних вони можуть проходити через проміжні вузли, які просто здійснюють
маршрутизацію.
В вузлі бази даних через відповідний порт, який використовує система
управління базами даних (наприклад у Oracle це служба Listener) запит попадає
в базу даних та обробляється відповідно до свого типу. Сформовану відповідь
вузол бази даних передає по проміжних вузлах, які здійснюють маршрутизацію
до вузла керування. В вузлі керування пакети з підзапитами обробляються та
створюється загальний пакет відповідь, який через проміжні вузли
відправляється користувачу.
Даний механізм показує обробку запитів в розподіленій системі в якій
розміщені вузли бази даних. Для детального опису потрібно розглянути роботу
вузла керування, а саме описати механізми за допомогою яких працює
планувальник та брокер.

37

Рис. 2.2. Загальний механізм обробки запиту в розподіленій системі

Планувальник, програма в які проходить обробка пакетів – запитів,
розділення їх на відповідні логічні елементи, множина яких потім передається
брокеру. Як показано на рисунку 2.3 в планувальнику розміщено наступні
модулі: модуль обробки вхідних пакетів, модуль розбиття пакету на множину
запитів, модуль передачі запитів брокеру, модуль обробки відповідей від
брокера, модуль обміну даними з планувальниками, модуль об’єднання
відповідей та модуль відправки вихідних пакетів.
Опишемо роботу кожного модуля планувальника керуючого вузла та
структуру механізмів взаємодії. Модуль обробки вхідних пакетів – служба,
вузла, яка приймає вхідний пакет – запит та перетворює його в формат для
обробки та передає до модуля розбиття пакету на множину запитів. У ньому
проводиться розбиття пакету на множину запити, яка буде відправлятися до
38
різних вузлів бази даних та за допомогою модулю взаємодії з брокером готує
множину пакетів для відправлення по маршруту в різні вузли розподіленої
системи обробки даних та передає пакети з підзапитами до вузлів розподіленої
системи в яких лежать бази даних.

Рис. 2.3. Схема роботи планувальника вузла керування

Після отримання відповіді відповідей від брокера через модуль обробки
відповідей проводиться перевірка наявності відповідей на всю множину запитів,
якщо якась відповідь відсутня, то через модуль обміну даними з
планувальниками запит передається в іншу мережу до вузла керування, а там
через планувальник обробляється. Якщо присутні відповіді на всю множину
39
запитів, то вони перетворюються, через модуль об’єднання відповідей, в єдиний
пакет – відповідь, який через модуль відправки вихідних пакетів відправляється
до користувача.
Для підготовки маршрутів доставки пакетів – запитів використовується
брокер, робота якого зображена на рисунку 2.4, основним завданням його є вибір
по маршруту відповідно до матриці відповідності. Матриця відповідності – це
матриця в якій вказано на яких вузлах лежать частини розподіленої бази даних і
які таблиці в цих частинах лежать.
В структурі брокера представлені наступні модулі: модуль отримання
завдання від планувальника, модуль визначення маршрутів, модуль передачі
запитів, модуль отримання відповідей, модуль перевірки відповідей, модуль
передачі відповідей планувальнику.
Після того, як пакет планувальником було розбито на множину запитів,
вони потрапляють до брокера через модуль отримання завдання від
планувальника та передаються до модулю визначення маршрутів для запитів.
Там проводиться співставлення таблиць, які потрібні для виконання
запитів та вузлів в яких лежать бази даних з цими таблицями відповідно до
матриці відповідності, будуються маршрути по яких, через модуль передачі
запитів, відправляються пакети. Після обробки пакетів вузлами з базами даних,
вони повертаються в керуючий вузол та передаються брокеру через модуль
отримання відповідей. Дальше проводиться перевірка відповіді на правильність
маршруту та вузла бази даних з якого він прийшов. Після цього, через модуль
передачі відповідей планувальнику вони передаються планувальнику, який і
продовжує подальшу обробку.
Описані вище механізми дозволяють обробляти пакети – запити, які
прийшли в управляючий вузол та відправляти їх до вузлів в яких розміщені
відповідні бази даних. Дане програмне забезпечення (планувальник та брокер)
повинно бути записане та синхронізоване на всіх керуючих та потенційно
керуючих вузла для того, щоб мати можливість постійно обробляти запити від
користувачів та відправляти їм відповідь.
40

Рис. 2.4. Схема брокера вузла керування

Проведено дослідження особливості обробки пакетів – запитів
розподіленій системі обробці даних з гетерогенними розподіленими базами
даних з використанням вузлів керування. Визначено основні елементи вузла
керування та описані їх алгоритми роботи по обробці пакетів. Показано, що для
управління розподіленою системою обробки даних необхідно застосовувати в
вузлах керування механізми планувальника роботи та брокера роботи вузла
керування.

2.2. Формальне представлення розподіленої системи обробки даних
Розподілену систему обробки даних формально представимо як набір
вузлів з відповідним програмним забезпеченням та набір каналів між ними по
41
яких проводиться передача пакетів з запитами. Вузли можуть бути розміщені як
на звичайних персональних комп’ютерах з одним процесором та кількома
ядрами (фізичними та логічними) так і на серверах та кластерах з
багатопроцесорною обробкою даних та великим об’ємом оперативної пам’яті.
Канали зв’язку між вузлами системи можуть бути як провідні так і безпровідні.
Провідні канали можуть бути побудовані на обладнанні, яке використовує
оптичний кабель так і коаксіальний.
Безпровідні канали можуть використовувати різні технології передачі
даних такі як: wi-fi, телефонний зв'язок (наприклад технологію 5G) так і
супутниковий канал зв’язку.
Вузли розподіленої системи обробки даних можна охарактеризувати
набором параметрів, такими як продуктивність, об’єм оперативної пам’яті, об’єм
жорсткого диску, надійність. Також до характеристики вузла можна віднести
наявність на ньому бази даних та програми для керування розподіленою
системою. Канали зв’язку розподіленої системи обробки даних
характеризуються пропускною здатністю, захищеністю.
Розглянемо розподілену систему обробки даних, як систему яка працює з
гетерогенними базами даних та вузлами керування. Під топологією мережі
будемо розуміти багатоканальну систему з можливістю вибору маршрутів для
передачі даних, які пов’язані між собою надлишковою системою зв'язку.
Потрібно формально описати розподілену систему обробки даних та її
параметри, як надійного і захищеного середовища передачі даних.
Представимо розподілену систему обробки даних, як множину вузлів та
зв’язків між ними:

DDPS = (N, CH),

де N – множина вузлів розподіленої системи обробки даних,
CH – множина каналів зв’язку між вузлами розподіленої системи обробки
даних.
42
При цьому

де n – кількість вузлів в розподіленій системі обробці даних.
Також

де c– кількість каналів системи.
В розподіленій системі обробки даних будемо використовувати наступні
параметри:
– продуктивність вузла розподіленої системи обробки даних, яка
вимірюється в мільйон інструкцій в секунду (МІ). Для простоти розрахунків
будемо рахувати, що кількості операцій за секунду буде достатньо, щоб
вирахувати час обробки пакетів з запитами.
– надійність вузла розподіленої системи обробки даних,
значення якого змінюється від 0 до 1.
– присутність програмного забезпечення баз даних вузла
розподіленої системи обробки даних, який приймає значення 0 – якщо в вузлі
відсутня база даних та 1 – якщо в вузлі присутня програмне забезпечення
системи управління базами даних.
– для каналу зв’язку пропускна здатність
(швидкість передачі даних ) та затримка обробки пакету відповідно. При чому
затримка передачі пакетів по каналу враховує час підготовки та перетворення
даних при передачі до вузла розподіленої системи обробки даних. Затримка
передачі пакетів також враховує час маршрутизації при проходженні по мережі.
43
В різних видах маршрутизації різні методики визначення затримки комутації та
вона залежить ще і від технологій, які застосовують в мережі.
– надійність вузла розподіленої системи обробки даних,
значення якого змінюється від 0 до 1.
Крім того потрібно поділити вузли розподіленої системи обробки даних за
видами:
N – загальна кількість вузлів системи, яка постійно змінюється в
залежності від появи зв’язку з новими вузлами та зникнення зв’язку з вузлами,
які уже в розподіленій системі обробки даних.
M – загальна кількість потенційних вузлів в яких встановлене програмне
забезпечення для керування розподіленою системою обробки даних, яка
постійно змінюється в залежності від загальної кількості вузлів системи.
K – загальна кількість вузлів в яких розміщені системи управління базами
даних, кількість їх реплікацій може змінюватися в залежності від загальної
кількості вузлів системи.
B – загальна кількість проміжних вузлів, які виконують роль в
маршрутизації пакетів в розподіленій системі обробки даних з використанням
баз даних.
При проектуванні та побудові розподілених систем обробки даних
обов’язково повинні враховуватися характеристики комп’ютерної мережі, яка
використовується. При побудові методів вибору кількості вузлів керування та
кількості вузлів з базами даних (в тому числі кількість реплікацій) важливо
визначити кількість вузлів та каналів зв’язків між ними. Можна представити таку
структуру графом, а для визначення залежності між кількістю вузлів та кількістю
каналів зв’язку потрібно визначити вид графу. Наприклад для повного графу
можна визначити залежність кількості вузлів від кількості каналів зв’язку:

44
Як показують експерименти розподілена система обробки даних містить
приблизно в два рази менше каналів зв’язку в порівняні з повним графом, тому
праву частину формулу треба ще поділити на 2.
Для повного розробки в подальшому моделі обробки запитів в
розподілених системах обробки даних з використанням баз даних потрібно
визначити всі характеристики вузлів та каналів зв’язку, а також залежності між
ними.
Для розподіленої системи обробки даних продуктивність визначається за
допомогою обчислювального прискорення (Computational Acceleration). Воно
розраховується за формулою:

де – час виконання задачі в одному вузлі, а – час виконання цієї
задачі в розподіленій системі обробки даних. Вузли розподіленої системи
містять різне програмне забезпечення, яке змінює продуктивність їх, а також
впливає на обчислювальне прискорення.
Проведемо аналіз впливу параметрів розподіленої системи обробки даних
на обчислювальне прискорення. В літературних джерелах втори досліджують
вплив різних механізмів на затримки передачі пакетів в розподіленій системі
обробки даних, а саме:
− встановлення з’єднання для ініціювання передачі пакету;
− перевірка активності сервера;
− передача даних від вузла керування та вузла бази даних та передача
результатів у зворотному напрямку;
− виникнення черги обробки пакетів в вузлі в якому встановлене керуюче
програмне забезпечення;
45
− виникнення черги обробки запитів в вузлі в якому встановлено систему
управління базою даних.
В розподіленій системі обробки даних з використанням баз даних потрібно
виконати обробку запиту, обчислювальна складність цієї операції складає МІ.
Для спрощеного проведення обчислень приймемо наступне: обчислювального
вузла системи розраховується, як середнє значення усіх продуктивностей вузлів
розподіленої системи обробки даних, а саме:

Тоді час, необхідний для обробки одного пакету в вузлі, обчислимо

Для визначення часу, який потрібно витратити на обробку одного і того
самого запиту в розподіленій системі обробки даних , врахувавши час
пересилання даних, необхідних для виконання обробки. Будемо вважати, що по
каналах зв’язку час пересилання відповідного масиву даних однаковий і
становить секунд. Тому, потрібно врахувати, що частина каналів завантажені
послідовно, а інші канали – паралельно. Приймемо твердження, що кількість
каналів зв’язку, по яких дані передаються пакети послідовно, як 50% від
загальної множини каналів розподілених систем обробки даних. Звідси можна
зробити висновок, що час виконання запиту в системі буде

46
Підставивши попередні рівняння отримаємо вираз для визначення часу
виконання запиту в розподіленій системі обробки даних:

Для отримання відповідної пронормованої функції продуктивності
розпоідленої системи потрібно поділити прискорення обчислення обробки
пакету на максимально можливий результат значення прискорення серед усіх
варіантів:

Фактично значення функції демонструє рівень прискорення по
відношенню до максимально можливого прискорення виконання обробки запиту
при заданих параметрах розподіленої системи обробки даних.
У випадку визначення продуктивності обробки запитів в розподіленій
системі обробки даних у МІPS для певної кількості вузлів можна обчислити за
формулою:

Для визначення надійності системи потрібно визначити безвідмовність
(відмовостійкість) всіх компонентів системи, а саме вузлів та каналів зв’язку.
Безвідмовність роботи – це функція яка залежить від часу та обчислюється:

47
Для визначення інтенсивності виходу ладу для всієї системи потрібно
порахувати добуток надійності роботи всіх вузлів та каналів зв’язку розподіленої
системи обробки даних.
Швидкість передачі пакетів по каналам зв’язку зростає з збільшенням
кількості каналів, а кількість яких, в свою чергу, зростає зі збільшенням кількості
вузлів розподіленої системи обробки даних з використанням баз даних.
Якщо представити все середовище як єдиний канал передачі даних, то
максимальну швидкість можна оцінити за допомогою мехінізму, який
використовує теорему про верхню межу швидкості передачі даних у системі, яка
показує залежність підвищення швидкості передачі пакетів при збільшені смуги
пропускання в каналах передачі даних.
При застосуванні принципів аналогії, потрібно визначити оцінку
швидкості передачі даних в каналах зв’язку, при багатоканальному середовищі
таким чином:

де с – кількість каналів зв’язку розподіленої системи обробки даних, яка
зв’язана з кількістю вузлів.

2.3. Модель оцінки часу обробки запитів в розподіленій системі
обробки даних з використанням розподілених баз даних
Проведемо аналіз часу обробки запитів в розподіленій системі обробки
даних та її прогнозування.
Для цього використаємо функцію множинної регресії, яка має вигляд:

48
За допомогою цієї функції можна сформувати модель з відповідним
числом початкових параметрів, які впливають на систему та визначити вплив
кожного параметру як окремо, так і на базовий показник. В нашому випадку
базовим показником буде час обробки запитів в розподіленій системі обробки
даних.
Для реалізації цієї моделі з використанням функції регресії, потрібно
вирішити наступні задачі:
1 Провести аналіз впливу початкових змінних на систему.
2 Провести формування специфікації, яка буде визначати відповідні
початкові змінні, що входять в регресійну функцію.
Для цього потрібно забезпечити специфікації моделі. Існує багато
варіантів вирішення, але найкраще підходить лінійна модель множинної регресії:

де Т– кінцевий показник часу обробки запитів, –
початкові змінні, – регресійні коефіцієнти, як часткові похідні від кінцевого
показника по відповідним початковим змінним, а саме:

49
В даному рівнянні коефіцієнт вільний член, по якому , в випадку коли всі
зміні рівні нулю, визначається значення кінцевого показника Значення
регресійних коефіцієнтів дорівнюють середній зміні кінцевого показника при
збільшенні значення любої початкової змінної на один крок та при фіксації всіх
інших початкових змінних. Величина, випадкова помилка для регресійної
залежності.
Також визначення коефіцієнтів по виборці неможливе, в зв’язку з тим, що
вони є випадковими величинами. Тоді потрібно сформувати замість
теоретичного рівняння регресії емпіричне рівняння лінійної регресії, а саме:

де – емпіричні оцінки значення коефіцієнтів або
емпіричні коефіцієнти регресії, – оцінка відхилення від
початкового.
Нехай у нас є п’ять оцінок незалежних початкових змінних і значення
кінцевого показника , який їм відповідає:

Для чіткого визначення значення параметрів рівняння кількість вимірів
повинна бути не менше кількості початкових параметрів, бо тоді виникне
ситуація, коли ми не зможемо визначити значення параметрів однозначно.
Якщо кількість вимірів буде дорівнювати кількості параметрів, то оцінки
параметрів розраховуються за принципом лінійних рівнянь однозначно. Для
того, щоб провести аналіз показників функціонування розподіленої системи
обробки даних на онові лінійної моделі множинної регресії, потрібно виконати
відповідні умови, а саме:
50
1. Специфікація моделі повинна мати вигляд:

2. Модель повинна бути не мультиколінеарною: відсутня лінійна
залежність між початковими параметрами. Це потрібно врахувати при виборі
початкових параметрів для формування специфікації моделі.
3. Значення відхилень при мають нормальний розподіл ( ).
Виконання третьої умови необхідно для перевірки статистичних гіпотез і
побудови інтервальних оцінок.
Специфікацію моделі складає набір початкових змінних. Важливе
значення мають два аспекти, які характерні для множинної регресії з кількома
змінними:
1. Потенційна мультиколінеарність.
2. Часткова кореляція, яка пов’язана з процедурою покрокового відбору
змінних.
Для включення в рівняння множинної регресії відповідного набору
початкових змінних, потрібно визначити оцінку степені взаємозв’язку
аналізуючого базового показника з іншими показниками. Початкові змінні, які
включаються у множинну регресію, повинні відповідати наступним вимогам:
1. Вони повинні бути колінеарно вимірними, а в тому випадку, коли в
модель потрібно включити якісну змінну, то її необхідно виразити через
кількість.
2. Змінні не повинні бути корельовані між собою і не повинні находитися
в однозначному функціональному зв’язку.
В загальному випадку, регресійна модель дозволяє використовувати різні
скінченні числа вхідних параметрів. Відбір початкових змінних проводиться на
основі попереднього аналізу характеру взаємодії результуючого показника. Але.
В загальному випадку, теоретичний аналіз не дозволяє однозначно відповісти на
51
питання про кількість взаємозв’язків початкових змінних і доцільності
включення тієї чи іншої змінної в модель. Звідси відбір початкових параметрів
моделі потрібно проводити в два етапи, а саме:
1. Вибирати змінні з врахуванням їх потенційного впливу на результуючий
показник.
2. Аналізувати матрицю показників кореляції та вибирати ті змінні, які
найбільше сильно зв’язані з кінцевим показником, а які між собою зв’язані
менше.
Відомо, що на час обробки запитів в розподіленій системі обробки даних
впливає час затримки передачі пакетів в комп’ютерній мережі. В свою чергу, на
показник часу затримки передачі впливають наступні параметри:
– множина вузлів (Set of Nodes) розподіленої системи обробки даних;
– множина зв’язків (Set of Connections) між вузлами розподіленої системи
обробки даних;
– множина параметрів (Set of Parameters) розподіленої системи обробки
даних.
Для формування моделі аналізу та прогнозування часу затримки пакетів в
мережі визначимо наступні кроки:
1. Вибираються початкові параметри для регресійного рівняння, а саме:

2. Розраховуються п’ять значень результуючого показника при різних
значеннях початкових параметрів .
3. Формується система лінійних рівнянь:
,
52
В результаті вирішення даної системи рівнянь розраховуються коефіцієнти
.
4. Формується вираз для аналізу часу обробки запитів в розподіленій
системі обробки даних з врахуванням відповідних коефіцієнтів, а саме:

Також відмітимо, що отримане співвідношення коректне для відповідного
фрагменту чи фрактоїду розподіленої системи обробки даних: локального
кластеру, чи локальної мережі для якої були виконанні оцінки початкових
параметрів.
Для формування регресійних функцій для всіх внутрішніх функцій моделі
потрібно вибрати функції в системі обробки запитів в розподіленій системі
обробки даних, які залежать від часу. Від часу залежить множина вузлів , яка
змінюється з часом, в зв’язку з динамічністю системи, множина зв’язків , яка
також з часом міняється, бо змінюється кількість вузлів та множина параметрів
розподіленої системи , яка також залежить від кількості вузлів і їх зміни.
В зв’язку з тим, що множина зв’язків була визначена, як матриця
суміжностей, то до неї застосовувати регресійну модель не потрібно в зв’язку з
великою кількістю зв’язків. Тому проведемо застосування регресійної моделі
для визначення коефіцієнтів для функції знаходження множини вузлів та функції
знаходження параметрів розподіленої системи.
Розглянемо приклад формування для моделі оцінки час обробки запитів в
розподіленій системі обробки даних на основі аналізу кількості вузлів в системі.
Для визначення коефіцієнтів візьмемо чотири приклади різних систем, з різною
кількістю вузлів.
Перша система буде локальна мережа однієї організації, в якій знаходяться
30 комп’ютерів, з них: 2 вузла, які виконують функцію управління (головний та
резервний), 3 вузла в яких проводиться обробка даних (налаштовані сервери баз
53
даних). Будемо рахувати, що всі інші вузли є проміжними та запити до баз даних
відправляються з любого вузла системи. Середній час обробки запитів в такій
локальній мережі становить 8 мс.
Друга система буде локальна мережа, в якій знаходяться 3000 комп’ютерів,
з них: 24 вузла, які виконують функцію управління, 16 вузлів, в яких проводиться
обробка даних (налаштовані сервери баз даних). Будемо рахувати, що всі інші
вузли є проміжними та запити до баз даних відправляються з любого вузла
системи. Середній час обробки запитів в такій локальній мережі становить 12 мс.
Третя система буде вся мереж, в якій знаходяться 20000 комп’ютерів, з
них: 44 вузла, які виконують функцію управління, 18 вузлів, в яких проводиться
обробка даних (налаштовані сервери баз даних). Будемо рахувати, що всі інші
вузли є проміжними та запити до баз даних відправляються з любого вузла
системи. Середній час обробки запитів в такій локальній мережі становить 21 мс.
Четверта система буде мережа, в якій знаходяться 18000 комп’ютерів, з
них: 23 вузла, які виконують функцію управління, 12 вузлів, в яких проводиться
обробка даних (налаштовані сервери баз даних). Будемо рахувати, що всі інші
вузли є проміжними та запити до баз даних відправляються з любого вузла
системи. Середній час обробки запитів в такій локальній мережі становить 14 мс.
В таблиці 2.1 представлені наступні параметри часу обробки пакетів в
розподіленій системі.

Таблиця 2.1.
Час обробки запитів в розподіленій системі обробки даних в залежності
від кількості вузлів системи

2 3 25 30 8
24 16 2960 3000 12
42 18 19960 20000 21
23 12 17965 18000 14
54
Тобто нам потрібно вирішити наступну систему рівнянь, яка нам дасть
можливість знайти коефіцієнти:

Вирішивши дану систему рівнянь ми знаходимо єдине правильне рішення
в вигляді:

Звідси вираз для аналізу і прогнозування часу обробки пакетів в
розподіленій системі обробки даних в залежності від кількості вузлів в системі
має вигляд:

В зв’язку з присутністю від’ємних коефіцієнтів та в рівнянні знаходження
часу обробки запитів в залежності від кількості вузлів розподіленої системи
обробки даних, потрібно накласти обмеження на змінні рівняння, а саме:

55
Таким чином, за допомогою даної моделі можна визначити показники
(коефіцієнти), які дозволяють порахувати час обробки запитів в розподіленій
системі обробки даних в залежності від кількості вузлів.
Застосуємо регресійну модель для знаходження часу обробки запитів в
розподіленій системі обробки даних в залежності від параметрів розподіленої
системи. Для цього потрібно визначити коефіцієнти взявши чотири ті ж самі
розподілені системи обробки даних з середніми показниками , а саме:
1. Локальна мережа однієї організації, в якій знаходяться 30 комп’ютерів з
наступними середніми параметрами: продуктивністю вузлів
0,11 терафлопс,120 швидкістю передачі по каналам зв’язку 5 Мбіт/с, час обробки
в вузлі бази даних 5 мс та час оновлення одного вузла керування 3 с.
2. Локальна мережа корпусів навчального закладу, в якій знаходяться
3000 комп’ютерів з наступними середніми параметрами: продуктивністю вузлів
0,9 терафлопс, швидкістю передачі по каналам зв’язку 4 Мбіт/с, час обробки в
вузлі бази даних 4 мс та час оновлення одного вузла керування 5 с.
3. Вся мережа навчального закладу, в якій знаходяться 20000 комп’ютерів
з наступними середніми параметрами: продуктивністю вузлів 0,12 терафлопс,
швидкістю передачі по каналам зв’язку 8 Мбіт/с, час обробки в вузлі бази даних
4 мс та час оновлення одного вузла керування 6 с.
4. Мережа, яка об’єднує навчальні заклади України, в якій знаходяться
18000 комп’ютерів з наступними середніми параметрами: продуктивністю вузлів
0,8 терафлопс, швидкістю передачі по каналам зв’язку 2 Мбіт/с, час обробки в
вузлі бази даних 4 мс та час оновлення одного вузла керування 6 с.
Інші два параметри розподіленої системи будемо приймати за константи,
в зв’язку з тим, що будемо вважати, що всі вузли даних систем є днаково
надійними та кількість вузлів баз даних описано вище.
В таблиці 2.2 представлені наступні параметри часу обробки пакетів в
розподіленій системі в залежності від середніх параметрів.

56
Таблиця 2.2.
Час обробки запитів в розподіленій системі обробки даних в залежності
від параметрів

0,11 5 5 3 8
0,9 4 4 5 12
0,12 4 8 6 21
0,8 2 4 6 14

Тобто нам потрібно вирішити наступну систему рівнянь, яка нам дасть
можливість знайти коефіцієнти:

Вирішивши дану систему рівнянь ми знаходимо єдине правильне рішення
в вигляді:

57
Звідси вираз для аналізу і прогнозування часу обробки пакетів в
розподіленій системі обробки даних в залежності від параметрів системи має
вигляд:

В зв’язку з присутністю від’ємних коефіцієнтів та в рівнянні знаходження
часу обробки запитів в залежності від параметрів розподіленої системи обробки
даних, потрібно накласти обмеження на змінні рівняння, а саме:

В розподілених системах обробки даних на сьогоднішній день ефективно
використовується централізоване управління, але при його застосуванні
розподілена система стає вразливою до зовнішніх атак і впливів негативних
факторів внутрішніх елементів системи.
Але розподілені системи активно переходять на децентралізоване
управління розподіленої системи з використанням баз даних, ефективність якого
залежить від координації дій учасників та взаємодію між ними. В таких системах
стоїть завдання на вдосконалення механізму координації дій між учасниками та
покращення параметрів розподіленої системи. Існують різні методи
децентралізованого управління, але самим ефективним підходом до управління
розподіленою системою обробки даних є мережецентричний механізм, який
може застосовуватися не тільки у розподілених системах, а і в різних сферах для
управління процесами діяльності людини та досягнення високої
результативності праці. Початковими засновниками і користувачами
мережецентричного підходу була оборонна промисловість, де він застосовувався
58
майже у всіх автоматизованих та управлінських системах. Через деякий час його
почали застосовувати до управління складних систем з неоднорідною
структурою.
При чому розмірність та відрізняється, але в зв’язку з тим, що ми для
розв’язку рівняння беремо просто значення змінних, а не їх розмірність, то перше
обмеження правильне.
Таким чином, за допомогою даної моделі можна визначити показники
(коефіцієнти), які дозволяють порахувати час обробки запитів в розподіленій
системі обробки даних в залежності від параметрів системи.

Висновки
Проведено дослідження особливості обробки пакетів – запитів
розподіленій системі обробці даних з гетерогенними розподіленими базами
даних з використанням вузлів керування. Визначено основні елементи вузла
керування та описані їх алгоритми роботи по обробці пакетів. Показано, що для
управління розподіленою системою обробки даних необхідно застосовувати в
вузлах керування механізми планувальника роботи та брокера роботи вузла
керування.
Розглянуто особливості формального представлення розподіленої системи
обробки даних при застосуванні мережоцентричного підходу. Визначено основні
характеристики та параметри механізмів обробки пакетів в розподіленій системі.
Визначено показники продуктивності, надійності та швидкості передачі в
розподіленій системі обробки даних. Показано, що для час обробки пакетів від
часу виконання в одному вузлі бази даних та часу виконання всіх запитів в
розподіленій системі обробки даних та для його визначення потрібно визначити
значення середньої продуктивності та час пересилання пакету по каналам
зв’язку.
Запропоновано модель обробки запитів в розподіленій системі обробки
даних з використанням розподілених баз даних з динамічною структурою.
Показано, що, за допомогою накладених обмежень на всі параметри моделі
59
можна визначити структуру розподіленої системи обробки даних з
оптимальними параметрами системи, бази даних та вузла керування, що
дозволить скоротити час обробки пакетів – запитів до гетерогенних розподілених
баз даних.
60
РОЗДІЛ 3
РЕАЛІЗАЦІЯ МЕХАНІЗМІВ УПРАВЛІННЯ РОЗПОДІЛЕНИМИ
БАЗАМИ ДАНИХ З ДИНАМІЧНОЮ СТРУКТУРОЮ

3.1. Розробка середовища для дослідження параметрів розподілених
баз даних
Одним з механізмів опису роботи складних систем, є спеціалізоване
середовище для обробки даних в розподілених базах даних та мова UML.
Користувачі, які звертаються до розподілених баз даних в мультибазових
системах проводять пошук чи модифікацію даних по відповідних параметрах,
при чому гетерогенні СУБД повинні зробити дії по аутентифікації користувача,
провести відповідний аналіз запитів для визначиення методів обробки запитів,
модифікувати їх та перевірити (якщо потрібно) на зв’язок з іншими вузлами баз
серверів БД, тобто проводити класичний аналіз за принципами диспетчеризації.
Архітектура розподілених системи обробки даних для роботи з базою
даних повинна включати в себе 3 рівня (рис. 3.1):
1 Рівень сховища розподілених даних, на якому розміщені розподілені
бази даних та елементи зовнішніх джерел з даними.
2 Рівень керуючих вузлів, який має відповідну структуру для
забезпечення ефективного керування обробкою пакетів та відповідей
від розподілених баз даних.
3 Рівень інтерфейсів користувачів (GUI).
Рівень вузлів керування мітить такі модулі:
− модуль обміну даними, який відповідає за обмін даними по
інформаційних потоках між розподіленими гетерогенними СУБД та
зовнішніми підключеннями користувачів розподіленої системи;
− модуль адміністрування, який є основним модулем для розподілених
баз даних таповинен забезпечувати роботу та контроль усієї системи
керування вузлами з базами даних та керує ним головний адміністратор
61
серверів баз даних, а саме: управляє та налаштовує обмін даними з
іншими вузлами підмережі, керує та налаштовує роботу з пакетами у
оперативній пам’яті вузла, налаштовує роботу по журналізації,
резервного копіювання в системі управління базою даних, забезпечує
керування ядром вузлів баз даних та відповідними сервісними
програмамиз використанням зовнішніх та внутрішніх утиліт, виконує
налаштовання керування розміщенням файлів на серверах та виділення
пам’яті під відповідні процеси, керує системними таблицями та
відповіднми службами серверу, керує всіма схемами баз даних та
їхніми користувачами;

Рис. 5.1. Архітектура системи роботи з розподіленими базами даних
62
− модуль керування ролями забезпечує роботу по налагодженню доступу
користувачів баз даних, через надання ролей відповідним групам
користувачів для доступу до функцій та процедур (звичайний
користувач), таблиць, схеми бази даних, представлень, серверів баз
даних та обробки подій для моніторингу на сервері БД;
− модуль управління компонентами БД управляє роботою з таблицями,
процедурами, функціями, тригерами, представленнями та пакетами для
кращого використання в СУБД та застосування їх в створені
різноманітних схем БД;
− модуль диспетчеризації керує відповідними потоками даних, для
різних схем в розподілених базах даних реплікаціями в інших вузлах
через керуючі процедури, які застосовуються для оновлення даних в
таблицях відповідних схем баз даних за мінімальний час;
− модуль входу забезпечує вхід користувачів відповідно до прав доступу,
для виконання відповідних запитів з таблицями схеми бази даних після
аутентифікації з використанням паролю та виданого йому цифрового
підпису;
− модуль обробки запитів використовує засоби для забезпечення обробки
SQL- запитів для керування та роботи з розподіленими БД;
− модуль резервного копіювання забезпечує виконання засобів для
створення «гарячих» копій з вузлів розпоідлених баз даних, при чому
воно виконується в відповідний час доби (тоді коли навантаження на
сервер мінімальне) та, вразі необхідності, відновлення роботи вузла з
резервної копії чи шляхом реплікації при відмові.
У практичній діяльності для обробки даних більшість компаній
використовує власні розробки , або готові програмні комплекси на основі СУБД
різного типу, як наприклад розподілена система на основі якої проводилися
експерименти по збору статистики для визначення коефіцієнтів виконання
запитів до баз даних зображена на рисунку 3.2.

63

Рис. 3.2. Структурна схема комплексної системи управління і підтримки
виконання запитів до розподілених баз даних

Отже, постійно виникає проблема отримання даних з розподілених
гетерогенних СУБД на зовнішні ресурси, наприклад, іnternet – сайти, зокрема,
через Web-портали. Пропонована система дозволить підтримати всі вищеописані
функції, при цьому в якості додаткових функцій система забезпечить захист
переданих і оброблюваних даних. Також особливу увагу буде приділено
механізмам керування та ефективності обробки запитів в базах даних.
Зазвичай на найвищому рівні знаходиться підсистема управління
розподіленою системою обробки даних, яка керує всією складною системою і
забезпечує оперативне подання та обробку інформації для порталу.
64
Представлення інформації виконується з розподілених баз даних, і для
вирішення цього завдання розробляється підсистема керування, зберігання,
обробки та підготовки даних. Саме в цю систему надходить вся необхідна
інформація , яка зберігається у відповідних форматах і при необхідності може
використовуватися на Web-порталі. Для того, щоб інформація з різних зовнішніх
джерел (баз даних) в коректному форматі потрапляла в єдине сховище потрібна
спеціальна підсистема синхронізації даних з гетерогенних СУБД, тобто
підсистема конвертації різних типів даних в єдиний формат зберігання.
Одночасно необхідно вирішити проблему оптимізації процесу конвертації
даних. На самому нижньому рівні знаходиться підсистема отримання даних, яка,
по суті, є простим механізмом отримання даних з гетерогенних СУБД для
подальшої обробки знаходиться в ній інформації.
В цілому, розглянута комплексна система повинна підтримувати такі
сервіси:
− Підтримка мережецентричного підходу;
− Забезпечення конвертації даних;
− Підтримка обміну даними;
− Моніторинг безпеки оброблюваних даних;
− Авторизація користувачів і сертифікація електронних підписів.
Узагальнена структурна схема комплексної системи управління та
підтримки безпеки взаємодії web-порталу з середовищем зберігання даних.
Служить для управління всією комплексною системою і забезпечує безперебійне
функціонування всіх підсистем і модулів.

3.2. Визначення кількості вузлів бази даних в залежності від
розмірності розподіленої системи
Для визначення часу обробки запитів в розподіленій системі потрібно
знайти час обробки запитів для кожного виду запитів, взявши при цьому різну
кількість вузлів системи, а саме: 20, 50, 100, 500, 1000.
65
Знайдемо час обробки запитів на Select (рис. 3.3) для 20 вузлів розподіленої
системи обробки даних з наступними параметрами розподіленої мережі:
L = 20 запитів, V = 3 Кбіт/с; Vk = 2 Кбіт/с; Vq = 8 Кбіт/с; S = 1 Кб.

Рис. 3.3. Час обробки пакету-запиту типу Select в розподіленій системі з
20 вузлів

Знайдемо час обробки запитів на Select (рис. 3.4) для 50 вузлів розподіленої
системи обробки даних з наступними параметрами розподіленої мережі:
L = 20 запитів, V = 3 Кбіт/с; Vk = 3 Кбіт/с; Vq = 12 Кбіт/с; S = 4 Кб.

Рис. 3.4. Час обробки пакету-запиту типу Select в розподіленій системі з
50 вузлів
66
Знайдемо час обробки запитів на Select (рис. 3.5) для 100 вузлів
розподіленої системи обробки даних з наступними параметрами розподіленої
мережі: L = 20 запитів, V = 3 Кбіт/с; Vk = 8 Кбіт/с; Vq = 17 Кбіт/с; S = 3 Кб.

Рис. 3.5. Час обробки пакету-запиту типу Select в розподіленій системі з
100 вузлів

Знайдемо час обробки запитів на Select (рис. 3.6) для 500 вузлів
розподіленої системи обробки даних з наступними параметрами розподіленої
мережі: L = 20 запитів, V = 7 Кбіт/с; Vk = 8 Кбіт/с; Vq = 11 Кбіт/с; S = 4 Кб.

Рис. 3.6. Час обробки пакету-запиту типу Select в розподіленій системі
з 500 вузлів
67
Знайдемо час обробки запитів на Select (рис. 3.7) для 1000 вузлів
розподіленої системи обробки даних з наступними параметрами розподіленої
мережі: : L = 20 запитів, V = 5 Кбіт/с; Vk = 6 Кбіт/с; Vq = 17 Кбіт/с; S = 7 Кб.

Рис. 3.7. Час обробки пакету-запиту типу Select в розподіленій системі
з 1000 вузлів

Знайдемо час обробки запитів на Insert (рис. 3.8) для 20 вузлів розподіленої
системи обробки даних з наступними параметрами розподіленої мережі:
L = 20 запитів, V = 3 Кбіт/с; Vk = 2 Кбіт/с; Vq = 8 Кбіт/с; S = 1 Кб.

Рис. 3.8. Час обробки пакету-запиту типу Insert в розподіленій системі з
20 вузлів
68
Знайдемо час обробки запитів на Insert (рис. 3.9) для 50 вузлів розподіленої
системи обробки даних з наступними параметрами розподіленої мережі:
L = 20 запитів, V = 3 Кбіт/с; Vk = 3 Кбіт/с; Vq = 12 Кбіт/с; S = 4 Кб.

Рис. 3.9. Час обробки пакету-запиту типу Insert в розподіленій системі
з 50 вузлів

Знайдемо час обробки запитів на Insert (рис. 3.10) для 100 вузлів
розподіленої системи обробки даних з наступними параметрами розподіленої
мережі: L = 20 запитів, V = 3 Кбіт/с; Vk = 8 Кбіт/с; Vq = 17 Кбіт/с; S = 3 Кб.

Рис. 3.10. Час обробки пакету-запиту типу Insert в розподіленій системі
з 100 вузлів
69

Рис. 3.11. Розподіл часу обробки пакетів в залежності від кількість вузлів бази
даних при різній загальній кількості вузлів розподіленої системи

Аналіз результатів моделювання показав, що при збільшенні кількості
вузлів системи, кількість вузлів в яких розміщені бази даних збільшуються не
пропорційно. Це пояснюється збільшенням навантаження на проведення
реплікацій при запитах не пов’язаних з пошуком. Для мережі з 20 вузлів
необхідно обрати 4 вузла з базами даних, 50 вузлів – 4 вузла, 100 вузлів – 5 вузлів,
500 вузлів – 6 вузлів, в для 1000 вузлів розподіленої системи необхідно 5 вузлів
з базами даних.

3.3. Порівняльний аналіз роботи методики синтезу розподіленої
системи обробки даних
Розглянемо комп’ютерні мережі, яка складається з N вузлів та великої
кількості даних, які зберігаються в частині цих вузлів. Кожний вузол здійснює
обробку пакетів по своєму. В вузлах, які відповідають за розміщення бази даних
здійснюється обробка запитів та підготовка відповідей. В вузлах, в яких
розміщене керуюче програмне забезпечення здійснюється обробка команд
керування та визначення маршрутів проходження пакетів. Проміжні вузли
70
виконують функцію маршрутизації пакетів від вузлів з керуючим програмним
забезпеченням та до вузлів з базами даних і навпаки. Типові сценарії
використання розподілених систем обробки даних з динамічною структурою на
основі мережецентричного керування накладають певні обмеження на структуру
та функціонування вузлів та каналів між ними.
Розглянемо узагальнену методику синтезу розподіленої системи обробки
даних, що ґрунтується на моделях оцінювання параметрів обробки даних та
аналізу і прогнозування функціональних параметрів, а також методах
визначення кількості вузлів обробки даних та механізму обробки інформації в
розподілених комп’ютерних системах з динамічною структурою на основі
мережецентричного механізму управління.

Рис. 3.12. Результат застосування узагальненої методики

Для проведення експерименту візьмемо чотири системи, які були описані
вище та визначимо, як зміниться час обробки запитів після застосування
методики синтезу розподіленої системи обробки даних з використанням моделей
оцінювання параметрів обробки даних та аналізу і прогнозування
71
функціональних параметрів, а також методах визначення кількості вузлів
обробки даних та механізму обробки інформації в розподілених комп’ютерних
системах з динамічною структурою на основі мережецентричного механізму
управління.
Прорахуємо середній час обробки запитів до застосування узагальненої
методики та після її застосування в гетерогенних розподілених базах даних
(рис. 3.12).

Таблиця 3.1.
Розрахунок економії коштів при застосування узагальненої методики
синтезу розподіленої системи обробки даних
1 система 2 система 3 система 4 система
Час обробки до
методики 4200 119200 21300000 13900000
Час обробки після
методики 3650 103000 18200000 11850000
Середня кількість 500 1000 1000000 1000000
запитів за місяць
Час економії за місяць 550 16200 3100000 2050000
Час економії за рік 6600 194400 37200000 24600000
Годин зекономлено за
рік 0,001833333 0,054 10,333 6,833
Днів зекономлено за
рік 0,000229167 0,00675 1,29166667 0,8541666
Місяців зекономлено 1,04167E-05 0,000306818 0,05871212 0,0388257
за рік
Ціна за місяць 5000 5000 5000 5000
Економія коштів за рік 1,5625 4602,27 5871212,12 3494318,1

Як видно з рисунка 3.12 застосування узагальненої методики синтезу
розподіленої системи обробки даних, що ґрунтується на моделях оцінювання
параметрів обробки даних та аналізу і прогнозування функціональних
параметрів, а також методах визначення кількості вузлів обробки даних та
механізму обробки інформації в розподілених комп’ютерних системах з
72
динамічною структурою на основі мережецентричного механізму управління дає
виграш по часу обробки запитів від 13% до 14,7%.
Проведемо розрахунок економії коштів при застосування узагальненої
методики синтезу розподіленої системи обробки даних. Для цього в таблицю 3.1
винесемо основні розрахунки по чотирьом системам.
Як видно з таблиці для великих систем з великою кількістю користувачів
та запитів, економія по грошах, які ідуть на зарплату працівників за рік буде рівна
кільком міліонам гривень, а для малих систем економія коштів незначна.

Висновки
Розроблено архітектуру розподіленої системи обробки даних з
використанням баз даних для проведення експериментальних досліджень часу
обробки запитів. Показано, що експериментальні дослідження доцільно
проводити на трьох операційних системах. Запропоновані механізми реалізації
комплексної системи управління взаємодії Web-порталу з гетерогенними
розподіленими базами даних з динамічною структурою на основі
мережецентричного підходу. Показано, що запропонований механізм підтримує
можливість конвертації ресурсів з СУБД з різним форматом зберігання даних в
єдиний формат для обробки пакетів в вузлах керування з застосуванням
планувальника та брокера.
Для визначення вагових коефіцієнтів використання запитів в розподіленій
системі обробки даних взято чотири розподілені системи обробки даних з різною
кількістю вузлів та було проведено збір статистики. Для простоти експерименту
всі ці системи використовують розподілені бази даних в вузлах, яких
встановлено СУБД Oracle. Розраховано середнє значення кількості використання
всіх запитів по видам запитів та визначено коефіцієнти використання
розподілених систем обробки даних, які потрібні для визначення середнього часу
обробки запитів для розподіленої системи з використанням гетерогенних баз
даних.
73
Для визначення часу обробки запитів в розподіленій гетерогенній
розподіленій системі знайдено час обробки запитів для кожного виду запитів,
взявши при цьому різну кількість вузлів системи: 20, 50, 100, 500, 1000. Аналіз
результатів моделювання показав, що при збільшенні кількості вузлів системи,
кількість вузлів в яких розміщені бази даних збільшуються не пропорційно. Це
пояснюється збільшенням навантаження на проведення реплікацій при запитах
не пов’язаних з пошуком. Для мережі з 20 вузлів необхідно обрати 4 вузла з
базами даних, 50 вузлів – 4 вузла, 100 вузлів – 5 вузлів, 500 вузлів – 6 вузлів, в
для 1000 вузлів розподіленої системи необхідно 5 вузлів з базами даних.
Застосування узагальненої методики синтезу розподіленої системи
обробки даних, що ґрунтується на моделях оцінювання параметрів обробки
даних та аналізу і прогнозування функціональних параметрів, а також методах
визначення кількості вузлів обробки даних та механізму обробки інформації в
розподілених комп’ютерних системах з динамічною структурою на основі
мережецентричного механізму управління дає виграш по часу обробки запитів
від 13% до 14,7%.

74
ЗАГАЛЬНІ ВИСНОВКИ

В результаті досліджень вирішена важлива проблема розробки моделей та
методів, які забезпечують підвищення ефективності управління розподіленою
базою даних в комп’ютерних системах з динамічною структурою. Ця
проблематика має суттєве значення для проектування та модернізації існуючих
розподілених систем обробки даних з метою забезпечення їх високої
ефективності при обробці запитів в розподілених базах даних.
Одержані наступні основні результати:
1 На підставі проведеного аналізу існуючих моделей та методів на даний час
в практиці і теорії побудови та експлуатації розподілених баз даних в
мережах загострилося протиріччя між необхідністю стійкого
функціонування гетерогенних розподілених баз даних в умовах впливу
внутрішніх та зовнішніх дестабілізуючих факторів і можливостями
існуючих методів забезпечення обробки інформації.
2 Розроблено модель оцінювання параметрів обробки інформації в
розподілених системах з динамічною структурою в яких реалізовано
розподілені бази даних наукова новизна якої полягає в тому, що вона
ґрунтується на виборі кортежу параметрів розподіленої системи та
врахуванні обмежень, що дозволяє формалізувати структуру управління
обробки запитів в розподілених базах даних.
3 Розроблено метод визначення необхідної кількості вузлів бази даних
наукова новизна якого полягає в тому, що він ґрунтується на застосуванні
механізму визначення вагових коефіцієнтів видів запитів, що дозволяє
отримати потрібну кількість вузлів баз даних в розподіленій системі для
забезпечення відповідних вимог до параметрів обробки запитів та
підвищення швидкості їх обробки.
4 Удосконалено модель для аналізу та прогнозування функціональних
параметрів розподілених систем обробки даних, яка відрізняється від
75
існуючих тим, що вона ґрунтується на застосуванні механізму на основі
фрактального підходу, що дозволяє розрахувати для фрагмента
розподіленої системи з динамічною структурою в якій реалізовано
розподілені бази даних, базовий показник функціонування – час обробки
запитів
Перспективними шляхами подальших досліджень у розглянутому
напрямку може бути широке коло питань щодо розробки нових та
удосконалених існуючих методів підвищення ефективності часу обробки запитів
в розподілених комп’ютерних мережах з використанням мережецентричного
підходу, які мають бути застосовані в умовах впливу зовнішніх та внутрішніх
дестабілізуючих факторів.
76
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Agrawal D. Database scalability, elasticity, and autonomy in the cloud.
DASFAA, 2018. – 160 p.
2. Benoit D. Automatic Diagnosis of Performance Problems in Database
Management Systems / Darcy G. Benoit // Proceedings of the Second
International Conference on Automatic Computing, June 13–16, 2015. – Р. 326–
327.
3. Bing Yao S. Optimization of Query Evaluation Algorithms // ACM TODS. –
2019. – № 2. – 240 p.
4. Bobby L. Practical Oracle Database Appliance / Bobby L. Curtis, Fuad Arshad,
Erik Benner, Maris Elsins // Apress; 2014. – 272 p.
5. Bodorik P. Correcting execution of distributed queries / P. Bodorik, J. Pyra, J. S.
Riordon // Proceedings of the second international symposium on Databases in
parallel and distributed systems, 2017. – 330 p.
6. Bruno N. Configuration-parametric query optimization for physical design
tuning / Nicolas Bruno, Rimma V. Nehme // Proceedings of the 2018 ACM
SIGMOD international conference on Management of data, June 09-12, 2018.
Vancouver, Canada, 2018. – 320 p.
7. Cecchet E. Dolly: Virtualization–driven database provisioning for the cloud /
Cecchet E., Singh R. // VEE’11, 2019. – 654 p.
8. Chacravarthy U.S. Query Optimization: Additional Constraints /
Chacravarthy U.S., Grant J., Minker Semantic J. // Proc. 1st Int. Conf. Expert
Database Syst., Charleston, S.C., Apr. 2016. – New York – 2016. – Р.259–270.
9. Chaudhuri S. Self–Tuning Database Systems: A Decade of Progress / Surajit
Chaudhuri, Vivek Narasayya // Proceedings of the Second International
Conference on Automatic Computing, p. 326–327, June 13–16, 2018. – 464 p.
10. Chaudhuri S. Self–tuning database systems / Chaudhuri S. and Narasayya V. //
International Conference on Very Large Data Bases, 2016. – 521 p.
77
11. Cheng J.M. IBM Database 2 Performance: Design, Implementation, and Tuning
/ Cheng J.M., Loosley C.R., Shibamiya A., Worthington P.S. // IBM Syst. J.–
2018. – 23. – № 2. – Р.189–210.
12. Christodoulakis S. Estimating Record Selectivities // Inf. Syst. – 2018. – № 2. –
Р. 105-115.
13. Cornell D.W. A Vertical Partitioning Algorithm for Relational Databases /
Cornell D.W. Yu P.S. // 3rd Int. Conf. Data Eng., Los Angeles, Ca, Febr. 3–5,
2017. – Proc. Washington, D.C. –2017. – Р.30–35.
14. Das S. Elastras: An elastic, scalable, and self–managing transactional database
for the cloud. ACM TDS, 38(1), 2017. – 784 p.
15. DeWitt D.J. Implementation Techniques for Main Memory Database Systems /
D.J. DeWitt, R.H. Katz, F. Olken, L.D. Shapiro, M.R. Stonebraker, D. Wood //
Proc. ACM SIGMOD Int. Conf. Manag. Data, Boston, Mass., June 18–21, 2018.
New York, 2018, Р. 1–8.
16. Garcia–Arellano C. Adaptive self–tuning memory in DB2. / C. Garcia–
Arellano, J. Storm // International Conference on Very Large Data Bases, 2018.
– 454 p.
17. Gillenson M. L. Fundamentals of Database Management Systems 2nd Edition.
Wiley, 2016. – 460 p.
18. Gray J. The Transaction Concept: Virtues and Limitations / Gray Jim.
Proceedings of the 7th International Conference on Very Large Databases, 2018.
– 620 p.
19. Hameurlain A. Evolution on query optimization methods. // Transactions on
Large-Scale Data- And Knowledge-Centered Systems. LNCS, 2019. –
P. 211-242.
20. Hasler T. Oracle SQL. Optimization, Deployment, and Statistics / Tony Hasler
// Apress; 2017. – 571 р.
21. Jain A.K. Statistical pattern recognition: A review / Jain A. K., Duin R. P. W.,
Mao J. // IEEE Transactions on Pattern Analysis and Machine Intelligence,
2020. – Vol. 22, no. 1.– P. 4–37.
78
22. John L. Gustafson Reevaluating Amdahl's Law. Communications of the ACM
31(5), 2018. – 460 p.
23. Kanevskiy D.Y. Cooperative coevolutionary ensemble learning / Kanevskiy D.,
Vorontsov K. V. // Multiple Classifier Systems: 7th International Workshop,
Prague, Czech Republic, May 23–25, 2017. Lecture Notes in Computer Science.
Springer–Verlag, 2017. – P. 469–478.
24. Kim W. Query Processing in Database Systems / Kim W., Reiner D.S., Batory
D.S. Query // New York, N.Y.: Springer–Veiiag, 2018. – 254 p.
25. Kwan E. Automatic configuration for IBM DB2 universal database / Kwan E.,
Lightstone S. // Technical report, IBM, 2019. – 554 p.
26. Kyte T. Oracle Database Architecture / Thomas Kyte, Darl Kuhn // Apress; 3rd
ed. 2019. – 824 р.
27. Lohman G.M. Optimization of Nested Queries in a Distributed Relational
Database // Proc. 10th Int. Conf Very Large Data Bases, Singapore, Aug. 27 –
2019. – Р. 403–415.
28. Ma L. Query–based Workload Forecasting for Self–Driving Database
Management Systems / Ma L., Aken D. V., Hefny A., Mezerhane G., Pavlo A.,
Gordon G. J. // Proceedings of the 2018 ACM International Conference on
Management of Data, 2018. – 751 p.
29. Markl V. LEO: An autonomic query optimizer for DB2 / V. Markl,
G. M. Lohman, V. Raman // IBM Systems Journal, v.42 n.l, 2016. – 637 p.
30. Mozafari B. Performance and resource modeling in highly–concurrent oltp
workloads. SIGMOD, 2018. – 244 p.
31. Murali V. Oracle RAC Perfomance Diagnostics and Tuning / Murali Vallath –
Apress, 2019. – 712 p.
32. Narayanan D. Continuous resource monitoring for self–predicting DBMS /
D. Narayanan, E. Thereska, A. Ailamaki // MASCOTS’05, 2017. – 257 p.
33. Selinger P.G., Astrahan M. M., Chamberlin D. D., Lorie R. A., Price T.G.
Access Path Selection in A Relational Database Management System. //
SIGMOD Conference. ACM, 2019. – P. 23-34.
79
34. Sokolinsky L.B. Organization of Parallel Query Processing in Multiprocessor
Database Machines with Hierarchical Architecture // Programming and
Computer Software, 2021. Vol. 27, No. 6. – P. 297-308.
35. Steinbrunn M. Heuristic and Randomized Optimization for the Join-Ordering
Problem. // VLDB Journal, 2017. Vol. 6, No. 3. – P. 191-208.
36. Stillger M. LEO – DB2's LEarning Optimizer / Michael Stillger, Guy M.
Lohman, Volker Markl, Mokhtar Kandil // Proceedings of the 27th International
Conference on Very Large Data Bases, September 11–14, 2018. – 54 p.
37. Stonebraker M. The INGRES Papers: Anatomy of a Relational Database
System. Addison-Wesley, 2019. – 486 p.
38. Tresp V. Committee machines // Handbook for Neural Network Signal
Processing / Ed. by Y. H. Hu, J.–N. Hwang. – CRC Press, 2018. – 754 p.
39. Valentin G. DB2 advisor: an optimizer smartenough to recommend its own
indexes / Valentin G., Zuliani M. // ICDE, 2019. – 854 p.
40. Vance B. Rapid Bushy Join-Order Optimization with Cartesian Products. //
SIGMOD Conference. ACM, 2018. – P. 35-46.
41. Whalen E. Oracle Performance Tuning and Optimization / Whalen E. – Sams
Publishing, 2015. – 670 p.
42. Wong E. Decomposition – A Strategy for Query Processing / ACM Transactions
on Database Systems, 3 (September), 2018. – 160 p.
43. Wong E. Decomposition: A Strategy for Query Processing. // ACM Transactions
on Database Systems, 2020. Vol. 1. – P. 223-241.
44. Yao S.B. An Attribute Based Model for Database Access Cost Analyses // ACM
Trans. Database Syst. – 2017. – № 1. – Р. 45–67.
45. Yao S.B. Approximating Block Acess in Database Organizations // Commun.
ACM. – 2017. – № 4. – Р. 260–261.
46. Ziane M. Parallel Query Processing with Zigzag Trees. // VLDB Journal. 2019.
Vol. 2, No. 3, – P. 277-301.
47. Zilio D. C. DB2 design advisor: integrated automatic physical database design /
D. C. Zilio // International Conference on Large Data Bases, 2018. – 784 p.
80
48. Zilio S. DB2 Design Advisor: Integrated Automatic Physical Database Design /
Zilio et al. // In Proceedings of the International Conference on Very Large Data
Bases, Toronto, Canada, 2019. - 24 p.
49. Hlumenko A. O., Stelmakh D. E., Kolonko M., Arsyrii O. A. Use of multivariant
storage and multimodel databases for processing heterogeneous data // Modern
information technologies: proceedings of the 10th International scientific
conference of students and young scientists, Odesa, May 14–15, 2020. Odesa:
Odesa National Polytechnic University, 2020. P. 118-119.
50. Hromey D. D. Algorithms for managing the logical structure of a database using
a parametric model of concurrent query access based on the random forest
method // Computational Nanotechnology. 2019. Vol. 6, No. 2. P. 41-47.
51. Arsyrii O., Kolonko M., Müllenbach S., Trofimov B., Hlava M. Concept
modeling for developing databases with polyglot persistence as a direction of
business digitalization // Sustainable Development. Varna, 2020. No. 2. P. 22-
29.

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets