Graph databases are a powerful data structure that can be applied to solve a variety of problems. They are widely used in electronic communications network due to the need for effective management of complex network structures, where traditional relational databases do not always provide sufficient performance and flexibility. There are many graph mapping algorithms. Each of them has its own characteristics and best areas of use. In this paper, Neo4j, Memgraph and ArangoDB graph databases are considered and compared for query performance in an experiment on the same data set by measuring query execution time. Also, a usability estimation is given for Neo4j, Memgraph and ArangoDB, which based on number of GitHub users, number of image downloads, support ability, deployment ability and supported programming languages.
[
Also, graph databases are used in the field of machine learning to create graph-based models, which allows to improve the accuracy of forecasting and data analysis using graph neural networks
Graphs are inherently additive, which means we can add new kinds of connections, nodes, labels, and subgraphs to an existing structure without breaking existing queries and application functionality.
Modern graph databases provide an ability to perform seamless development. In particular, the schema-free nature of the graph data model, combined with the ability to test the graph database application programming interface (API) and query language, allows to develop the application in a controlled manner.
Graph databases carry out a special role in electronic communications network, since a significant part of the algorithms performing in such systems are based on graphs. Therefore, the use of graph databases for this area is ponderable or even inevitable. Applying the graph databases in electronic communications network is discussed in the next section of this paper.
Importance of graph databases is unlikely to be overestimated in our time. However, these
databases also have some limitations, which should be taken into account when choosing this
technology to solve certain problems. One of the main limitations is scalability. Although graph
databases are great at managing relationships, they can struggle with horizontal scaling, which is
more easily implemented in other NoSQL databases. Another limitation is the complexity of graph
algorithms and queries, which can be computationally intensive and slow down as the graph size
increases. In addition, the integration of graph databases with existing data systems can be difficult,
requiring significant changes in data models and application logic [
Also, it is worth noting that there is no standardized query language for graph databases. It depends on the particular database. This can make it difficult to migrate from one provider to another, as different query languages may differ in functionality and syntax.
Graph databases have also found a prominent place in electronic communications network. They are widely used to improve network management, optimize traffic and ensure communication reliability. Graph databases make it possible to model complex network topologies more effectively, analyze connections between nodes and optimize routing.
For instance, paper [
Social networks are a large graph itself, that require multiple graph database servers to store and
manage them. Each database server hosts a graph partition for load balancing purposes. Achieving
these goals requires a dynamic redistribution algorithm. The following paper [
The knowledge graph, built using this data, provides a single, semantically enriched model that can support complex, cross-referenced queries. For instance, the system can identify users affected by a network incident, analyze user behavior trends, and suggest optimizations for network performance. Integrating these diverse data models into a graph database enables a user-aware network monitoring approach that links technical data with business insights, enhancing operational efficiency and service quality for electronic communication providers.
The following paper [
Paper [
Databases are a critical part of the electronic communications industry as they store and manage a vast amount of data relating to various aspects of electronic communications infrastructure, services and customers. Today's electronic communications compan intelligent, secure, and flexible data management practices driven by the increasing volume and complexity of data. Leveraging these advances allows electronic communications companies to gain a competitive advantage, improve operational efficiency, and provide innovative services to their customers.
Graph databases are becoming indispensable components of electronic communications network as they are designed to store and process data with a significant level of relationships between entities and with the possibility of painless changes of these relationships.
The essence of such kinds of databases implementation is that actually they are a superstructure on other types of data models, such as relational, NoSQL or others. As already mentioned above, there is no standardization in this area, which causes portability and other issues.
Since the development and improvement of graph databases are still ongoing, it is important to study various aspects of their behavior, as their drawbacks identification can help to improve similar solutions and contribute to a better understanding of options and approaches to their use. In addition, such studies allow us to outline the possible problems of using one or another database as a mean of implementing a certain technological solution. Therefore, the topic of this study is relevant and requires meticulous work.
This study aims to evaluate the performance of query processing for queries of different purposes in different graph databases. To be more specific, the following selections in graph databases are of particular interest and importance: • • • counting nodes, which meet the specified criteria; searching for the shortest path between nodes; to determine if there are any paths between nodes within reach in n-steps and others.
The obtained evaluations can also provide some support in choosing among graph databases for a specific task.
There can be found a lot of studies comparing graph databases and other types of databases. Let's briefly consider some of them. The most attention was paid to the works related to graph databases as they represent the most interest to the topic of this research.
In paper [
The paper presents comparison tables of such features: data storage, operation and management (availability of query language, graphical interface, API), data graph structure (simple, with attributes, hypergraph, nested graph, labeled node, with attributes, directed edges, labeled), query tools, integrity constraints.
Article [
The experiment aimed to measure an execution time of such requests as: counting nodes of a graph with a depth of 4 and 128, counting the number of nodes that had a node parameter of a certain value.
Queries were made on a database with a different number of nodes (1000, 5000, 10000, 100000), which allowed us to get an insight into how the selected systems scaled. It should be noted that the experiment was conducted on numerical and linear parameters.
A subjective comparison was made on such characteristics as: maturity, level of support, ease of programming, flexibility and security.
As a result, Neo4j outperformed MySQL in graph traversal queries by several times. In queries that did not require traversal, MySQL was faster for integer processing and Neo4j for string processing.
Article [
Comparison results of the following graph databases are also given: Neo4j, OrientDB, TitanBerkeleyDB, Titan-Cassandra and DEX.
As a result of the experiment, Neo4j got the best results with workaround workloads. Neo4j, DEX, Titan-BerkeleyDB, and OrientDB all achieved similar performance on intensive read-only workloads, but for read-write workloads, the performance of Neo4j, Titan-BerkeleyDB, and OrientDB drops dramatically.
Paper [14] describes a comprehensive experimental comparison of several graph database management systems (GDBs). The experiment aimed to evaluate and compare the performance of selected GDBs using a benchmarking tool called BlueBench, developed specifically for this purpose. Databases Neo4j, DEX, InfiniteGraph, OrientDB, Titan, TinkerGraph and others had been explored during the experiment.
The key performance indicators that had been taken into account during the experiment were execution time, scalability, transaction support, and query efficiency. The benchmarking involved running a series of predefined queries and operations on each database, measuring the tasks executing time and databases large-scale data handling. Tests were automated and aimed to be as consistent as possible across different systems to ensure fair comparison.
The results showed significant variations in between the different GDBs. Neo4j, DEX and TinkerGraph performed well in many areas among other graph databases.
Of particular interest in this study are those graph databases that are free, open-source and have use cases related with networks, traffic management and so on. Therefore, attention is focused on the following databases: Neo4j, Memgraph and ArangoDB. Let us provide some other arguments for this choice.
Neo4j is considered one of the most popular graph databases, it can be installed on the machine locally. This database has a lot of study materials, tutorials and examples so it is relatively easy to learn how to use it.
Memgraph is compatible with Neo4j and also uses Cypher language to write queries so it is easy to rewrite queries to use in this database. It is well-documented, and has libraries for various programming languages (at least twelve according documentation). This database also has good reviews and tutorials.
ArangoDB supports a lot of data models and, according to its documentation, can be a great fit
for use cases like network operations, traffic management, collect IoT data etc.
5.1. Neo4j
Neo4j [
Cypher, a SQL-like query language, is used for queries; LPG (Labeled Property Graph) in Neo4j is a graph data model that represents data using nodes, relationships, and properties; the scheme is optional when deploying a data set; ACID compliant. Neo4j database integrity is based on atomicity, consistency, isolation, and durability; supports data export in *.json and Excel formats.
Neo4j Desktop is a local environment for developing and managing graph databases on the Neo4j platform. Neo4j Desktop version 4.28.0 was installed and DBMS of version 5.20.0 enterprise were used to conduct an experiment, which is described in the following section of this paper. It is important to mention that APOC 5.20.0 plugging was used to get *.csv file from *.dump file.
Memgraph is a graph database designed for real-time processing and analysis of large volumes of
data. It was developed and presented in 2016. It is noted that «the fact that Memgraph is written in
C++ and resides in memory means that it is much faster than anything we have seen on the market»
[
Key features of Memgraph: supports Cypher query language; supports ACID in-memory transactions for fast access, storing all records in persistent memory; ensures high performance of both transactional and analytical queries, even in highly competitive environments; supports data export in *.csv and *.json formats.
Memgraph was deployed locally in a container using Docker version 4.33.0 for the current study. The following image for the container was used: memgraph/ memgraph-platform that included memgraph/memgraph-mage version latest and memgraph/lab version latest.
ArangoDB is a native multi-model database that supports graph, document, and key-value data models. It was initially released in 2011 and is implemented in C++ as a NoSQL database. ArangoDB allows to create a complex application with various data models within a single backend.
Key features of ArangoDB: • • • • • • supports AQL (ArangoDB Query Language), which is similar to SQL and designed to handle both structured and unstructured data; provides multi-model capabilities, allowing the use of graph, document, and key-value stores in one engine; ACID compliance; Framework (RDF); features built-in clustering and horizontal scalability, facilitating large-scale distributed deployments; supports data export in formats like *.json and *.csv.
ArangoDB can be run in various environments, including local installations, containers and cloud platforms. The following image was used to run ArangoDB locally on Docker.
To compare graph databases an objective and subjective indicators were used. The objective ones rest on comparing results of performing queries speed; subjective ones estimate the level of support and ability of use in different environments.
The Neo4j dataset of network management [
The dataset consists of 17 unique labels that form 18 different nodes and are interconnected by 12 unique relationship types. This forms approximately 83847 nodes and 181995 relationships.
It includes node types such as DataCenter, Router, Interface, Port, Rack, Switch, Version, Software, etc. Figure 1 shows the scheme of this dataset.
This dataset was taken in three different sizes for the experiment. The largest one contains all nodes and relationships. The middle one has approximately five times less elements of the nodes which aggregate the most data. The smallest one has ten times less data than the largest dataset.
The exact number of nodes and relationships is shown in Table 1.
Performing same queries on graphs of different sizes and comparing obtained results allows us to evaluate scaling ability of databases.
The experiment was carried out using a computer running on the Windows 10 Pro operating system. The machine has 8 GB of RAM and an Intel Core i3-6100 processor operating at a frequency of 3.70 GHz.
Graph databases were launched alternately on the machine during the experiment.
Each query was run ten times. Two maximum and minimum values were discarded and the average of the rest values was taken as the final result.
Ten different queries were used in databases' evaluation. They were grouped by similarity into three groups (Figure 2).
It is worth to be noted that each database has a slightly different syntax in writing queries. Figure 2 shows queries for Neo4j. Memgraph queries syntax is very similar to Neo4j but ArangoDB has its own query language AQL.
Figure 2-a depicts two queries that count how many nodes meeting given criteria there are in a database. It is important to note that for ArangoDB it was possible to write queries only of the first group due to its nature.
Figure 2-b depicts three queries which search for the shortest path from one node type to another.
Figure 2-c shows six queries which determine how many paths there are in exactly n-hops, where n is in the range from 1 to 6. It is also important to note that some combinations of nodes have too many variations of paths for Memgraph to find. Considering this fact, nodes with smaller number of paths were taken for final queries.
This section of the paper outlines obtained results in figures and graphical representation. Query execution time is represented in milliseconds. Section is divided into 4 subsections, three of them describe measurements of a separate group of queries specified above (subsection 7.1-7.3), and the last one introduces an estimation of the considered databases for the availability of support and the possibility of their use in various environments, which is an important criterion in choosing implementation tools for many projects.
First group of queries aims to count number of nodes which meet given criteria. Average query execution time in milliseconds is shown in Table 2, and Figure 3 depicts the dependence of the average query execution time on the size of the graph.
As can be seen, all databases showed similar results but Memgraph scaled slightly worse than other databases and ArangoDB showed the best results.
Second group of queries aims to search for the shortest path from one node type to another. Average query execution time in milliseconds is shown in Table 3, and Figure 4 shows the dependence of the average query execution time on the size of the graph.
As can be seen, for this group of queries Neo4j showed better results, especially for the graph with a large number of nodes. For instance, for the largest considered graph, the average query execution time of query #2.1 in Memgraph is four times higher than in Neo4j, and for graphs with the number of nodes 16854 and 83847, it is near 2 and near 3 times higher respectively. The same pattern is observed with the other two queries. This indicates that on large graphs Memgraph works more slowly with this type of queries. 120 100 8S0 ) M 6(0 E 4IM0 T 20 0 neo4j #2.3 memgraph #2.2 memgraph #2.3
5 L E S S
1 0 L E S S F U L L 5 L E S S
It is important to note that the juxtaposition of the line graphs for the two other queries (queries #2.2 and #2.3) on the same scale is intended to show that both Memgraph queries (line graphs in shades of red) take longer to execute than both Neo4j queries (line graphs in shades of blue).
Third group of queries aims to count how many paths there are in exactly n-hops from the certain node. Average query execution time in milliseconds is shown in Table 4, and Figure 5 depicts the dependence of the average query execution time on the size of the graph.
For this group of queries Neo4j and Memgraph showed similar results for queries #3.1, #3.3, #3.4 and #3.5.
For queries #3.1 and #3.5 Neo4j performed worse on the smallest graph size and better on the biggest. For the query #3.2 Neo4j performed much worse than Memgraph on the largest graph size.
To sum up, for the third group of queries, the performance of the considered databases in most cases was comparable, and the presence of fluctuations in some of them (query #3.2 on the full graph and query #3.5 on the 10less graph) requires further research.
Faced with some difficulties while using the considered databases, it was decided to provide their usability estimation, taking into account various aspects of their practical application, support of programming languages, etc. Let us list the main criteria taken into account for aggregated indicator which is called usability factor: • number of image downloads from the DockerHub platform. It reflects the demand and the prevalence of the database; number of users on the GitHub platform. It shows how many users are interested in the database improvement and may put an effort into its development; availability of user support from the database web page: value 1 if it is available on the web page and value 0 in another case; presence of an active community. Active community helps ameliorate the database which can be expressed in adding new features or drivers to support third-party tools, detection and elimination of vulnerabilities and errors. It is presented by a value 1 if an active community exists and a value 0 in another case; existence of images to deploy in the container. Containerization allows users to rapidly deploy applications and efficiently manage infrastructure. It is presented by a value 1 if it exists possibility of container deployment and value 0 in another case; availability to deploy on different cloud platforms, in particular, AWS, GCP and Azure are taken into account. More and more organizations hold their infrastructure in the cloud, which is why the possibility of database deployment in the cloud is significant. It is represented by a value from 0 to 3 according to the number of specified cloud platforms and the corresponding availability of instructions for deployment on them on the database web page; number of supported programming languages. Official libraries were taken into account. neo4j #3.1 memgraph #3.1 neo4j #3.2 memgraph #3.2 a) c) 25 )20 S (M15 E10 M IT 5
0 300 ) 2S00 M ( E 1IM00 T 0 5000 40)00
S 30(M00 20E00
M 10IT00
0 b) 6000 4)S000 M ( 2ITM000
0
5 L E S S
F U L L neo4j #3.3 memgraph #3.3 5 L E S S
F U L L = ( ∙ 1 5 ( ) 1 + + 1 ∙ (21 + 5 2 5 1 ∙ from official online resources of databases, such as official web pages, GitHub repositories, etc. It is also worth noting that the table contains the number of years the database has been on the market, which is required for further calculation of the aggregated factor.
A following equation (1) was used to calculate usability factor where ai number of image downloads of i-th database; yi number of years on the market of i-th database; bi existence; mi number of GitHub users of i-th database; si
point of i-th database user support point of active community i-th database existence; ci point of i-th database image existence to container deployment; pi
number of i-th database supported cloud platforms; li number of i-th database supported programming languages; ( maximum value among all ; maximum value among all ; lmax maximum value among all li.
Obtained usability factors for considered databases are in Table 5. Figure 6 shows the contribution of each added to the overall usability factor value. It is important to note, that the third addend cumulates user support and active community points (Support in Figure 6) and the fourth addend cumulates database image existence to container deployment and normalized number of supported cloud platforms in equal parts (Deployment ability in Figure 6).
1,1
1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0
Neo4j
languages
As can be seen, Neo4j has an advantage in most positions, which is caused on the one hand by a large number of supported features, and on the other hand by its widespread use among users.
During this study, three graph databases of various graph sizes were assessed through query execution time of 3 query groups. Experiments were conducted on the network management dataset and show that Neo4j demonstrates 2-4 times better performance for most queries compared to Memgraf. At the same time, its performance compared to ArangoDB was somewhat worse in the first group of queries. It was not possible to write the other two groups of queries in ArangoDB due to the peculiarities of its nature and the built-in query writing language. When performing the second group of queries, Neo4j showed significantly better results compared to Memgraph, especially for larger graphs, for instance, the average query #2.1 execution time in Memgraph is from 2 to 4 times higher than in Neo4j depending on the graph size. For the third group of queries, the results of Memgraph and Neo4j are comparable in almost all cases. However, it should be noted that the performance of Neo4j is slightly worse on the queries of the first and third groups when working with a graph of the smallest size. This may be due to the peculiarities of the internal implementation of Neo4j, as it is a NoSQL database by its nature. more detail. Hence, they were estimated by the usability factor and Neo4j has the highest score 0.92. From the subjective point of view, it turned out, that Neo4j is the easiest database to work with. In addition to query complications, importing data into ArrangoDB requires splitting the file separately into nodes by node types and into relationships by their types, and running created files one by one distinctly. It slows down the import process and makes it confusing.
The authors have not employed any Generative AI tools.