As with any graph database management system, native graph databases revolve around the idea of storage and use of query engines, which deals specifically with connected data persistence and traversal queries. The database query engine is in charge of operating queries, modifying, and extracting data. Native graph databases showcase the traversal of the graph data model paired with strategic index usage for locating the starting nodes for such operations. Storage involves how data can be physically housed and how it can be represented during extraction. Understanding graph database storage nuances is key to selecting the right graph database for your use case.
Relationships Matter: Non- and Native Graph Databases
Relationships are integral in any domain and requires frequent transversal. In a graph database, relationships are strictly explicit instead of being inferred. Creating explicit relationships can be gained either through the query engine on a non-native or native graph storage.
A graph database that depends on a non-native graph storage has relationships that will need to be inferred at runtime. For instance, if we intend to model an RDBMS graph, the processing engine will need to infer relationships through foreign keys while making the relationship concrete at runtime. This would be an expensive approach and won’t be feasible to traversing relationships due to the involvement of recursive joins.
Native Graph Databases and Index-Free Adjacency
As a native graph database, Neo4j turns relationships into first class entities in data records at store levels. It doesn’t place a layer of graph on an existing database storage engine. At the store level, Neo4j writes and reads data from the disk using techniques that are optimized for graph transversal.
Native graph databases utilizes a method known as the “index-free” adjacency.” It means that every data element is aimed directly to its incoming and outgoing relationships. This, in turn, point towards related
No comments:
Post a Comment