Live data from Hacker News

Graph Databases 101

cray.com

41–50 of 107 posts

Re: Graph Databases 101

#41
post #6

Earlier quoted context omitted.

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.

Cayley can be run in two ways: as HTTP service or as a Go library that you import from your Go app. To insert into Cayley when it's running as HTTP service you can do something like: `curl http://localhost:64210/api/v1/write -d '[{ "subject": "Krissy", "predicate": "loves", "object": "Justin Trudeau"}]'`.

To insert in the 'embedded' mode you can do: https://github.com/google/cayley/wiki/Cayley-Go-API-(as-a-Li....

Join #cayley on freenode and https://groups.google.com/forum/#!forum/cayley-users and get help from our community.

Re: Graph Databases 101

#42
post #38

Earlier quoted context omitted.

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!

Virtuoso, does 2 billion in 50GB. Just so you know. And hard graphs like the complete UniProt data of 20 billion+ in 800GB.

Re: Graph Databases 101

#43
post #40
post #35

Earlier quoted context omitted.

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 data…

> a database which can efficiently represent graphs and offers functionality for traversing them

First part is matching the commonly accepted definition (the one that had been around for about 50 years). The second part is your own invention.

> This is not what gun does

I did not even have a chance to take a look at that product yet. So far I'm just puzzled by the graph database definition some people seem to be using in this thread.

Re: Graph Databases 101

#44
post #20
post #6

Earlier quoted context omitted.

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

Is Cayley mature enough for production? I thought it was still relatively new. Would love to know a little more about how you're using it.

There is a similar question on Cayley's google group - https://groups.google.com/forum/#!topic/cayley-users/nirhCbq...

Also, I know it's being used by some companies. you can ask directly the people who uses it on IRC - #cayley (freenode).

Re: Graph Databases 101

#45
post #20
post #6

Earlier quoted context omitted.

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

Is Cayley mature enough for production? I thought it was still relatively new. Would love to know a little more about how you're using it.

It's been stable for us since deployment eight mounts ago, although we haven't pushed it too hard - our data is relatively small and queries not too complex.

From what I've seen, our use has a lot in common with Seed-DB, only in a different economic sector/activity.

Re: Graph Databases 101

#46
post #43
post #40

Earlier quoted context omitted.

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 data…

> a database which can efficiently represent graphs and offers functionality for traversing them First part is matching the commonly accepted definition (the one that had been around for about 50 years). The second part is your own invention. > This is not what gun does I did not even have a chance to take a look at that product yet. So far I'm just puzzled by the graph database definition some people seem to be usin…

perhaps this is a terminology issue, I'll admit that I'm too young to have used pre-relational graph databases, but presumably they have a way of navigating / jumping between documents/vertices, (presumably based on pointers), otherwise what point would there be in having a graph?

I'd encourage you to look at the product and see whether it meets your definition.

Re: Graph Databases 101

#47
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 nowadays is purely a government contracting shop (think healthcare.gov in terms of technology chops).

Re: Graph Databases 101

#48
post #36
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.

I'm not clear how Sun ever owned Cray care to explain?

The provenance was Cray Research -> SGI -> Tera/Cray according to those that have been around since the Cray Research days.

Source: err, I work here and asked a couple people a few cubes over. :)

The Sun deal was apparently more SGI wouldn't be caught dead with a supercomputer that ran on sparc so it got sold off to Sun.

Re: Graph Databases 101

#49
post #15
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...

But if you want to scale to more than two instances you will have to pay a $50k license. $50.000,00 dollars. Which is far too expensive for startups.

Look, I only wrecked a semester of research by chasing the slippery promises of graph databases. Don't wreck your entire startup on them.

Re: Graph Databases 101

#50
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 has been stable for us so far but I can't vault for it's scalability as our database is very small, less than 6M quads, so an 8GB machine is more than enough.
Post reply on HN