时序数据库入门：云上时序数据的存储、查询与选型实践

物联网、运维监控、金融行情……这些场景每天都在产生海量带时间戳的数据。这类数据"只写不改、按时间追加、按时间查询"，用传统关系型数据库存储会遭遇写入瓶颈和存储膨胀。本文从概念到实践，讲清时序数据库（Time Series Database，TSDB）是什么、怎么用、怎么选。

一、什么是时间序列数据？

时间序列数据是带时间戳、按时间顺序排列的数据。 每条记录回答一个问题：某个时刻，某个对象，某个指标是多少。

一条典型的时序数据由四要素构成：

时序数据有三个特征：只追加不改、时间戳天然有序、指标基数高。这三点决定了它需要一套专门的存储与查询设计。

二、为什么关系库不适合时序数据

1. 写入吞吐顶不住：关系库要为每条记录维护索引、日志、约束、事务，单机每秒几万条是上限；IoT 场景动辄每秒几十万到上百万点。
2. 存储膨胀：关系库按行存储，一条时序数据仅三个字段却带一整行索引与元数据开销。
3. 时间范围查询慢："查过去 7 天平均温度"这类查询关系库要全表扫描，时序库按时间分片直接定位对应时间块。

一句话：关系库是"全科医生"，时序库是"专科医生"。

三、时序库的核心机制

• 超表自动分片：一张逻辑时序表按时间窗口自动拆成多个物理子表（chunk），写入只碰当前活跃分片、查询按时间定位分片，避免全表扫描。
• 列式存储 + 时序专用压缩：差分编码（Delta-of-Delta）、Gorilla 浮点压缩等算法，把数字型时序数据的存储压到原来的十分之一甚至更低。
• 连续聚合：提前按分钟/小时/天把聚合结果算好存起来，查询直接读结果。
• 降采样 + 保留策略：高频数据抽稀成低频均值；给数据设保质期到期自动删，控制存储成本。

四、云上实践：一个最小可运行示例

以最易上手的 TimescaleDB（PostgreSQL 扩展）为例，思路对所有时序库通用：

-- 建时序表
CREATE TABLE conditions (
  time        TIMESTAMPTZ NOT NULL,
  device_id   TEXT,
  temperature DOUBLE PRECISION
);

-- 转成超表，按时间自动分片
SELECT create_hypertable('conditions', 'time');

-- 写入
INSERT INTO conditions VALUES (now(), 'device_01', 75.5);

-- 过去 7 天按小时聚合
SELECT time_bucket('1 hour', time) AS hour,
       avg(temperature) AS avg_temp
FROM conditions
WHERE time > now() - interval '7 days'
GROUP BY hour
ORDER BY hour;

云上使用时序数据库，还能获得托管运维、弹性伸缩、跨可用区高可用、冷热分层存储等能力——把冷数据自动归档到对象存储，进一步降低成本。

五、主流时序库怎么选

速记建议：

• 纯 IoT / 监控采集 → TDengine 或 InfluxDB
• 已有 PostgreSQL 技术栈、要复杂分析 → TimescaleDB
• 时序数据与业务数据频繁关联、走信创 → 金仓 KES TimeSeries
• 只搭监控看板 → Prometheus

各产品性能数字来自不同测试口径，横向直接比无意义，拿自己的数据量做 POC 才是正路。

六、什么时候别用时序库

• 数据是强关系型的（订单、用户、账户，主外键满天飞）
• 数据量没到量级（一天几万条，关系库绰绰有余）
• 需要复杂事务和多表 JOIN（专用时序引擎在这块是短板）

选数据库的第一原则不是"哪个技术新"，而是"你的数据长什么样"。

小结

一天 8.64 亿条带时间戳的数据，不是"换更贵机器"的问题，而是"换对数据库类型"的问题。让海量时序数据存得下、写得进、查得快、还省钱，这就是时序数据库存在的理由。

本文基于公开信息独立撰写，不代表任何厂商立场。
李白客，信创行业独立观察者。关注数据库、AI基础设施与国产化替代。