【TDengine】LSM 在 TDengine中的使用

Log Structured-Merge Tree（简称 LSM Tree）是一种分层、有序、基于硬盘的存储结构，广泛应用于数据库系统中，尤其是在设计用于处理时间序列数据的数据库时，如 TDengine。

你是否还在为物联网设备每秒百万级数据写入导致的存储瓶颈发愁？是否因数据库崩溃丢失关键监控指标而彻夜排查？TDengine作为专为工业物联网设计的时序数据库，通过创新融合LSM树（Log-Structured Merge Tree，日志结构合并树）与WAL（Write-Ahead Logging，预写日志）技术，构建了一套高性能数据持久化方案。本文将拆解这套组合拳的底层逻辑，读完你将掌握： - LS...

消息队列积压告警经常被当成「加机器」。单个分区被热点 key 打满、消费者线程卡在下游、或误把 Offset 重置到 earliest。乱会让下游重放几天数据。本文面向中级中间件 / 应用运维，覆盖开源 Kafka 与托管 MSK 都能用的只读命令。不讲如何从零搭集群，也不重复 ISR/副本不足类故障。先--dry-run，再停消费者，最后--execute# 必须先停掉所有该 group 的消费者Lag 先看是否在线、是否倾斜、是否生产突刺。加分区救不了已经堆在热点分区上的数据。

基于对 TDengine 的定义和理解，笔者将会在本篇文章中从 TDengine 能解决什么问题、它的优势与亮点、它与其它数据库的区别等维度展开详述，希望能帮助到对 TDengine 感兴趣的小伙伴。

TDengine作为专业的时序数据库，其核心技术优势体现在针对时序数据特点优化的存储架构。系统采用vnode作为基本存储单元，内部划分为WAL、元数据和时序数据三部分：元数据采用B+Tree结构实现高效查询；时序数据基于LSM结构设计，结合MemTable中的红黑树和跳表索引，确保海量数据下的高性能读写。独创的行列存储格式针对不同数据特征（稠密/稀疏）采用Tuple和Key-Value两种编码策略，配合列式存储的压缩算法，实现空间与性能的平衡。TSDB引擎通过时间分片、预计算等机制进一步优化查询效率，形成完

TDengine 引擎为什么这样快

不同的索引区别在哪里？时序数据库又应该如何选择索引方式实现科学的数据结构？本文将以 TDengine 为例为大家展开分析。

LSM 树的设计哲学极其巧妙：它彻底放弃了在磁盘上的原地更新，而是将所有的数据修改（包括插入、更新和删除）全部转化为在内存中的追加，以及后续在磁盘上的顺序写入。当内存表的数据量达到预设的阈值后，系统会将其瞬间“冻结”为不可变的结构，并由后台线程以纯顺序的方式刷入磁盘，形成持久化的 SSTable（Sorted String Table）文件。随着数据量的暴增，B+ 树的层级不断加深，写入一条简单的温度数据可能需要触发多次磁盘随机 I/O，最终导致整个 时序数据库 的吞吐量呈现断崖式的崩塌。

TDengine 存储引擎揭秘：如何实现 10 倍性能与 50 倍压缩？

tdengine技术实践

同一个数据库，三种进门方式：WebSocket 走 6041、REST 也走 6041、Native 独占 6030。端口背后藏着协议实现的本质差异。读懂这里，你才能写出公平的基准测试，也才知道日常开发该走哪扇门。

第 7 篇的模拟器里，电机设备的振动超过 0.18 就报状态码 2、超过 0.35 报 3——但这两个阈值是写死在模拟器里的。真实系统不能这样：阈值得能配、能停用、能按设备类型区分。这篇讲告警引擎：规则存 PostgreSQL，遥测在 TDengine，evaluate 实时跨库求值，一条规则从创建到触发的完整旅程。

前 9 篇，系统是跑在单机上的：一个 TDengine 容器，REPLICA 1，数据只有一份。节点挂了，数据还在盘上，但服务没了。这一篇把部署换成三节点集群，REPLICA 3，然后真的停掉一个节点做故障演练——看看查询还能不能继续。这也是本系列最后一篇：从部署到高可用，一条遥测数据的旅程完整闭环。

第 4 篇我们搭好了写入管线，背压、攒批、并发 worker 都就位了。可管线再高效，也得有数据往里喂。今天回到源头：数据从哪来？两条路——模拟器直接造，采集器从三源收，最终都汇入同一条 pipeline。这篇就讲四件事：物理模型、确定性 seed、归一化漏斗、坏数据去向。读完你能回答：模拟器的物理模型为什么这么设计？三源各适合什么场景？坏数据去哪了？

档案放 PostgreSQL，时序放 TDengine——这是很多 IoT 系统的标准姿势。但真要把两个数据源塞进同一个 Spring Boot 应用，配置、注入、防注入、分页、健康检查，每一步都有坑。本文用实战源码，讲透双数据源查询层的完整实现。

写入失败时，数据去哪了？一行 error 背后可能是几百条设备数据消失。本文从可运行源码出发，拆解数据保底三道防线：指数退避重试兜住瞬时错误，DiskSpool 原子写落盘兜住持久故障，重启后按序回放把数据捞回来。写文件为何必须 tmp→fsync→rename，一文讲透。

Streaming Job 的意义不在于"又多了导数方式"，而在于 Doris 把**数据接入**这件事的默认形态从"搭一条外部管道"变成了"发一条 SQL"。对于大量只需要镜像同步 + 轻量加工的实时数仓场景，架构里可以直接少掉 Kafka 和 Flink 两层。

十二、Hive基本查询操作（二） 第1关：Hive排序 第2关：Hive数据类型和类型转换 第3关：Hive抽样查询 有任何问题都可以随时关注私信！

本文全面系统地介绍了 Elasticsearch 文档操作的核心知识，涵盖文档的新增（指定ID、自动生成ID、创建式新增）、更新（全量更新、部分更新、脚本更新、批量更新）、查询（ID查询、字段过滤、批量查询）和删除（ID删除、批量删除、按查询删除）四大操作。文章不仅提供了详细的语法示例和返回结果解析，还通过实际应用场景（用户管理、商品管理、日志记录、订单管理、计数器）展示了如何在实际项目中应用这些操作。最后，总结了最佳实践建议、常用命令速查、返回结果字段详解和注意事项，帮助开发者高效、安全地使用 Elast

制造业数字化转型中，时序数据库选型面临诸多挑战。本文系统对比了八大主流时序存储引擎（InfluxDB、TimescaleDB、TDengine、Prometheus、QuestDB、VictoriaMetrics、Apache IoTDB、ClickHouse），从技术架构、工业协议适配、许可证合规、性能特点等维度展开分析，针对不同制造业场景（设备采集、产线监控、能耗统计等）给出适配建议。重点提出三步选型框架。