当前位置： 首页 > news >正文

ES+MySQL实时搜索架构实战解析

news 2025/9/10 5:42:33

一、ES概述

ElasticSearch（简称 ES）是一个分布式、高扩展、高实时的全文搜索引擎，同时也是一个开源的 NoSQL 数据库，主要用于存储、检索和分析海量数据。它基于 Lucene 搜索引擎库构建，提供了简单易用的 RESTful API，能够快速处理结构化、半结构化和非结构化数据。

ElasticSearch 的核心特性

  1. 全文搜索能力支持复杂的全文检索，能对文本进行分词、同义词处理、模糊匹配等，比传统数据库的LIKE查询更高效、更精准（例如电商的商品搜索、日志检索）。
  2. 分布式架构数据自动分片存储在多个节点，支持水平扩展（增加节点即可提升容量和性能），并通过副本机制保证高可用（某节点故障时，副本节点可无缝接管）。
  3. 实时性数据写入后几乎可以立即被检索到（延迟通常在毫秒级），适合对实时性要求高的场景（如实时监控、即时推荐）。
  4. 强大的聚合分析内置丰富的聚合功能，可对数据进行统计、分组、计算（如计算某商品类别的销量排名、分析用户行为趋势），常用于数据可视化和业务分析。
  5. 多数据类型支持不仅支持文本，还能处理数字、日期、地理位置等数据类型，甚至可以存储 JSON 格式的复杂结构。

二、MySQL主从架构场景下Canal+ES的架构

在 MySQL 主从架构中，Canal 和 ElasticSearch（ES）的联合使用，主要是为了实现MySQL 数据实时同步到 ES，从而利用 ES 强大的全文检索和聚合分析能力。这种架构常被用于构建 “MySQL 存储核心业务数据 + ES 提供高效查询” 的系统（如电商商品搜索、日志检索等）。
架构方案：MySQL 主从 + Canal + Elasticsearch

   写入路径（强一致）

  • 订单/库存写 → 直写 MySQL 主库。
  • 从库 负责 SQL 读请求（保障读写分离）。

   同步路径（最终一致）

  • MySQL 主库产生 Row-Based Binlog。
  • Canal 模拟从库订阅 Binlog，解析出 数据变更事件（Insert/Update/Delete）。
  • Canal Adapter / 自研消费者 将变更数据同步到 Elasticsearch（Upsert 到索引）。
  • ES 中的数据即为库存/商品的近实时视图，延迟通常在毫秒级。

   查询路径（低延迟）

  • 复杂查询/聚合/搜索 → 直接走 Elasticsearch，单次查询延迟压缩至 100ms 内。
  • 简单读（详情、库存校验） → 走从库 MySQL 或 Redis 缓存。

2.1 核心架构原理

MySQL 主从架构提供了数据备份和读写分离能力，而 Canal 可监听 MySQL 的 binlog 日志，将数据变更实时同步到 ES，形成 “MySQL ← Canal → ES” 的数据流闭环。整体架构如下：
  • Canal 的角色：模拟 MySQL 从库的 “slave” 角色，伪装成从库连接主库，订阅并解析 binlog 日志，获取数据变更（增删改）。
  • ES 的角色：存储同步过来的数据，提供全文检索、复杂聚合等查询能力，减轻 MySQL 的查询压力。

2.2、具体实现步骤

1. 准备基础环境
  • MySQL 主库配置：需开启 binlog（log_bin = ON），并设置binlog_format = ROW（Canal 仅支持 ROW 模式，可获取行级变更详情），同时为 Canal 创建具有REPLICATION SLAVE权限的账号（同主从复制的授权逻辑）。
  • Canal 部署：下载 Canal（官方地址），配置监听 MySQL 主库的地址、端口、账号密码，以及 binlog 的起始位置（如canal.instance.master.address = 主库IP:3306）。
  • ElasticSearch 部署：搭建 ES 集群（单节点也可测试），创建索引（Index）和映射（Mapping），定义需要同步的字段类型（如文本、数字、日期等）。
2. 核心数据同步流程
Canal 监听 MySQL binlog 后，通过以下步骤将数据同步到 ES：
（1）Canal 解析 binlog 获取数据变更
Canal 启动后，会像 MySQL 从库一样连接主库，获取 binlog 日志并解析为结构化的变更数据（包含操作类型：INSERT/UPDATE/DELETE，以及变更前后的字段值）。
例如，MySQL 执行UPDATE user SET name='张三' WHERE id=1，Canal 会解析出： 
{"table": "user","type": "UPDATE","data": [{"id": 1, "name": "张三", "age": 20}],  // 变更后的数据"old": [{"name": "李四"}]  // 变更前的旧数据（仅UPDATE有）
}
（2）数据转换与过滤（关键步骤）
Canal 本身不直接写入 ES，需通过客户端程序（如 Java、Python 脚本）处理数据：
  • 过滤无关数据：只同步需要索引到 ES 的表或字段（如过滤掉日志表、临时表）。
  • 格式转换：将 MySQL 的字段类型适配为 ES 的映射类型（如 MySQL 的datetime转为 ES 的date）。
  • 处理复杂逻辑：如关联多表数据（需查询 MySQL 从库补充关联字段）、计算衍生字段等。
（3）写入 ElasticSearch
客户端程序将转换后的数据通过 ES 的 REST API 写入 ES：
  • INSERT：调用POST /索引名/_doc/文档ID新增文档。
  • UPDATE：调用PUT /索引名/_doc/文档ID更新文档（或使用_updateAPI 做部分更新）。
  • DELETE：调用DELETE /索引名/_doc/文档ID删除文档

2.3、注意事项

数据一致性：

  • Canal 同步是异步的，存在毫秒级延迟，需业务容忍 “MySQL 与 ES 数据短暂不一致”。
  • 可通过 “双写”（写入 MySQL 的同时调用 ES API）保证强一致，但会增加业务复杂度。

异常处理：

  • 需实现失败重试机制（如 Canal 的ack机制确保未处理的变更不会丢失）。
  • 定期全量同步校验（如每天凌晨对比 MySQL 与 ES 数据，修复不一致）。

性能优化：

  • Canal 客户端批量处理变更（减少 ES 写入次数）。
  • ES 开启批量写入 API（_bulk），提升写入效率。
  • 对大表同步，可先全量导出 MySQL 数据到 ES，再通过 Canal 同步增量变更。

与 MySQL 从库的关系：

  • Canal 监听主库 binlog，与从库同步不冲突（从库仍负责备份和读业务）。
  • 若担心主库压力，Canal 也可监听从库的 binlog（需从库开启log_bin）。

三、倒排索引

倒排索引是基于MySQL正排索引的概念来说的
3.1 正向索引
如果把图书馆的每本书看作 “数据载体”，“书的编号” 就是主键，“书名、作者、目录、内容摘要” 就是值 —— 正向索引就像 “书号→书的信息” 的对照表，通过书号能直接查到这本书的所有关键信息。
如果是根据id查询，那么直接走索引，查询速度非常快。
但如果是基于title做模糊查询，只能是逐行扫描数据，流程如下：
1）用户搜索数据，条件是title符合"%手机%"
2）逐行获取数据，比如id为1的数据
3）判断数据中的title是否符合用户搜索条件
4）如果符合则放入结果集，不符合则丢弃。回到步骤1
逐行扫描，也就是全表扫描，随着数据量增加，其查询效率也会越来越低。当数据量达到数百万时，就是一场灾难。
3.2倒排索引
倒排索引中有两个非常重要的概念：
  • 文档（Document）：用来搜索的数据，其中的每一条数据就是一个文档。例如一个网页、一个商品信息
  • 词条（Term）：对文档数据或用户搜索数据，利用某种算法分词，得到的具备含义的词语就是词条。例如：我是中国人，就可以分为：我、是、中国人、中国、国人这样的几个词条
创建倒排索引是对正向索引的一种特殊处理，流程如下：
  • 将每一个文档的数据利用算法分词，得到一个个词条
  • 创建表，每行数据包括词条、词条所在文档id、位置等信息
  • 因为词条唯一性，可以给词条创建索引，例如hash表结构索引
3.3正向索引和倒排索引对比
概念区别：
  • 正向索引是最传统的，根据id索引的方式。但根据词条查询时，必须先逐条获取每个文档，然后判断文档中是否包含所需要的词条，是根据文档找词条的过程。
  • 而倒排索引则相反，是先找到用户要搜索的词条，根据词条得到保护词条的文档的id，然后根据id获取文档。是根据词条找文档的过程。
3.4优缺点：
正向索引：
  • 优点：
    • 可以给多个字段创建索引
    • 根据索引字段搜索、排序速度非常快
  • 缺点：
    • 根据非索引字段，或者索引字段中的部分词条查找时，只能全表扫描。
倒排索引：
  • 优点：
    • 根据词条搜索、模糊搜索时，速度非常快
  • 缺点：
    • 只能给词条创建索引，而不是字段
    • 无法根据字段做排序

四、ES数据库概念

4.1 mysql与elasticsearch
各自长处：
  • Mysql：擅长事务类型操作，可以确保数据的安全和一致性
  • Elasticsearch：擅长海量数据的搜索、分析、计算
我们统一的把mysql与elasticsearch的概念做一下对比：
MySQL
Elasticsearch
说明
Table
Index
索引(index)，就是文档的集合，类似数据库的表(table)
Row
Document
文档（Document），就是一条条的数据，类似数据库中的行（Row），文档都是JSON格式
Column
Field
字段（Field），就是JSON文档中的字段，类似数据库中的列（Column）
Schema
Mapping
Mapping（映射）是索引中文档的约束，例如字段类型约束。类似数据库的表结构（Schema）
SQL
DSL
DSL是elasticsearch提供的JSON风格的请求语句，用来操作elasticsearch，实现CRUD
在企业中，往往是两者结合使用：
  • 对安全性要求较高的写操作，使用mysql实现
  • 对查询性能要求较高的搜索需求，使用elasticsearch实现
  • 两者再基于某种方式，实现数据的同步，保证一致性

五、ES的深分页问题

1. 深分页为什么会慢？

  • Elasticsearch 底层是 Lucene，分页使用 from + size。
  • 深分页时，比如 from=100000, size=10：
    • Lucene 需要先取出前 100010 条数据，再丢掉前 100000 条，只返回最后 10 条。
    • 这会导致：
    1. 内存占用大（要维护大量候选结果）。
    2. CPU 消耗高（排序、打分都要计算）。
    3. 延迟急剧上升（越靠后页数，延迟越明显）。

2. 常见延迟表现

  • 前几页（比如 1~100 页，每页 10 条），延迟在 100ms 级别可接受。
  • 深分页（10w 级以上偏移），延迟可能达到秒级，甚至 OOM。

3. 解决策略

（1）Search After（官方推荐）
  • 原理：基于上一页的 sort 值继续往后拉，不允许随机跳页。
  • 使用场景：游标式翻页，用户只需要“下一页/加载更多”。
  • 优点：性能稳定，延迟和页数无关。
  • 缺点：不能直接跳到第 N 页。
GET sku_index_v1/_search { "size": 10, "sort": [{ "updatedAt": "asc" }, { "id": "asc" }], "search_after": ["2024-09-09T12:00:00", 12345] }
（2）Scroll API
  • 原理：游标方式，快照化查询结果，适合全量扫描。
  • 优点：适合日志导出、大批量处理。
  • 缺点：占用内存，不能长时间维持；不适合用户交互翻页。
GET /sku_index_v1/_search?scroll=1m { "size": 1000, "query": { "match_all": {} } }
（3）分段查询（数据分片 + 范围查询）
  • 原理：通过业务字段（时间/ID 范围）做条件分段，而不是简单的 from+size。
  • 例如：按 id > lastId 来查询下一批。
  • 优点：轻量，避免深分页；性能高。
  • 缺点：需要业务方改造查询逻辑。
（4）预计算与缓存
  • 热门分页：可以放到 Redis 缓存，直接返回。
  • 大分页导出：走 离线批处理（Hive/Spark → ES），不要依赖实时分页。

六、ES和MySQL的一致性问题

要保证Elasticsearch（ES）和MySQL之间的数据一致性，可以考虑以下几种方法：
  1. 双写：在应用程序中同时对MySQL和ES进行写操作。这确保了数据同时写入两个系统，从而保持一致性。这种方法简单直接，但会增加写入的延迟和复杂性。
  2. 使用消息队列：将写操作发送到消息队列，然后由消费者分别将数据写入MySQL和ES。这样可以确保写操作被顺序处理，从而保持数据的一致性。常用的消息队列包括Kafka、RabbitMQ等。
  3. 使用数据库的binlog：MySQL的binlog记录了数据库的修改操作，可以通过解析binlog来将数据同步到ES。可以使用工具如Debezium、Maxwell等来实时监听和解析binlog，并将数据同步到ES。
  4. 定期全量同步：定期将MySQL中的数据全量同步到ES。可以使用ETL工具或自定义脚本来实现全量同步。这种方法适用于数据量较小且对实时性要求不高的场景。

文章转载自：

http://fUQcwJoQ.kskpx.cn
http://zDs8W1G2.kskpx.cn
http://weS5guRK.kskpx.cn
http://kqNZ695o.kskpx.cn
http://oyUcx9eE.kskpx.cn
http://2T8Tch2x.kskpx.cn
http://qxMy7uWk.kskpx.cn
http://IQxVI7SH.kskpx.cn
http://DLseCa9I.kskpx.cn
http://Rs9QxIss.kskpx.cn
http://leUwz16s.kskpx.cn
http://s11kWQW5.kskpx.cn
http://GSrYKCMa.kskpx.cn
http://0asAVrcV.kskpx.cn
http://YpohSzRq.kskpx.cn
http://GdHH0PYY.kskpx.cn
http://GQtETVOA.kskpx.cn
http://NysY1D2I.kskpx.cn
http://2B9BeHMv.kskpx.cn
http://RXi3nJ5C.kskpx.cn
http://DEB2WCZG.kskpx.cn
http://uNoL7Ent.kskpx.cn
http://oVuycnHP.kskpx.cn
http://VASanRp9.kskpx.cn
http://zMHtTaUH.kskpx.cn
http://9UiT0rTW.kskpx.cn
http://px1wCN94.kskpx.cn
http://izZE6cnH.kskpx.cn
http://iu09F63v.kskpx.cn
http://i2mARvgN.kskpx.cn
http://www.dtcms.com/a/374492.html

相关文章：

  • ​人脸表情识别检测数据集​：近4k图像，8类，yolo标注
  • 【智能协同云图库】基于统一接口架构构建多维度分析功能、结合 ECharts 可视化与权限校验实现用户 / 管理员图库统计、通过 SQL 优化与流式处理提升数据
  • Linux使用-MySQL的使用
  • Linux grep 命令使用说明
  • 双引擎驱动！中新赛克AI安全方案入选网安创新大赛优胜榜单
  • Day42 PHP（mysql注入、跨库读取）
  • 开源 C++ QT Widget 开发（十四）多媒体--录音机
  • 小白成长之路-jenkins使用pipline部署
  • Elasticsearch面试精讲 Day 15：索引别名与零停机更新
  • vscode中使用git、githup的基操
  • Elasticsearch面试精讲 Day 12：数据建模与字段类型选择
  • 【Visual Studio 2017 和 2019下载】
  • 领码方案·AI狂潮：3天极速塑造高可用电商核心架构——从需求到上线，用智能驱动架构革新，打造可扩展、可维护、可复用的电商系统新范式
  • SpringCloud gateway配置predicates的匹配规则
  • Win系统下配置PCL库第一步之下载Visual Studio和Qt 5.15.2（超详细）
  • 腾讯云负载均衡增加访问策略后访问失败
  • 【Java EE进阶 --- SpringBoot】Spring DI详解
  • 内存中读写文件：设计原理与C/C++实现
  • 光场显微镜及其在三维生物成像中的应用
  • 基于FPGA的实时图像处理系统（3）——实时视频显示
  • 【慢教程】Ollama4：ollama命令汇总
  • 当医疗健康遇见RWA：区块链技术如何重塑医疗资产的未来
  • 【内存管理】6.6内核 - Vmalloc机制 - __purge_vmap_area_lazy
  • 第3周 机器学习课堂记录
  • 机器学习、深度学习与大模型：技术选型的思考与实战指南
  • 深度学习（四）：数据集划分
  • Python最新的好用技巧和特性总结
  • 看不见的安全防线：信而泰仪表如何验证零信任有效性
  • PyQt 界面布局与交互组件使用指南
  • 资产 OCR 识别：批量导入效率提升指南