8 ms·

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

by birken 15y ago

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.

barighona 15y ago
http://hotcelebritieswomenphoto.blogspot.com/2011/07/sexy-vanessa-minnillo-and-nick-lachey.html http://hotcelebritieswomenphoto.blogspot.com/2011/07/sexy-va...
timf 15y ago
> 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.
- cultureulterior 15y ago
  >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.
  - timf 15y ago
    I did not say what is offered is equivalent and no that is not "what everyone really wants".
ntoshev 15y ago
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.
- noblethrasher 15y ago
  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.
  - ntoshev 15y ago
    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.
espeed 15y ago
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/ 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 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.
- vyrotek 15y ago
  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.
  - espeed 15y ago
    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).
dreamdu5t 15y ago
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.

by birken 15y ago

barighona 15y ago

http://hotcelebritieswomenphoto.blogspot.com/2011/07/sexy-vanessa-minnillo-and-nick-lachey.html http://hotcelebritieswomenphoto.blogspot.com/2011/07/sexy-va...

timf 15y ago

> 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.

cultureulterior 15y ago
>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.
- timf 15y ago
  I did not say what is offered is equivalent and no that is not "what everyone really wants".

ntoshev 15y ago

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.

noblethrasher 15y ago
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.
- ntoshev 15y ago
  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.

espeed 15y ago

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/ 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 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.

vyrotek 15y ago
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.
- espeed 15y ago
  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).

dreamdu5t 15y ago

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.