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

电商订单五层存储架构：MySQL + ES + MongoDB + ClickHouse + HBase

news 2026/6/18 10:29:05

前言

电商订单系统存储架构设计核心思路：按业务场景、数据量级、读写模型拆分存储，一库一职责，互不越界。

中小团队常踩坑：单库承载所有订单业务，引发多表 JOIN 超时、大报表拖垮交易、冷数据膨胀拖慢在线查询；盲目引入多种存储又会出现边界混乱、同步复杂、维护成本飙升问题。

电商根据业务体量分为两套架构：

中小体量电商（日单百万内、历史订单 TB 级）：四层架构MySQL+ES+Mongo+ClickHouse完全覆盖需求；
头部巨型电商（日单千万 / 亿级、运行多年、归档订单千亿 / PB 级）：五层架构，HBase 承载海量冷订单归档、高并发历史单点查询。

一、五层架构总览

口诀：交易 MySQL，检索 ES，详情 Mongo，分析 CK，海量归档 HBase

MySQL：在线交易主库、资金唯一可信源，承载热订单、事务、列表查询
Elasticsearch：多维检索引擎，只负责模糊搜索、多条件筛选，不存完整详情
MongoDB：APP 订单详情专用库，存储嵌套商品、支付 / 退款流水、物流轨迹
ClickHouse：OLAP 数据分析引擎，支撑大盘、报表、离线对账、海量聚合统计
HBase：分布式宽表存储，专门承载超大规模已结清冷订单永久归档、高并发主键点查

二、五层存储分层详解

1. MySQL：在线交易核心主库（唯一资金基准）

核心定位

金融级事务存储，所有下单、支付、退款、核销、分账等资金操作的唯一可信数据源。

存储内容

扁平化极简结构化字段，只保留交易、资金、状态核心字段：
订单号、UID、订单状态、创建时间、实付金额、优惠券抵扣、退款金额、支付渠道单号、对账状态

适用场景

用户端「我的订单」列表分页、状态筛选
核心交易链路：下单、支付、取消、售后退款、扣库存、核销优惠券
财务实时对账、资金结算、资损追溯

绝对禁忌

不存储商品明细、状态流水、物流轨迹、售后图片等嵌套过程数据

不存放多年历史冷订单，避免表膨胀影响在线读写性能

不执行海量数据聚合报表，防止 CPU 打满阻塞交易

2. Elasticsearch：订单检索专用引擎

核心定位

解决 MySQL 分库分表后无法跨库模糊检索、多维度复合筛选的痛点，只做检索索引，不承担数据存储、详情渲染。

存储内容

仅同步少量检索维度字段，拒绝同步大数组、流水详情：
订单号、用户手机号、昵称、商品名称、订单状态、金额区间、支付时间

适用场景

商家后台、客服系统、运营后台订单搜索、批量筛选导出

绝对禁忌

不存储完整订单详情、状态变更流水

不频繁更新大文档（ES 更新机制为删除重建全文档，高频更新极易集群 OOM）

不用于海量资金聚合统计、财务对账

3. MongoDB：APP 订单详情展示库

核心定位

面向前端展示的文档型存储，专门解决 MySQL 多表关联查询臃肿、业务频繁迭代需要新增字段的痛点，纯展示层，不参与任何资金业务逻辑。

存储内容

全量嵌套页面数据，一次查询即可渲染完整订单详情：
多 SKU 商品列表、多渠道支付拆分记录、全生命周期状态日志、多次退款明细、物流完整轨迹、活动满减信息、客服售后备注、凭证图片地址

适用场景

用户订单详情页、售后详情页、物流轨迹查询

绝对禁忌

不作为交易主库，不处理支付、退款、优惠券核销等资金事务

不做财务对账基准、不支撑海量离线统计分析

千亿级归档冷订单场景不推荐长期存储，存储成本、查询吞吐弱于 HBase

4. ClickHouse：海量订单分析数据仓库

核心定位

列式时序 OLAP 引擎，承接所有离线、准实时数据分析需求，彻底隔离分析流量与在线交易流量。

数据来源

通过 MySQL binlog 实时同步全量订单交易流水，仅追加写入，极少更新、删除。

适用场景

实时交易大盘、日 / 周 / 月销量报表、品类成交额排行、活动效果复盘、批量离线财务对账、用户消费行为统计

绝对禁忌

不承接用户在线订单列表、详情单点查询

不支持高频单条更新、删除操作

不用于客服、商家实时查询历史归档订单

5. HBase：海量冷订单归档宽表存储

核心定位

基于 HDFS 的分布式 LSM 宽表，专门解决超大规模平台多年归档订单存储、高并发历史单点查询需求，中小电商可省略，头部平台必备。

独有核心能力（其余四类存储无法完全替代）

PB 级海量数据低成本存储：底层依托 HDFS，数据压缩比远高于 Mongo、MySQL，适合永久归档几年、十几年订单，满足审计合规要求；
行级原子操作、超高并发主键点查：商家、客服高频根据订单号 / 用户 ID 查询几年前历史订单，吞吐、延迟优于 Mongo；
原生多版本时序存储：自动记录每条订单所有变更时间戳，无需手动维护数组，天然存储状态变更、轨迹流水；
无缝打通大数据生态：可直接对接 Hive、Spark 做离线对账、用户画像分析，无需额外数据同步链路。

存储内容

超过 3~6 个月、状态终态（已完成、已退款、坏账核销）、无后续资金变更的全量归档订单，包含完整商品、支付、退款、轨迹、状态流水数据。

适用场景

头部电商历史订单永久归档，释放 MySQL、Mongo 在线存储资源；
客服、商家后台高并发查询多年前归档订单；
大数据离线计算、合规审计溯源。

绝对禁忌

不承载在线热订单交易写入、实时列表查询；

不用于多条件模糊检索（无倒排索引，筛选性能远差 ES）；

中小体量电商（TB 级以内冷单）无需部署，维护 Hadoop、Zookeeper 成本过高。

三、HBase 与其余四类存储替代关系说明

MySQL：完全无法替代 HBase
MySQL 单表容量有上限，分库分表运维繁重，存储成本高，不适合 PB 级归档冷订单，只能承载短期热订单。
Elasticsearch：完全无法替代 HBase
ES 核心能力是检索，海量冷订单构建全量倒排索引内存、磁盘开销巨大；主键点查性能、压缩率、存储成本全面落后 HBase。
MongoDB：仅中小平台可临时替代，超大规模场景无法平替
TB 级以内历史冷单：Mongo 分片可承载，开发简单、无需大数据组件；
千亿 / PB 级归档、客服高并发查历史单：Mongo 吞吐、压缩、运维复杂度不及 HBase，必须引入 HBase。
ClickHouse：完全无法替代 HBase
CK 擅长批量聚合分析，随机单点查询性能差，不适合用户、客服高频查单场景。

四、五层架构标准读写全流程

1. 下单 / 支付 / 退款核心交易流程

所有资金事务在 MySQL 中原子完成，资金数据唯一可信；
MySQL 事务提交成功后发送 MQ 消息，异步同步热订单完整详情至 Mongo，同步检索字段至 ES；同步失败仅影响页面展示，不阻断主业务；
MySQL binlog 实时同步全量交易数据至 ClickHouse，用于数据分析；
定时离线任务：将满足归档条件（超 6 个月、终态结清）的订单从 MySQL、Mongo 迁移至 HBase 永久归档，清理在线库冷数据。

2. 用户端「我的订单」列表查询

直接查询 MySQL，依托索引完成分页、状态筛选，数据实时、一致。

3. 用户点击订单详情

3 个月内热订单：优先查询 Mongo，一次性获取完整嵌套数据渲染页面；Mongo 故障自动降级多表查询 MySQL 兜底；
超过归档周期历史订单：路由查询 HBase 获取归档详情。

4. 后台 / 客服订单搜索筛选

ES 根据关键词、条件筛选，匹配出订单号列表；拿到 order_no 后，热单查 Mongo，归档冷单查 HBase 渲染详情。

5. 运营报表、财务大盘统计

直接查询 ClickHouse，海量数据秒级聚合，完全不占用在线交易库资源。

五、分层数据库核心能力对比表

存储	核心优势	核心短板	核心业务定位	是否能替代 HBase
MySQL	强事务、ACID、资金一致性、列表稳定	不适合海量归档、嵌套复杂数据	在线热订单、资金交易、订单列表	否
Elasticsearch	多维模糊检索、复合筛选	更新开销大、存储成本高	订单检索匹配订单号	否
MongoDB	文档模型、嵌套数据友好、开发简单	海量归档吞吐、压缩比弱	热订单 APP 详情展示	小规模可临时替代，大规模不行
ClickHouse	海量列式聚合、报表分析	随机点查性能差	离线数据大盘、对账统计	否
HBase	PB 级低成本归档、高并发主键点查、多版本时序、大数据生态联动	依赖 Hadoop 生态，运维复杂、无检索能力	终态冷订单永久归档、历史订单单点查询	专属分层，无完全替代品

存储	写入特性（实时/批量）
MySQL	实时单条事务写入稳定，批量一般
Elasticsearch	频繁更新大文档性能极差，只适合少量索引同步
MongoDB	实时局部更新友好，同步写入延迟稳定，中小批量表现均衡
ClickHouse	仅适合批量追加写入，单条实时更新性能差
HBase	批量离线归档写入吞吐天花板；业务同步单条实时写入延迟高、抖动大，不用于热订单实时更新