别再盲选数据库了！ClickHouse、Druid、QuestDB 到底怎么选？一篇文章帮你避开 90% 的坑
大家有没有发现这样一个现象？
很多团队做大数据平台的时候，前期讨论最多的问题不是业务怎么做，而是：
我们到底该选 ClickHouse、Druid 还是 QuestDB？
更有意思的是，很多项目最后选型理由居然是：
「网上都说 ClickHouse 快。」
「别人公司在用 Druid。」
「QuestDB 看起来挺新。」
听起来是不是有点耳熟？
其实，数据库选型最怕的不是选错，而是不知道为什么选。
作为一个做了很多年数据平台的人，我越来越觉得：
没有最好的数据库，只有最适合业务场景的数据库。
今天，就和大家聊聊这三个目前实时分析领域最热门的数据库。
希望你看完以后，再也不会因为数据库选型而纠结。
一、先搞清楚：实时分析到底解决什么问题？
很多人把 OLAP 理解成：
查询速度快。
其实这只是结果。
真正的目标只有一句话：
让海量数据能够在秒级甚至毫秒级完成统计分析。
举个例子。
假设电商平台一天产生：
订单
支付
退款
物流
浏览
点击
搜索
每天几十亿条日志。
老板突然问：
最近10分钟广东地区iPhone销量是多少？
如果去 MySQL：
SELECT SUM(num)
FROM order
WHERE province='广东'
AND create_time > NOW()-INTERVAL 10 MINUTE;
数据一亿条的时候还能忍。
十亿条开始卡。
百亿条以后基本可以去泡杯咖啡。
所以才有：
- 数据仓库
- 列式存储
- 实时OLAP
- MPP计算
- 向量化执行
这些技术。
而今天介绍的三个数据库，就是解决这一类问题。
二、ClickHouse：目前最均衡的实时分析数据库
如果让我推荐一个最值得学习的 OLAP 数据库。
我一定选 ClickHouse。
为什么？
因为它几乎没有明显短板。
它最大的几个特点：
✅ 列式存储
例如：
传统数据库：
id name age city
ClickHouse 实际存储：
id id id id
name name name
age age age
city city city
查询：
SELECT SUM(amount)
只读取 amount 这一列。
磁盘 IO 瞬间减少几十倍。
再来看建表。
CREATE TABLE order_detail
(
order_id UInt64,
user_id UInt64,
amount Decimal(18,2),
province String,
create_time DateTime
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(create_time)
ORDER BY (province, create_time);
这里真正重要的是：
PARTITION
ORDER BY
很多新手把 ORDER BY 当排序。
其实不是。
它更像：
数据物理排列规则。
查询：
SELECT
province,
SUM(amount)
FROM order_detail
WHERE province='浙江'
GROUP BY province;
因为数据天然排好序。
扫描的数据非常少。
所以速度极快。
再看看 Python 查询。
from clickhouse_driver import Client
client = Client(host='127.0.0.1')
result = client.execute("""
SELECT province,
sum(amount)
FROM order_detail
GROUP BY province
ORDER BY sum(amount) DESC
LIMIT 10
""")
for row in result:
print(row)
是不是非常简单？
ClickHouse适合什么？
我一般建议：
✔ BI分析
✔ 数据仓库
✔ 用户画像
✔ 日志分析
✔ 广告分析
✔ 风控分析
✔ 财务统计
一句话：
几乎所有离线+准实时OLAP都适合。
三、Druid：天生就是为了实时数据而生
如果 ClickHouse 是一个全能选手。
那么 Druid 就更偏实时。
它最大的特点：
数据可以边写边查。
比如：
每秒：
100万条埋点
不停进入系统。
与此同时：
运营后台正在实时刷新：
PV
UV
在线人数
订单量
GMV
Druid 可以做到：
几秒内就能查到最新数据。
这是很多传统数据仓库很难做到的。
例如实时查询：
SELECT
FLOOR(__time TO MINUTE),
COUNT(*)
FROM user_event
WHERE __time >= CURRENT_TIMESTAMP - INTERVAL '10' MINUTE
GROUP BY FLOOR(__time TO MINUTE);
基本就是实时刷新。
Druid 为什么这么快？
因为它用了很多技术：
- Segment
- Bitmap Index
- Rollup
- Cache
- Broker
- Historical Node
整个架构就是为了：
高并发聚合。
例如：
一个 Dashboard：
几十张图表
几百个维度
几十人同时访问
Druid 表现非常稳定。
不过。
它也有一个问题。
架构复杂。
生产环境一般包括：
Coordinator
Broker
Historical
MiddleManager
Router
ZooKeeper
Deep Storage
第一次部署的人基本都会头疼。
所以：
能驾驭 Druid 的团队，一般都有一定的大数据基础。
四、QuestDB：时间序列领域的新宠
很多人不知道。
QuestDB 根本不是为了 BI 而设计。
它主要面向：
Time Series Database（TSDB）
什么意思？
例如：
CPU
内存
股票
IoT
传感器
GPS
工业设备
监控
这些数据都有共同特点：
时间
+
数值
例如：
2026-06-01 10:00 CPU=35%
2026-06-01 10:01 CPU=37%
2026-06-01 10:02 CPU=42%
QuestDB 对这种数据进行了大量优化。
建表：
CREATE TABLE cpu_metric (
ts TIMESTAMP,
host SYMBOL,
cpu DOUBLE
) timestamp(ts)
PARTITION BY DAY;
查询：
SELECT
ts,
avg(cpu)
FROM cpu_metric
SAMPLE BY 1m;
注意：
SAMPLE BY
这是 QuestDB 非常经典的语法。
一分钟自动聚合。
写起来非常舒服。
Python 插入数据。
from questdb.ingress import Sender
with Sender.from_conf("http::addr=localhost:9000;") as sender:
sender.row(
"cpu_metric",
symbols={
"host": "server01"},
columns={
"cpu": 32.5},
)
sender.flush()
整个过程几乎就是几行代码。
QuestDB 最大优势：
写入速度非常夸张。
官方测试：
百万级写入压力非常轻松。
对于 IoT 场景来说非常舒服。
五、到底该怎么选？别只看“谁快”
很多文章喜欢直接给出一个“谁最快”的结论，但这种比较其实意义不大。
真正应该问的是：
你的数据是什么类型？你的查询是什么模式？未来三年的业务会长成什么样？
下面这张对比表，可能比一堆跑分更有价值。
| 维度 | ClickHouse | Druid | QuestDB |
|---|---|---|---|
| 核心定位 | 通用实时 OLAP | 实时分析引擎 | 时间序列数据库 |
| 写入能力 | ★★★★☆ | ★★★★★ | ★★★★★ |
| 查询能力 | ★★★★★ | ★★★★★ | ★★★★☆ |
| SQL 支持 | 非常完善 | 较完善 | 偏时间序列 |
| 部署复杂度 | ★★☆☆☆ | ★★★★★ | ★☆☆☆☆ |
| 学习成本 | 中等 | 较高 | 很低 |
| 最佳场景 | 数据仓库、BI、日志分析 | 实时看板、埋点分析 | IoT、监控、金融行情 |
我的建议也很直接：
如果你的业务主要围绕 BI、报表、用户行为分析、日志分析，优先考虑 ClickHouse。 它生态成熟、社区活跃、性能稳定，是目前很多互联网公司和企业数据平台的首选。
如果你的核心诉求是秒级更新的大屏、实时运营指标、海量埋点分析，并且团队有能力维护复杂集群，那么 Druid 会更有优势。
如果你的数据天然就是按时间连续产生，例如设备监控、工业物联网、股票行情、服务器指标，那么 QuestDB 往往比通用 OLAP 数据库更合适。
六、真正决定成败的，不是数据库，而是架构
这些年接触了不少数据平台项目，我发现一个很有意思的现象。
很多团队花了几个月时间争论数据库，却很少有人认真讨论：
- 数据模型有没有设计好？
- 分区策略是否合理？
- 排序键是不是符合查询模式？
- 是否存在冷热数据分层？
- 数据生命周期如何管理？
- 是否建立了完善的数据质量监控？
最后上线后发现：
查询慢，不是数据库慢。
而是：
SELECT *
扫了几十亿行。
或者：
ORDER BY
压根没设计。
又或者：
每天几百 GB 数据，全放一个分区。
这时候，就算把数据库从 ClickHouse 换成 Druid，再换成 QuestDB，性能提升也十分有限。
所以，我一直认为：
数据库决定的是性能上限，而数据模型、分区设计、索引策略、查询习惯和整体架构，决定的是性能下限。
一个优秀的数据平台，从来不是靠某一个明星数据库“拯救”出来的，而是靠一整套合理的架构设计和工程实践共同支撑起来的。
写在最后
过去十年，大数据的发展经历了从离线数据仓库到实时分析，再到湖仓一体、流批一体的不断演进。数据库越来越快，但业务对实时性的要求也越来越高。
如果让我用一句话总结今天这三个产品：
- ClickHouse：综合能力最强，几乎是现代数据仓库和实时 OLAP 的“全能选手”。
- Druid：为实时分析而生，尤其适合高并发 Dashboard 和运营大屏。
- QuestDB：专注时间序列，把一件事情做到极致。
作为技术人，与其追逐“最火”的数据库，不如先读懂自己的业务，再选择最匹配的工具。
技术选型没有标准答案，只有是否真正解决问题。真正成熟的架构师，看的从来不是数据库排行榜，而是业务未来三年的增长曲线。
我是 Echo_Wish，我们下期继续聊那些真正能提升数据平台性能和架构能力的硬核技术。
