[大数据]联机设备电量数据接入时序数据库可行性分析

概述

当前需要解决的问题

• 存储成本大：对于时序数据压缩不佳，需占用大量机器资源；

• 维护成本高：单机系统，需要在上层人工的分库分表，维护成本高；

• 写入吞吐低：单机写入吞吐低，很难满足时序数据千万级的写入压力；

• 查询性能差：适用于交易处理，海量数据的聚合分析性能差。

已有的业务场景瓶颈

• 按时间段读取电量数据

  查询数据库，目前无性能问题，未来设备量爆发式增长，采集数据频率提升时将会有性能问题

• 按小时统计设备的能耗增量

  查询数据库+查询缓存，速度用户无感知

• 按时间段修复能耗数据

  修复数据脚本，开发使用

• 相关的查询语句：

    查询某设备当前时间之前最近的一条记录
    查询某设备某个时间段内的所有记录
    查询某设备某个时间段内的最近一条记录
  

开源时序数据库介绍

开源时序数据库对比及排名

InfluxDB

• 概述

  InfluxDB是一个由InfluxData开发的开源时序型数据。它由Go写成，着力于高性能地查询与存储时序型数据。InfluxDB被广泛应用于存储系统的监控数据，IoT行业的实时数据等场景。

• 时序数据库能解决的问题

  • 存储成本：

  利用时间递增、维度重复、指标平滑变化的特性，合理选择编码压缩算法，提高数据压缩比；通过预降精度，对历史数据做聚合，节省存储空间。

  • 高并发写入：

  批量写入数据，降低网络开销；
  数据先写入内存，再周期性的dump为不可变的文件存储。

  • 低查询延时，高查询并发：

  优化常见的查询模式，通过索引等技术降低查询延时，通过缓存、routing等技术提高查询并发。

• influxDB的能力

  • 内置HTTP接口，使用方便
  • 数据可以打标记，查询较灵活
  • 自带特殊函数（求标准差，随机取样数据、统计数据变化比），数据统计和实时分析变得十分方便
  • 支持实时查询，数据在写入时被索引后就能够被立即查出

• influxDB的作用

  实时采集监控数据，按时间写入

  按不同纬度聚合查询监控数据，用于监控展现

  持续查询，定时归集指定时间的数据，用于更大时间范围监控数据的展现

    InfluxDB的连续查询是在数据库中自动定时启动的一组语句，语句中必须包含SELECT关键词和GROUP BY time()关键词。
    InfluxDB会将查询结果放在指定的数据表中。目的：使用连续查询是最优的降低采样率的方式，连续查询和存储策略搭配使用将会大大降低InfluxDB的系统占用量。而且使用连续查询后，数据会存放到指定的数据表中，这样就为以后统计不同精度的数据提供了方便。
  

• 重要概念

InfluxDB概念详解

• InfluxDB基本操作

  InfluxDB提供多种操作方式：

  1）客户端命令行方式

  2）HTTP API接口

  3）各语言API库

  4）基于WEB管理页面操作

• InfluxDB数据库操作

  新建数据库
  create database device_power

  显示数据库
  show databases

  删除数据库
  drop database device_power

  使用指定数据库
  use device_power

• InfluxDB数据表操作

  显示所有表
  show measurements

  新建表
  1、InfluxDB中没有显式的新建表的语句只能通过insert数据的方式来建立新表:
  insert device_message,device_mac=equipment1 consumption=100,current=1.2
  insert device_message,device_mac=equipment2 consumption=200
  其中 device_message 就是表名，device_mac是索引（tag），consumption=xx是记录值（field），记录值可以有多个，系统自带追加时间戳
  2、添加数据时，自己写入时间戳:
  insert device_message,device_mac=equipment2 consumption=200 1435362189575692182

  查询表字段
  查询tag：show tag keys from device_message!
  查询field：show field keys from device_message

  删除表
  drop measurement device_message

• 数据保存策略（Retention Policies）

  influxDB是没有提供直接删除数据记录的方法，但是提供数据保存策略，主要用于指定数据保留时间，超过指定时间，就删除这部分数据（数据库过期策略至少一个小时）

  查看当前数据库Retention Policies

    show retention policies on "db_name"
    show retention policies on device_power
  

  创建新的Retention Policies

    create retention policy "rp_name" on "db_name" duration 3w replication 1 default
    create retention policy test on device_power duration 1h replication 1 default
  
    rp_name：策略名；
    db_name：具体的数据库名；
    3w：保存3周，3周之前的数据将被删除，influxdb具有各种事件参数，比如：h（小时），d（天），w（星期）；
    replication 1：副本个数，一般为1就可以了；
    default：设置为默认策略
  

  修改Retention Policies

    alter retention policy “rp_name” on “db_name” duration 30d default
    alter retention policy test on device_power duration 2h default
  

  删除Retention Policies

    drop retention policy “rp_name” on “db_name"
    drop retention policy test on device_power
  

• 查询数据

  select * from device_message
  

• 插入数据

  插入数据同时创建表
  insert device_message,device_mac=equipment1 consumption=100,current=1.2

性能对比

读写速度对比测试

测试环境：内存：16GB，4核2.70GHz i5-6400处理器，单机模式，不涉及网卡，网络传输的影响

mysql写数据速度：769条/s

influxdb写数据速度：4.4w条/s

参考案例：InfluxDB和MySQL的读写对比测试

支持数据量

• 读写数据

在influxDate官方给出的被查表和查询语句下，如果数据量级不是非常大的时候，单节点的 InfluxDB 可以承载十万左右每秒的写入，600每秒的查询。

注意：目前iot服务的联机设备数据处理速度在1000台以内，后期需要优化处理逻辑，以保证数据实时处理；

参考案例：InfluxDB性能测试报告

• 存储数据

业务场景：5000个设备，每30秒存一次，存3个月，大约13亿条记录。

如果保存策略RP的保留是90天，那么分片shard的时长在一天就比较合理，那么一天的量就是：5,000×120×24=14,400,000，大概每天近1400万条数据。这个量对于influxdb单机来说是够用了。

使用RPs和CQs的组合，能够保存高精度的裸数据较短的时间，而保存高精度的数据更长时间。

参考文档：InfluxDB中文文档–采样和数据保留

未来应用的场景

• 能源行业设备智能运维

  物联网平台可被应用于对海量设备终端的统一管理与运维，对设备的状态进行在线监测与诊断，对设备能耗等信息进行聚合分析展示，并及时进行预警。还可以通过多维图表展示运维数据等。

• 园区智能巡检和安防

  在各种园区日常巡检、隐患上报、三维地图以及融合调度上有很多应用场景。设备管理运行状态、HSE风险等级、工艺流程、过程控制运行参数等检修情况各类业务现场及管理实时数据及信息的直观展示，及时发现问题，分析原因，提出整改建议，并贯彻执行。

MySQL数据模型和influxDB数据模型分析

• MySQL:

• influxDB:

使用influxDB数据库步骤

• 1、增量数据迁移

  双写 同时把数据写入到老数据源（MySQL）和新数据源（influxDB）（通过一个开关控制新老数据库使用）

• 2、双读

  读取数据时进行数据对比，判断写入数据是否一致并记录异常数据

• 3、切读

  观察一两周左右,确定没问题后，就可以开始切读了，把读开关切换到new，再观察几天

• 4、切写

  把写开关切换到new，继续观察几天

• 5、清理旧代码、老数据源数据

其他

切换数据库还有一些准备工作，后续更新