时序数据库选型指南：容量规划与压测方法（以 Apache IoTDB 为例）

- [1. 选型不要只问"能跑多快"：先把增长曲线写出来](#1. 选型不要只问“能跑多快”：先把增长曲线写出来)
- [2. 容量规划的基本公式：先估原始写入，再估落盘成本](#2. 容量规划的基本公式：先估原始写入，再估落盘成本)
- - [2.1 原始点数估算（最上层口径）](#2.1 原始点数估算（最上层口径）)
  - [2.2 落盘成本估算（需要结合压缩与元数据）](#2.2 落盘成本估算（需要结合压缩与元数据）)
- [3. 设计一套可复用的压测：把"写入、查询、合并"放在同一张桌子上](#3. 设计一套可复用的压测：把“写入、查询、合并”放在同一张桌子上)
- [4. IoTDB 写入路径需要验证什么：WAL、刷盘与顺序写](#4. IoTDB 写入路径需要验证什么：WAL、刷盘与顺序写)
- [5. 典型查询压测：不要只测点查，重点测"下采样聚合"](#5. 典型查询压测：不要只测点查，重点测“下采样聚合”)
- [6. Java 压测写入示例：用 Tablet 批写贴近生产（示意）](#6. Java 压测写入示例：用 Tablet 批写贴近生产（示意）)
- [7. 稳定性细节：OS 参数与连接队列别忽略](#7. 稳定性细节：OS 参数与连接队列别忽略)
- [8. 一份压测验收表：让选型从"感觉"变成"证据"](#8. 一份压测验收表：让选型从“感觉”变成“证据”)
- [9. 结语：选型的正确姿势是"带着容量与压测问题去看架构"](#9. 结语：选型的正确姿势是“带着容量与压测问题去看架构”)
- 资源链接

给出一套可复用的"容量规划 + 压测验收"框架，用来评估 TSDB 是否适配你的业务增长曲线。

1. 选型不要只问"能跑多快"：先把增长曲线写出来

所以选型阶段建议先写清楚这三条曲线（不用精确到小数点，但必须同口径）：

之后再谈"跑分"才有意义。

2. 容量规划的基本公式：先估原始写入，再估落盘成本

一个最实用的容量估算可以分两层：

2.1 原始点数估算（最上层口径）

复制代码

每日点数 = 设备数 × 每设备测点数 × 每秒采样点数 × 86400

举例（仅示意）：

10,000 台设备 × 50 测点 × 1Hz × 86400 ≈ 43.2 亿点/天

2.2 落盘成本估算（需要结合压缩与元数据）

落盘大小不是"点数 × 每点字节数"这么简单，还包含：

时间列与数值列编码压缩
写前日志（WAL）与刷盘策略
元数据（schema/统计信息/索引结构）
合并（compaction）过程中的临时空间

因此选型阶段正确做法是：用真实数据做一次落盘测量，再把测得的"每点平均落盘字节数"带入公式，而不是靠宣传数字。

3. 设计一套可复用的压测：把"写入、查询、合并"放在同一张桌子上

很多压测只做"写入吞吐"，但线上真实情况是：写入、查询、后台合并（compaction）同时发生。选型压测建议至少包含三种 workload：

纯写入压测：验证上限吞吐与 CPU/磁盘瓶颈
写入 + 查询混合压测：验证 P95 延迟稳定性
长跑压测（8～24 小时）：验证 compaction、磁盘水位、WAL 增长与恢复能力

下面用一张图表达"把后台过程也算进压测"的思路：
写入压力(批写/乱序)
IoTDB
查询压力(下采样/聚合)
后台合并(Compaction)
磁盘水位/IO 延迟
WAL 增长/刷盘频率
稳定性评估(P95/错误率)

压测输出建议至少包含：

写入成功率与重试率
查询 P50/P95 延迟
CPU、磁盘 IO、磁盘水位曲线
compaction 触发频率与耗时
宕机恢复时间（可选，但强烈建议做一次）

4. IoTDB 写入路径需要验证什么：WAL、刷盘与顺序写

IoTDB 的写入通常会经历"WAL + 内存表 + 刷盘文件 + 后台合并"的路径。选型阶段不必研究每个内部细节，但建议用"可观测指标"验证三件事：

WAL 是否成为瓶颈：高并发下 WAL 写入是否导致 IO 抖动？
刷盘是否可控：刷盘过于频繁会降低吞吐，过于稀疏会增加内存压力与恢复时间。
后台合并是否稳定：合并会消耗 IO 与 CPU，若与业务查询冲突，P95 延迟会抖动。

5. 典型查询压测：不要只测点查，重点测"下采样聚合"

在工业/物联网系统里，最常见的查询不是"查某一条"，而是"查一段时间范围并做统计"。例如：

sql 复制代码

-- 最近 7 天，每 10 分钟的平均温度
SELECT AVG(temperature)
FROM root.plantA.wf01.line02.motor07
GROUP BY ([now() - 7d, now()), 10m);

选型压测建议准备一组"典型查询模板"，每次压测都固定复用，便于横向对比。

示例模板（可按项目替换）：

单设备：近 1 天 / 7 天，下采样聚合
多设备：某产线所有设备的平均值（前缀查询）
异常筛选：温度 > 阈值 + 时间范围

6. Java 压测写入示例：用 Tablet 批写贴近生产（示意）

压测工具很多，但在选型阶段最省心的方法往往是：用 SDK 写一个最小压测器，直接复用你未来生产的写入模式（批写、按设备分桶、并发线程数）。

下面给一个简化示意（以实际版本 API 为准），核心是用 Tablet 做批写：

java 复制代码

import org.apache.iotdb.session.Session;
import org.apache.iotdb.tsfile.file.metadata.enums.TSDataType;
import org.apache.iotdb.tsfile.write.record.Tablet;
import org.apache.iotdb.tsfile.write.schema.MeasurementSchema;

import java.util.ArrayList;
import java.util.List;

public class IoTDBLoadGen {
    public static void main(String[] args) throws Exception {
        Session session = new Session.Builder()
                .host("127.0.0.1")
                .port(6667)
                .username("root")
                .password("root")
                .build();
        session.open(false);

        List<MeasurementSchema> schema = new ArrayList<>();
        schema.add(new MeasurementSchema("temperature", TSDataType.FLOAT));
        schema.add(new MeasurementSchema("vibration", TSDataType.FLOAT));

        Tablet tablet = new Tablet("root.plantA.wf01.line02.motor07", schema, 1024);

        long base = System.currentTimeMillis();
        for (int i = 0; i < 1024; i++) {
            tablet.addTimestamp(i, base + i * 1000L);
            tablet.addValue("temperature", i, 20.0f + (float) Math.random() * 10);
            tablet.addValue("vibration", i, (float) Math.random());
            tablet.rowSize++;
        }

        session.insertTablet(tablet);
        session.close();
    }
}

压测时可以做两种扩展：

多线程：按设备维度分片，每线程负责一组设备写入
乱序与补点：随机打乱部分时间戳，模拟真实现场网络抖动

7. 稳定性细节：OS 参数与连接队列别忽略

在高并发连接场景里，有些问题不是数据库内核造成的，而是 OS 默认参数限制。IoTDB 官方下载页给出一个典型建议：把 somaxconn 调到 65535，以避免高负载时出现 "connection reset"。

bash 复制代码

# Linux
sudo sysctl -w net.core.somaxconn=65535

压测时如果你看到偶发连接重置、握手失败，先把这些基础设施因素排除掉，再谈数据库性能。

8. 一份压测验收表：让选型从"感觉"变成"证据"

下面给一个可直接复用的验收表结构（示意）：

指标	目标	备注
写入吞吐（点/秒）	≥ X	批写/线程数/设备数
写入错误率	≤ 0.01%	重试策略
查询 P95（下采样）	≤ Y ms	7d/10m 聚合
磁盘占用（GB/天）	≤ Z	含 WAL/元数据
长跑稳定性	8h 无抖动	compaction 期间
宕机恢复时间	≤ T min	可选

把"目标---实测---备注"写清楚，选型讨论会更高效，也更容易向业务与管理层解释成本。

9. 结语：选型的正确姿势是"带着容量与压测问题去看架构"

当你用同一套容量口径与压测验收去评估 TSDB，数据库之间的差异就会自然显现：谁更适合你的写入模式，谁在后台合并时更稳定，谁在长周期留存与下采样查询上更省资源。

IoTDB 的优势往往体现在"工业/物联网常见 workload"上：设备域建模清晰、批写路径成熟、对下采样聚合友好，并且可以在边缘与云端形成一致的数据模型。这些特性只有在"正确的压测设计"里才会被看见。

资源链接

IoTDB 下载：https://iotdb.apache.org/zh/Download/
企业版官网：https://timecho.com