3、主流TSDB概览：InfluxDB、Prometheus、TimescaleDB、TDengine、ClickHouse的定位与特点
做日志监控系统选型，说白了就是选一个能扛住海量写入、又能快速查回来的存储引擎。市面上号称时序数据库的产品不少，但真正经得起生产环境毒打的，也就那么几个。我这些年踩过的坑不少，今天就把这几款主流TSDB的底牌给大家翻一翻。
核心观点：没有最好的TSDB，只有最适合你场景的TSDB。选型前先想清楚三个问题——写入量级多大？查询模式是聚合多还是原始数据多？团队运维能力如何？
3.1 InfluxDB：老牌劲旅，生态最成熟
InfluxDB 是我最早接触的时序数据库，2015年那会儿就开始用了。它的定位很明确——面向DevOps监控和IoT场景的通用TSDB。
核心特点：
- 类SQL查询语言（InfluxQL/Flux）：上手快，但Flux的学习曲线有点陡。我个人习惯还是用InfluxQL，简单直接。
- 数据模型：measurement + tag + field，tag建索引，field存值。这个模型很灵活，但tag基数过高时会炸内存——我在项目中遇到过某业务线把用户ID当tag，结果内存直接飙到32GB。
- 压缩率：中等偏上，实测约8:1到12:1（取决于数据类型）。
- 集群版：开源版是单机，集群版要付费。嗯，这里要注意，很多小公司用开源版扛到几百万时间线就开始吃力了。
我的经验：InfluxDB 适合中小规模（<100万时间线）的日志监控场景。如果你团队里没人愿意折腾分布式，单机版InfluxDB + 冷热数据分离，能撑很久。
3.2 Prometheus：云原生监控的事实标准
Prometheus 严格来说不算是纯粹的TSDB，它是一套完整的监控系统。但它的存储引擎确实是个时序数据库，而且做得相当出色。
定位：云原生环境下的指标监控与告警系统，Pull模型采集数据。
特点：
- 数据模型：metric + label，label就是tag。设计极其简洁，但功能强大。
- PromQL：这是我用过最优雅的时序查询语言。聚合、降采样、预测，一行搞定。举个例子：
rate(http_requests_total[5m])就能算出5分钟内的请求速率。 - 本地存储：默认只保留15天数据。我曾经踩过这个坑——某次排查历史问题时发现数据已经被自动删了，后来加了远程存储（Thanos/Cortex）才解决。
- 高基数问题：和InfluxDB一样，label值太多会导致内存爆炸。我建议把label数量控制在10个以内。
避坑指南：Prometheus 不适合存日志原文，它只适合存指标。如果你想把日志转成指标再存，那没问题。但直接存日志？别想了，它的设计就不是干这个的。
3.3 TimescaleDB：披着SQL外衣的时序数据库
TimescaleDB 是 PostgreSQL 的时序扩展。说白了，它就是在PG上加了自动分区、压缩、连续聚合这些时序特性。
定位：需要完整SQL能力、又想用时序功能的场景。比如金融交易数据、IoT设备数据。
特点：
- 全SQL支持：JOIN、子查询、窗口函数，随便用。你想想看，InfluxDB 和 Prometheus 能做到吗？做不到。
- 自动分区（Hypertable）：按时间自动创建分区表，对用户透明。我习惯把分区间隔设为1天，查询效率很高。
- 压缩率：约10:1到15:1，比InfluxDB好一些。
- 运维成本：如果你团队已经有PG DBA，那TimescaleDB几乎零学习成本。如果没有？嗯，PG的运维复杂度你懂的。
我的建议：如果你的日志监控系统需要和业务数据做关联查询（比如查某个订单的日志，同时关联订单状态），TimescaleDB 是首选。纯日志场景？它有点重了。
3.4 TDengine：国产之光，专为IoT而生
TDengine 是涛思数据的产品，我2020年开始接触。它的设计理念很激进——一个节点一个线程处理写入，把性能压榨到极致。
定位：物联网、车联网、工业互联网等超大规模时序数据场景。
特点：
- 超级表（Super Table）：一个超级表定义模板，自动为每个设备创建子表。这个设计很巧妙，查询时按设备过滤极快。
- 写入性能：单机每秒能写入数百万个数据点。我在项目中测试过，4核8G的机器，写入速度是InfluxDB的3倍以上。
- SQL兼容：支持大部分SQL语法，但有些高级功能（如窗口函数）还不支持。
- 集群：开源版就支持集群，这点比InfluxDB厚道。
避坑指南：TDengine 的强项是写入和简单聚合查询。如果你需要复杂的时序分析（比如降采样后再做傅里叶变换），它可能不太合适。另外，它的生态还在建设中，周边工具不如InfluxDB丰富。
3.5 ClickHouse：披着OLAP外衣的时序利器
ClickHouse 不是专门的TSDB，它是一个列式OLAP数据库。但它的时序处理能力，比很多专业TSDB还强。
定位：海量数据的实时分析，包括日志、监控、用户行为等。
特点：
- 列式存储：按列压缩，压缩率极高。我见过日志数据压缩到原始大小的1/20。
- 向量化执行：利用CPU的SIMD指令集，聚合查询快到飞起。比如统计百万条日志的PV，毫秒级返回。
- SQL方言：语法和标准SQL有差异，但功能强大。比如
toStartOfInterval()函数做降采样，一行搞定。 - 写入性能：批量写入极快，但单条写入性能一般。适合日志这种批量写入的场景。
我的经验：ClickHouse 不适合做实时监控的存储层，因为它的写入延迟是秒级的（批量flush）。但做日志分析平台的后端存储，它是最佳选择之一。我曾经用ClickHouse替换了Elasticsearch做日志存储，查询速度提升了10倍，存储成本降低了60%。
3.6 横向对比：一张表看懂
| 特性 | InfluxDB | Prometheus | TimescaleDB | TDengine | ClickHouse |
|---|---|---|---|---|---|
| 定位 | 通用TSDB | 监控系统 | 时序+SQL | IoT TSDB | OLAP分析 |
| 查询语言 | InfluxQL/Flux | PromQL | SQL | SQL | SQL |
| 写入性能 | 中等 | 中等 | 中等 | 高 | 高（批量） |
| 压缩率 | 8:1~12:1 | 5:1~8:1 | 10:1~15:1 | 10:1~15:1 | 15:1~20:1 |
| 集群 | 付费版 | 需扩展 | 开源 | 开源 | 开源 |
| 运维难度 | 低 | 低 | 中 | 中 | 中高 |
| 适用场景 | 中小规模监控 | 云原生监控 | 关联查询 | 大规模IoT | 日志分析 |
3.7 知识体系总览
下面这张图，我把这五款TSDB的定位和核心特点梳理了一下。你看完应该能有个整体印象。
看完这张图，你应该能理解为什么我说「没有银弹」了。每个数据库都有自己的舒适区，选型的关键是找到和你场景最匹配的那个。
总结一下：
- 中小规模监控 → InfluxDB
- 云原生环境 → Prometheus + Thanos
- 需要SQL关联查询 → TimescaleDB
- 大规模IoT → TDengine
- 海量日志分析 → ClickHouse
嗯，这五款TSDB的定位和特点就讲到这里。下一节我们会深入每个数据库的架构细节，看看它们内部是怎么设计的。到时候我会结合自己实际踩过的坑，给大家一些更具体的建议。