Comments on: Wishlist of features for a distributed graph data base technology https://www.rene-pickhardt.de/wishlist-of-features-for-a-distributed-graph-data-base-technology/ Extract knowledge from your data and be ahead of your competition Tue, 17 Jul 2018 11:07:57 +0000 hourly 1 https://wordpress.org/?v=4.9.6 By: PhD proposal on distributed graph data bases https://www.rene-pickhardt.de/wishlist-of-features-for-a-distributed-graph-data-base-technology/#comment-29632 Tue, 27 Mar 2012 10:19:28 +0000 http://www.rene-pickhardt.de/?p=1151#comment-29632 […] Over the last week we had our off campus meeting with a lot of communication training (very good and fruitful) as well as a special treatment for some PhD students called “massage your diss”. I was one of the lucky students who were able to discuss our research ideas with a post doc and other PhD candidates for more than 6 hours. This lead to the structure, todos and time table of my PhD proposal. This has to be finalized over the next couple days but I already want to share the structure in order to make it more real. You might also want to follow my article on a wish list of distributed graph data base technology […]

]]>
By: Stefan https://www.rene-pickhardt.de/wishlist-of-features-for-a-distributed-graph-data-base-technology/#comment-29628 Fri, 24 Feb 2012 16:17:40 +0000 http://www.rene-pickhardt.de/?p=1151#comment-29628 I agree with the main points of you “wishlist”. Only two little comments, as query language i would also prefer a tranversal language but for some usecases a graph matching language like sparql could also be interesting.
For example, in social networks searching persons depending on different features (age, homebase, interests …). I was thinking about transforming sparql queries to index lookups and tranversals. Supported by rules (e.g. for type subsumption), such a system could even be more powerful than sparql. Sarql does not support arbitrary depth tree traversal you would need for e.g. the “give me all ancestors of a person” query.
Combined system would be able to solve such problems.
Second the redundancy point, i agree that redundancy seems to be very interesting, especially regarding the graph distribution. But i also think that redundancy could lead to multiple side effects with write/delete operations. Keeping all redundant copies up to date in an distributed system where multipe competitive jobs are running at the same time is a challenging task. To solve this, you would probably have to apply versioning, version control and/or blocking or log mechanisms to graph-nodes or atomic subgraphs.
From my point of view this would be work for the later paret of the problem.
Thirdly and lastly, for me fault tolerance is the last to think about.

]]>