analytic-search外掛程式是Elasticsearch團隊自主開發的日誌情境檢索外掛程式,提供Kibana Discover查詢加速和查詢並發兩項功能,適用於日誌檢索和分析情境。
使用須知
analytic-search外掛程式為系統預設外掛程式,預設已安裝且不可卸載,可在外掛程式配置頁面查看。使用該外掛程式需要執行個體版本為7.10.0,核心版本為1.7.0及以上。
Kibana Discover查詢加速
通過最佳化索引合并策略及Date_histogram執行計畫策略,在沒有查詢條件或僅有一個查詢條件時,大幅降低查詢耗時。適用於日誌檢索情境,例如Kibana Discover中的無條件或單條件查詢。
效能參考
測試環境:10 * 16核64 GB節點。某業務日誌資料,一天600億個文檔,分成12個索引,每個索引60個分區。
查詢條件 | SSD雲端硬碟 | 高效雲端硬碟 | OpenStore儲存 |
沒有查詢條件 | 耗時降低96% | 耗時降低95% | 耗時降低94% |
一個查詢條件 | 耗時降低88% | 耗時降低77% | 耗時降低85% |
多個查詢條件 | 耗時降低8% | 耗時降低11% | 耗時降低14% |
開啟Kibana Discover查詢加速
建立索引時,在settings中配置index.sort按時間戳記欄位降序排列。以下樣本僅供參考,實際使用時需按照業務欄位名稱調整時間戳記欄位名和排序。
PUT test_log
{
"settings": {
"index.points.same_sort_order_as_index_sort": true,
"index.sort.field": [
"@timestamp"
],
"index.sort.order": [
"desc"
]
},
"mappings": {
"properties": {
"@timestamp": {
"type": "date"
}
}
}
}查詢並發功能
通過實現召回過程的並發,提高資源使用率,召回階段平均耗時降低50%。適用於查詢QPS低、查詢召回階段耗時高、節點計算資源充足的情境。
效能參考
測試環境:3 * 16核64 GB OpenStore冷熱共用計算型節點。某業務日誌資料,單索引1.6 TB,60億個文檔,60個分區。查詢條件為3個TermQuery(and) + TimeRange + Sort + Datehistogram,單shard命中1000w(命中率10%)。
測試結果:
單shard查詢耗時降低65%。
多shard查詢耗時降低53%。
開啟查詢並發
執行以下命令開啟查詢並發功能:
PUT _cluster/settings
{
"persistent": {
"apack.analytic_search.doc_concurrency.enabled": "true"
}
}開啟後,新接收到的查詢任務將按預設的並發策略執行。可通過以下參數調整並發行為。
叢集層級配置
參數 | 預設值 | 說明 |
apack.analytic_search.doc_concurrency.enabled | false | 是否開啟查詢並發功能:true(開啟)或false(不開啟)。 |
apack.analytic_search.doc_concurrency.concurrent.policy | 80%:4;90%:2 | 查詢並發策略,格式為 |
apack.analytic_search.doc_concurrency.min_support_doc | 10000 | 使用查詢並發的索引的最少文檔數,低於該值則不使用查詢並發。 |
apack.analytic_search.doc_concurrency.min_support_processors | 4 | 使用查詢並發的節點的最少核心數,低於該值則不使用查詢並發。 |
apack.analytic_search.doc_concurrency.max_support_heap_usage | 80% | 使用查詢並發的節點的最高JVM heap使用率,高於該值則不使用查詢並發。 |
apack.analytic_search.doc_concurrency.max_support_cpu_usage | 90 | 使用查詢並發的節點的最高CPU使用率,值為整數表示百分比,高於該值則不使用查詢並發。 |
索引層級配置
參數 | 預設值 | 說明 |
index.apack.analytic_search.doc_concurrency.enabled | true | 是否對該索引開啟查詢並發功能:true(開啟)或false(不開啟)。 |