CC BY
48
УДК 004.652
Н О. СОЛОДКА, СО. ПОЛЩУК, O.A. ЛЯШЕНКО
Державний вищий навчальний заклад «Украшський державний хiмiко-технологiчний ушверситет», м. Дншро
ВИКОРИСТАННЯ ГРАФОВО1 ТА РЕЛЯЦ1ЙНО1 МОДЕЛЕЙ ДАНИХ ПРИ РОЗРОБЦ1 ЕКСПЕРТНИХ СИСТЕМ
Виконано поргвняння ефективностг застосування реляцшно'1 (MySQL) та нереляцшно'1 (Neo4j) систем управлтня базами даних для побудови бази знань експертних систем з використанням семантично'1 мережг. Уякостг графовое системи управлгння базами даних розглянуто найбшьш вгдомого представника таких систем — Neo4j з власною мовою запитгв Cypher. Графовi бази даних добре застосовн для анализу зв 'язюв, тому великий ттерес представляв використання графових баз даних для створення експертних систем, для яких природньою в графова структура даних.
На прикладах формування певних запитiв з використанням двох ргзних моделей даних, з 'ясовано, чи в графова модель бшьш дощльним ршенням при проектувант та створеннi семантичних мереж, де потрiбно збер^ати та обробляти склады iврархiчнi зв 'язки мiж об 'вктами.
Для порiвняння ефективностi двох систем управлiння базами даних використанi наступш показники: певний набiр запитiв (мовами MySQL та Cypher), швидюсть Их обробки та простота розумтня запитiв.
При розглянутому обсязi даних, достатньому для формування експертно'1 системи зроблено висновок, що виявлення переваг графово'1 бази даних, таких як висок показники швидкостi роботи запитiв та лакотчтсть коду не вiдбувавться.
Анализ виконання тестiв продемонстрував, що обидвi системи управлiння базами даних впорались майже однаково. Час пошуку в реляцтнш i графовш базi даних вiдрiзнявться не суттвво. Складнощi при формуванш запитiв в реляцтнш базi даних можна уникнути зокрема за рахунок нестандартних алгоритмiчних рШень.
Ключовi слова: бази даних, графова модель, запит, iврархiчнi зв'язки, модель даних, мова запитiв Cypher, реляцтна модель, семантична мережа, структури даних, Java, Neo4j.
Н.А. СОЛОДКАЯ, Е.А. ПОЛИЩУК, О.А. ЛЯШЕНКО
Государственное высшее учебное заведение «Украинский государственный химико-технологический университет», г. Днипро
ИСПОЛЬЗОВАНИЯ ГРАФОВОЙ И РЕЛЯЦИОННОЙ МОДЕЛЕЙ ДАННЫХ ПРИ РАЗРАБОТКЕ ЭКСПЕРТНЫХ СИСТЕМ
Выполнено сравнение эффективности применения реляционной (MySQL) и нереляционной (Neo4j) систем управления базами данных для построения базы знаний экспертных систем с использованием семантической сети. В качестве графовой системы управления базами данных рассмотрен наиболее известный представитель таких систем — Neo4j с собственным языком запросов Cypher. Графовые базы данных хорошо применимы для анализа связей, поэтому большой интерес представляет использование графовых баз данных для создания экспертных систем, для которых естественной является графовая структура данных.
На примерах формирования определенных запросов с использованием различных моделей данных, выяснено, является графовая модель более целесообразным решением при проектировании и создании семантических сетей, где нужно хранить и обрабатывать сложные иерархические связи между объектами.
Для сравнения эффективности двух систем управления базами данных использованы следующие показатели: определенный набор запросов (на языках MySQL и Cypher), время выполнения для заданного размера записей (скорость их обработки), простота понимания и программной реализации запросов. При рассматриваемом объеме данных, достаточном для формирования экспертной системы, можно сделать вывод, что выявление преимуществ графовой базы данных, таких как высокие показатели скорости работы запросов и лаконичность кода не происходит.
Анализ тестов показал, что обе системы управления базами данных справились почти одинаково. Время поиска в реляционной и графов базе данных отличается не существенно Сложности при формировании запросов в реляционной базе данных можно избежать в том числе за счет нестандартных алгоритмических решений.
Ключевые слова: базы данных, графова модель, запрос, иерархические связи, модель данных, реляционная модель, семантическая сеть, структуры данных, язык запросов Cypher, Java, Neo4j.
N O. SOLODKA, E.O. POLISHYK, О.А. LIASHENKO
Ukrainian State University of Chemical Technology, Dnipro
USING THE GRAPH DATABASE MODEL AND THE RELATIONAL MODEL WHILE
DEVELOPING EXPERT SYSTEMS
Comparison of the effectiveness of the use of relational (MySQL) and non-relational (Neo4j) database management systems for building an expert systems knowledge base. The semantic network is chosen as a model of knowledge representation models. As the graph database management system, the most prominent representative of such systems - Neo4j with its own language of queries Cypher - is considered. Graph databases are well suited for analyzing interconnections, which is why there has been a lot of interest in using graph databases to create expert systems.
Using the examples of forming certain requests using two data models, it was found out that the graph model is a more expedient solution for designing and creating semantic networks where you need to store and process complex hierarchical connections between objects.
To compare the effectiveness of the two database management systems, the following indicators were used: the certain query set (in MySQL and Cypher languages), execution time for a given entries size, ease of understanding and software implementation requests.
With the considered volume of data sufficient to form an expert system, it can be concluded that the identification of the advantages of a graph database, such as high rates of query performance and code brevity does not occur.
Analysis of the tests showed that both database management systems performed handled almost the same. Execution time in the relational database and graph database is not significantly different. Difficulties in forming queries in a relational database can be avoided, including through non-standard algorithmic solutions.
Keywords: database, graph model, query, hierarchical relationships, data model, relational model, semantic network, data structures, query language Cypher, Java, Neo4j.
Постановка проблеми
Найбшьш поширеною моделлю представления знань в експертних системах (ЕС) е семантична мережа, як найбшьш наочна та доступна для програмно! реатзаци. Семантичш мереж зображуються у виглядi орiентованого графа або дерева, яке мае кореневий вузол та вузли без нащадшв.
Не зважаючи на те, що з 1980-х рр. реляцшш моделi даних поадають домiнуюче положення серед засобiв збереження даних, з часом перед розробниками програмних додатшв стали виникати завдання, для виршення яких реляцшш бази даних (БД) не завжди дають задовшьш результати в плаш швидкосп виконання запипв та простоти ввдображення структури даних [1]. Бшьш того, iнодi програмна реалiзацiя запипв мовою SQL е складним питанням. Наприклад, якщо е необхiднiсть реалiзувати багаторiвневi зв'язки в реляцiйнiй БД, то це буде багаторiвневий ланцюг складних запитiв на основi з'еднань join.
Традицшно в реляцiйнiй базi даш зберiгаються в стовпцях i рядках. Тим не менш, стовпцi та рядки насправдi це не так, як даш юнують в реальному свт. Скорiше, данi iснують як об'екти та вшносини мiж ними [1]. Саме в ЕС вшносини мiж даними часто можуть бути бшьш цшними, нiж самi даш. А реляцшна модель виявляеться не досить гнучкою для створення складних запипв, обробки рiзноманiтних iерархiчних i багаторiвневих зв'язк1в мiж об'ектами.
Як альтернатива реляцшних баз даних SQL з початку 2000-х набули свого розвитку так зваш NoSQL (Not only SQL, не тшьки SQL) сховища даних [2]. Одна з гшок таких баз даних - графов^ де даш збер^аються не у виглядi таблицi, а у виглядi графа. Основними елементами графово! моделi е вузли i зв'язки [3].
Графовi бази даних мають перевагу при роботi з даними, для яких саме зв'язки м1ж об'ектами вщграють важливу роль, особливо якщо е необхшшсть вiдстежувати зв'язки на декшька рiвнiв вглибину. У той час як реляцшш бази даних обчислюють з'еднання пiд час запиту через важю операцп join, графова база даних збертае з'еднання разом з даними в моделi [4].
Зазначеш преваги та сучасш тенденцп з вирiшения деяких задач на основi збереження шформацп у виглядi графiв та питання оптимально! обробки самих вшношень та зв'язшв мiж ними, спонукали обрати графову модель збереження даних при розробщ експертно! системи, для яко! природною е графова структура даних. Вибiр саме графово! БД для реал1зацп семантично! мереж1 в ЕС може спростити складнiсть алгоритмiв саме завдяки сво!й архiтектурi.
Аналiз останшх дослвджень i публiкацiй
У зв'язку i3 бурхливим ростом обсяпв шформацп на початку 2000-х розвиток отримав напрямок NoSQL. Зокрема, огляду, аналiзу та порiвнянню реляцiйних та нереляцiйних баз даних присвячено ряд публiкацiй [5-11]. Але наведеш дослщження не стосувалися проектування та розробки експертних систем з використанням семантичних мереж у якосп моделi представления знань.
Формулювання мети дослiдження Метою роботи було порiвняння ефективностi застосування реляцшно! та нереляцшно! моделей збереження даних для побудови бази знань експертно! системи з використанням семантично! мереж1. На прикладах формування одних i тих самих запипв з використанням рiзних моделей даних, з'ясувати, чи е графова модель бiльш доцiльним ршенням при проектуваннi та створеннi семантичних мереж, де потрiбно зберiгати та обробляти складш iерархiчнi зв'язки м1ж об'ектами.
Викладення основного матерiалу дослвдження Серед вiдомих графових БД можна видiлити AllegroGraph; FlockDB; Giraph; Apache HyperGraphDB; InfoGrid; Neo4j; SparkSee, Titan; [12].
Neo4j - найбiльш популярна графова БД, побудована на основi атьово! моделi даних з вщкритим вихiдним кодом, реалiзована на Java. Станом на 2015 рш вважаеться найпоширешшою графовою БД.
В графовiй БД Neo4j використовуеться власна мова запитiв та машпулювання даними - Cypher. Але запити можна робити також в шший споаб, наприклад, безпосередньо через Java API i на мовi Gremlin, створеному в проекп з вщкритим вихвдним кодом TinkerPop. 1нтерфейс програмування додатк1в для СУБД реал1зований для багатьох мов програмування, включаючи Java, Python, Clojure, Ruby, PHP, також реалiзовано API в CTrai REST. Neo4j мае обмеження: не бшьше 34 мiльярдiв вузлiв.
Архитектура Neo4j розроблена для ошгашзацп таких процеав, як управлiння, зберiгання та обхщ вузлiв i зв'язк1в. В Neo4j вiдношення е важливими об'ектами, яш представляють собою зв'язки мiж сутностями. Операцiя, що зазначена вище та вiдома в реляцiйнiй базi як об'еднання (join), продуктивнiсть яко! падае експоненцiйно з числом вщносин, в Neo4j здiйснюеться як навтащя вiд одного вузла до шшого, алгоритм роботи якого е лшшним [13].
Версп СУБД, як1 використовувались для тестування: Neo4j 3.2.3, MySQL 5.6(x64). Тестування вiдбувалося на персональному компютерi з наступними характеристиками: процесор Intel(R) Core(TM) i5-3210M CPU @2.50GHz, 64-розрядна операцiйна система, процесор х64, обсяг оперативно! пам'ятi 6 ГБ.
Для проведення порiвняння необхiдно насамперед створити таблиц у MySQL, а далi заповнити бази MySQL та Neo4j однаковими даними.
В MySQL задано наступну структуру таблицi test_table, в як1й передбачено лише два атрибути: out_node - значення батьшвського вузла; CREATE TABLE 4est_table' ( out_node' int(11) NOT NULL, in_node' int(11) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin 1; ALTER TABLE 4est_table' ADD UNIQUE KEY 'out Oout_node'), ADD UNIQUE KEY 4n Oin_node4); На обидва поля встановлено BTREE iндекси для прискорення операцп' зчитування даних. Було створено 1000 запиав. Нульовий елемент (колонка out_node) зв'язаний з першим (колонка in_node), перший (колонка out_node) з другим (колонка in_node) i таким чином до останнього. В Neo4j задано наступну структуру полей:
CREATE (test[Index] {value: [Index] })-[:LINK]->(test[Index] +1 {value: [Index] +1}) 1ндекси на вузлах не застосовувались. Для вимiру використовувалась вся потужшсть задано! множини (1000 елеменпв).
Для генерацп тестових даних написано код на мовi PHP: <?php
$mode = $argv[1]; $count = $argv[2] ?: 1000;
if ($mode == 'sql') {
$sql_code = "INSERT INTO 4est_table' Oout_node\ 4in_node4) VALUES\n"; for ($i = 0; $i < $count; $i++) {
$sql_code .= sprintf('(%d, %d),', $i, $i + 1) . "\n";
}
$sql_code = rtrim($sql_code, "\n,") . ';';
"\n";
file_put_contents('generator.sql', $sql_code);
}
if ($mode == 'cypher') {
$cypher_code = 'CREATE '; for ($i = 0; $i < $count; $i++) {
$cypher_code .= sprintf('(test%s)-[:LINK]->(test%s {value: %s}),', $i, $i + 1, $i + 1) .
}
$cypher_code = rtrim($cypher_code, "\n,");
file_put_contents('generator.cypher', $cypher_code);
Для nopiBHHHHfl ефективностi двох СУБД використанi наступш показники: певний Ha6ip запитiв, швидшсть !х обробки, простота розумiння та програмно1 реалiзацil запитiв. Зокрема, розглянуто два запити: пошук кореневого вузла (Q1) та багаторiвнева вибiрка вузла (Q2).
Запит Q1 в Neo4j: MATCH (n) WHERE NOT (n)<-[]-() RETURN n
Час виконання запиту Q1 у графовiй БД Neo4j дорiвнюe 3 мс; результат його виконання зображено на рис. 1.
Запит Q1 мовою SQL:
SELECT out_node FROM 'test_table' WHERE out_node NOT IN (SELECT in_node FROM 'test_table');
Час виконання запиту Q1 у релящйнш БД дор1внюе 0,2 мс; результат йоге виконання зображено на рис. 2.
Запит Q2 в графовш базi даних Neo4j:
MATCH result = ({ value:0 })-[*]->({ value:1000 }) RETURN result
Час виконання запиту Q2 у графовш СУБД Neo4j дорiвнюe 3 мс; результат його виконання зображено на рис. 3.
Рис. 1. Результат виконання запиту Q1 у графовш БД Neo4j
Check all With selected: Edit Copy @ Delete g Export Рис. 2. Результат виконання запиту Q1 у реляцшнш БД MySQL
"labels": [],
Рис. 3. Результат виконання запиту Q2 у графовш БД Neo4j
Запит Q2 мовою SQL: SELECT out_node, in_node FROM (SELECT * FROM test_table ORDER BY out_node, in_node) nodes_sorted,
(SELECT @pv := '1') initialisation WHERE fmd_in_set(out_node> @pv) AND length(@pv := concat(@pv ',', in_node)) AND in_node != 1000; Час виконання запиту Q2 у реляцшнш БД Neo4j дорiвнюe 1.2 мс; результат його виконання зображено на рис. 4.
+ Options out node in node
976 977
977 973
97В 979
979 980
980 981
981 982
982 983
983 984
984 985
985 986
986 987
987 983
98В 989
989 990
990 991
991 992
992 993
993 994
994 995
995 996
996 997
997 993
99В 999
40
Number of rows:
25
Рис. 4. Результат виконання запиту Q2 у реляцшнш БД MySQL
Функщя find_in_set буде сутгево сповшьнюватися Í3 збiльшенням запиав у таблицi. Також потенцiйно може спогворигися порядок виконання команд запипв, якщо розташувати запит всерединi шшого.
Висновки
1. За результатами тестування визначеш час виконання двох титв запитiв на обсязi 1000 запиав (вузлiв) та наведенi скрипти для оцшки простоти розумiння програмно! реалiзацi! коду.
2. Проведене порiвняння на основi розроблених запитiв показало, що обидвi БД впорались iз розглянутими у тестах запитами на заданому обсязi даних однаково ефективно. Час пошуку в реляцiйнiй i графовш базi даних вiдрiзняеться не суттево.
3. Продемонстровано, як за рахунок нестандартних алгоритмiчних рiшень та стороншх модулiв, яш розширюють можливостi SQL, можна реалiзувати роботу iз iерархiчною структурою в SQL, як це зроблено при реалiзацi! запиту Q2 (багаторiвнева вибiрка вузла).
4. Не зважаючи на привабливiсть графово! структури для реалiзацi! семантично! мереж1 в £С, де потрiбно зберiгати та обробляти складш iерархiчнi зв'язки м1ж об'ектами, традицiйний пiдхiд з використанням реляцшно! БД також може бути застосовано, осшльки обсяг даних не достатнш для виявлення переваг графово! БД, таких як висош показники швидкостi виконання запитiв та лакошчшсть коду.
Список використаноТ лiтератури
1. Hunger M., Boyd R., Lyon W. The Definitive Guide to Graph Databases for the RDBMS Developer: ebook. 2016. 28 p. URL: https ://neo4j. com/whitepapers/rdbms-developers-graph-databases-ebook/?utm source=odbms&utm campaign=dl&utm expid=.Iz8KdWvSRy2NIqH2l3CMPw.0&utm r eferrer=http%3A%2F%2Fwww.odbms.org%2F2016%2F02%2Fthe-definitive-guide-to-graph-databases%2F (дата звернення: 11.10.2018).
2. NoSQL базы данных: понимаем суть [Електронний ресурс]. - Режим доступу: http://habrahabr.ru/post/152477/. - Загол. з екрану.
3. Robinson I, Webber J, Eifrem E. Graph Databases. - O'Reilly Media, 2015. - 178 p.
4. Мелешко Е.А. Причины и предусловия применения нереляционных баз данных / Мелешко Е.А., Лозицкая Л.Г. [Електронний ресурс]. - Режим доступу: http://www.rusnauka.eom/4 SND 2012/Informatica/4 99281.doc.htm.
5. A comparison of a graph database and a relational database: a data provenance perspective / Chad Vicknair et.al. ACM SE '10 Proceedings of the 48th Annual Southeast Regional Conference, Oxford, Mississippi — April 15 - 17, 2010. NY:ACM New York, 2010. Article No. 42. table of contents ISBN: 978-1-4503-0064-3 doi>10.1145/1900008.1900067.
6. Глибовець А.М. Порiвняння Neo4 i реляцшно! бази даних MySQL / А.М. Глибовець, А.О. Добрянський // Науковi записки НаУКМА. Комп'ютерш науки. - 2015. - Т. 177. - С. 108-112. -Режим доступу: http://nbuv.gov.ua/UJRN/NaUKMAkn 2015 177 21
7. R. Angles, C. Gutierrez Survey of graph database models. ACM Computing Surveys, Vol. 40, No. 1, Article 1. New York, NY: ACM, February 2008. 39 р.
8. Salim Jouili, Valentin Vansteenberghe. An empirical comparison of graph databases. SOCIALCOM '13: Proceedings of the 2013 International Conference on Social Computing, Alexandria, VA, USA, September 08-14, 2013. Washington: IEEE Computer Society, 2013. P. 708-715. doi>10.1109/SocialCom.2013.106.
9. Garima Jaiswal, Arun Prakash Agrawal. Comparative analysis of Relational and Graph databases. IOSR Journal of Engineering (IOSRJEN). Vol. 3, Issue 8 (August. 2013), ||V2|| P. 25-27. URL: http://www.iosrjen.org/Papers/vol3_issue8%20(part-2)/E03822527.pdf (дата звернення: 11.10.2018). DOI: 10.9790/3021-03822527.
10. Srinath Srinivasa Data, Storage and Index Models for Graph Databases. Graph Data Management: Techniques and Applications, IGI Global, Chapter 3, 2012. P. 47-71. DOI: 10.4018/978-1-61350-053-8.ch003.
11. A Comparison between a Relational Database and a Graph Database in the context of a Personalized Cancer Treatment Application / Martinez А. et.al. Alberto Mendelzon International Workshop on Foundations of Data Management, Panama City, Panamá, June 2016. AMW. Vol.1644. URL: http://ceur-ws.org/Vol-1644/paper37.pdf.
12. List Of NOSQL Databases [Електронний ресурс]. - Режим доступу: http://nosql-database.org/. -Загол. з екрану.
13. Cypher, The Graph Query Language: [Електронний ресурс]. - Режим доступу: https://neo4j.com/cypher-graph-query-language - Загол. з екрану.
