For tabular data, relational databases rock. But the relational model doesn't align well with object-orientated programming so you have an ORM layer that adds complexity to your code. And with relational databases, the complexity of your schema grows with the complexity of the data.
The graph-database model simplifies much of this and makes working with the modern-day social graph so much cleaner.
Graphs allow you to do powerful things like find inferences inside the data in ways that would be hard to do with relational databases.
How would you calculate PageRank using a relational database? As I said, with a graph database and Gremlin, you can do it in 2 lines.
And also check out Peter Neubauer's introduction to graph databases and how they compare to RDBMS' and where they stand in the NOSQL-movement (http://www.infoq.com/articles/graph-nosql-neo4j).
> But the relational model doesn't align well with object-orientated programming so you have an ORM layer that adds complexity to your code.
The mismatch comes about for a number of reasons:
* OOP has no formal basis so it can't be reliably transformed into relational terms.
* OOP is identity-bound -- each object is essentially
an address in memory, not a relation in a set.
* The biggie: OOP mixes data with behaviour.
Relational does not.
> How would you calculate PageRank using a relational database? As I said, with a graph database and Gremlin, you can do it in 2 lines.
For something on PageRank's scale, a custom datastore based on matrices and their multiplication makes business sense. Or MapReduce over a distributed key-value store (note that these are both OLAP approaches).
Still. SQL's a bit verbose, but these days we have recursive queries. For Oracle users, I'm talking about CONNECT BY. If I find myself running the social graph every minute, I develop an ETL package that periodically moves data from my write-bound system to my read-bound system with a more query-friendly schema. Depending on how you look on it, relational systems invented "eventual consistency".
More to the point, boring old database greybeards have learnt that OLTP and OLAP are very different use cases. The 3/4/5NF of the OLTP database will be very different from the star schema of the OLAP database.
There's really not much about NoSQL that hasn't already been done, under a different name, by the relational crowd.
I still think there is a place for NoSQL. It's just not as universal a replacement for relational systems as many make it out to be, whether we're talking about document stores, distributed key-value stores, graph stores and so on.
The "NoSQL vs SQL debate" name will eventually change. Instead of isolating SQL from the other datastores, the debate will move toward discussing which database is the right tool for the job, where SQL/relational databases will have a specific role.
Putting relational databases into their own group is silly. I believe this came about because relational databases have dominated for so long, and this has caused developers to try and fit every problem into the relational database model.
In the early days of the Web, choosing a database meant choosing between relational database management systems -- Oracle was king but expensive, Microsoft SQL Server if you were on a Microsoft stack, and PostgreSQL or MySQL were the primary open-source options (with one being a real RDBMS while the other was basically just an SQL interface to the file system).
Ten years ago the RDBMS was the only good option so that's what everyone used even though many problems and programming languages didn't match up well with it -- it was like trying to fit a square peg in a round hole.
You don't have to do that anymore so relational databases can stop being the one-size-fits-all solution, and instead we can move toward using them for the specialized cases where they're the right fit.
The graph-database model simplifies much of this and makes working with the modern-day social graph so much cleaner.
Graphs allow you to do powerful things like find inferences inside the data in ways that would be hard to do with relational databases.
How would you calculate PageRank using a relational database? As I said, with a graph database and Gremlin, you can do it in 2 lines.
To see the types of things you can do with graphs, check out Marko's short screencast on Gremlin (http://www.youtube.com/watch?v=5wpTtEBK4-E).
And also check out Peter Neubauer's introduction to graph databases and how they compare to RDBMS' and where they stand in the NOSQL-movement (http://www.infoq.com/articles/graph-nosql-neo4j).