基于TableStore的物联网元数据管理

阿里云云栖号

于 2018-10-10 16:43:33 发布

阅读量1.1k

点赞数 1

文章标签：数据管理阿里技术协会架构

本文链接：https://blog.csdn.net/yunqiinsight/article/details/82996872

版权

背景

常见的企业级无线接入方案有两种，分别被称作廋AP和胖AP。瘦AP（AC+AP）架构为比较传统的企业级无线接入方案，主要优点就是漫游体验好，但是AC宕机的话会导致所属的AP全部无法工作。对于大型的办公场所，漫游的需求相对较弱，新型的胖AP（无AC，不会因为AC宕机导致网络不可用）+ 云端控制器架构成为了新兴的一种企业无线接入方案，运维人员通过云端对AP进行监控与管理。

某公司拥有无线AP约10,000台、接入终端（STA）100,000个。设备以一定的周期上报其状态到云端，云端将监控数据持久化后供用户查看。

业务描述

每个AP设备会以10s的周期上报其当前状态，上报数据格式为json，其格式如下：
AP状态：

{
    "ap_mac": "11:22:33:86:D9:E8",  // AP WAN口MAC地址，AP设备唯一标识
    "report_time": 1532315501985,   // 上报时间戳，毫秒
    "on_time": 1531417181972,       // 设备上线时间戳，毫秒
    "sta_cnt": 2,                       // 终端数量
    "cpu_usage": 12,                // CPU使用率
    "memory_usage": 38,             // CPU使用率
    "wan_recv_speed": 280,          // WAN口下行速率 单位bps
    "wan_sent_speed": 45348,        // WAN口上行速率 单位bps
}

需求以及架构选型

需求

通过MAC地址查看每个AP最新的状态。
用户需要在管理系统上对基于各种条件对设备进行查询。
需要对AP的各种指标进行排序，以便找出故障设备。
我们将上述的需求分为两种：
多维查询。
排序。
基于这两大类需求，我们给出如下的架构选型比较。

架构选型

针对这种IOT场景的设备状态监控数据，下面针对几种常见方案做比较。

MySQL

将设备上报的状态数据直接写入MySQL，并使用MySQL自带的查询、排序语句对数据进行分析，这种架构最为简单，用户运维成本较低。

这种架构仅仅适用于小规模量的数据，在大规模数据的情况下，MySQL的内部架构也导致了无法创建出一种万用的索引来满足多维查询的需求。并且MySQL底层使用的是B+数作为存储结构，会有随机写的问题，写入性能较差。
MySQL在使用前必须指定表结构，也就是说后续新增需求的话，必须要修改表结构，在数据量较大的情况下修改表结构很容易造成锁表导致线上故障。