Elasticsearch

Elasticsearch 生产调优 📖 前置阅读：本文是 ES 系列的生产调优篇，假设读者已经掌握了 ES 核心概念、SpringBoot 操作和高级搜索聚合。如果还没有，建议先阅读前三篇： Elasticsearch 核心概念：倒排索引、分词器与 REST API 全解析 —— 介绍篇 SpringBoot Elasticsearch 全操作指南 —— 实战篇 ES 高级搜索与聚合分析 —— 进阶篇 一、⚡ 问题切入：搜索怎么越来越慢了？ 商品从 10 万增加到 500 万，搜索响应时间从原来的 50ms 涨到了 2 秒。用户开始投诉"搜索好慢"，产品经理开始质疑"ES 不是很快吗"。 你打开监控面板，发现： 搜索 P99 延迟 2.3 秒 ES 堆内存使用率 85% 磁盘 IO 等待时间飙升 GC 频率从每小时 2 次变成了每 5 分钟 1 次 问题出在哪？不一定是数据量大就一定慢。500 万数据对 ES 来说远没到上限——一个设计良好的 3 节点集群处理几亿数据都没问题。慢的往往是索引设计不合理、查询写得不高效、分页方式用错了。 本篇要解决的问题：怎么设计索引让 500 万数据搜索保持在 100ms 以内，以及遇到性能问题时从哪下手排查。 二、🗂️ 索引设计最佳实践 2.1 分片数设计 —— 不是越多越好 ES 把一个 Index 的数据切分成多个分片（Shard）分布在不同节点上。每个分片本质上是一个独立的 Lucene 实例——有自己的倒排索引、段文件、内存开销。 ...

ES 高级搜索 📖 前置阅读：本文是 ES 系列的进阶篇，假设读者已经掌握了 ES 核心概念（倒排索引、分词器、Mapping）和 SpringBoot 的基本操作。如果还没有，建议先阅读前两篇： Elasticsearch 核心概念：倒排索引、分词器与 REST API 全解析 —— 介绍篇 SpringBoot Elasticsearch 全操作指南 —— 实战篇 一、⚡ 问题切入：搜索结果不够准怎么办？ 前面两篇学完，你已经可以搭建一个"能搜"的商品搜索功能了。但用户搜"苹果手机"时，排名第一的可能是"苹果水果礼盒"——因为倒排索引中"苹果"这个词也出现了。 问题出在几个地方： 用户搜"苹果手机"时，商品名包含"苹果手机"这四个字的应该排在最前面，但基础 match 查询没有考虑字段匹配的完整度 商品标题命中的权重应该比描述命中的权重更高，但基础查询一视同仁 用户期望按销量和评分来影响排序，而不仅仅是文本相关性 输入"苹果手鸡"应该能自动纠错成"苹果手机" 本篇要解决的问题就是：怎么让搜索结果更准、排序更合理、用户体验更接近 Google 搜索。 二、🔍 全文搜索再深入 2.1 multi_match —— 多字段搜索 第一篇的 match 查询只搜一个字段。实际产品中，搜索词可能同时匹配商品名、品牌名、描述等多个字段——用户输入"华为手机"，应该既搜 name 也搜 description，甚至搜 brand。 multi_match 就是为此而生的。它有三种模式，差异在于多字段之间如何计算和合并相关性分数： flowchart LR classDef mode fill:#450a0a,stroke:#dc2626,stroke-width:1.5px,color:#fecaca,font-weight:bold; classDef field fill:#0f172a,stroke:#3b82f6,stroke-width:1.5px,color:#bfdbfe,font-weight:bold; MM[multi_match\n搜索苹果手机] MM --> BF[best_fields\n取最优字段的分数] MM --> MF[most_fields\n各字段分数累加] MM --> CF[cross_fields\n跨字段组合匹配] BF --> BF_EX["name=苹果手机 → 10分\ndescription=苹果... → 2分\n最终得分：10分"] MF --> MF_EX["name=苹果... → 5分\ndescription=手机... → 3分\n最终得分：8分"] CF --> CF_EX["name=苹果 + detail=手机\n作为一个整体匹配\n最终得分：匹配两个字段"] class BF,MF,CF mode; class BF_EX,MF_EX,CF_EX field; best_fields（默认模式）：搜索词在所有字段中分别执行匹配，取分数最高的那个字段作为最终得分。适合"搜索词大概率完整出现在某一个字段中"的场景——比如用户搜完整商品名。 ...

SpringBoot Elasticsearch 📖 前置阅读：本文假设读者已了解 ES 的倒排索引、分词器、Mapping 和 REST API 基础操作。如果还不熟悉，建议先阅读 Elasticsearch 核心概念：倒排索引、分词器与 REST API 全解析。 本文按照"先搞懂操作 → 教程版完整实现 → 生产版四种模式 → 验证排错“的顺序组织。如果你只想快速上手 ElasticsearchRestTemplate 的 CRUD 和搜索，读完 Part 1 后直接看 Part 2 即可；如果你想理解真实项目中 ES 是怎么承载搜索、同步、秒杀、推荐四种场景的，需要完整读完。 关于版本：Part 2 教程版使用 Spring Boot 3.x + 新版 ElasticsearchClient（spring-boot-starter-data-elasticsearch 自动配置）；Part 3 生产版使用 Spring Boot 2.7.x + RestHighLevelClient（手动创建 Bean）。两个版本不能混用——读者根据自己的 Spring Boot 版本选择对应的代码。 Part 1：先搞懂要做什么 一、目标说明 这篇文章的目标很明确：让读者在一篇文章内学会 SpringBoot 项目中所有常用的 ES 操作，读完就能直接写到项目里。 具体来说，读完这篇文章会掌握： 用 @Document 和 @Field 注解定义 ES 映射 用 ElasticsearchRestTemplate 执行 CRUD、搜索、聚合、高亮 用 Spring Data ES Repository 做声明式查询 批量写入、条件删除 和 真实场景串联 一个完整的"商品搜索"功能从零到一的完整代码 二、前置条件 前置项 具体要求 验证命令 JDK 17+（文中用 17，8+ 均兼容） java -version Maven 3.6+ mvn -v SpringBoot 3.x（文中用 3.2.0） mvn dependency:tree | grep spring-boot Elasticsearch 8.x（7.x 也兼容文中大部分操作，需调整配置） curl -u elastic http://localhost:9200 前置知识 SpringBoot 基础、ES 核心概念（倒排索引、分词器、Mapping） — Part 2：教程版 —— 从零掌握 ES 全部操作 下面每一节都给出了完整的、可运行的代码。整个教程版使用同一个技术栈：Spring Boot 3.x + spring-boot-starter-data-elasticsearch，通过 ElasticsearchRestTemplate 操作 ES。 ...

Elasticsearch 核心概念：倒排索引、分词器与 REST API 全解析 一、⚡ 问题切入：MySQL 模糊搜索为什么不行？ 先看一个日常开发中最常见的搜索场景。用户在电商平台的搜索框里输入"华为手机"，后端需要从商品表中查出匹配的商品。你第一反应肯定是写这样一条 SQL： SELECT * FROM product WHERE name LIKE '%华为手机%'; 这看起来没问题。但产品经理走过来跟你说：“搜索结果要把完全匹配的放在最前面，然后按销量排序，还要展示分类筛选和品牌聚合。“你看着手里的 SQL，表情逐渐僵硬。 MySQL LIKE '%keyword%' 有一个致命伤：前置通配符导致索引失效。B+Tree 索引遵循最左前缀匹配原则，% 一上来就破坏了索引的有序性，数据库只能全表扫描。500 万商品数据，一条 LIKE 查询耗时 3 秒以上——用户体验直接爆炸。 这不是加个索引能解决的问题。MySQL 是为精确匹配和范围查询设计的，不是为人类自然语言的模糊搜索设计的。用户不会输入精确的字段值，他们会打错字（“苹果手鸡”），用近义词（“笔记本” vs “笔记本电脑”），甚至用拼音（“huawei shouji”）。 全文搜索引擎就是为这个问题而生的。看一组实际数据： # MySQL LIKE：2.8 秒（500 万数据） mysql> SELECT * FROM product WHERE name LIKE '%华为手机%'; 500 rows in set (2.812 sec) # Elasticsearch match：0.015 秒（同量级数据，3 节点集群） GET /product/_search { "query": { "match": { "name": "华为手机" } } } # 返回：500 条结果，耗时 15ms，按相关性排序 接近 200 倍 的延迟差距。而且 ES 返回的结果自带相关性评分——包含"华为手机"这四个字且连在一起出现的商品分数最高，只包含"手机"的排在后面，只包含"华为"的更靠后。这就是 ES 作为搜索引擎存在的核心价值。 ...