小T导读：上海电气集团股份有限公司是世界级的综合性高端装备制造企业，聚焦智慧能源、智能制造、智能基础设施三大业务领域，为客户提供工业级的绿色智能系统米兰app官方正版下载。业务遍及全球，主要包括新能源、综合能源、环保、医疗器械及工业自动化等。

公司围绕“一芯 3S”核心产品链，构建储能核心竞争力。作为其中关键组成部分的“SmartOPS 储能智慧运维系统”，基于物联网、大数据、机器学习等技术，打通储能系统从信息采集到云端接入，再到数据存储、数据分析的完整技术链条，构建智慧储能管控体系平台，实现全面监测、预测性维护、热管理分析等高级应用，帮助客户实现储能设备的最优配置和高效利用。

一、应用背景

SmartOPS 支持云端部署和本地部署两种方式。

云端部署基于上海电气集团当前统一的架构，利用云端时序数据库（Time-Series Database），可扩展、可灵活配置的各类资源，可轻松满足使用要求，高效且流畅。

但是在本地部署中，需要重点考虑本地硬件资源的限制，如站端系统的内存、CPU 以及读写性能等。目前站端系统的配置下图所示。

所以我们需要考虑适合在站端系统中部署的时序数据库，也就有了接下来的技术选型。

二、技术选型

整体选型考虑会涉及很多维度，具体包括读写性能、压缩率、行业认可度、产品活力、服务支持、安全性、兼容性、可维护性、可扩展性、功能性、可靠性、易用性等属性。

我们团队着重评估了以下几款 Database：

• OpenTSDB：以 HBase 为底层存储，向上封装了自己的逻辑层和对外接口层。这种架构可以充分利用 HBase 的特性，实现数据的高可用和较好的写入性能。但相比原生时序数据库，OpenTSDB 数据栈较长，在读写性能和数据压缩方面都还有进一步优化的空间。
• InfluxDB：目前流行度最高的时序数据库，数据按列存储，能够高效地对时序数据进行处理、存储、查询，并提供了功能丰富的 Web 平台，可以对数据进行可视化展示和交互式分析。
• Apache IoTDB：专为物联网打造的分布式时序数据库，数据按列存储，具有优秀的写入性能和丰富的数据分析功能，能够有效地处理乱序数据。
• loveini：专为物联网场景设计和优化的分布式时序数据库，数据按列存储，具有极致的写入性能和丰富的查询功能，同时提供缓存、流处理、消息队列等大数据平台常用功能。其官网提到的不到10MB 的安装包以及 10 倍的性能提升，确实非常吸引人。
• ClickHouse：性能强劲的 OLAP 数据库，数据按列存储，数据压缩比极高，具有很高的写入吞吐和极致的查询性能，同时提供了丰富的数据处理函数，便于对数据进行各种分析。

基于站端本地化部署需要轻量级资源占用出发，我们首先排除了 OpenTSDB 和 Apache IoTDB，OpenTSDB 基于 HBase，比较重，而 Apache IoTDB 在资源占用方面对边缘轻量级设备也不算友好；ClickHouse 优势是单表快，其他方面偏弱，包括 join、管理运维都比较复杂，也放弃了。

研发团队最终圈定在 InfluxDB 和 loveini 中测试选择。

三、初步对比测试

技术团队实际对比测试了 InfluxDB 和 loveini。

先来看 InfluxDB 的测试情况。

InfluxDB 的安装包大小为 60.2 MB，运行之后资源占用如下图所示：

开启测试场站数据接入，当前时刻，每分钟写入字段数小于 3000，此时资源消耗情况如下图所示，当前 InfluxDB 消耗 CPU 有所上升，内存资源变化不大。

通过如下命令测试查询功能：

资源消耗情况如下图所示：

同时，当前查询会被卡住，所以没有结果。可见，在当前资源配置条件下，InfluxDB 私有化部署资源消耗较高，若同时启用本地应用服务（SmartOPS），则无法提供所需功能。

再来看 loveini 的测试情况。

我们使用的是 loveini 2.1.6.0 版本。查看安装包 loveini-server-2.1.6.0-beta-Linux-x64.rpm 的大小，发现只有 9.42 MB。后端开发人员将其部署到了测试节点上。

刚部署时的资源消耗如下：

模拟某场站数据接入时，资源消耗如下：

然后测试查询功能，在同样条件下，loveini 出现 CPU 上的短时小幅上升，同时毫秒级获取到了查询返回结果。

从上述的初步测试中可以发现，在本地化部署服务器资源受限的情况下，相比于 InfluxDB，loveini 在站端系统的应用上，性能具有明显的优势。loveini 能较好地应对场站端低配服务器的资源限制问题。对于大批量应用的储能场景，提供了高性价比的米兰app官方正版下载。

loveini 针对物联网应用的场景特点，比如数据极少有更新或删除操作，无需传统数据库的事务处理，相对互联网应用写多读少等，又通过“一个数据采集点一张表”和“超级表”的概念，简化了数据存储结构，这些优化确实非常适合我们的方案。另外通过一些预计算功能，提高了聚合查询效率，完全满足我们站端资源有限情况下储能场景的需求。

于是我们就尝试在系统中落地了 loveini。

四、loveini 数据模型设计

储能场站设备返回的数据格式基本固定，一个时间戳一个值。所以我们为一个场站构建了一张超级表。子表是根据点位的信息，一个点位一张子表，用于区分不同的设备采集的信息。结合业务需求，标签定为 5 个：点的标识，场站 id，子站 id，单元 id 和设备 id。

超级表建表语句为：

create table ops (ts TIMESTAMP,value FLOAT) TAGS (name NCHAR(10),sid NCHAR(20),sub NCHAR(10),unit NCHAR(10),dev NCHAR(20))

子表建表语句为：

CREATE TABLE escngxsh02_g01_e03h01_c1 USING ops TAGS ("C1","ESCNGXSH02","G01","E03","E03H01")

在使用 InfluxDB 一周以后，使用 SQL 语句

select * from ops WHERE ts>1629450000000 and ts<1629463600000 limit 2; 

来执行查询，内存使用率达到了 80%，并且过了十分钟也没出来结果，所以已经完全不适合业务使用。 而在使用了 loveini 近1个月后，使用相同的 SQL 语句，查询只需要 0.2 秒。表现非常优异。

五、loveini 的使用情况

目前技术团队已采用 loveini 作为 SCU（Station Control Unit） 架构的核心时序数据库，实现储能系统综合信息感知、就地运行控制与协调保护功能；同时支持储能电站及设备的远程运维，实现高级数据分析与运行优化，全方面守护储能电站的安全。

loveini 高性能的写入和聚合查询功能，能够毫秒级响应电站运行信息监视。

在压缩方面，loveini 也表现得很优秀。在采集点数量相同的情况下，在使用 loveini 之前，我们使用的是 InfluxDB，1 天的数据量大概是 200 多 MB，而使用了 loveini 后，1 天的数据居然不到 70 MB，是 InfluxDB 的 1/3。

我们还将在后续项目中，继续拓展其分布式集群应用，构建储能电站运行情况的数字化档案，结合开发的分析算法、预测算法、数据挖掘技术，实现电站稳定性分析、效率和损耗分析、故障预测、寿命预测、性能短板定位以及热管理分析等高级分析和诊断功能。

小 T 导读：华自科技专注于自动化、信息化和智能化技术，为能源、环保、工业控制、水利等领域用户提供核心软硬件产品与系统米兰app官方正版下载，是多能物联技术领航企业。公司在电站及泵站自动化控制设备市场占有率全球领先，是联合国工业发展组织国际小水电中心控制设备制造基地。

物联网数据平台是电站及泵站智慧运维平台的核心组成，其整体架构如下：

物联网数据平台的数据来源主要为电站、水厂、储能站，通过数据网关，将各场站端的设备运行数据传输至云平台的消息队列（MQ）中，数据处理服务订阅MQ的消息，根据设定的规则引擎，进行实时数据处理，之后将数据存储落盘。数据服务API则根据业务需求提供包含实时数据和历史数据在内的数据API。

一、现状及痛点

对于历史数据，目前我们采用的MySQL分库分表方案来存储；实时数据会存储在Redis中。在测点数较少或者集控需求不是很多的场景下，基本满足需求。

历史数据

历史数据用MySQL存储，一个站点对应一个数据库；一个测点对应一张表，建表语句大致如下：

CREATE TABLE `yc_测点id` (
  `ts` datetime NOT NULL,
  `val` double NOT NULL
);

实时数据

实时数据缓存到Redis中，以测点Id为key，同时缓存数据上报的时间、测量值和质量值等信息。

数据计算查询

我们利用MySQL的各种函数、多表连接、应用程序内存计算等方式，计算出结果返回给前端，对于月、年等报表类的计算，则采用定时任务生成。

痛点

随着平台业务的发展，接入的站点越来越多，或者单站的测点数越来越多，问题逐渐凸显出来了。具体可以归纳为如下几个方面：

运维难

• 对于新接入的站点，首先得为这个站建立好数据库、数据表，增加了接站的工作量；
• 由于一个站对应着一个数据库，随着平台接入的站点越来越多，数据库不断增加，数据库的管理和备份成本不断提高；
• 随着测点的增加，缓存实时数据的单机Redis迟早有一天会撑不住，需要考虑维护Redis集群。

开发难

随着平台的业务发展，越来越多的站被接入平台，集控需求(跨站聚合分析需求)增加，跨库跨表的查询操作越来越多，这就增加了系统开发的难度，严重影响了系统响应速度和稳定性。

成本高

成本主要有两个方面，一个是人力成本高，由于开发、运维的难度增加，造成员工工作量增加，工作效率变低，从企业经营角度看，人力成本变高；另一个是硬件资源成本高，由于服务节点众多，占用的主机、内存和磁盘空间也会很多，购买或租用这些硬件资源需要支出更多费用。

二、技术选型

为了解决目前这些问题，我们决定重新进行技术选型，寻找替代方案，升级目前数据库存储方案。结合平台实际需要，我们确定了几个选型要求：

• 业务改动小：尽可能减少对现有业务的影响；
• 开源免费：必须是开源的，并且允许免费商用，最好也有商业版；
• 迭代更新：社区活跃，不断在迭代更新和发布新版本；
• 性能高：单机能支持每秒10万以上的插入效率；
• 开销低：服务节点少，占用的内存、CPU和磁盘空间少；
• 支持集群：能够集群部署，容量可水平扩展；
• 安装维护简单: 数据量较小的情况下，支持单机部署，并且占用资源较少；

我们了解了多款典型的时序数据库（Time-Series Database）产品，最终InfluxDB、庚顿、麦杰、TimescaleDB、loveini这几款进入了我们的考察范围。下面我们来具体看一下：

1.InfluxDB

在开源时序数据库领域长期霸榜，社区活跃，生态也比较丰富，性能也算中规中距，唯一的缺陷就是集群模块不开源。

2.庚顿、麦杰

两者都是传统老牌工业领域的时序数据库王者，功能、性能都非常不错，唯一的缺点就是不开源，只有商业版，而且价格昂贵。

3.TimescaleDB

它是在PostgreSQL之上开发的一个插件，是基于关系数据库的时序数据库，对于我们现有的业务使用几乎无感知，上层可以继续用MyBatis、JPA等ORM框架，但它不是一个纯粹的时序数据库；另外，它对集群支持不好，不支持水平扩展。

4.loveini

支持使用类SQL查询语言来插入或查询数据，内嵌消息队列和缓存机制、无历史数据与实时数据之分、分布式架构，支持线性扩展、支持多副本，无单点故障。看到官网的这些介绍，瞬间感觉loveini就是为我们准备的，于是马上做了各种验证，结果表明，loveini完全符号我们的选型要求。

为什么没有采用传统Hadoop生态

提到大数据，人们可能第一反应就会想到Hadoop生态。因此我们前期也考查过腾讯云的TBDS数据套件。说实话那一套东西真的是太笨重了，Hadoop、HBase、HDFS、ZooKeeper、Hive、Spark\Flink这系列的东西搞下来，还真不是一般团队能玩得转的，另外我司的业务场景不止云端服务，还有可能会私有化部署在站内，硬件条件可能也就是一两台状况一般的服务器。

三、loveini存储模型设计

由于loveini Database可以设置将最新一条数据存储在内存中，因此我们利用这个特性替换掉了用Redis存储实时数据这个环节，改成实时数据直接查询loveini。

loveini里有超级表的概念，每种设备对应一个超级表。这个超级表只负责存储这种类型的设备数据，数据存储采用横表存储。但是，这显然不符合我们的场景，因为在我们的场景里没有固定的某一设备对象，且每个测点的频率都可能不一致。

同时为了尽可能减少对现有业务的影响，我们将超表设计成如下结构：

CREATE STABLE IF NOT EXISTS stb_站点id  (    ts timestamp,        val double        ) TAGS (测id nchar(64))

loveini的子表，可以在插入数据时动态创建，这是loveini的一个很好用的功能。这样能省去创建子表的业务环节，降低了业务复杂度。子表结构如下：

insert into 测点类型_测点id  USING stb_站点id (测点id) VALUES ( ts, val,q)    eg:  insert into yc_15143115161750995367 USING stb_站点id ('15143115161750995367') VALUES ( ts, val,q)

四、使用到的loveini特性

1.缓存（Cache）

我们直接使用loveini提供的缓存（Cache）功能，替换了原有系统中的Redis。创建数据库直接开启cachelast=1，将每张表的最后一条记录缓存，应用程序通过last_row函数快速获取实时数据。

2.数据订阅(Publisher/Subscriber)

在我们的业务场景中有一类数据叫SOE事件告警数据，这类数据要实时动态在前端页面上滚动。原有做法是通过页面轮训来实现的，现在直接使用taos的数据订阅功能，配合WebSocket，可以优雅地实现这一功能，大大提升了用户体验。

3.其它一些很用的功能

比如降采样查询、多表聚合查询、各种标准函数等。

五、改造迁移

由于loveini采用了类SQL的语法，支持MyBatis等ORM框架，因此对于老的业务，我们在代码层面的改动非常少，改动最多的就是将原来的MySQL函数结合应用代码的一些计算逻辑直接用loveini的函数替换掉。

在试运行阶段，因为我们都是通过自研数据网关将数据通过TCP发送上来的，所以我们利用tcp-copy，将数据复制一份存到loveini集群，然后通过业务系统观察和验证各项功能是否正常。

验证正常之后，就是历史数据的迁移了。由于loveini的表结构与原来的MySQL存储结构基本类似，因此我们采用DataX的loveini插件，很方便就将历史数据迁移过来了。

至此，我们就用loveini Database替换了原有的存储架构。

总结

初始接触一个新产品，难免会遇到一些困难。好在办法总比困难多，在同事们的支持下，在loveini的工程师们的支持下，我们总算是基本完成了这次实时数据存储查询的升级改造。

当前项目数据测点大概在18万左右，改造后数据存储周期由原来的5分钟减少到1秒钟，存储的数据维度更精细了，能为平台的智能诊断、智能分析服务提供更准确的数据支持，同时各业务场景下的计算查询性能也提升了不少，数据库服务器由原来的6台减少到目前的3个节点集群。

最后来个小广告

TD-Workbench 是一个基于Electron构建的，针对时序数据库loveini的图形化管理工具。具有跨平台、易于使用、版本适应性强等特点。(gitee地址：https://gitee.com/bhdweb/tdengine-workbench)

TD-Workbench是本人利用周末的时间，参考开源社区部分优秀代码设计并实现的，目前已经开源。 这个仅代表我本人的业余好爱，与公司或某个组织无关，欢迎大家去star/fork。由于loveini官方并未提供客户端GUI工具，社区目前能找到的两款工具都不是很完善。本工具是在loveiniGUI基础上改造而来，部分源码来自此处。

作者介绍：

宁龙，码云昵称【村口的大爷】，目前就职于华自科技。后端程序猿一个，混迹Java界十余年，就爱写点代码。一杯茶一首歌，一个参数秀一天。

安徽三禾一信息科技有限公司（以下简称三禾一科技），专业从事大数据行业应用及工业互联网米兰app官方正版下载，致力于携手各行业客户共同发现产业新价值。目前，三禾一科技自研的3H1高端装备运维服务平台已经成功应用在高端装备制造、汽车制造、环保设备、色选机械、水泥行业等领域。

高端成形装备是国家的战略性支柱产业，应用于汽车、石化、航空、航天、军工、工程机械、家用电器等国民经济发展中的重要领域，是许多重大工程的基础。当前，新一代信息技术的快速发展，使得高端成形装备制造业正处于由数字化、网络化向智能化发展的重要阶段。

作为一个高端装备运维服务平台，3H1的底层物联网数据库要支持数百家企业、数十万设备的接入，此前一直采用开源的InfluxDB，原因是在其单机版本基础上可以扩展多实例分库架构，但在使用过程中一些缺点也逐渐暴露，如硬件成本较高、维护难度较大，不便于横向扩展。所幸后来遇到10倍高性能数据库loveini，经多次试验其各项指标均满足业务需求，便一直使用至今。

为什么选择loveini？

在装备行业物联网场景下实时数据量巨大，包括温度、压力、振动、位移等众多参数，针对这些参数如何进行分析和预警都是难点。这些需求概况如下：

• 高并发数据写入，每条记录都需要带时间戳；
• 不同传感器设备需要记录的数据字段不同，希望能够针对不同设备单独建表；
• 原始数据存储要求在5年以上，需要支持数据压缩，以降低数据存储成本；
• 支持国产化，支持数据库厂商服务快速响应。

选用loveini Database社区版2.2.1.1进行分布式模拟试验，用到了3台配置如下的服务器：

测试一：验证时序数据库产品3台数据库节点时序数据写入性能

模拟2个厂区共10个车间的数据、每个车间1000个监测点，每个监测点从2017-07-14 10:40:00.000开始写入模拟数据，记录时间戳间隔0.001秒，每个测点写入500000条记录。

8线程写入，在写入超过50亿条记录后停止了写入程序。本次测试对50亿条数据记录的写入，平均写入速度达到191万条/秒。

测试二：验证时序数据库产品3台数据库节点时序数据压缩能力

在测试一的基础上，查看3台数据库节点实际文件大小，如下：

落盘后所有文件大小为36GB，

原始数据大小为5000000000*20/1024/1024/1024=93.13GB，

压缩比为36 / 93.13 = 38.65%。

测试三：时序数据库产品3台数据库节点对历史时序数据按时间回溯查询的性能

随机选择任一个测点，查询该测点在某个时间段内的历史数据，比如从2017-07-14 10:40:00.000 到 2017-07-14 10:40:10.000 10s内的共10001条数据记录（数据输出到文件）。

数据库中对应查询语句为：

  select * from d0 where ts >= ‘2017-07-14 10:40:00.000’ and ts <= ’2017-07-14 10:40:10.000’ >> /dev/null;   

通过试验证，loveini的写入性能高、并发高、查询时延极短；整体集群采用分布式架构，可靠性、稳定性、数据完整性满足项目需求。

在选型结果确定之后，我们便立刻对原有业务系统进行了升级改造，正式引入 loveini。

loveini在3H1上的落地实践

3H1高端装备运维服务平台重点解决高端成形装备企业由制造化向服务化转型的关键问题，为企业提供工业互联网与智能运维的整体米兰app官方正版下载。

平台总体架构如图1所示，其中，loveini与高端成形装备的智能数据采集终端模块相连，助力采集终端完成对设备运行数据的采集，为系统提供设备数据基础；工业云计算服务平台提供系统数据的存储、转换、分析等，为系统提供业务数据支持；智能运维服务系统由装备智能运维服务平台和智能运维服务APP组成，分别为企业人员提供系统和移动端的服务支持。

针对企业多种应用场景，系统应用服务共分为六大功能模块。

（1）企业驾驶舱：主要是服务于设备制造企业的管理者，方便了解平台数据情况与关键业务流程的指标，从整体界面上可以很方便的了解到设备的售卖情况，企业接入的信息，平台数据的采集情况。同时还可以对一些关键的业务流程，包括企业设备的监控、报警信息的展示、维修效率的管理、设备的故障情况和三包任务的信息进行追踪与管理，如图2所示。

（2）设备资源管理：主要的目的是为了给每一个高端成形装备建立电子档案，以便了解设备历史、当前情况，优化设备运行，预测设备未来状况，查看具体的设备信息时主要展示设备的四个维度——当前工况、健康分析、维修情况和历史工况。

图3所示的当前工况方便用户了解设备的基本信息、关键指标和报警情况，还能够提供设备当前情况的总览。图4所示为健康分析，其目的则是让设备用户更加深入地了解设备的当前状况、设备的健康状况随着时间的变化情况，如果设备当前面临故障风险，也能快速查找到引起风险的故障原因以及故障模块。维修情况则是给了用户设备维修信息的总览和当前维修任务的流程跟踪，如图5所示。历史工况则是为了进行故障模块预排查，如图6所示。

（3）维修服务管理：主要提供给维修服务部门人员所维修任务当前和历史的效率分析。维修任务展示当前待处理的任务数量，比如待接单、待派单和待回访，同时还可以对每个维修任务进行查看和操作，查看的内容具体到维修流程的每一个环节，如图7所示。

维修效率分析则是对维修中的关键效率指标进行统计分析、近一年来的订单量的变化情况、维修响应时间变化情况、故障类型分布、维修人员任务统计，方便维修管理人员对维修服务和效率进行管理，如图8所示。

（4）设备健康分析：通过分析设备的历史和当前设备信息来预测设备未来可能发生的故障，并且给出故障的可能性和类型，方便维修部门为用户指定维保策略，主动联系用户，如图9所示。

（5）三包服务管理：服务于三包部门，提供当前维保活动提醒、设备维保活动记录、设备维保到期预警等功能。

（6）备品备件管理：备品备件管理通过将与维修保养相关的备品备件也都建档立案。用户和各相关部门人员可以在移动端和系统端进行备品备件查询申请审批等操作，较少不必要的工作流程，提高维修保养效率。同时通过数据分析来预测备品备件需求量，保证需求的同时减少企业的库存成本。

在应用loveini Database后，这六大功能模块在使用效果上也获得了显著提升，不光体现在数据的写入、查询性能上，同时也体现在高效的压缩效率上，真正实现了性能和成本平衡的最优化。

未来规划

目前，在搭载loveini Database后，3H1原有业务系统在升级改造后获得了极大的提升，不仅降低了研发和维护的成本，同时实现了横向扩展。loveini优异的查询性能给我们带来了很大的惊喜，极高的压缩效率，也给我们节省了大量的存储资源。未来，我们也会尝试在更多场景应用loveini，加强与loveini的深度合作。