4. 时序数据写入路径与存储引擎选型

时序数据库的写入路径决定了系统能否在设备规模扩大、采样频率提高、网络抖动导致乱序到达时仍然保持稳定吞吐。理解写入路径，需要把“数据从产生到落盘”拆成可观察的环节：接入、解析与校验、分区路由、内存缓冲、预写日志、刷盘与合并。不同数据库在这些环节上的取舍，直接决定了它们适合的场景。

写入路径：从设备到磁盘

以一台风机振动传感器为例，采样频率 1 kHz，每 10 ms 产生一个包含 8 个测点的数据点，单设备写入约 800 点/秒。数据经 MQTT 或 HTTP 到达接入层后，先做时间戳解析、标签（tag）提取和字段（field）校验。标签用于建立索引，字段用于存储测量值。随后按“时间 + 标签哈希”路由到对应分区或分片。写入请求通常先进入内存表（MemTable）并同步写入预写日志（WAL），保证断电可恢复；当内存表达到阈值（例如 64 MB 或 10 万行）后冻结并刷成磁盘文件，后台再执行合并（compaction），把多个小文件整理为更大的有序文件。

这条路径中有三个关键参数：批量大小、刷盘阈值和合并策略。批量写入把多条记录合并为一次网络与磁盘操作，能显著降低单位写入开销。例如将 1000 个点合并为一个批次，相比逐点写入，网络往返次数从 1000 次降到 1 次。但批量过大会增加单次请求延迟和内存占用，通常建议单批 500～5000 点，具体取决于单点大小和网络带宽。

乱序处理与写入放大

乱序是时序场景的常态：设备离线补传、网络重传、多采集器时钟不同步都会导致旧时间戳数据晚到。LSM 树结构对乱序写入天然友好，因为新数据先写入内存和 WAL，再按时间有序刷盘，不需要像 B+ 树那样在磁盘上原地更新。但乱序会带来两个代价：一是同一时间范围可能落在多个文件中，查询时需要合并更多文件；二是合并频率上升，写入放大增加。工程上常用“乱序窗口”参数控制容忍范围，例如允许 1 小时内的乱序数据直接写入，超出窗口的数据进入延迟队列或单独分区。选择该窗口时，要权衡设备补传时长与查询性能。

LSM 树与列式存储

LSM 树的核心是把随机写转为顺序写：写入先追加 WAL，再进内存表，刷盘时生成有序的 SSTable 文件。列式存储则把同一列的数据连续存放，配合时间戳有序排列，使范围查询和聚合只需读取相关列。两者结合后，时序数据库通常按“时间分区 + 标签索引 + 列式压缩”组织数据。压缩算法如 delta-of-delta、Gorilla、ZSTD 能显著降低存储成本。例如对规律采样的温度数据，delta-of-delta 编码后每点可能只需 1～2 字节，而原始 double 需要 8 字节。

主流时序数据库对比与选型

InfluxDB 使用 TSM 存储引擎，属于 LSM 变体，写入吞吐高，批量接口成熟，适合监控和 DevOps 场景。它的标签索引在标签基数过高时会膨胀，因此要控制标签数量。TimescaleDB 构建在 PostgreSQL 之上，使用 B+ 树和列存扩展，优势是完整 SQL 生态、事务和复杂关联查询，但写入吞吐和乱序处理弱于专用时序库，适合业务分析、报表和已有 PG 技术栈的团队。TDengine 采用“一设备一表”模型和列式+LSM 引擎，写入吞吐极高，适合工业物联网中海量设备、高频采样的场景。IoTDB 同样基于 LSM 和列式存储，针对乱序数据做了合并优化，在工业设备、车联网等乱序频繁的场景中表现突出。

选型时不要只看基准测试的峰值写入。应结合四个维度：一是写入模式，是持续高频还是批量补传；二是乱序比例和最大延迟；三是查询模式，是简单聚合还是复杂关联；四是运维成本，包括集群规模、压缩率和生态工具。例如某工厂有 5000 台设备，每台 200 个测点，采样周期 1 秒，则总写入约 100 万点/秒，乱序比例约 5%，最大延迟 30 分钟。此时应优先选择支持高吞吐和乱序窗口的 TDengine 或 IoTDB，而不是 TimescaleDB。若查询以 SQL 报表为主且写入量在 10 万点/秒以内，TimescaleDB 更合适。

写入参数示例与判断依据

以下是一组用于教学示例的写入参数，假设单点约 50 字节，目标写入 50 万点/秒：

批量大小：2000 点/批
并发写入连接：16
内存表阈值：128 MB
WAL 刷盘：每批同步
乱序窗口：30 分钟
合并策略：分层合并，每层文件数上限 8
压缩算法：ZSTD + delta-of-delta

观察写入是否达标，可以看三个指标：写入延迟 P99 是否低于 200 ms；WAL 磁盘写入是否持续低于磁盘带宽的 70%；合并队列是否长期积压。若合并队列持续增长，说明写入速度超过合并能力，需要降低批量大小、增加合并线程或调整分层策略。若 P99 延迟升高但吞吐正常，通常是批量过大或内存表刷盘阻塞，应减小批量或提高刷盘阈值。

存储引擎选型没有唯一答案，关键是让写入路径与业务的数据到达模式匹配。先量化写入速率、乱序比例和查询类型，再用小规模真实数据做写入压测，观察 WAL、内存表、合并队列和查询延迟的变化，才能做出可验证的选型决策。