[TINKERPOP-942] Use EventStrategy to solve OLAP bulk mutation of OLTP.

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 3.1.0-incubating
• Component/s: process
• Assignee: Unassigned
• Reporter: Marko A. Rodriguez
• Created: 05/Nov/15 15:34
• Updated: 28/Apr/21 19:06

Description

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.