术语聚合（实现分层刻面）查询性能缓慢

Question

我是在弹性搜索中对指标名称建立索引。度量名称的格式为foo.bar.baz.aux。这是我使用的索引。

{ 
    "index": { 
     "analysis": { 
      "analyzer": { 
       "prefix-test-analyzer": { 
        "filter": "dotted", 
        "tokenizer": "prefix-test-tokenizer", 
        "type": "custom" 
       } 
      }, 
      "filter": { 
       "dotted": { 
        "patterns": [ 
         "([^.]+)" 
        ], 
        "type": "pattern_capture" 
       } 
      }, 
      "tokenizer": { 
       "prefix-test-tokenizer": { 
        "delimiter": ".", 
        "type": "path_hierarchy" 
       } 
      } 
     } 
    } 
} 

{ 
    "metrics": { 
     "_routing": { 
      "required": true 
     }, 
     "properties": { 
      "tenantId": { 
       "type": "string", 
       "index": "not_analyzed" 
      }, 
      "unit": { 
       "type": "string", 
       "index": "not_analyzed" 
      }, 
      "metric_name": { 
       "index_analyzer": "prefix-test-analyzer", 
       "search_analyzer": "keyword", 
       "type": "string" 
      } 
     } 
    } 
} 

上述指标的度量标准名称创建下列条款foo.bar.baz

foo 
bar 
baz 
foo.bar 
foo.bar.baz 

如果我有一堆指标，像下面

a.b.c.d.e 
a.b.c.d 
a.b.m.n 
x.y.z 

我要编写一个查询抢令牌的第n级。在上面的例子中

for level = 0, I should get [a, x] 
for level = 1, with 'a' as first token I should get [b] 
       with 'x' as first token I should get [y] 
for level = 2, with 'a.b' as first token I should get [c, m] 

我想不出任何其他方式，除了写术语聚合。要找出a.b的二级令牌，下面是我提出的查询。

time curl -XGET http://localhost:9200/metrics_alias/metrics/_search\?pretty\&routing\=12345 -d '{ 
     "size": 0, 
     "query": { 
     "term": { 
      "tenantId": "12345" 
     } 
     }, 
     "aggs": { 
      "metric_name_tokens": { 
       "terms": { 
        "field" : "metric_name", 
        "include": "a[.]b[.][^.]*", 
        "execution_hint": "map", 
        "size": 0 
       } 
      } 
     } 
    }' 

这会导致下面的问题。我解析输出并从那里抓取[c，m]。

"buckets" : [ { 
    "key" : "a.b.c", 
    "doc_count" : 2 
    }, { 
    "key" : "a.b.m", 
    "doc_count" : 1 
} ] 

到目前为止好。该查询适用于大多数租户（请注意上面的tenantIdterm查询）。对于有大量数据（大约1Million）的某些租户来说，表现确实很慢。我猜测聚合的所有术语都需要时间。

我想知道术语聚合是否是这种数据的正确选择，并且还在寻找其他可能的查询类型。

Answer 1

几点建议：

• “镜子”的聚合过滤器在查询部分水平以及。因此，对于a.b.匹配，请使用下列为查询并保持相同的AGGS部分：

"bool": { 
    "must": [ 
    { 
     "term": { 
     "tenantId": 123 
     } 
    }, 
    { 
     "prefix": { 
     "metric_name": { 
      "value": "a.b." 
     } 
     } 
    } 
    ] 
} 

甚至使用regexp具有相同的正则表达式作为凝聚部。通过这种方式，聚合将不得不评估较少的桶，因为到达聚合部分的文档将更少。 你提到regexp对你来说效果更好，我最初的猜测是prefix会表现更好。

• 将"size": 0从聚合变为"size": 100。经过测试你提到这没有任何区别
• 删除"execution_hint": "map"并让Elasticsearch使用默认值。经过测试，你提到默认的execution_hint表现更差。
• 我唯一能想到的其他事情就是通过在索引时移动它来减轻搜索时间的压力。我的意思是：在索引时，在你自己的应用程序或者你正在使用的任何索引方法中，将文本分割为程序化索引（而不是ES），并将索引中的每个元素索引到一个单独的字段中。例如a.b在field2,a.b.c在field3等等。这对于同一个文件。然后，在搜索时间，根据搜索文本的内容查看特定字段。然而，这个想法在ES之外需要一些额外的工作。

从以上所有建议中，第一个建议的影响最大：查询响应时间从23秒提高到了11秒。