Elasticsearch 从 0 到 1（一）：ES 是什么，为什么需要它#

MySQL 查询和 ES 搜索的区别#

MySQL 更擅长结构化数据查询。

比如：

1
SELECT *
2
FROM product
3
WHERE category_id = 10
4
  AND price BETWEEN 100 AND 500
5
ORDER BY created_at DESC;

这类条件明确、字段结构稳定的查询，MySQL 很合适。

但如果是：

1
SELECT *
2
FROM product
3
WHERE title LIKE '%无线蓝牙耳机%'
4
   OR description LIKE '%无线蓝牙耳机%';

问题就多了：

• LIKE '%xxx%' 很难高效利用普通索引；
• 中文搜索不会自动理解词语边界；
• 很难计算“哪条结果更相关”；
• 高亮、聚合、复杂搜索体验都不方便做；
• 数据量上来后查询压力会明显变大。

ES 更适合搜索场景。它会先把文本拆成词，再建立倒排索引，让搜索变成“通过词找文档”。

什么是倒排索引#

普通索引可以理解成：

1
文档 -> 包含哪些词

倒排索引反过来：

1
词 -> 出现在哪些文档里

比如有三条商品：

1
1：无线蓝牙耳机
2
2：蓝牙音箱
3
3：有线游戏耳机

分词后可能得到：

1
无线 -> 1
2
蓝牙 -> 1, 2
3
耳机 -> 1, 3
4
音箱 -> 2
5
有线 -> 3
6
游戏 -> 3

用户搜索“蓝牙耳机”时，ES 可以快速找到包含“蓝牙”和“耳机”的文档，再根据相关性算出排序。

这就是 ES 比 LIKE 更适合全文搜索的根本原因。

ES 里的几个核心概念#

刚开始学 ES，先把几个词搞清楚。

1. Document 文档#

文档是 ES 里存储数据的基本单位。

可以把一条商品数据理解成一个文档：

1
{
2
  "id": 1001,
3
  "title": "无线蓝牙耳机",
4
  "brand": "SoundGo",
5
  "price": 199,
6
  "category": "数码",
7
  "stock": 80
8
}

它有点像 MySQL 表里的一行记录。

2. Index 索引#

索引是一组文档的集合。

比如商品搜索可以建一个索引：

1
products

里面放的都是商品文档。

它有点像 MySQL 的表，但不要完全等同。ES 的索引不仅保存文档，还包含 Mapping、分片、副本等配置。

3. Field 字段#

字段就是文档里的属性。

比如：

1
title
2
brand
3
price
4
category
5
stock

每个字段都有类型，比如 text、keyword、integer、date。

字段类型会影响搜索、排序、聚合和存储方式。

4. Mapping 映射#

Mapping 用来定义字段结构。

比如：

1
{
2
  "title": { "type": "text" },
3
  "brand": { "type": "keyword" },
4
  "price": { "type": "integer" }
5
}

Mapping 很重要。字段一旦建错，后面查询体验会很难受。

比如商品标题应该支持全文搜索，适合 text；品牌名通常用于精确筛选和聚合，适合 keyword。

Mapping 会在第二篇详细讲：Elasticsearch 从 0 到 1（二）：索引、Mapping 和分词器。

5. Shard 分片#

ES 的一个索引可以拆成多个分片。

分片的作用是把数据分散到多个节点上，提高存储和查询能力。

比如一个 products 索引有 3 个主分片：

1
products
2
  shard-0
3
  shard-1
4
  shard-2

每个分片本质上都是一个 Lucene 索引。

初学时先记住一句话：

分片决定数据怎么拆，副本决定数据怎么备份。

6. Replica 副本#

副本是分片的备份。

它有两个作用：

• 提高可用性；
• 分担读请求。

如果某个节点挂了，副本可以顶上。

生产环境里通常至少会配置 1 个副本。但开发环境单节点时，如果副本数大于 0，集群健康状态可能是 yellow，因为副本没有别的节点可放。

ES 适合什么场景#

ES 很适合：

• 商品搜索；
• 文章搜索；
• 日志检索；
• 订单搜索；
• 用户行为分析；
• 复杂筛选和聚合；
• 需要高亮、排序、相关性评分的搜索。

比如电商商品搜索：

1
关键词：蓝牙耳机
2
品牌：SoundGo
3
价格：100-300
4
排序：销量优先
5
高亮：标题里的匹配词

这种需求就是 ES 的典型应用。

ES 不适合什么#

ES 不是 MySQL 的替代品。

它不适合：

• 强事务；
• 复杂联表；
• 金融级强一致；
• 作为唯一数据源保存核心业务数据；
• 高频小事务更新。

更常见的架构是：

1
MySQL：保存核心业务数据
2
ES：保存适合搜索的冗余数据

比如商品主数据仍然在 MySQL，ES 里保存一份商品搜索文档。

为什么 ES 里的数据通常是冗余的#

ES 搜索文档通常会把多个表的数据拍平。

MySQL 可能是：

1
product 表
2
brand 表
3
category 表
4
inventory 表

ES 里可能是一条文档：

1
{
2
  "productId": 1001,
3
  "title": "无线蓝牙耳机",
4
  "brandName": "SoundGo",
5
  "categoryName": "数码耳机",
6
  "price": 199,
7
  "stock": 80
8
}

这样查询时不用联表，搜索会更快。

代价是：MySQL 数据变化后，要同步更新 ES。

数据同步和一致性会放到第五篇讲：Elasticsearch 从 0 到 1（五）：MySQL 数据同步与一致性。

第一篇先记住什么#

这一篇不用急着写 DSL，先把 ES 的定位搞清楚：

• ES 是搜索引擎，不是关系型数据库替代品；
• MySQL 适合结构化查询，ES 适合全文搜索和复杂检索；
• ES 的核心能力来自倒排索引；
• 文档是数据基本单位，索引是一组文档；
• Mapping 决定字段怎么存、怎么搜；
• 分片负责拆数据，副本负责备份和读扩展；
• 真实项目里通常是 MySQL 做主存储，ES 做搜索冗余。

下一篇继续讲怎么建索引、怎么设计 Mapping、为什么 text 和 keyword 不能乱用：

Elasticsearch 从 0 到 1（二）：索引、Mapping 和分词器

参考#

• Elastic Docs：Mapping
• Elastic Docs：Java API Client