elastic search 调优实战（二）

简单说两句

话接上回，前面从系统配置，索引字段选择对es 进行了调优，下面我针对一些常见的问题针对性的提出一些解决方案。抛转引玉，希望能帮助大家

1.es 数据太多了，应该怎么调优？

es 作为一个使用非常广泛的搜索引擎，一般是查询很快的，但是如果单个索引数据量太大，比如几百g，几个t,还是会拖慢搜索的。针对这种场景，可以采用以下方案

1.1 增加分片副本数，增加es 节点

es 一个索引可以被分成多个分片，每个分片分布在不同的es 节点上，这样可以减少每个节点的压力，提升查询效率。本来一个人干的事情，现在交给3个人干，当然效率提升了。

  "settings": {
    "number_of_shards" : 1,
    "number_of_replicas" : 0
  }

1.2 索引拆分成多个，使用别名搜索

es 支持别名进行关联索引查询，这样也可以减少每个索引的大小，比如订单按月拆分 order-2023-10 order-2023-09 order-2023-08 三个索引使用order- 这个别名关联查询。

    "aliases": {
      "order-": {}
    }

1.3 冷热分离

对于不常用的索引，可以把不常用的索引设置为冷数据，也可以减少资源占用，提升查询效率

PUT _ilm/policy/cold_data_policy
{
  "policy": {
    "phases": {
      "cold": {
        "actions": {
          "freeze": {}
        }
      }
    }
  }
}

PUT your_index/_settings
{
  "index": {
    "lifecycle": {
      "name": "cold_data_policy",
      "rollover_alias": "your_index"
    }
  }
}

今天的分享先到这里了，后面的文章再分享一下es查询方面的优化.

喜欢我的话，可以给我点个赞呀。

2.es查询慢，如何排查问题？

2.1 使用searchProfile 查看执行计划

kibana 界面如下，可以看到每个步骤的执行时间，定位到执行比较慢的地方，进行调优

2.2 使用慢查询日志，定位慢查询

配置慢日志记录：打开Elasticsearch配置文件（elasticsearch.yml）并找到以下配置项：

# 慢日志的阈值，默认为10s
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: 200ms

index.indexing.slowlog.threshold.index.warn: 10s
index.indexing.slowlog.threshold.index.info: 5s
index.indexing.slowlog.threshold.index.debug: 2s
index.indexing.slowlog.threshold.index.trace: 500ms

# 慢日志的输出位置，默认为elasticsearch/logs下的相应文件
index.search.slowlog.level: info
index.indexing.slowlog.level: info

可以使用日志查看工具（如tail命令）来实时监控慢日志。例如，使用以下命令查看慢查询日志：

tail -f elasticsearch/logs/_index_search_slowlog.log

2.2 使用metricbeat 监控es 运行情况

metricbeat 是es 官方提供的一个监控工具，是一个开源的轻量级数据收集器，用于从各种不同的系统和服务中收集指标数据。它是Elasticsearch生态系统中的一个组件，旨在提供实时的系统和服务监控。

Metricbeat可以监控各种不同的资源，包括操作系统、容器、数据库、Web服务器、消息队列等。它通过使用不同的模块来收集特定资源的指标数据，这些模块被称为Metricbeat模块。每个模块都有专门的收集器，用于从相应的资源中提取指标数据。

这是我配置好后的界面，可以很直观的了解到es集群的运行情况

3.大数据量的情况下，改怎么查询？

3.1 Scroll

Scroll API允许您在持续的时间段内从Elasticsearch中检索大量数据。它通过在初始搜索请求中设置一个保持活动状态的游标来工作。然后，您可以使用这个游标来连续检索更多的结果，直到满足您的需求为止。Scroll API适用于需要处理大量数据的情况，例如导出数据或批量处理数据。

response = es.scroll(scroll_id=scroll_id, scroll="1m")

3.2 Search After

Search After是一种基于游标的分页查询方法，它使用上一次查询的最后一个结果作为下一次查询的起点。您可以使用排序字段和排序顺序来确定查询的起点。与Scroll不同，Search After不需要保持活动状态的游标，并且可以在多个请求之间进行并行处理。Search After适用于需要分页查询大量数据的情况，例如在Web应用程序中显示结果。

sourceBuilder.query(boolQueryBuilder);
sourceBuilder.size(10000);
if (id != 0) {
    sourceBuilder.searchAfter(new Object[]{id});
}

4.语法太难记，能否像用mysql 那样查询es？

可以的，es 现在是支持sql 语法的，常用的 排序 分组 条件都支持，语法和mysql 差不多。下面一个sql 可以参考一下

POST /_sql?format=txt
{
  "query": "SELECT item_no,item_name_zht,count(*) FROM order_item where item_no is not null and item_no !='' GROUP BY item_no,item_name_zht LIMIT 10"
}

5.es 客户端偶尔报timeout 该怎么解决？

es经常报超时timeout ，可能是连接问题，尝试增加下面配置，给连接设置一个有效期，有效期过了之后，再重新创建连接，默认的连接是永久的，但是可能因为长时间没有访问，防火墙或者服务端断开连接，客户端不知道，继续用原来的连接访问。

httpClientBuilder.setKeepAliveStrategy((response, context) -> TimeUnit.MINUTES.toMillis(esropertyVo.getKeepAliveStrategy()));

6.把数据库数据同步到es ,有哪些方案

6.1定时同步

logstash datax 等工具定时读取数据，写入es，优点是比较简单，缺点是只能查到最新的数据，历史变更记录无法查到。删除的数据也不太好处理。

6.2实时同步

可以读取 数据库log 写入es,常用的有 canal ogg flinkcdc 等等。优点是可以回放所有的数据变更动作，缺点是需要依赖的工具比较多。

6.3双写

业务在操作数据库的方式，可以再同时写入es,异步或者同步的方式都行，优点是比较快，缺点是耦合度比较高。

今天的分享先到这里了，谢谢大家的观看

喜欢我的话，可以给我点个赞呀。