主流时序数据库（Time-Series Database, TSDB）按核心定位一般分成四大类：
- SQL/分析型：TimescaleDB、ClickHouse（时序引擎/物化视图）、QuestDB、InfluxDB 3
- 观测/监控型：Prometheus（本地 TSDB）、VictoriaMetrics、M3DB（Uber）
- 工业/IoT 场景型：TDengine、Apache IoTDB
- 公有云托管型：Amazon Timestream、Azure Data Explorer（Kusto/ADX）
一、各产品要点
TimescaleDB（基于 PostgreSQL）
- 概念：以 Hypertable 做时间/空间分片；连续聚合（Continuous Aggregates） 预计算并支持实时补数；列式压缩。适合需要标准 SQL/Join/事务一致性的场景。
- 典型优势：与 Postgres 生态无缝（FDW、工具链），迁移门槛低；运维难度较低。
- 注意点：极端高写入/高基数下需精心分区与策略（但多数业务足够用）。
ClickHouse（OLAP）用于时序
- 做法：通过 AggregatingMergeTree、物化视图 或 TimeSeries 表引擎 实现大规模时序预聚合与查询加速。适合日志/指标统一分析与复杂多维报表。
- 优势：极强的聚合/扫描性能、实时/近实时分析。
- 注意点：建模与物化链路需要数据工程实践；写入乱序与去重策略要设计好。
QuestDB
- 概念：专注超高吞吐写入 + 低延迟 SQL，引擎零 GC（Java/C++），分层存储（WAL→本地→对象存储 Parquet）。在资本市场等低延迟场景表现突出。
- 优势：标准 SQL（带时序扩展）、极简部署、对乱序写入优化。
- 注意点：生态相对 Timescale/ClickHouse 较新，功能取舍偏实时交易/监控。
InfluxDB 3（IOx 重构）
- 概念：核心引擎重写为 Rust + Apache Arrow + DataFusion + Parquet（FDAP 栈），统一以 DataFusion 执行计划驱动读写与压实；SQL/InfluxQL/Flux 统一到同一执行层。
- 优势：对象存储友好、跨生态互操作性强（Arrow/Parquet）。
- 注意点：从 v2→v3 跨代差异较大，功能/生态需以 v3 文档为准。
Prometheus（内置 TSDB）
- 概念：CNCF 事实标准的监控系统；本地 TSDB 以 WAL + 块文件 存储，配合远端写扩展到多租户/长保留方案（Cortex/Thanos/Victoria 等）。
- 优势：指标采集与告警闭环、社区生态最大。
- 注意点：单机为主，长时保留/多区域往往借助远端存储或外部 TSDB。
VictoriaMetrics
- 概念：为监控/指标优化的 TSDB，单机即可顶替中等规模集群；亦有集群版。强调高基数与低资源占用。
- 优势：部署简洁、性价比极高，兼容 PromQL/远端写。
- 注意点：极端超大规模/超高并发下需按官方建议选择单机或集群模式。
M3DB（Uber）
- 概念：为大规模长保留指标打造的分布式 TSDB，兼容 Prometheus 生态；使用 M3TSZ 等压缩算法。
- 优势：水平扩展、多租户、与 Prometheus 远端写配合成熟。
- 注意点：组件多、运维复杂度较高，适合大公司平台型团队。
TDengine
- 概念：面向工业 IoT 的 TSDB/流式计算一体化平台；snode 流处理、内置订阅/计算管道，开源含集群能力。
- 优势：写入与压缩针对时序深度优化；端云协同/流水线算子友好。
- 注意点：SQL/生态与通用数仓不同，需要按其范式建模与运维。
Apache IoTDB
- 概念：工业物联网取向，边云协同、超高压缩、面向设备/点位的时序元数据管理；分布式引擎含类 LSM 写入。
- 优势：面向设备层抽象、协议适配丰富，适合海量点位与边缘场景。
- 注意点：通用 BI/SQL 生态对接需要网关或中间层。
Amazon Timestream（托管）
- 概念：**内存层 + 磁盘层（磁性存储）**分层与生命周期策略，免运维、自动多 AZ。
- 适用：全托管/Serverless，写多读快的物联网/应用遥测。
- 注意点：云厂商锁定，成本与查询特性需结合用量评估。
Azure Data Explorer / Kusto（ADX）
- 概念：基于 KQL 的大规模遥测/日志/时序分析服务，内置make-series、异常检测、季节性/趋势分解等函数族；微软官方主推替代已退役的 TSI。
- 优势：查询语言对时序分析一等公民，交互式/近实时分析强。
- 注意点：学习 KQL；最佳在 Azure 体系内使用。
二、横向对比（精要）
| 维度 | TimescaleDB | ClickHouse(时序) | QuestDB | InfluxDB 3 | Prometheus | VictoriaMetrics | M3DB | TDengine | Apache IoTDB | Timestream | ADX/Kusto |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 主要定位 | SQL/OLTP+时序 | OLAP/时序分析 | 低延迟SQL&高吞吐 | Arrow/对象存储友好 | 监控采集/告警 | 监控长保留/高性价比 | 大规模多租户指标 | 工业IoT一体化 | 工业IoT/边云 | 托管IoT/遥测 | 托管日志/遥测/时序 |
| 语言/接口 | 标准 SQL | SQL | SQL | SQL/InfluxQL/Flux | PromQL | PromQL | PromQL/Graphite | SQL 类/函数 | 专用查询/多协议 | SQL 类/函数 | KQL |
| 预聚合 | 连续聚合 | 物化视图/聚合树 | SQL+索引 | DataFusion 执行 | 录入即聚合少 | TS 优化 | 聚合+保留 | 流计算内建 | 内置算子 | 分层+计划查询 | make-series 等 |
| 写入场景 | 中高 | 极高 | 极高 | 高 | 中（单机） | 高（单机/集群） | 极高（分布式） | 高 | 高 | 高 | 高 |
| 高基数 | 中 | 高 | 高 | 高 | 受限（需分摊） | 高（强调） | 高 | 中-高 | 中-高 | 高 | 高 |
| 运维复杂度 | 低-中 | 中 | 低 | 中 | 低 | 低 | 高 | 中 | 中 | 低 | 低 |
| 典型场景 | BI/报表/风控 | 海量日志/指标分析 | 交易/行情/低延迟 | 统一湖仓/IoT | 应用监控 | 大规模监控存储 | 大厂级监控平台 | 工业 IoT 平台 | 工业设备/点位 | 免运维 IoT | Azure 体系分析 |
（表内概括基于官方文档与实践报道，细节随规模/建模而变。参考文档见下方引用。）
三、性能与基数（cardinality）要点
- Prometheus 家族：单机 TSDB 简洁高效，但高基数（标签组合爆炸）会吃内存与查询性能，常用做法是远端写到 VictoriaMetrics/M3 等进行长保留与降本。
- OLAP/SQL 系（ClickHouse/QuestDB/InfluxDB3）：通过列式+压缩+预聚合（物化视图/Parquet 压实）来维持扫描效率；设计好分区键/排序键是关键。
- 工业 IoT（TDengine/IoTDB）：对乱序写入、点位元数据、极高压缩比做了专门优化，并内置流处理/计算，更贴近边—云一体的工程落地。
四、选型建议（按应用画像）
- 应用监控/告警为主（PromQL 生态）：
- 单集群中等规模 → VictoriaMetrics（单机或 HA）；
- 超大规模/多租户/超长保留 → M3DB 或 VictoriaMetrics 集群。
- 需要标准 SQL、与现有 Postgres/BI 深度融合：
- 以报表/风控/多表 Join 为主 → TimescaleDB；
- 海量日志+复杂聚合 → ClickHouse（物化视图/TimeSeries 引擎）。
- 超高吞吐与低延迟（交易/行情/风控回放）：
- 优先考虑 QuestDB，其在交易所/撮合侧有成功案例；也可评估 ClickHouse 的实时链路。
- 对象存储友好 + 跨生态（Arrow/Parquet）互通：
- InfluxDB 3（IOx）：统一 DataFusion 计划，利于湖仓一体与下游工具协作。
- 工业 IoT/边云协同/内置流处理：
- TDengine（snode/流式算子）或 Apache IoTDB（设备元数据/压缩/边云）；需要端侧/协议适配与工程化能力时更有优势。
- 全托管/少运维：
- Amazon Timestream（内存层+磁盘层分级与生命周期策略）；
- Azure Data Explorer（KQL 原生时序函数，TSI 已退役转向 ADX）。
五、实践落地的三条通用原则
- 建模先行：选择合适的时间分区、主键/排序键、标签设计，避免高基数爆炸；Prometheus 指标应规范维度并控制 label cardinality。
- 冷热分层/预聚合：对长周期看板用 连续聚合/物化视图；热数据保留在内存或高速层，冷数据下沉到列式/对象存储（Parquet）。
- 观测与再平衡：监控写入乱序、压缩比、查询热点；在 VictoriaMetrics/M3/ClickHouse 上按官方指导做分片与压实调优。
六、进一步资料（核心来源）
- InfluxDB 3 的 FDAP/Arrow/DataFusion 架构与重构目标。InfoQ+2 InfluxData+2
- TimescaleDB 连续聚合/压缩与实战经验。docs.timescale.com+2 tigerdata.com+2
- ClickHouse 的 AggregatingMergeTree、物化视图与 TimeSeries 表引擎。ClickHouse+2 ClickHouse+2
- Prometheus 存储模型（WAL/块）与远端写生态（Cortex）。Prometheus+1
- VictoriaMetrics 架构与高基数注意事项。docs.victoriametrics.com+2 docs.victoriametrics.com+2
- M3DB 架构/压缩（M3TSZ）与 Uber 实践。M3+2 M3+2
- TDengine 流处理架构与工业 IoT 定位。docs.tdengine.com+2 docs.tdengine.com+2
- Apache IoTDB 工业场景与分布式引擎。IoTDB Website+1
- Amazon Timestream 分层存储与生命周期策略。AWS 文档+1
- Azure Data Explorer / KQL 的时序分析函数与 TSI 退役动向。Microsoft Learn+2 Microsoft Learn+2