惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

C
Check Point Blog
S
Schneier on Security
P
Privacy & Cybersecurity Law Blog
S
Security @ Cisco Blogs
W
WeLiveSecurity
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Microsoft Azure Blog
Microsoft Azure Blog
NISL@THU
NISL@THU
T
Troy Hunt's Blog
L
LangChain Blog
L
LINUX DO - 最新话题
T
The Exploit Database - CXSecurity.com
Engineering at Meta
Engineering at Meta
N
News and Events Feed by Topic
A
About on SuperTechFans
N
Netflix TechBlog - Medium
P
Proofpoint News Feed
MyScale Blog
MyScale Blog
Martin Fowler
Martin Fowler
Y
Y Combinator Blog
H
Heimdal Security Blog
aimingoo的专栏
aimingoo的专栏
T
Threat Research - Cisco Blogs
SecWiki News
SecWiki News
Microsoft Security Blog
Microsoft Security Blog
T
Tenable Blog
P
Proofpoint News Feed
H
Hacker News: Front Page
G
GRAHAM CLULEY
I
Intezer
V
V2EX
S
Secure Thoughts
Stack Overflow Blog
Stack Overflow Blog
H
Help Net Security
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
人人都是产品经理
人人都是产品经理
博客园 - 聂微东
Latest news
Latest news
Recent Announcements
Recent Announcements
Hugging Face - Blog
Hugging Face - Blog
腾讯CDC
博客园_首页
Webroot Blog
Webroot Blog
博客园 - 三生石上(FineUI控件)
AI
AI
N
News | PayPal Newsroom
Google DeepMind News
Google DeepMind News
Security Archives - TechRepublic
Security Archives - TechRepublic
B
Blog RSS Feed
美团技术团队

博客园 - 若-飞

企业AI Agent落地的核心逻辑与路径 基于langchain,Function Call的成功率怎么解决? LangChain Checkpoint(检查点)是什么?—— Agent 的"存档机制" RAG 设计:Embedding 如何切分 AI 客服系统设计:RAG 知识库设计 Go 百万连接服务器设计:从网卡到业务的全链路解析 深度解析 sync.Pool:从设计哲学到生产实践 Goroutine 泄漏:原因、检测与防范 Go Channel 关闭与超时机制完全指南 Go Map 无限增长问题解决方案 LangChain 聊天记录压缩:原理、机制与实战 揭开 sklearn 文本分类的核心原理:从词袋到逻辑回归 大模型“胡说八道”怎么办?一张图读懂检测、评估与修复全方案 企业级AI知识库权限隔离设计:让AI“懂规矩”比“懂知识”更重要 RAG系统设计全解析:从架构到多模态的核心知识图谱 RAG召回率提升全攻略:7大核心方法让检索更精准 RAG召回率提升秘籍:Metadata过滤的底层原理与实践 构建更好的RAG系统:深入理解混合搜索 一文搞懂 RAG 中 Retriever 和 Reranker 的区别 一文搞懂 RAG 的召回率(Recall)是什么? LangChain / LangGraph、MCP、Harness Engineer 与 Claude Code 的对应关系 Agent Harness 技术笔记:从 Trajectory 到 Function Calling Loop BLEU 是什么?——从原理到工程实践 一文讲清:Approve / Permit / Permit2 的本质区别 分库分表后跨分页查询的完整方案 ai如何处理私有数据 ai幻觉是啥,以及如何解决 别再让大模型“凭空瞎猜”了!带你认识AI最强外挂:ChromaDB 用 useQuery 管请求:TanStack React Query 入门小结 HD钱包--BIP44 TRON 四种 API 面怎么选:从节点协议到 JSON-RPC 再到 TronGrid 以太坊节点存储与共识机制全解析 BSC节点发现协议全解析:UDP发现、Bootnode引导与Gossip交易广播 以太坊节点发现背后的分布式哈希表(DHT)与 Kademlia 原理解析 Solidity中的bytes与string:深入理解这两种特殊的动态数组 智能合约自毁:当资产还在,合约死了 —— 深度解析 selfdestruct 导致的资产锁定风险 TDengine CLI (taos) 使用指南 —— Docker 本地开发实战 在 macOS 上用 DBeaver 连接 TDengine:踩坑总结与最终配置指南 Solidity Storage Slot 深度解析 Geth Snapshot Export/Import 深度解析: 不是备份工具,而是数据分析利器 基于BSC 公链的数据备份与 Snapshot 机制深度解析 Docker 共享内存完全指南:从原理到实践,避免常见的理解误区 Docker容器"僵尸状态"问题排查与自动重启方案 SSE协议深度解析:被低估的HTTP服务器推送标准 Proxmox 启用 QEMU Guest Agent 实战指南 解决 Blockscout "batch too large" 错误的完整指南 一文讲清楚什么是基准测试(Benchmark) Rust中的宏(Macro):编译时的代码生成魔法 Docker优雅关闭的艺术:为什么stop_grace_period能防止数据丢失 为什么 Go 没有依赖注入和 Bean 机制?语言设计哲学对比
TDengine vs MySQL:时序数据处理的时代之选
若-飞 · 2026-01-06 · via 博客园 - 若-飞

引言:当通用数据库遇上专用引擎

在数据洪流的时代,每秒都有数以亿计的传感器、设备、应用在产生带时间戳的数据。面对这种时序数据的爆发式增长,传统的通用数据库开始显得力不从心。今天,我们就来深入对比一下传统数据库代表 MySQL 和时序数据库新星 TDengine,看看在不同场景下,它们各自的表现如何。

一、核心理念对比:通用工具 vs 专用武器

MySQL:瑞士军刀

  • 设计哲学:通用关系型数据库,追求ACID、支持复杂查询

  • 适用场景:OLTP交易系统、内容管理、ERP等

  • 数据模型:行存储,基于B+树索引

TDengine:精准手术刀

  • 设计哲学:专为时序数据优化,追求极致性能和压缩

  • 适用场景:物联网、监控系统、工业互联网

  • 数据模型:列存储,LSM树结构,按时间线组织

二、架构差异:单一大厦 vs 微型公寓群

数据组织方式

-- MySQL:所有住户住在一栋大厦里
-- 表结构:所有设备数据混杂
CREATE TABLE all_sensors (
    id BIGINT PRIMARY KEY,
    device_id VARCHAR(50),
    ts TIMESTAMP,
    value FLOAT,
    INDEX idx_device (device_id),
    INDEX idx_ts (ts)
);

-- TDengine:每个住户有自己的微型公寓
-- 超级表模板 + 子表实例
CREATE STABLE sensors (ts TIMESTAMP, value FLOAT)
TAGS (device_id BINARY(50), location BINARY(100));

-- 自动为每个设备创建子表
-- sensor_001, sensor_002, ... 各自独立

物理存储对比

MySQL存储(混乱但有序):
  时间戳1: [设备A数据, 设备B数据, 设备C数据...]
  时间戳2: [设备A数据, 设备B数据, 设备C数据...]
  → 按时间全局排序,不同设备数据交错

TDengine存储(分而治之):
  设备A: [时间戳1数据, 时间戳2数据, 时间戳3数据...]
  设备B: [时间戳1数据, 时间戳2数据, 时间戳3数据...]
  → 按设备隔离,每个设备数据连续存储

三、性能实测:数量级的差异

写入性能对比(单节点)

查询性能对比

-- 场景:查询单个设备24小时数据,每秒一个点(86400个点)

-- MySQL查询(使用索引)
SELECT * FROM all_sensors 
WHERE device_id = 'sensor_001' 
  AND ts BETWEEN '2024-01-01' AND '2024-01-02'
ORDER BY ts;
-- 耗时:500ms-2s(需要索引查找+回表)

-- TDengine查询
SELECT * FROM sensor_001 
WHERE ts BETWEEN '2024-01-01' AND '2024-01-02';
-- 耗时:10-50ms(直接顺序读取文件)

聚合查询对比

-- 场景:计算1000个设备过去24小时每5分钟的平均值

-- MySQL:灾难性的性能
SELECT 
    FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(ts)/300)*300) as time_bucket,
    device_id,
    AVG(value)
FROM all_sensors
WHERE ts >= NOW() - INTERVAL 1 DAY
GROUP BY time_bucket, device_id;
-- 需要扫描整个时间范围的数据,性能极差

-- TDengine:专为这种查询优化
SELECT 
    AVG(value)
FROM sensors
WHERE ts >= NOW() - 1 DAY
GROUP BY device_id, INTERVAL(5m);
-- 利用预计算和列存优势,秒级返回

四、功能特性对比表

五、运维复杂度对比

MySQL时序方案运维挑战

# 需要的组件堆栈:
- MySQL集群:主从复制
- Redis:缓存热数据
- Kafka:消息队列缓冲写入
- Flink/Spark:流式计算
- 监控系统:Prometheus + Grafana

# 运维任务:
1. 定期分区维护
2. 索引优化
3. 查询重写
4. 容量规划
5. 多组件协调

TDengine一体化运维

# 单一组件完成:
- 数据采集:内置taosAdapter
- 缓存:自动内存管理
- 消息队列:写入即缓冲
- 流计算:连续查询
- 存储:自动压缩分区

# 运维任务:
1. 配置保留策略
2. 监控基础指标
3. 定期备份(可选)

六、真实场景选择指南

选择MySQL,当...

  1. 数据关联复杂:需要多表JOIN、复杂子查询

  2. 事务要求严格:需要强一致性保证

  3. 数据结构多变:频繁修改表结构

  4. 已有生态绑定:团队熟悉MySQL,应用已适配

  5. 设备数较少:少于1000个,写入频率低

选择TDengine,当...

  1. 数据量爆发增长:设备数>1000,频率>1次/分钟

  2. 存储成本敏感:需要高压缩节省成本

  3. 查询模式固定:主要是时间范围查询和聚合

  4. 实时分析需求:需要流式计算和实时告警

  5. 简化架构:希望减少组件数量

  6. 典型时序场景:物联网、监控、金融行情

七、混合架构实践

聪明的架构师不会非此即彼,而是合理混用:

具体实现:

-- TDengine处理实时数据
INSERT INTO devices VALUES (NOW(), 'sensor_001', 23.5);

-- 定期同步聚合结果到MySQL
INSERT INTO mysql_daily_stats
SELECT 
    DATE(ts) as stat_date,
    device_id,
    AVG(value) as avg_value,
    MAX(value) as max_value
FROM devices
WHERE ts >= CURDATE() - INTERVAL 1 DAY
GROUP BY device_id;

八、迁移策略

如果要从MySQL迁移到TDengine:

步骤1:并行运行

旧系统:MySQL(继续服务)
新系统:TDengine(新数据写入)
            ↓
        数据双写
            ↓
      验证结果一致性

步骤2:历史数据迁移

# 1. 导出MySQL历史数据
mysqldump --where="ts>'2023-01-01'" iot_db sensor_data > history.sql

# 2. 转换为TDengine格式
python convert_to_taos.py history.sql > taos_data.csv

# 3. 批量导入TDengine
taos -c /etc/taos/ -s "INSERT INTO sensors FILE 'taos_data.csv'"

步骤3:切换查询流量

# 配置查询路由
location /api/sensor-data {
    # 新数据查询走TDengine
    if ($timestamp > '2024-01-01') {
        proxy_pass http://tdengine-api;
    }
    # 历史数据查询走MySQL
    proxy_pass http://mysql-api;
}

九、未来展望

MySQL的时序优化

MySQL也在进化:

  • 8.0的窗口函数增强

  • HeatWave引擎的列存支持

  • 更多的时序函数

TDengine的生态扩展

TDengine正在:

  • 加强云原生支持

  • 扩展更多数据源连接器

  • 完善企业级功能(审计、加密等)

结论:没有银弹,只有合适的选择

经过全面对比,我们可以得出以下结论:

MySQL仍然是

  • 复杂业务系统的首选

  • 需要强事务保证场景的不二选择

  • 团队技术栈成熟时的稳妥方案

TDengine专精于

  • 海量时序数据的高效处理

  • 物联网和监控系统的理想选择

  • 对成本和性能有极致要求的场景

终极建议

  • 如果你在构建新的物联网平台或监控系统,首选TDengine

  • 如果你的系统已经基于MySQL运行良好,设备量不大,保持现状

  • 如果你面临MySQL性能瓶颈,设备量超过千级,认真考虑TDengine

时序数据的时代已经到来,选择合适的工具比盲目追求技术潮流更重要。TDengine和MySQL不是取代关系,而是在不同战场各展所长的伙伴。理解它们的差异,根据你的业务需求做出明智选择,这才是技术决策的艺术所在。