时序数据库高吞吐架构选型：LSM-Tree原理与混合部署实践

大家好，我是数据库小学妹 👋

前阵子帮一家物流公司做监控大屏。300辆冷链车，每辆车40个传感器，每秒上报温度、湿度、位置。加上告警日志和设备状态，峰值写入每秒12000条。一开始用MySQL存，跑了1个月没问题。第2个月查询开始变慢，一个简单的温度趋势查询要等3秒。再过两周，INSERT延迟飙升到200毫秒，写入开始超时。我查了Buffer Pool命中率99%，磁盘IO的IOPS没到上限，索引该加的都加了，问题还是在那。

后来一个做物联网的同事提醒我：你的数据特征是"写多读少、按时间聚合、过期要淘汰"。MySQL不是为这种场景设计的，用时序数据库才对路。改用之后，写入延迟从200毫秒降到了3毫秒，存储成本降了一大半。今天把这些选型和落地经验整理出来，希望下次你遇到能帮你少走弯路少踩坑。

时序数据库为什么不能用关系型数据库

在讲选型之前，先搞清楚时序数据长什么样。

时序数据是按时间顺序产生的数据，传感器读数、服务器指标、股票行情、用户行为日志都属于这一类。它和普通业务数据有四个本质区别。

第一是写多读少，每秒写入一万多条数据，但查询一天可能只有几十次，写入量是查询量的几百倍。这类场景正是专用数据库的用武之地。

第二是按时间聚合，查询几乎都是"最近1小时的平均温度"“昨天的峰值”“过去7天的趋势”，没人会查某个设备在某个秒级的精确读数。

第三是过期淘汰，原始数据保留3个月，聚合数据保留1年，再老的数据没人看。

第四是追加写入几乎不更新，传感器报上来的数据写进去就不改了，不像订单表那样频繁UPDATE。

MySQL用的是B+树索引和行存引擎，每次INSERT要维护索引条目、事务版本链、undo log和redo log。对订单记录来说这些开销完全值得，但对传感器数据来说，你不需要事务、不需要行级锁、不需要B+树的随机IO。具体来说，MySQL每次写入要做3件事：先在B+树叶子节点找到插入位置做1次随机IO，然后维护MVCC版本链写undo log保证回滚能力，最后写redo log保证崩溃恢复。这3步对事务型业务是必须的，但对每秒写入上万条的传感器数据来说，每一步都是浪费。B+树的随机IO在高并发写入时产生大量锁竞争，MVCC版本链会迅速膨胀。

它用的是LSM-Tree结构，专门解决B+树的写入瓶颈。数据先进内存的memtable，这是追加写入不需要随机IO。memtable攒满之后批量刷到磁盘变成SSTable，刷盘是纯顺序IO，吞吐量比B+树的随机IO高一个数量级。随着写入持续，多个SSTable会触发compaction合并，把重叠的数据范围整理成新的文件。LSM-Tree的代价是读放大，查询时可能需要检查多个层级的SSTable文件。但时序数据的查询几乎总是按时间范围扫描，布隆过滤器可以快速跳过不包含目标数据的文件，实际读性能反而比B+树更好。

同一批硬件，写入性能能比MySQL高10倍以上。这不是理论值，是我在项目中实测出来的。

时序数据库的数据压缩原理

时序数据库不仅写入快，存储也省，核心原因是数据压缩算法。

MySQL的压缩很基础，InnoDB的页压缩最多省30%~50%的空间。它用的是专门针对时序数据设计的压缩算法，最经典的是Gorilla XOR压缩，Facebook在2015年发表的论文中提出的。核心思路很简单：相邻两个时间戳的差值通常不变，可以用差分编码存；相邻两个测量值如果变化不大，XOR结果会有很多前导零和尾部零，只需要存中间的差异位。

举个实际的例子。温度传感器每秒上报一次，大部分时间温度在23到25度之间波动，相邻两次读数的差值可能只有零点几度。用Gorilla压缩后，一条16字节的数据可以压到不到2字节，压缩比能达到8:1甚至10:1。这就是为什么它的存储成本比MySQL低一大截。我的项目里，原始数据从预计的300GB压到了40GB不到。

时序数据库与MySQL的核心差异

每一项都指向同一个判断：看你的数据工作负载是什么类型。

主流时序数据库架构对比

我调研了四款方案。

InfluxDB，Go语言写的，有自己的查询语言InfluxQL。它的TSM存储引擎是核心，写入走WAL预写日志加memtable缓存，攒够一批后flush成TSM文件。TSM文件内部按tag key排序，查询时直接定位。它的标签基数问题比较突出，tags组合越多内存中的series索引越大，官方上限3000万条时间线。我在实际项目中遇到过这个问题，传感器一多tags组合爆炸，查询直接卡死。另外集群版商业收费，中小团队需要考虑。

TDengine，国产开源，"超级表"概念是核心亮点。同类设备存在一张超级表里，每个设备一个子表，底层按设备ID哈希分片，单个设备历史查询IO效率不错。支持SQL语法，学习成本较低。复杂查询和生态工具还在完善中，JOIN能力和窗口函数相比成熟的关系数据库有差距。

TimescaleDB，基于PostgreSQL的时序扩展。核心概念是Hypertable，自动按时间把数据分成chunk，每个chunk就是普通的PostgreSQL表。好处是完全兼容PostgreSQL的SQL语法和工具链。底层还是PostgreSQL的行存引擎，写入性能比专用时序库差一些，数据压缩需要手动开启列式压缩插件。

KingbaseES，电科金仓的产品线里专门针对时序场景做了优化。存储层面采用时间分区加自适应行列存储的设计，数据按时间自动分片，查询时只扫描相关时间段减少IO开销。自研"二维分区"算法，时间轴主分区控制数据块和索引规模，空间轴次分区按设备ID等标签做哈希分区，把高并发写入压力均匀分散到各节点，避免单一节点集中承压。写入端通过Append追加写、无锁化和异步IO机制，减少高并发写入时的资源等待，写入性能远高于MySQL。它的核心优势在信创生态：CPU适配覆盖了鲲鹏、飞腾、龙芯、海光、兆芯、申威，操作系统适配了银河麒麟、统信UOS。安全方面通过了公安部等保四级认证，支持三权分立安全模型，政务和军工场景可以直接复用。KingbaseES配套了监控巡检工具，对已有KES使用经验的团队来说学习成本很低。SQL语法兼容Oracle和MySQL两种模式，从传统业务迁移过来时改造成本可控。高可用架构下对时序数据有专门优化，对数据一致性有要求的场景可以直接适配。更关键的是，金仓时序能力构建在KES融合数据库架构中，时序数据、关系数据、向量数据、GIS数据围绕同一个业务对象直接关联，不用多套系统来回同步。

我最后选了KingbaseES。原因有几个：团队之前用过KES，技术栈可以复用；信创适配覆盖了主流国产CPU和操作系统，客户环境可以直接部署；配套监控巡检工具省掉了额外部署的成本；SQL兼容Oracle模式，业务侧迁移改造量小。另外KES保留了完整的ACID事务支持，对数据一致性有要求的工业场景可以直接复用。综合来看，KES是得分最高的选项。

时序数据库的混合架构方案

时序数据库不是万能的，它擅长高速写入和按时间查询，但不擅长关联查询。比如查某辆车的传感器数据同时关联车辆型号、维护记录、负责人，这种跨表JOIN它做不好。所以我在项目里采用了它加MySQL的混合架构，各司其职。

我的方案是混合架构：MySQL存业务数据，时序库存传感器数据，两套系统各管各的长处。有些团队如果已经在用KES做主数据库，直接在KES上开启时序数据优化也是一种思路，省掉维护两套系统的成本。

应用层
  ├── 业务API ──→ MySQL（车辆表、用户表、工单表）
  └── 数据采集 ──→ 时序数据库（传感器读数）

查询层
  ├── 车辆管理 ──→ MySQL
  ├── 趋势分析 ──→ 时序数据库
  └── 综合报表 ──→ 先查时序库聚合，再关联MySQL

数据采集层用MQTT接收传感器数据，通过Telegraf写入时序库。Telegraf是InfluxData开源的数据采集代理，内置了它的输出插件，指定输入源和输出目标就能跑起来。趋势分析和告警规则走时序库，综合报表需要跨库时在应用层做关联。这种混合架构下，时序库专注高速写入和时间范围查询，MySQL负责业务关联，两者配合效果最好。

实际部署时我遇到一个问题：Telegraf默认每10秒采集一次，但传感器是每秒上报的。我把采集间隔改成了一秒，同时在KES端开启了批量写入缓冲，这样既保证了数据实时性，又不会因为频繁的小写入拖慢性能。

存储策略也得分层，原始数据每秒粒度保留九十天，降采样后的每分钟聚合数据保留一年，每日聚合数据保留三年。降采样的SQL大概长这样，写入时就触发不用事后跑批：

-- 持续查询：每秒数据降采样为每分钟聚合
CREATE STREAM avg_temp_1m
AS SELECT ts, device_id,
   AVG(temperature) AS avg_temp,
   MAX(temperature) AS max_temp,
   MIN(temperature) AS min_temp
   FROM sensor_data
   INTERVAL(1m);

告警规则跑在时序数据库上，温度超过设定阈值连续3分钟就触发。这种时间窗口判断它原生支持，比在MySQL里写窗口函数高效得多。改造后效果很明显，MySQL写入QPS从12000降到了300，传感器数据全部走时序库，写入延迟稳定在3毫秒以内，存储成本降了60%。

时序数据库选型决策框架

实际项目里我总结了一个四维判断框架。

数据规模是第一个维度。每秒千条以内MySQL还能撑住，每秒万条以上必须考虑时序数据库，每秒十万条以上得用分布式方案。数据量越大，这类专用方案的优势越明显。

团队技术栈是第二个维度。熟悉PostgreSQL生态的选PostgreSQL扩展最顺手，能接受新查询语言的可以看原生方案。如果需要SQL兼容、降低迁移成本，选支持标准SQL的方案，金仓KES同时兼容Oracle和MySQL两种模式，已有使用经验的团队可以直接复用技术栈。选型不仅要评估产品能力，还要考虑团队能不能快速上手。

JOIN需求是第三个维度。关联查询多的场景用支持标准SQL的关系型方案更合适，纯时序场景用专用数据库性能更好。我在实际项目里踩过这个坑，别指望它能替代关系库做复杂关联，跨表查询还是走业务库稳妥。

事务需求是第四个维度。金融交易类场景需要强一致性得选支持事务的方案，大多数监控场景不需要。金仓KES的特点是一套数据库同时具备完整ACID和时序数据优化能力，不需要在业务库和时序库之间二选一，对数据一致性有要求的场景可以直接一套系统搞定。如果你的场景既有时序写入又需要事务保证，这种一体化方案能省去大量架构复杂度。

时序数据库实战避坑清单

第一，别把所有数据都塞进关系数据库。监控数据、日志数据这些"写多读少、按时间聚合"的场景，MySQL真扛不住。我之前把全量监控数据都写进MySQL，INSERT延迟从零点几毫秒飙到200毫秒，磁盘也撑不住了。B+树不是为这种工作负载设计的，该用专门的方案就别硬上。

第二，降采样必须从第一天就配好。三千个设备每秒一条数据，一天就是两亿多条，不配降采样存储成本会指数级增长。我第一个项目忘了这茬，三个月后存储成本翻了八倍才补上。原始数据保留三个月，分钟级聚合保留一年，这个比例是我反复试出来的。降采样是它的核心功能，配好了能省大量存储空间。

第三，标签设计要小心高基数陷阱。标签组合越多内存占用越大，设备编号加车型加司机加路线四个标签一组合，基数可能几十万，写入和查询都会变慢。我的做法是只保留查询真正需要的标签，其他走业务库关联。InfluxDB的series上限是3000万条，TDengine的超级表容忍度高一些，但都不是无限的。标签设计要在项目初期就规划好。

时序数据库项目总结

那个监控项目上线半年了，运行很稳定。传感器数据存储成本比最初的MySQL方案低了60%，查询性能反而更好了。

MySQL是好数据库但不是万能的，它也不是银弹，有明确的适用边界。国内这几年这类数据库发展很快，除了InfluxDB、TDengine这些主流选项，KingbaseES也在信创场景下跑出了自己的特色——从CPU适配到安全合规再到监控运维工具链，走的是全栈路线。知道什么时候该用什么工具，比精通一个工具更重要。

朋友，你在监控或IoT场景中用过这类方案吗？踩过哪些坑？欢迎在评论区聊聊。

我是数据库小学妹，咱们下篇见 👋