Graph database

In computing, a graph database (GDB[1]) is a database that uses graph structures for semantic queries with nodes, edges and properties to represent and store data. A key concept of the system is the graph (or edge or relationship), which directly relates data items in the store a collection of nodes of data and edges representing the relationships between the nodes. The relationships allow data in the store to be linked together directly, and in many cases retrieved with one operation. Graph databases hold the relationships between data as a priority. Querying relationships within a graph database is fast because they are perpetually stored within the database itself. Relationships can be intuitively visualized using graph databases, making it useful for heavily inter-connected data.[2]

Graph databases are part of the NoSQL databases created to address the limitations of the existing relational databases. While the graph model explicitly lays out the dependencies between nodes of data, the relational model and other NoSQL database models link the data by implicit connections. Graph databases, by design, allow simple and fast retrieval[citation needed] of complex hierarchical structures that are difficult to model[according to whom?] in relational systems. Graph databases are similar to 1970s network model databases in that both represent general graphs, but network-model databases operate at a lower level of abstraction[3] and lack easy traversal over a chain of edges.[4]

The underlying storage mechanism of graph databases can vary. Some depend on a relational engine and “store” the graph data in a table (although a table is a logical element, therefore this approach imposes another level of abstraction between the graph database, the graph database management system and the physical devices where the data is actually stored). Others use a key-value store or document-oriented database for storage, making them inherently NoSQL structures. Most[according to whom?] graph databases based on non-relational storage engines also add the concept of tags or properties, which are essentially relationships having a pointer to another document. This allows data elements to be categorized for easy retrieval en masse.

Retrieving data from a graph database requires a query language other than SQL, which was designed for the manipulation of data in a relational system and therefore cannot “elegantly” handle traversing a graph. As of 2017, no single graph query language has been universally adopted in the same way as SQL was for relational databases, and there are a wide variety of systems, most often tightly tied to one product. Some standardization efforts have occurred, leading to multi-vendor query languages like Gremlin, SPARQL, and Cypher. In addition to having query language interfaces, some graph databases are accessed through application programming interfaces (APIs).

Graph databases differ from graph compute engines. Graph databases are technologies that are translations of the relational OLTP databases. On the other hand, graph compute engines are utilized in OLAP for bulk analysis. Graph databases have attracted considerable attention in the 2000s, due to the successes of major technology corporations in using proprietary graph databases[5], and the introduction of open-source graph databases.

Background

Graph databases, on the other hand, portrays the data as it is viewed conceptually. This is accomplished by transferring the data into nodes and its relationships into edges.   

Graph

Graph databases employ nodes, properties, and edges.

A graph within Graph databases is based on graph theory. It is a set of objects, either a node or an edge.

  • Nodes represent entities or instances such as people, businesses, accounts, or any other item to be tracked. They are roughly the equivalent of the record, relation, or row in a relational database, or the document in a document-store database.
  • Edges, also termed graphs or relationships, are the lines that connect nodes to other nodes; representing the relationship between them. Meaningful patterns emerge when examining the connections and interconnections of nodes, properties, and edges. The edges can either be directed or undirected. In an undirected graph, an edge from a point to another have one meaning. In a directed graph, the edges connecting two different points have different meanings depending on their direction. Edges are the key concept in graph databases, representing an abstraction that is not directly implemented in a relational model or a document-store model.
  • Properties are germane information to nodes. For example, if Wikipedia were one of the nodes, it might be tied to properties such as website, reference material, or words that starts with the letter w, depending on which aspects of Wikipedia are germane to a given database.

Graph Models

Labeled-Property Graph

A labeled-property graph model is represented by a set of nodes, relationships, properties, and labels. Both nodes of data and their relationships are named and can store properties represented by key/value pairs. Nodes can be labelled to be grouped. The edges representing the relationships have two qualities: they always have a start node and an end node, and are directed[6]; making the graph a directed graph. Relationships can also have properties. This is useful in providing additional metadata and semantics to relationships of the nodes[7]. Direct storage of relationships allows a constant-time traversal[8].

It is the most popular form of graph model as of 2018[9], and the model for the most popular graph database as of October 2018, Neo4j[10].

Resource Description Framework (RDF)

An example RDF graph

In a RDF graph model, the addition of information is each represented with a separate node. For example, imagine a scenario where a user has to add a name property for a person represented as a distinct node in the graph. In a labeled-property graph model, this would be done with an addition of a name property into the node of the person. However, in a RDF, the user has to add a separate node called 'hasName' connecting it to the original person node. Specifically, a RDF graph model is composed of nodes and arcs. A RDF graph notation or a statement is represented by: a node for the subject, a node for the object, and an arc for the predicate. A node may be left blank, a literal and/or be identified by a URIref. An arc may also be identified by a URIref. A literal for a node may be of two types: plain(untyped) and typed. A plain literal has a lexical form and optionally a language tag. A typed literal is made up of a string with a URIref that identifies a particular datatype. A blank node may be used to accurately illustrate the state of the data when the data does not have a URI[11].

It is used in The Open Graph protocol used in Facebook to "allow any web page to have the same functionality as any other object on Facebook."[12] and the Semantic Web.

Graph Types

There are multiple types of graphs that can be categorized. Gartner suggests the five broad categories graphs could be sorted into: social, intent, consumption, interest, and mobile graphs [13]. The social graph is about the connections between people. It is an intuitive, widely-implement graph type in the realm of graph databases. For example, Facebook and Twitter are some companies that utilizes the social graph. The well-known idea of Six degrees of separation can be mapped with the social graph. The intent graph deals with reasoning and motivation. The consumption graph or "payment graph" is heavily used in the retail industry. E-commerce giants such as Amazon, eBay and Walmart can track the consumption of individual customers with the consumption graph. The interest graph maps one's interests. It is often complimented with the social graph. It has potential to follow the previous revolution of web organization; by mapping the web by interest rather than indexing webpages. The mobile graph if built from mobile data. Mobile data in the future may include GPS, web, application, digital wallet data from Internet of Things(IoT) devices.

Performance

Execution of queries within a graph database is localized to a portion of the graph. It does not search through irrelevant data, making it advantageous for real-time big data analytical queries. Consequently, graph database performance is proportional to the size of the data needed to be traversed, staying relatively constant despite the growth of data stored.

Properties

Graph databases are a powerful tool for graph-like queries. For example, computing the shortest path between two nodes in the graph. Other graph-like queries can be performed over a graph database in a natural way (for example graph's diameter computations or community detection).

Graphs are flexible, meaning it allows the user to insert new data into the existing graph without loss of application functionality. There is no need for the designer of the database to plan out extensive details of the databases's future use-cases.

Underlying Storage

The underlying storage mechanism of graph databases can vary. Some depend on a relational engine and “store” the graph data in a table (although a table is a logical element, therefore this approach imposes another level of abstraction between the graph database, the graph database management system and the physical devices where the data is actually stored). Others use a key-value store or document-oriented database for storage, making them inherently NoSQL structures. One such NoSQL database that utilizes this method is ArangoDB[14]. ArangoDB is a native multi-model database that supports graphs as one of its data models. It stores graphs by holding edges and nodes in separate collections of documents. A node would be represented as any other document store, but edges that link two different nodes hold special attributes inside its document; a _from and _to attributes.

Processing Engine

Index-free Adjacency

Data lookup performance is dependent on the access speed from one particular node to another. Because index-free adjacency enforces the nodes to have direct physical RAM addresses and physically point to other adjacent nodes, it results in a fast retrieval. A native graph system with index-free adjacency does not have to move through any other type of data structures to find links between the nodes. Directly-related nodes in a graph are stored in the cache once one of the nodes are retrieved, making the data look-up even faster than the first time a user fetches a node. However, such advantage comes at a cost. index-free adjacency sacrifices the efficiency of queries that do not use graph traversals. Native graph databases use index-free adjacency to process CRUD operations on the stored data.

In Comparison: Relational Databases

Since Edgar F. Codd's 1980 paper on the relational model[15], relational databases have been the de-facto industry standard for large-scale data storage systems. However, relational model's requirement of a strict schema and data normalization imposed limitations on how relationships can be queried[16]. The increasing amount of data needing to be processed became an additional problem posed by the relational model.

Traditionally, databases have been designed with the relational model. In a relational model, data is normalized to support ACID transactions. The data normalization process removes any duplicate data within the database. The goal of data normalization is to preserve data consistency. The relational model enforces ACID transactions, separating data into many tables.

Relational models enforce heavy data normalization in order to guarantee consistency. One of the relational model's design motivation was to achieve a fast row-by-row access[15]. Problems arise with when there is a need to form complex relationships between the stored data. Although relationships can be analyzed with the relational model, complex queries performing many join operations on many different attributes over several tables are required. In working with relational models, foreign key constraints and should also be considered when retrieving relationships, causing additional overhead.

Compared with relational databases, graph databases are often faster for associative data sets[citation needed] and map more directly to the structure of object-oriented applications. They can scale more naturally[citation needed] to large data sets as they do not typically need costly join operations (here costly means when executed on databases with non-optimal designs at the logical and physical levels). 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 the relational databases, it is recommended the graph model itself should not be the sole reason to replace an already placed and well-designed relational database. The benefit of utilizing a graph database becomes relevant once there is an evidence for performance improvement by orders of magnitude and lower latency[17].

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 the concept of a database index, which allows data like this to be stored in a smaller subtable, containing only the selected data and a unique key (or primary key) of the record it is part of. 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. Generally, the tables are physically stored so that look-ups on these keys are fast.[18]

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 costly. Depending on the complexity of the query, the number of joins, and the indexing of the various keys, the system may have to search through multiple tables and indexes, gather lots of information, and then sort it all to match it together.[18]

In contrast, graph databases directly store the relationships between records. Instead of an email address being found by looking up its user's key in the userpk column, the user record contains a pointer that directly refers to the email address record. That is, having selected a user, the pointer can be followed directly to the email records, there is no need to search the email table to find the matching records. This can eliminate the costly join operations. For example, if one searches for all of the email addresses for users in area code "311", the engine would first perform a conventional search to find the users in "311", but then retrieve the email addresses by following the links found in those records. A relational database would first find all the users in "311", extract a list of the pk's, perform another search for any records in the email table with those pk's, and link the matching records together. For these types of common operations, a graph database (in theory at least) is significantly faster.[18]

The true value of the graph approach becomes evident when one performs searches that are more than one level deep. For example, consider a search for users who have "subscribers" (a table linking users to other users) in the "311" area code. In this case a relational database has to first search for all the users with an area code in "311", then search the subscribers table for any of those users, and then finally search the users table to retrieve the matching users. In contrast, a graph database would search for all the users in "311", then follow the back-links through the subscriber relationship to find the subscriber users. This avoids several searches, look-ups, and the memory usage involved in holding all of the temporary data from multiple records needed to construct the output. Technically, this sort of look-up is completed in O(log(n)) + O(1) time, that is, time proportional to the logarithm of the size of the data. In contrast, the relational version would be multiple O(log(n)) look-ups, plus the time needed to join all of the data records.[18]

The relative advantage of graph retrieval grows with the complexity of a query. For example, one might want to know "that movie about submarines with the actor who was in that movie with that other actor that played the lead in Gone With the Wind". This first requires the system to find the actors in Gone With the Wind, find all the movies they were in, find all the actors in all of those movies who were not the lead in Gone With the Wind, and then find all of the movies they were in, finally filtering that list to those with descriptions containing "submarine". In a relational database this will require several separate searches through the movies and actors tables, doing another search on submarine movies, finding all the actors in those movies, and then comparing the (large) collected results. In contrast, the graph database would simply walk from Gone With the Wind to Clark Gable, gather the links to the movies he has been in, gather the links out of those movies to other actors, and then follow the links out of those actors back to the list of movies. The resulting list of movies can then be searched for "submarine". All of this can be done via one search.[19]

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.[19]

Relational databases are very well suited to flat data layouts, where relationships between data is one or two levels deep. For example, an accounting database might need to look up all the line items for all the invoices for a given customer, a three-join query. Graph databases are aimed at datasets that contain many more links. They are especially well suited to social networking systems, where the "friends" relationship is essentially unbounded. These properties make graph databases naturally suited to types of searches that are increasingly common in online systems, and in big data environments. For this reason, graph databases are becoming very popular for large online systems like Facebook, Google, Twitter, and similar systems with deep links between records.

To further illustrate, imagine a relational model with two different tables people and friend. The people table contains two columns: person_id and person_name. Similarly, the friend tables two columns as well: person_id and friend_id, where person_id is a foreign key from the people table. In this case, searching for all of Jack's friends would result in the following SQL query.

SELECT p2.person_name 
FROM people p1 
JOIN friend ON (p1.person_id == friend.person_id)
JOIN people p2 on (p2.person_id == friend.friend_id)
WHERE p1.person_name = 'Jack';

Same query is translated into Cypher, a graph database query language used in Neo4j.

MATCH (ee:person)-[:FRIEND-WITH]-(friend)
WHERE ee.name = "Jack"
RETURN ee, friend

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. [20].

History

In the pre-history of graph databases, in the mid-1960s Navigational databases such as IBM's IMS supported tree-like structures in its hierarchical model, but the strict tree structure could be circumvented with virtual records.[21][22]

Graph structures could be represented in network model databases from the late 1960s. CODASYL, which had defined COBOL in 1959, defined the Network Database Language in 1969.

Labeled graphs could be represented in graph databases from the mid-1980s, such as the Logical Data Model.[3][23]

Several improvements to graph databases appeared in the early 1990s, accelerating in the late 1990s with endeavors to index web pages.

In the mid-late 2000s, commercial atomicity, consistency, isolation, durability (ACID) graph databases such as Neo4j and Oracle Spatial and Graph became available.

In the 2010s, commercial ACID graph databases that could be scaled horizontally became available. Further, SAP HANA brought in-memory and columnar technologies to graph databases.[24] Also in the 2010s, multi-model databases that supported graph models (and other models such as relational database or document-oriented database) became available, such as OrientDB, ArangoDB, and MarkLogic (starting with its 7.0 version). During this time, graph databases of various types have become especially popular with social network analysis with the advent of social media companies.

List of graph databases

The following is a list of notable graph databases:

Name Version License Language Description
AllegroGraph 5.1 (May 2015) Proprietary, clients: Eclipse Public License v1 C#, C, Common Lisp, Java, Python Resource Description Framework (RDF) and graph database
Amazon Neptune 1.0.1.0.200237.0 (September 2018)[25] Proprietary Not disclosed Amazon Neptune is a fully managed graph database by Amazon.com. It is used as a web service and is part of Amazon Web Services. Supports popular graph models property graph and W3C's RDF, and their respective query languages Apache TinkerPop Gremlin and SPARQL.
AnzoGraph 4.0 (February 2018) Proprietary C, C++ AnzoGraph is a massively parallel native graph GOLAP (Graph Online Analytics Processing) style database built to support complex SPARQL join queries and analyze trillions of relationships. AnzoGraph is designed for interactive analysis of broad swaths of RDF data, accumulated over weeks or years of transactions, possibly from many disparate GOLTP and other database sources.[26][27][28][29]
ArangoDB 3.3.11 / (June 28, 2018) Free Apache 2, Proprietary, C++, JavaScript, .NET, Java, Python, Node.js, PHP, Scala, Go, Ruby, Elixir NoSQL native multi-model database system developed by triAGENS GmbH. The database system supports three important data models (key/value, documents, graphs) with one database core and a unified query language AQL (ArangoDB Query Language)
DataStax Enterprise Graph v6.0.1 (June 2018) Proprietary Java Distributed, real-time, scalable database; supports Tinkerpop and integrates with Cassandra[30]
InfiniteGraph 3.0 (January 2013) Proprietary, commercial Java Distributed and cloud-enabled
JanusGraph 0.3.1 (October 2, 2018)[31] Apache 2 Java Open source, scalable, distributed across a multi-machine cluster graph database under The Linux Foundation; supports various storage backends (Apache Cassandra, Apache HBase, Google Cloud Bigtable, Oracle BerkeleyDB)[32]; supports global graph data analytics, reporting, and ETL through integration with big data platforms (Apache Spark, Apache Giraph, Apache Hadoop); supports geo, numeric range, and full-text search via external index storages (ElasticSearch, Apache Solr, Apache Lucene).[33]
MarkLogic 8.0.4 (2015) Proprietary, freeware developer version Java Multi-model NoSQL database that stores documents (JSON and XML) and semantic graph data (RDF triples); also has a built-in search engine and enterprise features such as ACID transactions.
Microsoft SQL Server 2017 RC1 Proprietary SQL/T-SQL, R, Python Offers graph database abilities to model many-to-many relationships. The graph relationships are integrated into Transact-SQL and use SQL Server as the foundational database management system.[34]
Neo4j 3.3.5 (April 2018)[35] GPLv3 Community Edition, commercial & AGPLv3 options for enterprise and advanced editions Java, .NET, JavaScript, Python, Ruby Open source, supports ACID, has high-availability clustering for enterprise deployments, and comes with a web-based administration tool that includes full transaction support and visual node-link graph explorer; accessible from most programming languages using its built-in REST web API interface, and a proprietary Bolt protocol with official drivers; most popular graph database in use as of January 2017[36]
OpenLink Virtuoso 8.1 (May 2018) Open Source Edition is GPLv2, Enterprise Edition is proprietary C, C++ Secure and High-Performance Multi-model (Hybrid) relational database management system (RDBMS) that supports both SQL and SPARQL for declarative (Data Definition and Data Manipulation) operations on data modeled as SQL Tables and/or RDF Graphs. Also supports indexing of RDF-Turtle, RDF-N-Triples, RDF-XML, JSON-LD, and mapping and generation of relations (SQL Tables or RDF Graphs) from numerous document types including CSV, XML, and JSON. May be deployed as a local or embedded instance (as used in the NEPOMUK Semantic Desktop), a one-instance network server, or a shared-nothing elastic-cluster multiple-instance networked server[37]
Oracle Spatial and Graph; part of Oracle Database 12.1.0.2 (2014) Proprietary Java, PL/SQL 1) RDF Semantic Graph: comprehensive W3C RDF graph management in Oracle Database with native reasoning and triple-level label security. 2) Network Data Model property graph: for physical/logical networks with persistent storage and a Java API for in-memory graph analytics
OrientDB 2.2.24 (July 2017) Community Edition is Apache 2, Enterprise Edition is commercial Java Second generation distributed graph database with the flexibility of documents in one product (i.e., it is both a graph database and a document NoSQL database at the same time); licensed under open source Apache 2 license; and has full ACID support; it has a multi-master replication and sharding; supports schema-less, -full, and -mixed modes; has a security profiling system based on user and roles; supports a query language similar to SQL. It has HTTP REST + JSON API.
SAP HANA SPS12 Revision 120 Proprietary C, C++, Java, JavaScript & SQL-like language In-memory ACID transaction supported property graph[38]
Sparksee 5.2.0 (2015) Proprietary, commercial, freeware for evaluation, research, development C++ High-performance scalable database management system from Sparsity Technologies; main trait is its query performance for retrieving & exploring large networks; has bindings for Java, C++, C#, Python, and Objective-C; version 5 is the first graph mobile database
Sqrrl Enterprise 2.0 (February 2015) Proprietary Java Distributed, real-time graph database featuring cell-level security and mass-scalability[39]
Teradata Aster 7 (2016) Proprietary Java, SQL, Python, C++, R MPP database incorporating patented engines supporting native SQL, MapReduce and Graph data storage and manipulation; provides a set of analytic function libraries and data visualization abilities[40]

APIs and graph query-programming languages

  • AQL (ArangoDB Query Language) – an SQL-like query language used in ArangoDB for both documents and graphs
  • Cypher Query Language (Cypher) – a graph query declarative language for Neo4j that enables ad hoc and programmatic (SQL-like) access to the graph.[41]
  • GraphQL – Facebook query language for any backend service
  • Gremlin – a graph programming language that works over various graph database systems; part of Apache TinkerPop open-source project[42]
  • SPARQL – a query language for RDF databases, can retrieve and manipulate data stored in Resource Description Framework format

See also

References

  1. ^ Nikolaos G. Bourbakis (1998). Artificial Intelligence and Automation. World Scientific. p. 381. ISBN 9789810226374. Retrieved 2018-04-20.
  2. ^ Yoon, Byoung-Ha; Kim, Seon-Kyu; Kim, Seon-Young (2017-3). "Use of Graph Database for the Integration of Heterogeneous Biological Data". Genomics & Informatics. 15 (1): 19–27. doi:10.5808/GI.2017.15.1.19. ISSN 1598-866X. PMC 5389944. PMID 28416946. Check date values in: |date= (help)
  3. ^ a b Angles, Renzo; Gutierrez, Claudio (1 Feb 2008). "Survey of graph database models" (PDF). ACM Computing Surveys. 40 (1): 1–39. CiteSeerX 10.1.1.110.1072. doi:10.1145/1322432.1322433. Retrieved 28 May 2016. network models [...] lack a good abstraction level: it is difficult to separate the db-model from the actual implementation
  4. ^ Silberschatz, Avi (28 January 2010). Database System Concepts, Sixth Edition (PDF). McGraw-Hill. p. D-29. ISBN 978-0-07-352332-3.
  5. ^ "Graph Databases Burst into the Mainstream". www.kdnuggets.com. Retrieved 2018-10-23.
  6. ^ Frisendal, Thomas (2017-09-22). "Property Graphs". graphdatamodeling.com. Retrieved 2018-10-23.
  7. ^ Das, S; Srinivasan, J; Perry, Matthew; Chong, Eugene; Banerjee, Jay (2014-03-24). "A Tale of Two Graphs: Property Graphs as RDF in Oracle".
  8. ^ Have, Christian Theil; Jensen, Lars Juhl (2013-10-17). "Are graph databases ready for bioinformatics?". Bioinformatics. 29 (24): 3107–3108. doi:10.1093/bioinformatics/btt549. ISSN 1460-2059. PMC 3842757. PMID 24135261.
  9. ^ "Graph Databases, 2nd Edition". O’Reilly | Safari. Retrieved 2018-10-23.
  10. ^ "DB-Engines Ranking". DB-Engines. Retrieved 2018-10-23.
  11. ^ "Resource Description Framework (RDF): Concepts and Abstract Syntax". www.w3.org. Retrieved 2018-10-24.
  12. ^ "Open Graph protocol". ogp.me. Retrieved 2018-10-23.
  13. ^ "The Competitive Dynamics of the Consumer Web: Five Graphs Deliver a Sustainable Advantage". www.gartner.com. Retrieved 2018-10-23.
  14. ^ "NoSQL databases, ArangoDB is a native multi-model database". ArangoDB. Retrieved 2018-10-23.
  15. ^ a b Codd, E. F. (1970-06-01). "A relational model of data for large shared data banks". Communications of the ACM. 13 (6): 377–387. doi:10.1145/362384.362685. ISSN 0001-0782.
  16. ^ Jaiswal, Garima (2013-08). "Comparative analysis of Relational and Graph databases". IOSR Journal of Engineering. 03 (8): 25–27. doi:10.9790/3021-03822527. ISSN 2278-8719. Check date values in: |date= (help)
  17. ^ "Graph Databases, 2nd Edition". O’Reilly | Safari. Retrieved 2018-10-23.
  18. ^ a b c d "From Relational to Graph Databases". Neo4j.
  19. ^ a b "Examples where Graph databases shine: Neo4j edition", ZeroTurnaround
  20. ^ Have, Christian Theil; Jensen, Lars Juhl (2013-10-17). "Are graph databases ready for bioinformatics?". Bioinformatics. 29 (24): 3107–3108. doi:10.1093/bioinformatics/btt549. ISSN 1460-2059. PMC 3842757. PMID 24135261.
  21. ^ Silberschatz, Avi (28 January 2010). Database System Concepts, Sixth Edition (PDF). McGraw-Hill. p. E-20. ISBN 978-0-07-352332-3.
  22. ^ Parker, Lorraine. "IMS Notes". vcu.edu. Retrieved 31 May 2016.
  23. ^ Kuper, Gabriel M (1985). The Logical Data Model: A New Approach to Database Logic (PDF) (Ph.D.). Docket STAN-CS-85-1069. Retrieved 31 May 2016.
  24. ^ "SAP Announces New Capabilities in the Cloud with HANA". 2014-10-22. Retrieved 2016-07-07.
  25. ^ "Amazon Neptune Engine Updates 2018-09-06". AWS. Retrieved Sep 22, 2018.
  26. ^ "In-Memory Massively Parallel Distributed Graph Database Purpose-built for Analytics". www.Cambridgesemantics.com. Retrieved 2018-02-20.
  27. ^ Rueter, John (February 15, 2018). "Cambridge Semantics Announces AnzoGraph Graph-Based Analytics Support for Amazon Neptune and Graph Databases". Businesswire. Retrieved February 20, 2018.
  28. ^ Zane, Barry (November 2, 2016). "Semantic Graph Databases: A worthy successor to relational databases". www.dbta.com. Retrieved February 20, 2018.
  29. ^ "Cambridge Semantics Announces AnzoGraph Support for Amazon Neptune and Graph Databases". Database Trends and Applications. 2018-02-15. Retrieved 2018-03-08.
  30. ^ Woodie, Alex (June 21, 2016). "Beyond Titan: The Evolution of DataStax's New Graph Database". Datanami. Retrieved May 9, 2017.
  31. ^ "JanusGraph version 0.3.1". 2018-11-14 – via Github.
  32. ^ "JanusGraph storage backends".
  33. ^ "JanusGraph index storages".
  34. ^ "What's New in SQL Server 2017". Microsoft Docs. April 19, 2017. Retrieved May 9, 2017.
  35. ^ "Release Notes: Neo4j 3.1.1". Neo4j. Retrieved May 9, 2017.
  36. ^ "Ranking of Graph DBMS". DB-Engines. Retrieved May 9, 2017.
  37. ^ "Clustering Deployment Architecture Diagrams for Virtuoso". Virtuoso Open-Source Wiki. OpenLink Software. Retrieved May 9, 2017.
  38. ^ Rudolf, Michael; Paradies, Marcus; Bornhövd, Christof; Lehner, Wolfgang. The Graph Story of the SAP HANA Database (PDF). Lecture Notes in Informatics.
  39. ^ Vanian, Jonathan (18 February 2015). "NSA-linked Sqrrl eyes cyber security and lands $7M in funding". Gigaom. Retrieved May 9, 2017.
  40. ^ Woodie, Alex (October 23, 2015). "The Art of Analytics, Or What the Green-Haired People Can Teach Us". Datanami. Retrieved May 9, 2017.
  41. ^ Svensson, Johan (5 July 2016). "Guest View: Relational vs. graph databases: Which to use and when?". sdtimes.com. BZ Media. Retrieved 30 August 2016.
  42. ^ TinkerPop, Apache. "Apache TinkerPop". tinkerpop.apache.org. Retrieved 2016-11-02.