DegDB, an open-source distributed graph database
1–10 of 16 posts
Re: DegDB, an open-source distributed graph database
#2Days since new graph database released: 0
;)
Re: DegDB, an open-source distributed graph database
#3never had time to publish proper documentation though.
you should also check out the paper that was published a few years after: http://onlinelibrary.wiley.com/doi/10.1002/spe.2226/abstract
Re: DegDB, an open-source distributed graph database
#4Re: DegDB, an open-source distributed graph database
#5It looks like your code is mostly stubbed out right now -- using gorm for any persistence. You'll find that storing a basic graph is easy; doing more complex traversals and optimization is a harder problem.
I can appreciate your concept of experimenting with adding monetary incentives on top of requests and datasets. Graphs can be a useful for this, if you view a graph as a (requestable) URI of triples.
I'd recommend linking in Cayley as your backend (you can use it as a library), and dealing with the requests/economics as an API layer on top. The benefit of open source is you don't have to reimplement everything yourself.
And if you have novel notions on how to distribute a graph that could be interesting, feel free to ping me. I warn you that it's a hard problem and bold claim in a number of ways -- it's not something you just build without working with a couple people.
Re: DegDB, an open-source distributed graph database
#6In the meantime a more interesting production ready open source distributed graph database is worth looking at: https://www.blazegraph.com/. It scales really well and will soon have GPU support for graph traversals. It has tinkerpop and SPARQL support.
Re: DegDB, an open-source distributed graph database
#7Nice to see. Is SPARQL support planned? I am wondering because it has a triplestore directory. In the meantime a more interesting production ready open source distributed graph database is worth looking at: https://www.blazegraph.com/ . It scales really well and will soon have GPU support for graph traversals. It has tinkerpop and SPARQL support.
Badwolf has a SPARQL-like query language too.
Re: DegDB, an open-source distributed graph database
#8Truples are common in graph databases, however both gun and Neo4J use more property graphs (while Neo4j has mandatory edge nodes, gun does not), which in my personal opinion is actually useful while triples are more of an academic thing (note here, I am biased because I am the author of gun). He chucks conflict resolution up to some fairly nondeterministic behavior that will ultimately require a lot of gossip, which then makes resolution hard and untimely. He also suggests that less popular content should be charged more, which I think worsens problems that already exist in things like Bittorrent, not mitigates them.
Re: DegDB, an open-source distributed graph database
#9Nice to see. Is SPARQL support planned? I am wondering because it has a triplestore directory. In the meantime a more interesting production ready open source distributed graph database is worth looking at: https://www.blazegraph.com/ . It scales really well and will soon have GPU support for graph traversals. It has tinkerpop and SPARQL support.
Re: DegDB, an open-source distributed graph database
#10Hey, maintainer of Cayley ( https://github.com/google/cayley ) here. Glad to see more people interested in this space! It looks like your code is mostly stubbed out right now -- using gorm for any persistence. You'll find that storing a basic graph is easy; doing more complex traversals and optimization is a harder problem. I can appreciate your concept of experimenting with adding monetary incentives on top of reque…
I'm aware that gorm isn't a great option for graph storage but seemed to be the easiest way of handling data storage initially. A lot of this project was written at a hackathon in ~36 hours but I've been refactoring.
I looked at Cayley (and have it as a dependency in an attempt to borrow the Gremlin parser). However, it doesn't seem to have a great way to store "metadata". How would you recommend adding fields to triples such as language, author, creation date, and cryptographic signature? Serializing and shoving them into Quad.Label seems kinda hacky.