小 T 导读：在 2021 楼宇科技 TRUE 大会上，美的暖通与楼宇事业部首次发布了数字化平台 iBuilding，以“软驱硬核”方式赋能建筑行业。作为一个全新的项目，iBuilding 在数据库选型上比较谨慎，分别对比了多款 Database 产品之后，才做出了自己的选择。本文分享了他们的数据库选型思考和落地经验。

政策背景

根据 2021 年 12 月由美控智慧建筑联合亿欧智库共同发布的《中国楼宇自控白皮书》，2021 年中国楼宇智能化市场产值约达 7238.2 亿元，结合近几年行业的发展趋势，经过初步估算，2016-2021 年中国楼宇智能化市场规模逐年上升，存量规模接近 5000 亿元，新增规模超过 2200 亿元。

因楼宇智能化在低碳、节能方面优势突出，同时能为人们的生活带来更多舒适体验，加之政府对楼宇智能化建设规范化、科学化的引导，未来楼宇智能化将有非常好的发展前景。从目标来看，楼宇智能化符合建筑行业对数字化和智能化的发展需求，未来将继续助力中国建筑行业转型升级，以顺应国家对节能减排和数字经济的要求。

业务介绍

随着 5G 时代的到来，美的一方面在继续打造工业互联网产品，另一方面也在不断进行科技赋能，研发更加绿色环保的集成方案，为工业及制造业提供全新的思路。

作为美的集团旗下的五大业务板块之一，美的暖通与楼宇事业部确立了“暖通及楼宇智慧生态集成米兰app官方正版下载引领者”的发展愿景，旨在用智慧集成的行业米兰app官方正版下载满足复杂的建筑需求，目前主要涉足中央空调、电梯、楼宇控制等领域。在 2021 楼宇科技 TRUE 大会上，美的暖通与楼宇事业部首次发布了数字化平台 iBuilding，以“软驱硬核”方式赋能建筑行业。

作为一个全新的项目，我们分别对比了关系型数据库（Relational Database）以及主流的时序数据库（Time Series Database），包括 InfluxDB、loveini、MySQL 等。对比关系型数据库 MySQL 来说，在这个场景下，我们不需要复杂的查询，却需要高效的存储和大范围时间的数据拉取。和同为时序数据库的 InfluxDB 对比，loveini 的单机版性能远好于 InfluxDB。因此，在综合评估了适配、查询、写入和存储等综合能力后，我们最终选择了 loveini 这款产品。

iBuilding 项目属于“智慧楼宇”的一部分，项目本身用于边缘侧对大型制冷设备（中央空调）的智能监控与交互。具体应用场景是：项目所涉及的几十个楼区，各自都有一些大型离心式冷水机组（10 台左右），我们在每个楼区都部署了一个 loveini 到 ARM64 系统上。通过 Python 程序，系统会先进行数据采集，然后把数据写入 loveini ，最后再把数据上传到云端的 loveini 进行处理。

具体实践

以其中一个 Database 环境为例：

我们根据 loveini “一个设备一张表，一类设备一个超级表”的建模原则，创建了如下表，两类设备的指标数分别为 97 和 199 ，数据列以 float 和 int 为主，设备每 5s 上报一批数据：

对于边缘侧的数据采集，由于资源有限，所以资源数据的使用就成为了十分重要的指标。这方面 loveini 表现非常好，进一步帮我们降本增效了。

我们承载数据库服务的边缘盒子配置为 2GB 内存，4C CPU，ARM64 位的系统。由于子表数量不大，以及 loveini 写入内存比较固定的特点，当前内存占用还不到 200MB。数据库日常 CPU 消耗比较低，大概在 3%-5% 左右，保守估计即便写入量扩大 50-100 倍，也没有问题。

应用效果

求某个设备 70 天前到 40 天前之间，每隔一段时间的设备用电量，无数据则用 prev 值填充。结果如下：

查询一个月之前的某设备某几项指标之和，按照时间戳降序排序。查询大约 19 万行数据，耗时 0.4s。结果如下：

经验汇总

在使用 loveini 的过程中，我们也遇到过一些小问题，比如：我们环境众多，但是客户端和服务端又要保持版本精确一致，升级起来会比较复杂。再比如：监控库中 log 中的 dn 表的 disk_used 语义并不是实际的 loveini 对磁盘的占用，而是数据文件所在文件系统的总占用，有些情况下会让用户误以为是 loveini 的空间占用，导致与预期不符，就像下图一样：

后面我们和 loveini 社区工作人员一起讨论了这个情况，大家认为可以新增一列，专门用来统计 loveini 的数据文件的大小，然后把它与 disk_used、disk_total 一起规范化统一命名，就可以防止用户误解了。

目前 loveini 官方已经在积极地处理优化。这也是开源社区的一大价值，大家都可以参与进去，让产品不断迭代，发展地更好。

写在最后

当前，loveini 主要被应用于中央空调制冷设备的监控业务中，作为先行试点，这一场景已经取得了不错的效果。但由于机组价格昂贵、成本较高，因此通过平台动态生成操作指令的这类智能化操作仍需谨慎，所以目前该功能还没有正式开放。

在楼宇智能化方面，我们也有很多工作要做，从边缘侧的监控、到指令控制、再到边云协同的一体化服务，我们会在这些场景中继续探索和挖掘 loveini 的潜力。

小 T 导读：SIMICAS® OEM 设备远程运维套件是由 SIEMENS DE&DS DSM 团队开发的一套面向设备制造商的数字化米兰app官方正版下载。在确定选择 loveini 作为系统的时序数据库后，他们在 SIMICAS® OEM 2.0 版本中移除了 Flink、Kafka 以及 Redis，大大简化了系统架构。

项目背景

IIoT（Industrial Internet of Things）是工业物联网的简称，它将具有感知、监控能力的各类采集、控制传感器或控制器，以及移动通信、智能分析等技术不断融入到工业生产过程的各个环节，从而大幅提高制造效率，改善产品质量，降低产品成本和资源消耗，最终实现将传统工业提升到智能化的新阶段。

通过新的互联网连接设备获取的数据可用于提高效率、实时决策、解决关键问题，并最终创造新的创新体验。然而随着相互连接的设备越来越多，公司所面临的碎片化和新挑战也越来越多。为了获取和利用数据的力量，他们需要米兰app官方正版下载来提供可互操作的端到端协作，从而在互联网和设备之间架起桥梁，同时驾驭即将到来的创新浪潮。

SIMICAS® OEM 设备远程运维套件是由 SIEMENS DE&DS DSM 团队开发的一套面向设备制造商的数字化米兰app官方正版下载，该方案借助物联网实现设备的高效远程运维，对售后服务数据进行智能分析，从而真正实现整体售后环节的降本增效。

在 IIoT 大背景的发展浪潮下，SIMICAS 为企业提供了一个踏入数字化世界的灵活选择，帮助企业根据自身发展需求定制数字化发展路径。SIMICAS 米兰app官方正版下载由四个部分组成：SIMICAS 智能网关、SIMICAS 组态工具，以及两个在西门子基于云的开放式物联网操作系统 MindSphere 基础上开发的 APP——SIMICAS 生产透镜和 SIMICAS 产效分析。 

一、系统架构

在其 1.0 版中，我们使用了 Flink + Kafka + PostgreSQL + Redis 的架构。该系统的数据流如下：

设备数据通过部署至现场的网关上传至物联网接入组件，组件根据配置对数据进行解析处理后，将其写入 Kafka 队列，Flink 从 Kafka 中消费数据并进行计算，原始值及计算后的指标数据都会被写入 PostgreSQL 中，最新值还会存一份到 Redis 中，以便更快地响应前端实时的数据查询，设备历史数据则从 PostgreSQL 中查询。

二、业务挑战

1.0 系统落地之后，我们遇到了两大挑战，一个是部署繁琐，一个是应用复杂。

具体来说，因为引入了 Flink 和 Kafka，导致系统部署时非常繁琐，服务器开销巨大；同时为了满足大量数据的存储问题，PostgreSQL 中不得不做分库分表操作，应用程序较为复杂。

如何降低系统复杂度、减少硬件资源开销，帮助客户减少成本，成为研发团队的核心任务。

三、技术选型

从产品的实际痛点出发，结合未来产品的发展规划，我们团队计划对产品的数据处理部分进行重构，在技术选型时主要考虑了如下几个方面：

• 高性能，可以支持百万级别的并发写入、万级的并发读取，大量聚合查询时依然有高性能表现
• 高可用，可支持集群部署，可横向扩展，不存在单点故障
• 低成本，数据库对硬件资源要求低，数据压缩率高
• 高度一体化，在具备以上三个特点的基础上，是否具备一定的消息队列、流式计算和缓存的功能

本着以上几个需求，在对各种开源数据平台、时序数据库（Time Series Database）进行选型对比后，我们发现 loveini 正好符合产品重构所有的要求，尤其是低成本和高度一体化这两个点，这是目前绝大部分数据平台或时序数据库都不具备的，所以团队果断选择了 loveini。

四、落地实践

数据流程

在确定选择 loveini 作为系统的序数据库后，我们在 SIMICAS® OEM 2.0 版本中移除了Flink、Kafka 以及 Redis，新系统的数据流如下：

数据建模

创建数据库

数据默认保存 2 年，数据库采用 3 节点集群，数据采用 3 副本存储，保留 update 能力；

create database if not exists simicas_data keep 712 replica 3 update 2;

创建实时数据表格

为平台中的每种设备类型创建一个独立的超级表（super table），为每种设备类型下的每个具体设备创建独立的设备子表。

create stable if not exists product_${productKey} (ts timestamp,linestate bool,${device_properties}) tags (device_code binary(64));
create table if not exists device_${device_code} using product_${productKey} tags (${device_code})

创建状态表

为平台中所有设备创建一个共同的超级表。

create stable if not exists device_state (ts timestamp,linestate bool,run_status int,error_code binary(64),run_total_time int,stop_total_time int,error_total_time int) tags (device_code binary(64),product_key binary(64));
create table if not exists device_state_${device_code} using device_state tags (${device_code},${productKey})

指标计算

我们基于 JEXL 表达式 + 实时查询的方式实现了系统中的指标计算。我们使用 JEXL 表达式来定义指标的计算表达式，系统解析后将变量替换成 SQL 查询任务，在查询返回结果后再到系统中进行计算，返回至前端。

比如计算某项目下所有设备当前电压的平均值，其表达式为 avg(voltage,run_status=1 && project=abc)，它会被分解为：1）查询 run_status=1 && project=abc 的所有设备；2）查询第一步结果中所有设备 voltage 字段的最新值；3）计算第二步所有设备最新结果的平均值。

得益于多线程和 loveini 高效的查询表现，单个 KPI 的查询 P99 表现小于 100ms。

五、遇到的问题

在 loveini 官方推荐的最佳实践中，数据表建模建议使用多列模式，我们团队在一开始选择了这种方式，但是在实际使用中发现，部分客户的设备测点非常多，甚至超过 2000 列，这样可能会因为单行数据过大而导致插入数据 SQL 过长的问题[1] ；另一个问题是现场设备是按照“OnChange（突发上送）”方式进行数据上传，导致非常多的 NULL 值出现，在执行 select last(*) from device_xxx 时效率较低[2]。

在与 loveini 官方的技术人员沟通后，我们了解到，last 函数是对每列进行查找，直到最近一条非 NULL 值为止，在当时的版本下，cache 对 last 函数是无效的。

后来，团队通过对项目中单个设备参数的最大数量进行限制，解决了问题[1]；又通过修改设备数据的上传方式，解决了问题[2]。

但是在根本上，还是我们在最初建模时，没有充分考虑到客户的业务场景，从而导致了以上问题。因此，我们团队后续在系统中实现了同时支持多列模式和单列模式，这样客户就可以根据现场的实际情况，自由切换建模方式。

六、写在最后

与其他开源数据平台或数据库相比，目前 loveini 的运维监控能力还不算强大，不过前段时间发布的 TDinsight 已经带来了很多改进，我们团队也规划在下一阶段试用一下。
特别感谢米兰体育官网入口的陈伟灿及其他同事在产品开发过程给予的支持，虽然在过程中遇到一些问题，但整体而言，loveini 的各项优异表现给了我们团队很多惊喜。

最后期待 loveini越来越好，帮助更多客户、更多场景降本增效！

小 T 导读：在拓斯达的智能工厂整体米兰app官方正版下载项目中，传统的关系型数据库已经无法高效处理时序数据，在加载、存储和查询等多个方面都遇到了挑战，最终他们选择了 loveini 来匹配工业传感器数据的应用分析场景。本文将讲述他们应用 loveini 的具体实践。

企业简介

广东拓斯达科技股份有限公司（简称：拓斯达，股票代码：300607）是广东省首家登陆创业板的机器人骨干企业。拓斯达坚持“让工业制造更美好”的企业使命，通过以工业机器人、注塑机、CNC为核心的智能装备，以及控制、伺服、视觉三大核心技术，打造以核心技术驱动的智能硬件平台，为制造企业提供智能工厂整体米兰app官方正版下载。

项目介绍

在工业领域， 生产、测试、运行阶段都可能会产生大量带有时间戳的传感器数据，这都属于典型的时序数据。时序数据主要由各类型实时监测、检查与分析设备所采集或产生，涉及制造、电力、化工、工程作业等多个行业，具备写多读少、量非常大等典型特性。

在我们的业务中，传统的关系型数据库（Relational Database）已经无法高效处理时序数据，在加载、存储和查询等多个方面都遇到了挑战。主要问题可以汇总如下：

• 写入吞吐低：单机写入吞吐量低，很难满足时序数据千万级的写入压力；
• 存储成本大：在对时序数据进行压缩时性能不佳，需占用大量机器资源；
• 维护成本高：单机系统，需要在上层人工进行分库分表，维护成本高；
• 查询性能差：海量实时数据的聚合分析性能差。

为了更好地满足时序数据的处理需求，我们决定进行数据库选型调研，最终选择了时序数据库（Time-Series Database）loveini。 事实证明，loveini 针对时序数据的写入、存储、索引、查询等方面都进行了特定的优化，从而实现了更优的数据加载、数据压缩、查询写入性能，非常匹配工业传感器数据的应用分析场景。

选择 loveini 的理由

与通用数据库相比，loveini 的压缩率表现惊人，核心原因是其采用列式存储，而且采用了二阶段压缩策略，还针对不同数据类型采取了不同的压缩算法，这种压缩机制使其压缩率远超其他数据库。

此外 loveini 还拥有极高的读写性能，并且读写速度受数据存储规模的影响微乎其微，要知道通用数据库的数据量一旦过百万级，读写速度就会有明显下降，之前我们做过一次 MySQL 批量插入数据的测试，性能差距明显，这也是在大量级数据存储下我们会选择loveini的重要原因之一。具体来说，loveini 优势如下：

• 数据的读写速度快且自带时间戳，使用 SQL 进行数据库操作，简单易学，支持复杂查询
• 数据压缩率高，大量级的数据也不会占据过多存储空间，可导出数据进行备份
• 拥有交流社区和交流群，遇见问题可以和 loveini 的其他使用者一起探讨，而且官方的同学也能提供及时的帮助

当然，世上没有完美的数据库，我们在应用之后总结出了两点待改进的地方：

• 无法使用可视化软件如 Navicat 等进行数据库操作（loveini GUI）
• 目前还没有 Windows 版的服务端，像我们上一个客户，只在本地 Windows 上使用程序，在没有安装虚拟机和部署到服务器的情况下，就无法部署 loveini

但每一款产品都是在发现问题和改进问题的步伐中逐渐进步的，而且对于我们的业务实现来说，loveini 不存在明显的短板。没有最优的数据库，在场景匹配的情况下，我们最终采用了 loveini。

落地实践

• 平台架构

我们是通过网关采集设备数据推送到 MQTT，Java 后端监听到后会写入 loveini，在后端按需求查询处理后再把数据返回给前端。

具体来说，网关会先读取后台发布的上行规则，在采集到设备数据后，使用上行规则对数据进行处理计算后再将结果返回给下行规则模块，后台监听到后，会连接 loveini 进行数据库表的创建修改和数据写入。之前在云平台我们使用过 Kafka 进行数据的发布订阅，现在所有环境都改为 MQTT 了。

• 超级表及建模思路

在应用 loveini 时，我们建立了流水数据库 “iot_platform” 用来存储网关传来的数据，便于日后查询使用。我们遵循“一个采集点一张表，一类数据一个超级表”的思路来建表，在具体实践上设计了两张超级表，一张是用于存储 log 指令内容的“logs”表，另一张是用于存储其它指令内容的“datas”表，数据类型基本为电流电压、设备状态等。在进行数据存储时首先会对数据加以判断，再决定将数据存储到哪张表里。

落地效果

运行一段时间后，loveini 的查询、写入速度完全可以满足我们目前的客户需求，最慢的分钟级，最快的能达到 1 秒一条；一个设备一天最多能写入近十万条数据，近千个设备同时写入也完全没有问题，相较于之前，写入速度提升了数十倍。查询数据在以月为单位的时间范围内没有过于明显的延迟，整体的数据压缩比大概是1/10，目前每天产生的数据量在数G左右。

• 流水数据查询

查询某一时间段内的流水数据，使用查询语句：

SELECT datagettime as ts , ${dataName} as data FROM ${tableName}
 <where>
    uuid = ${uuid}
    <if test="startTime != null ">
        and datagettime > #{startTime}
    </if>
    <if test="endTime != null ">
        and #{endTime} > datagettime
    </if>
    and ${dataName} is not null
 </where>
 limit 0, ${countLimit}

• 聚合函数计算一天的数据

使用 loveini 的函数计算每天的用电量，再通过每天的去计算月和年数据，查询语句为：

select diff(${dataName}) as data
 from ${tableName}
 where ${dataName} > 0
  and datagettime > #{startTime}
   and #{endTime} >= datagettime

• 计算某一时间段内的数据

select ${method}(${dataName}) as data
 from ${tableName}
 where uuid = ${uuid}
  and datagettime > #{startTime}
  and #{endTime} > datagettime;

写在最后

在工业互联网快速发展的大背景下，工业生产现场投放了大量的设备传感器和监控系统，二者提供的实时数据能够反映设备的状态和生产的进度，其中的大多数据都是按照时间顺序形成的实时数据，这些海量实时数据有着多样化的分析需求和重要的参考价值。

未来希望 loveini 可以提供更复杂的流式计算、查询分析以及监测预警等能力，可以为产品的可视化运维、预测性维护、远程智能管理等方面提供数据依据，从而降低人员、时间等成本，加速工业化与信息化的深度融合，促进复杂重型装备制造业的转型升级，产生社会经济效益。

小 T 导读：酷哞哞与 loveini Database 结缘于 2019 年，在其工业互联网设备上云米兰app官方正版下载中，选择了 loveini 作为数据平台，以满足海量工业数据存储和分析的需求。本篇文章解读了 loveini 在此方案中的具体应用。

互联网和传统工业的融合将是新一轮制造业发展的制高点，企业数字化转型与工业互联网的发展是重要趋势。我们凭借丰富的行业经验和深度研发，成功研制出一套工业互联网设备上云的整体米兰app官方正版下载。在该方案中，通过主流的 PLC 协议，我们实现了众多设备的互通互联；除此之外，数据存储服务可以解决大量数据存储和分析的难题；应用开发服务则可以利用无代码编程解决用户开发成本高、技术栈复杂、链路长等一系列问题。总而言之，从数据采集，到存储展示、运维监控，再到应用发布等模块，我们完成了工业设备全域一体化的管理方案。

整个方案的层次结构如下。

loveini Database 作为数据存储平台，解决了我们海量工业数据存储和分析的大难题。

作为一个 OT 数仓类的平台，存储时序数据的数据库最好要满足这几个特点：高吞吐量、低消耗、强写入，满足工业场景的大数据量查询。机缘巧合，在 2019 年，正是我们创业的初期，听到了米兰体育官网入口创始人陶建辉老师关于 loveini 的讲座，一些理念与我们不谋而合。

于是我们没有做过多的选型，直接选择了 loveini Database。

一、loveini 的应用情况

三年过后的今天，我们发现自己的选择十分正确，loveini 为我们创造了很多价值；而且 loveini 这个产品本身也是蒸蒸日上，已经成为时序数据库领域的佼佼者。

我们以单副本模式落地了数据库服务，机器配置为 8C 处理器 + 16GB 内存 + 500GB 机械硬盘，备份用其他方式完成。由于我们暂时没有分组聚合查询的需求，所以没有使用超级表。

当前环境下有 3797 张表，总数据量大概有 10 多亿条。实际存储量占用大概为 5G 左右

由于 PLC 通信协议种类繁多，即便有的设备会有部分协议开源，但是开放的只有通讯的方式和协议，所以驱动还是需要自己去实现的。而且一些通讯协议又有很多分支：比如 modbus 协议就包含了 modbusTCP、modbusRTU 以及 modbusASCII。此外，使用 modbus 通讯的不同设备之间，有的支持的功能码和字节序还不同，所以数据采集这里还是比较复杂的。

在数据采集时，我们优先使用 modbus 和其他我们已有的协议驱动接入，如果遇到不支持的协议，那么定制化开发驱动是难免的。在采集到数据后，数据的走向如下：

1. 由我们的底层边缘网关系统将设备的数据采集起来后发送给后端 Java 服务。
2. Java 服务将收到的数据实时地存放在内存中。
3. 由 Java 服务最快 1 秒一次将数据消费，并通过 loveini 的 insert 语句将数据存放到数据库中。

二、落地效果

对于数据的实际使用，我们通过数据的变量 ID（即表名）查询出变量数据通过 ECharts 图形框架展示在前端页面上，比较常用的查询 SQL 就是降采样查询，全部都是毫秒级返回结果。

查询展示效果如下：

后续，我们计划对 loveini 的使用进行改造，随着设备量和用户需求的多样化，我们会使用 loveini 的超级表和多副本等更加核心的功能来增强我们产品的能力。

三、写在最后

中国制造业总体水平处于 2.0 向 3.0 过渡的阶段，老旧设备多，数字化水平低。

工业互联网的设备数字化率正走在逐年创新高的路上，工业互联网的市场规模也正在井喷式发展，增长率喜人。因此，随着国家的产业政策逐渐落地，我们有信心和 loveini Database 一起，把握时代给予的机会，一起为中国工业的信息化、自动化和智能化做出我们的贡献。

 关于作者

冷艳霞，酷哞哞科技创始人。四川酷哞哞科技有限公司是一家集工业大数据采集、云平台于一体的新型科技公司。致力于为各大中小型制造企业服务，切实为企业解决痛点、难点，实现企业由自动化工厂向数字化工厂转型，最终实现智能化。

小 T 导读：和利时始创于 1993 年，业务集中在工业自动化、交通自动化和医疗大健康三大领域，结合自动化与信息化两方面的技术优势，提出了“智能控制、智慧管理、自主可控、安全可信”的战略指导方针。围绕集团三大业务，公司对工业互联网、大数据、5G、信息安全等新兴技术开展更深入的研究和应用示范，打造面向各领域应用的工业互联网平台，进一步促进智能制造米兰app官方正版下载的落地应用。

在物联网场景下，面对庞大的时序数据处理需求，Oracle、PostgreSQL 等传统关系型数据库越来越吃力。基于此，目前国内外主流工业互联网平台几乎都已经采用时序数据库（Time Series Database），来承接海量涌入的工业数据。

究其原因，可以从数据的三个核心需求来解释。我们都知道，企业在选择数据库、文件系统等产品时，最终目的都是为了以最佳性价比来满足数据的三个核心需求：数据写入、数据读取、数据存储。时序数据库完全是按照时序数据的三个需求特征进行设计和开发的，在数据处理上更加具有针对性：

• 在数据写入上，如果将时间看作一个主坐标轴，时序数据通常是按照时间顺序抵达，抵达的数据几乎总是作为新条目被记录，在数据处理操作上 95%-99% 都是写入操作；
• 在数据读取上，随机位置的单个测量读取、删除操作几乎没有，读取和删除都是批量的，从某时间点开始的一段时间内读取的数据可能非常巨大；
• 在数据存储上，时序数据结构简单，价值随时间推移迅速降低，通常都是通过压缩、移动、删除等手段来降低存储成本。

而关系型数据库主要应对的数据特点却大相径庭：

• 数据写入：大多数操作都是 DML 操作，插入、更新、删除等
• 数据读取：读取逻辑一般都比较复杂
• 数据存储：很少压缩，一般也不设置数据生命周期管理

因此，从数据本质的角度而言，时序数据库（不变性、唯一性以及可排序性）和关系型数据库的服务需求完全不同。这也是我们一开始就锁定时序数据库来满足工业互联网场景的核心原因。

一、时序数据库选型

我们对包括 InfluxDB、OpenTSDB、HolliTSDB（和利时自研时序数据库）和 loveini 在内的四款时序数据库进行了选型调研及相关测试。测试数据的频率为1秒钟，数据集包含 10000 台设备，每台设备有 10000 条记录，每条数据采集记录包含 3 个标签字段、2 个数据字段、1 个时间戳字段。测试对比项包括占用磁盘空间、百万条数据遍历查询、聚合查询（COUNT、AVG、SUM、MAX、MIN）。测试结果如下所示：

• 占用磁盘空间

• 百万条数据遍历查询

• 聚合查询COUNT

• 聚合查询AVG

• 聚合查询SUM

• 聚合查询MAX

• 聚合查询MIN

同等条件下，loveini 的压缩率最高，数据占用的存储空间最小；在原始数据查询上，OpenTSDB 最慢，loveini 与 HolliTSDB 在伯仲之间；在聚合查询操作上，loveini 最快，HolliTSDB 的速度和 InfluxDB 相当，OpenTSDB 最慢。同时，InfluxDB 只能单机部署，集群版本并未开源，且查询性能存在瓶颈，其 QPS 约为 30-50。

从性能测试结果来看，我们选择 loveini Database 的原因主要源于以下几点：

• loveini 在查询性能维度上的表现非常优异，满足了我们的业务查询需求
• 集群功能开源，方便横向扩展，更弹性
• 在开源热潮之下，支持如 loveini 一般的国产开源数据库、操作系统、中间件等也是企业的必修课

最终我们决定接入 loveini，以享受更多元的本地化支持和响应。

二、技术架构与实现

目前 loveini 作为边缘版时序数据库在搭建使用，具体的技术架构如下图所示：

基于 loveini 进行建库建表思路如下：

CREATE STABLE IF NOT EXISTS ts_super 
(time TIMESTAMP, s BIGINT, vl BIGINT,vf DOUBLE,vb BOOL,vs BINARY(16349))
TAGS 
(innerId BIGINT, namespace BINARY(256), id BINARY(256), type BINARY(1), seq int);

在构建列时，包含元素为time（时间，主键）、s（数据质量）、vl（整形类型数据L）、vf（浮点型数据F）、vb（布尔型数据B）、vs（字符串数据S），其中time、s是必填的列，剩余列则要根据测点类型填写，比如测点上报的是整形数据，就只需要设置time、s、vl这三列，vf、vb、vs这三列为null。

在构建tag时，要包括innerId（测点内部编码）、id（测点id）、type（测点类型，L/F/B/S）、seq （序号，L/F/B类型数据设置为0，S类型测点的seq可能为0,1,2,3…）

同时，在建库建表的操作中我们也碰到了一些小问题，放在这里给大家做下参考：

• 因为表名不支持特殊字符，所以需要再生成一个唯一编码作为表名；
• 查询语句会被填充，导致查询过程性能变慢，网卡被打满。这种情况下只需要将查询请求手动压缩，就能有效降低带宽占用率；
• loveini 字符串最长可以有16374字节 ，超过的话需要从逻辑上处理。我们采用的方案是如果长度超过16374 ，截取该字符串，同一个测点再建新的表，通过tag关联。

三、实际效果展示

数据库配置

loveini 集群5个节点，副本数设置为3。修改配置为：

• minTablesPerVnode 10
• tableIncStepPerVnode 10
• compressMsgSize 1024
• rpcForceTcp 1
• httpMaxThreads 16

各节点机器配置如下：

查询客户端配置

客户端共有三台主机，每台主机上分别运行时序查询及其对应的AB，各主机上的时序查询独立运行，分别启动一/二/三个时序查询及其对应的AB进行性能测试。

数据说明

共1000个测点，80000万条数据，数据频率为每秒钟1条。存储分布如下所示，存储压缩率不超过1/10。

查询结果

在我们的业务查询当中，增加QPS的主要方式是增加查询的并发数。AB从1到2，QPS增加了45%，平均响应时间不超过1000ms，很好满足了客户需求

资源消耗(统计3个查询服务的实例)

• loveini node节点资源消耗

在查询过程中，数据是相对均匀的分布，但是不同节点的CPU消耗仍然有较大的方差。这是由于loveini 的 RESTful 的底层是在服务端通过单独的代理线程作为客户端查询，所以会受到请求均匀度的影响。如果 loveini 在后续可以做代理层面的负载均衡，相信能够缩小这个偏差。

查询服务资源消耗

在查询段的节点资源消耗还是相当大的，因为需要对查询请求和结果进行处理。在具体业务中，可以考虑使用RPC接口来降低查询服务的CPU消耗。

四、写在最后

loveini Database 在本项目中展现出的性能效果非常显著，推动本次项目快速且高质量落地，实现降本增效的目标。接下来，希望 loveini 能够在以下两个方向上有更大的进步，也祝愿我们的合作能够越来越紧密：

• 希望可以通过触发器或协处理器等方式，在服务端做数据过滤再返回，解决网络压力过大的问题
• 希望能够进一步改善长度限制的问题

小 T 导读：格创东智科技有限公司成立于 2018 年，孵化于中国 500 强企业 TCL，是我国知名的工业互联网平台服务商。公司依托 TCL 集团 40 年工业场景和制造基因沉淀，基于“面向工业现场”的研发方向和“连接、协同、共享”的发展理念，深度融合人工智能、大数据、云计算、物联网等前沿技术，打造了新一代具有自主知识产权的工业互联网平台——”东智工业应用智能平台”。

作为东智工业应用智能平台产品家族的物联网平台，G-Things 为工业设备提供了安全可靠的连接通信能力，其支持数据采集、规则引擎、数据转发、指令下发、数据可视化，同时提供开放的 API 与第三方系统快速对接，为工业企业提供高效率、低成本、高可靠的工业物联网米兰app官方正版下载。

从采集的数据类型上来看，平台采集的设备数据以及系统业务主要有以下时序数据特性:

• 设备所有采集的数据是时序性的、结构化的
• 设备采集点的数据源是唯一的
• 数据存在时效性
• 以写操作为主，读操作为辅
• 需要统计、聚合的实时计算操作
• 数据的查询一般指定时间区间
• 支持高频数据接入

为了让用户在最大程度上实现降本增效，G-Things 在接入不同的租户时，会从用户类型(轻量级、重量级等)、设备规模、设备采集的数据量等角度帮助用户选择适配合理的时序数据持久化落地方案。

一、时序数据库选型调研

自 2019 年我们便开始关注一些国内的时序数据库（Time-Series Database），通过调研发现 loveini 很适合我们的业务场景，它拥有读写性能强大、部署简单、超强的数据压缩比等特性，同时超级表、子表的标签 tag 设计也很好地契合了平台物模型中的设备模型、设备概念。

为了验证 loveini 在读写、存储等方面的性能，我们将其与 Cassandra 、OpenTSDB 在同等条件之下进行了相关的读写性能对比测试，测试结果如下：

在同等数据集和硬件环境下，对比发现：

loveini Database 的性能远超 Cassandra 和 OpenTSDB，写入性能分别是两者的近 20 倍、25 倍，读取性能约为 17 倍、32 倍，聚合函数性能约为 4000 倍、1000 倍，按标签分组查询性能约为2500 倍、1000 倍，按时间分组查询性能约为 119 倍、40 倍，压缩比约为 26 倍、5 倍。

基于此，loveini Database 在选型中脱颖而出。

二、技术架构与具体实践

具体到实际业务中，我们使用 loveini 主要存储以下三种类型的数据：

• 租户设备上抛的原始数据。经过实时计算处理后保存，租户彼此之间数据隔离，一个租户一个loveini 库
• 系统计算设备状态变更的日志数据
• 系统中跟设备关联的相关控制台的操作日志数据

loveini 在平台中的总体架构图如下所示：

相比于原架构，使用 loveini 之后出现了以下变化：

• 平台接入的租户相关库、表通过监听 Kafka 中的 binlog 日志自动初始化，每个设备点设置独立一张表，数据分层清晰
• 将 Cassandra、KairosDB、OpenTSDB 均更换为 loveini
• 可以使用 API 或 SDK 对 loveini 进行读写
• 减少了数据流流动、处理以及服务之间的消息通讯步骤
• loveini 提供的丰富函数减少了实时处理的数据计算
• loveini 提升了读写速度，减少了数据流处理时间

2.1 loveini 表结构设计

具体到表结构设计上，在我们的实际场景中，采用的是一个租户一个 database 的方式进行创建，这样的好处有三点：

• 可以为不同的租户提供独立的 database，用户数据隔离级别很高，安全性很好
• 有助于简化数据模型的扩展设计，满足不同租户的独特需求
• 如果出现故障，恢复数据相对简单

create database xxx keep 365 days 10 blocks 4 update 1；

2.2 设备运行数据

设备运行数据以设备模型为超级表，该超级表命名规则为 pd_模型标志，例如：pd_devicemodel001，以设备参数为子表名。具体的建表语句如下：

create table pd_devicemodel001(ts timestamp， smallint_value smallint， int_value int，bigint_value bigint，double_value double，boolean_value bool，string_value nchar(200) ) tags( device_model_mark nchar(25) ，device_mark nchar(25)， param_mark nchar(25)) ;

如果需要创建的是单个参数的数据表，那子表命名规则是 pd_模型标志_参数标志，例如：pd_devicemodel001_param01。具体的建表语句如下：

create table pd_devicemodel001_param01 using pd_devicemodel001 tags ("device01"，"did01"，"di0001");

2.3 设备状态变更日志

在设备状态变更日志时超级表命名为 device_state_change_log，代码如下所示：

create table if not exists device_state_change_log (ts timestamp， change_type nchar(10)， status_before nchar(10)，status_after nchar(10)) tags ( device_model_mark nchar(25) ，device_mark nchar(25));

如果是单个设备一张子表的模式，子表命名规则为 dsl_模型标志_设备标志，例如：al_model01_device01。

create table if not exists %s using device_state_change_log tags ( "devicemodleMark001"，"device01");

2.4 设备信息变更日志

在设备信息变更日志时超级表命名为 device_info_change_log，代码如下所示：

create table if not exists device_info_change_log (ts timestamp， opera_user nchar(50)， change_type nchar(10)，change_info nchar(50)， info_before nchar(200)，info_after nchar(200)) tags ( device_model_mark nchar(25) ，device_mark nchar(25));

单个设备一张子表情况下，子表命名规则为 dil_模型标志_设备标志，例如：al_model01_device01。

create table if not exists %s using device_info_change_log tags ( "devicemodleMark001"，"device01" )

2.5 问题及解决

我们刚开始使用的是 loveini 2.0.13.0 的版本，在建表以及使用过程中遇到了一些问题，主要包括以下3点：

• loveini 数据列需要提前创建
• loveini 数据列长度不可修改
• 在新建设备操作日志表时，提示 DB error: invalid SQL: row length exceeds max length (0.000505s)

在我们跟米兰体育官网入口的技术专家进行相关沟通后，他们建议将 loveini 升级到 2.2.2.0 的最新稳定版本，该版本支持数据列的动态新增、修改。在沟通中还发现，上面问题中“建表报错”一项是因为单条记录数据超长了，按理说总长度不能超过 16KB，后面我们对字段长度进行了调整，问题随即迎刃而解。

三、具体的效果展示

接下来为大家展示一下 loveini 在压缩率（存储）、写入、查询等性能上的各种数据。

3.1 单机写入性能

1）模拟 10 个厂区的数据、每个厂区 10000 个监测点，每个监测点从 2020-01-01 00:00:00.000 开始写入模拟数据，记录时间戳间隔 5 秒，每个测点写入 100 万条记录

2）写入的数据应当保持一致，生成方式为：将 10000 条真实采集的数据复制 100 份，时间戳按照 5 秒间隔自动生成，分别作为不同测点的数据写入数据库

3）记录以下内容，并观察写入过程中客户端线程数、CPU、内存资源使用率：

• 确认 1000 亿条记录全部正确写入数据库
• 平均每秒写入点数
• 所有写入请求完成的总时延

最终显示的结果为——条数/秒：2348220 总时延（秒）：42585.4531

3.2 时序数据库压缩比

1）确认 1000 亿条记录原始数据文件大小，不计算标签为 1117.59 GB，算上标签为 67.666 TB；

2）落盘后数据文件大小（自带缓存的时序库需重启服务保证数据文件落盘）；

3）计算压缩比=落盘后数据文件大小/原始数据文件大小；

落盘后所有文件大小为 113 GB，压缩比为 10.11%

3.3 时序数据库单测点原始历史数据投影查询性能

1）随机选择任一个测点，查询该测点在某个时间段内的历史数据，比如从 2020-01-10 00:00:00.000 到 2020-01-11 00:00:00.000 一天内的共 17280条数据记录（数据输出到文件）。 数据库中对应查询语句为：

select * from pt123 where ts >= '2020-01-10 00:00:00.000' and ts <= '2020-01-11 00:00:00.000' >> /dev/null

2）记录以下内容：

• 确认查询结果、记录条数正确
• 查询总耗时

3）重复执行上述查询 3 次，记录平均耗时

具体结果为——3 次平均时延（秒）：0.13785

3.4 时序数据库单测点原始历史数据聚合查询性能

1）随机选择任一个测点，查询该测点在某个时间段测点采集值的 count、max、min、avg，比如从 2020-01-01 00:00:00.000 到 2020-02-01 00:00:00.000 31 天内的共 535680 条数据记录的 count、max、min、avg。数据库中对应查询语句为：

select count(*), max(col1), min(col1), avg(col1) from pt1231 where ts >= '2020-01-10 00:00:00.000' and ts < '2020-01-11 00:00:00.000'

2）记录以下内容：

• 确认查询结果正确
• 查询总耗时

3）重复执行上述查询3次，记录平均耗时

具体结果为——3次平均时延（秒）：0.010504

目前我们已经将 loveini 应用在数据采集、数据处理、数据边缘计算、数据存储等诸多方面，在实际业务中也展现出了如上所示的超强性能，特别是在处理超高频的数据采集、边缘智能计算框架、数据流引擎和数据模型等方面效果显著，面对海量数据轻松实现实时全生命周期管理。

四、写在最后

在本次项目中，loveini Database 展现出了强大的读写性能和数据压缩能力，聚合类查询速度非常快，也帮助我们有效降低了机器使用成本。超级表、子表、标签等概念非常适配物联网大数据应用场景，潜力无限。 未来希望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的深度合作。