1. Elasticsearch入门：ES发展史、ES核心概念、ES应用场景、ES与关系型数据库对比
大家好，我是你们的老朋友。今天咱们正式开启Elasticsearch的学习之旅。说实话，我第一次接触ES是在2015年，当时公司日志系统扛不住了，MySQL查个日志要等半天。后来用了ES，查询速度从分钟级降到了毫秒级——那种感觉，就像从绿皮火车直接换成了高铁。
这一章是入门基础，我会把ES的来龙去脉、核心概念、能干什么、跟MySQL比有什么不同，一次性讲清楚。你不需要记住所有细节，但一定要理解ES的设计哲学——它为什么快？它适合解决什么问题？
1.1 ES发展史：从开源搜索到数据中枢
Elasticsearch的诞生，其实挺有意思的。2004年，有个叫Shay Banon的哥们，他妻子想学做菜，他就写了个搜索菜谱的应用叫Compass。后来他觉得Compass太笨重，干脆重写了一个——这就是ES的雏形。
2010年，第一个公开版本发布。我记得当时很多人不看好，觉得一个搜索框架能翻出什么浪？结果呢？
- 2012年：成立Elastic公司，开始商业化
- 2015年：成为GitHub上最火的搜索项目之一
- 2018年：纽交所上市，市值一度超过50亿美元
- 2021年：与Elasticsearch B.V.合并，推出Elastic Stack（ELK全家桶）
现在ES已经不只是搜索引擎了。它成了日志分析、指标监控、安全分析、甚至向量检索的通用平台。我见过最夸张的案例——某电商用ES做商品推荐，每天处理10亿+请求，延迟控制在20ms以内。
核心启示：ES的成功，在于它把「搜索」这件事做到了极致，然后围绕搜索构建了一个完整的生态。你想想看，从日志到APM，从安全到AI，底层都是搜索。
1.2 ES核心概念：索引、文档、分片、副本
这部分是ES的基石。我建议你反复看，因为后面所有操作都基于这些概念。
1.2.1 索引（Index）
索引，说白了就是「一类文档的集合」。你可以把它类比成MySQL里的数据库。比如你有一个电商系统，商品数据放一个索引，订单数据放另一个索引。
但ES的索引更灵活。它支持动态映射——你不需要提前定义字段类型，ES会自动推断。嗯，这里要注意：生产环境千万别依赖动态映射，我踩过坑——有一次线上ES集群突然写入变慢，查了半天，发现是某个字段被动态映射成了text类型，导致索引膨胀了3倍。
# 创建一个名为products的索引
PUT /products
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1
}
}1.2.2 文档（Document）
文档是ES里最小的数据单元。它本质上是一个JSON对象。比如一条商品记录：
{
"product_id": "P1001",
"name": "iPhone 15 Pro",
"price": 8999.00,
"tags": ["手机", "苹果", "旗舰"]
}每个文档都有一个唯一的_id。你可以自己指定，也可以让ES自动生成。我个人习惯用业务ID作为文档ID，这样方便后续更新和删除。
1.2.3 分片（Shard）
分片是ES实现分布式存储的关键。一个索引的数据会被拆成多个分片，分散到不同节点上。为什么这么做？
- 水平扩展：数据量大了，加节点就行，分片会自动重新分配
- 并行查询：一个查询可以同时跑在多个分片上，速度翻倍
分片数量在创建索引时就要定好。我建议：
- 每个分片大小控制在20-40GB
- 分片总数不要超过节点数的10倍
- 生产环境至少2个分片起步
避坑指南：我曾经接手过一个项目，索引分了100个分片，但只有3个节点。结果每个节点上堆了30多个分片，查询性能反而比不分片还差。记住：分片不是越多越好，要跟节点数匹配。
1.2.4 副本（Replica）
副本就是分片的备份。每个分片可以有一个或多个副本。副本的作用：
- 高可用：主分片挂了，副本顶上
- 提升读性能：查询可以同时从主分片和副本读取
默认情况下，每个分片有一个副本。我建议生产环境至少保留1个副本。但要注意：副本越多，写入性能会下降，因为每个副本都要同步数据。
1.3 ES应用场景：它能解决什么问题？
ES的应用场景，我总结为三大类：
| 场景 | 典型例子 | 为什么用ES |
|---|---|---|
| 全文搜索 | 电商商品搜索、站内搜索 | 支持中文分词、模糊匹配、高亮显示 |
| 日志分析 | ELK日志平台、APM监控 | 海量数据写入、实时聚合分析 |
| 指标监控 | 系统监控、业务指标看板 | 支持时间序列、聚合计算、可视化 |
我见过最典型的案例：某金融公司用ES做风控系统。每天处理5000万笔交易，实时检测异常行为。如果发现某账户短时间内频繁交易，ES能在100ms内触发告警。换成传统数据库？等查完数据，钱早转走了。
个人经验：如果你遇到「数据量大、查询条件复杂、要求毫秒级响应」的场景，优先考虑ES。但如果你的业务是「频繁更新、强事务、复杂关联查询」，那还是老老实实用关系型数据库。
1.4 ES与关系型数据库对比
很多初学者会问：ES能替代MySQL吗？我的回答是：不能，也不应该。它们的设计目标完全不同。
| 对比维度 | Elasticsearch | 关系型数据库（如MySQL） |
|---|---|---|
| 数据模型 | 文档型（JSON） | 关系型（表、行、列） |
| 查询方式 | RESTful API + DSL | SQL |
| 事务支持 | 不支持（最终一致性） | 支持ACID |
| 扩展方式 | 水平扩展（加节点） | 垂直扩展为主 |
| 写入性能 | 高（近实时） | 中等 |
| 查询性能 | 高（倒排索引） | 中等（B+树索引） |
| 适用场景 | 搜索、日志、分析 | OLTP、事务处理 |
你想想看，为什么ES写入快？因为它用的是倒排索引。传统数据库存的是「文档→关键词」的映射，而ES存的是「关键词→文档」的映射。搜索时直接定位关键词，不需要全表扫描。
但ES也有短板。它不支持事务，没有外键约束，更新操作是「先删后写」。所以，我建议的架构是：
- MySQL：负责核心业务数据，保证事务一致性
- ES：负责搜索和分析，提升查询体验
- 两者通过同步机制（如Canal、Logstash）保持数据一致
一句话总结：ES不是MySQL的替代品，而是互补品。用MySQL存数据，用ES搜数据——这才是最佳实践。
好了，第一章的内容就到这里。你可能会觉得概念有点多，没关系，后面每一章都会反复用到这些概念。下一章我们直接上手，安装ES并跑通第一个搜索请求。到时候你会发现，这些概念其实没那么抽象。
公众号:蓝海资料掘金营，微信deep3321