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

Cayley – An open-source graph database

github.com

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Cayley – An open-source graph database

#41

Post by reactor »

sverhagen wrote: post #26

We have Elasticsearch as a generic document search engine, each document has a non-trivial amount of properties (let's say 50 or so). It's incredibly performant for all sort of searches, the details of each of which this solution wasn't specifically designed for, hence me calling it a generic search engine. Every time I contemplate of bringing graph relationships, that exist between these documents, into the mix, I g…

Worth taking a look at https://arangodb.com or http://janusgraph.org/ (Fork of Titan graph db)

Re: Cayley – An open-source graph database

#42

Post by reactor »

scalatohaskell wrote: post #18
barakm wrote: post #4

Maintainer here, good to see Cayley on HN again :) We've got a lot of new features on master, (GraphQL support, Gephi interfaces, Recursive iterators, etc) and are cutting a release next week. Active work in the coming releases on tightening down the indexing and really bringing it into prod. EDIT: Feel free to join the new Slack or the Discourse mailing list/discussion board!

Whats the difference between Cayley and lets say OrientDb / ArangoDb ?

One of the difference is Cayley/Arangodb doesn't provide an index free adjacency (a moot point as I'm not sure if it is even worth considering as hash index are quite fast and gives O(1)) while OrientDb has IFA.

Re: Cayley – An open-source graph database

#43

Post by mrjn »

jnordwick wrote: post #40
ashwin95r wrote: post #39

Earlier quoted context omitted.

Exactly what https://dgraph.io is built for. Low latency, high throughput.

Looks interesting. That semi-declarative query language is hideous though. Reminds me of attempts to make XML into a programming language.

(author of Dgraph)

It's based on GraphQL, which is definitely not a hack like XML => language and currently catching on faster than a forest fire. Dgraph's derivation, GraphQL+- (for lack of better name) is a lot more powerful than Cypher or Gremlin. Both of the latter allow only returning lists of results; while GraphQL+- returns back an entire subgraph. Thus, all the relationships are maintained. It also allows expressing complex joins using a function like variable blocks; feeding results from one into another like you'd do in any popular language.

You can try running some complex queries with GraphQL+-, it might change your view. http://play.dgraph.io/

Re: Cayley – An open-source graph database

#44

Post by jnordwick »

mrjn wrote: post #43
jnordwick wrote: post #40

Earlier quoted context omitted.

Looks interesting. That semi-declarative query language is hideous though. Reminds me of attempts to make XML into a programming language.

(author of Dgraph) It's based on GraphQL, which is definitely not a hack like XML => language and currently catching on faster than a forest fire. Dgraph's derivation, GraphQL+- (for lack of better name) is a lot more powerful than Cypher or Gremlin. Both of the latter allow only returning lists of results; while GraphQL+- returns back an entire subgraph. Thus, all the relationships are maintained. It also allows exp…

Cool af

Edit: I still think it looks hideous. Def try to figure it out more tomorrow.

Re: Cayley – An open-source graph database

#45

Post by dimfeld »

jnordwick wrote: post #32

What exactly is this? The GitHub page speaks of different backends, and those appear to just be databases or key-value stores in themselves (e.g, Postgres and Bolt). Is Cayley basically a query rewritter, that is it has some tables in the backend and when queried, Cayley then goes to the "real" (for lack of a better word) database? Cayley's query language might be more full featured, but it isn't a storage mechanism…

Cayley's graph data layout is most similar to a Hexastore-style [1] triple store, though IIRC it doesn't do the full six-way index that the original Hexastore paper describes. The Redis page on secondary indexing [2] has a great quick intro to what this actually entails (search the page for Hexastore).

As you might guess from the Redis link, this style of graph lends itself well to KV stores, so the answer to your question #1 might be that it's a long-term decision, but the style of graph is really designed for a KV store anyway. But I haven't discussed this at all with the Cayley devs so I can't actually speak for them.

I'm using it with the BoltDB backend and have been pleased with the performance overall. I haven't looked at the backends for more complex databases like Postgres in detail, but it does appear that the backend interface has potential for predicate pushdown as well. The repository's graph directory [3] contains the various backends if you want to check it out. Overall it doesn't look very difficult to add another backend type, but I haven't tried it yet. Looking at the existing SQL backend, it appears to already support MySQL, PostgreSQL, and CockroachDB (but I've tried none of these with Cayley).

[1] http://www.vldb.org/pvldb/1/1453965.pdf [2] https://redis.io/topics/indexes [3] https://github.com/cayleygraph/cayley/tree/master/graph

Re: Cayley – An open-source graph database

#47

Post by solipsism »

sverhagen wrote: post #26

We have Elasticsearch as a generic document search engine, each document has a non-trivial amount of properties (let's say 50 or so). It's incredibly performant for all sort of searches, the details of each of which this solution wasn't specifically designed for, hence me calling it a generic search engine. Every time I contemplate of bringing graph relationships, that exist between these documents, into the mix, I g…

I guess you've considered doing the graph search and the text search separately and joining the results?

Re: Cayley – An open-source graph database

#48

Post by mrjn »

sverhagen wrote: post #26

We have Elasticsearch as a generic document search engine, each document has a non-trivial amount of properties (let's say 50 or so). It's incredibly performant for all sort of searches, the details of each of which this solution wasn't specifically designed for, hence me calling it a generic search engine. Every time I contemplate of bringing graph relationships, that exist between these documents, into the mix, I g…

(author of Dgraph)

Dgraph's retrieval is pretty fast, so looking up properties is trivial. It also supports indexing various data types: supports full-text search, term matching and regexps on strings, inequality and sorting on ints, floats, dates etc. https://docs.dgraph.io/v0.7.4/query-language/#functions

One of our users is on the path to switch to Dgraph from Elastic Search. So, I'd say try Dgraph out and see if that'd help your use-case. I think it should. And if Dgraph is missing something that you need from ES, feel free to file an issue. Happy to address it.

Re: Cayley – An open-source graph database

#49

Post by sverhagen »

solipsism wrote: post #47
sverhagen wrote: post #26

We have Elasticsearch as a generic document search engine, each document has a non-trivial amount of properties (let's say 50 or so). It's incredibly performant for all sort of searches, the details of each of which this solution wasn't specifically designed for, hence me calling it a generic search engine. Every time I contemplate of bringing graph relationships, that exist between these documents, into the mix, I g…

I guess you've considered doing the graph search and the text search separately and joining the results?

Yes, but I can easily reason myself into scenarios where the intermediate result would be prohibitively large.
Post reply on HN