Marko A. Rodriguez created TINKERPOP3-942:
---------------------------------------------
Summary: Use EventStrategy to solve OLAP bulk mutation of OLTP.
Key: TINKERPOP3-942
URL: https://issues.apache.org/jira/browse/TINKERPOP3-942
Project: TinkerPop 3
Issue Type: Improvement
Components: process
Affects Versions: 3.1.0-incubating
Reporter: Marko A. Rodriguez
Assignee: Daniel Kuppitz
We need to be able to do this in TinkerPop3.
https://github.com/thinkaurelius/faunus/wiki/Distributed-Graph-Computing-with-Gremlin
This can be solved with {{EventStrategy}}.
Lets think of the hardest problem first -- distributed graph database (e.g.
Titan) being mutated by a distributed graph processor (e.g. Giraph). Each
Giraph node will map to a Titan node. Then the Giraph node will create a
connection back to the respective Titan node via the {{writeGraph}} model by
[~dkuppitz] in {{BulkLoaderVertexProgram}}. Every time a {{addV()}},
{{addE()}}, {{property()}} is called, an event is fired and THAT event is call
back to the Titan to create the vertex/edge/property. Likewise for {{drop()}},
etc. In other words, all {{Mutating}} steps can have a call back in OLAP to
mutate the OLTP system.
What about the easy case of {{TInkerGraph}} OLAP talking to {{TinkerGraph}}
OLTP? Well, this gets back to {{GraphComputer.RESULT_GRAPH}} and whether your
graph computer is operating over the real graph or a clone of it. However, I
think its just the same as TItan/Giraph-style.
So what is this good for?
* Drop all the "knows" edges.
* Change all the date properties from {{java.util.Date}} to {{Long}}.
* Infer all {{foaf}}-edges.
* etc.
Things to consider -- transactions.
If we solve this cleanly, then that is truly the final "big hurdle" in the
{{GraphComputer}} story.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
