时序数据库深度剖析：从存储引擎到查询优化的全方位实战

引言：为什么传统数据库扛不住时间序列？

在物联网、监控告警、金融行情、DevOps 运维等场景中，时间序列数据无处不在。这类数据有三个显著特征：写入量大（每秒百万级数据点）、追加写为主（极少更新删除）、时间范围查询为主（最近 N 分钟/小时/天的聚合分析）。传统关系型数据库在处理这类负载时往往力不从心，时序数据库（Time-Series Database, TSDB）应运而生。

本文将深入剖析三大主流时序数据库——InfluxDB、TimescaleDB、ClickHouse——的存储引擎设计原理、数据压缩策略、查询优化机制，并结合生产级场景给出架构选型指南。

一、时序数据的存储模型设计

1.1 数据模型：Measurement Tag Field Timestamp

InfluxDB 提出了一套经典的时序数据模型：

• Measurement：等价于表名，定义数据的类别（如 cpu、temperature）
• Tag：键值对索引，用于分组和过滤（如 host=server01, region=us-west）
• Field：实际数据值（如 usage_user=35.2），不建索引
• Timestamp：纳秒级时间戳，作为主键的一部分

这种模型的精髓在于：Tag 建索引支持高效过滤，Field 不建索引但高效压缩存储。TimescaleDB 则沿用了关系模型的 hypertable 抽象，将时间自动分区，对 DBA 更友好。

1.2 列式存储 vs 行式存储

ClickHouse 采用纯粹的列式存储（MergeTree 引擎家族），每列独立压缩。对于时序查询中常见的 SELECT avg(temperature) FROM metrics WHERE time