ElasticSearch 6.3.2 150GB索引查询耗时15秒优化求助

查询语句优化 #

• 调整分页参数：你当前设置size: 2000，需要每个分片返回2000条结果，协调节点要对10000条结果做合并排序，开销极大。如果业务允许，优先把size调整到100以内；如果确实需要拉取大量数据，替换为scroll或者search_after方案，避免使用from+size做大深度分页。
• 替换精确匹配场景的查询类型：phoneNumber、dob、pinCode这类属于精确值匹配的字段，不要用match查询（会触发分词、相关性打分逻辑），替换为term查询，查询效率可提升数倍。
• 优化multi_match逻辑：你当前两个multi_match都需要遍历6个字段的倒排索引，开销较高。可以在索引构建阶段新增一个合并字段，把field1~field6的内容都拷贝到该字段中，查询时直接查询单个合并字段即可，减少多字段检索的计算量。也可根据业务匹配需求，明确指定multi_match的type参数（如best_fields/most_fields），避免默认规则的额外开销。
• 关闭不必要的相关性打分：当前查询如果不需要按相关性排序，可在查询外层包constant_score，或者设置boost: 0，同时明确指定minimum_should_match: 1，跳过打分计算环节，可大幅降低CPU占用，避免影响其他查询运行。

字段映射优化 #

• 调整精确值字段的类型：phoneNumber、dob、pinCode这类字段统一设置为keyword类型，不要使用text类型，避免不必要的分词存储和检索开销。如果当前字段已经是text类型，可新增keyword子字段，查询时指定查询子字段即可。
• 关闭非检索字段的索引：所有不需要参与检索的字段，在映射中设置index: false，减少索引体积，提升检索效率。

集群与硬件优化 #

• 调整分片规格：当前150G数据分5个分片，单分片大小约30G，可将分片数调整为8~10个，将单分片大小控制在20G以内，提升查询并发能力。同时尽量保证分片均匀分布在不同的数据节点上，避免单点压力过大。
• 优化内存配置：给ES节点分配的堆内存建议为服务器物理内存的50%，最大不超过31G，剩余内存留给系统做文件系统缓存，尽量将索引文件缓存到内存中，避免磁盘IO成为瓶颈。
• 替换存储介质：如果当前使用机械磁盘，替换为SSD磁盘，随机读写性能提升明显，可大幅降低查询的IO耗时。

缓存优化 #

• 开启ES请求缓存：在查询请求中添加request_cache: true参数，或者在索引配置中开启请求缓存，重复度较高的查询可直接命中缓存返回结果，无需重新计算。
• 新增应用层缓存：对于查询频率较高的请求，可以在应用层用Redis做结果缓存，设置合理的过期时间，直接从缓存返回结果，大幅降低ES的查询压力。

内容的提问来源于stack exchange，提问作者Aditya Goel