湖北seo整站优化,做网站的需要哪些职位,网站开发范例文档,规范网站建设1 物联网应用场景简介
物联网#xff08;Internet of Things#xff0c;简称 IoT#xff09;是指通过各种信息传感、通信和 IT 技术来实时连接、采集、监管海量的传感设备#xff0c;从而实现对现实世界的精确感知和快速响应#xff0c;继而实现自动化、智能化管理。在查…1 物联网应用场景简介
物联网Internet of Things简称 IoT是指通过各种信息传感、通信和 IT 技术来实时连接、采集、监管海量的传感设备从而实现对现实世界的精确感知和快速响应继而实现自动化、智能化管理。在查询 IoT 设备状态的场景下吞吐量和时延是两个重要的性能指标。
在工业物联网中常见有以下几种设备时序数据的查询需求
案例1查询某个设备最近的记录案例2查询某个租户所有设备的最近一条记录案例3查询某个设备最近5分钟的统计信息案例4查询某个设备最近一天的秒级数据
本教程通过一个工业物联网的案例来演示 DolphinDB 的序列查询性能并对比测试了 DolphinDB TSDB 引擎、OLAP 引擎以及 ClickHouse MergeTree 引擎在上述查询案例上的时延指标。总体来说DolphinDB TSDB 引擎的性能时延对比 DolphinDB OLAP 引擎和 ClickHouse MergeTree 引擎有显著优势。
2 案例数据准备
2.1 数据集说明
本教程参考了某工业物联网 SaaS 平台服务商的数据集模拟并使用一份高度仿真的数据。该SaaS服务商的主要业务是监控各个地区的噪声情况。表结构如下
序号字段名称字段类型注释1tenantIdINT租户ID2deviceIdINT设备ID3soundPressureLevelDOUBLE声音分贝4soundPowerLevelDOUBLE声音功率值5tsTIMESTAMP数据采集时间戳6dateDATE日期
一行数据包含租户 ID、设备 ID、声压、噪声功率、采集时间戳和日期共计 6 列数据。每行记录占用 36 字节。该案例数据包含100 个租户每个租户管理 100 个噪声监控设备记录了从 2022-01-01 至 2022-01-1212亿的噪声数据共计 40G。
2.2 库表设计及数据模拟
使用 DolphinDB TSDB 引擎创建一个名为 NoiseDB 的数据库存储噪声数据。TSDB 引擎是 DolphinDB 自 2.00 版本起专门为物联网场景设计研发的数据存储引擎具备优秀的写入和序列查询性能。
在噪声监控的 SaaS 服务中较为频繁的查询场景是以租户为维度查询某一天某个设备的状态信息。因此设计 noise 表按日期、租户 ID 进行分区可以有效利用分区剪枝。同时使用区分度较高的设备 ID 和数据采集时间戳作为排序键查询索引使查询时能够快速定位对应设备的数据提升查询性能。具体实现脚本如下。
db1 database(,VALUE,1000..2000)
db2 database(, VALUE, 2022.01.01..2022.12.30) // TSDB for iot
dbNoise database(dfs://NoiseDB,COMPO,[db1,db2], engineTSDB) create table dfs://NoiseDB.noise(tenantId INT,deviceId INT,soundPressureLevel INT,soundPowerLevel DOUBLE,ts TIMESTAMP,date DATE
)
partitioned by tenantId, date
sortColumns[deviceId,ts]
库表创建完成后模拟 2022-01-01 至 2022-01-12 的数据具体代码详见附录 DolphinDB 脚本。
可以通过 SQL 查询验证下数据集大小
select count(*) from loadTable(database(dfs://NoiseDB),noise) where date between 2022.01.01:2022.01.102 1260010000
导入完成后每个分区下生成3个level 0 file未满足自动合并条件大于等于10个 levelFile需要进行手动合并。
chunkIds exec chunkId from getChunksMeta() where type1
for (x in chunkIds) {triggerTSDBCompaction(x)
}
完成后将案例数据导出数据至 csv 文件以便后续导入 OLAP 引擎、ClickHouse。在 ClickHouse 中使用OPTIMIZE TABLE noise 合并下 mergeTree。具体过程参照附录 ClickHouse 脚本。
3 SQL 查询
在 DolphinDB 中可以使用 SQL 快速实现4个设备状态查询需求并且代码十分简洁。
案例1查询某个设备最近的100条记录:
noise loadTable(database(dfs://NoiseDB),noise)
select * from noise
where date2022.01.01 and tenantId1055 and deviceId10067
order by ts desc
limit 100# timer(10) select ...
Time elapsed: 24.33 ms
脚本的 where 条件语句中指定了分区列 date 和 tenantId 进行过滤便于 DolphinDB 系统通过分区剪枝快读定位到对应的分区。同时指定了数据库的 sort key (deviceId) 作为过滤字段利用 TSDB 的索引机制可以快速定位到数据块并按时间顺序取回最新的100条记录。平均一次查询耗时 2ms未命中缓存的首次查询耗时 14ms。
案例2查询某个租户所有设备最新状态
noise loadTable(database(dfs://NoiseDB),noise)
select * from noise
where date2022.01.01 and tenantId1055
context by deviceId
csort ts desc
limit 1# timer(10) select ...
Time elapsed: 246.619 ms
该脚本在 where 条件语句中同样指定了分区列以快速定位到对应的数据分区。通过 context by 子句来根据设备 ID 将数据进行分组每组数据通过 csort 子句按时间倒序排列考虑到物联网存在消息乱序的情况必须使用csort将数据按采集时间排序。使用 limit 1 获取每个窗口内的最新的一条记录从而获取该租户当日所有设备的最新状态。平均一次查询耗时 25ms首次查询耗时 121ms。
案例3查询某个设备5分钟内的噪声统计值
noise loadTable(database(dfs://NoiseDB),noise)
selectmin(ts) as startTs,max(ts) as endTs,max(soundPressureLevel),avg(soundPressureLevel),max(soundPowerLevel) ,avg(soundPowerLevel)
from noise
where date2022.01.01 and tenantId1055 and deviceId10067 and ts between 2022.01.01T00:50:15.518:2022.01.01T00:55:15.518
group by tenantId, deviceId# timer(10) select ...
Time elapsed: 22.168 ms
该脚本首先根据 where 指定的过滤条件定位并扫描数据块取出对应时间段的数据并按 tenantId, deviceId 进行聚合计算以获取声音分贝、功率的统计值。平均一次查询耗时 2ms首次查询耗时 13ms。
案例4查询某个设备最近一天的明细数据
noise loadTable(database(dfs://NoiseDB),noise)
select *
from noise
where date2022.01.01 and tenantId1055 and deviceId10067
order by ts# timer(10) select ...
Time elapsed: 23.261 ms
该脚本首先根据 where 指定的过滤条件定位并扫描数据块取出对应时间段的明细数据并按采集时间排序。平均一次查询耗时 2ms首次查询耗时 16ms。
注首次查询指未命中数据库缓存及操作系统缓存的查询。
4 对比测试
进一步测试 DolphinDB TSDB 引擎与 OLAP 引擎以及 ClickHouse MergeTree 引擎在上述数据集的时序查询性能。测试过程中尽可能地保持环境变量相同以保证科学有效。具体测试脚本详见附录。
4.1 测试环境
测试机器配置
操作系统CentOS 7
CPU: 2 cores
内存10 G
磁盘SSD
核心测试参数
对测试中影响性能的关键参数保持对等一致。
软件信息核心参数库表设计DolphinDB2.00.6 单节点memSize8G TSDB引擎 / OLAP引擎partitioned by tenantId, datesortColumns [deviceId,ts]ClickHouse22.6.1 单节点max_server_memory_usage8GMergeTree引擎partition by tenantId, dateorder by deviceId, ts
测试时DolphinDB 和 ClickHouse 均采用单节点并分配 8G 最大内存。在引擎方面DolphinDB TSDB 引擎ClickHouse MergeTree 引擎的内部实现都采用了 LSM-tree。并保持库表设计完全一致。
时间衡量标准
由于端到端的时间容易受到网络抖动和客户端实现性能的影响因此本次测试的测量时间设定为从查询引擎接收到请求至计算出结果为止。 4.2 测试结果
三者的具体测试结果为下表表中数值为平均耗时/首次查询耗时单位 ms平均耗时的计算逻辑为
平均耗时 首次耗时 9次缓存命中耗时 / 10
测试用例场景DolphinDB TSDBDolphinDB OLAPClickHousecase1查询某个设备最新100 条记录2 / 1434 / 5114 / 150case2查询某个租户所有设备的最新状态25 /12162 / 17073 / 400case3查询某个设备 5min的噪声统计值2 / 1315 / 13612 / 82case4查询某个设备最近一天的明细数据2 / 1624 / 22022 / 200
可以看出OLAP 引擎和 ClickHouse 在不同的查询场景下性能各有其优势和劣势。
而 TSDB 引擎性能均优于 ClickHouse在相对复杂的点查场景性能差距更大。在场景4下 DolphinDB TSDB 引擎比 ClickHouse 的性能高 12.5 倍首次查询高13倍。在该场景中TSDB 引擎需要读取对应设备的10000条记录压缩后的存储大小约为90K。存储在6个连续的Block中读取效率非常高效。而 ClickHouse 则是 scan 了该分区下1000000条记录的数据块因此两者的首次查询性能差距较大而缓存后的性能差距主要取决于两者在计算性能上的差别 。
5 总结
DolphinDB TSDB 引擎在物联网场景有着卓越的点查性能可以以毫秒级延时迅速响应设备的状态信息其性能更优于 ClickHouse 的 MergeTree 引擎。
6 附录
DolphinDB 脚本ClickHouse 脚本
