Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Getting Started with Graph Databases

academy.datastax.com

Post reply on HN
Print view View original

21–30 of 35 posts

Re: Getting Started with Graph Databases

#21

Post by dperfect »

Maybe I still just don't "get it", but this explanation didn't really show me how a graph database is any better than an RDBMS, apart from a somewhat simpler interface (which in my opinion is still no better than many ORMs).

For good performance, it sounds like you still need to make good decisions about what to index, as well as putting hard limits on your data - even if not strictly enforced by the data model. And if those kinds of things affect performance, then surely changes to the schema (or whatever you'd call it here) will result in a need for migration/reoptimization. The trouble is, when that needs to happen, I personally would rather have tight control over when and how it happens (with a migration), rather that rely on a black box that supposedly makes everything simple. I'm assuming graph databases have ways to control that process, but that kind of proves my point - you don't get greater performance, simplicity, and flexibility for free, especially when you compare it to something as mature as the current RDBMS's. So what problem is it really solving?

Also, the comparison is a little unfair to RDBMS's - this makes it sound like you'd need separate join tables for every kind of person-media relationship, when you could certainly just use one join table with a column for various relationship types. And the complexity of TV shows with seasons and episodes? I'm pretty sure those distinctions would still need to be modeled in a thoughtful way with a graph database, but I could be wrong.

Re: Getting Started with Graph Databases

#22

Post by Finster »

marknadal wrote: post #12

This article overly inflates the complexity of graphs and databases in order to sound fancy. I've written a response that is very direct and shows how simple a graph database can be: https://github.com/amark/gun/wiki/Graph-Databases-101 .

Personally, I don't need to be shown how simple a graph database can be. I need to know how it will interact with real world data.

Re: Getting Started with Graph Databases

#23

Post by snacksthecat »

rustyrazorblade wrote: post #20
marknadal wrote: post #12

This article overly inflates the complexity of graphs and databases in order to sound fancy. I've written a response that is very direct and shows how simple a graph database can be: https://github.com/amark/gun/wiki/Graph-Databases-101 .

Hi. Presenter here. Honestly the goal wasn't to sound fancy. If you're going to work in the GraphDB world, you're going to come across this terminology. If your concern around my intro is the complexity described of the relational world, well, that's kind of the point. Anyone with at least a few years experience in the RDBMS world has probably come across a project that's spiraled completely out of control with a out…

I didn't think it was overly fancy or confusing at all. I'm not even a particularly techie person and I found the presentation and material to be very palatable. I came away from the video wanting to learn some more about graph databases which I'd say was probably your goal. Very nice job with this!

Re: Getting Started with Graph Databases

#24

Post by jonpaine »

dperfect wrote: post #21

Maybe I still just don't "get it", but this explanation didn't really show me how a graph database is any better than an RDBMS, apart from a somewhat simpler interface (which in my opinion is still no better than many ORMs). For good performance, it sounds like you still need to make good decisions about what to index, as well as putting hard limits on your data - even if not strictly enforced by the data model. And…

Index-free-adjacency.

There are myriad pros/cons between graph/relational/nosql, but to me, a "real" graph db will have index free adjacency, allowing it to do deep traversals (friend of a friend-of a friend-oaf-oaf....) in constant time. It finds it's value in traversal of deeply connected datasets.

Any article or comparison that doesn't at least try to explain index free adjacency isn't going to make a compelling case for a graphdb, let along a native graph db. One reason for that may be that many "graph" databases don't have index free adjacency, so have worst than expected deep traversal characteristics.

Re: Getting Started with Graph Databases

#25

Post by losvedir »

marknadal wrote: post #12

This article overly inflates the complexity of graphs and databases in order to sound fancy. I've written a response that is very direct and shows how simple a graph database can be: https://github.com/amark/gun/wiki/Graph-Databases-101 .

Hmm, maybe I'm missing something, but how do you deal with "edges" in your example? That was the cool part of the original article for me: the concept of specifying relationships between objects via edges between the vertices.

Re: Getting Started with Graph Databases

#26

Post by dang »

jmiserez wrote: post #4

FYI: There are two "Graph Databases 101" posts on the front page now. This one and the older one here: https://news.ycombinator.com/item?id=11257280 (4 hours ago, 15 comments)

We've changed the title of this one back from "Graph databases 101".

Submitters: the HN guidelines ask you to "please use the original title unless it is misleading or linkbait". Note how that does not read "please change the title to make it more misleading and linkbait".

Re: Getting Started with Graph Databases

#27

Post by dperfect »

jonpaine wrote: post #24
dperfect wrote: post #21

Maybe I still just don't "get it", but this explanation didn't really show me how a graph database is any better than an RDBMS, apart from a somewhat simpler interface (which in my opinion is still no better than many ORMs). For good performance, it sounds like you still need to make good decisions about what to index, as well as putting hard limits on your data - even if not strictly enforced by the data model. And…

Index-free-adjacency. There are myriad pros/cons between graph/relational/nosql, but to me, a "real" graph db will have index free adjacency, allowing it to do deep traversals (friend of a friend-of a friend-oaf-oaf....) in constant time. It finds it's value in traversal of deeply connected datasets. Any article or comparison that doesn't at least try to explain index free adjacency isn't going to make a compelling c…

That makes sense. I'm seeing index-free adjacency mentioned in some other comparisons. Sounds pretty cool.

So if each node has pointers directly to related nodes (without needing an index lookup), does that also mean that inserts and updates are slower? From what I understand, if you're bypassing the need for an index lookup at query time, you have to pay for that at some other point in time - specifically by looking up the appropriate pointers at the time of insert/update. Is that accurate?

Re: Getting Started with Graph Databases

#28

Post by ifcologne »

jonpaine wrote: post #24
dperfect wrote: post #21

Maybe I still just don't "get it", but this explanation didn't really show me how a graph database is any better than an RDBMS, apart from a somewhat simpler interface (which in my opinion is still no better than many ORMs). For good performance, it sounds like you still need to make good decisions about what to index, as well as putting hard limits on your data - even if not strictly enforced by the data model. And…

Index-free-adjacency. There are myriad pros/cons between graph/relational/nosql, but to me, a "real" graph db will have index free adjacency, allowing it to do deep traversals (friend of a friend-of a friend-oaf-oaf....) in constant time. It finds it's value in traversal of deeply connected datasets. Any article or comparison that doesn't at least try to explain index free adjacency isn't going to make a compelling c…

Using a novel index, which combines hashes with linked-list, it is possible to gain the same complexity O(n) when traversing the whole graph.

Index-free adjacency is an implementation detail - with drawbacks:

If you store the vertices at each node as list of direct pointers, then traversing all neighbors has complexity O(k), if a vertex has k edges. Note that this is the best possible complexity because O(k) is the size of the answer. Deleting a single edge also has the same complexity of O(k) (assuming a doubly linked list), which is much worse.

Furthermore, usually one will want to be able to traverse edges in both directions, which makes it necessary to store direct pointers on both vertices that are incident with an edge. A consequence of this is that deleting a supernode is even worse: To remove all incident edges one has to visit every adjacent vertex – and perform a potentially expensive removal operation for each of them.

In general, a graph database is “a database that uses graph structures for semantic queries with nodes, edges and properties to represent and store data” (Wikipedia) – independent of the way the data is stored internally.

Re: Getting Started with Graph Databases

#29

Post by okram »

jonpaine wrote: post #24
dperfect wrote: post #21

Maybe I still just don't "get it", but this explanation didn't really show me how a graph database is any better than an RDBMS, apart from a somewhat simpler interface (which in my opinion is still no better than many ORMs). For good performance, it sounds like you still need to make good decisions about what to index, as well as putting hard limits on your data - even if not strictly enforced by the data model. And…

Index-free-adjacency. There are myriad pros/cons between graph/relational/nosql, but to me, a "real" graph db will have index free adjacency, allowing it to do deep traversals (friend of a friend-of a friend-oaf-oaf....) in constant time. It finds it's value in traversal of deeply connected datasets. Any article or comparison that doesn't at least try to explain index free adjacency isn't going to make a compelling c…

You have to consider both in-memory and disk representation.

http://thinkaurelius.com/2013/11/01/a-letter-regarding-nativ...

Some graph databases have direct references in-memory and thats great, but a poor organization on-disk and thats bad.

Re: Getting Started with Graph Databases

#30

Post by okram »

ifcologne wrote: post #28
jonpaine wrote: post #24

Earlier quoted context omitted.

Index-free-adjacency. There are myriad pros/cons between graph/relational/nosql, but to me, a "real" graph db will have index free adjacency, allowing it to do deep traversals (friend of a friend-of a friend-oaf-oaf....) in constant time. It finds it's value in traversal of deeply connected datasets. Any article or comparison that doesn't at least try to explain index free adjacency isn't going to make a compelling c…

Using a novel index, which combines hashes with linked-list, it is possible to gain the same complexity O(n) when traversing the whole graph. Index-free adjacency is an implementation detail - with drawbacks: If you store the vertices at each node as list of direct pointers, then traversing all neighbors has complexity O(k), if a vertex has k edges. Note that this is the best possible complexity because O(k) is the s…

Your last sentence is perfect. Each chosen internal representation has time/space-tradeoffs its making. Users needs to pick a graph database based on the tradeoffs they can live with for their application.
Post reply on HN