Graph Databases and Big Data
Graph stores can be divided in property graphs, triples stores and hybrid (or exotic) systems. Each flavor has its pros and cons, all depends on your business context and what you wish to achieve. One could also separate graph stores in function of basic and enterprise features. In contrast with the relational stores there is indeed a much broader spectrum of ‘quality’. Things like encryption, clustering, high-availability and such do not show up in all systems. The triple world, in particular, can be more academic than enterprise minded. This is also reflected in prices and licensing.
As such, picking the right solution for your project can be a challenge on its own. The diversity and incoherence can be overwhelming. We have gone through this process over the years time and again, if you need guidance we’re here to help.
Property Graphs
Property graphs have the characteristic that the nodes (and edges) carry a payload, usually in the shape of some JSON. Some implementations enforce a schema, sone don’t, some partially. In the context of graph learning one speak of heterogeneous and homogeneous graphs, depending on whether the schema across the graph elements is uniform or not. Property graphs have much in common with other NoSQL systems (like MongoDB) but there is a much broader range of API flavors, graph query languages and enterprise readiness.
Triple Stores and Semantic Databases
Triples stores are very different compared to property graphs; nodes and edges don’t carry data. Rather, everything sits in ‘triples’. Triples are basic arrows and this gives at the same time a lot of flexibility and a very different way of thinking. SPARQL, the semantic query language, is uniformly implemented across all vendors but each adds to it in the shape of custom functions.
The world of triples is more linked to academic research and governmental projects compared to the more business-minded world of property graphs. At the same time, many semantic stores profile themselves as ‘universal’ in the sense that they (try) to embrace the diversity of data sources found in a typical enterprise.
Hybrid and Exotic Systems
In this category one finds relational systems which implemented a graph API on top of the underlying tabular structure. This has good and bad. Microsoft and Oracle at the forefront but also MySQL and PostgreSQL have graph-layers. Typically you will find Gremlin as a query language but some, like Microsoft, managed to integrate the specifics of graph queries inside the SQL language.
These organizations are also known to offer solutions
The graph store landscape evolves rapidly and the diversity, compared to RDBMS, is staggering. There is something for everyone, it all depends on your business aims and budget.
-
Algebraix
-
Amazon
-
Amisa Server
-
BrightstarDB
-
Cayley
-
CubicWeb
-
Dydra
-
FlockDB
-
Giraph
-
GlobalsDB
-
GraphBase
-
Hama
-
HyperGraphDB
-
InfoGrid
-
JanusGraph
-
Lexis Nexis
-
MarkLogic
-
Mulgara
-
Oracle
-
Pregel
-
Redland
-
RedStore
-
SparkSee
-
SparqlDB
-
Sqrrl
-
Strabon
-
Teradata
-
VelocityGraph
-
Virtuoso