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

Thomas Heute theute at redhat.com
Thu Mar 12 07:52:10 EDT 2015


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



More information about the hawkular-dev mailing list