北京
作者 ｜ Sergio De Simone
译者 ｜ 明知山
AI 驱动软件测试平台开发商 Momentic 近期 对其缓存系统进行了重构，以应对每天超 200 万次、总计 200 亿条记录的查询需求，并将平均响应延迟维持在 250 毫秒左右。这一改进得益于从 PostgreSQL 迁移到列式数据库 ClickHouse。
采用新缓存架构的核心原因是缓存数据表数据量急剧膨胀——从约 8 万条记录激增至 10 亿条，这一变化开始暴露出 PostgreSQL 的性能瓶颈：
由于高写入、高读取的工作负载，我们遇到了资源使用率飙升以及查询并发读写缓存时的锁争用问题。随着数据量增长了好几个数量级，情况只会变得更糟。
Momentic 决定迁移至 ClickHouse 时，其缓存系统每日处理约 60 万次缓存查询，且要求响应延迟低于一秒。相较于 PostgreSQL，ClickHouse 在架构层面一大核心优势是采用了稀疏主键索引，而非 B 树索引。PostgreSQL 的查询开销通常会随数据量增大而上升，而 ClickHouse 在已知键值的情况下可将检索范围缩小至少量数据颗粒，在海量数据场景下大幅提升查询效率。
通过精心设计主键，将测试 ID、步骤 ID、平台版本、Git 分支与提交时间戳纳入主键字段，在 90% 的场景（特性分支）中实现了高效检索。但主干分支查询却需要访问海量条目，存在性能隐患：
这意味着大多数查询只需要读取 1 至 2 个数据分片，但某些异常查询每次都要读取几乎所有数据分片，导致内存使用和磁盘操作出现剧烈波动。
为解决这一问题，Momentic 采用了物化视图，按测试 ID 预计算所有可用的提交时间戳，让查询直接定位至对应数据分片。
另一项关键优化是减少单次测试执行产生的查询次数，原先在 PostgreSQL 中使用的三次独立查询在 ClickHouse 上运行时效率很差。
我们改用仅执行 INSERT 操作，并结合 ClickHouse 的 ReplacingMergeTree 引擎：用 SELECT 获取缓存，重新 INSERT 已使用的缓存，以此来延长其过期时间（TTL），单次测试任务结束后 INSERT 新缓存，然后让 ClickHouse 异步完成数据去重。这项优化带来的性能提升十分显著，我们得以彻底移除 Redis 缓存层——此时由于缓存键基数已大幅升高，Redis 的价值已经相当有限。
为了完成迁移，Momentic 让 ClickHouse 与 PostgreSQL 并行运行，将所有写入同时复制到两个系统。生产流量继续由 PostgreSQL 提供服务，同时对 ClickHouse 进行“影子查询”，并对两个数据库的结果进行差异比对，确保正确性。在 Momentic 确认新系统稳定可靠后，流量逐步从 PostgreSQL 切换到 ClickHouse。即使在切换完成后，双写机制仍维持了一段时间，一旦出现异常可安全回滚至原数据库。
通过这次重构，Momentic 成功将缓存规模扩展至 200 亿条记录，每天处理超 200 万次查询，同时平均解析延迟稳定维持在 250 毫秒左右。如需深入了解此次迁移及其设计决策，请参阅原文。
查看英文原文：
https://www.infoq.com/news/2026/07/momentic-postgres-clickhouse/
声明：本文由 InfoQ 翻译，未经许可禁止转载。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
