JanusGraph is a distributed graph database, which means it can be set in a multi-node cluster. However, when working in such an environment, there are some important things to consider. In addition, if configured correctly, JanusGraph users will deal with some special considerations.
1. Dynamic Graphs
JanusGraph support dynamic creation of graphics. This standard Gremlin Server implementations allow access patterns are different. Traditionally, user configured accordingly by gremlin-server.yaml files, create graphics and binding when the server starts. For example, graphs yaml part of your file is as follows:
graphs {
graph1: conf/graph1.properties,
graph2: conf/graph2.properties
}
Then, you will visit the diagram on the Gremlin Server in the following ways: String graph1 bind to open on the server according to its corresponding graphical properties file for graph2 well.
However, if we use ConfiguredGraphFactory dynamically created map, then these figures will manage JanusGraphManager, showing the arrangement by the ConfigurationManagementGraph management. This is particularly useful because it allows you to define configuration diagram after the service starts, and allow to persist and manage a distributed configuration in Figure JanusGraph cluster.
To properly use ConfiguredGraphFactory, you must use JanusGraphManager and ConfigurationManagementGraph in the cluster to configure each Gremlin Server. Here are detailed.
Consistency 1.1. Map
If you use ConfiguredGraphFactory configure all JanusGraph service, JanusGraph will ensure representation of all graphs JanusGraph on all nodes in the cluster are up to date.
For example, if you update or delete the configuration diagram on a JanusGraph node, then we have to remove the figure from the cluster cache per JanusGraph node. Otherwise, our cluster may appear inconsistent graph. This automatic processing queue JanusGraph clear the log message by using the back-end systems.
If you have a service is configured incorrectly, it may not be successfully removed the figure from the cache.
note:
Any updates TemplateConfiguration will not lead to update previously used graphics / graphic configuration creates the template configuration. To update a single figure configuration, you must use the API available to perform this update. Then, these updates will result in API across all cluster nodes of the graph JanusGraph cache cleared.
1.2. FIG dynamic and goes through the binding
JanusGraph graphics can be created dynamically binding on all JanusGraph each node in the cluster and its <graph.graphname> and <graph.graphname> traverse _traversal reference to lag up to 20 seconds to allow binding to take effect in the cluster any node. Read here for more information.
JanusGraph by having each node in the cluster polling ConfigurationManagementGraph for this purpose has been to create graphics for all configurations. Then, JanusGraphManager will use its open configuration of the persistent pattern, the pattern in its cache, and <graph.graphname> bind to store the reference pattern GremlinExecutor, and bind <graph.graphname> _traversal to graphics reference traverse on. GremlinExecutor.
This allows graphic string bound access dynamically created references you traverse through each node in the cluster and JanusGraph. This is especially important to use Gremlin Server client and use TinkerPops of withRemote function.
1.2.1 Set
To set up the cluster to bind dynamically created graphics and traverse the reference, you must:
- Configure each node to use ConfiguredGraphFactory.
- Configuring each node JanusGraphChannelizer, Gremlin Server will lower-level components (e.g. GremlinExecutor) injected into JanusGraph project, allow us to better control the Gremlin Server.
To each node is configured to use JanusGraphChannelizer, we must update the gremlin-server.yaml to do this:
channelizer: org.janusgraph.channelizers.JanusGraphWebSocketChannelizer
You can choose the following channelizers:
- org.janusgraph.channelizers.JanusGraphWebSocketChannelizer
- org.janusgraph.channelizers.JanusGraphHttpChannelizer
- org.janusgraph.channelizers.JanusGraphNioChannelizer
- org.janusgraph.channelizers.JanusGraphWsAndHttpChannelizer
All TinkerPop channelizers are identical to corresponding functions.
1.2.2 Using TinkerPop function of withRemote
Due to traverse the reference binding on JanusGraph service, so we can use TinkerPop of withRemote function. This will allow in the case of remote graphics referenced in the query run locally gremlin. Traditionally, by sending a string representation script to run queries against remote Gremlin service, which shows a process on a remote service and the response is serialized and sent back. However, TinkerPop also allows the use remoteGraph, if you're building can easily be transferred to TinkerPop compatible graphics infrastructure for multiple implementations, which may be useful.
To use this feature in JanusGraph, we must first ensure that a map is created on a remote cluster JanusGraph:
ConfiguredGraphFactory.create("graph1");
Next, we have to wait 20 seconds to ensure traverse references on each node binding JanusGraph in remote cluster.
Finally, we can use withRemote methods to access local references to the local remote graph:
gremlin> cluster = Cluster.open('conf/remote-objects.yaml')
==>localhost/127.0.0.1:8182
gremlin> graph = EmptyGraph.instance()
==>emptygraph[empty]
gremlin> g = graph.traversal().withRemote(DriverRemoteConnection.using(cluster, "graph1_traversal"))
==>graphtraversalsource[emptygraph[empty], standard]
In order to accomplish the above conf / remote-objects.yaml Cluster API should be told how to access remote JanusGraph server; for example, it may look like:
hosts: [remoteaddress1.com, remoteaddress2.com]
port: 8182
username: admin
password: password
connectionPool: { enableSsl: true }
serializer: { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV3d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
Welcome to sweep the code number of public attention, better communication
