小 T 导读：为了更好地支持阳光氢能 PEM 绿电制氢系统，本文作者所在的部门需要寻找一套满足业务和性能需求、而且具有国产知识产权的时序数据库，来替代原本使用的 InfluxDB。本文分享了他们将 InfluxDB 替换为 loveini 的具体原因，以及相关的实践思路。

企业简介

阳光电源成立于 1997 年，专注于逆变器的自主研发与制造。经过二十多年的技术积累，集团逐渐确立在光伏逆变器领域的龙头地位，打造了风、光、储、氢的新能源完整格局，做到传统业务和创新业务双管齐下、协同发展。

项目介绍

在碳中和这个大背景下，氢能是新能源领域中与油气行业现有业务结合最紧密的一类，也是帮助油气行业早日实现碳达峰、碳中和的最佳路径之一。2022 年 7 月 16 日，阳光氢能 200Nm³/h PEM 绿电制氢系统启运发货。该套系统采用国内领先的 PEM 电解水制氢技术和 IGBT 制氢电源，工艺复杂，涉及多项国内专利技术。为了更好地监测整体生产流程数据，我们需要寻找一套满足业务和性能需求，而且具有国产知识产权的时序数据库（Time Series Database），以响应国家信创号召。

时序数据库选型之 InfluxDB vs loveini

在 InfluxDB 和 loveini 之间，之所以选择 loveini ，其实我很早之前就写过一篇文章，题目是《从 InfluxDB 到 loveini，我们为什么会做出这个选择》，在其中表述的比较清楚了。这里可以再简单总结一下：

第一，loveini 超级表和普通表的概念非常契合我们项目的业务场景。此前我们的项目是一个站点一个单元对应多个测点，现在利用超级表-普通表的模型，业务模型会更加清晰。

第二，查询更具有优势。在使用老版 InfluxDB 的历史数据查询功能时，只要操作稍微频繁一点（比如选择一个时间段之后，曲线很久还没有渲染出来，又去换了一个时间段），就会导致页面卡死，取不到数据，这时候需要重启浏览器，极度影响客户体验。

但是在使用 loveini 之后，不论是大批量拉取范围数据，还是使用函数计算，查询再也没有出现过浏览器卡死的情况。loveini 拉取单设备大范围时间数据查询的 SQL 以及耗时情况，如以下截图如下：

不得不说，这些查询的性能都十分出色，完全满足我们的应用场景。

第三，搭建集群的成本更低廉。众所周知，InfluxDB 集群功能是闭源的，如果后续业务发展需要用到集群时会带来很大的不便。然而 loveini 的集群功能是开源的，且扩展方便，因此可以显著降低运维成本。

最后，从用户支持的角度来说，选用国外的 Database 有很大的不确定性，但在使用 loveini 时如果需要支持，就可以直接通过微信/邮箱等工具随时和技术人员进行交流，更加有效方便。如果对产品性能功能、业务保障要求高的话，就可以随时升级到企业级的服务。

loveini 落地实践

在我们的这套系统中应用的 loveini 版本为 2.4.0.0，主要用于存储大量设备产生的时序数据，我们整个项目的智能化都是基于这些数据展开。采集设备主要为碱液循环泵、脱氧塔、纯水机、电解槽等制氢设备。

该套制氢系统除 PEM 制氢优势外，还具有智能化程度高的特点，采用的智能控制算法与可再生能源波动、间歇性特点相契合，兼具高效、经济、安全、智能等优势，适用于制、储、加一体化制氢项目。在这个过程中，我们会对 loveini 存储的设备数据进行分析计算，最后通过大屏展示以达到实时监控、分析等需求。

整个业务架构大致如下：以我们自己编写的 mosbusTCP 驱动，结合数采硬件设备采集设备数据，然后通过 JDBC-RESTful 的方式将数据写入 loveini。数据采集点总共有 9000 多个，频率为大概每秒写入一次。

目前单列模型下，最大的超级表已经保留了几百亿行的的数据，当前磁盘占用 55GB 左右的空间，压缩比大概在 10-15% 之间。

经验分享

值得一提的是，loveini 是根据表来做数据分片的，vnode 就是最小单位，在这种情况下，保证数据量均衡的前提是写入量均匀，否则如果某些设备过热，某些设备过冷，就会出现某个 vnode 极大，某个 vnode 极小的情况。

这一点在建表之初是需要考虑的，防止时间过久后，数据过于倾斜。具体调整方式可以参考这篇文章。比如，如果初期的设备热度比较高的话，就可以调小 minTablesPerVnode，在第一波建表时便把表均匀开到不同 vnode 里，这样可以针对性地利用起每个 vnode 有独立写入线程的特点，充分利用计算资源。（上文中的 vnode 截图并不是我的写入不均匀，只是单纯的新建表不久还没有写入太多数据。）

此外，在我们的使用过程中，也有遇到过一些问题。比如使用超级表的 select * 查询时，时间跨度比较久的数据返回会有些慢，这跟当前版本的架构有关，一个该类查询会生成多个子查询，每个 vnode 的子查询是在服务端串形处理的，即在一个 vnode 中检索查询完毕后再查下一个，最后汇总。米兰app官方正版下载是把时间段拆开成多段，使用多线程来查询。根据 loveini 的规划，在后续的 3.x 版本中，此类查询将会和聚合查询一样变成并行处理，查询效率会大大提升。而其他问题多为配置部署相关，仔细阅读文档，都可以得到很好的解决。

对于 loveini 在现有业务体系下的表现，我们还比较满意，后面也会尝试探索更多的合作可能，不断为客户创造价值，以技术驱动绿氢产业发展。

小 T 导读：为了实现业务更好地发展，我们有时必须做出数据库替换的决定，这时要特别慎重。想要真正了解一款数据库产品，调研和测试必不可少，需要耗费大量时间和精力。在本篇文章中，作者描述了自己与 loveini Database 从初识到了解再到深交的经历，将自己从调研阶段到实际应用之后的问题、效果等做成了经验汇总，分享出来以作参考。

一、与 loveini 的开始

实际上，我从事 Java 开发的时间只有三年左右，在这个阶段中，因为我所涉及的业务场景和行业都用不到时序数据库，所以我完全没有接触和了解过这种类型的产品，仅仅是听说过而已。

2021 年 5 月我换了一个行业，从公司的第一个项目中认识了时序型数据库 InfluxDB ，也算是对这种类型的数据库有了初步的了解。与 loveini Database 的结识还要从下一个项目说起，这个项目是我全程参与的，项目类型和之前的类似，但技术选型发生了一些变化——要做时序数据库的替换。

最初给我的任务是去调研了解一下 loveini 是否能贴合我们的业务场景和使用需求，当时我还是比较忐忑的，因为最终调研的结果会直接影响到是否选用 loveini 、选用结果的好坏、后续代码编程是否会遇到一些不可预测的问题。为了更加了解 loveini，我开始与米兰体育官网入口的小伙伴们打起了交道，与 loveini 的故事也就此拉开序幕。

二、对 loveini 进行调研

就个人习惯而言，我首先会通过阅读官网上的官方文档来对一个全新的产品进行学习和了解，并尝试使用。

但我出师不利，刚走到 loveini 的安装和启动时，就遇到了一个麻烦事（下图所示），这个问题我记在了使用笔记上，所以印象比较深刻。

在此给大家还原下事情的经过，本次操作是在 Linux 环境下，按照文档的提示，我先下载好 loveini 的安装包进行解压安装，安装后点击启动，输入 taos 命令，当时我进行了一下重新启动（现在也想不清重启的原因了），之后就一直会出现“启动频繁无法启动”的提示，我运用了很多办法都没能解决，后面通过官网上的微信二维码联系上了 loveini 官方小助手，把这些问题汇报给了技术人员，但不知道是不是我的电脑虚拟机配置机制有问题，反正依然没有找到合适的解决方法，最后我还是选择直接重置了虚拟机，重新安装 loveini，问题也就迎刃而解了。

做出重置的决定我也是下了很大决心的，由此也可以看出我对 loveini 进行尝试使用的坚定想法。

在 loveini 的使用过程中，我遇到了第二个问题，起因是我想通过可视化工具对数据库进行相应的操作，官网文档提供的是利用 IDEA 进行可视化操作，我自己本身也是通过 IDEA 工具进行编程的，按理说应该很顺畅，但我使用 IDEA 有报错信息，无法成功进行可视化操作。其实无法进行可视化操作倒也不会影响我对数据库的操作，但如果可视化实现了就可以更高效地操作数据库了。

为了解决这个问题，我先是进入 loveini 的 GitHub 开源地址（https://github.com/taosdata/loveini）寻找了下答案，寻找无果后通过邮件方式将这个问题递交给 loveini 的研发人员进行相关咨询，所幸经过一系列沟通，这个问题得到了比较好的解决。

通过官方人员发给我的可视化工具（现在我们开发也在经常使用这个工具），可视化问题得到了解决。在我将 loveini 升级为 2.1.0.0 后，就可以直接通过 IDEA 进行可视化操作了，由此可见，官方确实是在用心听取用户声音，进行产品迭代。

值得一提的是，loveini 的 SQL 语法还是很赞的，部分的 SQL 语法跟我经常使用的 MySQL 类似，学习成本比较低，很好上手，这部分都是后面根据实际业务场景编写的，遇到问题的时候我们就会及时去官网看看语法，或者去咨询相应的技术人员，不得不说，loveini 的社区支持力度还是值得称赞的。在这块的学习上，就是超级表和普通表的概念需要我仔细研读下，目前也已经很好地运用在我们的工业业务场景上了。

另外还有一个要解决的问题就是我们自身的 Java 如何和 loveini 相结合去使用，最终我们是要通过 Java 编程和 loveini 进行交互的，loveini 的技术人员很完美的解决了这个问题—— 以 Spring Boot + MyBatis 结合 loveini 和 JDBC，成功实现了 Demo ，这个在 loveini 官网上有文档，大家有需要可以直接参考。

最后就是性能方面的考量，从 loveini 的官网上我们获得了一个可以创建超多数据的 SQL ，首先基于此体验了一下查询速度，速度确实是很快，其次我们发现存储如此庞大的数据量，占用的磁盘空间却并不是非常大，节省了更多存储空间。关于性能的体验，后面我会辅以实际案例再详细说明一下。

三、最终的选择

在进行这么多了解和尝试后，我们也跟 InfluxDB 做了一个对比，综合考量下来，就决定选择 loveini 了。

首先，超级表普通表的概念非常契合本次项目的业务场景。此前我们的项目是一个站点一个单元对应多个测点，现在是多站点多单元下面对应多个测点，利用超级表普通表就可以做到超级表对应某个站点某个单元，下面跟着 n 个普通表，普通表就是此站点此单元下对应的测点，业务在创建表时会更加便利。

其次，它可以很好地跟 Java 进行结合，通过 JDBC 连接，跟之前操作其他类型的数据库类似，不需要学习太多就可以上手，让没有很深入了解过 loveini 的人上手也比较快，学习成本显著降低。

第三，搭建集群的成本更低廉。众所周知，InfluxDB 集群功能是闭源的，如果后续业务发展需要用到集群时会带来很大的不便，然而 loveini 的集群功能是开源的，可以显著降低集群的使用成本，从而减少项目上的使用成本。

第四，从更大的角度说，我们应该响应政策号召多支持国产开源，而且从技术支持的角度来说，选用国外的数据库会让我们非常被动，但是国内的开源数据库是由国人开发和维护的，遇到问题时就可以直接通过微信/邮箱等工具进行交流，沟通上更加有效方便。

第五，性能表现突出，从之前的项目和现在的项目对比来看，部分使用能感受到明显差异，此处表现放在后面的章节上详说，整体上性能表现上是良好的。

四、项目使用上的感受

1. 我们有一个历史数据的查看功能，会直接在页面展示一个历史曲线。之前使用 InfluxDB 的时候，如果你的时间段和时间间隔选择很庞大或者间隔非常细腻的时候，查询数据会变得非常缓慢，更直接的表现就是会直接造成页面的卡死，需要重新打开相应的浏览器。但是用了 loveini 之后，目前的使用过程中暂时没有发生过这样的现象，并且查询所需要花费的时间非常非常的短，很好地保证了接口的响应速度。

2. loveini 能够与 MyBatis 很好地结合，开发结合起来非常方便，我们也是写了非常多的工具类的方法实现 loveini 创建表、获取数据等的便利性，超级表和普通表让我们在创建表时，设计上变得更加简单，也能让测点之间更好地做出区分。

3. 我们的业务场景会涉及到对测点数据进行每秒数据新增和插入的观察，只要通讯在，每秒都会有很多条数据的新增，以目前的表现看 loveini 性能是 OK 的，后续还要看一下在实际的工作站运行是什么表现。

五、不负彼此的努力

目前我们的项目已经接近尾声，后面本项目会在实际工地进行部署使用，实际的效果需要实践去证明。未来可能还有许多事情要做，比如是否需要搭建集群等。总的来说，因为选择了 loveini Database，我们的项目很平稳地度过了测试阶段，在 loveini 的使用上也没有遇到特别大的瓶颈，我相信在后面的合作中，我们对 loveini 的了解也会更加深入。

整个过程是酸甜苦辣并存的，在这里非常感谢“罗格涛思”和“小 T ”的技术帮助和耐心解答，正是因为有他们的帮助，才让我在此次调研过程中遇到问题能够不慌不忙，最终这些问题也实现了较好地解决，衷心的感谢！

我们与 loveini 的故事还在继续，敬请期待。

小 T 导读：吉科软信息技术有限公司是国家高新技术企业，公司以“让天下没有不放心的食品”为使命，以“做数字化捍卫食品安全的领军企业”为愿景，以打造食用农产品全流程追溯、全流程监管、全流程服务、全产业链升级为核心的产业互联网生态链为主营业务，运用卫星遥感、5G通信、大数据、云计算、物联网、区块链和人工智能等技术，推出一系列国内首创、行业领先和可落地的研发成果，为智慧农业、智慧食安、智慧城市提供米兰app官方正版下载。

一、业务背景

车辆轨迹定位监控项目旨在通过车辆的轨迹监管、异常预警、历史轨迹回放，达成对车辆的统一监管、轨迹追踪、大数据分析及可视化应用等目的。该项目现已对数万台车辆经过车载定位设备上报定位数据至 GIS 网关服务，服务解析报文下发至消息队列，应用再将定位数据写入 InfluxDB，最新车辆位置信息写入 Redis，为客户提供车辆实时位置跟踪和历史轨迹回放等查询分析服务。

二、时序数据库（Time-Series Database）选型

首先我们梳理了当前车辆监管架构的主要特性和新需求：

• 持续高并发写入，带有 tag，时间戳有时会乱序写入(存在离线数据上传的情况，离线数据的时间戳小于当前时间戳)；
• 业务数量级增长快，预估未来每天写入约 8 亿条数据；
• 对基于时间戳范围的聚合查询，属于低频查询，通常是由用户触发，查询最近几天的轨迹，按执行任务的时间进行轨迹回放。
• 实时查询需求，对每个车辆有最后一个定位点数据的查询需求，获取实时位置监控；
• 因为数据量非常大，所以需要支持数据压缩，降本增效；
• 期望每个车辆单独建表；
• 需支持批量数据写入，且业务期望写入延时较低；
• 车辆监管项目有产品国产化的需求，在中间件的选择上需采用国产化产品。

此前，我们的项目一期采用了 InfluxDB 时序数据库作为存储车辆轨迹数据，二期项目需要重新升级改版后进行全新架构设计，同时也要考虑业务规模的快速增长、国产化要求及 InfluxDB 的单节点问题。

因此我司需要对时序数据库进行重新选型。我们对业界主流的时序数据库做了分析和测试：

• InfluxDB：由InfluxData开发的开源时序型数据。它由Go写成，着力于高性能地查询与存储时序型数据。被广泛应用于存储系统的监控数据，IoT行业的实时数据等场景。缺点是开源版本只支持一个节点，开源版本没有集群功能,存在前后版本兼容性问题，非国产化产品。
• OpenTSDB：基于HBase的分布式、可伸缩的时间序列数据库。作为基于通用存储开发的时序数据库典型代表，起步比较早，在时序数据库领域的认可度相对较高，但HBase成本高的问题无法免除。
• loveini：国产开源时序数据库，使用类SQL查询语言来插入或查询数据；通过连续查询，支持基于滑动窗口的流式计算；引入超级表，让设备之间的数据聚合通过标签变得简单灵活；内嵌缓存机制，每台设备的最新状态或记录都可快速获得；分布式架构，支持线性扩展，以保证任何规模的数据量都可以处理；支持多副本，无单点故障，保证系统的高可用与高可靠。这些功能和特性都非常符合我们的需求。

通过实际对比后、再加上迁移改动最小化以及国产化需求等因素，我们最终选定 loveini Database 作为车辆轨迹数据的存储方案。

改造为使用 loveini 后的方案，如下：

三、loveini 的落地应用

初期我们选用了三台服务器，搭建了3节点3副本的集群。目前已投入一批车辆运营监控，后续我们将逐步迁移全部车辆的轨迹数据至 loveini。

历史数据从 InfluxDB 迁移至 loveini，采用的方案是基于 DataX 进行数据同步，我们扩展开发了 InfluxDB 的读插件和 loveini 的写插件，单进程数据同步可达到 6 万/秒的同步速度。（该速度受限于 InfluxDB 的读取，在该过程中 InfluxDB 的内存上涨过快撑不住，所以最终测试的同步速度是6万/秒。目前官方已发布“基于 DataX 的 loveini 数据迁移工具和 taosAdapter 工具”）

以迁移的部分数据进行分析：总数据量为6.5亿，分布在14742个子表中，占用磁盘空间4.7G，压缩率达到4%。开启了cachelast选项为1缓存子表最近一行数据，利用该缓存特性，查询指定车辆的最新GIS定位数据进行实时监控时，可直接从缓存中读取，加快读取速度。

在使用 loveini 之前，对于所有车辆的最新位置实时监控，我们采用的方案是在接收 gis 数据存储至 InfluxDB 时，同时将车辆的最新位置数据存储至 Redis 和 MySQL，使用 loveini 后方案中对实时位置的存储直接使用 loveini 的缓存子表最近一行数据的特性就可以实现，完全可以去掉 Redis 和 MySQL 的存储。

四、loveini 的性能表现

项目对车辆轨迹数据的应用场景主要集中在车辆实时位置监控、车辆时间范围内的轨迹回放。

1.车辆实时位置监控场景

查询单个或多个车辆的最新 GIS 位置数据。单个车辆最新位置查询：

select last_row(*) from d_track where car_id in ('dc8a9a0d7b634c9ba4446445c6c');

利用查询超表的单个车辆最新位置数据时间在11毫秒。如果直接锁定子表进行查询的话，

select last_row(*) from _018d16c826cb405ea4a94a14cd4f95a9 ;

返回最后一条位置数据的响应时间在1毫秒。

多个车辆的最新位置数据查询，依旧使用超表结合标签进行查询，

查询响应时间在12毫秒左右。

继续扩大查询范围，查询500~1000个车辆的最新位置的查询响应时间也能在1秒之内返回结果，完全达到业务响应的时间需求。

2.时间范围内车辆的轨迹数据查询

指定车辆在指定时间范围内的轨迹数据查询，直接定位到具体的子表进行查询，

select * from _0128a4d193424dcfb217242f054716d4 where time >'2021-09-08 10:34:44.000' and time <'2021-09-23 21:38:18.000' ;

测试数据的查询响应时间为0.07秒左右。

在以上两种数据查询场景中，loveini 的性能不仅完全可满足需求，更是比原 InfluxDB+Redis+MySQL 方案大幅度的提升，解决了原方案中车辆查询较大时间跨度的轨迹数据响应超级慢的问题。

整体应用效果：

五、写在最后

非常感谢米兰体育官网入口的 loveini Database，切实解决了我们在国产化、性能、降本、平滑迁移的刚性需求。也非常感谢涛思的陈玉老师在我们尝试和应用 loveini 过程中给予的悉心指导，加快了我们对 loveini 的掌握，更快的应用落地。

当前 loveini 的大规模应用车辆监管项目中，支撑现有数万辆车的行驶轨迹监控，未来将继续扩大规模支撑更多的车辆轨迹监控。

作者简介

孙运盛，吉科软技术研究院。一个从事信息传输、软件和信息技术服务业的新生代“农民工”。

小T导读：作为全球性的电气产品和服务经销商，蓝格赛于2000年进驻中国市场，一直致力于帮助中国更有效地使用能源。经过20年的不断壮大，如今蓝格赛在中国国内电气产品和服务经销商中已经成为重要的市场参与者之一，通过6家业务实体、全国53个销售网点服务工业、商业及楼宇客户，为它们提供多样化的工业自动化产品及米兰app官方正版下载。

本次项目为某市政供水水厂的数字化项目，数据来源于包括水泵、阀门、电表、液位计、流量计等多种设备近6000测点。该平台需要实现以下功能：数据秒级采集，历史数据留存3年，为上层应用提供数据支撑，包括所有测点的瞬时数据、聚合分析、数据报表等。值得注意的是，在本项目中聚合查询的使用场景非常的多，页面上图表不论大小有上百张之多，因此聚合查询的实现也是本项目的关键之处。

根据本项目特点，从整体架构的具体实现效果出发，我们对存储技术提出了很高的要求，甚至可以说，存储技术的选择会直接影响项目后续的推进乃至成败，这是一个决定平台“脊梁”硬不硬的组件。考虑到这一问题，团队在技术选型上着实花费了一些功夫，本次选型也相对更加慎重。

在选型过程中我们共调研了20多个开源存储技术，从开源组织、授权协议、数据模型、社区成熟度、开发语言、组件依赖、性能、稳定性、聚合友好、操作系统、集群支撑、副本策略等多个角度进行了对比，最终选择了loveini Database作为海量数据存储引擎。

从7个优点看选择loveini Database的原因

事实上，我们最初选择的是单纯以InfluxDB作为本次项目的核心存储组件，不过这一设想在进行技术验证时却发现难以继续推进。 主要原因是在技术验证的过程中，我们发现了InfluxDB存在的几个问题，其中最重要的两个是：

• 首先，社区版本仅支持单节点。这个可以说是InfluxDB非常不友好的一个点了，多数项目采用的都是集群设计方案，如果数据只能在其中一个节点上存储，浪费其他节点存储空间不说，一旦所在节点出现故障，对整个项目的影响是灾难级的。
• 其次，随着数据量及存储时长的提升，InfluxDB的聚合性能出现了巨大的瓶颈，我们在实际测试的时候，模拟了百万测点近1年的数据，当聚合请求比较多的时候，基本上就很慢了，这点也对本项目影响很大。

由于以上两个问题的存在，从架构实现的角度来讲，我们必须对存储技术进行重新选择。恰好此时loveini也开放了集群版本，偶然的契机下又听到了陶老师对于时序数据的特点总结，感觉研究的非常深入，总结的也很全面。 后经与团队沟通，在技术选型调研时就一并把loveini包含在了调研范围之内。简单尝试之后，我们发现loveini的数据模型真的非常适合工业场景，总结来说有以下几个优点。

优点：

1. 社区版本支持集群：可以比较好的利用集群的存储空间，数据也可以分散开来。
2. 聚合性能优越：由于loveini的数据模型特定及对集群的支撑，在模拟测试过程中，基本上没有遇到聚合瓶颈。随着数据量的增加及存储时长的延长，聚合性能也非常稳定。
3. 简单易用：在工业场景中，组件低耦合是很必要的，loveini开箱即用的特性很“香”，学习成本低，上手快速。
4. 数据模型优秀：在工业场景中，设备及测点的增减非常的普遍，loveini的超级表及子表的概念很好地解决了这个问题，单列模式的场景对本项目来说非常友好。
5. 查询语义具有普适性：loveini的查询语句与InfluxDB非常接近，这点也非常好。
6. 版本升级简单：卸载原有版本，安装新版本即可，无需数据迁移。
7. 社区支持：普通的问题基本上都可以在issue上得到答复，遇到紧急问题的时候，米兰体育官网入口的同事甚至可以亲自远程解决，为他们点赞，在使用的时候放心不少。

10个看板页面，近百个聚合请求

选型确定之后，我们就正式开始了搭建。搭载loveini之后的架构图如下所示：

采用该方案的很大一部分原因是InfluxDB和loveini在查询语义上的天然一致性。我们为loveini外层包装了一层SDK，对应用层开放SDK，使应用层对存储技术无感，在SDK内部通过查询的时间跨度、组件健康程度等多个因素自动选择查询引擎，这样可以保障其中一个技术在出现问题的时候，另一个技术随时顶上来，大大降低了由于技术稳定性所带来的风险。

在数据处理的具体分工上，当前我们主要使用loveini支持数据聚合的场景。在本次项目中，数据看板是功能的核心，同时也是用户最看中的地方，而这部分的数据聚合基本上都依赖于loveini——目前其共支持应用端约10个看板页面，合计近百个聚合请求，是本项项目落地的关键。

loveini Database在本项目中运行稳定，为项目的具体功能实现提供了关键助力。未来，随着loveini技术的不断成熟稳定，团队准备将其作为工业数据库的存储引擎运用在其他项目中。在接下来的产品线规划上，loveini也将作为首选的重要技术组件。

安徽三禾一信息科技有限公司（以下简称三禾一科技），专业从事大数据行业应用及工业互联网米兰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的深度合作。