Hacker News Reader

Comment by birken | Hacker News Reader

This is a great post, however I think there is one caveat... NoSQL is a premature optimization for relational data. NoSQL isn't necessarily an optimization if your dataset is one that isn't relational, where you gain flexibility and get the scaling for free.

However, the truth is that most business datasets are relational, and because of that relational databases do an excellent job of storing and accessing that data in an efficient way. I completely agree that people who try to force what would be a simple relational database into a complicated NoSQL system to gain scaling in the future are making a huge mistake.

View on HN

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.

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.

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 not a very useful statement, because there is no clear-cut border between relational and non relational data. You can map everything to a relational schema and to most nosql models.

People seem to forget the MS in RDMS.

It's true that anytime you write a function that maps some set to the set of logical values (true, false, null, maybe, ...) you're dealing with relational data. So while there is no clear cut border, at some point it becomes obvious that you would benefit from a Relational Data Management System. The danger is that your particular data set might out grow a particular management system.

When you switch to a "NoSql" solution all you're doing is deciding that you need a more purpose built managment system for your relational data.

It's not just the data, it's also what you do with it. I think a typical social network is a reasonably good fit to the relational model. But this is mostly because any given user cares only about his friends, and at most about the friends-of-friends. If you try to do something different, like computing eigenvector centrality of clusters of people, suddenly an RDBMS is inadequate and you want a graph database or something simpler like mapreduce.

> where you gain flexibility and get the scaling for free.

Is it really for free? While I tend to agree with your point, one of the wrinkles here is that the older SQL systems have been beaten to death in production. We've had all sorts of 'little problems' with some of these newer systems. And this is not just about runtime issues, the 'hardened product' benefits reveal themselves in more secondary things like education, troubleshooting, monitoring, add-on products, and backup.

>older SQL systems have been beaten to death in production

But they haven't. SQL Multi-master replication systems with no single points of failure really aren't that common, and that's what everyone really wants. Everything else imposes huge production costs.

I did not say what is offered is equivalent and no that is not "what everyone really wants".

What dataset isn't relational? Seriously. Even a basic chat software, you think Redis would be great for that. But what about when you want to relate users to messages?

Actually, I've never worked on any project where our data set only needed simple key value mapping and no relationships at all.

Reply on news.ycombinator.com