Cayley – An open-source graph database
github.com
github.com
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!
Cool to see cayley on HN again :) Pretty excited to use it some time.
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.
Specifically, you could use postgresql for the edge traversing and its jsonb column to store searchable attributes.
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 in itself?
There are two things from that:
1. There is no way for Cayley to take the graph structure of the data into account when laying it out on disk or when executing the query. Is this the long-term decision, or is this just a stop-gap until a storage mechanism can be done?
2. This would seem to imply that the abstraction layer from Cayley to the backend storage would be relatively slim. How difficult is it to add another storage driver for another SQL database or for one with a custom query language?
Another thing I noticed:
> query -- films starring X and Y -- takes ~150ms
Even on two year old hardware that seems dog slow - less than 7 queries a second - for a very simple query.
True though. I'm guessing with a latency number like that, the throughput is pretty bad too.
That semi-declarative query language is hideous though. Reminds me of attempts to make XML into a programming language.
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/
Edit: I still think it looks hideous. Def try to figure it out more tomorrow.
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
1. Use Cayley as a library 2. Put metadata in separate nodes.
- There were a couple of issue loading the data that we fixed and contributed back the patch
- Loading the data was really slow, and it got slower every time a new entry was added (Loading the full freebase dump required 1 week on a very beefy machine with SSD. Used LevelDB)
- Then the queries were relatively slow. Without going too much into details, we were using the data to analyze texts and extract entities, and the relationship between them, and even parallelizing the queries, they were relatively slow (depending on complexity between 0.1 and 1 sec on average). We solved the issue implementing a robust caching layer in front of it and carefully planning the queries.
- In general, it was stable and performant enough for a backend service. But we were pushing really the envelope of what it could do.
All in all, I would say that I was happy with it. In comparison, I tried a year earlier to use Neo4J in a similar role and I give up after 2 weeks because I wasn't even able to get it loading part of the dataset without crashing on a similar hardware.
The Freebase Film Data has only 21M facts. Freebase 1.9 billion facts.
How long does it load? What's the avg query response for very simple searches (like who is the US president)?
Dgraph was 10X faster.
Can someone run the benchmark for the real Freebase (1.9 billion facts)?
Also LevelDB/Bolt is not suitable for this, better use MongoDB or Postgres or MySQL as Cayley data store.
I tried building something with Cayley once but couldn't fetch all the data I wanted in a single query, or didn't know how to, then got frustrated and deleted everything.
The topic of 'reification' found throughout our recent discussion is how we can generally add metadata to links, thereby making it a lot easier to fit the two models together.
They are better suited for Graph Databases because the queries tend to be many joins traversing paths both deep and wide.