Аналіз сучасних розробок ефективних систем управління базами даних

Размещено на http://www.allbest.ru/

Аналіз сучасних розробок ефективних систем управління базами даних

Лукашевич Яна Петрівна аспірант, Поліхун Антон Вячеславович аспірант, Інститут проблем моделювання в енергетиці ім. Г.Є. Пухова, Національна академія наук України; Дмитрієнко Оксана Олексіївна кандидат педагогічних наук, доцент, доцент кафедри математичного аналізу та інформатики, Полтавський національний педагогічний університет імені В.Г. Короленка

Анотація

Робота присвячена аналізу останніх досягнень у галузі розробки ефективних систем управління базами даних (СУБД). Досліджуються та порівнюються сучасні рішення, спрямовані на оптимізацію продуктивності, масштабованість та гнучкість в управлінні даними. У роботі розглядаються технології реляційних (SQL) та NoSQL баз даних, де також враховують аспекти безпеки, транзакційної стійкості та забезпечення доступу.

Дана робота присвячена аналізу сучасних тенденцій в галузі систем управління базами даних (СУБД), зокрема інтеграції SQL та NoSQL підходів. У роботі розглядаються основні характеристики та функціональні можливості SQL СУБД, таких інтеграційних моделей, як PostgreSQL, Oracle Database, а також їх порівняння з NoSQL СУБД інтеграційними моделями MongoDB та Amazon DynamoDB. Проведення аналізу містить вивчення переваг та недоліків кожного підходу, а також можливості їх інтеграції для оптимального використання в різноманітних сценаріях застосування. Результати аналізу можуть служити орієнтиром для вибору оптимального типу СУБД в залежності від конкретних вимог.

Для проведення аналізу спрощеного алгоритму на основі реляційної моделі SQL СУБД розглядалися аспекти виконання запитів та визначення продуктивності. Виконання запитів для СУБД відіграє ключову роль, де кількість запитів безпосередньо залежить від часу обробки та звірення даних. Визначення продуктивності розглядається для аналізу ефективності програмної системи, яка здатна справлятися з поставленими завданнями під час обробки запитів. З метою тестування продуктивності застосовуються різні моделі СУБД, які мають різний час відгуку. Досліджено, що на визначення продуктивності можуть впливати декілька факторів, таких як апаратне забезпечення, моделі даних, розподіл та фізичний дизайн.

На основі використаних літературних джерел проаналізовано декілька інтегрованих СУБД на основі архітектури SQL та NoSQL. Коротко проаналізовано кожну інтегровану систему з описаними перевагами та недоліками з використанням моделей SQL та NoSQL.

Ключові слова: база даних, реляційна модель, спрощений алгоритм, продуктивність, транзакції, SQL, NeSQL.

Abstract

Analysis of modern developments in effective database management systems

Lukashevych Yana Petrivna PhD student, Polukhin Anton Vyacheslavovich PhD student, G.E. Pukhov Institute for Modelling in Energy Engineering, National Academy of Sciences of Ukraine; Dmytriienko Oksana Oleksiivna Candidate of Pedagogical Sciences, Associate Professor, Associate Professor of the Department of Mathematical Analysis and Informatics, Poltava V.G Korolenko National Pedagogical University

This paper analyses the latest developments in the field of efficient database management systems (DBMS). Modern solutions aimed at optimising performance, scalability and flexibility in data management are studied and compared. The paper considers relational (SQL) and NoSQL database technologies, which also take into account aspects of security, transactional stability and accessibility.

This paper is devoted to the analysis of current trends in the field of database management systems (DBMS), in particular the integration of SQL and NoSQL approaches. The paper considers the main characteristics and functionalities of SQL DBMS, integration models such as PostgreSQL, Oracle Database, as well as their comparison with No SQL DBMS integration models MongoDB and Amazon DynamoDB. The analysis includes the study of the advantages and disadvantages of each approach, as well as the possibility of their integration for optimal use in various application scenarios. The results of the analysis can serve as a guide for choosing the optimal type of DBMS depending on specific requirements.

To analyze a simplified algorithm based on the SQL DBMS relational model, we considered the aspects of query execution and performance determination. Query execution plays a key role for a DBMS, where the number of queries directly depends on the time of data processing and reconciliation. Performance measurement is considered to analyse the effectiveness of a software system that is able to cope with the tasks set during query processing. Different DBMS models with different response times are used for performance testing. It has been shown that several factors, such as hardware, data models, distribution, and physical design, can affect performance.

Several integrated DBMS based on SQL and NoSQL architectures are analyzed on the basis of the used literary sources. Each integrated system is briefly analyzed with described advantages and disadvantages using SQL and NoSQL models.

Keywords: database, relational model, simplified algorithm, performance, transactions, SQL, NeSQL.

Постановка проблеми

Системи управління базами даних (СУБД) є невід'ємною частиною для інформаційних систем та технологій, які здатні забезпечувати ефективне управління, зберігання та доступ до даних, що є основою для функціонування багатьох сфер діяльності, бізнес-процесів та сервісів. Швидкий розвиток технологій та збільшення обсягів даних містять значний вплив на сучасні розробки СУБД, що супроводжується новими проблемами та викликами [1; 2].

Сучасні можливості систем управління базами даних (СУБД) хоч і є ефективними, але з точки зору надійності даних, продуктивності та стабільності за останній час були надані менш ефективні рішення. Одночасно з цим зростають й складнощі, які можуть виникати в СУБД, що пояснюється зростанням обсягів великих даних, які підлягають обробці та збереженню. Другорядною проблемою зростання складнощів СУБД відіграє розвиток нових технологій, які впродовж останніх 20 років були значно розвинені. До таких технологій відносяться інформаційні технології, штучний інтелект та машинне навчання, Інтернет речей та розумні технології, які вимагають більше сучасних можливостей від СУБД [2; 3].

Надійність даних безпосередньо залежить від безпеки, де СУБД повинні забезпечувати безпеку даних, які обробляються та зберігаються ними. Основною проблемою безпеки даних є те, що база даних, яка містить важливу інформацію є потенційною мішенню для кіберзлочинців - хакерів, які зазвичай намагаються отримати доступ до даних або змінити їх. Варто враховувати те, що до основної проблеми з питань безпеки даних СУБД є конфіденційність, так як дані можуть використовуватися як для шахрайства, так і для злочинів [4; 5].

Окрім зростання складнощів та надійності даних також не менш важливими є продуктивність та стабільність СУБД. Продуктивність відповідає за швидку та ефективну обробку запитів, однак обробка великих обсягів даних є складним завданням, так як деякі теперішні СУБД працюють на застарілих апаратних платформах, які не здатні підтримувати високу продуктивність. Одночасно з цим на продуктивність СУБД впливає оптимізація для застосунків, що значно впливає на зниження продуктивності, якщо такі системи не оптимізовані. До проблем стабільності СУБД відноситься те, що такі системи в деяких випадках можуть бути схильними до помилок, збоїв та втрат даних. Тому для забезпечення стабільності необхідно своєчасно оновлювати компоненти такої системи, що дозволить уникнути проблем та підвищити безпеку даних [5; 6; 7].

До основних проблем ефективності СУБД можна розглянути основні 7 факторів. До таких факторів відносяться: погана оптимізація (обмежені можливості SQL-запитів, що може призвести до повільної роботи системи та витрат ресурсів); масштабованість (проблеми, які виникають під час обробки великих обсягів даних або при збільшенні одночасної кількості користувачів); індексація (недостатня індексація впливає на швидкодію виконання запитів з врахуванням великого обсягу даних, а відсутність індексів може призвести до повільного пошуку та фільтрації даних); велика кількість запитів (збільшення кількості одночасних запитів призводить до перевантаження сервера та зменшення продуктивності); неоптимальне зберігання даних (менш ефективна структура даних призводить до надмірного використання ресурсів); блокування транзакцій (проблеми, які виникають при одночасному доступі до них); недостатній моніторинг та оптимізація (недостатність засобів для проведення моніторингу та відсутність оптимізації може призвести до складнощів для виявлення та розв'язання проблем ефективності).

Аналіз останніх досліджень і публікацій

Тенденція розвитку сучасних розробок СУБД містить безліч переваг та недоліків, що обумовлюється використанням ефективного програмного забезпечення, методів кіберзахисту, оптимізації, контролю на моніторингу даних. Однак ситуація в Україні змушує шукати нові шляхи для вирішення проблем з надійністю та конфіденційністю даних, що обумовлюється військовою агресією від 24 лютого 2022 року. Наприклад, в роботі [8] авторами на основі проведеного дослідження було з'ясовано, що кількість кібератак на органи державної влади, об'єкти критичної інфраструктури зменшилася, однак нещодавні події свідчать протилежне, коли проводилася хакерська атака на українську телекомунікаційну компанію мобільного зв'язку «Київстар».

Деякі з українських науковців досліджують вплив сучасних розробок СУБД та їх можливостей, в яких можуть використовуватися нові технології зі збереженням, обробкою та аналізом великих даних за допомогою інтеграції. У роботі [9] авторами проведено аналіз, який складається з рейтингу: реляційних СУБД; рейтингу СУБД, орієнтованих на обробку даних; рейтинг комерційних СУБД; рейтинг СУБД з відкритим програмним кодом. На основі рейтингу реляційних СУБД найбільш ефективними є Oracle (27%) та MySQL (26%), а серед найменш ефективних є Microsoft Access, Maria DB, Hive та Microsoft Azure SQL Database, яка кожна з них складає всього лише 2%.

Якщо порівняти можливості сучасних технологій та систем управління, які відповідають за обробку, збереження та захист даних, то на основі цього можуть бути розроблені самокеровані СУБД, які відрізняються своєю архітектурою й призначені для автономної роботи. У роботі [10] розглядається можливість розробки такої самокерованої системи, архітектура якої отримала назву «Peloton», яка відрізняється від попередніх тим, що більшість аспектів систем контролюються інтегрованим компонентом планування. Це дозволяє оптимізувати систему під фактичне робоче навантаження та прогнозує майбутні тенденції зміни робочого навантаження для того, щоб система могла завчасно підготуватися до передбачуваних змін. Однак незважаючи на те, що авторами проводилося дослідження у 2017 році, деякі з науковців продовжили дослідження самокерованих СУБД, де в роботах [11; 12; 13] описано вдосконалення таких систем.

Попереднім методам прогнозування властиво моделювати використання ресурсів у вигляді запитів, однак такі показники можуть дуже часто змінюватися у часі, коли змінюється фізичний дизайн бази даних разом з апаратними ресурсами, що робить попередні моделі прогнозування менш ефективними. У роботі [14] авторами представлено спеціально розроблений фреймворк прогнозування «QueryBot 5000», на основі якого для СУБД можливо прогнозувати очікувану швидкість надходження запитів у майбутньому, що обумовлено на основі історичних (минулих) даних. Також в роботі представлено метод на основі кластеризації для зменшення загальної кількості моделей прогнозування, які потрібно підтримувати, що дозволяє оптимізувати систему для більш зручного та ефективного застосування. Для реалізації моделей авторами розглядався зовнішній контролер для PostgreSQL та MySQL, що продемонструвало їхню ефективність у виборі індексів.

Метою даної статті є проведення аналізу характерних особливостей систем управління базами даних, який охоплює застосовування сучасних технологій для зберігання даних. В якості дослідження розглядаються моделі SQL та NoSQL системи управління базами даних, на основі яких далі були розглянуті та проаналізовані інтегровані системи з метою вивчення характерних особливостей, переваг та недоліків таких систем. Для досягнення поставленої мети необхідно вирішити наступні задачі: провести огляд літератури застосування сучасних технологій для зберігання даних; вивчити характерні параметри для побудови алгоритму системи управління базами даних; порівняти можливості SQL та NoSQL для систем управління базами даних; з'ясувати, яка з технологій зберігання даних є найефективнішою, враховуючи безпеку даних, продуктивність та стабільність.

Виклад основного матеріалу

Бази даних можуть використовувати одну або декілька моделей даних в залежності від обсягу даних для їх обробки, збереження та операцій, які можуть бути доступними для пошуку та маніпулювання ними. Зазвичай такі моделі можуть бути концептуальними (наприклад, модель «сутність-зв'язок», в якій не передбачені чіткі вимоги щодо зберігання відсутні, а використовуються лише для опису взаємозв'язків та характеристик даних), логічними (наприклад, реляційна модель, яка обумовлена вимогами щодо зберігання даних та їх представлення, але містить обмеження, які пов'язані з відсутністю опису, як зберігаються дані з використанням фізичних пристроїв) та фізичними (наприклад, оператор фізичного пошуку даних для фізичного вилучення даних) [15].

Однією з найбільш відомих логічних моделей є реляційна модель даних, яка містить безліч концепцій й широко застосовується для СУБД. Деякі з популярних СУБД, таких PostgreSQL, Oracle Database використовують архітектуру з інших логічних моделей даних, однак спільним для всіх сучасних СУБД є те, що вони використовують мову структурованих запитів (SQL) для визначення структури даних, пошуку та операцій щодо управління ними. Характерною ознакою такої СУБД є потужна модель узгодженості даних, яка допускає, що операції з базою даних, які згруповані в транзакцію повинні бути або успішними, або невдалими, а дані повинні слідувати визначеній бізнес-логіці, де успішні транзакції зберігаються у сховищі.

NoSQL на відміну від реляційної моделі даних SQL не містить формальних визначень, а різновид моделей NoSQL СУБД може реалізувати різні моделі даних (наприклад, ключ-значення Redis, документ MondoDB, широкі стовпці Cassandra та граф NeoSQL). На рис. 1. показано характерні особливості побудови моделей SQL (яка складається з графових та без агрегатних БД) та NoSQL (яка складається з документованих, агрегатних та стовпчикових БД) [16].

Рис. 1. Характерні особливості побудови сучасних моделей SQL та NoSQL: [9]

Окрім того, NoSQL СКБД можуть мати окрему мову запитів, яка розроблена для роботи з конкретними структурами даних, доступними для реалізації інших моделей даних в СКБД. У деяких моделях даних NoSQL, наприклад, ключ-значення та документи, в яких надлишкові дані можуть зберігатися за рахунок місця в сховищі. Модель узгодженості менш сувора на відміну від SQL СУБД, що сприяє підвищенню продуктивності, якої можуть вимагати веб-додатки з великою кількістю одночасних користувачів. Розглянувши деякі характеристики двох моделей була складена порівняльна характеристика основних переваг та недоліків, яка наведена у табл. 1. Порівнюючи деякі переваги та недоліки цих двох моделей можна зробити висновок, що обидві моделі містять протилежні характеристики, які впливають на розробку та роботу СУБД.

Таблиця 1. Порівняльний аналіз моделей SQL та NoSQL для СУБД [9]

Після того, як вище були зазначені основні переваги та недоліки, далі розглянемо характерні особливості при виборі кожної моделі. Вибір між SQL СУБД та NoSQL СУБД залежить від чітко виражених вимог до застосування. Наприклад, якщо для застосування враховуються вимоги стандартизованої мови запитів, ефективного виконання складних запитів та підтримки цілісності, то в такому випадку краще використовувати модель NoSQL СУБД. В іншому випадку, якщо застосування вимагає гнучкості для зберігання різних типів даних, швидкого масштабування та доступності, то в такому випадку краще використовувати модель NoSQL СУБД. Далі розглянемо деякі приклади застосування цих моделей: для моделей SQL СУБД передбачається застосування для систем управління клієнтами (CRM), запасами (ERP), контентом (CMS) та даними (DBMS); для NoSQL СУБД передбачається застосування для соціальних мереж, веб-сервісів, Інтернет речей та аналізу даних в реальному часі.

Далі з'ясуємо, з чого повинна складатися сучасна база даних. База даних складається з набору взаємопов'язаних даних, які зберігаються та мають відношення до моделі даних. В більшості випадків база даних використовується одним або декількома програмними додатками через СУБД, де разом - база даних, СУБД та програмний додаток складає загальну систему бази даних. Однак відокремлення бази даних від СУБД, наприклад, у сфері реляційних баз даних, зазвичай неможливе без експорту бази даних в інший формат. Тому в подібних випадках база даних часто стає непридатною для використання СУБД, якщо не імпортувати її назад у формат, який зрозумілий для СУБД.

Для того, щоб краще зрозуміти з чого складається сучасна база даних розглянемо спрощений алгоритм (рис. 2.) на основі реляційної моделі SQL СУБД, який складається з користувача, фізичних пристроїв та компонентів СУБД. Спрощений алгоритм системи СУБД і кінцевого користувача продемонстровано з особливою увагою на компонентах, які мають відношення до вивчення такої системи. Стрілки представляють собою потік інформації від пристрою кінцевого користувача до бази даних, що знаходиться в постійному сховищі. Прямокутний контур демонструє межі для СУБД, які взаємодіють з фізичними пристроями, а штриховий прямокутний контур відображає основні компоненти, які відносяться до СУБД. В якості об'єктноорієнтованої скриптової мови використовується Parser, який створений для генерації HTML-сторінок на веб-сервері.

Виконання запитів. Виконання запитів проводиться для отримання та маніпуляцій з даними у випадках, коли користувач використовує термінал (ПК) та програмне забезпечення для обробки транзакцій, коли запит надсилається до СУБД й після чого відбувається безліч дій, ніж користувач отримає відповідь на свій запит.

Рис. 2. Спрощений алгоритм на основі реляційної моделі SQL СУБД: [16]

Синтаксичний аналізатор запитів перевіряє серед інших можливих запитів правильність запиту, і якщо запит проходить ці та інші перевірки, він переміщується до нижчого рівня, де передається оптимізатору запитів. Оптимізатор, який генерує один або декілька планів виконання запиту містить фізичні оператори для реалізації (наприклад, фізичні структури даних будуть використані при виконанні запиту, а СУБД проводить об'єднання таблиць). Точність оптимізатора залежить від деяких аспектів, наприклад, статистика попередніх виконаних запитів, доступних індексів тощо.

Наступним кроком буде те, як механізм виконання запитів реалізує план виконання запиту, використовуючи при цьому фізичні оператори, що містяться в ньому. В цьому процесі значну роль відіграє пам'ять, в якій відбувається пошук об'єктів даних для буферного обміну, яка напряму пов'язана з виконавчим механізмом. У разі, якщо деякі дані неможливо знайти, тоді надсилається запит до диску, де можуть зберігатися необхідні дані.

Оскільки сильні моделі узгодженості часто вимагають, щоб транзакції зберігалися в базі даних й потребує, щоб всі операції в транзакції були успішними, блокування зазвичай доповнюється журналами транзакцій. Ці журнали записуються для того, щоб всі операції були зафіксовані у базі даних й можуть слугувати для відміни попередніх операцій запису, якщо пізніша операція запису у тій самій транзакції завершилася невдало [16].

Визначення продуктивності. Вимірювання продуктивності відбувається для того, щоб з'ясувати наскільки ефективно програмна система справляється з виконанням поставлених завдань або запитів й вимірюється зазвичай часом відгуком (необхідний час для проходження виклику в системі до іншої частини системи) або пропускною здатністю, або в деяких випадках використанням обчислювальних ресурсів. На рис. 2. час відгуку складає час, який необхідний після того, як кінцевий користувач надіслав запит до програмного додатка, який передає запит до СУБД, що повертає набір даних до програмного додатка, який надає дані на пристрої кінцевого користувача. СУБД виконує та обробляє запити для тестування продуктивності.

Окрім того, необхідно також враховувати фактори, які можуть вплинути на продуктивність. Серед таких факторів можуть бути:

- апаратне забезпечення (більша частина локального часу відгуку пояснюється часом, який витрачається на обробку даних процесором, доступом до пам'яті та диска, а також програмним забезпеченням, яке очікує на завершення інших завдань);

- моделі даних (реляційні бази даних підпорядковуються принципам проєктування, які намагаються мінімізувати надлишковість, щоб усунути потенційні аномалії даних, спричинених надлишковими даними, а також намагаються мінімізувати потреби в просторі для зберігання, що в свою чергу призводить до затримки та уповільнення виконання запитів через більшу кількість з'єднань таблиць);

- розподіл (операції запису у розподілених конфігураціях створюють нетривіальні проблеми як для продуктивності, так і для узгодженості даних, а в розподілених системах баз даних фактично всі транзакції повинні обирати або узгодженість даних, або їх доступність);

- фізичний дизайн (у реляційних базах даних ефективне фізичне проєктування значною мірою досягається за допомогою індексів, а в базах даних NoSQL, як правило, за рахунок розподілу бази даних між обчислювальними вузлами) [16].

Порівняльний аналіз. На основі джерел [9; 17; 18] розглянемо декілька інтегрованих СУБД, які використовують моделі SQL та NoSQL. Аналіз включає в себе характеристику кожної СУБД та основні переваги та недоліки застосування таких інтегрованих систем. У табл. 2. наведена характеристика до кожної інтегрованої СУБД, яка містить тип моделі та характерні особливості. На основі проаналізованих параметрів для кожної системи наведено основні фактори - гнучкість, швидкість, масштабованість, підтримка транзакцій, надійність та стабільність, розширені функції, підтримка вбудованих операцій, а також обмежуючі фактори, які відображені в недоліках до кожної системи.

Таблиця 2. Використання структури моделей SQL СУБД та NoSQL СУБД для інтеграції з іншими моделями СУБД [9; 16; 17]