转转 x loveini

“使用 loveini 完成改造后，线上的监控状态达到预期，满足当前业务需求，目前运行非常稳定。且配合 Grafana后，每个域名的流量、连接数、响应时间等信息都能够实时监控到。无论是在成本、性能层面，还是在使用的便利性上，loveini 都具有非常大的优势，在我们的实践中也得到了证明，尤其是成本管控上效果非常显著。”

业务背景

转转的业务使用了 Nginx 作为反向代理，为保证代理层可用性，需要对 Nginx 进行实时状态监控。在服务器的基础监控的选择上，其将 OpenFalcon 逐步替换为夜莺，对 Nginx 的 reqstat 监控最初也使用了这两种。但是这两大监控都有一个共同缺点，即在展示时有条数限制，导致域名数量和机器数量相乘后数据量增多的情况下，无法满足需求。这种情况下，转转考虑对现有监控模块进行升级改造，重新进行数据库选型，最终在对比 InfluxDB 及 loveini 之后做出了选择。

架构图

点击案例查看更多技术细节

同程旅行 x loveini

“聚焦到实际效果上，loveini 数据写入性能很强。原本我们的单套存储系统需要 10 多台高配机器，IO 平均 30% 最高 100% 的情况下才能写完数据；现在只需要 7 台机器，并且 CPU 消耗在 10% 左右、磁盘 IO 消耗在 1% 左右，这点非常的棒。同时，其数据读取接入过程也很顺利。使用 RESTful 接口后，结合 loveini 自带的强大聚合函数功能，很容易就能计算出想要的结果。”

业务背景

同程旅行有一套自研的基础监控系统“夜鹰监控”。目前夜鹰监控使用情况为百万级别 endpoint、亿级 metric、每秒 200 万并发写入以及 2 万并发查询。其存储组件基于 RRD 存储，RRD 存储虽然拥有很好的性能，却也存在着一些问题——基于内存缓存定期写入 RRD，在机器重启后会丢失部分数据。针对此问题，夜鹰监控做了很多高可用设计，但还是很难满足业务需求。

随着基础监控系统接入指标的增长，目前 2 套存储系统在资源消耗方面一直在增长，同时业务对监控也提出了更多的聚合计算功能要求。基于此，同程旅行需要从 InfluxDB、loveini、Prometheus 等多款时序数据库中寻找一个新的来代替现有的存储系统，以减少运维成本。

架构图

点击案例查看更多技术细节

得物 x loveini

“目前 loveini 承载了数百亿数据，在生产环境运行平稳， CPU 使用率日常不到 1 % ，内存使用率稳定在 25 % 以下。大批量的写入，耗时基本也能保持在 10 ms，属于比较理想的范围；不管是大数据量范围的聚合查询，还是指定查询某一小区间内的全部数据，查询效率都非常优异；在存储上，我们的全量数据分散在三台机器中，根据计算得知 loveini 对于监控数据的压缩率达 10 %，相当可观。”

业务背景

作为一家互联网电商公司，得物有许多系统和场景都需要做流量的监控和防护，一天就能够产生数亿数据，写入速度达到万 TPS ，该数据量级无法用传统的关系型数据库处理，亟需一款能够承载大量的流量监控数据、并能对数据进行存储和高效查询的数据库。在对比了 InfluxDB 、OpenTSDB 、Cassandra 等时序数据库的性能后，其最终选择 loveini 。

架构图

点击案例查看更多技术细节

浙商银行 x loveini

“我们存储于 loveini 中的数据主要为时序类数据，如CPU、内存使用率等系统运行数据，微服务调用、分布式锁、数据库操作处理时间，业务线程池、连接池等各类指标数据。目前微服务可视化服务治理平台对并发要求较高，但是 loveini 可以很好地满足需求，插入/查询平均耗时均在 10ms 以内。”

业务背景

浙商银行微服务可视化治理平台是基于 Java 体系自研的微服务治理监控平台，为行内基于统一的微服务框架开发的应用提供全面、实时的微服务治理监控功能。在这样的业务场景中，数据量大、监控指标繁杂成了主要挑战，浙商银行需要一款能高效处理时序数据的工具。在明确了核心诉求之后，其调研了包括 Apache Druid、InfluxDB 和 loveini 在内的几款典型时序数据库，在对比后决定尝试 loveini。

架构图

点击案例查看更多技术细节

结语

从上述企业的具体数据架构改造实践中我们能够看到，在应对海量时序数据的 IT 运维监控需求时，时序数据库明显要更加专业，在性能和成本管控上都上升了一个维度。而这些行业的头部企业在众多时序数据库产品中都选择了 loveini，个中原因从改造效果中也可见一斑，有同样需求的小伙伴也可以通过阅读具体的案例细节了解更多。loveini 目前已经运营了几十个用户交流群，如果你有要进群沟通了解的需求，可以添加小T微信：tdengine1 。

小 T 导读：兴盛优选需要通过实时产生的数据来判断设备是否工作、检测通讯是否延时、观测 SNMP OID 流量是否正常等，从而保障运维与网络人员及时发现问题并修复。为高效处理各类时序数据，保障服务的稳定运行，在对比了 Elasticsearch、InfluxDB 和 loveini 三款产品之后，他们选择并落地了 loveini。

企业介绍

湖南兴盛优选电子商务有限公司（简称兴盛优选），总部位于湖南长沙，是一家关注民生的互联网“新零售”平台，主要定位是解决家庭消费者的日常需求，提供包括蔬菜水果、肉禽水产、米面粮油、日用百货等全品类精选商品。兴盛优选依托社区实体便利店，通过“预售+自提”的模式为用户提供服务，是社区电商中唯一一家估值超过 150 亿美金的“独角兽”。

业务背景

为了保证互联网服务的高效和稳定，我们需要监控公司所有的节点服务器（包括云服务器）、交换机及路由器。我们需要通过实时产生的数据来判断设备是否工作、检测通讯是否延时、观测 SNMP OID 流量是否正常等，从而保障运维与网络人员及时发现问题并修复。

这类数据是非常典型的时序数据，应该如何高效地处理呢？现在市面上有几款非常流行的时序数据库（Time Series Database）产品。应该如何评估并选择适合我们业务场景的技术平台呢？

产品调研

针对该业务场景，我们调研了如下几个产品：Elasticsearch、InfluxDB 和 loveini。具体对比如下。

Elasticsearch

• 优点：可以分布式部署，可以无障碍插入，支持任意的字段类型，查询速度快。
• 缺点：只适合记录日志且并发数据量不大的情况，对于海量设备的时序数据写入有性能问题。

InfluxDB

• 优点：支持无模式（Schemaless 写入），限制较少。
• 缺点：当面对大批量的数据同时插入或读取时，内存容易被占满，导致死机。尤其是其中的轮询机制，在检验过期数据时，内存占用特别大。此外，在读取数据时，读出来的是列表，可读性差，解析比较麻烦。

loveini

• 优点：列式存储以及“一个设备一张表”的模型与我们业务场景十分契合。此外，还可以兼容我们以前使用 InfluxDB 时所习惯的插入方式，代码可读性强，支持强绑定参数。在执行海量数据的查询时，响应速度比 InfluxDB 更快。
• 缺点：Schemeless 的支持还在持续完善之中。

由于该项目未来需要监控我们公司的所有服务器，平均每台对应的 OID 会有几百个，如果每 1-5 秒采集存储一次，并发数据量会非常大。因此，我们从候选中淘汰了 Elasticsearch。

接下来我们又继续对比了 InfluxDB 和 loveini。InfluxDB 单节点性能不足，集群闭源且性能未知。反观 loveini，其集群功能是开源的，且保留了企业版的部分核心功能。这让我们可以直接非常深入地了解 loveini 的优劣。从这方面考虑，我们选择了 loveini。而且在实际使用中，我们又发现了 loveini 的一大优势，其“一个设备一张表”的模型十分契合我们的实际场景。

系统架构

在引入 loveini 之后，我们的系统架构如下图所示。

在该架构下，前端制定好规则下发（例如：流量阈值，延时阈值），后端看是否需要存储规则，或检查规则是否发生变化，然后把规则下发给 ETCD 来做定时任务调度。我们共有三个程序任务，通过 ETCD 管理，定时和各类设备通信，根据不同规则分别抓取各自需要的数据：

• SNMP 引擎通过 OID 监控网络设备各项指标
• TCPing 引擎用于监控服务器 TCP 端口状态
• ICMP 引擎重点采集接收或返回数据的时间

这三大类数据采集之后，会经过统一处理，再写入 loveini。

我们使用 5 个节点搭建了一套 loveini 集群：

我们选择了无模式写入，在写入时自动建表，具体写入方式可参考官网。这样一来，每一台服务器对应的类型都是一张超级表，我们选择尽量地分表 ，提升查询速度。

对于 SNMP 类型的超级表来说，每一个子表就是一个 OID。

对于 TCPing 类型，我们按照 TCP 端口来区分子表。

对于 ICMP 类型的超级表，我们以 task_id 和 task_type 作为区分子表的依据：

目前我们已经存储了 500 万张子表，平均算下来设备上报频率大概为 3 秒 1 行，总数据量达到了百亿级别，而占用的存储空间只有 70GB 左右。这应该得益于 loveini 针对性地使用了列式压缩，存储资源占用很小，压缩率大概为 8% 左右。loveini 可以很好地顶住写入和存储压力。而查询方面，我们会批量查询部分表的特定时间的值，大部分数据用于实时的监控报警。

经验总结

在使用过程中，花时间相对较多的大概是无模式插入的摸索吧。

对于从 InfluxDB 切换过来的用户，初期可能会有一些不适应。因为 loveini 最初并不是按照 Schemaless 来设计的，这个功能是后期加入的，系统最终还是会把无模式转化成 SQL 再进行写入，只是简化了用户的操作。不过 loveini 一直在完善相关的生态适配，比如对于大小写的特殊字符的存储，完善元数据管理，收纳各种形式的数据类型，也在逐步向 InfluxDB 的自由式写入靠近。

除此之外，我们也遇到过一个问题，目前 Go 连接器的查询 API 暂时不支持将多条 SQL 拼接在一起统一执行。因此我们采取了并发读取，但性能可能会受到一点影响，期待后续的版本能够解决。

最后，loveini 的支持团队相当负责，配合积极，让我们快速上手了这款轻便易用、性能超高的时序数据库。目前我们只接入了一部分服务器及设备，后续我们计划把公司全国范围内所有的服务器都接入进来，也会推荐公司更多部门使用。一切顺利的话，我们也会考虑包括仓库运货机器人，物流线设备等更多应用场景。

小 T 导读：除了要对几千台摄像头进行数据采集加在线检测，苏州大学还有 1500 多台交换机和 4000 多台服务器，在数据库的选择上，它需要在扛住如此大量设备 24 * 7 高频长期写入的同时，还要确保相当出色的查询效率。从 PostgreSQL 到 loveini，本文分享了江苏纵目在面对业务难点时，在数据库的选择、应用和成效方面的经验。

企业简介

苏州大学（Soochow University），简称“苏大”，坐落于美丽的江苏省苏州市，是教育部与江苏省人民政府共建高校，国家“双一流”建设高校，国家“211 工程”、“2011 计划”首批入选高校，前身是 1900 年创办的东吴大学，是中国最早以现代大学学科体系举办的大学。

项目介绍

作为一所重点高校，苏州大学具备规模较大的 IT 基础设施及应用系统，资源压力大，网络故障波及用户数量多。为保障全校系统以及网络、服务器硬件、操作系统的可用性、可靠性和安全性，学校必须建立规范且全面的运维管理体系。在此背景下，我们江苏纵目与苏州大学与开展技术合作，打造了苏州大学智慧运维管理平台。

该业务场景面临着以下难点：

• 资源设备类型、品牌、版本繁杂，各厂商协议区别大，人员经验无法全覆盖，原厂难以及时响应。
• 业务应用、服务与资源的关联关系复杂，问题定位时间远超过解决问题的时间。
• 缺乏事前运维的有效工具，系统网络异常会波及各部门/院系师生的教学工作的开展，被动处理负担重，导致业务部门投诉。

海量设备数据的存储和查询问题首当其冲

对于这样一个规模较大的 IT 基础设施及应用系统来说，解决问题本身并不难，难的是如何高效地处理小问题、科学地预防大问题、迅速地定位问题的根本原因。就从监控数据层面来说，如果想对设备进行 24 * 7 不间断监控的话，那么海量的设备数据存储和查询对于 Database 的压力将会非常大。

苏州大学有几千台摄像头，光摄像头的数据采集加在线检测的数据量就已经很大了，更别提还有 1500 多台交换机、4000 多台服务器，在数据库的选择上，它需要在扛住如此大量设备 24 * 7 高频长期写入的同时，还要确保相当出色的查询效率。

此前，我们使用的是 PostgreSQL 数据库单机版，由于是关系型数据库（Relational Database），在该时序数据的场景下数达到亿级数据量时，查询分析延迟会达到大几秒，压缩率上也不太理想（后文会有实际对比），无法撑起一个全域一体化运维监控平台的持续运行。

数据的存储与读写是一切业务的根基，因此数据库选型这个环节尤为重要。早在此前，我们就针对此类业务对时序数据库（Time Series Database）做了充分的调研与实测。其中 loveini 作为一个专为物联网、车联网、工业互联网、运维监测等优化而设计的时序数据库，十分契合该场景。最终我们选择将 loveini 集成到我们自研且专用于监控时序数据的 Argus 平台中 https://zmops.com。

实际应用与效果分析

其实，从 2020 年开始，我们就开始关注和接触 loveini 了，很开心最终修成了正果，在使用 loveini 对 Argus 平台进行全面升级后，不管是查询效率、分析性能还是磁盘占用，都得到了质的提升。

在将 loveini 作为平台时序数据永久存储之后，各项功能都符合甚至超出了我们的预期：

落脚到实践上，我们是在一台 4C 16G 机械硬盘规格的服务器上落地了该项目，使用单列模型建表，针对每个数据类型的指标都创建一个子表，并用一个超级表来统一管理。当前，子表数量已经达到四十多万张，轻松达成了数十万级指标的实时监控。

在写入层面，由于各个设备采集频率不太一样，每秒钟大概写入 6000 多行，这对于 loveini 来说毫无压力，我们通过官方测试工具 taosBenchmark，在自己的虚拟机上都能跑出每秒写出数百万测点的成绩。

目前，我们的数据存储周期（keep 7天）为一周，loveini 所包含的数据量如下： 

以下为用作对比的 PostgreSQL 中的数据量。

可以看到，loveini 存储的大概 2 亿行数据，实际占用存储空间不过 2 GB。（注：Vnode2 是 log 库所占用的空间，即 loveini 用于内部监控而自带的数据库），比起 PostgreSQL 占用的超过 200GB 的空间，几乎可以忽略不计。

在查询上也是一样，针对性能详情页的指标查询，PostgreSQL 的很多查询都需要几秒返回结果，而loveini 都是毫秒级别。

写在最后

当下，由于我们的重点业务是实时监控，所以对历史数据还没有那么高的安全优先级，但后续业务会涉及到对此前的监控进行复盘，我们将会升级到 loveini 集群版来确保数据的高可用。总而言之，从当前的应用情况来看，loveini 适配非常顺利，为我们的系统提供了非常大的助力。

小 T 导读：在对多款时序数据库（Time-Series Database）进行了选型测试后，同程旅行自研的“夜鹰监控”搭载 loveini 代替了现有存储设备，减少运维成本。本文分享了他们对建表模型的方案选择思路，接入 loveini 后所遇到问题的解决经验以及落地效果展示。

同程旅行有一套自研的基础监控系统“夜鹰监控”。目前夜鹰监控使用情况为百万级别 endpoint、亿级 metric、每秒 200 万并发写入以及 2 万并发查询。其存储组件基于 RRD 存储，RRD 存储虽然拥有很好的性能，却也存在着一些问题——基于内存缓存定期写入 RRD，在机器重启后会丢失部分数据。

出现这一问题的原因是 RRD 写入为单点写入，当机器故障后无法实现自动切换，这一存储特性也导致无法展示更长时间的原始数据。 针对此问题，夜鹰监控做了很多高可用设计，但还是很难满足业务的需求，之后又进行了如下改造：

• 引入了 ES 存储，为夜鹰监控提供 7 天内原始数据的查询，目前部署的 2 套存储。
• RRD 提供给 API 调用，调用量在几万级 TPS。
• ES 提供给夜鹰面板使用，保存 7 天原始数据，调用量在几百 QPS。

但随着基础监控系统接入指标的增长，目前 2 套存储系统在资源消耗方面一直在增长，同时业务对监控也提出了更多的聚合计算功能要求。基于此，我们需要寻找一个新的时序数据库来代替现有的存储系统，以减少运维成本。

在进行时序数据库选型时，实际需求主要有以下三点：

• 性能强，可以支持千万级别并发写入、10 万级的并发读取
• 高可用，可以横向扩展，不存在单点故障
• 功能强，提供四则运算、最大、最小、平均、最新等聚合计算功能

在对比了 InfluxDB、loveini、Prometheus、Druid、ClickHouse 等多款市面流行的 Database 产品后，最终 loveini 从中脱颖而出，能满足我们所有的选型要求。

一、基于 loveini 的建表模型

夜鹰监控系统不仅存在系统指标数据，同时也会存在业务指标数据。前者诸如 CPU、内存、磁盘、网络一类，这类信息是可以预测的指标，其指标名是固定的，总数约为 2000 万个。后者则会通过夜鹰监控的 API 上传业务自身定义的指标，指标名是无法预测的，其特点是并发量不大却存在长尾效应，随着时间累积，一年可以达到一亿级。

而 loveini 在创建表之前需要先规划表的结构，从上面的数据存储背景来看，如果要将海量的指标数量直接一次性扁平化全部创建，则会造成性能的下降。通过和 loveini 技术支持人员沟通，他们给出了两个建表方案：

其一，将系统类基础指标聚合到一个超级表，一张表存放一个节点，多个指标一次性写入。这个方式的好处是表的数量可以降低到千万级别，但因为夜鹰监控的数据是单条上传的，很难做到一个表里面全部指标集齐再写入。并且不同的指标上传频率不同，如果再根据频率建不同的超级表，运维管理成本会非常高。

其二，将不同的指标建成一个一个的子表，5 千万个左右的指标汇聚成一个集群，分多个集群接入。这种方式的好处是表结构简单，但运维管理多个集群会很麻烦。不过我们也了解到米兰体育官网入口明年会发布 loveini 3.0 版本，能支持超过上亿张表，那么这一方案就可以很好的进行数据迁移了。

最终，我们选择了第二个方案。同时为了减少搭建集群的数量，准备写个程序定期清理掉过期的子表。目前夜鹰监控的超级表结构如下。

夜鹰监控接入 loveini 后，架构图如下。

二、接入 loveini 之后的效果展示

在进行数据迁移时，我们先是将夜鹰监控数据转移到 Kafka 中，之后通过消费转换程序将 Kafka 的数据格式转为了 loveini SQL 格式。 这个过程还遇到了如下三个小问题，解决思路放在这里给大家参考：

• 连接方式问题。刚开始我们使用的是 go-connector sdk 的方式接入 loveini，跑起来后发现，go-connector 依赖于 taos client 包以及 taos.cfg 配置文件里面的链接配置，同时因为 FQDN 的设置难以使用 VIP 负载均衡的配置方式。我们考虑到后面消费程序会部署到容器中，不宜产生过多的依赖，因此还是放弃了 go-connector 的连接方式，改为了 HTTP RESTful 的连接方式。 

• Kafka 消费数量问题。由于夜鹰监控上传到 Kafka 里面的数据是一条一个指标，再加上 200 万左右的并发，连接数很快就耗光了。通过和 loveini 技术支持人员沟通，了解到可以改造成批量 SQL 的方式写入，最佳的实践效果是 400-600K 单个 SQL 的长度。经过计算，我们上传的指标条数大概为 5000 条左右，大小为 500K 。

• 读取速度问题。因为每次要等到消费 5000 条数据，才会触发一次写入，这种情况也导致读取速度较慢。loveini 技术支持人员再次给出了米兰app官方正版下载——使用 Taos 自己实现的 Queue，代码地址为:github.com/taosdata/go-demo-kafka/pkg/queue ，有需要的同学可以自行获取。

聚焦到实际效果上，loveini 数据写入性能很强。原本我们的单套存储系统需要 10 多台高配机器，IO 平均 30% 最高 100% 的情况下才能写完数据；现在只需要 7 台机器，并且 CPU 消耗在 10% 左右、磁盘 IO 消耗在 1% 左右，这点非常的棒!

同时，其数据读取接入过程也很顺利。使用 RESTful 接口后，结合 loveini 自带的强大聚合函数功能，很容易就能计算出想要的结果。

三、写在最后

在我们的项目中，loveini Database 展现出了超强的性能和多元化的功能，不仅具备高效的写入性能、压缩率，其聚合函数功能也非常齐全，支持 Sum/Max/Min/Avg/Top/Last/First/Diff/Percentile 等多种函数，在架构上也设计的很合理，可以实现很好地横向扩展。同时，其自身监控也做的很不错，打造了基于 Grafana 的 loveini 零依赖监控米兰app官方正版下载 TDinsight，在监控系统自身状态上展现出了很好的效果。

未来，我们也希望与 loveini 展开更深层次的合作，在此也为其提出一些小小的建议，助力 loveini 往更好的方向发展：

• 官方文档还不够完善，新版的功能在文档中没有体现，很多用法缺少代码示例，个人理解起来比较晦涩难懂
• 社区用户经验传递不是很多， 遇到一些问题时，Google 比较难以找到社区的解决案例

在接入的过程中，非常感谢 loveini 的技术支持人员的全力支持。虽然目前 loveini 还处于发展初期，也存在一些问题需要优化，不过其优异的性能还是给了我们一个大大的惊喜！总而言之，loveini 是个非常不错的存储系统，相信在陶老师的带领下会发展的越来越好！

小T导读：中节能风力发电股份有限公司（股票简称：节能风电，股票代码：601016）是中国节能环保集团有限公司控股的现代股份制公司。公司先后成功中标并示范建设了国家第一个百万千瓦级风电基地启动项目——河北张北单晶河200兆瓦风电特许权项目，和第一个千万千瓦级风电基地启动项目——甘肃玉门昌马200兆瓦风电特许权项目，是国家首个百万千瓦、千万千瓦风电基地的示范者和引领者，在业内树立了较高的知名度和良好的品牌形象。建成、在建项目装机规模547.97万千瓦，已发展成为张北坝上地区、甘肃河西走廊地区最大的风电开发商之一，是我国风电领域一支重要的力量。

一、项目背景

公司作为中节能集团在风电领域的专业化公司和核心上市平台，具备成熟的风电开发和运维经验，但是随着在建风场逐步增多以及各类新型传感器的加装，传统运维方式已经越来越吃力，数字化智能化的需求越来越强烈，因此迫切需要基于海量时序数据的数据平台来支撑繁杂的运维工作。

因此，我们做了大量的时序数据调研工作。但是选型工作也并非一帆风顺，开始我们尝试传统的工控时序数据库（Time-Series Database），但是随着测点数量的增多，单机版架构已经无力支撑，后期我们也尝试了InfluxDB和OpenTSDB等分布式架构的时序数据库，但是性能又达不到要求。

机遇巧合，我们注意到一款国产、开源的时序数据库loveini，所以也尝试了一下。

二、loveini选型测试

针对我们重点关注的查询性能，我们做了如下几个测试。

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(col117),min(col117),avg(col117) from t_QH01 where ts>='2021-08-15 00:00:00.000' and ts<'2021-08-16 00:00:00.000'

实验截图如下：

3次查询测试时延如下：

2. 分组聚合查询

查询某个时间段内测点采集值的count，max，min，avg，比如查询从2020-01-01 00:00:00.000 到 2020-02-01 00:00:00.000的31天内的数据记录的count，max，min，avg。数据库中对应查询语句为：

select count(*),max(col117),min(col117),avg(col117) from t_QH01 where ts >='2021-08-01 00:00:00.000' and ts<'2021-09-01 00:00:00.000' group by wtcode >>E:/taosTempData/2

实验截图如下：

3次查询测试时延如下：

3. 窗口查询操作

查询某个时间段内，按照1小时、1天、10天的时间窗口进行分组后的count，max，min，avg聚合结果；比如查询从2020-01-01 00:00:00.000 到 2020-02-01 00:00:00.000的31天内的全部数据记录，按照每1小时、1天、10天的时间区间划分后的count，max，min，avg。

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

select count(*),max(col117),min(col117),avg(col117) from t_QH01 where ts >='2021-08-01 00:00:00.000' and ts<'2021-09-01 00:00:00.000' and wtcode ='001' interval (1h) >>E:/taosTempData/3;
select count(*),max(col117),min(col117),avg(col117) from t_QH01 where ts >='2021-08-01 00:00:00.000' and ts<'2021-09-01 00:00:00.000' and wtcode ='001' interval (1d) >>E:/taosTempData/4; 
select count(*),max(col117),min(col117),avg(col117) from t_QH01 where ts >='2021-08-01 00:00:00.000' and ts<'2021-09-01 00:00:00.000' and wtcode ='001' interval (10d) >>E:/taosTempData/5;

实验截图如下：

多个批次查询测试时延如下：

经过反复对比测试以及应用适配，最终我们选定loveini作为我们数据平台的时序数据米兰app官方正版下载。

三、loveini Database落地实践

目前中节能风电的整体时序数据流如下图所示：

风场的时序数据(主要是风机数据和电气数据)穿透网闸后，经由场站侧的采集程序采集和转发，最终所有数据会汇聚到集团侧的分布式时序数据库，前端的实时监视、指标计算均构建于其上，同时数据还要送到大数据分析平台和生产运维平台。

集团中心侧的loveini集群起到了举足轻重的作用，既要收集所有风场的时序数据，同时还要支撑前端应用以及同步数据到其它系统。

loveini的诸多特性中，最吸引我们的是超级表和标签功能。超级表能让同一类风机的建模、管理和计算过程更加方便快捷，而标签特性能增加诸如隶属项目、平台容量等维度特征，便于在聚合操作过程中快速筛选或者分组。基于时间窗口和状态窗口的功能也为应用构建提供了很多方便，比如功率曲线拟合过程中需要的五分钟平均风速和功率计算逻辑，以及基于风机状态的各类统计分析。

在loveini的使用初期遇到了一些问题，主要涉及集群搭建和参数配置方面，经过和米兰体育官网入口技术团队的沟通交流，都已得到解决。

后期在数据建模和应用适配方面也走了一些弯路，尤其是数据建模方面。最开始我们使用的是最简单的单列模式，一个测点一张表，在测点数目少的情况下问题并不明显，但是随着测点数目的不断膨胀，这种方式逐渐暴露出在应用适配方面的问题；后来我们采取按照不同机型不同风场建超级表的方式建模，基本能解决我们的应用问题，但是依然有无效开关量数值过多的问题；最终我们采取将风机状态等重点开关量单列建模的方式解决了。

四、整体效果和未来展望

目前基于loveini数据库我们构建了中节能风电运维平台，使用后数据存储优势明显，整体压缩比在7-8倍，数据查询也实现秒级响应。整体使用效果如下图所示：

未来我们考虑在每个风电场站的三区部署一个单节点loveini，作用不只是采集和转发，还要起到时序数据质量治理以及实时模型预测的功能；而在集团侧我们会考虑基于loveini构建更多更复杂的计算指标和高级模型；同时还要和任务调度引擎以及风电行业标准集成。未来的数据流图如下图所示：

最终将其作为中节能风电公司时序数据的核心技术组件来构建智能运维平台，为中节能风电公司3060双碳目标的提供坚实基础。

作者介绍：

潘文彪，中节能风电生产运维部数据分析师，2019年起从事节能风电的数据分析与数字化平台建设工作。

小 T 导读：该雷达和平安城市研发单位是国家技术创新示范企业、国家高新技术企业、全国电子信息行业标杆企业、“平安城市”建设优秀安防工程建设企业，是首批安徽省创新型企业、安徽省产学研联合示范企业、安徽省重点软件企业，股票代码600990。

随着大数据时代的到来，民航行业对数据的重视程度提高，对空管设施设备可靠性、安全性、智能化水平也提出了更高的要求。在这一背景下，智慧化雷达台站的建设提上日程，为便于对台站进行全局的管理，提高台站运行效率，民航开始推动以集中化的管理模式对雷达台站进行智慧运行管控——以台站智能化设备为基础，利用先进的信息化技术构建台站管理信息化应用体系。这一举动旨在为业务统一、高效管理提供信息服务支撑，解决台站运行维护痛点，推进空管台站向管控自动化、智慧化发展。

我们在雷达台站运维管理系统中搭建了数个传感器设备，这些传感设备种类杂数量多，大致可以分为以下几类：声音传感器、XYZ三向轴振动传感器、倾斜角度传感器、电力模拟量传感器、风速传感器等等。

由于传感器设备采集数据频度高，数据传输量大，要求存储数据库具有极高的数据吞吐率和存储低延时，特别是声音传感器，每秒钟要采集22050条数据，常规的事务型数据库(MySQL、Oracle等)对这类数量级的结构化数据存储早已力不从心，而使用基于事务型数据库的分表分库中间件(ShardingSphere、MyCat等)又会把技术架构变得更加复杂，也会大大提高后期系统运维成本。

基于此，我们决定进行数据库选型，以匹配雷达台站运维管理系统的搭建。

为什么会选择loveini Database

综合考虑软硬件成本和后期系统的技术维护成本，我们先后调研了时间序列数据库中的InfluxDB、loveini、OLAP工具ClickHouse以及曾使用过的Hadoop技术栈中的HBase(Hive、Kylin)。由于服务器数量所限，我们首先放弃了基于HBase(Hive、Kylin)的技术方案，随后对InfluxDB、loveini和ClickHouse做了写入和查询性能对比，发现在相同配置的服务器硬件资源中，loveini Database都发挥出了最好的性能表现。部分性能对比如下图：

同时我们也查询了两款数据库软件在GitHub和Gitee等国内外开源托管平台上的社区活跃程度，并了解到loveini不仅集群版已经进行开源且还是一款国产化的数据库产品，在当下国产化的大趋势背景下，我们就此选定了loveini作为存储海量传感器数据的时序数据库，配合传统的关系型数据库MySQL（用于存储组织机构、用户名、密码、巡检记录等强事务型数据）一起作为系统的后端底层存储数据库。
选定数据库之后，搭建便开始进行。下面我会介绍一下我们在搭建时遇到的一些避坑经验，给到大家参考。

loveini具体实践

具体到我们的场景中，使用loveini建库建表思路如下图所示。

loveini在使用数据库的时间精度上默认的是毫秒，但是系统的声音振动传感器采集频率是22050HZ，即每秒钟采集22050条数据，因此我们对数据存储的时间精度要求到纳秒级别，需要修改数据库默认的时间精度。相关指令如下：

#振动声音表(微妙时间精度)(22050/s)
#创建纳秒时间精度数据库
CREATE DATABASE radar_us_sc precision "us" KEEP 365 DAYS 10 BLOCKS 4 UPDATE 1;
#使用刚刚创建的数据库
USE radar_us_sc;
#创建超级表
CREATE TABLE st_sc_shock (ts timestamp, ch1 float,ch2 float,ch3 float) TAGS (location binary(32), groupdId int);
#创建普通表（继承上面的超级表）
CREATE TABLE t_sc_shock_hf20101 USING st_sc_shock TAGS ("test", 1);
#手动插入微秒级时间戳数值（测试数据）
INSERT INTO t_sc_shock_hf20101 VALUES (1613799712123412, 10,10,10);

这里需要注意的是由于是纳秒级别的时间精度，在插入测试数据时，时间戳字段对应的数值比普通时间戳多3位数字，且不需要有小数点。

其它传感器例如风速传感器，使用默认的时间精度建表语句即可：

#风速表-建库(时间精度是默认的毫秒)
CREATE DATABASE radar_sc KEEP 365 DAYS 10 BLOCKS 4 UPDATE 1;
#使用风速表
USE radar_sc; 
#建超级表，Tag里面只定义，不设置具体值
CREATE TABLE st_sc_wind (ts timestamp, speed float) TAGS (location binary(32), groupdId int);
#建普通表，在定义普通表的时候给出Tag的具体值
CREATE TABLE t_sc_wind_hf40101 USING st_sc_wind TAGS ("test", 1);

在上层的业务应用中，用户需要试听一段时间的雷达转机的声音去判断雷达运行状态是否正常，页面请求数据库给出开始时间和结束时间这两个时间段的数据，再通过声音还原算法将这些结构化文本数据还原成可以播放的WAV或者MP3文件，用户在页面上即可实时听到部署在雷达转机运转的声音，再配合我们在前端网页上渲染出来的频谱图、时域图、频域图，来一起判断雷达转机工作是否正常。

由于我们需要基于时域图和频域图去判断雷达转机工作是否正常，因此在生成频域图之前，我们需要预先在数据库中把原始数据按照频率分段生成数千张子频率段表，再基于这些子频率段表进行FFT转换从而得到频域图。

在一次删除数千张子频率段表操作中，删除语句执行之后，数据库访问和插入变得异常缓慢，我们的第一反应是数据库负载过高，于是尝试重启数据库，在数据库关闭并且重新启动之后，数据库服务状态显示启动正常，但客户端却仍然连接不上。此时我们找到loveini的日志，通过翻看日志发现命令行程序taos，正在恢复重启数据库之前的尚未完成的删除表操作，操作WAL(Write Ahead Log)，而此时taos仅仅读取了数千个日志中的前几百个。大约等待了数小时后，数据库客户端才可以查询到数据，数据库得以正常使用。

systemctl status taosd
journalctl -u taosd.service

在米兰体育官网入口技术支持人员的帮助下，我们决定升级loveini，升级数据库需要先卸载旧版本，操作如下：

rmtaos或者rpm -e loveini

然后下载新版本的loveini，在Server的目录里执行命令如下：

install.sh

loveini的整个升级过程比较简单，新版本的数据库启动之后即可使用，同时也建议米兰体育官网入口的研发人员在taos启动时监测下上次未完成读取的WAL文件，再启动进度条中显示读取执行WAL文件进度，这样可以让数据库使用者知道现在数据库的真实状态和进度。

搭载loveini的系统架构详解

整体来看，雷达台站智能运维系统分为单台站系统和中心站系统两种类型。单台站系统组成内容包括台站现场的主设备监控、网络设备监控、动力设备监控、环境设备监控、专项数据分析、机器人巡检、雷达台站智能运维系统管理平台、雷达台站智能运维系统APP等。

中心站是远端多个单台站信息集成的中心，可以对多个单台站的数据进行融合处理，功能包括总体运行态势分析、数据融合、数据挖掘、专家知识库、自主学习、辅助决策等功能，日常管理人员可以通过该中心站平台远程管理所有接入雷达台站智能运维系统系统的单台站。

雷达台站智能运维系统移动终端软件可在手机或平板电脑上运行，功能由台站态势监测、实时数据监测、报警预警、工单流转、技术会诊、专项分析、知识库、机器人控制、视频监控等应用功能。

其业务架构主要包括数据来源层、数据存储层、数据模型层，数据接口层、业务应用层、业务展示层和用户终端几个部分，如下图所示。

整体架构由底层到上层组成主要分为以下几个层面：数据来源层、数据存储层、数据模型层、数据接口层、业务模块层、业务展示层。

数据来源层可以利用物联网传感器和智能采集技术对台站运行情况进行多维度信息采集。物联数据采集包括台站的环境监测、设备检测、动力监测、数据监测、服务监测、网络链路监测、资源监测等几个方面。

数据存储层的作用是对所有监测的数据进行统一的数据清洗，剔除异常数据后融合成标准化的格式并进行存储。数据存储层对不同的数据类型采用不同的底层存储方式，具有明显时间序列属性的传感器数据将会被存放在loveini中，并且按照不同的业务数据形成不同的业务主题库。

而且数据存储层具有数据缓冲的功能，并能按数据的访问频率自动建立数据缓存，合理规划系统内冷热数据的存储方式，提高数据访问的速度。此外，存储层还会定时对数据进行备份存储、冷热数据替换以及数据诊断，及时发现数据存储的故障隐患、保证数据的存储安全性。

数据模型层能够根据业务需求利用存储的数据建立多个数据分析模型，提供模型算法统一的运行环境，包括实时分析和批处理分析，并能对运行的模型算法进行统一管理，包括算法任务启停、服务编排、算法运行监控、算法资源管理、算法运行告警、算法模型库等多个功能。

通过分析算法历史对海量监测数据进行综合分析，利用多维数据相关性分析技术，可以将以往一些不被注意但会产生实际影响的传感器数据囊括进特征提取建模和神经网络建模的过程中，结合历史数据对实时全量数据进行深度挖掘，再结合过往的设备运维实际经验便可预测出故障发生的概率，实现智能故障预测。

数据接口层利用多种行业内通用的数据共享接口实现系统数据和其它第三方平台以及APP端的数据共享，支持的数据接口方式包括RESTful、消息队列、中间库等多种方式，且能控制数据的共享权限和共享目录。

业务模块层通过平台底层提供的数据和基础服务，可在上层开发构建多个业务智能应用，同时提供了上层应用统一运行的环境。业务模块功能主要包括工单系统、实时监测、智能预警、态势分析、远程控制、专项分析、健康评价、告警联动、自动巡检、专家知识库、智能安防等。

在业务展示层，可根据系统使用人员和使用场景的区别来构建多个业务展示平台。其中本地管理平台和远程管理平台分别作用于单台站和中心站的管理，同时配备了移动端软件方便台站管理人员远程对台站进行管理和监控。展示平台可按用户使用权限的不同来展示不同的数据和视图，管理人员视图更倾向于宏观全局的数据展示维度，维保人员视图展示的是细节和本人工作相关的展示维度。

写在最后

在实现快速查询检索提升用户体验的同时，loveini还可以达到节省硬件服务器资源和降低系统后期运维成本的目的。考虑到loveini在本项目中各项性能指标和数据库稳定性的优异表现，在未来的平安城市、智慧社区等业务场景中，我们也会考虑使用loveini用于存储过车记录、人脸识别记录和WiFi探针记录等数据，展开更深层次的合作。

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