[
https://issues.apache.org/jira/browse/ATLAS-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16269195#comment-16269195
]
Graham Wallis commented on ATLAS-2270:
--------------------------------------
Hi [~ppadovani]
As you said JanusGraph fully supports Cassandra and ElasticSearch.
I think there may be two things that we need to fix to get that combination
working in Atlas - in addition to your pom changes.
* I hadn't realised that there was an issue with the '.' character - but until
now I guess Atlas has only been using ES 1.x.
* The other issue is that from JanusGraph 0.2.0 onwards JanusGraph expects to
communicate with ElasticSearch using the REST API. Until now Atlas has relied
on the graphDB (whether titan or janus) to bring up an embedded ES index
server; but from JanusGraph 0.2.0 onwards we need to spawn a separate ES server
process that JanusGraph can connect to as a REST client, as described here
[http://docs.janusgraph.org/latest/upgrade.html]
That change to the internal Janus-ES topology was one of the things that
triggered this JIRA - as I wanted to assess the level of interest in ES rather
than just assume that Atlas should continue with it. Many uses of Atlas are
based on hadoop and I think would understandably have a bias toward Solr. So
with regard to my (rather poorly formatted :-) ) tables in this JIRA I am
starting to think that the interesting combinations might be HBase-Solr,
Cassandra-ES and _possibly_ BDB with either Solr or ES (but maybe not both).
The latter is IMHO quite useful for dev/debug purposes as it is very easy to
stop Atlas and configure a gremlin-console to look at the BDB graph on the
filesystem. I wonder whether that set of combinations may provide reasonable
coverage at least for now - i.e. it would be minimal but sufficient. Please
(anyone) comment if you agree or disagree.
BTW: Are you currently working with JanusGraph 0.1.1 or 0.2.0?
Many thanks
Graham
> Supported combinations of persistent store and index backend
> ------------------------------------------------------------
>
> Key: ATLAS-2270
> URL: https://issues.apache.org/jira/browse/ATLAS-2270
> Project: Atlas
> Issue Type: Bug
> Reporter: Graham Wallis
>
> We need to discuss and decide which combinations of persistent store and
> indexing backend Atlas 1.0.0 (master) should support. This includes
> building/running Atlas as a standalone package and running UTs/ITs as part of
> the Atlas build.
> This JIRA focusses on titan0 and janusgraph 0.2.0, as they are the graph
> databases that will be supported in master/1.0.0. This JIRA deliberately
> ignores titan1 and janusgraph 0.1.1 as the former should be
> deprecated/removed and the other is a transient state as we get to janusgraph
> 0.2.0.
> With titan0 as the graph provider, Atlas has supported the following
> combinations of persistent store and indexer. It is suggested that this set
> is kept unchanged:
> {{
> titan0 solr es
> ------------------------------------
> berkeley 0 1
> hbase 1 0
> cassandra 0 0
> }}
> With janusgraph (0.2.0) as the graph provider, Atlas *could* support
> additional combinations. Cassandra is included in this discussion pending
> response to ATLAS-2259.
> {{
> janus 0.2.0 solr es
> ------------------------------------
> berkeley ? 1
> hbase 1 ?
> cassandra ? ?
> }}
> It is suggested that the combinations marked with '1' should be continued and
> the remaining 4 combinations, marked with '?', should be considered. There
> seems to be evidence of people using all 4 of these combinations, although
> not necessarily with Atlas.
> Depending on the decision made above, we need to ensure that it is possible
> to build Atlas as a standalone package with any of the combinations - i.e.
> that they are mutually exclusive and do not interfere with one another. They
> currently interfere which makes it impossible to build Atlas with
> -Pdist,berkeley-elasticsearch because the 'dist' profile will exclude jars
> that are needed by the berkeley-elasticsearch profile - which leads to class
> not found exceptions when the Atlas server is started. The solution to this
> could be very simple, or slightly more sophisticated, depending on how many
> of the combinations we choose to support.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
