Comment by espeed | Hacker News Reader

Comment by espeed | Hacker News Reader

Parent Full thread

NoSQL is a premature optimization for relational data

I don't know about that either. Graph DBs have been around a while and are ideal for relational data (you don't have to mess with tables and joins because everything is explicitly joined), but Web developers are just starting to realize their power.

If I am developing a website that uses the Facebook Graph API (http://developers.facebook.com/docs/reference/api/) or the Twitter API to store my users' friends and followers (and many modern auth systems are doing this), a graph database is ideal because you can use a graph query language like Gremlin (https://github.com/tinkerpop/gremlin/wiki) to do all sorts of cool stuff, like find a user's friends of friends:

  g.v(user_id).outE('friend').inV.outE('friend').inV

This says for the graph database "g":

1. Start at the vertex for the user_id

2. Follow the outgoing edges labeled "friend" to the incoming vertices (these incoming vertices are the user's friends)

3. From the user's friends, follow the outgoing edges to the incoming vertices one more time to get their friends.

This is so much simpler than messing with joins in a relational database, and it's much more performant on large data sets.

Funny thing though, a well designed relational database will execute your graph queries faster. It won't do generic graph queries faster, but if your sql data model and code are optimized for the type of graph data you are storing, sql will almost always be significantly faster, orders of magnitude in some cases. Obviously not a data model argument, but a real world argument nevertheless. If you then need to scale further you will probably end up putting up the same caching layer between your database and the front end, but at least all your data will be in once place (the sql database).

a well designed relational database will execute your graph queries faster

Why do you say that? -- see "MySQL vs. Neo4j on a Large-Scale Graph Traversal" (http://markorodriguez.com/2011/02/18/mysql-vs-neo4j-on-a-lar...).

You can represent a graph in almost any data structure, including a relational database. But the difference between a graph database and everything else is that in a real graph database (like Neo4j), each node has an internal/local index for its adjacent nodes so it doesn't have do an external look up for each traversal step.

Watch this video on "The Graph Traversal Programming Pattern" to see what I'm talking about (http://vimeo.com/13213184).

From the article:

"However, no attempts have been made to optimize the Java VM, the SQL queries, etc"

Emphasis being on optimizing the sql. We have run tests comparing neo4j and postgres, and postgres comes out with greater throughput for our data set, where our database implementation was done people who know postgres extremely well. Where you will see especially great differences is aggregate queries, such as if you want to count the number of a certain type of connections coming into a set of nodes, and then sort these nodes by that number. A sql database is much better at stuff like that.

What were you using to query the graph?

Gremlin has significantly improved what you can do with graph aggregating and sorting:

  // count incoming friends for each node and sort by most friends
  m = [:] 
  g.V.inE('friend').outV.groupCount(m)   
  m.sort{}

This is so much simpler than messing with joins in a relational database

I disagree. I have no idea what you just said and I'm sure I could figure out the join faster than trying to figure it out.

In graph speak, vertices are nodes (or objects) in the graph and edges are the links between nodes -- it's really quite easy once you become familiar with it.

This script will return a list of all the user's friends:

   g.v(user_id).outE('friend').inV

All you're doing is starting with the user node v(user_id) and following the outgoing links that are labeled "friend" to the adjacent nodes (the "incoming vertices").

In a graph, each "edge" (each link) has an outgoing vertex and an incoming vertex. The outgoing vertex is where the edge starts from, and the incoming vertex is what the edge points to:

  outgoing_vertex -- edge("friend") --> incoming_vertex

Here's a more concrete example...

  james -- "friend" --> julie

In this example, "james" is the outgoing vertex, "julie" is the incoming vertex, and they are linked together by an edge labeled "friend".

Again "vertex" means the same thing as node so every user in the graph is a node (a vertex).

Thanks for the explanation.

it's really quite easy once you become familiar with it

This was really my point. Things are always simpler when you're familiar with it and I happen to be very familiar with SQL. I just don't think ease should be a highlighted feature of NoSQL.

Don't get me wrong though. I use a few NoSQL systems in my company. But I didn't pick them because they were easy to understand.

Reply on news.ycombinator.com