4 ms·

You must have missed something because that is the opposite of what it being said here. The graph model is more declarative than the so called relational model

You must have missed something because that is the opposite of what it being said here. The graph model is more declarative than the so called relational model. In the graph, this node here represents Bob, this one Alice, Alice is Bob's manager. (alice)-[:MANAGES]->(bob) The query costs you 1 traversal from one node to another, a minuscule cost regardless of size. O(1) your cost stays the same no matter how many employees you have. In a relational database, you have an employees table with a FK_ID for Manager that is indexed and is a O(log(n)) operation. As your employees table gets bigger your cost increases. Take a look at slides 5-8 from this presentation => http://bit.ly/1iN6Y60 http://bit.ly/1iN6Y60 and the "what we put in cache" image => http://maxdemarzi.com/2012/08/13/neo4j-internals/ http://maxdemarzi.com/2012/08/13/neo4j-internals/ Then it will all make sense.

batbomb 12y ago
It's a O(log(n)) operation, but we aren't talking log base 2(100,000), since it's usually a B+tree, not just a B-tree. In practice, you don't usually end up with a B+tree more than 4 levels deep. So, we are usually talking 3, at most 4 buffer reads for the index, and possibly an extra read to an additional buffer or disk if you need non-indexed data, assuming the amount of managers is fairly smaller than employees. Follow the 5 minute rule (you should have enough memory for anything you might touch every 5 minutes) and in practice you get will probably get similar performance to a graph database. You'd be surprised what you can do with recursive common table expressions in SQLite, Postgres, and Oracle too.
3pt14159 12y ago
Actually your cost is O(n) for the graph in the worst case, and the mysql index is worst case to O(log(n)) (as you implicitly point out), so really what we are talking about here is speed in practice. I've found that in practice graph databases generally need more (in gigabytes / terabytes) fast random access (SSD / RAM), or very intelligent / lucky data storage strategies. Furthermore, adding data to a already large node can sometimes cause problems since the database will take steps to avoid fragmentation. This is also a problem in some kinds of manipulations in a traditional relational database, but generally you farm more information into its own table in though, which makes this problem less likely. Also, I find sharding harder on graph databases of sufficient complexity, although there are cases where it can be easier too. But if we're talking actual performance operations, generally relational databases preform as well or better than graph databases for a traditional SaaS or social network app, which relies more heavily on aggregate querying, something that is easier to make more performant for the types of scales and expected timelines that most of these apps operate on. As for your slides that you linked, joins are considered harmful for certain types of querying at certain scales, but you can usually work around these problems by either "doing the join in code", creating Entity–Attribute–Value models (EAV) for certain cases, or if you really want you can just use the MEMORY storage engine (and get that o(1) average case lookup time). Or at that point you can use multiple datastores if you need to. Anyway, I don't really know what my point is. I've used graph DBs before, and they were alright, but I find the cost of giving up SQL to be pretty high, and I actually enjoy some of the constraints that exist on the DB level for something like MySQL or Postgres. Plus, when you're ready to scale there are a bunch of people that can quickly get you 2x or 3x speed improvements without knowing much about the structure of your data. If you ever want someone to analyze your data to figure out your growth rate, or what have you, it is easier. It is easier for marketing to get weekly Excel exports of the data. Right tool, right job, yadda yadda.

batbomb 12y ago

It's a O(log(n)) operation, but we aren't talking log base 2(100,000), since it's usually a B+tree, not just a B-tree. In practice, you don't usually end up with a B+tree more than 4 levels deep. So, we are usually talking 3, at most 4 buffer reads for the index, and possibly an extra read to an additional buffer or disk if you need non-indexed data, assuming the amount of managers is fairly smaller than employees. Follow the 5 minute rule (you should have enough memory for anything you might touch every 5 minutes) and in practice you get will probably get similar performance to a graph database. You'd be surprised what you can do with recursive common table expressions in SQLite, Postgres, and Oracle too.

3pt14159 12y ago

Actually your cost is O(n) for the graph in the worst case, and the mysql index is worst case to O(log(n)) (as you implicitly point out), so really what we are talking about here is speed in practice. I've found that in practice graph databases generally need more (in gigabytes / terabytes) fast random access (SSD / RAM), or very intelligent / lucky data storage strategies. Furthermore, adding data to a already large node can sometimes cause problems since the database will take steps to avoid fragmentation. This is also a problem in some kinds of manipulations in a traditional relational database, but generally you farm more information into its own table in though, which makes this problem less likely. Also, I find sharding harder on graph databases of sufficient complexity, although there are cases where it can be easier too. But if we're talking actual performance operations, generally relational databases preform as well or better than graph databases for a traditional SaaS or social network app, which relies more heavily on aggregate querying, something that is easier to make more performant for the types of scales and expected timelines that most of these apps operate on. As for your slides that you linked, joins are considered harmful for certain types of querying at certain scales, but you can usually work around these problems by either "doing the join in code", creating Entity–Attribute–Value models (EAV) for certain cases, or if you really want you can just use the MEMORY storage engine (and get that o(1) average case lookup time). Or at that point you can use multiple datastores if you need to. Anyway, I don't really know what my point is. I've used graph DBs before, and they were alright, but I find the cost of giving up SQL to be pretty high, and I actually enjoy some of the constraints that exist on the DB level for something like MySQL or Postgres. Plus, when you're ready to scale there are a bunch of people that can quickly get you 2x or 3x speed improvements without knowing much about the structure of your data. If you ever want someone to analyze your data to figure out your growth rate, or what have you, it is easier. It is easier for marketing to get weekly Excel exports of the data. Right tool, right job, yadda yadda.