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

Graph Databases 101

cray.com

Post reply on HN
Print view View original

21–30 of 107 posts

Re: Graph Databases 101

#21

Post by jexp »

valine wrote: post #7
kinow wrote: post #5

Earlier quoted context omitted.

Depends on what kind of data and graph you are going to store/use. Neo4j is quite popular, cypher isn't very hard to learn, and it has lots of examples. Might be a good choice for a beginner. https://en.wikipedia.org/wiki/Graph_database#List_of_graph_d...

> cypher isn't very hard to learn Oh but I love a challenge. Are there reasons to choose cypher besides a gentle learning curve?

Cypher expressses the graph patterns that you're looking for in an ASCII-art-syntax, so you don't loose sight of the core of your question. On top of that you get filtering, projection, aggregation, pagination.

The most fun things are in-query dataflow which allows you to pass information from one query part to the next (projected, aggregated, ordered etc).

And the really cool collection and map functions, so you save a lot of roundtrips between client and server.

See: http://neo4j.com/developer/guide-sql-to-cypher/

Re: Graph Databases 101

#22

Post by whazor »

valine wrote: post #2

Question as someone new to graph databases: Are there any open source graph databases worth looking into?

There are multiple systems out there, however I have my doubts. It is important that your data does not get corrupted, and that your transactions will not get lost. Furthermore, speedups are possible with certain indices. That is why I personally would want to see some more safety/speed analysis and comparisons between the different systems.

Re: Graph Databases 101

#24

Post by phpnode »

marknadal wrote: post #23
valine wrote: post #2

Question as someone new to graph databases: Are there any open source graph databases worth looking into?

(Full disclosure: I'm the author, we are VC backed) https://github.com/amark/gun is an Open Source graph database with Firebase like realtime synchronization.

We've had this discussion before but that product is not a graph database, it has no graph traversal features

Re: Graph Databases 101

#25

Post by marknadal »

phpnode wrote: post #24
marknadal wrote: post #23

Earlier quoted context omitted.

(Full disclosure: I'm the author, we are VC backed) https://github.com/amark/gun is an Open Source graph database with Firebase like realtime synchronization.

We've had this discussion before but that product is not a graph database, it has no graph traversal features

Dijkstra's algorithm is wonderful, but by no means is a requirement for being a graph database. A graph database is that, a database composed of nodes that can interconnect into a graph. GUN supports this and allows for traversing the graph. We haven't implemented Dijkstra's algorithm, which is what your "discussion" refers to.

Re: Graph Databases 101

#26

Post by phpnode »

marknadal wrote: post #25
phpnode wrote: post #24

Earlier quoted context omitted.

We've had this discussion before but that product is not a graph database, it has no graph traversal features

Dijkstra's algorithm is wonderful, but by no means is a requirement for being a graph database. A graph database is that, a database composed of nodes that can interconnect into a graph. GUN supports this and allows for traversing the graph. We haven't implemented Dijkstra's algorithm, which is what your "discussion" refers to.

We've never talked about Dijkstra as far as I recall. Your product doesn't support graphs any more than, say, mongodb does because ultimately all you are doing is loading an object from JSON and then sending it to the consumer. This is in contrast to true graph databases whose main selling point is their ability to efficiently traverse, filter and aggregate large graphs to find the answer to some question, and then send the answer to the consumer.

Gun doesn't meet anyone's definition of "graph database" other than your own. If I load some JSON from a URL, and use lodash to pluck some data out of it, is it a graph database?

Re: Graph Databases 101

#27

Post by marknadal »

phpnode wrote: post #26
marknadal wrote: post #25

Earlier quoted context omitted.

Dijkstra's algorithm is wonderful, but by no means is a requirement for being a graph database. A graph database is that, a database composed of nodes that can interconnect into a graph. GUN supports this and allows for traversing the graph. We haven't implemented Dijkstra's algorithm, which is what your "discussion" refers to.

We've never talked about Dijkstra as far as I recall. Your product doesn't support graphs any more than, say, mongodb does because ultimately all you are doing is loading an object from JSON and then sending it to the consumer. This is in contrast to true graph databases whose main selling point is their ability to efficiently traverse, filter and aggregate large graphs to find the answer to some question, and then s…

Dijkstra was your complaint about shortest path.

GUN can do efficient traversal and filtering, and this is going to be even better in our 0.5.x release with lexical cursor support.

By "anyone" do you mean Wikipedia's? https://en.m.wikipedia.org/wiki/Graph_database , because GUN does match its definition. Although we haven't implemented Dijkstra's.

I'm out in France right now and just boarded a plane to Slovenia, so I won't be able to reply again. Have a good one.

Re: Graph Databases 101

#28

Post by rail2rail »

valine wrote: post #2

Question as someone new to graph databases: Are there any open source graph databases worth looking into?

We're using TitanDB. One of the main benefits for us is that AWS has provided backend integration with DynamoDB. This affords you practically infinite and painless scaling on a pay-as-you-go model. Love it.

https://aws.amazon.com/blogs/aws/new-store-and-process-graph...

Re: Graph Databases 101

#29

Post by thesz »

It introduces false dichotomy "graph vs relational".

In fact, most (if not all) graph algorithms can be expressed using linear algebra (with specific addition and multiplication). And matrix multiplication is a select from two matrices, related with "where i=j" and aggregation over identical result coordinates.

The selection of multiplication and addition operations can account for different "data stored in links and nodes".

So there is no such dichotomy "graph vs relational".

Re: Graph Databases 101

#30

Post by grandalf »

thesz wrote: post #29

It introduces false dichotomy "graph vs relational". In fact, most (if not all) graph algorithms can be expressed using linear algebra (with specific addition and multiplication). And matrix multiplication is a select from two matrices, related with "where i=j" and aggregation over identical result coordinates. The selection of multiplication and addition operations can account for different "data stored in links and…

True but highly irrelevant to why anyone might choose to use a graph database (or choose not to use one in favor of a relational database)...
Post reply on HN