Since
Edgar F. Codd's 1970 paper on the
relational model,
relational databases have been the de facto industry standard for large-scale data storage systems. Relational models require a strict schema and
data normalization which separates data into many tables and removes any duplicate data within the database. Data is normalized in order to preserve
data consistency and support
ACID transactions. However this imposes limitations on how relationships can be queried. One of the relational model's design motivations was to achieve a fast row-by-row access. and map more directly to the structure of
object-oriented applications. They can scale more naturally to large datasets as they do not typically need
join operations, which can often be expensive. As they depend less on a rigid schema, they are marketed as more suitable to manage ad hoc and changing data with evolving schemas. Conversely, relational database management systems are typically faster at performing the same operation on large numbers of data elements, permitting the manipulation of the data in its natural structure. Despite the graph databases' advantages and recent popularity over relational databases, it is recommended the graph model itself should not be the sole reason to replace an existing relational database. A graph database may become relevant if there is an evidence for performance improvement by orders of magnitude and lower latency.
Examples The relational model gathers data together using information in the data. For example, one might look for all the "users" whose phone number contains the area code "311". This would be done by searching selected datastores, or
tables, looking in the selected phone number fields for the string "311". This can be a time-consuming process in large tables, so relational databases offer
indexes, which allow data to be stored in a smaller sub-table, containing only the selected data and a
unique key (or primary key) of the record. If the phone numbers are indexed, the same search would occur in the smaller index table, gathering the keys of matching records, and then looking in the main data table for the records with those keys. Usually, a table is stored in a way that allows a lookup via a key to be very fast. Relational databases do not
inherently contain the idea of fixed relationships between records. Instead, related data is linked to each other by storing one record's unique key in another record's data. For example, a table containing email addresses for users might hold a data item called userpk, which contains the
primary key of the user record it is associated with. In order to link users and their email addresses, the system first looks up the selected user records primary keys, looks for those keys in the userpk column in the email table (or, more likely, an index of them), extracts the email data, and then links the user and email records to make composite records containing all the selected data. This operation, termed a
join, can be computationally expensive. Depending on the complexity of the query, the number of joins, and indexing various keys, the system may have to search through multiple tables and indexes and then sort it all to match it together.
Properties add another layer of
abstraction to this structure that also improves many common queries. Properties are essentially labels that can be applied to any record, or in some cases, edges as well. For example, one might label Clark Gable as "actor", which would then allow the system to quickly find all the records that are actors, as opposed to director or camera operator. If labels on edges are allowed, one could also label the relationship between
Gone With the Wind and Clark Gable as "lead", and by performing a search on people that are "lead" "actor" in the movie
Gone With the Wind, the database would produce
Vivien Leigh,
Olivia de Havilland and Clark Gable. The equivalent SQL query would have to rely on added data in the table linking people and movies, adding more complexity to the query syntax. These sorts of labels may improve search performance under certain circumstances, but are generally more useful in providing added semantic data for end users. g.V().hasLabel("person").has("name", "Jack"). out("friendsWith"). hasLabel("person"). values("name") •
SPARQL, an RDF graph database
query language standardized by
W3C and used in multiple RDF
Triple and
Quad stores • Long form PREFIX foaf: SELECT ?name WHERE { ?s a foaf:Person . ?s foaf:name "Jack" . ?s foaf:knows ?o . ?o foaf:name ?name . } • Short form PREFIX foaf: SELECT ?name WHERE { ?s foaf:name "Jack" ; foaf:knows ?o . ?o foaf:name ?name . } • SPASQL, a hybrid database query language, that extends
SQL with
SPARQL SELECT people.name FROM ( SPARQL PREFIX foaf: SELECT ?name WHERE { ?s foaf:name "Jack" ; foaf:knows ?o . ?o foaf:name ?name . } ) AS people ; The above examples are a simple illustration of a basic relationship query. They condense the idea of relational models' query complexity that increases with the total amount of data. In comparison, a graph database query is easily able to sort through the relationship graph to present the results. There are also results that indicate simple, condensed, and declarative queries of the graph databases do not necessarily provide good performance in comparison to the relational databases. While graph databases offer an intuitive representation of data, relational databases offer better results when set operations are needed. ==List of graph databases==