Question

我正在尝试调试AWS Neptune遇到的性能问题。我正在运行一些Gremlin查询，它们似乎总是在数据库上导致30个请求。我想知道我的查询是否做错了。

这个问题的奇怪之处是突然发生了。以前，这工作得很好，而且我们没有性能问题。

我每次通话都有两个常规查询，一个查询节点，一个查询边缘：

nodes = g.V(id).emit().repeat(__.out('manages')).dedup().project('label', 'name', 'job', 'department', 'manager').\
    by(__.id()).by('name').by('job').by('department').by('manager').toList()

id_list = list(map(lambda node: node["label"], nodes))

edges = g.V(id).emit().repeat(__.out('manages')).dedup().bothE('similar_to').dedup().\
    where(__.and_(__.inV().has(T.id, P.within(id_list)), __.outV().has(T.id, P.within(id_list)))).\
    project('from', 'to', 'similarity').by(__.outV().id()).by(__.inV().id()).by('similarity').toList()

从本质上讲，我有两种边缘类型：manages和similar_to。我尝试使用“管理”边创建一棵树，然后在该树中找到所有“相似”边。

此查询提供了所需的结果，但未优化吗？

Answer 1

这两种遍历都遵循相同的路径，因此可以轻松地将它们组合在一起：

g.V(id).
  emit().
    repeat(__.out('manages')).
  aggregate('x').
  bothE('similar_to').dedup().
  filter(__.otherV().where(P.within('x'))).
  project('from', 'to', 'similarity').
    by(__.outV().id()).
    by(__.inV().id()).
    by('similarity').
  toList()

现在我才意识到我们可以使它更加简单。由于您需要两个由similar_to连接的顶点都成为x的一部分，因此这意味着结果中的每个边都必须是x中任何一个顶点的边缘。因此，我们可以只使用bothE和otherV，而不必使用outE和inV（启用路径跟踪）：

g.V(id).
  emit().
    repeat(__.out('manages')).
  aggregate('x').
  outE('similar_to').dedup().
  filter(__.inV().where(P.within('x'))). /* outV is already guaranteed to be within "x" */
  project('from', 'to', 'similarity').
    by(__.outV().id()).
    by(__.inV().id()).
    by('similarity').
  toList()

为什么我的Gremlin查询导致这么多请求？这是正确的行为吗？

1 个答案: