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

前言

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

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

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

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

一、五层架构总览

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

1. MySQL：在线交易主库、资金唯一可信源，承载热订单、事务、列表查询
2. Elasticsearch：多维检索引擎，只负责模糊搜索、多条件筛选，不存完整详情
3. MongoDB：APP 订单详情专用库，存储嵌套商品、支付 / 退款流水、物流轨迹
4. ClickHouse：OLAP 数据分析引擎，支撑大盘、报表、离线对账、海量聚合统计
5. 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，海量数据秒级聚合，完全不占用在线交易库资源。

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

方案 1：中小电商四层架构

适用：日订单百万以内，历史冷订单总量 TB 级，客服查询并发量低
组件：MySQL + ES + MongoDB + ClickHouse
冷单方案：近 1 年归档订单全部存入 Mongo 分片，超 1 年冷单可同步至对象存储做备份，极少访问。

方案 2：头部巨型电商五层架构

适用：日订单千万 / 亿级，平台运行 3 年以上，归档订单千亿条、PB 存储，客服 / 商家每日海量查询历史订单
组件：MySQL + ES + MongoDB + ClickHouse + HBase
冷热分层规则：

• MySQL：0~3 个月热订单，承载交易与列表；
• Mongo：0~3 个月热订单详情展示；
• ES：全量订单检索索引；
• ClickHouse：全量交易数据分析；
• HBase：3 个月以上已结清终态订单，永久归档存储、历史订单查询。

七、架构设计核心总结

• 无 HBase 四层架构：轻量化、运维简单，满足绝大多数中小型电商业务需求；
• 新增 HBase 构成五层架构：解决巨型平台海量历史订单存储、高并发冷单点查询、大数据离线分析联动三大痛点，其余四类存储无法同等效果替代；
• 分层核心原则：在线交易与归档存储隔离、检索与详情渲染隔离、在线读写与数据分析隔离，各存储各司其职，从根源避免资源抢占、线上雪崩风险；
• 选型关键判断：仅当平台订单体量达到千亿归档、高频查询多年前历史订单时，才需要引入 HBase，否则引入只会增加集群维护成本。