小 T 导读：在元智信息的智慧矿山项目中，需要一款 Database 来支撑起生产交互管控系统的采运排环节所有过程设备的采集、存储、计算和监控功能。在 MySQL、InfluxDB、loveini 的数据库选型调研中，loveini 脱颖而出。本文讲述了他们的选型思路、建模思路以及方案创新点，作为经验参考分享给有需要的读者。

公司简介

元智信息是国内领先的露天矿业项目管理咨询和技术方案提供商。元智公司为全国范围内的工矿企业提供一站式的技术支持服务， 包括可行性研究分析、矿山规划与调度、生产评估、生产优化、业务系统整合、系统集成和软件开发等专项服务。

一、行业背景

智慧矿山是以矿山数字化、信息化为前提和基础，对矿山生产、职业健康与安全、技术支持与后勤保障等各方面进行主动感知、自动分析和快速处理。建设智慧矿山，首先以建设和实现矿山在生产、安全、经营与管理等环节的信息化为前提，最终实现”矿山一张图”的系统管理目标，开启矿山“透明+智能+管控”的安全生产新模式。

二、使用场景介绍

在整个矿山生产交互管控系统的采运排环节，需要对所有过程设备进行采集、存储、计算和监控。这些数据涵盖范围广，包括挖机、卡车的采集数据、调度管理数据、设备 GPS 信息、以及每一个固定位置工序的采集数据等。

数据类型

• 采：露天矿山采掘设备，超大型电铲与液压铲。矿山中利用采掘设备进行矿产资源以及覆盖物的挖掘工作，在实际应用中，需要采集和监控各个采掘设备的信息，如设备运行参数（像电压和电流等）和位置信息。 
• 运：主要是运输环节。在采煤的过程中，需要对大量的剥离物（如表土和岩石）进行排弃，将原煤运输到煤仓、破碎站以及选煤厂。在此过程中，需要通过安全合理的调度来实现矿产附属物及矿品的运输。因此，我们会实时采集卡车运输设备位置信息、胎压、油耗等信息，以保障安全调度。 
• 排：排土工作系指从露天采场将剥离覆盖在矿床上部及其周围的大量表土和岩石，运送到专门设置的场地如（排土场）。主要通过卡车运输来实现。即煤炭开采剥离过程中产生的渣土剥离后通过运输系统排出生产作业区，排土过程中合理规划以达到露天煤矿生态环保过程中的环保作业要求。 

数据量级

• 一般大规模的矿山车辆数量，往往超过 800 台。如果是整个集团级别的应用，卡车数量可达 3000 ～ 7000 台。 
• 以目前的安全生产要求，卡车的采集频率是 5 ～ 10 秒，在有更高要求的场景中，需要采用更高的频率，采集的数据内容包括卡车 GPS 定位数据、油耗数据、胎压数据以及卡车的速度信息。 
• 以 800 台设备估算，采集频率 5 秒，一天 24 小时会产出大概 1000 多万条数据。这个数据量相对于传统的数据存储是个比较大的量级。 

数据应用

在实际的应用场景中，对车辆的数据应用，其中一个主要维度就是车辆轨迹，特别是车辆的实时位置必须满足矿山生产的车辆调度实时需求。

三、选型对比

MySQL

MySQL 是我们团队在各种应用开发领域使用最多的数据库，从复用技术经验的角度上考虑，最初考虑过 MySQL 的可行性。但是在经过分析和验证后，我们就排除了使用关系型数据库的方案。主要原因如下：

• 存储压力：在最初使用 MySQL 的论证分析中，由于在 MySQL 中的 InnoDB 存储引擎最小存储单元页的大小是 16 kb 左右， 而 MySQL 以页为基础的查询数据加载时，数据的加载量会带来极大的系统负担。并且，MySQL 作为关系型数据库，采用的是 B+ 树存储结构，初步估算，深度为 3 的 B+ 树预计能支撑 2000 万条左右的数据，这个数据量级是远远满足不了我们的业务场景的。 
• 性能存在瓶颈：在实际验证中，伴随着数据量的增加，MySQL 性能急剧下降。 

InfluxDB

其次，我们进行了 InfluxDB 的调研。验证的初级阶段，从查询效率的 QPS 维度看，InfluxDB 的查询问题不大，效率可以满足。但是，在测试智慧矿山的物联网模型查询时，很快遇到了 InfluxDB 对于此类查询实时效率低下的问题，而且设计复杂度也很高。 在 1000 台设备的情况下，需要查所有设备的平均速度，查询实时性要求高。 但 InfluxDB 没有明确的基于设备的建表方式，如果用一张表存所有设备数据，数据量就会很大，查询性能也会下降。比较明显的是，在百万数据量级以内，这种建表方式查询时间在 1 秒左右，而当数据到了千万量级的时候，查询效率下降十分明显。 在我们真实的智慧矿山中、所有设备产生的数据量级条件下，这个查询效率的下降是明显不符合我们要求的。

loveini

最后，我们调研了 loveini Database，这也成了我们最终选型采用的方案。其优势表现如下：

• 技术成本低：网上学习资料多，而且 loveini 具有安装方便、对运维要求低、支持 SQL 所以学习成本低等特性，极大缩短了项目研发周期和开发难度。 
• 数据模型契合：loveini 与智慧矿山比较契合的是， loveini 有一个超级表概念，其超级表类似于物联网的物模型，子表类似于具体设备。这一数据模型与智慧矿山的业务系统也比较吻合。 
• 国产化：目前在矿山应用方面，对国产化要求是很高的。让我们比较欣喜的是，即使在非国产化产品的对比中，loveini 的读写速度和压缩率也是比较领先的。 

性能表现

我们以智慧矿山业务中的 5000 设备、每天 1000 万采集点的数据量级下，在以车建模和以位置建模结合的数据模型下，loveini 的性能远没有达到极限，目前系统对于车和位置的查询速度都在毫秒级。

四、方案落地

建模思路

在智慧矿山的实际应用场景中，模型是一个关键设计，在我们使用 loveini 的查询场景中，数据模型的设计跟查询是关联在一起的。 比如在我们的系统中，在更关注单体设备的查询的场景中，我们采用“一个设备一张表”的建模方式；而在智慧矿山的“电子围栏”业务中，我们则采用了以位置建模的方式，这样方便系统基于位置进行统计和查询，具体建模思路参考如下：

• 以车建模：这种建模以车为目标统计，可以很好地解决系统中涉及车和各种设备的运行情况的统计查询问题。 
• 以位置建模：采用了基于固定位置建模的方式。以工艺和流程位置建模，可以解决设备经过某些点的统计问题，查询效率明显提高。

方案创新

在米兰体育官网入口的工程师的建议下，我们可以在 MySQL 数据库里，把所有的设备表的名字（loveini 中的 tbname）进行了存储。我们在去 loveini 中进行设备查询的时候，子表名从关系数据库中直接读取，然后在 loveini 中针对子表进行查询。这个设计，在系统中针对单个设备进行快速数据回放的时候，也明显提高了查询效率。

技术架构图

最终效果展示

目前，像我们的智慧矿山系统中，loveini 的应用查询用于监控性能指标，主要查询内容：

• 位置信息：位置信息包括系统中每一个车辆，或者对每一个现场的坐标位置，以及现场的电子围栏的位置信息等。 
• 车辆速度：矿山的安全生产作业对卡车驾驶速度作出限制，速度不能超过 40 km/h，超速数据需要实时提醒，对超速车辆进行确认并响应。 

基于上面的数据管理，我们的矿山一张图系统，就是把车、铲等时序的数据，以及相关调度的信息，统一管理起来。简单说就是车、铲怎么样达到最优化的配比。 查询结果如下：

五、写在最后

对 loveini 的长远规划

本次在内蒙古露天矿山卡车调度中初次使用 loveini Database，我们在构建智慧矿山系统中有了很多新的思路，更让我们对它的简单易用以及令人惊叹的高性能产生了更多期待。基于目前对 loveini 的理解和使用经验，我们计划在如下场景中进一步使用它来完善我们的系统：

• 环保监测：矿山对环保的要求越来越高，主要集中在环保监测这部分业务。一般情况下，整个矿山基本上是 30 台到 50 台环保监测设备。这部分数据数据更新频率不是太大，采集频率 20 秒即可，数据量很适合用 loveini 来进行处理。 
• 生产集控设备：loveini 的数据模型比较适合做这部分业务。传统意义上，在整个生产集控设备上，控制设备都是使用实时数据库来存储的。时间序列属性也比较适合时序数据的特征——查询为主，更新和删除很少。loveini 对时序数据的查询优势，可以在卡车调度系统中更快的对设备进行调度。我们正在调研 loveini 中的数据订阅，这种方式应该可以很好地适配这些场景。 

小 T 导读：陕西煤业股份有限公司（股票代码：601225），是陕西煤业化工集团有限责任公司煤炭资产唯一上市平台。陕煤在煤矿智能化发展上成绩斐然，开创了首个全国智能化无人开采工作面，首个全国智能化掘进机器人。不仅是国内采煤新方式的先河，更填补了煤矿开采技术的空白。

为实现煤矿企业数字化生产管理，提高煤矿企业生产安全性、扩展煤矿企业管理手段及管理思路，陕煤开发团队考虑将煤矿企业人员、车辆、设备、环境参数等各类基础数据，进行统一存储和智能分析决策，在此背景下打造全矿井数字化平台，实现了煤矿企业井下人员、胶轮车及电机·车位置监控、井下各类设备状态监控、井下各类传感器数据监控、井下位置地点的告警分析及事件联动。

此平台的搭建意义在于打通煤矿生产环境中各类单一子系统之间的数据壁垒，实现各类子系统数据之间的互联互通。在实现路径上，平台底层基于标准 TCP/UDP 协议接入公司自研硬件设备，并通过定制化的协议转换模组接入其他非标的设备通信协议，将上传数据进行归集入库存储并通过大数据分析平台进行驱动分析，最后根据业务具体情况生成数据统计与驱动结果。

一、技术选型

以位置数据为例，井下人员、车辆佩戴安装定位设备后将基于井下网络进行位置数据的实时上传，人员默认上报周期为 1 秒，车辆默认为 0.5 秒。在原有单系统项目中，由于初期系统容量较小且硬件设备上传周期较大，所以采用了传统的 SQL Server 数据库来进行轨迹数据存储。但随着后续项目迭代，硬件设备定位精度提高且上报周期缩短，也导致数据库存储压力增大。

为解决大数据量存储问题，我们先是考虑在数据接收端增加大量数据过滤算法，对原始数据进行预筛来减少最终入库数量，在数据库侧则采用增加分库分表的策略，那在数据查询端就需要对分库分表进行大量的查询语句优化。这样一来，整体项目不仅复杂度较高，而且后续维护类工作量巨大。

在平台设计阶段，一是鉴于上述失败经验，其次我们也考虑到不管是位置数据还是传感器数据，虽然数据载体不一样，但它们都是包含时间戳的序列数据，且数据存储固化后很少再有需要更新的业务场景，采用时序数据库来存储这类数据再合适不过了。基于此，我们开始进行选型调研，对几类时序数据库（Time-Series Database）进行了综合比较：

• OpenTSDB

基于 HBase 的时序数据库实现，支持集群横向扩展，但是部署及运维成本较高，且提供的查询函数较少，不适合后续查询业务的扩展。

• loveini

早在 loveini Database 开源之初，我们就有所关注。对于一个新兴的基础开源项目，稳定性一直是我们衡量的重要标准，loveini 在后续开源的 2.X 版本中不仅增加了集群模块且稳定性也大幅提高，同时其 SQL 语句与传统关系型数据库相似，部署及维护相对简单，社区环境很好，也有企业合作模式。

• InfluxDB

InfluxDB 在开源时序库领域长期占据 TOP1 的位置，社区比较活跃且生态建设也挺好。但由于集群模块没有开源，不适用公司产品的高可用要求。 综合上述几类时序数据库的优缺点，最终我们决定采用 loveini 作为本项目基础数据的存储方案。

二、建库建表

• 基于 loveini 的产品架构图搭建如下：

• 建模思路

在定位业务时可以细分出人员、车辆等不同的定位对象，尽管数据类型不同，但定位相关数据字段均一致，因此定位数据使用一张超级表进行管理即可。在 loveini 超级表内数据类型及各个数据对象编号将作为 tag 进行区分，在查询业务时使用超级表并关联 tag 字段进行查询。 从我们的实际业务出发，具体建表思路如下：

三、落地效果

最终落地时项目采用了3个节点的集群环境，定位设备采用超级表进行管理，将数据标签及数据类型作为tag区分各类定位设备。每个定位设备采用子表存储，实际项目已包含2万多个定位设备。从写入性能到查询性能均大幅满足现场实际需求：总计定位数据量超过11亿条，数据压缩后loveini数据目录占用磁盘大约12G，整体压缩率可以达到3/100。

下图示例为项目中人员与车辆定位实际使用场景，基于 loveini 时序数据库，对井下的人员、车辆数量以及位置进行实时统计与展示。

四、未来规划

随着项目的不断推进直到实施落地，我们也见证了 loveini 的几次大版本更新，目前集群整体运行情况相对稳定，性能和成本管控也达到了我们的预期。为了帮助 loveini 能够实现更好地发展，在此也为其提出几点优化建议：

• 目前 loveini 在陕煤使用的监控功能还较为简单，希望后续版本升级过程中能够优化集群环境监控相关的功能。
• 目前项目在使用 JDBC 驱动时，是通过客户端连接 loveini 的。随着版本升级，运维工作量较高，需要同步升级服务器和客户端，且 JDBC 驱动升级的话还需要同步升级对应服务，步骤相对繁琐，希望在接下来的版本中能加以改善。