【问题标题】:ArangoDB AQL Filtering Using Edges and Vertices with Unknown Positions in Graph Traversal Path使用图遍历路径中未知位置的边和顶点的 ArangoDB AQL 过滤
【发布时间】:2016-09-19 19:41:01
【问题描述】:

我有一个通用的图结构,我需要根据它们与图中其他节点的连接来找到图中的非叶节点。我要返回的节点的位置没有定义,可能有多个路径到我要返回的节点。我想运行一个查询以将我在排序列表中显示的一堆项目返回给客户端。我不想在客户端运行多个异步查询和排序。

此列表根据将顶点连接在一起的边进行过滤,或者该节点是否连接到另一个节点。过滤条件在客户端更新,导致重新构造查询并重新查询数据库。图中需要返回的节点的位置并不保证对所有结果都相同,它们可能是叶节点,也可能是路径中的任何位置。我想要返回的顶点可以通过通向它们的边上的属性来识别,或者远离它们。每条边上还有一个用于排序的日期属性和一个用于过滤的类型属性。

图表“myGraph”中的图像,如下所示。

------- 
| v:1 |\
------- \
   | \   \ -------
   |  |   \| v:4 |\
   |  \    ------- \
   |   |  /   ^     \ -------
   |    \/    |      \| v:7 |
   |    /|  return    -------   
   |   /  \             
   |  /   |              
-------   \
| v:2 |\   |
------- \   \
   |     \ -------
   |      \| v:5 |\
   |       ------- \
   |                \ -------
   |                 \| v:8 |\
   |                  ------- \ 
   |                     ^     \ -------
   |                     |      \| v:10|
-------                return    -------   
| v:3 |\   
------- \   
         \ -------
          \| v:6 |\
           ------- \
                    \ -------
                     \| v:9 |
                      -------
                         ^
                         | 
                       return

上图说明了给定一组过滤条件我想要返回的内容,但是如果我更改过滤条件,返回的结果可能会有所不同。我想要返回的节点很容易根据通向它们或远离它们的边缘上的属性来识别。

我有一个类似于以下内容的查询,但我无法找到一种方法来索引路径中的节点,这些节点的边缘通向或远离满足特定过滤条件的节点。

FOR item in vertexCollection1
   FILTER .... // FILTER the vertices
   FOR v, e, p IN 1..4 OUTBOUND item._id GRAPH 'myGraph'
      // ?? Not sure how to efficiently return from here
      // ?? FILTER p.vertices[??].v == 7 OR p.vertices[??].v == 10
      // ?? FILTER p.edges[??].type == "type1" OR p.edges[??].type == "type2"... etc based on user selections
      // ?? LET date = p.edges[vertexPosition - 1].date 
      // ?? LET data = p.vertices[??]
      // SORT DATE_TIMESTAMP(date) DESC
      // RETURN {date: date, data: data}

我目前正在使用 [ ** ] 操作根据其所在的集合获取特定节点,使用类似以下内容:

LET data = p.vertices[ ** FILTER CONTAINS(CURRENT._id, "collectionName") OR ...]

但这很尴尬,并且需要将顶点放置在特定的集合中以方便查询构造。这也没有解决如何索引连接到我要返回的节点的关联边的问题。

如果这个问题在其他地方得到回答,我深表歉意,如果它是指向答案的指针,我们将不胜感激。我不确定使用正确的术语来简明地描述问题并进行相应的搜索。

谢谢!

【问题讨论】:

    标签: arangodb aql


    【解决方案1】:

    我能够使用类似于以下结构的查询获得所需的行为:

    LET events = (
    FOR v, e, p IN 1..3 OUTBOUND 'collection/document_id' GRAPH 'myGraph' OPTIONS {"uniqueEdges": "global"}
        FILTER .... // Filter the vertices
        LET children = (
            FOR v1, e1, p1 IN 1..1 OUTBOUND v._id GRAPH 'myGraph'
                FILTER e1.type == "myEventType" OR ... // Filter immediate neighbors I care about
                SORT(e1.date)  // I have date timestamps on everything
                RETURN { child: v1._id, ... /* other child attributes as needed */ }
        )
    
        // FILTER .... conditions on children if necessary in context of v
    
        RETURN DISTINCT (data: v, children: children, ... /* other attributes as needed */ )
    )
    
    FOR event IN events
        SORT(event.date) // I need chronological sorting and have date attribute on every node
        RETURN event
    

    RETURN 子句上的 DISTINCT 修饰符似乎删除了由多个路径到同一节点产生的重复项,并且我能够根据各种子节点和父节点上的属性添加我需要的自定义过滤器。

    我不确定这是否是最佳或正确的方法,但它适用于我的用例。如果有更正或优化,请告诉我。

    谢谢!

    --- 性能更新

    我目前正在一个包含大约 700000 个文档和 2000000 条边的图表中进行测试。过滤条件根据用户在 web 应用程序中的选择动态添加到查询中,查询的性能很大程度上取决于添加的过滤条件。如果没有过滤器,或者过滤条件非常广泛,则查询可能需要一秒钟才能执行(在我们的测试硬件上)。如果过滤条件非常严格,则查询可以在几毫秒内执行。但是,默认和最常见的用例是用于较慢版本的查询。我只处理一小部分数据,我们预计文档和边缘的数量将增长到数百万,因此我们扩大规模时的性能非常值得关注。我目前已将数据库分割为多个图表,以尝试减少任何单个查询可以扫描的节点/边的范围和数量,但尚未确定我可以进行的其他优化以允许查询随着数据集的扩展而扩展。我们目前正在努力改进我们的数据导入基础架构以扩展数据集,但尚未完成这项工作,因此我还没有任何关于更能代表我们预期配置的数据库的性能数据。

    【讨论】:

    • 看起来不错,你有什么大小的数据集,你觉得它的性能好吗?
    • 我用性能细节更新了“答案”帖子,因为评论长度限制阻止了足够详细的响应。
    • 看看您是否可以使用db._explain() 来分解查询并可能向您展示索引可以帮助您的地方。目前无法在图表上放置索引,但您可能会发现文档集合中的索引会有所帮助。尤其是涵盖您的用户可能通过他们的自定义查询触发的键。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多