时间戳

首页 > 解决方案 > 为什么我的 Gremlin 查询会导致这么多请求？这是正确的行为吗？

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

问题描述

我正在尝试调试我在使用 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。我尝试使用“管理”边缘创建一棵树，然后在该树中找到所有“相似”边缘。

这个查询给出了想要的结果，但它是否未优化？

标签： graphgremlinamazon-neptune

解决方案

两个遍历都遵循几乎相同的路径，这使得它们很容易组合：

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。因此，我们可以只使用and ，而不是使用bothEand otherV（启用路径跟踪）：outEinV

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()

推荐阅读