Apache IoTDB 树表双模型直播回顾（下）

最新推荐文章于 2025-11-13 17:28:48 发布

原创

最新推荐文章于 2025-11-13 17:28:48 发布 · 1.5k 阅读

32 ·

CC 4.0 BY-SA版权

文章标签：

#apache #iotdb

2 月 26 日面向 Apache IoTDB 树表双模型的功能特性、适用场景、建模选择和未来规划，田原同学通过直播进行了全面解答。以下为直播讲稿（下），干货满满，建议收藏⬇️⬇️

⚡️注意：

1. 功能演示部分请直接查看视频（1:21:17 开始）观看

2. 需要获取直播 PPT 请联系小助手欧欧（微信号 apache_iotdb）

时序数据模型介绍

表模型功能介绍（本期文字）

创建表模型连接

数据库&表管理

数据写入

数据删除

数据更新

数据查询

表模型 RoadMap（本期文字）

表模型功能介绍

跟大家简单介绍了背景之后，会再花一些时间去介绍一下怎么创建表模型的连接，怎么进行表跟数据库的管理，还有增删改查这四个常见的操作，可能查询会讲得久一点。

（1）创建表模型连接

首先是创建表模型的连接，我们有 client，就是我们自己提供的命令行，还有 JDBC，还有 Java 的这些 SDK，那它们的指定方式分别是什么呢？就是刚刚也提到过的 -sql_dialect。我们是把 table 和 tree 作为两种视图、两种方言，去对同一个数据进行操作的，所以是通过 -sql_dialect table 的方式去指定连接用哪一个视图去看你的这份数据。这个参数是可选的，这是为了以前的树模型用户做兼容，因为以前树模型用户是不需要指定这个的，所以你不指定的话，我们还是默认为你是树模型用户，你只有指定了这个之后，你才是一个表模型用户。连进来之后，我们在 CLI 里面也可以执行 SET SQL_DIALECT=TABLE/TREE 进行模型切换，或者执行 SHOW CURRENT_SQL_DIALECT 去看当前的模型到底是树，或者当前的语法到底是树还是表。

JDBC 也是一样的，它通过这个问号后面的 sql_dialect=table 去决定是 table 还是 tree，你不指定的话默认还是tree。跟树模型不太一样的是我们在这个端口后面还多增加了一级数据库，对于表模型来讲，你可以直接连到这个默认数据库的空间，也可以执行 SET SQL_DIALECT=TABLE/TREE 去进行模型的切换。

Java 的 SDK 就比较简单了，我们重新为表模型抽象了一套接口，也就是我在用表试图进行写入和查询的时候，它是用 ITableSessionPool 和 ITableSession 这两个组件进行读写的，原来的 Session 或者 SessionPool 就服务于树模型了。通过这样做区分之后，它就不支持模型切换了，因为本身接口名字就已经决定了它一定是一个表模型。

（2）数据库&表管理

接下来一块是我们的数据库和表管理。刚刚说不同的模型，它在空间上面目前是分离的，所以一个数据库它要么属于树模型，要么属于表模型，取决于是在树模型连接下面创建的，还是表模型连接下面创建的。一个 DATABASE 下面可以有多张表，我们的时间分区也只能指定到 DATABASE 层级，就是我要按多少天或者默认一周进行分区。数据副本也只能指定到数据库层级，但是 TTL 是可以指定到表级别的。

对于这个逻辑视图而言，左下角的逻辑视图，用户看到的就是一个 IoTDB 下面可以有多个 DATABASE，每个 DATABASE 下面有多张表。但是到 IoTDB 的物理文件组织上面，data 目录下面可能先分了顺序/乱序，顺序下面分了不同的 DATABASE。DATABASE 到表之间还有两层，这两层就是我们做写入并发或者查询并发的时候，IoTDB 在内部帮我们做了 region，就是我们的一个并发单元。这个 region 下面会有刚刚说的指定时间分区，每个时间分区数据是会被放在一个文件夹下面的，一个时间分区下面会有多个 table 的数据。物理上面是这样组织的，会比逻辑视图要稍微复杂一点。

那我们怎么去创建一个表呢？创建语法其实也跟关系型数据库比较类似，唯一的区别就是我们多了一个列类别，我在这边用颜色标出来的，包括标签列、属性列、TIME 列和测点列，我们要在数据类型后面去指定到底这一列属于哪个类别。写出来的这个创建示例以 region、car_id 作为 TAG 列，model，就是属于哪一种车型作为属性列，速度还有温度作为 FIELD 列。

（3）数据写入

表模型的功能首先是数据写入。数据写入目前是支持 CLI 里面的 SQL、JDBC SQL、Java SDK、Python SDK 以及 REST API SDK。

大家可能会比较好奇我应该用哪一个？首先对于 CLI 里面的 SQL，它肯定不适合在生产里面去写数据，因为它只适合我们测试的时候去随时构造测试的数据集，并且随时去查看这个数据集对不对。JDBC SQL 是一个标准的接口协议，适合跟第三方的生态做集成，比如 DBeaver。目前不太推荐在生产里面直接用 JDBC 进行写入，因为它的写入性能相较于下面几个会低一些。Java SDK 就是我们原生提供的 Java 的 API，它的性能非常高，我们推荐生产里面直接用；Python 也是，这个取决于你的业务到底是用 Java 写的还是用 Python 写的，可以选择不同的 SDK 进行写入。REST API 的性能也比 JDBC SQL 要高，但是它比 Java 和 Python 这种原生的数据接口要稍微低一些，它适合一些业务开发语言 SDK 还没有提供的时候使用，比如 C、C++、Go 语言还没提供，可以用 REST API 进行写入。

表格中也对各类写入方式的便捷程度、性能以及是否支持自动建表和自动扩展列做了一个对比，大家也可以根据这个表格去决定自己到底要用什么。这里为什么有一些是不支持的，比如 CLI SQL 和 JDBC SQL 为什么不支持自动建表和自动扩展列？因为我们的写入 SQL 是向标准 SQL 做兼容的，我们不会在 insert 里面去