分析查询和聚合

Elasticsearch具有强大的分析器API,可用于检查和分析你的搜索查询,然而,响应是一个非常大的JSON blob,很难手工分析。

X-Pack包含Search Profiler工具,可以将此JSON输出转换为易于导航的可视化,使你能够更快地诊断和调试性能较差的查询。

overview.png

入门

在Kibana中自动启用搜索概要分析器,它位于Kibana的Dev Tools选项卡下。

要开始分析查询:

  1. 在Web浏览器中打开Kibana并登录,如果你在本地运行Kibana,请转到http://localhost:5601/
  2. 单击侧面导航中的DevTools以打开Search ProfilerConsole是首次访问DevTools时打开的默认工具。
    gs1.png
    在顶部导航栏上,单击第二项:Search Profiler
    gs2.png
  3. 这将打开Search Profiler界面。
    gs3.png
  4. 将默认的match_all查询替换为你要分析的查询,然后单击Profile
    gs4.png
    Search Profiler显示搜索的索引的名称,每个索引中的分片以及查询所花费的时间,以下示例显示了对match_all查询进行概要分析的结果,搜索了三个索引:.monitoring-kibana-2-2016.11.30.monitoring-data-2test

    如果我们仔细查看测试索引的信息,我们可以从累积时间看到查询花了0.132ms来执行,在索引中的五个碎片中(DWZD0iosQNeJMTvb4q1JDw 0到5),碎片3是最慢的(0.053ms),其次是碎片2(0.038ms),碎片按时间降序排序。

    gs5.png

    Cumulative Time指标是各个分片时间的总和,它不一定是查询返回的实际时间(挂钟时间),由于可能在多个节点上并行处理分片,因此挂钟时间可能远远小于累积时间,但是,如果碎片在同一节点上并置并串行执行,则挂钟时间更接近累积时间。

    虽然Cumulative Time指标对于比较索引和碎片的性能很有用,但它并不一定代表实际的物理查询时间。

  5. 要查看碎片的更详细分析信息,请单击“展开”按钮,这将显示有关在碎片上运行的查询组件的详细信息。

    在此示例中,在碎片上运行了一个“MatchAllDocsQuery”,由于它是唯一的查询运行,因此它占用了100%的时间,当你将鼠标悬停在一行上时,“搜索概要分析器”会显示有关查询组件的其他信息。

    gs6.png

    该面板显示了低级Lucene方法的时序细分,有关更多信息,请参阅时序细分的参考文档。

分析更复杂的查询

要了解查询树在搜索概要分析器中的显示方式,让我们看一个更复杂的查询。

  1. 索引以下数据:

    POST test/test/_bulk
    {"index":{}}
    {"name":"aaron","age":23,"hair":"brown"}
    {"index":{}}
    {"name":"sue","age":19,"hair":"red"}
    {"index":{}}
    {"name":"sally","age":19,"hair":"blonde"}
    {"index":{}}
    {"name":"george","age":19,"hair":"blonde"}
    {"index":{}}
    {"name":"fred","age":69,"hair":"blonde"}
  2. 在查询编辑器上方的索引过滤器中输入"test"(带有灰色_all的输入框),这会将分析查询限制为test索引。
    gs7.png

博弈
2.5k 声望1.5k 粉丝

态度决定一切