使用远程JanusGraph连接和使用嵌入式连接相比，有哪些优缺点？

Question

我在我的Java后端中使用嵌入式JanusGraph，我的代码依赖于从graph = JanusGraphFactory.open(conf)实例化的JanusGraph。

据我所知，这将直接连接到Cassandra和Elasticsearch，并在我的后端应用程序JVM中运行JanusGraph处理器。但是，如果我想扩展JanusGraph，我需要在集群上运行单独的JanusGraph服务器，并需要从后端作为客户端连接到这些服务器。

根据Github上远程JanusGraph示例，这可以通过实例化一个EmptyGraph graph = EmptyGraph.instance();来实现，它不是JanusGraph的实例，而是org.apache.tinkerpop.gremlin.structure.util.empty.EmptyGraph;的实例。

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

最后，我可以理解，为了可扩展性，单独运行JanusGraph服务器是更好的选择，但我将失去对JanusGraph API的直接访问，因此我想知道是否有什么我误解的地方以及远程部署方法的优缺点，以及与嵌入式方法相比将失去什么。

编辑：

根据此答案 （如果有误，请纠正）：

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

优点

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

缺点

- 很难进行手动事务管理 - 必须使用Groovy脚本作为字符串并将其发送到远程（集群提交）以执行您的代码的事务。

- Ali Aboud

---

你好，你有没有关于如何使用远程JanusGraph进行事务管理的示例？ - Serhii Zadorozhnyi

Answer 1

无论上面列出的优缺点是否正确，我都会列出我的学习成果：

使用gremlin server方法时，作为用户，架构将看起来像一个Web服务器（额外成本），它正在联系存储系统。这些gremlin服务器的升级/降级必须根据负载手动处理，否则它将成为整个系统的瓶颈。

在嵌入式模式中，您有一个存储系统（比如Cassandra）和另一个通过tinker pop gremlin与其交互的存储系统。使用此方法，您不必维护gremlin服务器，只需您的程序/客户端与存储服务器进行交互即可。

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

- Bishnu