You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@iotdb.apache.org by GitBox <gi...@apache.org> on 2021/10/17 00:47:01 UTC
[GitHub] [iotdb] SteveYurongSu commented on a change in pull request #4090: [IOTDB-1810] Compatibility of Apache IoTDB with InfluxDB - Compatibility Scheme
SteveYurongSu commented on a change in pull request #4090:
URL: https://github.com/apache/iotdb/pull/4090#discussion_r729884144
##########
File path: docs/zh/UserGuide/API/InfluxDB-Protocol.md
##########
@@ -33,3 +33,217 @@ InfluxDB influxDB = InfluxDBFactory.connect(openurl, username, password);
InfluxDB influxDB = IoTDBInfluxDBFactory.connect(openurl, username, password);
```
+## 2.方案设计
+
+### 2.1 InfluxDB-Protocol适配器
+
+该适配器以 IoTDB Java Session 接口为底层基础，实现了 InfluxDB 的 Java 接口 `interface InfluxDB`，对用户提供了所有 InfluxDB 的接口方法，最终用户可以无感知地使用 InfluxDB 协议向 IoTDB 发起写入和读取请求。
+
+
+
+
+
+
+### 2.2 元数据格式转换
+
+InfluxDB 的元数据是 tag-field 模型，IoTDB 的元数据是树形模型。为了使适配器能够兼容 InfluxDB 协议，需要把 InfluxDB 的元数据模型转换成 IoTDB 的元数据模型。
+
+#### 2.2.1 InfluxDB 元数据
+
+1. database: 数据库名。
+2. measurement: 测量指标名。
+3. tags : 各种有索引的属性。
+4. fields : 各种记录值（没有索引的属性）。
+
+
+
+#### 2.2.2 IoTDB 元数据
+
+1. storage group： 存储组。
+2. path(time series ID)：存储路径。
+3. measurement： 物理量。
+
+
+
+#### 2.2.3 两者映射关系
+
+InfluxDB 元数据和 IoTDB 元数据有着如下的映射关系：
+1. InfluxDB 中的 database 和 measurement 组合起来作为 IoTDB 中的 storage group。
+2. InfluxDB 中的 field key 作为 IoTDB 中 measurement 路径，InfluxDB 中的 field value 即是该路径下记录的测点值。
+3. InfluxDB 中的 tag 在 IoTDB 中使用 storage group 和 measurement 之间的路径表达。InfluxDB 的 tag key 由 storage group 和 measurement 之间路径的顺序隐式表达，tag value 记录为对应顺序的路径的名称。
+
+InfluxDB 元数据向 IoTDB 元数据的转换关系可以由下面的公示表示：
+
+`root.{database}.{measurement}.{tag value 1}.{tag value 2}...{tag value N-1}.{tag value N}.{field key}`
+
+
+
+如上图所示，可以看出：
+
+我们在 IoTDB 中使用 storage group 和 measurement 之间的路径来表达 InfluxDB tag 的概念，也就是图中右侧绿色方框的部分。
+
+storage group 和 measurement 之间的每一层都代表一个 tag。如果 tag key 的数量为 N，那么 storage group 和 measurement 之间的路径的层数就是 N。我们对 storage group 和 measurement 之间的每一层进行顺序编号，每一个序号都和一个 tag key 一一对应。同时，我们使用 storage group 和 measurement 之间每一层 **路径的名字** 来记 tag value，tag key 可以通过自身的序号找到对应路径层级下的 tag value.
+
+#### 2.2.4 关键问题
+
+在InfluxDB中，Tag的顺序不同并不会影响实际的结果。
+
+eg:
+`insert factory,workshop=A1,production=B1 tempture=16.9`和`insert factory,production=B1,workshop=A1 tempture=16.9`两条数据表达的含义相等。
+
+但在IoTDB中，一个path由多个部分组成，比如`root.monitor.factory.A1.B1`是由一个存储组`root.monitor.factory`和两个节点`A1`和`B1`组成的。
+
+那么节点的顺序就是需要考虑的，因为`root.monitor.factory.A1.B1`和`root.monitor.factory.B1.A1`是两条不同的序列，因此可以认为IoTDB中对Tag对顺序是敏感的。
+
+所以需要记录InfluxDB每个Tag对应的顺序，确保在InfluxDB中，即使Tag不同的同一条时序对应到IoTDB中也是同一条时序。
+
+因此这时需要考虑的一个问题是InfluxDB的tag key及对应顺序关系如何持久化到IoTDB数据库中里，这样才不会丢失相关信息。
Review comment:
```suggestion
在 InfluxDB 的 SQL 语句中，tag 顺序的不同并不会影响实际的结果。
例如：
`insert factory, workshop=A1, production=B1, temperature=16.9` 和 `insert factory, production=B1, workshop=A1, temperature=16.9` 两条 SQL 的含义相等。
但在 IoTDB 中，上述插入的数据点可以存储在 `root.monitor.factory.A1.B1.temperature` 下，也可以存储在 `root.monitor.factory.B1.A1.temperature` 下。因此，IoTDB 路径中储存的 InfluxDB
的 tag 的顺序就是需要考虑的，因为 `root.monitor.factory.A1.B1.temperature` 和
`root.monitor.factory.B1.A1.temperature` 是两条不同的序列。我们也可以认为，IoTDB 对 tag 的顺序是“敏感”的。
因此，我们还需要在 IoTDB 中记录 InfluxDB 每个 tag 对应在 IoTDB 路径中的层级顺序，确保在执行 InfluxDB SQL 时，即使 tag 不同的同一条时序对应到IoTDB中也是同一条时序。
这里还需要考虑的一个问题是：InfluxDB的tag key及对应顺序关系如何持久化到IoTDB数据库中里，这样才不会丢失相关信息。
```
##########
File path: docs/zh/UserGuide/API/InfluxDB-Protocol.md
##########
@@ -33,3 +33,217 @@ InfluxDB influxDB = InfluxDBFactory.connect(openurl, username, password);
InfluxDB influxDB = IoTDBInfluxDBFactory.connect(openurl, username, password);
```
+## 2.方案设计
+
+### 2.1 InfluxDB-Protocol适配器
+
+该适配器以 IoTDB Java Session 接口为底层基础，实现了 InfluxDB 的 Java 接口 `interface InfluxDB`，对用户提供了所有 InfluxDB 的接口方法，最终用户可以无感知地使用 InfluxDB 协议向 IoTDB 发起写入和读取请求。
+
+
+
+
+
+
+### 2.2 元数据格式转换
+
+InfluxDB 的元数据是 tag-field 模型，IoTDB 的元数据是树形模型。为了使适配器能够兼容 InfluxDB 协议，需要把 InfluxDB 的元数据模型转换成 IoTDB 的元数据模型。
+
+#### 2.2.1 InfluxDB 元数据
+
+1. database: 数据库名。
+2. measurement: 测量指标名。
+3. tags : 各种有索引的属性。
+4. fields : 各种记录值（没有索引的属性）。
+
+
+
+#### 2.2.2 IoTDB 元数据
+
+1. storage group： 存储组。
+2. path(time series ID)：存储路径。
+3. measurement： 物理量。
+
+
+
+#### 2.2.3 两者映射关系
+
+InfluxDB 元数据和 IoTDB 元数据有着如下的映射关系：
+1. InfluxDB 中的 database 和 measurement 组合起来作为 IoTDB 中的 storage group。
+2. InfluxDB 中的 field key 作为 IoTDB 中 measurement 路径，InfluxDB 中的 field value 即是该路径下记录的测点值。
+3. InfluxDB 中的 tag 在 IoTDB 中使用 storage group 和 measurement 之间的路径表达。InfluxDB 的 tag key 由 storage group 和 measurement 之间路径的顺序隐式表达，tag value 记录为对应顺序的路径的名称。
+
+InfluxDB 元数据向 IoTDB 元数据的转换关系可以由下面的公示表示：
+
+`root.{database}.{measurement}.{tag value 1}.{tag value 2}...{tag value N-1}.{tag value N}.{field key}`
+
+
+
+如上图所示，可以看出：
+
+我们在 IoTDB 中使用 storage group 和 measurement 之间的路径来表达 InfluxDB tag 的概念，也就是图中右侧绿色方框的部分。
+
+storage group 和 measurement 之间的每一层都代表一个 tag。如果 tag key 的数量为 N，那么 storage group 和 measurement 之间的路径的层数就是 N。我们对 storage group 和 measurement 之间的每一层进行顺序编号，每一个序号都和一个 tag key 一一对应。同时，我们使用 storage group 和 measurement 之间每一层 **路径的名字** 来记 tag value，tag key 可以通过自身的序号找到对应路径层级下的 tag value.
+
+#### 2.2.4 关键问题
+
+在 InfluxDB 的 SQL 语句中，tag 顺序的不同并不会影响实际的结果。
+
+例如：
+`insert factory, workshop=A1, production=B1, temperature=16.9` 和 `insert factory, production=B1, workshop=A1, temperature=16.9` 两条 SQL 的含义相等。
+
+但在 IoTDB 中，上述插入的数据点可以存储在 `root.monitor.factory.A1.B1.temperature` 下，也可以存储在 `root.monitor.factory.B1.A1.temperature` 下。因此，IoTDB 路径中储存的 InfluxDB
+ 的 tag 的顺序就是需要考虑的，因为 `root.monitor.factory.A1.B1.temperature` 和
+`root.monitor.factory.B1.A1.temperature` 是两条不同的序列。我们也可以认为，IoTDB 对 tag 的顺序是“敏感”的。
+
+因此，我们还需要在 IoTDB 中记录 InfluxDB 每个 tag 对应在 IoTDB 路径中的层级顺序，确保在执行 InfluxDB SQL 时，即使 tag 不同的同一条时序对应到IoTDB中也是同一条时序。
+
+这里还需要考虑的一个问题是：InfluxDB的tag key及对应顺序关系如何持久化到IoTDB数据库中里，这样才不会丢失相关信息。
Review comment:
```suggestion
在 InfluxDB 的 SQL 语句中，tag 出现的顺序的不同并不会影响实际的执行结果。
例如：
`insert factory, workshop=A1, production=B1, temperature=16.9` 和 `insert factory, production=B1, workshop=A1, temperature=16.9` 两条 InfluxDB SQL 的含义（以及执行结果）相等。
但在 IoTDB 中，上述插入的数据点可以存储在 `root.monitor.factory.A1.B1.temperature` 下，也可以存储在 `root.monitor.factory.B1.A1.temperature` 下。因此，IoTDB 路径中储存的 InfluxDB 的 tag 的顺序是需要被特别考虑的，因为 `root.monitor.factory.A1.B1.temperature` 和
`root.monitor.factory.B1.A1.temperature` 是两条不同的序列。我们可以认为，IoTDB 元数据模型对 tag 顺序的处理是“敏感”的。
基于上述的考虑，我们还需要在 IoTDB 中记录 InfluxDB 每个 tag 对应在 IoTDB 路径中的层级顺序，以确保在执行 InfluxDB SQL 时，不论 InfluxDB SQL 中 tag 出现的顺序如何，只要该 SQL 表达的是对同一个时间序列上的操作，那么适配器都可以唯一对应到 IoTDB 中的一条时间序列上进行操作。
这里还需要考虑的另一个问题是：InfluxDB 的 tag key 及对应顺序关系应该如何持久化到 IoTDB 数据库中，以确保不会丢失相关信息。
```
##########
File path: docs/zh/UserGuide/API/InfluxDB-Protocol.md
##########
@@ -33,3 +33,217 @@ InfluxDB influxDB = InfluxDBFactory.connect(openurl, username, password);
InfluxDB influxDB = IoTDBInfluxDBFactory.connect(openurl, username, password);
```
+## 2.方案设计
+
+### 2.1 InfluxDB-Protocol适配器
+
+该适配器以 IoTDB Java Session 接口为底层基础，实现了 InfluxDB 的 Java 接口 `interface InfluxDB`，对用户提供了所有 InfluxDB 的接口方法，最终用户可以无感知地使用 InfluxDB 协议向 IoTDB 发起写入和读取请求。
+
+
+
+
+
+
+### 2.2 元数据格式转换
+
+InfluxDB 的元数据是 tag-field 模型，IoTDB 的元数据是树形模型。为了使适配器能够兼容 InfluxDB 协议，需要把 InfluxDB 的元数据模型转换成 IoTDB 的元数据模型。
+
+#### 2.2.1 InfluxDB 元数据
+
+1. database: 数据库名。
+2. measurement: 测量指标名。
+3. tags : 各种有索引的属性。
+4. fields : 各种记录值（没有索引的属性）。
+
+
+
+#### 2.2.2 IoTDB 元数据
+
+1. storage group： 存储组。
+2. path(time series ID)：存储路径。
+3. measurement： 物理量。
+
+
+
+#### 2.2.3 两者映射关系
+
+InfluxDB 元数据和 IoTDB 元数据有着如下的映射关系：
+1. InfluxDB 中的 database 和 measurement 组合起来作为 IoTDB 中的 storage group。
+2. InfluxDB 中的 field key 作为 IoTDB 中 measurement 路径，InfluxDB 中的 field value 即是该路径下记录的测点值。
+3. InfluxDB 中的 tag 在 IoTDB 中使用 storage group 和 measurement 之间的路径表达。InfluxDB 的 tag key 由 storage group 和 measurement 之间路径的顺序隐式表达，tag value 记录为对应顺序的路径的名称。
+
+InfluxDB 元数据向 IoTDB 元数据的转换关系可以由下面的公示表示：
+
+`root.{database}.{measurement}.{tag value 1}.{tag value 2}...{tag value N-1}.{tag value N}.{field key}`
+
+
+
+如上图所示，可以看出：
+
+我们在 IoTDB 中使用 storage group 和 measurement 之间的路径来表达 InfluxDB tag 的概念，也就是图中右侧绿色方框的部分。
+
+storage group 和 measurement 之间的每一层都代表一个 tag。如果 tag key 的数量为 N，那么 storage group 和 measurement 之间的路径的层数就是 N。我们对 storage group 和 measurement 之间的每一层进行顺序编号，每一个序号都和一个 tag key 一一对应。同时，我们使用 storage group 和 measurement 之间每一层 **路径的名字** 来记 tag value，tag key 可以通过自身的序号找到对应路径层级下的 tag value.
+
+#### 2.2.4 关键问题
+
+在 InfluxDB 的 SQL 语句中，tag 顺序的不同并不会影响实际的结果。
+
+例如：
+`insert factory, workshop=A1, production=B1, temperature=16.9` 和 `insert factory, production=B1, workshop=A1, temperature=16.9` 两条 SQL 的含义相等。
+
+但在 IoTDB 中，上述插入的数据点可以存储在 `root.monitor.factory.A1.B1.temperature` 下，也可以存储在 `root.monitor.factory.B1.A1.temperature` 下。因此，IoTDB 路径中储存的 InfluxDB
+ 的 tag 的顺序就是需要考虑的，因为 `root.monitor.factory.A1.B1.temperature` 和
+`root.monitor.factory.B1.A1.temperature` 是两条不同的序列。我们也可以认为，IoTDB 对 tag 的顺序是“敏感”的。
+
+因此，我们还需要在 IoTDB 中记录 InfluxDB 每个 tag 对应在 IoTDB 路径中的层级顺序，确保在执行 InfluxDB SQL 时，即使 tag 不同的同一条时序对应到IoTDB中也是同一条时序。
+
+这里还需要考虑的一个问题是：InfluxDB的tag key及对应顺序关系如何持久化到IoTDB数据库中里，这样才不会丢失相关信息。
+
+需要解决的事情：
+ 1. 怎样把InfluxDB中tag key映射到IoTDB中path中的节点顺序。
+ 2. 在不知道InfluxDB中可能会出现所有tag key的情况下，怎么维护它们之间的顺序。
+ 3. InfluxDB的tag key及对应顺序关系如何持久化到IoTDB数据库中。
Review comment:
```suggestion
```
##########
File path: docs/zh/UserGuide/API/InfluxDB-Protocol.md
##########
@@ -33,3 +33,217 @@ InfluxDB influxDB = InfluxDBFactory.connect(openurl, username, password);
InfluxDB influxDB = IoTDBInfluxDBFactory.connect(openurl, username, password);
```
+## 2.方案设计
+
+### 2.1 InfluxDB-Protocol适配器
+
+该适配器以 IoTDB Java Session 接口为底层基础，实现了 InfluxDB 的 Java 接口 `interface InfluxDB`，对用户提供了所有 InfluxDB 的接口方法，最终用户可以无感知地使用 InfluxDB 协议向 IoTDB 发起写入和读取请求。
+
+
+
+
+
+
+### 2.2 元数据格式转换
+
+InfluxDB 的元数据是 tag-field 模型，IoTDB 的元数据是树形模型。为了使适配器能够兼容 InfluxDB 协议，需要把 InfluxDB 的元数据模型转换成 IoTDB 的元数据模型。
+
+#### 2.2.1 InfluxDB 元数据
+
+1. database: 数据库名。
+2. measurement: 测量指标名。
+3. tags : 各种有索引的属性。
+4. fields : 各种记录值（没有索引的属性）。
+
+
+
+#### 2.2.2 IoTDB 元数据
+
+1. storage group： 存储组。
+2. path(time series ID)：存储路径。
+3. measurement： 物理量。
+
+
+
+#### 2.2.3 两者映射关系
+
+InfluxDB 元数据和 IoTDB 元数据有着如下的映射关系：
+1. InfluxDB 中的 database 和 measurement 组合起来作为 IoTDB 中的 storage group。
+2. InfluxDB 中的 field key 作为 IoTDB 中 measurement 路径，InfluxDB 中的 field value 即是该路径下记录的测点值。
+3. InfluxDB 中的 tag 在 IoTDB 中使用 storage group 和 measurement 之间的路径表达。InfluxDB 的 tag key 由 storage group 和 measurement 之间路径的顺序隐式表达，tag value 记录为对应顺序的路径的名称。
+
+InfluxDB 元数据向 IoTDB 元数据的转换关系可以由下面的公示表示：
+
+`root.{database}.{measurement}.{tag value 1}.{tag value 2}...{tag value N-1}.{tag value N}.{field key}`
+
+
+
+如上图所示，可以看出：
+
+我们在 IoTDB 中使用 storage group 和 measurement 之间的路径来表达 InfluxDB tag 的概念，也就是图中右侧绿色方框的部分。
+
+storage group 和 measurement 之间的每一层都代表一个 tag。如果 tag key 的数量为 N，那么 storage group 和 measurement 之间的路径的层数就是 N。我们对 storage group 和 measurement 之间的每一层进行顺序编号，每一个序号都和一个 tag key 一一对应。同时，我们使用 storage group 和 measurement 之间每一层 **路径的名字** 来记 tag value，tag key 可以通过自身的序号找到对应路径层级下的 tag value.
+
+#### 2.2.4 关键问题
+
+在 InfluxDB 的 SQL 语句中，tag 顺序的不同并不会影响实际的结果。
+
+例如：
+`insert factory, workshop=A1, production=B1, temperature=16.9` 和 `insert factory, production=B1, workshop=A1, temperature=16.9` 两条 SQL 的含义相等。
+
+但在 IoTDB 中，上述插入的数据点可以存储在 `root.monitor.factory.A1.B1.temperature` 下，也可以存储在 `root.monitor.factory.B1.A1.temperature` 下。因此，IoTDB 路径中储存的 InfluxDB
+ 的 tag 的顺序就是需要考虑的，因为 `root.monitor.factory.A1.B1.temperature` 和
+`root.monitor.factory.B1.A1.temperature` 是两条不同的序列。我们也可以认为，IoTDB 对 tag 的顺序是“敏感”的。
+
+因此，我们还需要在 IoTDB 中记录 InfluxDB 每个 tag 对应在 IoTDB 路径中的层级顺序，确保在执行 InfluxDB SQL 时，即使 tag 不同的同一条时序对应到IoTDB中也是同一条时序。
+
+这里还需要考虑的一个问题是：InfluxDB的tag key及对应顺序关系如何持久化到IoTDB数据库中里，这样才不会丢失相关信息。
+
+需要解决的事情：
+ 1. 怎样把InfluxDB中tag key映射到IoTDB中path中的节点顺序。
+ 2. 在不知道InfluxDB中可能会出现所有tag key的情况下，怎么维护它们之间的顺序。
+ 3. InfluxDB的tag key及对应顺序关系如何持久化到IoTDB数据库中。
+
+解决方案：
+1. 通过利用内存中的Map <Measurement, Map <Tag Key, Order> > Map结构，来维护Tag之间的顺序。
+
+ ```java
+ Map<String, Map<String, Integer>> measurementTagOrder
+ ```
+ 可以看出Map是一个两层的，第一层的Key是String类型的Measurement，第一层的Value是一个<String,Integer>的Map。
+
+ 第二层的Key是String类型的Tag Key，第二层的Value是Integer类型的Tag Order，也就是Tag对应的实际顺序。
+
+ 这样就可以先通过measurement定位，再通过tag key定位，最后就可以获得Tag对应的顺序了。
+
+3. 除了在内存中维护InfluxDB的Tag顺序外，还需要进行持久化操作，将InfluxDB的Tag顺序持久化到IoTDB数据库中里。
+ 存储组为`root.TAG_INFO`，分别以`database_name`,`measurement_name`,`tag_name`和`tag_order`来存储节点来记录数据。
Review comment:
```suggestion
**解决方案：**
通过利用内存中的`Map<Measurement, Map<Tag Key, Order>>` 这样一个 Map 结构，来维护 tag 在 IoTDB 路径层级上的顺序。
```java
Map<String, Map<String, Integer>> measurementTagOrder
```
可以看出 Map 是一个两层的结构。
第一层的 Key 是 String 类型的 InfluxDB measurement，第一层的 Value 是一个 <String, Integer> 结构的 Map。
第二层的 Key 是 String 类型的 InfluxDB tag key，第二层的 Value 是 Integer 类型的 tag order，也就是 tag 在 IoTDB 路径层级上的顺序。
使用时，就可以先通过 InfluxDB measurement 定位，再通过 InfluxDB tag key 定位，最后就可以获得 tag 在 IoTDB 路径层级上的顺序了。
除了在内存中维护 InfluxDB 的 tag 顺序外，还需要对该顺序信息进行持久化操作，即将 InfluxDB tag 在 IoTDB 路径层级上的顺序持久化到 IoTDB 数据库中。
存储方案如下：
存储组为`root.TAG_INFO`，分别用存储组下的 `database_name`, `measurement_name`, `tag_name` 和 `tag_order` 测点来存储节点来记录数据。
```
##########
File path: docs/zh/UserGuide/API/InfluxDB-Protocol.md
##########
@@ -33,3 +33,217 @@ InfluxDB influxDB = InfluxDBFactory.connect(openurl, username, password);
InfluxDB influxDB = IoTDBInfluxDBFactory.connect(openurl, username, password);
```
+## 2.方案设计
+
+### 2.1 InfluxDB-Protocol适配器
+
+该适配器以 IoTDB Java Session 接口为底层基础，实现了 InfluxDB 的 Java 接口 `interface InfluxDB`，对用户提供了所有 InfluxDB 的接口方法，最终用户可以无感知地使用 InfluxDB 协议向 IoTDB 发起写入和读取请求。
+
+
+
+
+
+
+### 2.2 元数据格式转换
+
+InfluxDB 的元数据是 tag-field 模型，IoTDB 的元数据是树形模型。为了使适配器能够兼容 InfluxDB 协议，需要把 InfluxDB 的元数据模型转换成 IoTDB 的元数据模型。
+
+#### 2.2.1 InfluxDB 元数据
+
+1. database: 数据库名。
+2. measurement: 测量指标名。
+3. tags : 各种有索引的属性。
+4. fields : 各种记录值（没有索引的属性）。
+
+
+
+#### 2.2.2 IoTDB 元数据
+
+1. storage group： 存储组。
+2. path(time series ID)：存储路径。
+3. measurement： 物理量。
+
+
+
+#### 2.2.3 两者映射关系
+
+InfluxDB 元数据和 IoTDB 元数据有着如下的映射关系：
+1. InfluxDB 中的 database 和 measurement 组合起来作为 IoTDB 中的 storage group。
+2. InfluxDB 中的 field key 作为 IoTDB 中 measurement 路径，InfluxDB 中的 field value 即是该路径下记录的测点值。
+3. InfluxDB 中的 tag 在 IoTDB 中使用 storage group 和 measurement 之间的路径表达。InfluxDB 的 tag key 由 storage group 和 measurement 之间路径的顺序隐式表达，tag value 记录为对应顺序的路径的名称。
+
+InfluxDB 元数据向 IoTDB 元数据的转换关系可以由下面的公示表示：
+
+`root.{database}.{measurement}.{tag value 1}.{tag value 2}...{tag value N-1}.{tag value N}.{field key}`
+
+
+
+如上图所示，可以看出：
+
+我们在 IoTDB 中使用 storage group 和 measurement 之间的路径来表达 InfluxDB tag 的概念，也就是图中右侧绿色方框的部分。
+
+storage group 和 measurement 之间的每一层都代表一个 tag。如果 tag key 的数量为 N，那么 storage group 和 measurement 之间的路径的层数就是 N。我们对 storage group 和 measurement 之间的每一层进行顺序编号，每一个序号都和一个 tag key 一一对应。同时，我们使用 storage group 和 measurement 之间每一层 **路径的名字** 来记 tag value，tag key 可以通过自身的序号找到对应路径层级下的 tag value.
+
+#### 2.2.4 关键问题
+
+在 InfluxDB 的 SQL 语句中，tag 顺序的不同并不会影响实际的结果。
+
+例如：
+`insert factory, workshop=A1, production=B1, temperature=16.9` 和 `insert factory, production=B1, workshop=A1, temperature=16.9` 两条 SQL 的含义相等。
+
+但在 IoTDB 中，上述插入的数据点可以存储在 `root.monitor.factory.A1.B1.temperature` 下，也可以存储在 `root.monitor.factory.B1.A1.temperature` 下。因此，IoTDB 路径中储存的 InfluxDB
+ 的 tag 的顺序就是需要考虑的，因为 `root.monitor.factory.A1.B1.temperature` 和
+`root.monitor.factory.B1.A1.temperature` 是两条不同的序列。我们也可以认为，IoTDB 对 tag 的顺序是“敏感”的。
+
+因此，我们还需要在 IoTDB 中记录 InfluxDB 每个 tag 对应在 IoTDB 路径中的层级顺序，确保在执行 InfluxDB SQL 时，即使 tag 不同的同一条时序对应到IoTDB中也是同一条时序。
+
+这里还需要考虑的一个问题是：InfluxDB的tag key及对应顺序关系如何持久化到IoTDB数据库中里，这样才不会丢失相关信息。
+
+需要解决的事情：
+ 1. 怎样把InfluxDB中tag key映射到IoTDB中path中的节点顺序。
+ 2. 在不知道InfluxDB中可能会出现所有tag key的情况下，怎么维护它们之间的顺序。
+ 3. InfluxDB的tag key及对应顺序关系如何持久化到IoTDB数据库中。
+
+解决方案：
+1. 通过利用内存中的Map <Measurement, Map <Tag Key, Order> > Map结构，来维护Tag之间的顺序。
+
+ ```java
+ Map<String, Map<String, Integer>> measurementTagOrder
+ ```
+ 可以看出Map是一个两层的，第一层的Key是String类型的Measurement，第一层的Value是一个<String,Integer>的Map。
+
+ 第二层的Key是String类型的Tag Key，第二层的Value是Integer类型的Tag Order，也就是Tag对应的实际顺序。
+
+ 这样就可以先通过measurement定位，再通过tag key定位，最后就可以获得Tag对应的顺序了。
+
+3. 除了在内存中维护InfluxDB的Tag顺序外，还需要进行持久化操作，将InfluxDB的Tag顺序持久化到IoTDB数据库中里。
+ 存储组为`root.TAG_INFO`，分别以`database_name`,`measurement_name`,`tag_name`和`tag_order`来存储节点来记录数据。
Review comment:
```suggestion
**解决方案：**
通过利用内存中的`Map<Measurement, Map<Tag Key, Order>>` 这样一个 Map 结构，来维护 tag 在 IoTDB 路径层级上的顺序。
```java
Map<String, Map<String, Integer>> measurementTagOrder
```
可以看出 Map 是一个两层的结构。
第一层的 Key 是 String 类型的 InfluxDB measurement，第一层的 Value 是一个 <String, Integer> 结构的 Map。
第二层的 Key 是 String 类型的 InfluxDB tag key，第二层的 Value 是 Integer 类型的 tag order，也就是 tag 在 IoTDB 路径层级上的顺序。
使用时，就可以先通过 InfluxDB measurement 定位，再通过 InfluxDB tag key 定位，最后就可以获得 tag 在 IoTDB 路径层级上的顺序了。
除了在内存中维护 InfluxDB 的 tag 顺序外，还需要对该顺序信息进行持久化操作，即将 InfluxDB tag 在 IoTDB 路径层级上的顺序持久化到 IoTDB 数据库中。
存储方案如下：
存储组为`root.TAG_INFO`，分别用存储组下的 `database_name`, `measurement_name`, `tag_name` 和 `tag_order` 测点来存储节点来记录数据。
```
##########
File path: docs/zh/UserGuide/API/InfluxDB-Protocol.md
##########
@@ -33,3 +33,217 @@ InfluxDB influxDB = InfluxDBFactory.connect(openurl, username, password);
InfluxDB influxDB = IoTDBInfluxDBFactory.connect(openurl, username, password);
```
+## 2.方案设计
+
+### 2.1 InfluxDB-Protocol适配器
+
+该适配器以 IoTDB Java Session 接口为底层基础，实现了 InfluxDB 的 Java 接口 `interface InfluxDB`，对用户提供了所有 InfluxDB 的接口方法，最终用户可以无感知地使用 InfluxDB 协议向 IoTDB 发起写入和读取请求。
+
+
+
+
+
+
+### 2.2 元数据格式转换
+
+InfluxDB 的元数据是 tag-field 模型，IoTDB 的元数据是树形模型。为了使适配器能够兼容 InfluxDB 协议，需要把 InfluxDB 的元数据模型转换成 IoTDB 的元数据模型。
+
+#### 2.2.1 InfluxDB 元数据
+
+1. database: 数据库名。
+2. measurement: 测量指标名。
+3. tags : 各种有索引的属性。
+4. fields : 各种记录值（没有索引的属性）。
+
+
+
+#### 2.2.2 IoTDB 元数据
+
+1. storage group： 存储组。
+2. path(time series ID)：存储路径。
+3. measurement： 物理量。
+
+
+
+#### 2.2.3 两者映射关系
+
+InfluxDB 元数据和 IoTDB 元数据有着如下的映射关系：
+1. InfluxDB 中的 database 和 measurement 组合起来作为 IoTDB 中的 storage group。
+2. InfluxDB 中的 field key 作为 IoTDB 中 measurement 路径，InfluxDB 中的 field value 即是该路径下记录的测点值。
+3. InfluxDB 中的 tag 在 IoTDB 中使用 storage group 和 measurement 之间的路径表达。InfluxDB 的 tag key 由 storage group 和 measurement 之间路径的顺序隐式表达，tag value 记录为对应顺序的路径的名称。
+
+InfluxDB 元数据向 IoTDB 元数据的转换关系可以由下面的公示表示：
+
+`root.{database}.{measurement}.{tag value 1}.{tag value 2}...{tag value N-1}.{tag value N}.{field key}`
+
+
+
+如上图所示，可以看出：
+
+我们在 IoTDB 中使用 storage group 和 measurement 之间的路径来表达 InfluxDB tag 的概念，也就是图中右侧绿色方框的部分。
+
+storage group 和 measurement 之间的每一层都代表一个 tag。如果 tag key 的数量为 N，那么 storage group 和 measurement 之间的路径的层数就是 N。我们对 storage group 和 measurement 之间的每一层进行顺序编号，每一个序号都和一个 tag key 一一对应。同时，我们使用 storage group 和 measurement 之间每一层 **路径的名字** 来记 tag value，tag key 可以通过自身的序号找到对应路径层级下的 tag value.
+
+#### 2.2.4 关键问题
+
+在 InfluxDB 的 SQL 语句中，tag 顺序的不同并不会影响实际的结果。
+
+例如：
+`insert factory, workshop=A1, production=B1, temperature=16.9` 和 `insert factory, production=B1, workshop=A1, temperature=16.9` 两条 SQL 的含义相等。
+
+但在 IoTDB 中，上述插入的数据点可以存储在 `root.monitor.factory.A1.B1.temperature` 下，也可以存储在 `root.monitor.factory.B1.A1.temperature` 下。因此，IoTDB 路径中储存的 InfluxDB
+ 的 tag 的顺序就是需要考虑的，因为 `root.monitor.factory.A1.B1.temperature` 和
+`root.monitor.factory.B1.A1.temperature` 是两条不同的序列。我们也可以认为，IoTDB 对 tag 的顺序是“敏感”的。
+
+因此，我们还需要在 IoTDB 中记录 InfluxDB 每个 tag 对应在 IoTDB 路径中的层级顺序，确保在执行 InfluxDB SQL 时，即使 tag 不同的同一条时序对应到IoTDB中也是同一条时序。
+
+这里还需要考虑的一个问题是：InfluxDB的tag key及对应顺序关系如何持久化到IoTDB数据库中里，这样才不会丢失相关信息。
+
+需要解决的事情：
+ 1. 怎样把InfluxDB中tag key映射到IoTDB中path中的节点顺序。
+ 2. 在不知道InfluxDB中可能会出现所有tag key的情况下，怎么维护它们之间的顺序。
+ 3. InfluxDB的tag key及对应顺序关系如何持久化到IoTDB数据库中。
+
+解决方案：
+1. 通过利用内存中的Map <Measurement, Map <Tag Key, Order> > Map结构，来维护Tag之间的顺序。
+
+ ```java
+ Map<String, Map<String, Integer>> measurementTagOrder
+ ```
+ 可以看出Map是一个两层的，第一层的Key是String类型的Measurement，第一层的Value是一个<String,Integer>的Map。
+
+ 第二层的Key是String类型的Tag Key，第二层的Value是Integer类型的Tag Order，也就是Tag对应的实际顺序。
+
+ 这样就可以先通过measurement定位，再通过tag key定位，最后就可以获得Tag对应的顺序了。
+
+3. 除了在内存中维护InfluxDB的Tag顺序外，还需要进行持久化操作，将InfluxDB的Tag顺序持久化到IoTDB数据库中里。
+ 存储组为`root.TAG_INFO`，分别以`database_name`,`measurement_name`,`tag_name`和`tag_order`来存储节点来记录数据。
Review comment:
```suggestion
**解决方案：**
通过利用内存中的`Map<Measurement, Map<Tag Key, Order>>` 这样一个 Map 结构，来维护 tag 在 IoTDB 路径层级上的顺序。
```java
Map<String, Map<String, Integer>> measurementTagOrder
```
可以看出 Map 是一个两层的结构。
第一层的 Key 是 String 类型的 InfluxDB measurement，第一层的 Value 是一个 <String, Integer> 结构的 Map。
第二层的 Key 是 String 类型的 InfluxDB tag key，第二层的 Value 是 Integer 类型的 tag order，也就是 tag 在 IoTDB 路径层级上的顺序。
使用时，就可以先通过 InfluxDB measurement 定位，再通过 InfluxDB tag key 定位，最后就可以获得 tag 在 IoTDB 路径层级上的顺序了。
除了在内存中维护 InfluxDB 的 tag 顺序外，还需要对该顺序信息进行持久化操作，即将 InfluxDB tag 在 IoTDB 路径层级上的顺序持久化到 IoTDB 数据库中。
**存储方案如下：**
存储组为`root.TAG_INFO`，分别用存储组下的 `database_name`, `measurement_name`, `tag_name` 和 `tag_order` 测点来存储节点来记录数据。
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscribe@iotdb.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org