Hype around graph databases... why?

Question

There is some hype around graph databases. I'm wondering why.

What are the possible problems that one can be confronted with in today's web environment that can be solved using graph databases? And are graph databases suitable for classical applications, i.e. can one be used as a drop-in replacement for a Relational Database? So in fact it's two questions in one.

Related: Has anyone used Graph-based Databases (http://neo4j.org/)?

Tagliatelle

You will find some answers in these two stackoverflow threads: - What are some examples of problems that are best solved with graphs? - Have anyone used Graph based Databases : http://neo4j.org/ Regarding classical apps, this Neo4j wiki page could be of interest: Domain Modeling Gallery (I wrote it). – Contribution

Answer 1

Many relational representations of graphs aren't particularly efficient for all operations you might want to perform.

For example, if one wants the connected set of all nodes where edges satisfy a given predicate, starting from a given node, there's no natural way in SQL to express that. Likely you'll either do a query for edges with the predicate, and then have to exclude disconnected edges locally, or have a very verbose conversation with the database server following one set of links to the next in iterated queries.

Graphs aren't a general replacement for relational databases. RDBs deal primarily in sets (tables), while graphs are primarily interesting because of the "shape" of interconnections. With relational DBs you follow links of a predetermined depth (a fixed number of joins) between sets, with results progressively filtered and grouped, while graphs are usually navigated to arbitrary and recursively-defined depth (i.e. not a predetermined number of "joins"). You can abuse either to match the characteristics of the other, but they'll have different strengths.

Tonometer

Transitive closure may not be part of the SQL standard (and is presumably hard to implement in the general case, or more vendors would have done it) but it is not hard to implement for a specific application using stored procedures. – Zildjian

For sure; but having to write ad-hoc queries as stored procedures can put a crimp in your style. – Tonometer

@Zildjian The problem isn't being able to do it, the problems are efficiency and performance. To gain good read performance you'd have to sacrifice insert performance and waste lots of disk space. This article: codeproject.com/KB/database/Modeling_DAGs_on_SQL_DBs.aspx outlines how this can be done using stored procedures for inserts and common SQL for reads. – Contribution

And I believe also how elegant/ natural one can solve problems. That's why people prefer different programming languages, and that's why people might prefer different data stores. – Lagting

You can do transitive closure in standard SQL - you can use recursive common table expressions. I've used them on PostgreSQL and MS SQL Server, and i believe they are supported by other leading RDBMSs. The syntax is slightly clunky, but they're really good fun once you get the hang of them. I suspect they aren't as fast as the equivalent queries in a graph database, though. – Assonance

@TomAnderson quite right, and I have used them in Postgres. But they are essentially query iteration server-side. Without specific indexes, they won't be as fast as something purpose-built. – Tonometer

Answer 2

In my opinion, social networking sites may benefit from graph databases because graph is a natural way of storing connections between users.

Khz