{"id":896,"date":"2016-06-16T22:19:42","date_gmt":"2016-06-17T05:19:42","guid":{"rendered":"https:\/\/database.guide\/?p=896"},"modified":"2023-02-14T12:45:59","modified_gmt":"2023-02-14T02:45:59","slug":"what-is-a-graph-database","status":"publish","type":"post","link":"https:\/\/database.guide\/what-is-a-graph-database\/","title":{"rendered":"What is a Graph Database?"},"content":{"rendered":"

A graph database<\/dfn> is a database that uses a graphical\u00a0model to\u00a0represent and store the data.<\/p>\n

The graph database model is an alternative to the relational model.<\/p>\n

In a\u00a0relational database,\u00a0data is stored in\u00a0tables using a rigid structure with a predefined schema.<\/p>\n

In a graph database, there is no predefined schema as such. Rather, any\u00a0schema is simply a reflection of the data that has been entered. As more varied data is entered, the schema grows accordingly.<\/p>\n

<\/p>\n

What does a Graph Database Look Like?<\/h2>\n

Here’s an example of a simple graph database.<\/p>\n

\"Screenshot<\/a>
Example of a simple graph database.<\/figcaption><\/figure>\n

The blue and green circles are nodes<\/em>. The arrows represent\u00a0relationships<\/em>.<\/p>\n

You can immediately see that\u00a0the relationship that Tom Hanks has with all those\u00a0movies (i.e. the green circles) is that he’s acted in them. But he also has\u00a0directed a movie that he has acted in, so\u00a0he has two relationships with that particular movie.<\/p>\n

Actually, this is not the full database. It’s just the results of a query from the sample Movie database supplied with the Neo4j<\/a> graph database management system.<\/p>\n

Do Graph Databases use SQL?<\/h2>\n

Most graph database management systems are NoSQL systems, meaning, they either don’t support SQL, or they do, but also support other query languages.<\/p>\n

NoSQL originally meant “Non SQL” but this is sometimes\u00a0expanded to mean “Not only SQL”.<\/p>\n

In most cases,\u00a0SQL doesn’t make sense with the graph architecture. Graph databases are typically structured a lot\u00a0differently to the relational model that SQL was designed for.<\/p>\n

Many graph database management systems use\u00a0their own proprietary query language.<\/p>\n

The graph in the previous\u00a0example was generated from the following query:<\/p>\n

$<\/span>MATCH (tom:Person {name: \"Tom Hanks\"})-[:ACTED_IN]->(tomHanksMovies) RETURN tom,tomHanksMovies<\/span><\/pre>\n
That code is written in Cypher – the proprietary query language for Neo4j.<\/p>\n
Some graph database systems support other\u00a0languages such as JavaScript, JSON, XQuery,\u00a0SPARQL, etc<\/p>\n
Graph Database Management Systems (GDBMS)<\/h2>\n
Graph databases are created and managed using a database management system (DBMS<\/a>) specifically designed for graph databases. These can be\u00a0referred to as a Graph Database Management System\u00a0(GDBMS)\u00a0or\u00a0a Graph DBMS.<\/p>\n
Some\u00a0GDBMSs use a relational\u00a0storage engine, while the NoSQL systems\u00a0typically use a completely different architecture for their storage engine, for example\u00a0a key-value store<\/a> or document-oriented database<\/a>.<\/p>\n
Many NoSQL database systems use \u00a0tags<\/i> or properties<\/i>\u00a0to define relationships between nodes. This can help return large amounts of related data without the need to use joins across many tables, as one would be required to do using the relational model using SQL.<\/p>\n
Example of a Graph DBMS<\/h3>\n
Here’s another example of some query results using the Neo4j graph database management system. This time showing the user interface.<\/p>\n
\"Screenshot<\/a>
Example of query results in the Neo4j graph database. The results show the nodes (blue and green circles) and the relationships (arrows) between them.<\/figcaption><\/figure>\n
The graphical representation of data in a graph database is in contrast to the tabular structure presented in the commonly used relational database\u00a0model.<\/p>\n
Example of a Relational DBMS<\/h3>\n
Just for a comparison, here’s an example of a query in MySQL<\/a>\u00a0(a relational<\/em> DBMS). Note the results are displayed in a tabular format (as opposed to the\u00a0nodes and arrows that the graph model uses).<\/p>\n
\"Screenshot<\/a>
A query in MySQL Workbench. The query results are provided in a tabular format.<\/figcaption><\/figure>\n
Benefits of Graph Databases<\/h2>\n
Graph databases can have many benefits over other types of databases, and in particular, relational databases.<\/p>\n
Performance<\/h3>\n
Graph databases can have major performance benefits over relational databases, particularly when it comes to large queries across\u00a0related data.<\/p>\n
Relational\u00a0database applications commonly have queries that join many tables – perhaps 20, 30, or more. Queries like this can run extremely slowly, especially as more and more records are entered into the database. Recursive queries can be a particular issue, especially if they run many levels deep.<\/p>\n
In many cases, if that same data was stored in a graph database, the queries would be much simpler and they would run much quicker.\u00a0This is because, on a graph database, queries are localised to a portion of the graph. This means that the\u00a0execution time for each query is proportional only to the size of the part of the graph traversed to satisfy that query, rather than the size of the overall graph.<\/p>\n
Of course, this all depends on the data.\u00a0The graph model is not necessarily the ideal model for all cases. Some data is more suited to the tabular structure of relational databases. However, the graph model is well suited to querying\u00a0large associative data sets.<\/p>\n
Flexibility<\/h3>\n
Because there’s no need to define a set schema, you have complete flexibility over how the database grows.<\/p>\n
With the\u00a0relational model, you would need to map out the requirements in full detail before creating the database. You need to try to foresee\u00a0any potential change in business requirements and try to build a solution that caters for all possible future scenarios. This is not always possible.\u00a0If the business requirements\u00a0grow\/change\u00a0significantly, the structure of the database may also need to change significantly. It may even have to be completely redone.<\/p>\n
With the graph model, as the business grows, you can always\u00a0add new types\u00a0of relationships, new nodes, and new subgraphs to any existing database\u00a0without disturbing existing queries and application functionality.<\/p>\n
Development and Maintenance<\/h3>\n
Software development has\u00a0evolved to a point where it’s standard practice to release updates\u00a0incrementally and iteratively. This is in contrast to the major release cycle that often took many months or even years.<\/p>\n
Graph databases are well suited to this incremental\/iterative release practice, because\u00a0no underlying structural changes need to take place before any changes can occur on the application.<\/p>\n
What can a Graph\u00a0Database be used for?<\/h2>\n
Graph databases can be used in\u00a0a wide variety of applications. Some popular uses for graph databases include:<\/p>\n