预测市场的数据增长极快。随着 Polymarket 月交易量达到数十亿美元，其 PostgreSQL 数据库在分析负载下开始不堪重负。他们最终引入 ClickHouse 作为专用分析引擎，成功解决了这个问题。
问题：PostgreSQL 遇到瓶颈
和许多快速成长的初创公司一样，Polymarket 早期所有业务都跑在 PostgreSQL 上，包括：
- 交易、订单、用户账户等事务操作
- 内部仪表盘
- 公开排行榜
随着链上活动激增，出现了两个严重问题：
- 仪表盘分析查询频繁超时
- 排行榜功能消耗大量资源，导致整个数据库变慢
他们急需将 OLTP（事务型）和 OLAP（分析型）工作负载分离。
解决方案：Postgres + ClickHouse 混合架构
Polymarket 保留 PostgreSQL 处理事务型工作（它在这方面表现优秀），同时将所有重度分析工作迁移到 ClickHouse —— 一款专为实时分析设计的超快列式数据库。
他们构建了一个现代数据仓库，主要数据流入路径包括：
- 链上交易数据 → 通过 Goldsky（子图/流式）摄入
- Web 分析数据 → 使用 ClickPipes 从 S3 加载
- 链下元数据 → 从 Postgres 同步
用物化视图重构排行榜
最大的改进来自于排行榜的重构：
- 以前：在 Postgres 上运行复杂查询 → 经常超时
- 现在：ClickHouse 物化视图 → 计算时间缩短至毫秒级
效果非常显著：
- 排行榜查询从超时变为 50ms 以内
- 支持更细粒度的分类排行榜（按市场类型、交易量层级等）
- API 可稳定处理每秒数百次请求，平均延迟约 25ms
核心收益
- 解放 Postgres —— 现在专注于事务处理，性能大幅提升
- 实现大规模实时分析
- 功能迭代更快 —— 新排行榜类别和仪表盘开发成本大幅降低
- 分析负载成本更优
给开发者的经验教训
- 尽早分离 OLTP 和 OLAP —— 不要等到出问题再行动。
- ClickHouse 在高写入、高查询的分析场景（尤其是时序和事件数据）表现极为出色。
- 物化视图 是 ClickHouse 最强大的特性之一，能大幅加速复杂聚合查询。
- 现代摄入工具（Goldsky、ClickPipes、dbt 等）让搭建数据仓库比以前容易得多。
- 混合架构更具优势 —— 用合适的工具做合适的事，而不是把所有东西塞进一个数据库。
Polymarket 的技术栈是务实扩展的优秀范例：保留 Postgres 的强项，同时在需要极致分析速度的地方引入 ClickHouse。
你有没有将分析负载迁移到 ClickHouse 或其他 OLAP 数据库？
遇到了哪些挑战？
欢迎在评论区分享你的经验。
Tags: #ClickHouse #PostgreSQL #数据库扩展 #数据工程 #Polymarket #预测市场 #后端开发 #性能优化 #OLAP #技术栈
Top comments (0)