一、场景特性

每个业务场景都有自己特有数据特性，IoT也不例外。单纯从设备检索的角度切入来看，IoT的设备检索特性如下：

?????1.?亿级数据；

?????2.?数据高频变更；

? ? ?3.?时序特性；

?????4.?无冷热特征；

? ? ?5.?结构松散；

? ? ?6.?数据异构；

二、数据Dump层

整体思路和多数检索场景类似：全量数据+增量数据。由于底层用了多套云检索引擎，因此整个Dump层天然具备云原生的能力，与此同时，我们采用了影子库、主备集群、读写分离、配置化、全链路监控等手段，来保障数据的吞吐、时延、稳定、高效。

三、物模型检索

物模型是物理空间中的实体（如传感器、车载装置、楼宇、工厂等）在云端的数字化表示，从属性、服务和事件三个维度，分别描述了该实体是什么、能做什么、可以对外提供哪些信息。因此相对于设备的元数据（名称等），物模型数据的检索是极其重要的一部分。然而，虽然单个设备的物模型属性数量是有限的，但是不同的设备的物模型属性数是完全不一样的，这就导致最终最终设备的物模型的属性是不可穷尽的，但是我们的索引表的宽度是有限的。因此，就需要用有限的索引列存储无限的物模型数据。

通过结合物模型的特点：数据定义明确、整体数量不可穷尽、单设备可穷尽，将单设备的物模型信息与索引进行映射，多设备复用相同索引，实现物模型数据的检索。

四、SQL-Like检索能力

云上的产品ToB的比重更高，使用我们云平台的大多数用户都有一定技术背景，SQL在技术人员普及度又极高，为了降低用户的使用成本，我们提供了SQL-Like的检索能力，用户能够像查询数据库一样来检索数据。与此同时，我们底层用了多套检索引擎，因此我们希望在上层使用SQL检索的方式来屏蔽底层引擎的差异。简而言之，上层使用SQL语法，下层适配多套检索引擎。

为此，我们设计了一套：适配多引擎、业务自定义、SQL检索框架。整体架构上，参考了Apache Calcite。

SQL-Helper：我们提供了SQL拼装工具，用户可以像写JAVA那样完成SQL书写，防止SQL拼写错误带来的调试效率问题；

Adapter：适配层模块，基于底层引擎进行适配、路由；

Parser：SQL解析模块；

Completer：语句补全、替换等；

Validater：语句校验模块；

Tanslator：语句转义为底层引擎请求，并进行参数优化；