Graph Database An Alternative for Relational Database

Abstract. Directed Acyclic Graph (DAG) is a directed graph which is not cyclic and is usually employed in social network and data genealogy. Based on the characteristic of DAG data, a suitable database type should be evaluated and then chosen as a platform. A performance comparison among relational database (PostgreSQL), document-oriented database (MongoDB), and graph database (Neo4j) on a DAG dataset are then conducted to get the appropriate database type. The performance test is done on Node.js running on Windows 10 and uses the dataset that has 3910 nodes in single write synchronous (SWS) and single read (SR). The access performance of PostgreSQL is 0.64ms on SWS and 0.32ms on SR, MongoDB is 0.64ms on SWS and 4.59ms on SR, and Neo4j is 9.92ms on SWS and 8.92ms on SR. Hence, relational database (PostgreSQL) has better performance in the operation of SWS and SR than document-oriented database (MongoDB) and graph database (Neo4j).Keywords: database performance, directed acyclic graph, relational database, document-oriented database, graph database Abstrak. Directed Acyclic Graph (DAG) adalah graf berarah tanpa putaran yang dapat ditemui pada data jejaring sosial dan silsilah keluarga. Setiap jenis database memiliki performa yang berbeda sesuai dengan struktur data yang ditangani. Oleh karena itu perlu diketahui database yang tepat khususnya untuk data DAG. Tujuan penelitian ini adalah membandingkan performa dari relational database (PostgreSQL), document-oriented database (MongoDB) dan graph database (Neo4j) pada data DAG. Metode yang dilakukan adalah mengimplentasi dataset yang memiliki 3910 node dalam operasi single write synchronous (SWS) dan single read (SR) pada setiap database menggunakan Node.js dalam Windows 10. Hasil pengujian performa PostgreSQL dalam operasi SWS sebesar 0.64ms dan SR sebesar 0.32ms, performa MongoDB pada SWS sebesar 0.64ms dan SR sebesar 4.59ms sedangkan performa Neo4j pada operasi SWS sebesar 9.92ms dan SR sebesar 8.92ms. Hasil penelitian menunjukan bahwa relational database (PostgreSQL) memiliki performa terbaik dalam operasi SWS dan SR dibandingkan document-oriented database (MongoDB) dan graph database (Neo4j).Kata Kunci: performa database, directed acyclic graph, relational database, document-oriented database, graph database

Download Full-text

Relational database and graph database: A comparative analysis

Journal of Process Management New Technologies ◽

10.5937/jouproman5-13553 ◽

2017 ◽

Vol 5 (2) ◽

pp. 1-9

Author(s):

Surajit Medhi ◽

Hemanta Baruah

Keyword(s):

Comparative Analysis ◽

Relational Database ◽

Graph Database

Download Full-text

The study on data migration from relational database to graph database

Journal of Physics Conference Series ◽

10.1088/1742-6596/1345/2/022061 ◽

2019 ◽

Vol 1345 ◽

pp. 022061

Author(s):

Zhihong Nan ◽

Xue Bai

Keyword(s):

Relational Database ◽

Data Migration ◽

Graph Database

Download Full-text

Process, Analyze and Visualize Telecommunication Network Configuration Data in Graph Database

Vietnam Journal of Computer Science ◽

10.1142/s2196888820500037 ◽

2019 ◽

Vol 07 (01) ◽

pp. 65-76

Author(s):

Péter Lehotay-Kéry ◽

Attila Kiss

Keyword(s):

Relational Database ◽

Telecommunication Network ◽

Graph Database ◽

Network Configuration ◽

Vast Number ◽

Customer Support ◽

Storage Size ◽

Disk Space ◽

Configuration Data ◽

And Storage

In network telemetry systems, nodes produce vast number of configuration files based on how they are configured. Steps were taken to process these files into databases to help the work of the developers, testers and customer support to focus on the development and testing and to be able to give advice to the customers about how to configure the nodes. However, the processing of these data in relational database manager system is slow, hard to query and the storage takes huge disk space. In this paper, we are presenting a way to store the data produced by these nodes in graph database, changing from relational database to NoSQL environment. With our approach, one can easily represent and visualize the network of machines. In the end, we are going to compare the inserting, querying time and storage size in different database manager systems. The results could also be used for other types of configuration data too from other kinds of machines to show the connection between them and query them easily.

Download Full-text

Working with Legacy Relational Data in A Graph-Based World

International Journal for Population Data Science ◽

10.23889/ijpds.v5i5.1629 ◽

2020 ◽

Vol 5 (5) ◽

Author(s):

James Farrow

Keyword(s):

Relational Database ◽

Relational Data ◽

Graph Database ◽

Metadata Record ◽

Relational Database System ◽

Record Data ◽

Linkage Information ◽

Legacy Data ◽

Graph System ◽

Link Information

The Next Generation Linkage Management System (NGLMS) was designed around keeping all data in a graph database. However, this constraint, while easily achievable for greenfield projects and/or new data linkage units, may not be easily met where legacy data exists. Objectives and ApproachThe NGLMS was extended to encompassed system where data was held partially or even completely in a relational database. By grouping the data managed by the NGLMS into system metadata, record link data and record data and allowing system metadata and record data to be stored separately and independently in either a relational or a graph database, the NGLMS allows hybrid installations of mixed graph and relational data and, with some loss of functionality, purely relational installations. ResultsThe functionality of the NGLMS was expanded to allow review of existing legacy data stored in a relational database system. Through minor changes to the server used by the NGLMS Clerical Review tool (NGLMS-CR) the review tools was able to present the same interface and allow the same integration as project stored completely within the graph database. Hybrid projects where link information was stored in a graph could be accommodated with no loss of functionality.Relational-only projects allowed clerical review of identified clusters in a manner identical to the graph-only NGLMS but involved some curtailment of the advanced clustering, time-slicing, compositional and concurrent functionality of the NGLMS due to the loss of the functionality provided by a graph database. They do provide an upgrade pathway to hybrid projects and then graph-only projects. Conclusion / ImplicationsAllowing the NGLMS to be configured as a hybrid system enables a gradual adoption of the NGLMS toolset and software. purely relational data still allows the use of the NGLMS-CR with customisable workpools and workflows a hybrid relational/graph system where record data is still kept in a relational store but cluster and linkage information is kept in the graph store allows the use of legacy data without major disruption and provides a pathway to full adoption

Download Full-text