Graph Databases for Beginners: Native vs. Non-Native Graph Technology
No technology is equally good at everything, and databases are no exception. It’s possible for databases to satisfy different kinds of functions: batch and transactional workloads, memory access and disk access, SQL and XML access and graph and document data models.
When building a database management system (DBMS), development teams must decide early on what cases to optimize for, which will dictate how well the DBMS will handle the tasks it is dealt (what the DBMS will be amazing at, what it will be ok at and what it may not do so well).
As a result, the graph database world is populated with both technology designed to be “graph first,” known as native, and technology where graphs are an afterthought, classified as non-native.
There’s a considerable difference when it comes to the native architecture of both graph storage and processing. Unsurprisingly, native technologies tend to perform queries faster, scale bigger (retaining their hallmark query speed as the data set grows in size) and run more efficiently, calling for much less hardware. As a result, it’s critical to understand the differences.
In this “Graph Databases for Beginners” blog series, we have covered why graphs are the future a tour of aggregate stores and other graph data technologies Now that we have a relatively comprehensive grasp of the basics, it is time to go over the differing internal properties of a graph database. Today, we will discuss some of the characteristics that distinguish native graph databases and why these characteristics are of interest to graph database users. There are two main elements that distinguish native graph technology: storage and processing.
Graph storage commonly refers to the underlying structure of the database that contains graph data. When built specifically for storing graph-like data, it is known as native graph storage. Graph databases with native graph storage are optimized for graphs in every aspect, ensuring that data is stored efficiently by writing nodes and relationships close to each other. Graph storage is classified as non-native when the storage comes from an outside source, such as a relational, columnar or other NoSQL database.
These databases use other algorithms to store data about nodes and relationships, which may end up being placed far apart. This non-native approach can lead to latent results as their storage layer is not optimized for graphs.
Native graph processing is another key element of graph technology, referring to how a graph database processes database operations, including both storage and queries. Index-free adjacency is the key differentiator of native graph processing. At write time, index-free adjacency speeds up storage processing by ensuring that each node is stored directly to its adjacent nodes and relationships. Then, during query processing (i.e., read time), index-free adjacency ensures lightning-fast retrieval without the need for indexes. Graph databases that rely on global indexes (rather than index-free adjacency) to gather results are classified as having non-native processing. Another important consideration is ACID writes . Related data brings an uncommonly strict need for data integrity beyond that of other NoSQL models.
In order to store a connection between two things, we must not only write a relationship record but update the node at each end of the relationship as well. If any one of these three write operations fails, it will result in a corrupted graph. The only way to ensure that graphs aren’t corrupted over time is to carry out writes as full ACID transactions. Systems with native graph processing include the proper internal guard rails to ensure that data quality remains impervious to network blips, server failures, competing transactions and the like.
To dive into further detail, the element that makes a graph storage native is the structure of the graph database from the ground up.
