TimescaleDB
问题
TimescaleDB 是什么？它和 InfluxDB 有什么区别？
答案
一、TimescaleDB 简介
TimescaleDB 是基于 PostgreSQL 的时序数据库扩展。它将 PostgreSQL 变成一个高性能的时序数据库，同时保留了 PostgreSQL 的全部功能（SQL、JOIN、索引、事务等）。
核心理念：时序数据不应该被独立存储，而应该与业务数据共存。
-- 安装扩展
CREATE EXTENSION timescaledb;
二、核心优势
| 优势 | 说明 |
|---|---|
| 标准 SQL | 完整的 SQL 支持 |
| 零迁移成本 | 基于 PostgreSQL，无需学习新语言 |
| 混合查询 | 时序数据可以 JOIN 业务表 |
| ACID 事务 | 继承 PostgreSQL 的事务能力 |
| 完整生态 | 所有 PG 工具、扩展、ORM 直接可用 |
三、核心概念：Hypertable
Hypertable（超表）是 TimescaleDB 的核心概念——外观上是一张普通表，内部自动按时间分区。
-- 1. 创建普通表
CREATE TABLE metrics (
time TIMESTAMPTZ NOT NULL,
host TEXT NOT NULL,
cpu_usage DOUBLE PRECISION,
memory_usage DOUBLE PRECISION
);
-- 2. 转换为超表（自动按时间分区）
SELECT create_hypertable('metrics', 'time',
chunk_time_interval => INTERVAL '7 days' -- 每7天一个 Chunk
);
-- 3. 之后像普通表一样操作
INSERT INTO metrics VALUES
(NOW(), 'server1', 85.3, 72.1),
(NOW(), 'server2', 60.5, 45.8);
-- 查询：完全标准的 SQL
SELECT time, host, cpu_usage
FROM metrics
WHERE time > NOW() - INTERVAL '1 hour'
AND host = 'server1'
ORDER BY time DESC;
Chunk 的优势
- 查询裁剪：只扫描相关时间范围的 Chunk
- 高效删除：过期数据直接
DROPChunk（比DELETE快 1000 倍） - 独立压缩：每个 Chunk 独立压缩，不影响新数据写入
- 并行查询：不同 Chunk 可以并行扫描
四、压缩
TimescaleDB 支持将旧数据原地压缩，压缩比通常 90~95%。
-- 开启压缩
ALTER TABLE metrics SET (
timescaledb.compress,
timescaledb.compress_segmentby = 'host', -- 按 host 分段压缩
timescaledb.compress_orderby = 'time DESC' -- 按时间排序存储
);
-- 压缩 7 天前的数据
SELECT compress_chunk(c)
FROM show_chunks('metrics', older_than => INTERVAL '7 days') c;
-- 自动压缩策略：7天前的数据自动压缩
SELECT add_compression_policy('metrics', INTERVAL '7 days');
五、连续聚合（Continuous Aggregates）
连续聚合是 TimescaleDB 最强大的功能之一——自动维护的物化视图，增量更新。
-- 创建连续聚合：每5分钟的平均CPU
CREATE MATERIALIZED VIEW cpu_5min
WITH (timescaledb.continuous) AS
SELECT
time_bucket('5 minutes', time) AS bucket,
host,
AVG(cpu_usage) AS avg_cpu,
MAX(cpu_usage) AS max_cpu,
MIN(cpu_usage) AS min_cpu
FROM metrics
GROUP BY bucket, host;
-- 设置自动刷新策略
SELECT add_continuous_aggregate_policy('cpu_5min',
start_offset => INTERVAL '1 hour',
end_offset => INTERVAL '5 minutes',
schedule_interval => INTERVAL '5 minutes'
);
-- 查询连续聚合（和查表一样）
SELECT * FROM cpu_5min
WHERE bucket > NOW() - INTERVAL '6 hours'
AND host = 'server1'
ORDER BY bucket DESC;
与手动降采样相比，连续聚合的优势：
- 增量更新：只计算新数据，不重新全量聚合
- 实时可查：最新数据会自动合并原始数据查询
- 多层嵌套：可以在 5 分钟聚合上再建 1 小时聚合
六、数据保留
-- 自动删除 30 天前的数据
SELECT add_retention_policy('metrics', INTERVAL '30 days');
-- 手动删除旧数据（比 DELETE 快 1000 倍，直接 DROP Chunk）
SELECT drop_chunks('metrics', older_than => INTERVAL '30 days');
七、与纯时序数据库对比
| 对比 | TimescaleDB | InfluxDB |
|---|---|---|
| 基础 | PostgreSQL 扩展 | 独立数据库 |
| 查询语言 | 标准 SQL | Flux / InfluxQL |
| JOIN | ✅ 支持 | ❌ 不支持 |
| 事务 | ✅ ACID | ❌ |
| 学习成本 | 低（会 SQL 就行） | 中（需学 Flux） |
| 写入性能 | 高 | 更高 |
| 压缩比 | 90-95% | 90-95% |
| 生态 | PostgreSQL 全生态 | TICK Stack |
| 适合场景 | 时序 + 业务数据混合 | 纯时序数据 |
八、实际应用场景
监控数据 + 告警
-- 查询 CPU 超过 90% 的服务器（最近 5 分钟）
SELECT host, AVG(cpu_usage) AS avg_cpu
FROM metrics
WHERE time > NOW() - INTERVAL '5 minutes'
GROUP BY host
HAVING AVG(cpu_usage) > 90
ORDER BY avg_cpu DESC;
时序数据 JOIN 业务表
-- 时序数据 JOIN 资产表，这是 TimescaleDB 的独特优势
SELECT m.host, a.team, a.location,
AVG(m.cpu_usage) AS avg_cpu
FROM metrics m
JOIN assets a ON m.host = a.hostname -- JOIN 业务表！
WHERE m.time > NOW() - INTERVAL '1 hour'
GROUP BY m.host, a.team, a.location
ORDER BY avg_cpu DESC;
常见面试问题
Q1: TimescaleDB 和 InfluxDB 该如何选择？
答案：
选择 TimescaleDB 的场景：
- 已有 PostgreSQL 基础设施
- 需要标准 SQL（团队更熟悉）
- 时序数据需要 JOIN 业务数据
- 需要事务支持
选择 InfluxDB 的场景：
- 纯时序数据（不需要关联业务数据）
- 需要极致的写入性能
- 团队熟悉 TICK Stack（Telegraf + InfluxDB + Chronograf + Kapacitor）
Q2: TimescaleDB 的 Chunk 大小如何选择？
答案：
chunk_time_interval 的选择依据：
| 写入量 | 建议 Chunk 时间 |
|---|---|
| 每天 < 1GB | 1 周 |
| 每天 1~10GB | 1 天 |
| 每天 > 10GB | 数小时 |
原则：每个 Chunk 大小控制在 25%~50% 的可用内存，保证最新的 Chunk 能被缓存在内存中。
Q3: TimescaleDB 的写入性能如何优化？
答案：
- 批量插入：使用
COPY或多值INSERT替代逐条INSERT - 关闭自动提交：一个事务内写入多条数据
- 调整 Chunk 大小：避免频繁创建新 Chunk
- 异步写入：应用层缓冲后批量写入
- 关闭不必要的索引：减少写入时的索引维护
-- 批量写入性能最佳
COPY metrics FROM '/data/metrics.csv' WITH (FORMAT csv);