每次看到我都想叹口气。不是嫌这问题蠢,是它问错了方向——把两个根本不在一条赛道上的东西,摆成了二选一。
我见过太多团队在选型会上为"哪个更强"吵半天,最后拍脑门定了一个,跑半年才发现踩坑。其实这俩货的"甜区"几乎不重叠,真要较真,它们连对手都算不上。
PostgreSQL 是个正经的关系型数据库,设计目标就是把业务数据稳稳当当地存住。事务、约束、外键、回滚,这些保证数据不丢不错的东西,它全包了。你半夜发现一条脏数据,一句 UPDATE 改完 rollback 都来得及。
ClickHouse 不是"另一个数据库",它本质是个列式分析引擎。它的世界里没有"改一行"这种操作的概念——数据进来基本就是追加,然后等着被海量地扫描、聚合。它的全部才华都用在了一件事上:让你在几十亿行数据上跑 GROUP BY,还能秒回。
一个是会计,一个是统计员。你拿统计员去收账,或者让会计去做全国人口普查,都不对口。
场景一:你在做业务系统(订单、用户、交易、支付) 毋庸置疑,必须是PostgreSQL。需要事务、需要约束、需要"这笔扣了那笔必须加上"。ClickHouse 在这种场景中会让你怀疑人生——它改一条数据要重写一整块数据块(part),而且还是异步的,你刚 UPDATE 完去查,可能还没生效。业务系统用 ClickHouse 当作主库,可能会出现大量数据不致的问题。
场景二:你要分析一大堆历史数据(日志、埋点、行情、链上数据) ClickHouse 主场。PostgreSQL 也能查,但当你的数据达到几十亿行,随便一个 GROUP BY 能让 PG 跑到地老天荒,索引也救不了你——因为分析查询本质上是全列扫描,B+ 树索引帮不上忙。ClickHouse 的列式存储只读出需要的列,加上向量化执行,速度根本不是一个量级。
场景三:实时看板,每秒几万条写入,前端要秒级出图 ClickHouse。高吞吐写入是它的看家本领,批量插进去跟玩一样。PG 在高并发写入下,Vacuum 和索引维护迟早让你头疼,连接池打满都是轻的。
场景四:你就一个人,一个库,啥都得干 老实用 PostgreSQL,先用起来。等哪天你真被某个分析查询卡脖子了,再接 ClickHouse 当分析从库也不迟。我见过最典型的过度设计之一就是——过早引入 ClickHouse ,为了一年用不到几次的分析需求,养一整套完全不同的运维体系,值吗?
场景五:复杂关联查询(join 七八张表还带子查询) ClickHouse 的 join 一直是软肋,早年单线程、吃内存,官方文档甚至建议你把数据拉平(denormalize)别 join。最近版本好了不少,但真要复杂的多表关联,还是 PG 稳。
场景六:时序数据(监控指标、IoT、tick 级行情) 两个都能干。PG 挂个 TimescaleDB 插件很香,自带降采样和连续聚合,对熟悉 PG 的团队几乎零成本。CH 用 MergeTree 加物化视图也能做,而且体量再大一个数量级也更稳。看你的数据量和团队底子。
PG 作为主库,通过逻辑复制或者 CDC 把数据同步到 ClickHouse,专门负责算。ClickHouse 只管"算",不管"记"。
这是很多团队的现实架构,不是非此即彼。我就见过一个做金融风控数据的团队,订单和用户跑在 PG 上,每天的借贷、还款快照和交易流水同步进ClickHouse 做风控和因子计算——各司其职,谁也不抢谁的活。
选型的核心就一句话:你主要的读写模式是什么? 事务优先选 PG,扫描聚合优先选 CH。先把这个问题答清楚,比看一百篇"XX vs YY 谁更强"都有用。
所以下次再有人问你 PG 还是 ClickHouse,先反问一句:你到底要它干什么?
工具没有高低,只有合不合适。这话听着像句废话,但被错误选型坑过的团队都懂,它不是。