16 ms·

Dgraph is a next generation graph database with GraphQL as the query language

64 points by velmu 10y ago

mosselman 10y ago
Could someone in the community with experience in graph databases and dgraph in particular shine some light on the quality of dgraph? There appears to be a lot of exposure, but the lack in streamlined installation or examples of production environments (as far as I could see) makes it hard to judge whether it is a good option for integration with new projects. Also "...our Samurai equity multiplier." put me off a bit.
- woodcut 10y ago
  It's an RDF graph mapped to a key-value database, so you describe edges in a tuple {subject-predicate-object} such as "tom-likes-frank" and while the complexity you can model depends on how you define your schema, RDF is good enough for most applications. However it isn't easy to define weighted graphs -afaik- without creating numerous predicates for discrete intervals. I'm pretty positive about this project, it's like google cayley if it hadn't have got bogged down in trying to support numerous database drivers. It'll show its strength if and when it implements raft and reaches a stable production state.
  - mosselman 10y ago
    Thank you for the clarification. How would Dgraph compare to Neo4j for example? I have looked at google cayley's as well (looked through the docs) and I must say I liked the premise. Do you think the support of multiple databases has degraded the database's performance?
    - woodcut 10y ago
      I worked on implementing a backend for google cayley, the issue is the iterators abstract how a backend actually works so it becomes harder to optimise without introducing tighter coupling, also imho effort is better spent on more important things like high availability etc. I haven't touched it in a while so i can't speak re. its performance today. I've never worked with Neo4j but it's a stable and matured product with numerous large scale deployments, enough said. :)
      - bogomipz 10y ago
        Could you elaborate? I was under the impression that Cayley supported MongoDB and LevelDB as backends: http://google-opensource.blogspot.com/2014/06/cayley-graphs-in-go.html http://google-opensource.blogspot.com/2014/06/cayley-graphs-...
        woodcut 10y ago
        yeah cayley supports numerous backends that do have replication such as mongodb and postgres or cockroach db. The issue being that a complex query consists of multiple stages like 'friends of friends of friends'. So if you're using a remote backend iterating over the result of a query then recursively making new queries results in performance that is at best poor.
dang 10y ago
https://news.ycombinator.com/item?id=11322444 https://news.ycombinator.com/item?id=11322444
aymanc 10y ago
i'm not sure if it's only me, But whenever i needed graph-db type queries i found much more success with targeted relational database queries. they take a lot longer to implement but perform feasible results (sometimes u might need to buffer a few things, some pre-calculations here and there). (neo4j vs mysql innodb on multiple layered recommender systems) The thing is that i don't see the point of such a graph db if not for what i just mentioned. any clarification would be great.
diegoperini 10y ago
Is there any graph based dbms solutions that uses its own storage backend, engineered for graph operations exclusively in a way that key value stores or relational cannot compete? If so, are they reliable?

64 points by velmu 10y ago

Could someone in the community with experience in graph databases and dgraph in particular shine some light on the quality of dgraph? There appears to be a lot of exposure, but the lack in streamlined installation or examples of production environments (as far as I could see) makes it hard to judge whether it is a good option for integration with new projects. Also "...our Samurai equity multiplier." put me off a bit.

woodcut 10y ago
It's an RDF graph mapped to a key-value database, so you describe edges in a tuple {subject-predicate-object} such as "tom-likes-frank" and while the complexity you can model depends on how you define your schema, RDF is good enough for most applications. However it isn't easy to define weighted graphs -afaik- without creating numerous predicates for discrete intervals. I'm pretty positive about this project, it's like google cayley if it hadn't have got bogged down in trying to support numerous database drivers. It'll show its strength if and when it implements raft and reaches a stable production state.
- mosselman 10y ago
  Thank you for the clarification. How would Dgraph compare to Neo4j for example? I have looked at google cayley's as well (looked through the docs) and I must say I liked the premise. Do you think the support of multiple databases has degraded the database's performance?
  - woodcut 10y ago
    I worked on implementing a backend for google cayley, the issue is the iterators abstract how a backend actually works so it becomes harder to optimise without introducing tighter coupling, also imho effort is better spent on more important things like high availability etc. I haven't touched it in a while so i can't speak re. its performance today. I've never worked with Neo4j but it's a stable and matured product with numerous large scale deployments, enough said. :)
    - bogomipz 10y ago
      Could you elaborate? I was under the impression that Cayley supported MongoDB and LevelDB as backends: http://google-opensource.blogspot.com/2014/06/cayley-graphs-in-go.html http://google-opensource.blogspot.com/2014/06/cayley-graphs-...
      - woodcut 10y ago
        yeah cayley supports numerous backends that do have replication such as mongodb and postgres or cockroach db. The issue being that a complex query consists of multiple stages like 'friends of friends of friends'. So if you're using a remote backend iterating over the result of a query then recursively making new queries results in performance that is at best poor.

dang 10y ago

https://news.ycombinator.com/item?id=11322444 https://news.ycombinator.com/item?id=11322444

aymanc 10y ago

i'm not sure if it's only me, But whenever i needed graph-db type queries i found much more success with targeted relational database queries. they take a lot longer to implement but perform feasible results (sometimes u might need to buffer a few things, some pre-calculations here and there). (neo4j vs mysql innodb on multiple layered recommender systems) The thing is that i don't see the point of such a graph db if not for what i just mentioned. any clarification would be great.

diegoperini 10y ago

Is there any graph based dbms solutions that uses its own storage backend, engineered for graph operations exclusively in a way that key value stores or relational cannot compete? If so, are they reliable?