★ FEATURED ARTICLE 文章目录一、先用一句话说清它是什么它和其他时序数据库比，优势在哪二、先说痛点：为什么传统方案在时序数据上一定会崩三、灵魂设计：一设备一张表 + 超级表3.1 数据模型长什么样3.2 为什么这个设计能快 10 倍3.3 那「表太多怎么管」？超级表来解决四、集群架构：虚拟节点 + 副本组4.1 六个核心概念，一次讲透4.2 分片和分区，是两件不同的事4.3 写入为什么必须走 Leader4.4 mnode 为什么不会成为瓶颈五、拆开 taosd：一个进程里塞了什么5.1 RPC 层：不用 HTTP，也不用 gRPC5.2 DNODE 模块：入口与中枢5.3 VNODE 的六个子模块5.4 MNODE：资源调度的大脑六、一次写入的完整生命周期（重点）6.1 六个阶段6.2 内存 → 磁盘：写驱动，不是读驱动6.3 落盘后生成三类文件6.4 块级预计算：聚合查询的秘密6.5 压缩：两级可选6.6 生命周期：duration 与 keep6.7 冷热分层：把老数据挪去对象存储七、参数速查：真正要紧的就这几个八、查询：为什么它敢说自己分析能力强8.1 数据类型：远不止「数字 + 时间」8.2 SQL 兼容性：迁移成本有多低九、性能实测：这些「10 倍」到底怎么来的9.1 两个最经典的压测场景9.2 存储：这是最狠的一项9.3 查询：真正拉开数量级的地方9.4 写入与降采样十、真正拉开差距的：流计算 + 数据订阅10.1 流式计算：让数据库自己算10.2 数据订阅：库内自带的消息队列10.3 黄金搭档：STREAM + TOPIC10.4 配套组件：一个都不少10.5 端口与接入方式速查十一、AI 能力：TDgpt 是什么十二、上手实战：从源码到跑起来12.1 环境准备12.2 编译12.3 安装与启动12.4 建库、建表、写数据12.5 压测：taosBenchmark12.6 集群怎么加节点12.7 验证：自己跑一遍测试12.8 打一个你自己的社区发行包12.9 部署形态速查：不必非得自己装十三、避坑清单：这几件事我见过太多次十四、什么场景该用它，什么场景别用十五、写在最后：它到底解决了什么问题一个做车联网的朋友跟我吐槽：为了存 30 万辆车每秒上报的轨迹，他们团队拼了 Kafka + HBase + Spark + Redis 四件套，运维三个人轮班，每年光机器和人力就是一笔不小的账。后来他们把整套换成了一个数据库，机器少了，人也不用轮班了。那个数据库就是 TDengine。如果你正在做物联网、工业互联网、车联网、IT 运维监控，或者任何一个「设备多、数据多、要靠时间查」的系统，这篇文章大概率能帮你省下几个月试错。我把 TDengine 的源码仓库、架构设计、数据模型、写入链路、存储引擎、流计算、数据订阅、AI 能力全部拆开讲了一遍。全文配了 7 张自绘的高清架构/流程/时序图，重点代码只留关键的那几段——看完你能自己判断：它到底该不该进你的技术选型。一、先用一句话说清它是什么TDengine 是一款开源、高性能、云原生、AI 驱动的时序数据库（Time-Series Database，TSDB）。它的定位不是「又一个数据库」，而是一个极简的时序数据处理平台：除了存时序数据，它还把缓存、数据订阅、流式计算、AI 智能体统统内置了。它能扛的规模是什么量级？每天 TB 甚至 PB 级的数据，来自数十亿个传感器和采集点。广泛用于物联网、工业互联网、车联网、IT 运维监控。在 GitHub 上，它已经攒下25.2k Star、87,903 次提交、248 位贡献者——注意，这不是一个「demo 级」的开源项目，而是从第一天就按分布式高可靠架构设计的工业级系统，而且集群功能也全部开源。它和其他时序数据库比，优势在哪维度TDengine 的答案高性能通过创新的存储引擎设计，写入和查询性能比通用数据库快 10 倍以上，存储空间不到通用数据库的 1/10云原生原生分布式设计，分区分片、存储计算分离、RAFT 一致性，支持 Kubernetes 部署，可跑在公有云 / 私有云 / 混合云极简平台内建消息队列、缓存、流式计算、AI 智能体，应用不必再集成 Kafka / Redis / HBase / Spark分析能力支持标准 SQL，并为时序场景做 SQL 扩展；超级表、存算分离、分区分片、预计算、自定义函数、AI AgentAI 智能体内置 TDgpt，连接时序基础模型、大语言模型、机器学习和传统统计算法，提供预测、异常检测、数据补全、数据分类简单易用无任何外部依赖，安装和集群几秒钟搞定；提供 REST 接口和各种语言连接器；自带命令行与运维工具核心开源核心代码包括集群功能全部开源，社区活跃图 1 · 功能全景图：中间是内核，六个方向是它真正替代掉的外部组件。这张图值得你先存下来，后面每个板块我都会展开讲。二、先说痛点：为什么传统方案在时序数据上一定会崩不理解痛点，就看不懂 TDengine 的设计。时序数据有三个和其他业务数据完全不同的特征，而传统方案对这三个特征几乎全都不友好。第一，写多读少，而且是持续高压写入。30 万辆车，每辆每秒 1 条，就是每秒 30 万次写入。传统关系库每写一行都要维护 B+ 树索引、加行锁、写 undo/redo 日志——这套机制是为「少量事务、强一致」设计的，拿来扛持续高频写入，等于让卡车去跑 F1。第二，数据永远按时间追加，几乎不更新、不删除（业务上）。但传统库依然会为每行维护索引、维护事务版本、维护回滚段。这些开销在时序场景里 100% 是浪费。第三，设备维度极高（高基数）。一个工厂几万台设备，一个城市几百万块电表。如果全部塞进一张大表，「设备 ID」这一列就会变成一个巨大且几乎无选择性的索引，查询时必须先扫索引再回表，越跑越慢。于是行业里的「标准解法」变成了堆组件：Kafka 做缓冲，扛写峰Redis 做缓存，扛实时读取HBase / Cassandra 存明细，扛海量写入Spark / Flink 做流式计算和聚合再加一个 MySQL 存元数据这套架构能跑，但代价是：四五个组件、三四种一致性模型、一套跨组件的排障流程、以及一个必须专职盯着它的团队。TDengine 的核心思路很简单粗暴：把这五个组件的活儿，用一套存储引擎和数据模型自己干完。三、灵魂设计：一设备一张表 + 超级表这是 TDengine 最值得反复琢磨的地方，也是它敢说「高基数不崩」的底气。3.1 数据模型长什么样假设你要采集电表数据。传统思路是建一张meters表，每行带一个device_id。TDengine 的思路是：每个设备单独一张表，同一类设备共用一个「超级表」做模板。-- 超级表：只是一份 schema 模板，本身不存任何一行数据CREATESTABLE meters(tsTIMESTAMP,-- 时间戳，第一列必须是时间currentFLOAT,-- 电流voltageFLOAT,-- 电压phaseFLOAT-- 相位)TAGS(locationBINARY(64),-- 标签：位置groupIdINT-- 标签：分组);超级表（STable）定义了两类东西：普通列（ts / current / voltage / phase）：随时间变化的采集量标签列（location / groupId）：设备的静态属性，每个设备只有一份然后写入数据时，子表会被自动创建：-- 一句 SQL 完成「建表 + 打标签 + 写数据」三件事INSERTINTOd1001USINGmeters TAGS('California.SanFrancisco',2)VALUES(NOW,10.3,219,0.32);d1001就是子表名，等价于「设备 ID」。它第一次出现时被自动建出来，标签被写入，数据也落库了。图 2 · 数据模型结构图：左边是模板，中间是无数子表，右边是标签的独立存储。注意三个箭头的含义——建子表这件事，是写入时自动完成的。3.2 为什么这个设计能快 10 倍把「一张大表」拆成「一设备一张表」，四个性能问题同时消失：① 锁竞争消失。一张大表，所有设备抢同一把锁；拆表之后，每张表只被一个设备写，根本不需要加锁。② 写入变成纯追加。单设备数据按时间顺序到达，落盘就是 append，没有随机 IO。传统库要维护索引、找位置插入，时序库直接往后写。③ 查询变成连续读。查某设备的某个时间段，就是在一个连续的文件块里顺序读。没有回表，没有索引跳跃。④ 压缩率暴涨。单设备的数据变化很规律（相邻时间点的值往往很接近），列式存储 + 差分编码能压得极狠——这就是「存储空间不到通用库 1/10」的来源之一。3.3 那「表太多怎么管」？超级表来解决一设备一张表听起来很美好，但你马上会问：100 万台设备就是 100 万张表，怎么管理？超级表就是答案：共用 schema：一类设备只需要定义一次，改结构不用改 100 万次标签统一索引：标签全部常驻内存并建索引，千万级标签过滤可以毫秒级返回聚合一次搞定：SELECT AVG(voltage) FROM meters GROUP BY location这种跨设备聚合，先按标签筛出符合条件的表，再只读这些表的数据块，大幅减少需要扫描的数据量建表零成本：写入即建表，不需要预先执行 100 万条 DDL而标签存储本身是一个独立的 Key-Value 结构，和时间序列数据完全分开存。这意味着：改一个设备的标签，不需要重写它的历史数据。这一点在传统宽表模型里是做不到的。一句话总结这一节：用「拆表」换掉锁和随机 IO，用「超级表 + 标签」换回可管理性和聚合能力。这个取舍是 TDengine 全部性能优势的源头。四、集群架构：虚拟节点 + 副本组单机能跑，但要上生产就得看集群。TDengine 的逻辑单元设计得非常清晰，理解下面这张图，你就理解了它 80% 的运维行为。图 3 · 集群逻辑架构图4.1 六个核心概念，一次讲透单元是什么关键点pnode物理节点：一台物理机、虚拟机或容器由 FQDN 唯一标识，系统完全依赖 FQDN 通信dnodetaosd进程在 pnode 上的一个运行实例集群里至少要有 1 个；它是集群的组成单位vnode虚拟节点，数据分片与存储的基本单元有独立的线程、内存和存储路径，彼此完全独立mnode管理节点，整个系统的大脑一个集群最多 3 个，通过 Raft 选主，强一致qnode查询节点，3.0 起为存算分离引入可与 vnode 同机，也可独立部署snode流计算节点承载CREATE STREAM的实时计算任务vgroup虚拟节点组 =副本单元副本数为 3 时，一个 vgroup 含 3 个 vnode几个必须记住的硬约束：一个 vnode 最多可容纳 100 万张表，也就是 100 万个采集点一个 vnode 里的所有表，必须属于同一个数据库副本要配 3，集群里至少得有 3 个 dnode一个设备（表）的所有数据，只放在一个 vnode 上，绝不拆散到多台机器4.2 分片和分区，是两件不同的事这是很多人混淆的地方，也是调优的关键：分片（sharding）靠 vnode 实现：3.0 使用一致性哈希决定每张表落在哪个 vnode。建库时会一次性分配好 vnode 数量，并确定每个 vnode 负责的表范围。vnode 还负责负载均衡、数据恢复、支持异构环境。分区（partitioning）靠时间实现：vnode 内部按duration参数把数据分成不同时间段的文件组。一个设备的数据量能有多大？即使每秒一条 16 字节的记录，一年原始数据也不过 0.5GB 量级——所以一个 vnode 完全扛得住，不需要把同一设备拆到两台机器上。这个判断非常重要，它避免了跨节点查询带来的复杂性。4.3 写入为什么必须走 Leader多副本环境下，写操作只能由 Leader vnode 处理，然后由它转发给 Follower。数据包会带上版本号，保证顺序一致。写入请求会等待「过半副本确认」，超时未达半数就返回失败Leader 挂掉后，Follower 会接替（Raft 选主）超出副本数上限的节点叫 learner，用于扩容和负载再均衡，通过快照追赶数据4.4 mnode 为什么不会成为瓶颈理论上所有元数据请求都要问 mnode，它岂不是单点？不会。原因在客户端驱动taosc：它会缓存 vgroup 分布信息和表的 schema。同一个应用第二次写同一张表，基本不再打扰 mnode。而且 mnode 自己也是以 vgroup 形式存储的（ID 固定为 1），天生多副本。五、拆开 taosd：一个进程里塞了什么taosd是核心服务进程，负责所有数据相关操作——写入、查询、管理。日志默认在/var/log/taos/。
阅读完成 · 觉得有帮助？
