Gremlin:OLAP与分割查询

我有一个查询（下面的链接），我必须每天或每周在我的应用程序中执行一次，以查找连接的用户组。在查询中，我为应用程序的每个用户检查所有可能的组（不是所有用户都被评估，但可能很多）。目前我只使用Gremlin服务器在localhost中进行性能测试，因为我的应用程序还没有上线

问题是，当模拟多个用户测试此查询时，查询达到了在Gremlin Server中默认配置的请求可以接受的时间限制，另一个问题是，查询没有占用全部CPU使用率，因为单个查询似乎被设计为使用单个线程或以某种方式减少CPU处理量

因此，我想到了两种解决方案，将查询划分为每个用户一个区块或使用OLAP：

解决方案1： 先发送一个查询以获取用户，然后为每个用户发送一个查询，然后删除服务器代码中的重复项，这在我的情况下应该是可行的，因为我可以同时发送所有查询，所以我可以使用所有可用资源并绕过时间限制

解决方案2： 使用OLAP。我想OLAP没有时间限制。问题是：我的想法是使用Amazon Neptune，据我所知，那里不支持OLAP。 关于这一问题：

大卫说： 更新：自GA（2018年6月）以来，Neptune在单个请求/事务中支持多个查询

“一个请求中的多个查询”是什么意思

我的解决方案1与OLAP相比如何

我是否应该寻找另一种支持OLAP而不是Neptune的数据库服务？哪一个可能是？我不想要一个选项，意味着学习设置自己的“海王星式”服务器，我的时间有限

如果您想查看我的查询：

---

这是一个有点复杂的问题

问题是，当模拟多个用户测试此查询时，查询达到了在Gremlin Server中默认配置的请求可以接受的时间限制

我假设您无法更改默认值是有原因的，但是对于那些可能正在阅读此答案的人来说，可以在服务器上（使用中的

evaluationTimeout

）和基于和的请求的每个请求上配置超时

另一个问题是，查询没有占用全部CPU使用率，因为单个查询似乎被设计为使用单个线程或以某种方式减少CPU处理量

如果您在Gremlin服务器中使用TinkerGraph进行测试，那么请知道TinkerGraph非常简单。它不会在内部并行运行遍历的任何方面（没有与OLAP相关的TinkerGraphComputer）

因此，我想到了两种解决方案，将查询划分为每个用户一个区块或使用OLAP：

这两种方法都有可能奏效。在第一个解决方案中，您建议使用poor man的OLAP，您必须设计自己的并行处理方法（即管理线程池、同步状态等）。我认为这种方法是人们处理此类问题的常见第一步。我想知道您是否需要像每个请求一个用户那样细粒度。我认为一次发送几个是可以接受的，但是只有在您的实际环境中进行测试才能得到答案。这个解决方案的好处在于，它通常适用于任何图形系统，包括海王星

在OLAP中使用第二个解决方案更为棘手。你有一个明显的问题，海王星不直接支持它，但去一个不同的供应商，不会立即解决你的问题。虽然OLAP使您不用担心如何最佳地并行化您的工作负载，但这并不意味着您可以立即接受您想要运行的Gremlin查询，将其放入Spark并获得即时胜利。例如，我从TinkerPop参考文档中获取：

In OLAP, where the atomic unit of computing is the vertex and its local 
"star graph," it is important that the anonymous traversal does not leave the 
confines of the vertex’s star graph. In other words, it can not traverse to an 
adjacent vertex’s properties or edges.

在您的查询中，已经有一个地方是您“离开星图”的，因此您可以立即找到需要解决的问题。通常，这种限制可以用于OLAP目的，但它并不像将

withComputer（）

添加到遍历中并在这种情况下获得胜利那样简单

使用OpAP以外的另一个图来进一步使用OLAP，您可能想至少考虑一下这个复杂的遍历是否可以更好地被写为一个可以更好地将您的用例绑定到比处理任意的Gremlin时更通用的<代码> TravaScript程序> /代码>的能力。就这一点而言，混合使用Gremlin OLAP、定制的

VertexProgram

和一些标准的map/reduce样式处理可能最终得到最优雅、最高效的答案

对于不支持OLAP的图，我一直在考虑的一个想法是将图中与算法相关的部分放到

子图（）

（使用Java）中，然后在TinkerGraph中本地执行它！我认为，在一些用例中，算法有一些限制可以提前定义以形成子图，这些限制可以很容易地过滤，并且生成的子图不会太大以至于需要花费大量时间来构建，这可能是有意义的。如果子图除了一个算法之外还有一些用途——几乎像缓存图一样工作，那就更好了。我不知道这对你是否有用，但这是一个想法。这是我最近写的一篇博文，其中谈到了。也许你会发现它很有趣

关于OLAP，我认为您的第一个解决方案似乎很好。你还没有一个几十亿的边图，现在你可能负担得起这种方法

“一个请求中的多个查询”是什么意思

我相信这只意味着您可以发送一个脚本，如：

g.addV().iterate()
g.addV().iterate()
g.V()

其中可以在单个事务的范围内执行