通过嵌入式使用远程 janusgraph 连接有什么优点和缺点?

Ali*_*oud 5 java tinkerpop gremlin-server janusgraph

我在我的 Java 后端使用嵌入式 janusgraph 我的代码取决于从 graph = JanusGraphFactory.open(conf)

AFAIK 这直接连接到 Cassandra 和弹性搜索,并在我的后端应用程序 JVM 中运行 janusgraph 处理器。但是如果我想扩展 janusgraph,我需要在集群上运行单独的 janusgraph 服务器,并且需要作为客户端从我的后端连接到这些服务器。

根据github上的远程 janusgraph 示例,这是通过实例化一个 EmptyGraph 来完成的,该 EmptyGraphgraph = EmptyGraph.instance();不是 JanusGraph 的实例,而是 org.apache.tinkerpop.gremlin.structure.util.empty.EmptyGraph;.

我可以从上面的示例中了解到,我只能通过将 gremlin 查询提交给 janusgraph 服务器来使用它们,但是除非将代码作为字符串提交给服​​务器,否则我将无法直接使用管理 API。

最后,我可以理解,单独运行 janusgraph 服务器对可扩展性更好,但我将无法在我的代码中直接访问 janusgraph api,所以我想知道我是否理解一些我想念的 内容以及远程部署方法的优缺点和嵌入式方法相比我会失去什么?

编辑:

根据这个答案 纠正它,如果错了

连接到远程 gremlin 服务器的优缺点

优点

  • 服务器有更多的控制权,所有的查询都是集中的。
  • 由于每个人都通过远程 gremlin 服务器运行遍历/查询,因此所有内容都受到事务保护。默认情况下,远程 gremlin 服务器在事务中运行您的遍历/查询。
  • 中央战略管理
  • 中央模式管理

缺点

  • 很难进行手动事务管理
  • 您必须使用 groovy 脚本作为字符串并将其发送到删除(集群提交)以执行代码的事务。

Bis*_*hnu 0

无论上面列出的优点和缺点都是正确的,除此之外我将列出我的经验教训:

使用gremlin 服务器方法,作为用户,架构将看起来像一个 Web 服务器(额外成本正在联系存储系统的这些gremlin服务器的扩容/缩容必须根据负载手动处理,否则将成为整个系统的瓶颈。

嵌入模式下,您有一个存储系统(例如 Cassandra)和另一个通过 Tinker Pop Gremlin 与之交互的存储系统。这样,您就不必维护 gremlin 服务器,只需您的程序/客户端与存储服务器进行交互。

考虑通过 Apache Spark 加载数据,一旦您使用更多执行器运行作业,gremlin 服务器应该有足够的能力来处理负载。