基础概念
1. 时序数据库通用概念
本节介绍时序数据库领域中常见的基础概念，包括时序数据、时间序列、设备、测点、数据点、采集频率、TTL、元数据、编码和压缩。
1.1 时序数据
在物联网、工业生产、能源电力、车联网、基础设施监测等场景中，设备通常会通过传感器持续采集自身或环境的状态数据。例如，电机采集电压和电流，风机采集叶片转速、角速度和发电功率，车辆采集经纬度、速度和油耗，桥梁采集振动频率、挠度和位移量。
这类数据的共同特点是与时间相关：同一采集对象会随着时间推移不断产生新的记录。按时间顺序持续产生并记录的数据，称为时序数据。
1.2 时间序列
在时序数据场景中，一个采集点位会随着时间不断产生数据点，这些数据点按时间戳递增排列后，形成一条时间序列。从表格形式看，一条时间序列可以表示为由时间和值组成的数据表；从图形形式看，一条时间序列可以表示为随时间变化的趋势曲线，也可以形象地称为设备的“心电图”。
1.3 设备（Device）
设备也称为实体、装备等，是实际场景中拥有物理量的设备或装置，可以是物理设备、测量装置或传感器集合。
常见示例如下：
| 场景 | 设备示例 | 标识方式示例 |
|---|---|---|
| 能源场景 | 风机 | 区域、场站、线路、机型、实例等 |
| 工厂场景 | 机械臂 | 物联网平台生成的唯一 ID |
| 车联网场景 | 车辆 | 车辆识别代码 VIN |
| 监控场景 | CPU | 机房、机架、Hostname、设备类型等 |
1.4 测点（Timeseries）
测点也可称为物理量、时间序列、时间线、信号量、指标、点位或测量值，是实际场景中检测装置记录的测量信息。通常，一个物理量代表一个采集点位，能够定期采集所在环境或设备的物理量。一个测点随时间产生的数据点按时间戳递增排列后，即形成一条时间序列。
常见示例如下：
| 场景 | 测点示例 |
|---|---|
| 能源电力场景 | 电流、电压、风速、转速 |
| 车联网场景 | 油量、车速、经度、纬度 |
| 工厂场景 | 温度、湿度 |
1.5 数据点（Data Point）
数据点由一个时间戳和一个数值组成。时间戳用于表示数据产生的时间，数值用于表示该测点在该时间的采集结果。数值可以为 BOOLEAN、FLOAT、INT32 等多种类型。
表格形式的时间序列中的一行，或趋势图中的一个点，都可以理解为一个数据点。
1.6 采集频率（Frequency）
采集频率指物理量在一定时间内产生数据的次数。例如，一个温度传感器每秒采集一次温度数据，则采集频率为 1Hz，即每秒 1 次。
采集频率越高，单位时间内产生的数据点越多，对写入、存储和查询能力的要求也越高。
1.7 数据保存时间（TTL）
TTL 用于指定数据的保存时间。超过 TTL 的数据将被自动删除。
合理使用 TTL 可以控制磁盘空间占用，避免磁盘写满等异常，并有助于维持查询性能、减少内存资源占用。
1.8 元数据（Schema）
元数据是数据库的数据模型信息，用于描述数据的结构和定义。对于树模型，元数据通常包括路径层级、设备、测点、数据类型、编码和压缩方式等信息。
1.9 编码（Encoding）和压缩（Compression）
编码是一种压缩技术，用于将数据以二进制形式表示，从而提高存储效率。压缩是在编码后进一步压缩二进制数据，以提升存储效率。
IoTDB 支持的编码和压缩详细信息请查看：压缩和编码。
2. IoTDB 常见概念
本节介绍 IoTDB 树模型、分布式和部署中的常见概念。这些概念用于说明 IoTDB 如何以层级路径组织、管理和部署时序数据。
2.1 数据模型相关概念
2.1.1 数据模型（sql_dialect）
IoTDB 支持树模型和表模型两种数据模型。两种模型管理的核心对象均为设备和测点，但组织方式和使用语法不同。
树模型：以层级路径的方式管理数据，一条路径对应一个设备的一个测点。
表模型：以关系表的方式管理数据，推荐一张表对应一类设备。
同一个集群实例中可以存在两种模型空间。不同模型的语法、数据库命名方式不同，默认不互相可见。
2.1.2 数据库
树模型中的数据库是以 root. 为前缀的一段路径，可理解为树模型数据的上层管理边界。建模时通常推荐仅使用 root 的下一级节点作为数据库，例如 root.db。
数据库的父节点或子节点不能再设置为数据库。一个数据库也可以充分利用机器资源，通常无需为了性能原因创建多个数据库。
2.1.3 时间序列与设备
时间序列（测点）是以数据库路径为前缀、由英文句号（.）分割的完整路径，可包含任意多个层级。每条时间序列可以有独立的数据类型、编码方式和压缩方式。
树模型中通常将倒数第二级视为设备。例如 root.db.turbine.device1.metric1 中，device1 这一层级即为设备，metric1 为测点。设备无法单独创建，通常随时间序列创建而存在。
建模时，建议仅将能够唯一定位时间序列的标签放入路径中，一般不超过 10 层；低基数标签尽量放在前面，便于系统压缩公共前缀。
如果设备数量较少但单设备测点数量很多，可在末级增加 .value 等层级，使倒数第二层节点数量更充足，例如 root.db.device01.metric.value。
2.1.4 别名、标签和属性
创建时间序列时，可以为测点添加别名、标签和属性。别名与测点绑定，可在使用原测点名的场景中等价使用；SQL 查询中的临时别名只替代本次查询结果中的名称，不与时间序列绑定。
| 概念 | 作用 |
|---|---|
| 别名（Alias） | 绑定到测点，用于替代原测点名进行访问 |
| 标签（Tag） | 可用于查询时间序列路径，系统维护“标签 -> 时间序列路径”的索引 |
| 属性（Attribute） | 用于描述时间序列，只能从时间序列路径查询属性信息 |
2.2 分布式相关概念
IoTDB 支持以集群方式运行。集群中常见概念包括节点、Region 和多副本。一个常见的集群部署模式是 3C3D，即 3 个 ConfigNode 和 3 个 DataNode。
2.2.1 节点
IoTDB 集群包括 ConfigNode、DataNode 和 AINode 三类节点。
ConfigNode：管理集群的节点信息、配置信息、用户权限、元数据、分区信息等，负责分布式操作的调度和负载均衡。所有 ConfigNode 之间互为全量备份。
DataNode：服务客户端请求，负责数据的存储和计算。
AINode：提供机器学习能力，支持注册已训练好的机器学习模型，并通过 SQL 调用模型进行推理。
2.2.2 数据分区（Region）
在 IoTDB 中，元数据和数据都被划分为较小的分区，即 Region，并由集群中的各个 DataNode 管理。
SchemaRegion：元数据分区，用于管理一部分设备和测点的元数据。
DataRegion：数据分区，用于管理一部分设备在一段时间内的数据。
不同 DataNode 上相同 RegionID 的 Region 互为副本。
2.2.3 多副本
数据和元数据的副本数可配置。多副本可提供高可用服务。
| 类别 | 配置项 | 单机推荐配置 | 集群推荐配置 |
|---|---|---|---|
| 元数据 | schema_replication_factor | 1 | 3 |
| 数据 | data_replication_factor | 1 | 2 |
2.3 部署相关概念
IoTDB 有两种运行模式：单机模式和集群模式。
2.3.1 单机模式
IoTDB 单机实例包括 1 个 ConfigNode、1 个 DataNode，即 1C1D。
特点：便于开发者安装部署，部署和维护成本较低，操作方便。
适用场景：资源有限或对高可用要求不高的场景，例如边缘端服务器。
部署方法：单机版部署。
2.3.2 集群模式
IoTDB 集群实例为 3 个 ConfigNode 和不少于 3 个 DataNode，通常为 3 个 DataNode，即 3C3D；当部分节点出现故障时，剩余节点仍然能对外提供服务，保证数据库服务的高可用性，且可随节点增加提升数据库性能。
特点：具有高可用性、高扩展性，可通过增加 DataNode 提高系统性能。
适用场景：需要提供高可用和可靠性的企业级应用场景。
部署方法：集群版部署。
2.3.3 特点总结
| 维度 | 单机模式 | 集群模式 |
|---|---|---|
| 适用场景 | 边缘侧部署、对高可用要求不高 | 高可用性业务、容灾场景等 |
| 所需机器数量 | 1 | ≥3 |
| 安全可靠性 | 无法容忍单点故障 | 高，可容忍单点故障 |
| 扩展性 | 可扩展 DataNode 提升性能 | 可扩展 DataNode 提升性能 |
| 性能 | 可随 DataNode 数量扩展 | 可随 DataNode 数量扩展 |
单机模式和集群模式，部署步骤类似（逐个增加 ConfigNode 和 DataNode），仅副本数和可提供服务的最少节点数不同。