Elasticsearch 入门

1. 一句话简介

Elasticsearch（简称 ES）是一个基于 Lucene 构建的分布式、RESTful 风格的全文检索引擎，用 JSON 文档存储数据，对外提供近实时的搜索、分析和聚合能力。它把数据按「索引（Index）、类型（Type）、文档（Document）、字段（Field）」组织，本质是一个非关系型文档存储，适合海量数据下的检索与统计分析。

本模块通过 spring-boot-starter-data-elasticsearch 展示了它与 Spring Boot 的整合方式：用 @Document、@Field 注解把 Java 实体（Person）映射为 ES 文档，用 ElasticsearchRepository 完成增删改查，用 ElasticsearchTemplate 创建/删除索引和管理映射，用 NativeSearchQueryBuilder 实现分词、排序、分页查询，用 AggregationBuilders 做分组、平均等聚合统计。核心解决「关系型数据库难以支撑的大数据量全文检索与聚合分析」问题——例如对 remark 字段用 ik_smart 中文分词器做全文检索（模块中搜索"东汉"能命中刘备、曹操、孙权三人），并对 age、country 等字段做平均年龄、按国家分组等统计。

2. 什么时候使用

✅ 适合全文检索：需要对长文本、文章、日志等做关键字搜索并支持中文分词（如模块中 remark 字段用 IK 分词器），关系型数据库的 LIKE '%...%' 无法命中分词且性能差。
✅ 大数据量下查询性能敏感：数据量达到千万级以上，需要毫秒级返回，ES 依靠倒排索引和分布式分片可以水平扩展。
✅ 需要复杂的聚合统计：按字段分组、求均值/最值、分桶统计等分析需求，可直接在查询时完成（模块演示了按国家分组的平均年龄聚合），无需另外跑报表任务。
✅ 需要灵活的检索能力：组合分词、排序、分页、范围查询（模块的 findByAgeBetween）、布尔过滤等复杂条件，且想用 DSL 灵活拼装。
✅ 与 Spring 生态深度集成：项目是 Java/Spring Boot，希望用 Repository 模式声明式定义查询（findByXxx 方法名自动生成 DSL），开发效率高。
❌ 强事务与强一致性场景：ES 是近实时（近秒级可见）的，不保证像事务数据库那样的 ACID，不适合作为唯一事实源做账务、订单等需强一致性的写入。
❌ 频繁更新、关系复杂的数据：ES 的更新本质是「删旧写新」，多对多关联、复杂 JOIN 查询不便处理，关联建议反规范化或另做索引。
❌ 低数据量、简单查询：就几万行数据、简单条件查询，直接上 MySQL 等关系库更简单、运维成本更低，引入 ES 反而增加架构复杂度。
❌ 对精确性要求高于性能：ES 的评分排序、分词匹配带有概率性，若要求严格唯一约束、精确统计口径，仍需配合关系型数据库。
❌ 运维与资源受限的小团队：ES 集群需要独立部署、内存配置、分片调优、版本兼容（Spring Data ES 与 ES 版本强绑定，本模块要求 ES 6.x），学习与维护成本较高。

3. 常见业务场景

站内全文搜索：电商商品搜索、文档/邮件检索、论坛帖子搜索。用户在搜索框输入关键字，利用分词和相关性评分返回匹配结果——正如模块对 remark 用 ik_smart 分词后搜索"东汉"命中相关人物，可进一步做高亮、纠错、搜索建议。
日志与指标分析：集中收集、检索、分析海量应用日志和系统指标（常与 Logstash、Kibana 组合成 ELK）。ES 的分片扩容能力支撑 PB 级日志，聚合查询用于统计错误率、接口耗时分布、QPS 等。
用户画像与标签检索：筛选用户标签、属性组合出目标人群（例如"年龄 20-25 且活跃"）。模块的 findByAgeBetween 范围查询、country 分组聚合，正是这种多维过滤与人群统计的雏形。
推荐、智能筛选与实时看板：在亿级数据上组合多条件过滤并按热度/时间排序返回，同时用聚合实时计算排行榜、分布柱状图等看板指标——模块演示的 avg/terms 及嵌套聚合就是此类统计的核心。
数据仓库 / 数据集市的补充检索层：作为大数据分析结果的检索出口，承接离线计算结果，对外提供快速查询与多维筛选接口，弥补 Hive、数仓维表难以支撑的秒级交互式检索。

4. 同类技术对比

对比维度	Elasticsearch	MySQL（关系型数据库）	Solr / Lucene	Redis Search
定位	分布式全文检索引擎	通用关系型事务数据库	传统搜索引擎 / 底层库	内存中的检索模块
全文检索与中文分词	强，内置 IK 等分词器，倒排索引	弱，仅 `LIKE` 模糊匹配，难命中分词	强，老牌搜索引擎方案	较强，依赖 Redis Stack
查询能力	检索 + 排序 + 分页 + 聚合统计	支持复杂关联 JOIN 与事务	检索为主，聚合较弱	检索为主，功能相对有限
实时性	近实时（写入后秒级可见）	强一致，即时可见	近实时，需选择合适更新策略	强一致，内存即时可见
分布式与水平扩展	强，分片/副本天然支持	需分库分表，扩展较繁琐	依赖外部方案（如 SolrCloud）	有一定扩展性，受内存约束
数据结构/事务	文档型，弱事务	结构化，强事务 ACID	文档型，弱事务	需把数据装入 Redis
学习与运维成本	较高，需维护集群、调优	低，成熟通用	较高	低
数据规模	适合海量数据检索分析	适合中小规模在线存储	适合海量数据检索	适合数据可放入内存的场景

选型建议：

数据量庞大、要全文检索和聚合分析 → 选 Elasticsearch，尤其是日志、站内搜索、人群/标签筛选类场景。
数据量中等、核心是事务与强一致（订单、账务、业务主数据）→ 选 MySQL 等关系型数据库，ES 只作为旁路的检索/分析副本。
已有 Solr 技术栈积累、检索要求高但对 Spring Data/聚合诉求不强 → 可考虑 Solr；单纯追求极致底层性能并愿意自己造轮子 → 用 Lucene。
数据能放入内存、需要极低延迟检索、且不想引入重型搜索引擎 → 可选 Redis Search。
实际大型系统最常见的做法是「MySQL 存事实 + ES 建索引做检索分析」：写入走事务库，再把数据同步进 ES 提供搜索与聚合，事务与检索各尽其职。