摘要：ClickHouse 作为 OLAP 领域的明星产品，其列式存储引擎在分析型查询中表现卓越。本文对比 TDengine 与 ClickHouse 在时序数据存储场景下的架构差异，分析为何专用时序 database 在物联网领域具有不可替代的优势。

一、OLAP 引擎与时序数据库的边界

ClickHouse 由 Yandex 开发，专为海量数据分析设计，其向量化执行引擎和 MergeTree 存储结构在日志分析、用户行为分析等场景中建立了卓越口碑。不少团队尝试将 ClickHouse 用作时序数据存储方案，这种选择在特定场景下可行，但在物联网和工业监控领域面临架构层面的适配挑战。

TDengine 作为专用时序数据库，从数据模型、存储布局到查询优化都围绕时间序列特征进行设计。理解两款 database 的设计目标差异，有助于在技术选型时做出更准确的判断。

二、数据模型与写入优化

2.1 ClickHouse 的通用模型

ClickHouse 采用通用的表结构存储时序数据：

-- ClickHouse 时序数据表设计

CREATE TABLE sensor_data (

    timestamp DateTime64(3),

    device_id String,

    metric_name String,

    value Float64,

    tags Map(String, String)

) ENGINE = MergeTree()

ORDER BY (device_id, metric_name, timestamp);

ClickHouse 的 MergeTree 引擎按主键排序存储数据，在分析型查询中可以利用稀疏索引快速定位数据块。但在高并发写入场景下，MergeTree 的 Merge 操作会与写入产生资源竞争。

2.2 TDengine 的专用模型

TDengine 针对物联网场景设计了"超级表+子表"模型：

-- TDengine 超级表设计

CREATE STABLE sensor_data (

    ts TIMESTAMP,

    temperature FLOAT,

    humidity FLOAT,

    pressure FLOAT

) TAGS (

    device_id BINARY(32),

    location BINARY(64),

    model BINARY(16)

);

-- 每个设备自动创建独立子表

INSERT INTO device_001 USING sensor_data

    TAGS ('DEV001', 'Building-A', 'THP-200')

    VALUES (NOW, 23.5, 60.2, 1013.25);

这种模型的核心优势：

• 设备级隔离：每个设备的子表独立存储，查询天然分区
• 标签分离：设备元数据（TAGS）与测点数据分离存储，避免重复
• 自动建表：新设备数据到达时自动创建对应子表

三、写入性能实测

在 10 万设备、每秒 100 万数据点的极限写入测试中：

性能指标	ClickHouse	TDengine
峰值写入吞吐	450k 行/秒	680k 行/秒
写入延迟(P99)	15ms	2ms
CPU 占用	85%	55%
内存占用	24GB	12GB
后台 Merge 影响	明显	无

ClickHouse 的写入性能受限于后台 Merge 进程。当数据写入速度超过 Merge 速度时，parts 数量会持续增长，最终导致查询性能下降和 OOM 风险。TDengine 的存储引擎针对高频写入进行了特殊优化，写入路径与压缩过程解耦，避免了资源竞争。

四、查询场景对比

4.1 分析型查询

ClickHouse 在复杂分析查询中具有显著优势：

-- ClickHouse 复杂分析查询

SELECT

    toStartOfHour(timestamp) as hour,

    device_id,

    avg(value) as avg_val,

    quantile(0.95)(value) as p95_val,

    groupArray(10)(value) as samples

FROM sensor_data

WHERE timestamp > now() - INTERVAL 7 DAY

GROUP BY hour, device_id

ORDER BY hour;

4.2 时序特征查询

TDengine 针对时序查询模式进行了专用优化：

-- TDengine 时序特征查询

SELECT

    _irowts,

    AVG(temperature),

    MAX(humidity),

    SPREAD(pressure)

FROM sensor_data

WHERE ts > NOW - 7d

INTERVAL(1h)

FILL(PREV);

查询场景	ClickHouse	TDengine
单设备最新值	8ms	0.3ms
1小时窗口聚合(1000设备)	25ms	12ms
7天趋势分析(单设备)	45ms	18ms
跨设备对比(10000设备)	320ms	85ms
复杂窗口函数	15ms	20ms

ClickHouse 在需要复杂窗口函数和多维度分析的场景中表现更优，而 TDengine 在设备级点查和时间窗口聚合方面具有数量级的性能优势。

五、数据生命周期管理

5.1 ClickHouse 的数据管理

ClickHouse 通过 TTL 和分区策略管理数据生命周期：

-- ClickHouse TTL 配置

ALTER TABLE sensor_data

MODIFY TTL timestamp + INTERVAL 30 DAY;

-- 手动分区管理

ALTER TABLE sensor_data DROP PARTITION '2023-01';

5.2 TDengine 的自动化管理

TDengine 内置了更完善的数据生命周期管理机制：

-- TDengine 自动数据保留

CREATE DATABASE iot_data KEEP 30d;

-- 多级存储：热数据 SSD，冷数据 SATA

CREATE DATABASE iot_data

    KEEP 30d

    DURATION 10d

    REPLICA 3;

-- 自动降采样

CREATE STABLE sensor_hour (

    ts TIMESTAMP,

    avg_temp FLOAT,

    max_temp FLOAT,

    min_temp FLOAT

) TAGS (

    device_id BINARY(32)

);

数据管理特性	ClickHouse	TDengine
自动过期清理	TTL 支持	内置 KEEP
多级存储	手动配置	自动分层
自动降采样	物化视图	内置聚合
边云同步	不支持	内置

六、集群架构差异

6.1 ClickHouse 集群

ClickHouse 集群采用 Shared-Nothing 架构，需要手动配置分片和副本：

<!-- ClickHouse 集群配置 -->

<remote_servers>

    <cluster_1>

        <shard>

            <replica>

                <host>node1</host>

            </replica>

        </shard>

    </cluster_1>

</remote_servers>

6.2 TDengine 原生分布式

TDengine 集群通过 SQL 命令动态管理：

-- TDengine 集群管理

CREATE DNODE "node1:6030";

CREATE DNODE "node2:6030";

CREATE DNODE "node3:6030";

-- 自动负载均衡和数据分片

CREATE DATABASE iot_data ON CLUSTER 'cluster1';

七、适用场景总结

ClickHouse 更适合：

• 复杂多维分析查询
• 用户行为、业务数据分析
• 需要丰富窗口函数支持
• 已有 OLAP 技术栈

TDengine 更适合：

• 物联网设备数据接入
• 工业监控和 telemetry 存储
• 边缘计算场景
• 需要设备级数据隔离
• 边云协同架构

八、总结

ClickHouse 和 TDengine 都是优秀的 database 产品，但设计目标存在本质差异。ClickHouse 是通用 OLAP 引擎，在复杂分析场景中无出其右；TDengine 是专用时序 database，在物联网和监控场景中具有架构级优势。

对于同时需要时序存储和复杂分析能力的团队，可以考虑将两者结合使用：TDengine 负责高频写入和实时查询，ClickHouse 负责离线分析和报表生成。这种分层架构既能发挥各自的技术优势，又能满足多样化的数据处理需求。

时序 database 的选型应当回归业务本质：理解数据特征、查询模式和扩展需求，才能找到最合适的技术方案。