CEX 业务特点鲜明:高并发、低延迟、强一致、海量历史数据、实时风控与分析并存。单一数据库很难全覆盖,通常是组合方案。
五款数据库核心定位
| 数据库 | 类型 | 核心优势 | 主要短板 |
|---|---|---|---|
| MySQL | 单机 OLTP(可分库分表) | 成熟稳定、生态完善、事务强 | 单机容量和并发有瓶颈,分库分表运维复杂 |
| PostgreSQL | 单机 OLTP(功能最强) | SQL 标准好、JSON/GIS/窗口函数强、扩展性强 | 分布式方案不如 MySQL 成熟,高并发写入弱于 MySQL |
| TiDB | 分布式 HTAP(偏 TP) | 水平扩展、MySQL 协议、强一致事务 | 延迟比单机 MySQL 高、资源消耗大 |
| Doris | MPP OLAP | 实时分析、导入快、查询秒级 | 不适合事务、高频点更新弱 |
| ClickHouse | 列存 OLAP | 超大数据量聚合极快、压缩率高 | JOIN 弱、更新删除代价高、并发查询能力差 |
CEX 核心业务模块与数据库匹配
1. 撮合引擎 / 订单簿
- 通常不落数据库,在内存中用自研引擎(Disruptor、LMAX 模式)跑
- 数据库只做持久化归档,任何传统 DB 都扛不住撮合级别的延迟要求(微秒级)
2. 账户 / 资金 / 钱包(核心交易账本)
- 首选 MySQL 或 PostgreSQL(单机 + 主从 + 分库分表)
- 数据量超大、需要弹性扩展时选 TiDB
- PostgreSQL 的
NUMERIC类型处理金额更严谨,MySQL 生态和 DBA 人才更多 - 关键要求:强一致、ACID、高可用,绝对不用 Doris/ClickHouse
3. 订单 / 成交记录(高写入 + 高查询)
- 热数据(近 1~3 个月):MySQL 分库分表 或 TiDB
- 冷数据 / 历史查询:归档到 Doris 或 ClickHouse
- 用户个人订单查询走 TP 库,全局统计走 AP 库
4. K 线 / 行情数据
- 实时 K 线:Redis + 消息队列
- 历史 K 线、深度分析:ClickHouse(时序聚合极强)或 Doris
- ClickHouse 在超大数据量 Tick 级数据上几乎是业界标配
5. 实时风控 / 反洗钱 / 大户监控
- Doris 更合适:实时导入 + 多表 JOIN + 高并发查询
- ClickHouse 也能做,但 JOIN 弱、并发弱,适合单表分析
6. BI 报表 / 运营分析 / 对账
- Doris 或 ClickHouse 都行
- 要频繁 JOIN、并发查询多(分析师同时查) → Doris
- 单表超大、追求极致聚合速度 → ClickHouse
7. 日志 / 审计 / 操作流水
- ClickHouse 最佳,压缩率高、写入快、成本低
- 量级不大时 Doris 也可以
典型CEX 架构组合
方案 A:中小型CEX (成本优先)
MySQL(核心交易 + 订单)→ Binlog/CDC → ClickHouse(分析 + 日志)
→ Redis(行情缓存)方案 B:中大型CEX (主流方案)
MySQL 分库分表(账户 + 订单热数据)
↓ CDC (Canal/Flink CDC)
├→ Doris(实时风控 + 运营分析 + 订单历史)
└→ ClickHouse(K线 + 行情 + 日志)
Redis(撮合缓存 / 行情推送)
Kafka(事件总线)方案 C:超大型 / 扩展性优先
TiDB(账户 + 订单,替代 MySQL 分库分表)
↓ TiCDC
├→ Doris(实时分析 + 风控)
└→ ClickHouse(海量历史 + Tick 数据)选型建议(按场景)
| 场景 | 首选 | 备选 |
|---|---|---|
| 用户账户、资金流水 | MySQL / PostgreSQL | TiDB |
| 订单、成交(在线) | MySQL 分库分表 | TiDB |
| 订单、成交(归档) | Doris | ClickHouse |
| K线、Tick、深度 | ClickHouse | Doris |
| 实时风控 | Doris | Flink + Doris |
| 运营报表 / BI | Doris | ClickHouse |
| 日志 / 审计 | ClickHouse | Doris |
| 合规对账 | PostgreSQL / MySQL | TiDB |
几个实战经验
- 金额字段千万别用 Float/Double,MySQL 用
DECIMAL,PostgreSQL 用NUMERIC - 撮合引擎不要指望任何数据库,内存 + 异步落盘是唯一解
- MySQL 分库分表到一定规模后运维成本会超过 TiDB,拐点大约在单表百亿 / 集群几十个分片
- ClickHouse 不适合做用户维度的高并发查询(比如用户查自己订单),它擅长的是"扫全表做聚合"
- Doris 和 ClickHouse 并不是二选一,很多CEX 两个都用,各司其职
- PostgreSQL 在券商 / 传统金融更常见,加密货币CEX MySQL 更主流(主要是生态和人才惯性)