[Hawkular-dev] Titan's future at Datastax and Hawkular Inventory

[Lukas Krejci]

https://github.com/tinkerpop/tinkerpop3/blob/master/gremlin-core/src/main/java/com/tinkerpop/gremlin/structure/io/GraphMigrator.java

This is part of the core Tinkerpop3. So switching to another Tinkerpop3-based 
graph database shouldn't theoretically be an insurmountable obstacle. If we 
move away from graph dbs altogether, we might use the Gremlin IO to persist 
the graph to a file (GraphML) and work with that to migrate it to the 
different datastore.

On Thursday, March 12, 2015 12:52:10 Thomas Heute wrote:
> My main concern if our API can remain as-is is the (difficult) data
> migration. How can we mitigate the risks ?
> 
> Thomas
> 
> On 03/11/2015 09:48 PM, Lukas Krejci wrote:
> > Hi all,
> > 
> > today, Jirka and me attended the webinar organized by Datastax where they
> > outlined their plans for Titan - our candidate graph database to use for
> > inventory storage.
> > 
> > The outcome is IMHO both good and bad.
> > 
> > Datastax is committed to push Titan to 1.0 and port it to Tinkerpop3 API
> > (which is due "imminently" and the port is well under way -
> > https://github.com/thinkaurelius/titan/tree/titan09). They are also
> > committed to be further involved in the design of the Tinkerpop3 API
> > (i.e. the equivalent of JDBC for graph databases).
> > 
> > Once Titan 1.0 is out they plan to "let the community take over" and don't
> > plan any further work on it.
> > 
> > After that, they're shifting focus on DSE Graph - a proprietary graph
> > database that will be integrated into DSE - their proprietary offering
> > expanding on Cassandra's capabilities. This is not going to be open
> > source but will support the Tinkerpop3 API as its primary interface.
> > 
> > So there are 2 outcomes for us from this IMHO.
> > 
> > First, if we are to stick with a graph database as the storage platform
> > (which I think makes sense), we should adopt Tinkerpop. We currently
> > support Tinkerpop2 which is radically different from Tinkerpop3 but the
> > contact surface between us and their API is quite small (at least at the
> > moment) and in an area that actually didn't change that much (the Gremlin
> > graph traversal DSL).
> > 
> > Second, given the unique advantage of the shared storage for metrics and
> > inventory, we should stick with Titan (perf benchmarks still pending) for
> > now and see how it will evolve post 1.0. If it dies slowly and we hit
> > issues that we would not be able to solve ourselves, we can choose
> > another database implementing Tinkerpop3. At the moment the only other
> > choice is Neo4j, but given the involvement of many graphdb companies in
> > the design of the Tinkerpop3 API
> > (http://www.tinkerpop.com/docs/3.0.0.M7/#tinkerpop-contributors), I am
> > quite confident that there are going to be more choices in due time.
> > 
> > As a side note, our inventory API is not tied to the Tinkerpop API in any
> > way. It's just that the graph API naturally fits for implementing the
> > inventory API and in fact, the impl is quite compact. But should we, due
> > to some cataclysmic findings, choose to abandon tinkerpop API altogether,
> > then only a fraction of the inventory codebase would be affected - the
> > REST API, UI and all the other future integration code would be
> > unaffected by that departure.
> > 
> > WDYT?
> > 
> > Lukas
> > 
> > 
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev