3:48 p.m.
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
6:52 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
7:03 a.m.
https://github.com/tinkerpop/tinkerpop3/blob/master/gremlin-core/src/main...
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
3356
days inactive
3357
days old
2 comments
2 participants
participants (2)
-
Lukas Krejci -
Thomas Heute