为什么 RexsterGraph 不适用于高性能图遍历？答案

【问题标题】：Why RexsterGraph is not meant for high-performing graph traversals?为什么 RexsterGraph 不适用于高性能图遍历？
【发布时间】：2014-06-27 10:55:26
【问题描述】：

为什么蓝图堆栈中的 RexsterGraph 不适用于高性能图遍历：
https://github.com/tinkerpop/blueprints/wiki/Rexster-Implementation

有什么限制？然后我应该回退执行 gremlin 抛出一个简单的字符串评估吗？

【问题讨论】：

标签： graph-databases gremlin

【解决方案1】：

RexsterGraph 使用 Rexster REST API，它是 Blueprints API 的 RESTful 表示。因此，RexsterGraph 中调用的每个蓝图方法都会转换为 HTTP 调用。

下面是一个示例，说明为什么这对“高性能遍历”不利。以toy graph 为例。假设我想用RexsterGraph 做一些简单的事情，比如：g.v(1).out.filter{it.name=='josh'}.name。这将转化为以下 HTTP 调用：

vertices/1 - 获取v(1) 的数据
vertices/1/outE - 获取v(1) 的出边
vertices/2 - 知道出边告诉我们要检索的另一个顶点
vertices/3 - 知道出边告诉我们要检索的另一个顶点
vertices/4 - 知道出边告诉我们要检索的另一个顶点
vertices/2 - 现在我们正在过滤，所以我们需要 name 属性
vertices/3 - 现在我们正在过滤，所以我们需要 name 属性
vertices/4 - 现在我们正在过滤，所以我们需要 name 属性
vertices/4 - 现在我们要“josh”了，所以获取 name 属性

如您所见，它效率不高。它是 Blueprints API 到 Rexster REST API 的一对一映射。就是这样。可以提高效率吗？可能......我们可能会考虑缓存属性值或其他东西，但对于“高性能遍历”来说，它仍然会非常健谈。试图使其更高效的其他问题是处理序列化闭包的机制，以便可以在服务器上执行。

最后，很久以前就决定这不是一个好方法，我们开始建议不要使用RexsterGraph，而是使用服务器端DSLs 和 RexPro/REST Gremlin 扩展。

【讨论】：