Question

我们正在评估平面计算空间中的ArangoDB性能。有许多其他产品可以通过特殊的API或查询语言来做同样的事情：

MarkLogic Facets
ElasticSearch Aggregations
Solr Faceting等

我们知道，Arango中没有特殊的API可以明确地计算出来。但实际上，它不是必需的，多亏了全面的AQL，它可以通过简单的查询轻松实现，如：

 FOR a in Asset 
  COLLECT attr = a.attribute1 INTO g
 RETURN { value: attr, count: length(g) }

此查询计算attribute1上的facet并以以下形式生成频率：

[
  {
    "value": "test-attr1-1",
    "count": 2000000
  },
  {
    "value": "test-attr1-2",
    "count": 2000000
  },
  {
    "value": "test-attr1-3",
    "count": 3000000
  }
]

据说，在我的整个集合中，attribute1采用了三种形式（test-attr1-1，test-attr1-2和test-attr1-3）并提供了相关的计数。几乎我们运行DISTINCT查询和聚合计数。

看起来简单干净。只有一个，但真正重要的问题 - 性能。

上面提供的查询运行时间为31秒！仅在8M文档的测试集合之上。我们已经尝试了不同的索引类型，存储引擎（使用rocksdb和没有），调查解释计划无济于事。我们在此测试中使用的测试文档非常简洁，只有三个短属性。

我们希望此时有任何意见。要么我们做错了什么。或者ArangoDB根本不适合在这个特定领域执行。

顺便说一句，最终目标是在不到一秒的时间内运行类似下面的内容：

LET docs = (FOR a IN Asset 

  FILTER a.name like 'test-asset-%'

  SORT a.name

 RETURN a)

LET attribute1 = (

 FOR a in docs 

  COLLECT attr = a.attribute1 INTO g

 RETURN { value: attr, count: length(g[*])}

)

LET attribute2 = (

 FOR a in docs 

  COLLECT attr = a.attribute2 INTO g

 RETURN { value: attr, count: length(g[*])}

)

LET attribute3 = (

 FOR a in docs 

  COLLECT attr = a.attribute3 INTO g

 RETURN { value: attr, count: length(g[*])}

)

LET attribute4 = (

 FOR a in docs 

  COLLECT attr = a.attribute4 INTO g

 RETURN { value: attr, count: length(g[*])}

)

RETURN {

  counts: (RETURN {

    total: LENGTH(docs), 

    offset: 2, 

    to: 4, 

    facets: {

      attribute1: {

        from: 0, 

        to: 5,

        total: LENGTH(attribute1)

      },

      attribute2: {

        from: 5, 

        to: 10,

        total: LENGTH(attribute2)

      },

      attribute3: {

        from: 0, 

        to: 1000,

        total: LENGTH(attribute3)

      },

      attribute4: {

        from: 0, 

        to: 1000,

        total: LENGTH(attribute4)

      }

    }

  }),

  items: (FOR a IN docs LIMIT 2, 4 RETURN {id: a._id, name: a.name}),

  facets: {

    attribute1: (FOR a in attribute1 SORT a.count LIMIT 0, 5 return a),

    attribute2: (FOR a in attribute2 SORT a.value LIMIT 5, 10 return a),

    attribute3: (FOR a in attribute3 LIMIT 0, 1000 return a),

    attribute4: (FOR a in attribute4 SORT a.count, a.value LIMIT 0, 1000 return a)

   }

}

谢谢！

Answer 1

原来在ArangoDB Google Group上发生了主线程。这是link to a full discussion

以下是当前解决方案的摘要：

从特定功能分支运行Arango的自定义构建，其中已经完成了许多性能改进（希望它们能够很快进入主要版本）。
构面计算不需要索引
MMFiles是首选的存储引擎
应该编写AQL以使用“COLLECT attr = a.attributeX WITH COUNT INTO length”而不是“count：length（g）”
AQL应该分成更小的部分并且并行运行（我们运行Java8的Fork / Join来传播face AQL然后将它们加入到最终结果中）
一个用于过滤/排序和检索主要实体的AQL（如果需要，在排序/过滤时添加相应的跳转列表索引）
其余是每个方面值/频率对的小AQL

与上面提供的原始AQL相比，最终我们获得了＆gt; 10x 的性能提升。

ArangoDB分面搜索性能

1 个答案: