某中心选择PostgreSQL扩展替代专用OLAP实现10万行/秒分析

某中心零信任产品套件的工程团队近期发文解释为何选择TimescaleDB而非ClickHouse来增强内部平台的分析和报告能力。作者强调该方案在"存储分析数据与配置数据的简易性"与"专用OLAP系统性能"之间取得了非凡平衡。

基于工程极简主义理念，该团队构建了数字体验监控（DEX）平台——一个内部可观测性平台，用于监控零信任环境中的设备、网络和应用性能。该系统包含配置平面（用于创建和管理合成测试的接口）和分析平面（从WARP客户端收集结构化日志的摄入管道，支持存储和仪表板可视化）。

尽管自2017年起就使用ClickHouse，但高级软件工程师Robert Cepa解释未采用该方案的原因：“ClickHouse最常用的MergeTree表引擎针对高吞吐量批量插入优化。它将每次插入作为独立分区写入，然后通过后台合并维持数据管理。这种设计使写入速度极快，但不适用于每分钟数百万设备上传单个日志事件的小批量写入场景。过多小写入会引发写入放大、资源竞争和节流问题。”

为保持初始版本简洁并在四个月内交付可用的DEX最小可行产品，团队使用PostgreSQL同时处理配置数据和分析日志，在发布时实现每秒200次插入，大多数客户的查询延迟控制在数百毫秒内。但随着使用量增长，Cepa指出：“当插入速率达到每秒1000次，表数据增长至数十亿行时，开始出现性能下降，特别是大客户查询7天以上时间范围且涉及数万台设备时。”

面对数十亿设备日志的增长，团队探索通过预计算聚合（降采样）提升性能——预先计算并存储摘要数据而非重复查询原始数据。这项优化使查询性能提升1000倍，原本需要数秒渲染的图表现在可即时显示，即使针对数万台设备的7天视图也是如此。

由于PostgreSQL不会自动刷新物化视图或管理表分区，团队转向支持列存储和稀疏索引的TimescaleDB。这个基于Apache 2.0许可证的开源时序数据库作为PostgreSQL扩展，在保持完整SQL兼容性和ACID特性的同时，优化了时间戳数据的存储和查询。

通过TimescaleDB的自动分区管理和降采样功能，该中心简化了内部基础设施，将PostgreSQL扩展集成到现有环境中。Cepa总结道：“不是每个团队都需要需要100号汽油、碳陶瓷刹车和超高性能轮胎的专业赛车：虽然每个组件都能提升性能，但其维护成本和独特性会带来实际负担。对某中心许多团队而言，TimescaleDB在保持分析数据与配置数据同库存储的简易性同时，获得了专用OLAP系统的卓越性能。”

通过对比TimescaleDB压缩超表与PostgreSQL表的性能测试，Cepa测得性能提升5到35倍（具体取决于查询类型和时间范围），这主要得益于压缩技术和稀疏索引。技术社区主要质疑未选用ClickHouse的决定。Hacker News用户arunmu评论：“其放弃已用于分析的ClickHouse的理由模糊不清。ClickHouse支持JSON格式，可通过物化视图重构成更结构化的表。聚合和其他性能调优正是ClickHouse的强项。”

TimescaleDB开发公司联合创始人Ajay Kulkarni回应：“PostgreSQL配合TimescaleDB就能胜任。为何要使事情复杂化？“英国CDS解决方案架构师Jamie Lord表示：“对已投入PostgreSQL生态的团队而言，这代表引人注目的演进而非革命。在保留现有工具、知识和操作流程的同时，获得了可与专用OLAP系统媲美的分析能力。”

在DEX项目成功实施后，TimescaleDB已被某中心其他项目采纳为原始日志的聚合层，例如零信任分析与报告系统，为每秒摄入数百万行的系统生成分析和长期报告。