这几个 IoTDB 分布式调优的关键细节，你一定要知道！

（本文适用于 IoTDB 1.3 与 2.0 版本）

最近有用户联系到我们，问：

我看 IoTDB 官网的例子，都是讲智慧工厂的，有没有通用的数据建模方案？每个省建立一个数据库是否性能更好？路径是否可以设置为 root.省份.车牌号.设备类型.设备号.物理量？

这位朋友提出的这些问题涵盖了几个关键的“知识点”，接下来我们将逐一展开并回答。

01 数据库建几个？

答案很明确，不需要为了性能而去建多个数据库。IoTDB 作为一个分布式数据库，不需要因为性能原因特意做分库分表，即使只建立一个数据库，也足以吃满机器的性能。

当然，由于不同数据库之间可以单独设置时间分区跨度、Region 个数和权限等，也可以根据业务属性语义而去创建多数据库。不同数据库的数据是相互隔离的，不支持跨数据库的查询，这使得多数据库适合用在业务数据需要严格区分的情况下。

需要注意的是，数据库的数量不仅影响数据组织方式，还与一个重要的概念密切相关，这就是 Region。

02 Region 是什么？如何调整 Region 数量？

（1）基本知识

Region 是 IoTDB 内部一个十分重要的概念，每个 Region 都是一个单节点上相对独立的工作单元，具有独立的运行线程与持久化存储的路径。

数据库和 Region 具有一对多的绑定关系，一个数据库会拥有多个 Region，一个 Region 只能属于一个数据库，多个相同 ID 的副本 Region 分布在多个节点上，提供高可用能力。对于单节点而言，Region 越多，就越能并发利用机器资源。但 IoTDB 为每个 Region 绑定了一定的内存资源，为了防止内存溢出，每个 DataNode 的 Region 数量是有上限的。因此所有 Database 的 Region 总数量是动态变化的，拥有一个软上限。随着数据增加，Region 数量会逐渐扩增直到软上限。

经验表明，每个 DataNode 的 Region 软上限数量等于 CPU 逻辑核心数 ÷ 2，就既能达到很好的并发度，也不会占用过多内存，是通常情况下的推荐配置。

Region 数量可在 iotdb-system.properties 中进行配置，设置每个 DataNode 的 Region 数量软上限，要求整个集群一致：

• 1.3.3 与更早的版本：默认参数为 5，如需调优推荐手动计算 CPU 逻辑核心数 ÷ 2 来配置 → data_region_per_data_node=5

• 1.3.4 版本后：默认参数将变为 0，其是一个特殊标记，等效于自动识别的 CPU 逻辑核心数 ÷ 2，也可以自行计算设置为实际大于 0 的数字 → data_region_per_data_node=0

（2）深入了解

Region 有多重身份：

1. 从分布式数据库的角度，一个 Region 是一个数据分片实例。

2. 从查询和存储的角度，一个 Region 是一个串行写入的 IoT-LSM 存储引擎（可以理解成一个并发度）。

3. 从副本角度，Region 是数据复制的单元，多个相同 ID 的 Region 互为副本提供高可用能力。

如果单节点 Region 数量已经达到 CPU 逻辑核心数 ÷ 2，但读写速度还想进一步提升，此时如果通过系统指标确定硬盘 IO、网络带宽、内存 GC 和 CPU 等都不是瓶颈，这种情况有可能是并发度不足，可以将所有节点的 data_region_per_data_node 参数进一步调大到 CPU 逻辑核心数，然后重启集群，这样在新的时间分区到来时便会有新的 Data Region 被创建来承担写入压力。

对于上述提到的 Region 数量软上限 data_region_per_data_node，只有在单数据库的情况下才能确保这一个数据库独占软上限，在多数据库的情况下则各数据库会按一定的均衡策略分享此上限，在数据库较多的情况下可能会慢慢超越此软上限。

03 如何建模？

在上文的介绍之后，我们给出这位朋友关心的首选建模方案：

1. 只使用一个数据库，例如 root.db，既不会影响性能，也方便多省数据联合查询。

2. data_region_per_data_node 配置为 CPU 逻辑核心数 ÷ 2，以更充分的利用硬件资源。

3. 路径使用 root.db.省份.设备类型.车牌号.物理量，将个数越少的属性放在越上层，使得树结构达到最佳的压缩效果。