时序数据库入门：什么是 TSDB？时序库与关系型数据库对比、主流产品选型指南（2026）

一篇关于时间序列数据库（TSDB）的入门科普，关键词覆盖：什么是时序数据库、时序数据库和关系数据库的区别、主流时序数据库对比。不写通稿，只说人话。

阅读时间：约 10 分钟 | 标签：#时序数据库 #TSDB #数据库选型

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

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

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

概念	说明	示例
timestamp	时间戳	`2026-09-09 10:00:00`
metric	指标名	`cpu_usage`、`temperature`
tag	标签/维度	`device_id=01`、`region=beijing`
field	数值	`75.5`

三个特征决定了它的存储与查询方式：写多读少、只追加不更新；时间戳天然有序；指标基数高（一台设备一个 ID）。

二、什么是时序数据库（TSDB）？

时序数据库（Time Series Database，TSDB）是专门为海量带时间戳数据设计的数据库，围绕"时间"做存储、索引、压缩、聚合的整套优化。

判断是否属于 TSDB 射程很简单：数据主要靠时间戳组织和查询 → 用时序库；靠主外键关系组织 → 用关系库。

三、时序数据库 vs 关系型数据库

关系型数据库存时序数据，有三个硬伤：

写入吞吐：关系库要为每条记录维护索引、日志、约束、事务，单机每秒几万条是极限；工业 IoT 场景动辄每秒几十万到上百万点。
存储膨胀：关系库按行存储，一条时序数据仅三个字段却带一整行索引与元数据开销；时序库用列式存储 + 时序专用压缩（Delta-of-Delta 差分、Gorilla 浮点压缩），压缩比可达 10:1。
时间范围查询："查过去 7 天平均温度"关系库要全表扫描，时序库按时间分片直接定位时间块。

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

四、主流时序数据库对比（2026）

1. 专用时序引擎

产品	出身	特点	注意点
InfluxDB	国外开源	生态最成熟，InfluxQL/Flux 查询	开源版不支持集群，商用授权收费
TDengine	国产（涛思数据）	超级表模型，写入/压缩性能突出	SQL 兼容性有限
IoTDB	国产（Apache）	树形设备层级，边缘强	通用场景生态略弱
Prometheus	CNCF	监控领域事实标准	不算通用时序库

2. 关系型扩展

TimescaleDB：PostgreSQL 扩展，用 Hypertable（超表）按时间自动分区，完整 SQL + PG 生态。适合已有 PG 技术栈、需要复杂 SQL 分析的团队。

3. 融合多模（国产代表：金仓 KES TimeSeries）

金仓 KES TimeSeries 是 KingbaseES V9 内嵌的时序能力，走"融合多模"路线------时序表、关系表、GIS、向量在同一个库里，一条 SQL 就能做时序数据与业务表的 JOIN，不用 ETL 搬数据：

超表自动分片：一张逻辑时序表按时间窗口自动拆成多个 chunk（物理子表），写入只碰当前活跃分片、查询按时间定位分片，标准 SQL 即可操作。
列式存储 + 时序专用压缩：Delta-of-Delta 差分编码、Gorilla 浮点压缩，典型数字型时序数据压缩比约 10:1。
性能与生态：官方披露 TSBS 基准写入超 124 万指标点/秒；兼容 InfluxDB 协议，现有 Telegraf 采集可平滑迁移，降低迁移门槛。
落地案例：北京轨道交通应急指挥调度平台中，写入性能较原系统提升 10 倍以上，历史分析从分钟级缩短到秒级，时序数据存储占用降低 70%--80%。

上手代码示例

InfluxDB 行协议（写入）：

复制代码

weather,location=beijing,device_id=01 temperature=23.5,humidity=61 1757385600000000000

这条行协议金仓 KES TimeSeries 也兼容------它提供 InfluxDB 协议接口，Telegraf 采集配置不用大改，就能把数据平滑切到金仓。

TimescaleDB 建超表 + 时间桶聚合（SQL）：

sql 复制代码

CREATE EXTENSION IF NOT EXISTS timescaledb;

CREATE TABLE conditions (
  time        TIMESTAMPTZ NOT NULL,
  device_id   TEXT,
  temperature DOUBLE PRECISION
);

SELECT create_hypertable('conditions', 'time');

-- 过去 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;

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

五、三个核心机制

连续聚合（Continuous Aggregation）：提前按分钟/小时/天把数据算好存起来，查询直接读结果，用存储换查询速度。
数据保留策略（Retention Policy）：给数据设保质期（原始存 30 天、降采样存一年、到期自动删），防止存储被历史数据吃光。
降采样（Downsampling）：高频数据抽稀为低频均值，趋势还在、存储省 99%。

六、时序数据库选型建议

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

什么时候别用时序库：数据是强关系型的（订单/用户/账户）；数据量没到量级（一天几万条）；需要复杂事务和多表 JOIN（专用时序引擎是短板）。

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

结语

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

本文基于公开信息独立撰写，不代表任何厂商立场。

李白客，信创行业独立观察者。关注数据库、AI基础设施与国产化替代。