🚀 数据库技术对比分析报告

Apache Doris · Elasticsearch · ClickHouse · TiDB 全方位深度对比

系统定位与核心特性

Apache Doris

实时 MPP 分析型数据仓库

极致 OLAP 性能
湖仓一体
高并发查询
实时 BI

Elasticsearch

分布式搜索与分析引擎

全文检索
日志分析
向量搜索
可观测性

ClickHouse

列式数据库管理系统

单表查询
高压缩比
批量写入
时序分析

TiDB

分布式 HTAP 数据库

ACID 事务
实时分析
MySQL 兼容
强一致性

核心特性对比矩阵

特性维度 Apache Doris Elasticsearch ClickHouse TiDB
系统定位 MPP 实时分析数仓 搜索与分析引擎 列式数据库 HTAP 数据库
核心架构 MPP (列存) 倒排索引 (Lucene) 列存 + 向量化 HTAP (行存+列存)
事务支持 ⚠ 加载原子性 ✗ 单文档原子性 ✗ 不支持 ✓ 分布式 ACID
数据更新 ✓ 支持高频更新 ⚠ 低频更新 ✗ 不支持高频 ✓ 极高
查询接口 SQL (MySQL 兼容) Query DSL / SQL 类 SQL SQL (MySQL 8.0)
全文检索 ✓ 倒排索引 ✓✓ 核心能力 ✗ 不支持 ⚠ 有限支持
Join 能力 ✓✓ 强大 ✗ 不支持 ⚠ 弱 ✓✓ 强大
存储压缩比 10:1 1.5:1 8:1 5:1
运维复杂度 低 中等 高 中等

综合评分雷达图

架构设计与核心机制

Apache Doris - FE/BE 架构

Frontend (FE)

负责元数据管理、查询解析与规划、节点管理。通过 BDB JE 协议同步元数据，实现高可用。

Backend (BE)

负责数据存储和查询执行。采用列式存储引擎，支持高压缩比和向量化执行。

MPP 架构

大规模并行处理，将复杂查询拆分到所有节点并行执行，支持 Shuffle Join。

Elasticsearch - 分布式搜索架构

倒排索引

基于 Lucene 的倒排索引，实现毫秒级全文搜索。支持分词、词干提取等 NLP 特性。

Shard & Replica

通过分片实现水平扩展，通过副本保证高可用和自动故障转移。

近实时 (NRT)

数据写入后需要 refresh（默认 1 秒）才能被搜索，权衡写入吞吐量和可见性。

ClickHouse - 去中心化架构

列式存储

按列存储数据，配合向量化执行引擎，单表查询性能极佳。

去中心化

每个节点独立管理元数据，依赖 ZooKeeper 实现高可用，运维复杂度较高。

表引擎

支持多种表引擎（MergeTree、ReplacingMergeTree 等），适应不同场景。

TiDB - HTAP 混合架构

TiKV (行存)

基于 RocksDB 的分布式 KV 存储，处理 OLTP 负载，提供 ACID 事务保证。

TiFlash (列存)

列式存储引擎，作为 TiKV 的 Raft Learner 副本，实时同步数据用于 OLAP 分析。

消除 ETL

通过内部实时复制替代外部批量 ETL，实现真正的实时分析，秒级数据可见。

数据一致性模型对比

维度 Doris Elasticsearch ClickHouse TiDB
一致性模型 强一致性 (MVCC) 近实时 (NRT) 最终一致性 强一致性 (Raft)
事务隔离级别 加载级别原子性 单文档原子性 不支持 快照隔离
并发控制 MVCC 版本控制 无 MVCC + 2PC
数据可见性 实时 ~1 秒延迟 实时 实时
适用场景 分析型系统 搜索与日志 日志分析 核心业务系统

性能基准测试对比

写入性能对比

指标 Doris Elasticsearch ClickHouse TiDB
数据写入速度 550 MB/s 110 MB/s 600+ MB/s 200-300 MB/s
倒排索引写入 >20 MB/s <5 MB/s 不支持 有限
实时更新支持 ✓ 支持高频 ⚠ 低频 ✗ 不支持 ✓ 极高
批量导入 百万条/秒 中等 极快 快
最佳写入场景 实时流 + 批量 日志流 离线批量 事务写入

查询性能对比 (日志分析场景)

🏆 关键发现：Doris vs Elasticsearch

  • ✓ 写入性能：Doris 快 3-5 倍（峰值提升 32%-400%）
  • ✓ 查询性能：Doris 快 2.3-56 倍（耗时缩短 38%-90%）
  • ✓ 存储成本：Doris 节省 50%-80%（仅为 ES 的 1/5）
  • ✓ 资源占用：Doris CPU 资源仅为 ES 的 1/4

复杂查询性能 (多表 Join)

场景 Doris Elasticsearch ClickHouse TiDB
单表聚合 (亿级) 1-2 秒 6-7 秒 1-3 秒 3-5 秒
双表 Join 优秀 不支持 一般 优秀
多表 Join (3+) 优秀 不支持 较差 优秀
大表 Join (>1000万) 性能优秀 不支持 性能急降 性能良好

企业案例佐证

中信银行信用卡中心

场景：日志云平台升级，从 Elasticsearch 迁移到 Doris

成果：

  • 磁盘占用下降 58%
  • 日志写入峰值提升 32%
  • 查询耗时缩短 38%
  • CPU 资源仅为 ES 的 1/4（4台8核32G vs 9台16核32G）

某大型支付平台

场景：安全数据平台，替换 ES + Hudi 架构

成果：

  • 查询性能提升高达 56 倍（平均 3 倍）
  • 存储成本降低 50%
  • 写入吞吐量提升 4 倍

核心功能特性对比

数据更新能力

功能 Doris Elasticsearch ClickHouse TiDB
实时更新 ✓ Unique Key 模型 ⚠ Update API (低性能) ✗ 不支持高频 ✓ 原生 OLTP
删除操作 ✓ 行级删除 ✓ 软删除 ⚠ 异步删除 ✓ 行级删除
Upsert ✓ 原生支持 ⚠ 脚本实现 ✗ 不支持 ✓ 原生支持
部分列更新 ✓ 2.0+ 支持 ⚠ 全文档重建 ✗ 不支持 ✓ 支持
更新机制 Merge-on-Write 删除 + 重建 异步合并 原地更新

Join 能力详细对比

Apache Doris ⭐⭐⭐⭐⭐

  • ✓ Local Join、Broadcast Join
  • ✓ Shuffle Join、Hash Join
  • ✓ Colocate Join（性能优化）
  • ✓ 支持复杂多表 Join (3+)
  • ✓ 大表 Join 性能优秀

TiDB ⭐⭐⭐⭐⭐

  • ✓ 完整 SQL Join 支持
  • ✓ Hash Join、Merge Join
  • ✓ Index Join 优化
  • ✓ 分布式 Join 优化器
  • ✓ 大表 Join 性能良好

ClickHouse ⭐⭐⭐

  • ⚠ 仅 Local Join、Broadcast Join
  • ✗ 不支持 Shuffle Join
  • ⚠ 小表 (<1000万) 性能尚可
  • ✗ 大表 Join 性能急剧下降
  • ⚠ 需要手动优化查询顺序

Elasticsearch ⭐

  • ✗ 不支持标准 SQL Join
  • ⚠ Nested 嵌套对象 (性能差)
  • ⚠ Parent-Child 父子文档
  • ✗ 不适合关系型查询
  • ✗ 需要数据冗余设计

湖仓一体能力

功能 Doris Elasticsearch ClickHouse TiDB
Hive 联邦查询 ✓ 原生支持 ✗ 不支持 ⚠ 通过 JDBC ⚠ 有限支持
Iceberg/Hudi ✓ 原生支持 ✗ 不支持 ✗ 不支持 ⚠ 路线图
对象存储 (S3/OSS) ✓ 原生支持 ⚠ 通过快照 ✓ 支持 ✓ 支持
流式集成 (Kafka/Flink) ✓ 原生支持 ✓ Logstash/Beats ⚠ 需外部工具 ✓ CDC 支持
统一查询引擎 真正湖仓一体 仅日志场景 生态封闭 HTAP 统一

SQL 兼容性

功能 Doris Elasticsearch ClickHouse TiDB
SQL 标准 MySQL 协议兼容 部分 ANSI SQL 类 SQL 语法 MySQL 5.7/8.0 兼容
窗口函数 ✓ 完整支持 ✗ 不支持 ✓ 支持 ✓ 完整支持
子查询 ✓ 支持 ⚠ 有限 ✓ 支持 ✓ 完整支持
CTE (公共表表达式) ✓ 支持 ✗ 不支持 ✓ 支持 ✓ 支持
存储过程/触发器 ✗ 不支持 ✗ 不支持 ✗ 不支持 ✗ 不支持

适用场景与推荐指数

🚀 Apache Doris 推荐场景 (⭐⭐⭐⭐⭐)

实时报表分析

✓ 电商实时大屏（订单、GMV、用户行为）
✓ 金融实时风控（交易监控、异常检测）
✓ 高并发 BI 查询（数千 QPS）

日志存储与分析

✓ 统一日志检索与报表分析平台
✓ 10 倍于 ES 的性价比
✓ 高吞吐实时写入 + 低成本海量存储

用户画像与精准营销

✓ 支持高频数据更新（Unique Key）
✓ 复杂多维分析和圈人能力
✓ 实时标签计算与推送

湖仓一体架构

✓ 联邦查询 Hive/Iceberg/Hudi
✓ 统一 OLAP 引擎
✓ 降低架构复杂度

🔍 Elasticsearch 推荐场景 (⭐⭐⭐)

全文检索

✓ 文档搜索（企业知识库）
✓ 日志关键字搜索
✓ 商品搜索（电商场景）

APM 与可观测性

✓ 分布式链路追踪
✓ 指标收集与展示
✓ 配合 Kibana 可视化

向量搜索与 RAG

✓ GenAI 应用向量搜索
✓ 检索增强生成 (RAG)
✓ 语义搜索

⚠️ 不推荐场景

  • ✗ 复杂聚合计算（性能不佳）
  • ✗ 存储成本敏感场景（压缩比低）
  • ✗ 多表关联分析（不支持 Join）
  • ✗ 绝不能作为主数据库（缺乏 ACID 事务）

⚡ ClickHouse 推荐场景 (⭐⭐⭐⭐)

大规模日志分析（单表）

✓ PB 级日志数据存储
✓ 单表聚合查询
✓ 时间范围、维度分组

离线批处理

✓ T+1 数据分析报表
✓ 批量 ETL 处理
✓ 历史数据归档分析

时序数据分析

✓ 监控指标存储与查询
✓ IoT 数据分析
✓ 传感器数据处理

⚠️ 不推荐场景

  • ✗ 复杂多表 Join（性能差）
  • ✗ 高频数据更新（不支持）
  • ✗ 运维资源有限（复杂度高）

💎 TiDB 推荐场景 (⭐⭐⭐⭐⭐)

HTAP 统一平台

✓ 消除 OLTP 到 OLAP 的 ETL 延迟
✓ 单一系统处理事务与分析
✓ 秒级数据可见性

实时风控与欺诈检测

✓ 金融实时交易监控
✓ 异常行为实时分析
✓ ACID 事务保证 + 实时分析

核心业务系统

✓ 替代传统 MySQL（水平扩展）
✓ 分布式 ACID 事务
✓ 强一致性保证

实时库存管理

✓ 电商实时库存分析
✓ 事务 + 分析统一
✓ 高并发读写

场景适用性矩阵

核心业务场景 Doris Elasticsearch ClickHouse TiDB
高并发在线事务 (OLTP) 不适用 高风险 不适用 高
HTAP (OLTP + 实时 OLAP) 低 低 低 高 (核心)
实时 BI 报表 / 仪表盘 高 (核心) 低 中 中
Ad-Hoc 即席复杂查询 高 (核心) 低 中 中
日志检索与搜索 高 高 (核心) 中 中
日志聚合分析 高 (性价比) 中 高 中
高并发数据服务 (Data Serving) 高 (Unique Key) 中 低 高 (TiKV)
全文搜索引擎 (App Search) 低 高 (核心) 不支持 中
向量搜索 / RAG (GenAI) 中 高 低 中

总拥有成本 (TCO) 对比分析

存储成本对比 (基于 100 TB 原始数据)

Apache Doris
1.0x

压缩后 10 TB × 3 副本 = 30 TB

基准成本

Elasticsearch
2.2x

压缩后 67 TB × 1 副本 = 67 TB

存储成本是 Doris 的 2.2 倍

ClickHouse
0.8x

压缩后 12.5 TB × 2 副本 = 25 TB

存储成本最低

TiDB
1.5x

压缩后 20 TB × 3 副本 = 60 TB
(含 TiKV + TiFlash)

HTAP 架构增加存储

压缩率对比

计算成本对比

场景 Doris Elasticsearch ClickHouse TiDB
简单查询 (高 QPS) 低成本 中等成本 低成本 中等成本
复杂 Join 查询 低成本 不适用 高成本 低成本
实时更新场景 低成本 高成本 不适用 低成本
批量导入 极快 中等 极快 快

运维成本对比

维度 Doris Elasticsearch ClickHouse TiDB
安装部署
★ ★ ★ ★ ★
★ ★ ★ ★ ★
★ ★ ★ ★ ★
★ ★ ★ ★ ★
外部依赖 无依赖 无依赖 依赖 ZooKeeper 无外部依赖
扩缩容 ✓ 自动均衡 ✓ 自动 Rebalance ⚠ 手动管理 ✓ 自动调度
故障恢复 ✓ 自动恢复 ✓ 自动恢复 ⚠ 手动介入 ✓ 自动恢复
运维复杂度 ⭐⭐ 低 ⭐⭐⭐ 中等 ⭐⭐⭐⭐ 高 ⭐⭐⭐ 中等
监控工具 内置 Dashboard Kibana 第三方工具 Grafana + Prometheus
学习曲线 MySQL 熟悉即可 需学习 DSL 需深入学习 MySQL 兼容

总成本对比 (3年 TCO 估算)

技术选型决策树

🎯 核心选型原则

技术选型应严格基于业务场景的核心需求，而非技术栈的"流行度"或"完整性"。

开始选型
│
├─ 主要需求是全文检索？
│  ├─ 是 → Elasticsearch (文档搜索、日志关键字检索)
│  └─ 否 → 继续
│
├─ 需要 ACID 事务保证？
│  ├─ 是 → 继续
│  │  ├─ 需要实时分析统一 → TiDB (HTAP 统一平台)
│  │  └─ 纯事务场景 → TiDB / MySQL
│  └─ 否 → 继续
│
├─ 需要复杂多表 Join？
│  ├─ 是 → Apache Doris / TiDB
│  └─ 否 → 继续
│
├─ 需要实时数据更新 (高频 Update/Upsert)？
│  ├─ 是 → Apache Doris / TiDB
│  └─ 否 → 继续
│
├─ 数据规模 > PB 级，且主要是单表查询？
│  ├─ 是 → ClickHouse
│  └─ 否 → 继续
│
├─ 需要湖仓一体能力 (Hive/Iceberg 联邦查询)？
│  ├─ 是 → Apache Doris
│  └─ 否 → 继续
│
├─ 运维资源有限，希望降低运维成本？
│  ├─ 是 → Apache Doris
│  └─ 否 → 继续
│
└─ 有强大研发团队，可以深度定制？
   ├─ 是 → ClickHouse
   └─ 否 → Apache Doris

选型标准详解

选择 Apache Doris 的标准

✅ 核心标准

当业务需要极致的 OLAP 分析性能、高并发查询、低延迟响应，并且对成本（特别是存储成本）高度敏感时。

决策信号：

  • ✓ 正在构建实时 BI 报表、用户画像或 Ad-hoc 即席查询平台
  • ✓ 需要支持高并发的 API 查询（Data Serving）
  • ✓ 关键迁移信号：正在使用 Elasticsearch 进行日志分析，遭受高昂存储成本和缓慢聚合查询困扰
  • ✓ 需要湖仓一体能力，统一查询多种数据源
  • ✓ 运维资源有限，希望降低管理复杂度

权衡：

Doris 不是 OLTP 数据库，不处理 ACID 事务。

选择 Elasticsearch 的标准

✅ 核心标准

当业务核心是搜索，特别是非结构化文本、地理空间或向量搜索时。

决策信号：

  • ✓ 首要任务是全文搜索、语义搜索或模糊搜索
  • ✓ 场景是可观测性 (Observability)，需要日志、指标、APM 跟踪（ELK Stack）
  • ✓ 构建 GenAI 应用，需要向量搜索和 RAG（检索增强生成）
  • ✓ 团队已在 ES 生态（Kibana, Logstash）上有大量投入

权衡：

  • ⚠️ ES 不是 ACID 数据库，绝不能作为主数据库
  • ⚠️ Join 能力弱，不适合复杂关联分析
  • ⚠️ 分析聚合的性价比远低于 Doris

选择 ClickHouse 的标准

✅ 核心标准

当数据规模达到 PB 级，且主要是单表查询和聚合，有专业 DBA 团队可接受高运维成本时。

决策信号：

  • ✓ 数据规模 > PB，且主要是单表离线分析
  • ✓ 有专业 DBA 团队，可接受高运维成本
  • ✓ 业务需要深度定制和性能极致优化
  • ✓ 主要场景是时序数据、监控指标、IoT 数据分析

权衡：

  • ⚠️ 复杂多表 Join 性能差
  • ⚠️ 不支持高频数据更新
  • ⚠️ 运维复杂度高（依赖 ZooKeeper）

选择 TiDB 的标准

✅ 核心标准

当业务强依赖于单一系统、强一致性 ACID 事务、并同时需要对最新鲜的事务数据进行实时分析时。

决策信号：

  • ✓ 首要目标是消除 OLTP 和 OLAP 之间的 ETL 管道
  • ✓ 团队以 SQL 为中心，希望简化运营（一个系统 vs 两个系统）
  • ✓ 业务场景是实时风控、实时欺诈检测、需要实时库存分析的电商平台
  • ✓ 需要替代传统 MySQL，实现水平扩展

权衡：

  • ⚠️ 纯 OLAP 分析性能可能不如 Doris
  • ⚠️ 不支持存储过程、触发器等 MySQL 高级特性
  • ⚠️ TiFlash 会增加额外存储开销

组合架构模式

💡 最佳实践：组合的力量

对于大多数中大型企业而言，最终的架构决策不是"四选一"，而是"如何组合"。

架构模式 1：HTAP 统一平台

架构：TiDB 单一系统

适用场景：追求运营简单性且分析负载适中的场景

优势：无 ETL 延迟，运维简单，技术栈统一

权衡：OLAP 性能不如专用引擎

架构模式 2：高性能 OLTP + OLAP

架构：TiDB (OLTP) + Doris (OLAP)

适用场景：兼顾高性能事务与高性能分析

数据流：通过 CDC 从 TiDB 实时流入 Doris

企业案例：蔚来汽车、小米集团

优势：各司其职，性能最优

架构模式 3：数据库 + 搜索引擎 + 分析引擎

架构：TiDB / MySQL (SoR) + Elasticsearch (搜索) + Doris (分析)

适用场景：最成熟的"各司其职"架构

系统之源 (SoR)

TiDB / MySQL
保证 ACID 事务

搜索引擎

Elasticsearch
App 搜索、RAG、日志检索

分析平台

Apache Doris
内部 BI、Ad-hoc、日志分析

数据流：从 SoR 通过 CDC/消息队列分别流入专用的分析引擎和搜索引擎

优势：构建现代、可扩展、高性能数据平台的成熟架构

快速选型参考表

场景 推荐系统 理由
实时报表分析 Doris 高并发、复杂 Join、实时更新
日志存储与分析 Doris > ES 性价比高 10 倍，兼具检索和分析
全文检索 Elasticsearch 专业检索引擎，成熟生态
PB 级单表离线分析 ClickHouse 单表查询性能极佳，存储成本低
用户画像与精准营销 Doris 支持实时更新，复杂多维分析
多表关联分析 Doris / TiDB Join 性能远超 ClickHouse
湖仓一体架构 Doris 原生支持数据湖联邦查询
HTAP 统一平台 TiDB 消除 ETL，事务 + 分析统一
核心业务系统 (OLTP) TiDB 分布式 ACID 事务，强一致性