Please follow these instructions when upgrading from Titan or an older JanusGraph release.
JanusGraph is based on the latest commit to the titan11 branch of
Titan repo.
JanusGraph has made the following changes to Titan, so you will need to adjust your code and configuration accordingly:
- module names:
titan-*are nowjanusgraph-* - package names:
com.thinkaurelius.titanare noworg.janusgraph - class names:
Titan*are nowJanusGraph*except in cases where this would duplicate a word, e.g.,TitanGraphis simplyJanusGraphrather thanJanusGraphGraph
For more information on how to configure JanusGraph to read data which had previously been written by Titan refer to Chapter 37, Migrating from Titan.
JanusGraph 0.1.z is compatible with Elasticsearch 1.5.z. There were several configuration options available, including transport client, node client, and legacy configuration track. JanusGraph 0.2.0 is compatible with Elasticsearch versions from 1.y through 6.y, however it offers only a single configuration option using the REST client.
The TRANSPORT_CLIENT interface has been replaced with REST_CLIENT. When
migrating an existing graph to JanusGraph 0.2.0, the interface property must
be set when connecting to the graph:
index.search.backend=elasticsearch index.search.elasticsearch.interface=REST_CLIENT index.search.hostname=127.0.0.1
After connecting to the graph, the property update can be made permanent by
making the change with JanusGraphManagement:
mgmt = graph.openManagement() mgmt.set("index.search.elasticsearch.interface", "REST_CLIENT") mgmt.commit()
A node client with JanusGraph can be configured in a few ways. If the node
client was configured as a client-only or non-data node, follow the steps
from the transport client section to connect to the
existing cluster using the REST_CLIENT instead. If the node client was
a data node (local-mode), then convert it into a standalone Elasticsearch
node, running in a separate JVM from your application process. This can be
done by using the node’s configuration from the JanusGraph configuration to
start a standalone Elasticsearch 1.5.z node. For example, we start with these
JanusGraph 0.1.z properties:
index.search.backend=elasticsearch index.search.elasticsearch.interface=NODE index.search.conf-file=es-client.yml index.search.elasticsearch.ext.node.name=alice
where the configuration file es-client.yml has properties:
node.data: true path.data: /var/lib/elasticsearch/data path.work: /var/lib/elasticsearch/work path.logs: /var/log/elasticsearch
The properties found in the configuration file es-client.yml and the
index.search.elasticsearch.ext.* properties can be inserted into $ES_HOME/config/elasticsearch.yml
so that a standalone Elasticsearch 1.5.z node can be started with the same
properties. Keep in mind that if any path locations have relative paths,
those values may need to be updated appropriately. Once the standalone
Elasticsearch node is started, follow the directions in the transport client
section to complete the migration to the REST_CLIENT interface. Note that
the index.search.conf-file and index.search.elasticsearch.ext.* properties
are not used by the REST_CLIENT interface, so they can be removed from the
configuration properties.
In JanusGraph 0.2.0, time-to-live (TTL) support was added for HBase storage backend.
In order to utilize the TTL capability on HBase, the graph timestamps need to be
MILLI. If the graph.timestamps property is not explicitly set to MILLI, the default
is MICRO in JanusGraph 0.2.0, which does not work for HBase TTL. Since the graph.timestamps
property is FIXED, a new graph needs to be created to make any change of the graph.timestamps
property effective.