4 ms·

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

by 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).
  - vyrotek 15y ago
    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.
thadeus_venture 15y ago
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).
- espeed 15y ago
  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-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 http://vimeo.com/13213184).
  - thadeus_venture 15y ago
    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.
    - espeed 15y ago

by espeed 15y ago

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

thadeus_venture 15y ago

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

espeed 15y ago
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-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 http://vimeo.com/13213184).
- thadeus_venture 15y ago
  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.
  - espeed 15y ago