atlas-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Wallis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ATLAS-2270) Supported combinations of persistent store and index backend
Date Tue, 28 Nov 2017 18:22:00 GMT

    [ 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)

Mime
View raw message