目录

引言：时序数据的规模挑战

一、时序数据库存储模型：LSM Tree的演进与局限

1.1 写入优化的核心：LSM Tree

1.2 时序数据库的存储模型演进

二、TsFile：专为时序设计的列式存储格式​编辑

2.1 文件结构概览

2.2 编码与压缩：极致降低存储成本

时间戳编码

数值编码适配方案

工业数据集实测压缩效果

2.3 文件内部索引：元数据与统计信息加速查询

三、乱序数据写入：时间顺序的破坏与修复

3.1 乱序数据的成因

3.2 通用LSM Tree的乱序处理代价

3.3 IoTDB的顺乱序分离引擎

四、分布式架构：从主从到无共享

4.1 时序数据的分布式分片策略

4.2 元数据管理：时间序列树

4.3 共识协议框架

五、查询处理：向量化与索引加速

5.1 查询执行流程

5.2 向量化执行

5.3 多种索引支持

六、与国外时序数据库的架构对比

6.1 数据模型对比

6.2 存储格式对比

6.3 分布式架构对比

6.4 场景适配选型

七、大数据生态集成

7.1 Flink 实时集成

7.2 Spark 离线分析集成

7.3 Hadoop MapReduce 集成

7.4 Pipe 数据同步与灾备

八、典型落地场景与案例

九、总结与选型思考

引言：时序数据的规模挑战

在传统数据系统中，一条“数据”往往对应一个业务事件：一次交易、一次点击、一次登录。而在物联网场景中，一台设备在1秒内就能产生数十甚至数百个测量值，并且这种产生是持续、高频率、永不间断的。

以一台智能风电机组为例，它可能包含振动、温度、转速、功率、风向等200多个传感器，每个传感器每秒上报一次数据，单台机组一天产生的数据点数计算如下：

200 点/秒 × 86,400 秒/天 = 17,280,000 点/天

对于一个拥有1000台风机的风电场，一天的时序数据点数量将达到172亿点。这仅仅是原始采集量，还未包含聚合、标签、元数据等附加信息。

面对这种超大规模数据，传统的关系型数据库、NoSQL 数据库（如HBase、Cassandra）乃至早期的时序数据库，均在写入吞吐、存储成本、查询延迟等方面存在明显瓶颈。本文将系统拆解时序数据库存储内核设计，并以此为核心线索，详解Apache IoTDB的核心技术实现与工业级优化方案。

一、时序数据库存储模型：LSM Tree的演进与局限

1.1 写入优化的核心：LSM Tree

现代时序数据库几乎都基于LSM Tree（Log-Structured Merge-Tree）或其变体构建。LSM Tree 的核心价值是将随机写入转化为顺序写入，从底层大幅提升海量数据的写入性能。

典型 LSM Tree 写入结构与流程如下：

写入流程：
新数据 → WAL（预写日志） → MemTable（内存表） → 磁盘SSTable
                                      ↓
                           后台Compaction（合并压缩）

但通用 LSM Tree（LevelDB、RocksDB）是为通用 KV 存储设计，直接适配时序数据场景存在三大核心短板：

  1. 时间维度未充分利用：通用 KV 存储的 Key 无序，而时序数据天然具备时间有序性，LSM Tree 无法针对时间维度做专属优化。

  2. 多序列隔离性差：时序数据按「设备-测点」划分为海量独立时间序列，而 LSM Tree 混合存储所有序列的 KV 数据，查询指定序列时需扫描大量无关数据，查询效率低下。

  3. Compaction 写放大严重：时序数据多为时间顺序写入，但通用 LSM Tree 会反复合并重叠 Key 区间，产生大量无效 I/O，造成严重写放大问题。

1.2 时序数据库的存储模型演进

针对通用 LSM Tree 的适配缺陷，业界成熟时序数据库基于其架构做了三大针对性创新，彻底适配时序数据特征：

  • 独立时序存储单元：将同一时间序列的数据在物理磁盘上连续存放，实现单序列数据的高效扫描与读取。

  • 时间维度分区：按固定时间粒度（小时/天）对数据分片，时间范围查询可直接跳过无关分区，缩减扫描范围。

  • 列式存储布局：同一测点在全时间轴的数值连续存储，完美适配时序聚合、统计类查询场景。

Apache IoTDB 自研的TsFile 专属时序存储格式，是上述优化思想的集大成落地实现。

二、TsFile：专为时序设计的列式存储格式

2.1 文件结构概览

TsFile 是 IoTDB 专为工业时序数据设计的底层存储文件格式，将一组关联时间序列统一封装为单一文件，逻辑结构分层清晰：

[文件头]
[元数据索引区]
    ├── 序列元数据列表
    │   ├── root.sg1.d1.s1 (INT64, RLE编码)
    │   ├── root.sg1.d1.s2 (FLOAT, Gorilla编码)
    │   └── ...
    └── 块元数据列表
[数据区]
    ├── ChunkGroup 1 (时间范围: t0 ~ t1)
    │   ├── Chunk: s1 (值数组 + 时间戳数组)
    │   ├── Chunk: s2
    │   └── Chunk: s3
    ├── ChunkGroup 2 (时间范围: t1 ~ t2)
    │   └── ...
[文件尾]

核心概念释义：

  • Chunk：单个测点在连续时间范围内的最小数据存储单元，由独立的时间戳列、数值列组成。

  • ChunkGroup：同一时间区间内，同一设备多个测点 Chunk 的逻辑分组，对应单设备单时间切片的完整数据。

  • 元数据索引：记录每个 Chunk 的文件偏移量、起止时间、聚合统计信息，为快速过滤、查询加速提供支撑。

该结构核心优势：查询指定时间范围、指定测点数据时，仅需定位对应 Chunk，读取对应两列数据即可，无需加载无关测点内容，极大减少磁盘 I/O。

2.2 编码与压缩：极致降低存储成本

TsFile 深度适配时序数据单调递增、数值局部相似的特征，内置多类专属编码器，支持按数据类型、数据分布智能选型，最大化压缩比。

时间戳编码

针对时序数据时间戳天然单调递增的特性，提供两种核心编码：

  • 二阶差分编码：对时间戳做两次差值计算，将大数值时间戳转化为极小整数，配合变长编码实现超高压缩比。

  • RLE 游程编码：适配等间隔采集场景，仅记录间隔值与重复次数，极致精简存储空间。

数值编码适配方案

数据类型

推荐编码

原理

整数（INT32/INT64）

RLE / TS_2DIFF

利用数值局部连续性，通过差值存储替代原始数值，缩减体积

浮点数（FLOAT/DOUBLE）

Gorilla

相邻数值异或运算，仅存储差异位，适配工业小幅波动数据

布尔值

PLAIN / RLE

重复布尔值批量压缩，无冗余存储

字符串

DICTIONARY / REGULAR

字典映射精简重复字符串，固定差值编码优化离散文本

其中，Gorilla 编码是时序场景专属压缩算法，适配工业浮点数小幅波动特征，核心伪代码如下：

// Gorilla压缩伪代码示例
long prevValue = 0;
for (double value : values) {
    long currentBits = Double.doubleToLongBits(value);
    long xor = currentBits ^ prevValue;
    if (xor == 0) {
        // 与前值相同，只需写一位'0'
        writeBit(0);
    } else {
        // 与前值不同，写'1' + 控制位 + 异或值
        writeBit(1);
        // 省略具体位编码逻辑...
    }
    prevValue = currentBits;
}
工业数据集实测压缩效果

数据类型

原始大小

TsFile压缩后

压缩比

64位整数（等差序列）

8MB

0.1MB

80:1

64位整数（随机）

8MB

2.8MB

~2.8:1

浮点数（稳定变化）

8MB

1.2MB

6.7:1

浮点数（高频波动）

8MB

3.5MB

2.3:1

时间戳（1ms间隔）

8MB

0.05MB

160:1

在典型工业物联网场景中，TsFile 整体压缩比稳定在8:1 ~ 20:1，可将100TB原始时序数据压缩至5-12.5TB物理存储，大幅降低企业存储成本。

2.3 文件内部索引：元数据与统计信息加速查询

每个 Chunk 的元数据均内置完整的时间范围、聚合统计信息（min、max、sum、count、nullCount 等），IoTDB 查询引擎可基于此实现多层查询优化：

  1. 时间范围过滤：仅加载与查询时间区间重叠的 Chunk，直接跳过全量无关数据块。

  2. 数值裁剪过滤：例如执行 temperature > 100 查询时，若 Chunk 最大值小于100，直接跳过该数据块，无需扫描原始数据。

  3. 聚合预计算：执行均值、求和、计数等聚合查询时，直接复用元数据预存的统计结果，避免全量数据扫描。

该设计大幅削减无效磁盘 I/O，对大范围、高聚合的时序查询场景性能提升极为显著。

三、乱序数据写入：时间顺序的破坏与修复

3.1 乱序数据的成因

真实工业物联网场景中，设备数据无法严格按照时间顺序上报，乱序数据是常态，核心成因分为三类：

  • 网络波动：网络延迟、丢包重传导致历史数据滞后于新数据到达服务端。

  • 边缘缓存：边缘设备断网离线缓存数据，网络恢复后批量回传历史时序数据。

  • 人工运维：后期手动补录、导入历史离线数据。

乱序数据会打破传统 LSM Tree 的顺序写入逻辑，若处理不当，会引发频繁数据合并、严重写放大，大幅降低系统吞吐。

3.2 通用LSM Tree的乱序处理代价

传统 LevelDB/RocksDB 以 设备ID+时间戳 为有序 Key 存储数据，乱序写入需要将旧时间戳数据插入 SSTable 对应位置，依赖 MemTable 刷盘与频繁 Compaction。

当业务乱序比例较高时，会触发严重的写放大（Write Amplification）：写入1MB有效业务数据，可能引发10MB~100MB的无效磁盘 I/O，彻底拖累系统写入性能。

3.3 IoTDB的顺乱序分离引擎

IoTDB 独创顺乱序分离存储引擎，核心思路：将顺序递增数据与乱序滞后数据物理分区存储，避免乱序数据破坏顺序数据的紧凑存储布局，从根源减少 Compaction 开销。

整体写入流程如下：

写入流程：
  新数据
      ↓
 判断时间戳是否大于当前最新时间
      ↓
是 → 写入顺序文件（Sequence TsFile）
 否 → 写入乱序文件（Unsequence TsFile）
      ↓
 后台低负载任务：定期合并乱序文件与顺序文件

核心机制解析：

  • 顺序文件：纯时间序追加写入，Chunk 内部时间戳严格递增，无需频繁 Compaction，写放大无限趋近于1。

  • 乱序文件：乱序数据独立封装 TsFile，文件内部数据有序，仅与顺序文件存在时间区间重叠，不影响主写入链路。

  • 智能合并调度：系统低负载时段自动执行乱序、顺序文件合并，生成新有序文件并清理旧文件，不占用在线写入资源。

该架构可稳定容忍10%~20%的高比例乱序数据，写入吞吐无明显衰减。TSBS 基准测试数据显示，IoTDB 乱序写入性能远超同类时序数据库。

核心合并策略配置示例（iotdb-common.properties）：

# 顺乱序文件合并线程数
merge_thread_count=4
# 合并触发条件：乱序文件总大小超过顺序文件的5%
merge_trigger_ratio=0.05
# 合并时是否执行全量合并（默认增量合并，性能更优）
full_merge_on_trigger=false

四、分布式架构：从主从到无共享

4.1 时序数据的分布式分片策略

分布式时序数据库的核心难点，是海量高基数时序数据的合理分片与负载均衡。行业主流分片方案各有优劣：

  • 按时间分片：按时间区间划分数据节点，时间查询定位快，但新数据集中写入当前节点，易引发热点瓶颈。

  • 按设备/序列分片：按设备哈希分散写入，负载均衡性好，但跨设备聚合查询需调度多节点，链路复杂。

  • 混合分片：先按设备哈希分片，单节点内部再按时间分区，兼顾负载均衡与查询效率。

Apache IoTDB 采用元数据与数据分离的原生无共享分布式架构，原生支持混合分片策略，集群角色分工明确：

节点类型

核心职责

部署数量建议

ConfigNode

管理设备树元数据、分片映射规则、集群调度、共识管理

3/5个奇数节点（保证一致性）

DataNode

时序数据存储、SQL查询执行、副本数据同步

≥3个，支持线性扩容

AINode（可选）

内置时序机器学习、异常检测、数据推理能力

按需弹性部署

4.2 元数据管理：时间序列树

区别于传统数据库二维表模型，IoTDB 采用树形层级元数据模型，完全适配工业设备层级架构，时序路径以 root 为根，通过「.」分割层级，类文件系统管理模式：

root
 ├── metro
 │    ├── line1
│    │    ├── train1
│    │    │    ├── speed
│    │    │    └── temperature
 │    │    └── train2
 │    └── line2
  └── factory
      └── workshop
          ├── robot1
          └── robot2

树形模型三大核心优势：

  1. 场景适配性强：天然匹配工厂-车间-设备-测点的工业层级架构，贴合运维认知习惯。

  2. 批量查询便捷：支持通配符路径查询，可一次性批量查询同层级所有测点数据。

  3. 权限精细化管控：可基于路径前缀，为不同部门、用户分配独立子树的读写权限。

分布式环境下，元数据树拆分存储于多台 ConfigNode，基于 Raft 协议保证强一致性。数据写入时，系统通过时序路径哈希映射归属 DataNode，再按时间分区落地为 TsFile 文件。

4.3 共识协议框架

IoTDB 内置统一可插拔共识协议框架，支持不同组件差异化适配，兼顾一致性与性能：

  • ConfigNode：基于 RatisConsensus（Raft 开源实现），保障元数据强一致性，杜绝集群配置错乱。

  • DataNode：支持双协议切换，高性能场景选用 IoTConsensus（弱一致、低延迟、高吞吐），核心数据场景选用 RatisConsensus 强一致协议。

IoTConsensus 专为物联网海量追加写场景优化，允许副本短暂数据不一致，最终自动同步，大幅降低写入延迟、提升并发吞吐，适配工业高并发写入场景。

五、查询处理：向量化与索引加速

5.1 查询执行流程

IoTDB 采用分层优化查询引擎，标准化 SQL 从解析到执行全链路优化，流程如下：

1.SQL语句 → 逻辑计划生成器 → 物理计划优化器 → 分布式执行调度器 → DataNode本地执行

典型业务聚合查询示例：

SELECT AVG(temperature) 
FROM root.factory1.line1.* 
WHERE time >= 2025-01-01 00:00:00 AND time < 2025-01-02 00:00:00 
GROUP BY ([2025-01-01T00:00:00, 2025-01-02T00:00:00), 1h)

逻辑计划：扫描指定路径下所有温度测点，过滤目标时间区间，按1小时粒度聚合均值。

物理优化：自动识别数据分布节点，生成并行扫描任务；复用 Chunk 元数据预存的 sum、count 数值，跳过原始数据扫描，直接输出聚合结果。

5.2 向量化执行

传统数据库火山模型逐行迭代返回数据，在海量时序分析场景效率极低。IoTDB 自研向量化执行引擎，批量读取数据、批量计算，最大化利用 CPU 缓存与 SIMD 指令。

向量化聚合核心伪代码：

// 向量化聚合计算平均值
public AggregationResult computeAvg(ChunkReader reader) {
    long[] timestamps = new long[BATCH_SIZE];
    double[] values = new double[BATCH_SIZE];
  int batchCount = 0;
   double sum = 0;
    int count = 0;
   
    while (reader.hasNextBatch()) {
        batchCount = reader.readBatch(timestamps, values);
        for (int i = 0; i < batchCount; i++) {
            sum += values[i];
           count++;
        }
    }
   return new AvgResult(sum / count);
}

一次性加载批量数据至内存数组，批量完成聚合计算，相比逐行执行性能提升数倍。

5.3 多种索引支持

除 TsFile 内置元数据索引外，IoTDB 配套多层外部索引，全方位加速各类查询场景：

  • 布隆过滤器：快速判定时序序列是否存在于文件，避免无效文件打开与扫描。

  • 倒排索引：针对设备状态、字符串标签等离散字段建索引，秒级响应等值查询。

  • 路径通配符索引：优化 root.*.temperature 类模糊路径查询，大幅提升元数据匹配效率。

六、与国外时序数据库的架构对比

6.1 数据模型对比

数据库

核心数据模型

核心特点

InfluxDB（早期）

Tag-Field自定义模型

适配云原生监控，纳秒级时间精度支持薄弱，工业层级适配性差

TimescaleDB

关系表继承模型

兼容标准SQL，生态成熟，但是基于PG改造，存储压缩率偏低

Prometheus

指标+标签KV模型

轻量化监控适配，模型简单，单机容量有限，长期存储依赖第三方组件

Apache IoTDB

树模型 + 兼容表模型（2.0+）

树模型适配工业层级场景，表模型兼容标准SQL，双模型无缝映射，适配全场景

6.2 存储格式对比

  • InfluxDB(TSM)：单时序独立存储，存在百万级序列基数瓶颈，高测点场景性能大幅衰减。

  • TimescaleDB：行存/行列混合存储，压缩能力薄弱，依赖第三方插件实现数据压缩。

  • Prometheus：自定义块存储格式，压缩比一般，无法支撑超大容量工业数据。

  • Apache IoTDB：自研 TsFile 专属时序列式存储，深度优化亿级高基数序列场景，压缩比行业领先。

6.3 分布式架构对比

  • InfluxDB Enterprise/IOx：早期集群版闭源，3.0重构对象存储架构，生态与架构仍在迭代，稳定性不足。

  • TimescaleDB：依赖Citus插件实现分片，非原生分布式架构，扩容与负载均衡能力有限。

  • Apache IoTDB：原生无共享分布式架构，多共识协议可选，端边云一体化协同为核心差异化优势，完美适配工业边缘+云端部署场景。

6.4 场景适配选型

Apache IoTDB 最优适配场景：

  • 千万级设备、百亿级测点的超大规模工业物联网场景；

  • 需要端-边-云协同、弱网断点续传、边缘离线缓存的场景；

  • 存储成本敏感，追求高压缩比、低运维成本，无需人工冷热分层的企业级业务。

七、大数据生态集成

IoTDB 不局限于独立时序存储，深度兼容主流大数据生态，提供原生连接器，支持实时流处理、离线分析、数据同步全链路能力。

7.1 Flink 实时集成

通过 IoTDB-Flink Connector，可将 IoTDB 作为 Flink 实时任务的数据源与输出端，支撑实时计算、异常预警场景：

// Flink读取IoTDB时序数据
DataStream<RowData> stream = env
   .addSource(new IoTDBSource(
        "jdbc:iotdb://127.0.0.1:6667/",
        "root.user",
       "password",
        "SELECT * FROM root.factory.** WHERE time > 2023-01-01"
     ));

7.2 Spark 离线分析集成

借助 IoTDB-Spark-Connector，直接加载 TsFile 文件为 Spark DataFrame，无需数据导出迁移，高效支撑离线大数据分析：

val df = spark.read.format("org.apache.iotdb.spark.tsfile")
   .option("path", "/hdfs/data/sequence/")
  .load()
df.filter("time > '2023-01-01'").groupBy("device").avg("temperature").show()

7.3 Hadoop MapReduce 集成

TsFile 原生适配 MapReduce 输入格式，支持大规模并行离线扫描与数据统计：

Job job = Job.getInstance(conf);
job.setInputFormatClass(TsFileInputFormat.class);
TsFileInputFormat.setInputPaths(job, new Path("/user/iotdb/data"));
// 预设查询过滤条件，减少无效扫描
TsFileInputFormat.setQuery(job, "SELECT * FROM root.** WHERE temperature > 80");

7.4 Pipe 数据同步与灾备

IoTDB 内置 Pipe 数据同步模块，支持 TsFile 级别增量同步，适配边缘上云、集群灾备、跨地域数据复制场景：

CREATE PIPE data_sync AS 
SOURCE('iotdb-connector', 'host=127.0.0.1', 'port=6667')
SINK('hdfs', 'path=/backup/iotdb/')
WITH ('format'='tsfile', 'sync_interval'='60s');

八、典型落地场景与案例

IoTDB 已广泛应用于：

  • 能源电力：国家电网物联平台、中国核电设备可靠性管理；

  • 钢铁冶金：宝武钢铁远程智能运维，单序列 2000 亿时序点；

  • 轨道交通：中车四方城轨车辆智能运维，3200 测点/列车；

  • 汽车：长安汽车车联网，57 万车辆接入，8000 万测点；

  • ICT/云：华为 MRS 时序数据库、阿里云 MaxCompute 优化等。

场景一：智能制造产线设备监控

-- 场景：汽车焊装车间，500 台机器人，每台 200 个测点，10ms 采样
-- 1. 创建存储组和模板
SET STORAGE GROUP TO root.auto.welding;
CREATE SCHEMA TEMPLATE robot_template (
    current DOUBLE ENCODING=GORILLA,
    voltage DOUBLE ENCODING=GORILLA,
    torque DOUBLE ENCODING=TS_2DIFF,
    position_x DOUBLE ENCODING=GORILLA,
    position_y DOUBLE ENCODING=GORILLA,
    position_z DOUBLE ENCODING=GORILLA,
    alarm_code INT32 ENCODING=RLE
);

-- 2. 批量挂载到 500 台机器人
-- （通过脚本批量执行）
-- SET SCHEMA TEMPLATE robot_template TO root.auto.welding.robot_001;
-- ...

-- 3. 实时查询所有机器人的报警状态
SELECT LAST alarm_code 
FROM root.auto.welding.robot_*.alarm_code
WHERE alarm_code > 0;

-- 4. 查询某机器人过去 1 小时的轨迹（三维位置）
SELECT position_x, position_y, position_z
FROM root.auto.welding.robot_001
WHERE time >= now() - 1h;

-- 5. 计算每小时能耗（电流 × 电压积分）
SELECT 
    time,
    SUM(current * voltage) * 0.001 AS energy_kwh
FROM root.auto.welding.robot_001
GROUP BY ([now() - 24h, now()), 1h);

场景二：车联网实时数据处理

// 场景：10 万辆车，每车 100 个 CAN 信号，每秒上报
// 使用 IoTDB + Kafka + Flink 实时处理

// Flink 实时计算车辆急加速/急减速事件
DataStream<TelemetryEvent> stream = env
    .addSource(new FlinkKafkaConsumer<>("vehicle-can", new CANDecoder(), properties))
    .assignTimestampsAndWatermarks(
        WatermarkStrategy.<TelemetryEvent>forBoundedOutOfOrderness(Duration.ofSeconds(30))
    );

// 5 秒窗口计算加速度
DataStream<AlertEvent> alerts = stream
    .keyBy(event -> event.vehicleId)
    .window(TumblingEventTimeWindows.of(Time.seconds(5)))
    .aggregate(new AverageAggregate())
    .map(avg -> {
        double acceleration = (avg.speed - avg.lastSpeed) / 5.0;
        if (acceleration > 3.0) {  // 急加速阈值 3 m/s²
            return new AlertEvent(avg.vehicleId, "HARD_ACCELERATION", avg.timestamp);
        }
        return null;
    })
    .filter(Objects::nonNull);

// 写入 IoTDB 告警序列
alerts.addSink(new IoTDBSink<>("iotdb", 6667, "root", "root",
    (AlertEvent alert) -> new IoTDBRow(
        "root.vehicle." + alert.vehicleId + ".alerts",
        alert.timestamp,
        Arrays.asList("event_type", "severity"),
        Arrays.asList(TSDataType.TEXT, TSDataType.TEXT),
        Arrays.asList(alert.type, "HIGH")
    )
));

// 原始 CAN 数据同时写入 IoTDB 用于事后分析
stream.addSink(new IoTDBSink<>("iotdb", 6667, "root", "root"));

这些场景的共同特点是：设备规模大、测点多、写入频率高、需长期存储、要求低查询延迟，正是 IoTDB 的主战场。

九、总结与选型思考

面对千亿级海量工业时序数据，高性能时序数据库必须具备四大核心能力，也是技术选型的核心评判标准：

  1. 超高写入吞吐：稳定承接海量并发写入，高乱序、高负载下无丢数、无性能断崖下跌；

  2. 极致存储性价比：通过专属编码压缩，大幅降低物理存储成本，无需复杂分层存储；

  3. 高效查询性能：支撑大范围、高基数、通配符聚合查询，实现秒级/亚秒级响应；

  4. 低运维复杂度：无需频繁冷热迁移、索引重建、分片重均衡，大幅降低运维成本。

Apache IoTDB 通过自研TsFile存储格式、顺乱序分离写入引擎、工业级树形元数据模型、原生分布式架构，全方位解决了工业物联网时序数据写入、存储、查询、扩容、运维的全链路痛点。

参考资料与资源

开源版本官方下载地址：https://iotdb.apache.org/zh/Download/，可获取各版本二进制

结合业务场景的选型建议；

企业级技术与解决方案官网：https://timecho.com，提供工业级时序数据库落地方案、行业案例与技术服务支持；

  • 中小规模监控场景（<100万序列、存储周期<30天）：主流时序数据库均可适配，优先考虑社区生态与上手成本；

  • 大规模工业物联网场景（千万级序列、长期存储）：优先选择 IoTDB，重点关注其高基数处理、高压缩比、线性扩容能力；

  • 端边云协同场景：IoTDB 原生端边云架构具备不可替代的场景优势；

  • PostgreSQL生态场景：可评估 TimescaleDB 适配方案；

  • 纯云原生K8s监控场景：Prometheus + Thanos/Cortex 为成熟标配。

# 时序数据库 # 大数据 # 数据库
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

分层架构中的“防腐层”与 DTO 转换最佳实践

本文以电信性能监控系统为例，探讨领域驱动设计(DDD)在复杂系统中的应用。针对业务逻辑庞杂、外部依赖多的问题，提出通过防腐层(ACL)和DTO转换构建高内聚低耦合架构的解决方案。文章详细阐述了四层架构模型（用户接口层、应用层、领域层、基础设施层）及其数据流转机制，并以场景监控功能为例，展示了从领域模型定义、ACL转换到视图对象设计的完整实践过程。重点强调了领域模型应包含业务行为、使用MapStru

avatar AtomGit开源社区
cover

Mooncake：以 KVCache 为中心的分离式 LLM 服务架构

avatar AtomGit开源社区

Solon框架模板漏洞深度剖析与修复实战

分析发现 Solon 框架在3.1.0版本上存在一个有意思的模板漏洞，对这个漏洞进行简单分析后，发现整个漏洞的利用链是非常有意思的。同时发现最新版的修复方式过于简单，询问 AI 后，AI 也认为修复也是不完善的安全修复，于是进行一系列的绕过尝试，最后还是没有利用成功，简单进行分享。Solon 是一个轻量级的 Java 应用开发框架，类似于 Spring Boot ，但更加轻量。支持多种模板引擎，包

avatar AtomGit开源社区