Alima777 commented on a change in pull request #829: [IoTDB-508] Add AlignByDeviceQuery documents URL: https://github.com/apache/incubator-iotdb/pull/829#discussion_r383678554
########## File path: docs/Documentation-CHN/SystemDesign/5-DataQuery/6-AlignByDeviceQuery.md ########## @@ -0,0 +1,199 @@ +<!-- + + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + +--> + +# 按设备对齐查询 + +AlignByDevicePlan 即按设备对齐查询对应的表结构为： + +| Time | Device | sensor1 | sensor2 | sensor3 | ... | +| ---- | ------ | ------- | ------- | ------- | --- | +| | | | | | | + +## 设计原理 + +按设备对齐查询其实现原理主要是计算出查询中每个设备对应的映射值和过滤条件，然后将查询按设备分别进行，最后将结果集拼装并返回。 + +### AlignByDevicePlan 中重要字段含义 + +首先解释一下 AlignByDevicePlan 中一些重要字段的含义： + +- dataTypeMapping: 该变量继承自基类 QueryPlan，其主要作用是在计算每个设备的执行路径时，提供此次查询的 paths 对应的数据类型。在按设备对齐查询中，基类中的 paths 字段除了有验证的额外作用外，和 dataTypes 字段主要都是为这个字段服务。 +- deviceToMeasurementsMap, deviceToFilterMap: 这两个字段分别用来存储设备对应的映射值和过滤条件。 +- dataTypeConsistencyChecker：该字段主要用来验证不同设备的同名 sensor 的数据类型是否一致。如 `root.sg.d1.s1` 和 `root.sg.d2.s1` 应该是同一数据类型。 +- groupByPlan, fillQueryPlan, aggregationPlan：为了避免冗余，这三个执行计划被设定为 RawDataQueryPlan 的子类，而在 AlignByDevicePlan 中被设置为变量。如果查询计划属于这三个计划中的一种，则该字段会被赋值并保存。 + +在进行具体实现过程的讲解前，先给出一个覆盖较为完整的例子，下面的解释过程中将结合该示例进行说明。 + +```sql +SELECT s1, "1", *, s2, s5 FROM root.sg.d1, root.sg.* WHERE time = 1 AND s1 < 25 ALIGN BY DEVICE +``` + +其中，存储组 `root.sg` 共包含两个设备 d1 和 d2，其中 d1 有两个传感器 s1 和 s2，d2 只有传感器 s1，相同传感器 s1 的数据类型相同。 + +下面将按具体过程进行分别解释： + +### 逻辑计划生成 + +- org.apache.iotdb.db.qp.Planner + +与原始数据查询不同，按设备对齐查询并不在此阶段进行 SELECT 语句和 WHERE 语句中后缀路径的拼接，而将在后续生成物理计划时，计算出每个设备对应的映射值和过滤条件。因此，按设备对齐在此阶段所做的工作只包括对 WHERE 语句中过滤条件的优化。 + +对过滤条件的优化主要包括三部分：去非、转化析取范式、合并同路径过滤条件。对应的优化器分别为：RemoveNotOptimizer, DnfFilterOptimizer, MergeSingleFilterOptimizer。该部分逻辑可参考：[Planner](/#/SystemDesign/progress/chap2/sec2). + +### 物理计划生成 + +- org.apache.iotdb.db.qp.strategy.PhysicalGenerator + +生成逻辑计划后，将调用 PhysicalGenerator 类中的 `transformToPhysicalPlan()` 方法将该逻辑计划转化为物理计划。对于按设备对齐查询，该方法的主要逻辑实现在 `transformQuery()` 方法中。 + +首先解释一下 `transformQuery()` 方法中一些重要字段的含义： + +- prefixPaths, suffixPaths：前者为 FROM 子句中的前缀路径，示例中为 `root.sg.d1`, `root.sg.*`; 后者为 SELECT 子句中的后缀路径，示例中为 `s1`, `"1"`, `*`, `s2`, `s5`。 +- devices：对 prefixPaths 进行去星和设备去重后得到的设备列表，示例中为 `[root.sg.d1, root.sg.d2]`。 +- measurementSetOfGivenSuffix：记录该 suffix 对应的 measurements，示例中，对于后缀 \*, `measurementSetOfGivenSuffix = {s1,s2}`，对于后缀 s1, `measurementSetOfGivenSuffix = {s1}`; + +Measurement 共有三种类型，常量 Measurement，不存在的 Measurement 以及存在且非常量的 Measurement，下面将结合具体字段进行解释。 + +- `loc`：标记当前 Measurement 在 SELECT 后缀路径中的位置，如示例中常量`1`的位置为 1，而 `s5` 的位置为 5. Review comment: 是5没错，因为有个*，*在这个例子里占两位，所以loc标记的是measurement的位置而不是suffix的位置 ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
