跳到内容

部署场景

JanusGraph 提供了多种存储和索引后端选择,这使得其部署具有极大的灵活性。本章将介绍几种可能的部署场景,以帮助您应对这种灵活性带来的复杂性。

在讨论不同的部署场景之前,了解 JanusGraph 本身及其后端的作用非常重要。首先,应用程序只直接与 JanusGraph 通信,主要是通过发送 Gremlin 遍历进行执行。然后,JanusGraph 与配置的后端通信以执行接收到的遍历。当 JanusGraph 以 JanusGraph Server 的形式使用时,并没有像“主”JanusGraph Server 这样的东西。因此,应用程序可以连接到任何 JanusGraph Server 实例。它们还可以使用负载均衡器来安排对不同实例的请求。JanusGraph Server 实例之间不直接通信,这使得在需要处理更多遍历时可以轻松地扩展它们。

注意

本章介绍的场景只是 JanusGraph 如何部署的示例。每次部署都需要考虑具体的用例和生产需求。

入门场景

此场景是大多数用户在刚开始使用 JanusGraph 时可能希望选择的场景。它以最少的服务器数量提供可伸缩性和容错性。JanusGraph Server 与存储后端的一个实例以及可选的索引后端的一个实例在每台服务器上一起运行。

Getting started deployment scenario diagram

这样的设置可以通过简单地添加更多相同类型的服务器或将其中一个组件移动到专用服务器上来扩展。后者描述了将部署转换为高级场景的增长路径。

此场景可以使用任何可伸缩的存储后端。但请注意,对于 Scylla,当它与此场景中的其他服务共同托管时,需要进行一些配置。如果此场景中要使用索引后端,那么它也需要是可伸缩的。

高级场景

高级场景是入门场景的演变。JanusGraph Server 实例不再与存储后端以及可选的索引后端一起托管,而是分离在不同的服务器上。将不同组件(JanusGraph Server、存储/索引后端)托管在不同服务器上的优势在于它们可以相互独立地扩展和管理。这提供了更高的灵活性,但代价是需要维护更多的服务器。

Advanced deployment scenario diagram

由于此场景提供了不同组件的独立可伸缩性,因此使用可伸缩后端当然也最有意义。

极简主义场景

也可以将 JanusGraph Server 与后端一起托管在同一台服务器上。这对于测试目的特别有吸引力,例如当 JanusGraph 只支持一个应用程序时,该应用程序也可以在同一台服务器上运行。

Minimalist deployment scenario diagram

与前面的场景相反,此场景最适合使用不可伸缩的后端。内存后端可用于测试目的,或者 Berkeley DB 用于生产,Lucene 作为可选的索引后端。

嵌入式 JanusGraph

除了从应用程序连接到 JanusGraph Server,还可以将 JanusGraph 作为库嵌入到基于 JVM 的应用程序中。虽然这减少了管理和网络开销,但它使得 JanusGraph 无法独立于应用程序进行扩展。嵌入式 JanusGraph 可以作为任何其他场景的变体进行部署。JanusGraph 只是从服务器直接移动到应用程序中,因为它现在只作为库而不是独立服务使用。您需要将 `janusgraph-core` 依赖项以及所选后端所需的模块引入到您的项目中。例如,如果您有一个 Maven 项目,并且您使用 Cassandra 和 Lucene 作为后端,您应该将以下依赖项添加到您的 `pom.xml` 中

<dependencies>
    <dependency>
        <groupId>org.janusgraph</groupId>
        <artifactId>janusgraph-core</artifactId>
        <version>${janusgraph.version}</version>
    </dependency>
    <dependency>
        <groupId>org.janusgraph</groupId>
        <artifactId>janusgraph-cql</artifactId>
        <version>${janusgraph.version}</version>
    </dependency>
    <dependency>
        <groupId>org.janusgraph</groupId>
        <artifactId>janusgraph-lucene</artifactId>
        <version>${janusgraph.version}</version>
    </dependency>
</dependencies>

然后,您可以在应用程序代码中启动一个 JanusGraph 实例,类似于您在 Gremlin 控制台中所做的那样

import org.janusgraph.core.JanusGraph;
import org.janusgraph.core.JanusGraphFactory;
import org.janusgraph.core.schema.JanusGraphManagement;

public class MyGraphApp {
    public static void main(String[] args) {
        JanusGraph graph = JanusGraphFactory.open("/path/to/your/config/file");
        JanusGraphManagement mgmt = graph.openManagement();
        mgmt.printSchema();
        mgmt.commit();
        graph.close();
    }
}

Gremlin 解析器

JanusGraph 服务器可以接受纯字符串格式的临时 Gremlin 查询,而嵌入式 JanusGraph 需要您为任何查询编写 Java 代码。您可以在 JanusGraph 之上开发自己的 DSL(领域特定语言),以向最终用户公开图查询功能。或者,您可以利用内置的 Gremlin 解析器来获取纯字符串格式的任何 Gremlin 查询,解析它们并在嵌入了 JanusGraph 的应用程序中执行它们。要利用 Gremlin 解析器,请查看 graph.script-eval。一旦您打开脚本评估选项,您就可以使用 `JanusGraph::eval` 方法评估 Gremlin 查询

graph.eval(/* gremlin script */ "g.V().count().next()",                 /* commit */ false);
graph.eval(/* gremlin script */ "g.addV().next();g.V().count().next()", /* commit */ true)

如上所示,您可以传入单个 Gremlin 查询或纯字符串格式的 Gremlin 脚本。可选地,您可以在执行后提交或回滚脚本。这在您希望阻止最终用户更新图时很有用。