众多数据库方案被弃用, IoT 物联网如何应对海量设备数据的存储和分析？
截至目前，涛思数据推出的TDengine物联网大数据平台已经发布了多个来自智慧城市各个领域的用户案例，覆盖了智慧水务、智慧矿山、智慧排水等领域。这些案例，都在数据库选用上，进行过充分的调研，并在生产环境中实测，是用户花时间整理出来的，内容详实，干货多多。本篇推文将这些案例进行了精选和整理，值得收藏。
前端
智慧水务大数据的监测数据库
水环境综合治理运维系统中须要对截流井设备中的液位、电流、硫化氢等进行监测，并经过PLC程序进行自动化管理设备的启停与报警短信推送。传感器采集的信息经过MQTT协议传到网关，网关收集到信息后会定时推送到业务后台服务，由服务层来作数据存储和实时分析。设备运行业务数据放在MySQL里面，液位、电流频率、硫化氢、雨量物联网数据放在TDengine中。
服务器
在数据库选型中，起初用户考虑了OpenTSDB+HBase。这个方案用的人比较多，但有缺陷。其中HBase对集群要求较高，须要很好的调优；OpenTSDB默认的compaction策略每到整点写入HBase时，至关耗费CPU，综合考虑人员及服务器等成本放弃了该方案。运维
以后采用TDengine，用户认为TDengine在提供高性能的同时大大下降了安装、部署、维护的成本，是当前水环境综合运维系统底层采用的变量数据存储引擎。函数
实现雨量监测预警，TDengine在智慧水务大数据中的应用性能
智慧矿山系统底层测点数据的存储学习
华夏天信RED-MOS露天煤矿智慧矿山操做系统的地面生产集控系统采用的PLC设备将采集的信号统一接入智能预警平台，整合1、二期集控系统、机房状态监测系统、电气综保装置、破碎系统等数据接入RED-MOS露天煤矿智慧矿山操做系统。系统中接入的监控点数量将近1万5千点。其中接近2300点须要绑定组态显示，即时页面更新，总体数据采集到显示到前端要求秒级展现。
大数据
用户同时要求大数据量展现（历史数据回溯），可展现30天的全量数据，点数量超过50万条。读取时间要求在5~10s。这对底层的数据库提出了一个至关大的挑战。
spa
在数据库选型中，经过一些对比分析，最终决定考量MongoDB和TDengine。操作系统
MongoDB须要至少6台服务器，方案缺陷明显：比较耗费服务器资源，占用空间过大，历史数据备份和恢复很是痛苦；写入波动明显，在生产环境上线前模拟压测中发现没法达到项目要求；单机稳定性较差，大比例出现没法访问 的状况。
后采用TDengine，用户认为TDengine自己很是轻量，在解决对时序数据的高性能读写需求同时，大大下降了安装、部署、维护的成本，是当前RED-MOS系统底层采用的测点数据存储引擎。TDengine解决了最为头疼的历史数据回溯性能问题。
智慧城市大数据管理系统的接入实践
在某新区智慧城市大数据管理系统中，使用TDengine的数据存储各种终端设备的采集数据，好比智能灯杆上照明状况、用电状况，供水压力流量数据、燃气压力、可燃气体泄露、污水排污成分数据、环境监测设备上的PM2.五、 PM10等信息，停车场通行数据等结构化时序数据等。预计将来，系统上会有十万个监测设备，每日数据增量会在80GB左右。
此前的实现方案都是借助于如HBase生态中的各类组件进行数据的存储和查询。在流处理过程当中，更多采用Spark Streaming，或者Storm来进行实时处理查询等。但基于传统解决方案，不是实现窗口查询的方式难以落地，就是数据查询效率不能接受。在HBase中是经过各类汇聚来实现查询，效率难以保证；Spark Streaming的查询处理虽然能够经过SQL来实现，可是对于窗口函数的定义和读取晦涩冗长。
TDengine相对于前者使用的各类重型组件来讲，在部署维护、入门、数据迁移、学习使用上都有先天性的优点，所以在部署物联网数据存储平台过程当中，结合实际业务中的数据查询须要，用户选择了TDengine。
智慧排水系统中的数据采集和存储
智慧排水系统中须要对排水设备中的液位进行监测。一般会在被监测区域部署电流液位传感器，采集电流液位频率。传感器采集的信息经过MQTT协议传到网关，网关收集到信息后会定时推送到业务后台服务，由服务层来作数据存储和实时分析。设备运行数据放在SQLServer里面，液位电流频率等特别多的数据放在TDengine中。
在用户目前的应用场景中，海量的数据来自拦蓄盾检测设备上报的数据。在这些监测数据的处理流程上，数据从网关推送过来后会有一个判断是否实时数据。对于非实时数据，则会流经Redis去重，作报警判断而后写入SQLServer。对于实时数据则直接写入TDengine，不须要再通过Redis。以后前端须要的一些相似液位电流数据等就能够直接从TDengine访问。
在这以前，全部数据都是使用SQLServer存储，发现数据量达到2000万后SQLServer的查询时延已经很是慢，不得不作分库分表操做来提升查询速度，但这个解决方法遇到跨库跨表的查询很是不便。
总体来说，TDengine对于处理高频采集的结构化时序数据吞吐量、资源开销和压缩都很是优秀。
