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

31–40 of 107 posts

Re: Graph Databases 101

#31

Post by arupauqa »

kawera wrote: post #6
valine wrote: post #2

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

Cayley is a good option; we use it in production. https://github.com/google/cayley

What's the story on inserting data into Cayley? I think every single code example I have seen on it only shows traversing graphs with it.

Also, if you don't mind me asking, how does it not being a property graph affect modelling your data and queries? At a glance it seems that queries would get significantly more complex if you wish to take several properties of a vertex into account.

Re: Graph Databases 101

#32

Post by AdamN »

Everybody's focused on graph databases here but let's talk about Cray! One of the most forward-thinking computer technology companies ever to exist is starting to get out there again. If they got a few hundred million dollars from an outside investor, they could do friggin' incredible things. They already do incredible things but not out there in the way it so easily could be.

Re: Graph Databases 101

#33

Post by sklogic »

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…

Of course you can express anything on top of a relational model. But for graphs such a representation would have been awfully inefficient. For this reason, CADs never even tried to switch to a relational data storage once that fancy new relational databases appeared, most of the professional CADs are still using good old graph databases.

Re: Graph Databases 101

#34

Post by sklogic »

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

Mind naming any historical (i.e., from the pre-relational era) graph DBMS that had graph traversal features?

Re: Graph Databases 101

#35

Post by sklogic »

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…

Are you inventing your own new, hipstor definition of a "graph database" here? I used graph databases a lot, and I never heard of any of the requirements you've listed.

Re: Graph Databases 101

#36

Post by fulafel »

AdamN wrote: post #32

Everybody's focused on graph databases here but let's talk about Cray! One of the most forward-thinking computer technology companies ever to exist is starting to get out there again. If they got a few hundred million dollars from an outside investor, they could do friggin' incredible things. They already do incredible things but not out there in the way it so easily could be.

Cray is a brand name that has been passed around between half a dozen companies (including Sun and SGI) dotted by various kinds of product reboots and commercial failures. Cool stuff but supercomputing isn't the most financially sound business it seems. The current name holder is the company previously called Tera, originally famous for making an aggressively multithreaded HPC computer.

Re: Graph Databases 101

#37

Post by kevinschumacher »

kinow wrote: post #19
valine wrote: post #7

Earlier quoted context omitted.

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

Not really, if you learn Cypher you should be fine learning the basics of Gremlin, SPARQL, or other languages to operate on graphs in a few hours. There was some post about enabling SPARQL in Neo4J, but when you install Neo4J it comes with cypher by default (not sure if it supports anything else). I use Apache Jena + SPARQL, but had to use Neo4J to help in a master thesis. Took me a few hours of "How the heck can I d…

You can definitely run gremlin queries against Neo4j by a couple of methods.

One example: https://github.com/thinkaurelius/neo4j-gremlin-plugin

Also can use the Tinkerpop3 or Blueprints APIs to access your graph with Gremlin.

Re: Graph Databases 101

#38

Post by owen11 »

jalfresi wrote: post #17
kawera wrote: post #6

Earlier quoted context omitted.

Cayley is a good option; we use it in production. https://github.com/google/cayley

Might I ask what sort of dataset size, servers etc you are using? I'm looking for an graph database and Cayley seems the best fit, though I'm not sure what sort of limits on the data there would be in the real world.

Cayley can store 130 million quads (2 nodes + connecting edge) on 20 GB harddrive. Join #cayley on freenode and https://groups.google.com/forum/#!forum/cayley-users and be part of our community!

Re: Graph Databases 101

#39

Post by [deleted] »

rail2rail wrote: post #28
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...

[deleted]

Re: Graph Databases 101

#40

Post by phpnode »

sklogic wrote: post #35
phpnode wrote: post #26

Earlier quoted context omitted.

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…

Are you inventing your own new, hipstor definition of a "graph database" here? I used graph databases a lot, and I never heard of any of the requirements you've listed.

Not at all but maybe I'm not being clear. My definition of "graph database" is "a database which can efficiently represent graphs and offers functionality for traversing them, in order to allow queries such as 'find the business relationships between user X and user Y based on who they've worked with' (ala linkedin)"

This is not what gun does. It alternately calls itself "the simplest database out there", "not a database" and "a distributed cache". It provides a mechanism for sharing a list of objects across multiple peers, but must transfer all of the data to each peer. It is conceptually similar to downloading a large chunk of JSON from a server and using lodash, ramda etc to query it, but no one would call that a graph database.

Post reply on HN