一、Apache Doris 是什么？

Apache Doris（原名 Palo，由百度开源）是一款现代化的 MPP（大规模并行处理）分析型数据库，专为实时数据分析场景设计。它基于 Google Mesa 论文的思想演进而来，是目前国内使用最广泛的 OLAP（联机分析处理）数据库之一。

核心特性

• 高性能 OLAP：基于列式存储 + 向量化执行引擎，聚合查询极速
• 实时数据写入：支持秒级数据摄入，写入即可见
• 标准 SQL：兼容 MySQL 协议，降低迁移成本
• 弹性架构：FE（前端）+ BE（后端）分离，水平扩展能力强
• 丰富的数据模型：Aggregate、Unique、Duplicate 三种模型覆盖多种场景
• 多表物化视图：自动命中，加速复杂查询
• 湖仓一体：通过 Catalog 直接查询 Hive、Iceberg、Hudi 等数据湖

典型应用场景

二、三者的本质定位

在对比之前，首先明确三者的设计定位，这是理解一切差异的根源：

MySQL       →  OLTP 事务型数据库（联机事务处理）
TiDB        →  HTAP 混合负载数据库（事务 + 分析兼顾）
Apache Doris →  OLAP 分析型数据库（联机分析处理）

一句话总结：MySQL 管事务，Doris 管分析，TiDB 想两者兼顾。

三、架构对比

MySQL 架构

MySQL 采用单机主从架构（或集群），以行式存储为核心，围绕 InnoDB 引擎构建 ACID 事务能力。

Client → MySQL Server
           ├── 查询解析器
           ├── 查询优化器
           └── InnoDB 存储引擎（行式存储 + B+Tree 索引）
                └── 主从复制（异步/半同步）

水平扩展：依赖 ShardingSphere、Vitess 等中间件，原生能力弱。

TiDB 架构

TiDB 是受 Google Spanner/F1 启发的分布式 HTAP 数据库，由三个核心组件构成：

Client
  ↓
TiDB Server（无状态计算层，兼容 MySQL 协议）
  ↓
PD（Placement Driver，元数据管理 + 调度中心）
  ↓
┌──────────────────────────────────┐
│  TiKV（行式存储，OLTP 事务）     │
│  TiFlash（列式副本，OLAP 加速）  │
└──────────────────────────────────┘

TiKV 使用 Raft 协议保证多副本一致性，TiFlash 是 TiKV 的列式存储副本，实现 HTAP。

Apache Doris 架构

Doris 采用 FE + BE 两层架构，无 ZooKeeper 依赖，运维简单：

Client（MySQL 协议）
  ↓
FE（Frontend 前端节点）
  ├── SQL 解析 & 查询规划
  ├── 元数据管理（Catalog）
  └── Leader / Follower 高可用

  ↓（查询计划下发）

BE（Backend 后端节点）× N
  ├── 列式存储（Segment 文件）
  ├── 向量化执行引擎
  └── 本地 Compaction

MPP 并行执行：查询被切分成多个 Fragment，分布在所有 BE 节点并行执行，充分利用多机算力。

四、核心维度对比

4.1 存储引擎

4.2 事务能力

⚠️ 注意：Doris 不适合作为在线事务系统的主库，事务能力是其短板。

4.3 查询性能

4.4 扩展能力

4.5 生态与兼容性

五、Doris 的三种数据模型

这是 Doris 区别于传统数据库的重要特性，按需选择模型可大幅提升性能：

Aggregate 模型（聚合模型）

• 适用：数据本身就是聚合结果，如 PV/UV 统计表
• 原理：写入时自动对相同 Key 的数据进行预聚合（SUM/MAX/MIN/REPLACE）
• 优势：查询无需实时计算，速度极快

CREATE TABLE user_stats (
    user_id     BIGINT,
    date        DATE,
    pv          BIGINT SUM DEFAULT "0",    -- 自动累加
    uv          BIGINT REPLACE DEFAULT "0" -- 取最新值
) AGGREGATE KEY(user_id, date)
DISTRIBUTED BY HASH(user_id) BUCKETS 10;

Unique 模型（主键模型）

• 适用：有主键更新需求，如订单状态更新
• 原理：相同 Key 的新数据替换旧数据（Upsert 语义）
• 优势：保证主键唯一性，适合 CDC 场景

CREATE TABLE orders (
    order_id    BIGINT,
    status      VARCHAR(20),
    amount      DECIMAL(10,2),
    update_time DATETIME
) UNIQUE KEY(order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 16;

Duplicate 模型（明细模型）

• 适用：原始日志存储，保留所有明细数据
• 原理：不做任何预处理，完整保留每条记录
• 优势：灵活，适合 Ad-hoc 查询

CREATE TABLE access_log (
    ts          DATETIME,
    user_id     BIGINT,
    page        VARCHAR(255),
    duration_ms INT
) DUPLICATE KEY(ts, user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 32;

六、典型选型指南

问题：我该用哪个？

是否需要强事务（转账、下单）？
  ├── 是 → MySQL（小数据量）或 TiDB（大数据量/高并发）
  └── 否 → 下一步

数据量是否超过单机 MySQL 瓶颈（TB 级以上）且以分析查询为主？
  ├── 是 → Apache Doris
  └── 数据量不大但需要复杂分析 → Doris 或 ClickHouse

是否需要事务 + 分析混合负载，且不想维护两套系统？
  └── TiDB（HTAP，但分析性能略弱于 Doris）

常见架构组合

方案一：MySQL + Doris（最常见）

业务系统 → MySQL（事务写入）
              ↓ Flink CDC / DataX 同步
           Doris（分析查询）← BI 报表 / 数据大屏

方案二：Kafka + Doris（实时分析）

埋点/日志 → Kafka → Flink → Doris Routine Load
                                    ↓
                              实时数据大盘

方案三：TiDB 独立承担 HTAP

业务系统 → TiDB（TiKV 处理事务）
               ↓ 自动同步到 TiFlash
          TiFlash（分析查询）← BI 报表

七、性能基准参考

以 TPC-H 100GB 测试集为参考（不同环境结果有差异）：

数据仅供参考，实际性能受硬件、数据分布、SQL 复杂度等多种因素影响。

八、总结

Apache Doris 并不是要替代 MySQL 或 TiDB，而是在数据分析领域提供了 MySQL 无法企及的能力。三者在现代数据架构中往往是互补关系，组合使用才能发挥最大价值。

参考资料

• Apache Doris 官方文档
• TiDB 官方文档
• MySQL 8.0 Reference Manual
• SelectDB 云数仓（Doris 商业版）