IoTDB 在国际数据库性能测试排行榜中位居第一?测试环境复现与流程详解

9 月 19 日,数据库性能测试平台 benchANT 发布了最新的时序数据库排行榜,其中 Apache IoTDB 的各项性能指标均处于领导地位【1】。

benchANT排行总榜截图-20230927.png

(benchANT 时序数据库排行榜)

在写入、查询与存储性能方面,IoTDB 均表现优异。IoTDB 的写入吞吐量(Write Throughput)通过计算导入 2,617,920,000 个数据点的耗时得到,测试结果可达到 363 万点/秒,与 benchANT 排行榜中的 InfluxDB、TimescaleDB 、QuestDB 对比,IoTDB 的写入吞吐量最多是其 6.9 倍,最少也可达到 1.4 倍。

查询延迟(Read Latency):通过查询“1 个设备的 1 个测点在 1 个小时内按照 1 分钟进行分段聚合的值”这一场景计算得到,IoTDB 的查询延迟可达到 2 毫秒。与 benchANT 排行榜中的 InfluxDB、TimescaleDB、QuestDB 对比,IoTDB 的查询响应速度最多是其 96.5 倍,最少也可达到 3 倍。

存储占用(Storage Comsumption): 通过在查询测试结束时记录存储空间占用得到,IoTDB 的存储占用可达到仅占用 2 GiB。与 benchANT 排行榜中的 InfluxDB、TimescaleDB、QuestDB 对比,IoTDB 的存储占用最低是其 1/35。

同时,排行榜考虑到 AWS 云服务器的硬件成本,用读取吞吐量(Read Throughput)除以月成本(Monthly Costs),计算出的成本效益(Operations Per Cost),也就是代表“每一美元能够置换多少的读取性能”,进而评估时序数据库的投入性能比。在这一指标中,IoTDB 与排行榜中的 InfluxDB、TimescaleDB、QuestDB 对比,成本效益最多是其 22.2 倍,最少也可达到 1.4 倍,在使用性价比上也存在优势。

下图反映了排行榜上的主流时序数据库的各项性能测试指标对比:

benchANT性能对比图-20230927.png

(benchANT 时序数据库排行榜各数据库性能对比)

Timecho 团队基于 benchANT 使用的服务器硬件环境和参数配置,基于TSBS工具对这些数据库系统进行了重复测试,以对排行榜中的结果进行验证。

1. 背景介绍

benchANT 位于德国,是一家专门做云设施和数据库性能评估的测试机构。在用户对数据库选型很难找到以性能、功能表现为参考基准榜单的情况下,benchANT 致力于在统一的硬件资源,相同的系统配置和固定的测试负载下对各类常见的关系型数据库、NoSQL 数据库及时序数据库做性能测试,以保证测试结果的公平性,并依据各项指标进行排名。

当前 benchANT榜单上收录了如下三种测试场景:

  • "CRUD: General Purpose":该场景主要测试数据库 CRUD 操作的性能,使用的测试工具为 YCSB【2】。benchANT 在该场景测试了 MySQL、PostgreSQL 及 Cassandra 等数据库在不同负载下的性能对比(读写延迟、吞吐等指标)。

  • "OLTP: Mix":该场景主要测试数据库在事务方面的性能,使用的测试工具为 Sysbench【3】。benchANT 在该场景测试了 MySQL 及 PostgreSQL 等数据库在不同负载下的性能对比(每秒执行的事务数量、查询延迟等指标)。

  • "Time Series: DevOps":该场景主要测试时序数据库的读写性能,测试工具为 TSBS 测试工具作为基准。Time Series Benchmark Suite (TSBS) 由 Timescale 开发,提供了时序数据生成、数据导入、查询生成、查询执行等功能,并可以自动化统计测试的结果【4】。作为一个开源的项目,TSBS 被 InfluxDB、TimescaleDB、VictoriaMetrics、QuestDB、ClickHouse 等众多时序数据库系统接受,同时有很多数据库厂商依据这个基准生成测评报告对外公布,以证明其数据库系统的优异性能。不过benchANT 做出的时序数据库性能测试排行稍有不同:benchANT基于TSBS套件的DevOps场景,设置了统一的预置参数(工作负载、集群大小等),然后将各数据库部署在相同的 AWS(Amazon Web Services)云环境中进行测试,以得出一个客观的测试结果,其中包含了下列6个指标:

    • WRITE THROUGHPUT:写入吞吐,单位时间内处理的写入数据点数量,该数值越高表明数据库写入性能越高。

    • READ THROUGHPUT:查询吞吐,单位时间内处理的查询请求的数量,该数值越高表明数据库处理查询请求的能力越强。

    • READ LATENCY:查询延迟,单个查询的响应时间,该数值越低表明数据库处理单个查询的速度越快。

    • STORAGE CONSUMPTION:存储空间占用,记录测试运行过程中的磁盘平均使用量。

    • MONTHLY COSTS:月度开销,仅与使用的AWS机器费用有关。

    • OPERATIONS PER COST:成本效益,记录单位开销内能够执行的操作数量,该数值越高表明数据库的成本效益越大。

2. 测试准备

2.1 软件版本

本次测试中采用的 IoTDB 版本为 V1.2.1【5】,硬件资源使用AWS-EC2,采用的 JDK 版本为 OpenJDK17,采用的Golang版本为1.19,测试工具为 benchANT fork 在代码仓库下的 TSBS【6】。

2.2 硬件资源和配置

为保证公平性及可复测性,benchANT 针对数据库的测试均运行在亚马逊云服务 AWS EC2 上,通过标准化的流程一键评测并生成测评结果。其中针对时序场景的测试,benchANT 通过 Scaling 属性进行区分不同的测试规模,该属性描述了实例规格和测评数据库集群规格的对应关系,集群 small(即 1 节点)+ 实例大小 small = xSmall scaling,集群 small (即1节点)+ 实例大小 medium = small scaling。其中 small, medium 实例的配置如下:

benchANT硬件资源配置-20230927.png

需要说明的是,benchANT 在时序测试场景下构建了 xSmall 与 small 两种规模均非大规模集群。在我们实际的测试中,随着机器规格的提升,IoTDB 对机器资源的调度可以更加精细、具有更大的发挥空间。通过构建不同的规模,可以更全面的评测数据库在不同资源下的性能表现。

在 xSmall scaling 下,benchANT 客户端使用 AWS EC2 c5.4xlarge 实例,客户端机器的规格为 16 核 32GB;IoTDB Server 使用 AWS EC2 m5.large 实例,Server 的规格为 2 核 8GB,IoTDB 的部署形态为 1ConfigNode 1DataNode。

在 small scaling 下,benchANT 客户端使用 AWS EC2 c5.4xlarge 实例,客户端机器的规格为 16 核 32GB;IoTDB Server 使用 AWS EC2 m5.xlarge 实例,Server 的规格为 4 核 16GB,IoTDB 的部署形态为 1ConfigNode 1DataNode。

benchANT测试实例-20230927.png

3. 测试步骤

3.1 IoTDB 建模

在测试中,IoTDB 的建模如下图所示:

benchANT建模-20230927.png

如上文介绍,benchANT 的测试选取了 TSBS 中的 DevOps 场景,该场景模拟了服务器运行时的监控数据,每个运行的服务器(设备)均采集 9 大项监控指标(cpu、diskio、disk、kernel、mem、net、nginx、postgresl、redis)。

9项监控指标 metric 作为 9 个 db,每个 db 下均有 1000 个设备(代表 1000 台服务器),每个 db 下的设备采集的测点保持一致,如 cpu metric 下一共记录了 10 个测点,分别为:usage_user、usage_system、usage_idle、usage_nice、usage_iowait、usage_irq、usage_softirq、usage_steal、usage_guest 和 usage_guest_nice,这 10 项测量值的数据类型均为 INT,记录了用户侧 CPU 使用率、系统侧 CPU 使用率等;mem metric 下一共记录了 9 个测点,分别为:total、available、used、free、cached、buffered、used_percent、available_percent 及 buffered_percent,这 9 项测量值的数据类型为 INT 或 DOUBLE,记录了内存总量、内存可用量、内存空闲量等。9 个大项监控指标累计记录了 101 项测量值。

除了测量值外,每个设备也会记录其专属的 tags 信息(标签值),标签值是设备的描述,其不随时间而进行改变,在 benchANT 测试场景中设备的 tags 信息记录了 region、datacenter、rack、os、arch、team、service、service_version 及 service_environment 字段,IoTDB 将 tags 数据当作一个测点存储于设备之下,并在该测点上添加 tags 索引。

在该建模中,每个设备均为对齐设备,即该设备下所有测点的时间戳都是“对齐”的【7】,采用对齐设备,可以在一定程度上提升写入性能,降低存储空间占用。

另外我们可以发现,对于每一个 db,该 db 下的所有设备挂载的测点都是相同的,实际上这种结构也可使用 IoTDB 中的“模板”进行优化【8】,以 cpu metric 为例,在 IoTDB 中创建一个 cpu 模板 cpu_template:

create schema template cpu_template (
usage_user INT32, usage_system INT32, usage_idle INT32, usage_nice INT32, usage_iowait INT32, usage_irq INT32, usage_softirq INT32, usage_steal INT32, usage_guest INT32, usage_guest_nice INT32);
set schema template cpu_tempalte to root.cpu;

然后将该模板挂载至 root.cpu 层级并激活即可,如此 root.cpu 下的设备都会包含 cpu 模板中包含的测点。通过使用模板,可以降低数据库的元数据空间占用。

3.2 写入性能

测试数据集共生成了1000 个设备(服务器),数据集的时间范围为 3 天(2022-07-25T00:00:00Z ~ 2022-07-28T00:00:00Z),数据的采集间隔为 10 秒,所以一共包含 1000 3 24 60 6 * 101 = 2,617,920,000 个数据点。benchANT 榜单里的写入吞吐,便是通过计算导入 2,617,920,000 个数据点所需的耗时得到。

数据写入阶段包含大量的可调参数,参数不同,数据库的性能也可能有很大不同。为保证测试的公平性,benchANT 测试采用的关键参数如下:

  • "workers": benchANT用于数据导入的并发客户端数量,当数据库部署在 2C8GB 实例时,该值设置为 50;当数据库部署在 4C16GB 实例时,该值设置为 100。

  • "hashWorkers": 控制数据的写入转发规则,当该值设置为 true 时,可以保证相同设备的数据均由同一个客户端进行写入,保证了数据库服务端不会接收到乱序数据;当该值设置为 false 时,则每个设备的数据都会由随机的客户端进行写入,数据库服务端会接收到一定程度的乱序数据。 benchANT 在时序场景下的测试,针对所有数据库的测试该值均设置为 false,这样测试出的结果更加贴近真实场景。

  • "batchSize": 单次写入包含的数据点数量,针对所有时序数据库的测试该值均设置为 1000。

3.3 查询性能

在数据导入阶段完成后,benchANT 会执行查询性能测试,针对 Devops 场景,TSBS 提供了"single-groupby-1-1-1"、"single-groupby-1-1-12"等多种查询类型,而在 benchANT 的测试框架里,目前只基于最具代表性的"single-groupby-1-1-1"查询类型进行评测。

"single-groupby-1-1-1"查询类型表示的含义是“查询 1 个 metric 中的 1 个 host 在 1 个小时内按照 1 分钟进行分段聚合的值”,参考“3.1 IoTDB 建模”小节,针对该类型的 IoTDB 查询示例 SQL 语句为:SELECT MAX_VALUE(usage_user) FROM root.cpu.host_1 GORUP BY ([2022-07-25 00:00:00, 2022-07-25 01:00:00), 1h)

在 benchANT 的测试中,一共生成了 100000 个"single-groupby-1-1-1"类型的查询语句,每个查询语句会从Metric "CPU"下的1000个设备里随机选择1个设备、从 "2022-07-25T00:00:00Z"至"2022-07-28T00:00:00Z" 的时间区间内随机选择1个小时作为查询条件。执行完 100000 次查询后,记录整个查询阶段的查询吞吐、查询延迟信息。

查询测试中的关键参数是"workers",表示执行查询测试时并发客户端的数量,该参数与数据写入时指定的"workers"参数保持一致。

3.4 命令集脚本

本章节介绍 benchANT 测试流程使用的命令集脚本。

用户首先需要在 AWS 创建 EC2 实例来部署测试客户端与数据库服务端。客户端对应的 EC2 规格代码固定为 c5.4xlarge,服务端根据测试负载不同对应两类规格代码 m5.largem5.xlarge。EC2实例操作系统选择 ubuntu,存储类型选择 GP2,存储容量为 100 GB。

创建完 EC2 实例后,用户需要在客户端部署 TSBS,在服务端部署 IoTDB Server(采用默认的 1 ConfigNode + 1 DataNode 模式部署)。客户端安装好 Golang 编译环境后,通过链接 https://github.com/benchANT/tsbs 将代码下载至本地,在代码目录执行 make 命令即可一键生成可执行程序,以下 4 个步骤涉及的“数据生成”、“数据导入”、“生成查询”及“执行查询”程序均位于 bin 目录下。

本章节假设 IoTDB Server 部署在 m5.xlarge实例上,部署的机器 IP 为 172.31.8.255。

3.4.1 数据生成

nohup bin/tsbs_generate_data --use-case="devops" --seed=123 --scale=1000 \
  --timestamp-start="2022-07-25T00:00:00Z" \
  --timestamp-end="2022-07-28T00:00:00Z" \
  --log-interval="10s" --format="iotdb" \
  > iotdb-data-1000hosts-3days &

其中参数的含义如下:

  • use-case:测试场景,有"devops"与"iot"两种。benchANT 测试使用的是"devops"。该场景模拟了服务器运行时的监控数据。

  • seed:数据生成的随机数种子。

  • scale:devops 场景中 host/ 服务器的数量,等同于 IoTDB 里设备的数量。

  • timestamp-start:生成数据集的开始时间。

  • timestamp-end:生成数据集的结束时间。

  • log-interval:每条数据的时间间隔。

  • format:指定数据库。

执行完该命令生成的数据集格式如下所示,其中 0 开头的对应于 IoTDB 中的时间序列创建语句,1 开头的表示数据插入语句。

3.4.2 数据导入

nohup cat iotdb-data-1000hosts-3days | bin/tsbs_load_iotdb \
--host="172.31.8.255" --port="6667" --user="root" --password="root" --timeout=1000 \
--workers=100 --batch-size=1000 > output.log 2>&1 &

其中参数的含义如下:

  • host:IoTDB server 部署的地址,本文假设 IoTDB 部署的地址为"172.31.8.255"。

  • port:IoTDB server 部署的端口,默认为 6667。

  • user:IoTDB 连接用户名,默认为 root。

  • password:IoTDB 连接密码,默认为 root。

  • timeout:IoTDB 执行请求的超时时间。

  • workers:并发客户端数量。

  • batch-size:批处理大小,benchANT 客户端每次转发的数据行数。

该命令执行结束之后,会在output.log文件保存写入测试的结果,包含写入的数据总量、写入耗时、写入吞吐等指标。

3.4.3 生成查询

bin/tsbs_generate_queries --use-case="devops" --seed=123 --scale=1000 \
    --timestamp-start="2022-07-25T00:00:00Z" \
    --timestamp-end="2022-07-28T00:00:00Z" \
    --queries=100000 --query-type="single-groupby-1-1-1" --format="iotdb" \
    > iotdb-queries.txt

其中参数的含义如下:4.1

  • timestamp-start:查询数据集的开始时间。

  • timestamp-end:查询数据集的结束时间。

  • use-case:测试场景,与写入数据生成时使用的参数保持一致。

  • seed:数据生成的随机数种子。与写入数据生成时使用的参数保持一致。

  • scale:devops 场景中 host/ 服务器的数量,等同于 IoTDB 里设备的数量,与写入数据生成时使用的参数保持一致。

  • queries:生成的查询测试语句的数量。

  • query-type:查询类型。 benchANT 测试使用了查询类型"single-groupby-1-1-1",即查询一个设备、一个测点在 1 小时内按分钟分段聚合的结果。生成的查询语句示例:SELECT MAX_VALUE(usage_user) FROM root.cpu.host_1 GORUP BY ([2022-07-25 00:00:00, 2022-07-25 01:00:00), 1h)

执行完该条命令后,总共会生成十万条查询语句,每个查询语句会从 Metric "CPU" 下的 1000 个设备里随机选择 1 个设备、从 "2022-07-25T00:00:00Z"至"2022-07-28T00:00:00Z" 的时间区间内随机选择 1 个小时作为查询条件。

3.4.4 执行查询

cat iotdb-queries.txt | bin/tsbs_run_queries_iotdb \
--host="172.31.8.255" --port="6667" --user="root" --password="root" \
--workers=100 --print-responses=false --use-groupby=true

其中参数的含义如下:

  • host:IoTDB server 部署的地址,本文假设 IoTDB 部署的地址为"172.31.8.255"。

  • port:IoTDB server 部署的端口,默认为 6667。

  • user:IoTDB 连接用户名,默认为 root。

  • password:IoTDB 连接密码,默认为 root。

  • workers:并发客户端数量。

  • print-responses:是否打印查询的结果。

  • use-groupby:使用 IoTDB GroupBy RPC 接口。

该命令执行结束之后,会打印出查询测试的结果,包含查询延迟、查询吞吐等指标。

为了使得 JIT 可以更好的进行代码编译预热,上述测试语句可以重复执行 3 次,每次执行间隔 30s。

4. 性能测试结果与分析

4.1 测试结果

下图所示为 benchANT 在时序场景下的测试榜单,可以看到 IoTDB 在 small Scaling 环境与 xSmall Scaling 环境下的读、写、存储性能均排在首位,且大幅领先其他数据库产品。

Small Scaling 环境下的测试榜单:

benchANT small scaling-20230927.png

(benchANT 时序数据库排行榜: Small Scaling)

xSmall Scaling 环境下的测试榜单:

benchANT xsmall scaling-20230927.png

(benchANT 时序数据库排行榜: xSmall Scaling)

写入吞吐(WRITE THROUGHPUT):表示单位时间内处理的写入数据点数量,该数值越高表明数据库写入性能越高。在 small Scaling 环境下,IoTDB 的写入吞吐为 3,636,312 ops,是 InfluxDB 的 6.9 倍、TimescaleDB 的 2.3 倍、QuestDB 的 1.4 倍;在 xSmall Scaling 环境下,IoTDB 的写入吞吐为 1,426,490 ops,是 InfluxDB 的 5.4 倍、TimescaleDB 的 1.1 倍、QuestDB 的 2.8 倍。

查询延迟(READ LATENCY):表示单个查询的响应时间,该数值越低表明数据库处理单个查询的速度越快。在 small Scaling 环境下,查询延迟为 2ms,查询性能是 InfluxDB 的 23 倍、TimescaleDB 的 97 倍、QuestDB 的 57 倍;在 xSmall Scaling 环境下,查询延迟为 1ms,查询性能是 InfluxDB 的 47 倍、TimescaleDB 的 430 倍、QuestDB 的 82 倍。

存储占用(STORAGE CONSUMPTION):表示存储空间占用,记录测试运行过程中的磁盘平均使用量。在 small Scaling 环境与 xSmall Scaling 环境中,IoTDB 的存储空间使用量均为 2GB,排名位于榜首,这体现了 IoTDB 实现的高压缩比能力。

成本收益(OPERATIONS PER COST):数值越高越好,因为 IoTDB 在单位成本内可执行的写入请求及查询请求是最多的,所以 IoTDB 的成本收益排名第一。

4.2 性能分析

在 benchANT 测试中,IoTDB 提供了两个版本的配置参数:Vanilla 与 Tuned,其中 Vanilla 为默认参数,即使用 IoTDB 默认的配置文件,仅修改了 JAVA 的最大堆内内存;Tuned 为进阶参数,根据机器的配置与测试负载对数据库的参数进行了相应的适配。

下表以 benchANT Small Scaling 环境( 4 核 16GB、单机部署)为例,介绍了 IoTDB 在 Vanilla 版本与 Tuned 版本下设置的参数,通过这些参数的对比,用户也可以了解 IoTDB 常见的调优方向。

benchANT参数对比-20230927.png

  • 内存参数:Vanilla 环境仅将 DataNode 的最大堆内内存设置机器内存*0.75,这种设置相对简单。Tuned 环境对 ConfigNode 与 DataNode 使用的内存进行了更加细致的分配。ConfigNode 存储的是集群全局数据,该部分数据通常占用空间较小,所以可以给 ConfigNode 分配较少的内存。DataNode 存储了真实的时间序列元数据与数据,该部分占用空间较大,所以给 DataNode 分配较多的内存。

  • GC 算法:JDK17 使用的默认 GC 算法为 G1,G1 算法以回收效率优先。而在 benchANT 的评测中,Throughput(写入吞吐、查询吞吐等)是一个重要的数据库性能衡量指标,所以可以将 GC 算法调整为更加关注吞吐量的 Parallel GC 算法。

  • 共识协议:benchANT 测试的 xSmall 与 small 场景均为数据库单机部署,而 IoTDB 默认的共识协议 Ratis,IoT 主要适配分布式集群;对于单机实例部署,采用 Simple 共识协议便可满足要求。

  • 合并参数:benchANT 测试中有一项评估指标为“存储空间占用”,而“存储空间占用”会在查询评测结束时进行统计,所以为了达到较低的“存储空间占用”,IoTDB-Tuned 适当加强了合并的力度,可以在更短的时间内完成数据合并。

  • 数据分区参数:IoTDB 在 benchANT 测试的建模中会生成 9 个 database,而 benchANT 使用的测试机器规格相对较小,所以为每个 database 分配一个 data region 便可达到足够的并行度。并机器规格提升时,可以通过调整 default_data_region_group_num_per_database 参数来提升写入及查询的并行度。

  • 其他参数:该部分列出的参数对 IoTDB 的性能影响相对较小。

    • enable_last_cache 用于控制是否开启 last 缓存,由于 benchANT 查询测试中没有最新值查询,所以可以关闭最新值缓存功能。由于 IoTDB 采用了高效的最新值缓存算法,所以该参数的开关对写入性能相对较小。

    • dn_metric_level 是 IoTDB 监控写入的级别,开启该指标主要用于线上问题排查;监控数据的采集会造成 CPU 使用率些微升高,在 benchANT 测试中可关闭该选项。

    • max_number_of_points_in_page 用于控制 TsFile 中 Page 的数据点数,通常数据点数越多、数据的压缩效果越好。同时 Page 里的数据点数也会影响查询的性能,benchANT 的查询测试只会查询 1 小时范围内的点,所以综合考虑压缩率与查询性能后,Tuned 环境将该值设置为合适的点数。

    • wal_async_mode_fsync_delay_in_ms 用于控制 WAL 模块调用 fsync 的频率,以保证数据落盘的可靠性。IoTDB-WAL 默认采用 fsync 模式,fsync_delay 等于 1 秒。通常 fsync 的频率越高,消耗的 IO 资源越多,对写入性能造成的影响越大。由于 IoTDB 采用了批量写等优化,大幅降低了 fsync 的频率对写入性能的影响,Tuned 环境将 fsync_delay 设置成 3 秒即可满足需求。

5. 总结

从测试结果可以看到,无论是在小规格机器或大规格机器上,IoTDB 都能很好的利用机器性能,表现出高效的写入效率。 并且随着机器规格的提升,IoTDB 写入性能的提升也更加明显,领先其他数据库的比例也更多。

在保持高写入性能的前提下,通过合理的文件结构设计与文件合并机制,借助于 IoTDB 强大的查询引擎及丰富的查询接口设计,IoTDB 的查询性能领先其他数据库达十倍甚至百倍。

IoTDB 提供了丰富的编码与压缩算法,能够非常好的适应各种数据类型与数据分布。在 benchANT 测试中,INT 类型使用 TS_2DIFF 编码、DOUBLE 类型使用了 GORILLA 编码,压缩方式采用了 LZ4,在保持了高压缩比的同时还能保证高写入查询性能,最终的测试结果验证了 IoTDB 的“高效读写、高压缩比”。

benchANT 对时序数据库测试的结果,证明了 Apache IoTDB 强大的性能和与较其他数据库系统的巨大优势。

6. 参考文献

【1】benchANT 排行榜, https://benchant.com/en/ranking/database-ranking

【2】YCSB 测试工具, https://github.com/brianfrankcooper/YCSB

【3】Sysbench 测试工具, https://github.com/akopytov/sysbench

【4】TSBS 测试工具介绍, https://www.timescale.com/blog/time-series-database-benchmarks-timescaledb-influxdb-cassandra-mongodb-bc702b72927e/

【5】IoTDB 版本下载, https://iotdb.apache.org/zh/Download/

【6】benchANT 测试工具, https://github.com/benchANT/tsbs

【7】Timecho 官网: IoTDB 数据模型, https://www.timecho.com/docs/zh/UserGuide/V1.2.x/Basic-Concept/Data-Model-and-Terminology.html

【8】Timecho 官网: IoTDB 元数据管理, https://www.timecho.com/docs/zh/UserGuide/V1.2.x/User-Manual/Operate-Metadata.html

更多内容推荐:

了解如何使用 IoTDB 企业版