跨国深谈← 返回←传感器数据撑爆了数据库怎么办？让 Postgres 自己变强

传感器数据撑爆了数据库怎么办？让 Postgres 自己变强

关联

人物 Kevin Ball · Brandon Purcell

公司 TimescaleDB · Tiger Data · Postgres · HyperCore · Tiger Cloud · Tiger Lake · Fluid Storage · PG vector · CERN · Postgres Connector

概念 超级表 · 数据块 · 连续聚合 · 智能体 · 编码智能体 · 零拷贝

做物联网、金融、监控这类业务的人，几乎都会遇到同一个坑：设备每秒都在上报数据，表越涨越大，PostgreSQL 越跑越慢。

换一套专门的时序数据库，又意味着拆系统、改应用、维护多条数据管道。Brandon Purcell 在 Software Engineering Daily 上聊了第三条路：不换数据库，给它装一个扩展。

他在科技行业干了很久，早年写代码，后来联合创办了地理空间分析公司 Spatial Key(在 Postgres 上跑了约 13 年后卖出)，如今是 Tiger Data 的产品管理总监。

时序数据为什么会难倒普通数据库？

传感器读数、金融行情、应用监控，这类数据有共同特点：只写入、几乎不更新，持续累积，查询时总是按时间段来查。

普通数据库为此苦不堪言：写入出现瓶颈，查询越来越慢，单表的索引越撑越大。

数据量有多大？Brandon 说他们有个客户接了 2200 万台设备，每台每几秒甚至每秒都在上报 。

而多数人的起点恰恰是 Postgres——等到撑不住了，传统做法是拆家：交易数据留在 Postgres,分析数据搬去另一个分析型数据库。

代价是多套数据管道，还得改写应用。TimescaleDB 的思路是让两者共存于同一个系统，应用一行代码都不用改。

一张表还是那张表，底层却大变样

对开发者来说，迁移过去零差异：还是那张带时间戳的表，还是同样的 SQL 。变化全在引擎内部。

核心概念叫 hypertable(超级表)。它自动按时间把数据切成一个个 chunk(数据块)。

查询近三个月的数据，规划器只碰相关的块，不会扫全表——即使你有十几年的历史、几十亿行。

每个块内部还有一套混合存储：新数据用传统的行存储，按策略自动转成列存储并压缩。

列存储配合向量化执行(一次批量处理多批数据)，查询可以快 10 到 1000 倍 。压缩率通常在 90%,最高见过 98%——因为传感器读数往往大量重复。

压缩反而更快？还有 CERN 的 70TB 变 5TB

直觉上压缩过的数据查询应该更慢，但配合向量化执行，结果恰恰相反。真实的例子：

CERN(欧洲核子研究中心)原先存了约 70TB 时序数据，迁移到 TimescaleDB 后压到 5TB,还因此能把数据整体搬到更快的固态硬盘上，性能跟着提升 。

写入端的收益同样明显。普通 Postgres 表的写入速度会随数据增长线性下滑，TimescaleDB 基本保持平稳。

在普通硬件上能做到每秒百万行以上的写入 。

通用数据库、时序数据库、向量库，能不能只要一个？

Brandon 的另一个论点是：别拆。

设备元数据放在普通表里，和超级表直接 join;向量嵌入用 pgvector(或其扩展 pgvector scale)存在同一个库里；全文检索用他们开源的 PG Text Search,据称规模可对标 Elasticsearch 。

三者组合起来能做混合搜索。而在很多公司，这意味着至少三套系统，再靠应用层拼数据。

云端的热冷分层：10 年数据，只热 2 年

Tiger Cloud 是托管服务，但更有意思的是分层存储(tiered data):设一个策略，比如 10 年数据只保留最近 2 年在本地热存储，其余 8 年自动搬到 S3,底层是 Iceberg 格式——但查起来仍是一张表，跨冷热区间查询时自动合并结果 。

还有个测试中的产品 Tiger Lake,打算和 Snowflake、Databricks 做双向同步。

给 AI 代理准备的新玩具：秒级分叉数据库

roadmap 上最超前的是 Fluid Storage:零拷贝分叉。

几秒或几分钟就能把生产数据库 fork 出一个副本，让 AI 代理或 CI/CD 流程在副本上随便折腾，改动的部分以差异形式记录，不碰生产系统 。

主持人立刻想到质量测试：如今测一个数据密集的功能，弄一份生产数据副本又慢又麻烦，这个能力正好补上缺口。

上手门槛和坑在哪？

支持 Postgres 16、17、18(刚发布的版本弃用了 15)。一条 curl 命令或 Docker 镜像就能本地跑起来。真正需要花心思的主要是两件事：

一是数据块大小调优(默认 7 天，高吞吐场景可能要缩到 1 小时，云端已有自动推荐)；

二是连续聚合的刷新策略——比如船上的设备离线一个月，回传一批数据，物化视图就得大范围重算，很耗 CPU 和磁盘 。

他们正在做的细粒度刷新只更新变化的设备，专门解决这个问题。

值得一提的还有 Postgres Connector:指向你现有的生产库，实时同步过来，让你并行测试，不用停机做备份恢复。

本集带走

• 时序数据的特点是只写不改、持续累积、按时间查询，普通 Postgres 会随数据增长出现写入和查询的线性退化。
• TimescaleDB 是 Postgres 扩展而非分叉：SQL 零变化，应用零改动，底层自动按时间分块、行存转列存压缩。
• 压缩配合向量化执行反而提速 10–1000 倍；CERN 把 70TB 压到 5TB。
• 冷数据自动分层到 S3,查询时冷热合并，仍是同一张表；Tiger Lake 将打通 Snowflake、Databricks。
• 正在开发的 Fluid Storage 支持零拷贝分叉数据库，让 AI 代理和测试环境秒级获得生产数据副本。

我们有一个客户拥有 2200 万台设备，它们全都在发出读数，每几秒一次、每秒一次，有些甚至是亚秒级的。
We have one customer that has 22 million devices and they’re all emitting readings every few seconds, every second, in some even sub-second as well.
—— Brandon Purcell · [05:34]

但当压缩数据与向量化结合时，我们看到查询加速了 10 倍到 100 倍再到 1000 倍。
But when you’re compressing the data combined with the vectorization, we’ve seen acceleration in queries 10 to 100 to 1,000 times.
—— Brandon Purcell · [08:50]

我们有客户在 Tiger Cloud 环境里，每秒有两万、三万个查询，每天打出数十亿次查询，而用的在我看来只是普通硬件，并非疯狂专用硬件。
And we have customers that are in our Tiger Cloud environment that have 20,000, 30,000 queries a second that are hitting billions of queries a day against what I would consider nominal hardware, not crazy specialized hardware.
—— Brandon Purcell · [19:26]

我想我甚至看到了构建独立智能体的可能性，它们监控你的数据库、监控系统、实时给出建议，远超开箱即用的初始开发，而这一切在幕后使用的都是同一套工具。
And I think I see even the ability to build independent agents that are monitoring your database, monitoring the system, making recommendations in real time, above and beyond just the initial development out of the box, all using the same tools behind the scenes.
—— Brandon Purcell · [47:54]