好的，我们开始今天的讲座，主题是Elasticsearch查询吞吐骤降的慢查询定位与字段建模优化实践。
引言：查询吞吐骤降与慢查询的噩梦
Elasticsearch作为一个强大的分布式搜索和分析引擎，在现代应用中扮演着至关重要的角色。然而，随着数据量的增长和查询复杂度的提升，我们经常会遇到查询吞吐骤降和慢查询的问题。这不仅会影响用户体验，还会对整个系统的稳定性造成威胁。因此，掌握定位慢查询、分析瓶颈并进行优化，对于保障Elasticsearch集群的健康运行至关重要。
第一部分：慢查询定位与分析
定位慢查询是解决问题的首要步骤。Elasticsearch提供了多种工具和方法来帮助我们找到那些耗时的查询。
1.1 Elasticsearch慢查询日志
Elasticsearch的慢查询日志是最直接的慢查询定位手段。我们需要先启用慢查询日志功能，然后才能记录慢查询。
-
配置慢查询日志：
在
elasticsearch.yml配置文件中，我们可以设置慢查询日志的阈值。例如：index.search.slowlog.threshold.query.warn: 10s index.search.slowlog.threshold.query.info: 5s index.search.slowlog.threshold.query.debug: 2s index.search.slowlog.threshold.query.trace: 500ms index.search.slowlog.threshold.fetch.warn: 1s index.search.slowlog.threshold.fetch.info: 800ms index.search.slowlog.threshold.fetch.debug: 500ms index.search.slowlog.threshold.fetch.trace: 100ms这些配置项分别对应不同级别的日志阈值，当查询时间超过设定的阈值时，相应的日志信息就会被记录。
query对应查询阶段，fetch对应数据获取阶段。 -
动态更新慢查询日志配置：
我们也可以通过API动态更新慢查询日志的配置，而无需重启Elasticsearch节点。
PUT /your_index/_settings { "index.search.slowlog.threshold.query.warn": "5s", "index.search.slowlog.threshold.query.info": "2s", "index.search.slowlog.threshold.query.debug": "1s", "index.search.slowlog.threshold.query.trace": "500ms" } -
分析慢查询日志：
慢查询日志的格式通常包含查询语句、查询耗时、查询类型等信息。通过分析这些信息，我们可以初步判断慢查询的原因。日志文件通常位于
config/jvm.options配置的ES_LOG_DIR目录下。例如：[2023-10-27T10:00:00,000][WARN ][index.search.slowlog.query] [node-1] [your_index][0] took[10.5s], took_millis[10500], types[], stats[], search_type[QUERY_THEN_FETCH], total_shards[5], source[{"query":{"match":{"your_field":"your_value"}}}]这个日志表明，对
your_index索引的查询，花费了10.5秒，查询语句是{"query":{"match":{"your_field":"your_value"}}}。
1.2 Elasticsearch Profiler API
除了慢查询日志，Elasticsearch还提供了Profiler API，可以更详细地分析查询的执行过程，包括每个阶段的耗时、使用的索引、以及相关的资源消耗。
-
使用Profiler API：
在执行查询时，我们可以添加
profile=true参数来启用Profiler API。GET /your_index/_search?profile=true { "query": { "match": { "your_field": "your_value" } } } -
分析Profiler结果：
Profiler的返回结果包含非常详细的查询执行信息，例如：
{ "took": 15, "timed_out": false, "_shards": { "total": 5, "successful": 5, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 1, "relation": "eq" }, "max_score": 1.0, "hits": [ { "_index": "your_index", "_type": "_doc", "_id": "1", "_score": 1.0, "_source": { "your_field": "your_value" } } ] }, "profile": { "shards": [ { "id": "[node-1][your_index][0]", "searches": [ { "query": [ { "type": "MatchQuery", "description": "your_field:your_value", "time_in_nanos": 1234567, "breakdown": { "score": 123456, "build_scorer": 789012, "create_weight": 345678, "match": 567890 } } ], "collector": [ { "name": "SimpleTopScoreCollector", "reason": "search_top_hits", "time_in_nanos": 456789 } ] } ] } ] } }通过分析
profile.shards[].searches[].query和profile.shards[].searches[].collector部分，我们可以找到查询中最耗时的环节。例如，time_in_nanos表示该阶段的耗时，breakdown则提供了更细粒度的耗时分解。
1.3 Elasticsearch Task API
Task API可以用来监控正在执行的查询任务，并获取任务的详细信息。这对于发现长时间运行的查询非常有用。
-
使用Task API：
我们可以使用
_tasksAPI来列出当前正在运行的任务。GET /_tasks?detailed=true&actions=search -
分析Task信息：
Task API的返回结果包含任务的ID、类型、开始时间、以及执行状态等信息。通过监控任务的执行状态，我们可以及时发现并终止长时间运行的查询。
1.4 常用诊断工具
除了Elasticsearch内置的工具，还有一些常用的诊断工具可以帮助我们定位慢查询。
-
Grafana + Prometheus：
使用Grafana和Prometheus可以监控Elasticsearch的各项指标，例如CPU利用率、内存使用率、磁盘I/O等。通过监控这些指标，我们可以发现集群的性能瓶颈。
-
APM工具：
使用APM（Application Performance Monitoring）工具，例如Elastic APM、Pinpoint等，可以追踪查询的整个调用链，并分析每个环节的耗时。
第二部分：字段建模优化
找到慢查询之后，下一步就是分析慢查询的原因，并进行相应的优化。字段建模是影响查询性能的关键因素之一。合理的字段建模可以提高查询效率，降低资源消耗。
2.1 选择合适的数据类型
选择合适的数据类型是字段建模的基础。不同的数据类型在存储空间和查询效率上都有所差异。
| 数据类型 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
keyword |
精确匹配、排序、聚合。例如：用户名、商品ID、状态码等。 | 节省存储空间，查询效率高。 | 不支持分词，无法进行模糊查询。 |
text |
需要分词的文本内容。例如：文章内容、商品描述等。 | 支持分词，可以进行模糊查询。 | 占用存储空间较大，查询效率相对较低。 |
integer |
整数类型。例如：年龄、数量等。 | 节省存储空间，查询效率高。 | 只能存储整数。 |
long |
长整数类型。例如：时间戳、ID等。 | 可以存储更大的整数。 | 占用存储空间较大。 |
float |
浮点数类型。例如：价格、评分等。 | 可以存储小数。 | 精度有限，可能存在舍入误差。 |
double |
双精度浮点数类型。例如：地理坐标等。 | 精度更高。 | 占用存储空间更大。 |
boolean |
布尔类型。例如：是否启用、是否删除等。 | 节省存储空间，查询效率高。 | 只能存储true或false。 |
date |
日期类型。例如：创建时间、更新时间等。 | 支持日期格式化、范围查询等。 | 需要进行日期格式转换。 |
geo_point |
地理坐标类型。例如：经纬度。 | 支持地理位置查询、距离计算等。 | 需要进行地理位置索引。 |
nested |
嵌套对象类型。用于存储复杂对象数组。 | 可以存储复杂的数据结构，支持对嵌套对象进行查询。 | 查询效率相对较低。 |
object |
对象类型。用于存储单个复杂对象。 | 可以存储复杂的数据结构。 | 不支持对对象内部字段进行独立查询。 |
2.2 避免过度索引
虽然索引可以提高查询效率，但过多的索引会增加存储空间，降低写入性能，并可能导致查询性能下降。因此，我们需要避免过度索引。
-
只对需要查询的字段建立索引：
对于不需要进行查询的字段，可以将其
index属性设置为false。{ "mappings": { "properties": { "your_field": { "type": "text", "index": true }, "unindexed_field": { "type": "text", "index": false } } } } -
使用
_sourcefiltering：对于不需要返回的字段，可以在查询时使用
_sourcefiltering来排除这些字段，减少网络传输和客户端的解析开销。GET /your_index/_search { "_source": ["your_field1", "your_field2"], "query": { "match": { "your_field": "your_value" } } } -
谨慎使用动态mapping：
动态mapping虽然方便，但可能会导致字段类型不符合预期，从而影响查询性能。建议显式地定义mapping，避免动态mapping带来的问题。
2.3 选择合适的分词器
分词器是文本分析的关键组件。不同的分词器在分词效果和查询效率上都有所差异。
-
standard分词器：Elasticsearch默认的分词器，适用于英文文本。
-
ik_max_word分词器：常用的中文分词器，会将文本拆分成最细粒度的词语。
-
ik_smart分词器：另一种中文分词器，会进行智能分词，保留更少的词语。
-
自定义分词器：
可以根据实际需求，自定义分词器。
PUT /your_index { "settings": { "analysis": { "analyzer": { "your_analyzer": { "type": "custom", "tokenizer": "ik_max_word", "filter": [ "lowercase", "stop" ] } } } }, "mappings": { "properties": { "your_field": { "type": "text", "analyzer": "your_analyzer" } } } }
2.4 使用Keyword类型进行聚合和排序
对于需要进行聚合和排序的字段，建议使用keyword类型。keyword类型不会进行分词，可以提高聚合和排序的效率。
2.5 Nested Object优化
Nested Object 用于存储复杂对象的数组，查询效率相对较低，优化Nested Object的查询至关重要。
-
避免过度使用Nested Object：
尽量将Nested Object拆分成独立的文档，或者使用Denormalization的方式将数据冗余到父文档中。
-
使用Nested Query：
使用Nested Query可以对Nested Object进行精确查询。
GET /your_index/_search { "query": { "nested": { "path": "your_nested_object", "query": { "match": { "your_nested_object.your_field": "your_value" } } } } } -
使用Inner Hits：
使用Inner Hits可以返回匹配的Nested Object。
GET /your_index/_search { "query": { "nested": { "path": "your_nested_object", "query": { "match": { "your_nested_object.your_field": "your_value" } }, "inner_hits": {} } } }
2.6 使用Doc Values
Doc Values是一种列式存储结构，可以提高聚合和排序的效率。默认情况下，大部分字段类型都会启用Doc Values。对于不需要进行聚合和排序的字段，可以禁用Doc Values。
{
"mappings": {
"properties": {
"your_field": {
"type": "keyword",
"doc_values": false
}
}
}
}第三部分：查询优化
除了字段建模，查询语句的编写也会影响查询性能。以下是一些常用的查询优化技巧。
3.1 避免使用script查询
script查询会将查询逻辑放在脚本中执行，性能较低。尽量使用Elasticsearch内置的查询方式。
3.2 使用filter context
filter context不会计算文档的相关性得分，可以提高查询效率。对于不需要计算相关性得分的查询，建议使用filter context。
GET /your_index/_search
{
"query": {
"bool": {
"filter": {
"term": {
"your_field": "your_value"
}
}
}
}
}3.3 限制查询范围
尽量缩小查询范围，减少需要扫描的文档数量。例如，可以使用时间范围查询、地理位置范围查询等。
3.4 使用routing
routing可以将相关的文档路由到同一个分片上，提高查询效率。
PUT /your_index/_doc/1?routing=your_routing_value
{
"your_field": "your_value"
}
GET /your_index/_search?routing=your_routing_value
{
"query": {
"match": {
"your_field": "your_value"
}
}
}3.5 使用pre_filter_shard_size
pre_filter_shard_size参数可以控制在哪些分片上执行查询。当查询条件只与部分分片相关时，可以使用pre_filter_shard_size来减少需要扫描的分片数量。
3.6 调整refresh_interval
refresh_interval参数控制索引的刷新频率。降低refresh_interval可以提高写入性能，但会降低查询的实时性。
3.7 避免深度分页
深度分页会导致Elasticsearch扫描大量的文档，性能较低。建议使用scroll API或search_after API来进行深度分页。
3.8 使用缓存
Elasticsearch提供了多种缓存机制，例如：
-
Node Query Cache：
缓存查询结果。
-
Shard Request Cache：
缓存分片级别的查询结果。
-
Field Data Cache：
缓存字段数据。
合理利用缓存可以提高查询效率。
第四部分：硬件与集群配置优化
除了软件层面的优化，硬件和集群配置也会影响查询性能。
-
选择合适的硬件：
-
CPU：
选择多核CPU，提高并发处理能力。
-
内存：
分配足够的内存，避免频繁的磁盘I/O。
-
磁盘：
使用SSD，提高读写速度。
-
网络：
使用高速网络，减少网络延迟。
-
-
合理的集群配置：
-
分片数量：
合理设置分片数量，提高查询的并发度。
-
副本数量：
合理设置副本数量，提高查询的可用性和容错性。
-
节点角色：
合理分配节点角色，例如Master节点、Data节点、Ingest节点等。
-
JVM参数：
合理设置JVM参数，例如堆大小、垃圾回收算法等。
-
第五部分：持续监控与优化
优化是一个持续的过程。我们需要持续监控Elasticsearch的性能，并根据实际情况进行调整。
-
监控关键指标：
-
查询吞吐量：
每秒查询次数。
-
查询延迟：
查询的平均耗时。
-
CPU利用率：
CPU的使用情况。
-
内存使用率：
内存的使用情况。
-
磁盘I/O：
磁盘的读写速度。
-
-
定期进行性能测试：
模拟真实场景，进行性能测试，发现潜在的问题。
-
及时更新Elasticsearch版本：
新版本通常会包含性能优化和Bug修复。
字段建模优化和集群配置调整确保性能稳定
字段建模优化、查询语句优化、硬件和集群配置优化等多个方面入手，可以有效地提高Elasticsearch的查询吞吐量，降低查询延迟，保障系统的稳定运行。
持续监控和版本更新保证系统长期健康
持续监控Elasticsearch的性能指标，并根据实际情况进行调整，及时更新Elasticsearch版本，是保障系统长期健康运行的关键。