|
|
|
|
|
by thadeus_venture
5438 days 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). |
|
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).