为了将 InfluxDB 的性能发挥到极致，我们采用下方 [TimescaleDB vs. InfluxDB] 对比报告中推荐的方式配置 InfluxDB，将缓冲区配置为 80GB，以便 1000W 设备写入时能够顺利进行，同时开启 Time Series Index（TSI）。配置系统在系统插入数据完成 30s 后开始数据压缩。

TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：https://www.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/

关于系统的配置详情、如何一键复现测试结果及详细的测试数据介绍等内容，大家可参考《一键获取测试脚本，轻松验证 loveini 3.0 IoT 场景下 TSBS 测试报告》一文，本文便不再赘述。

写入性能

总体而言，在预设的五种规模的卡车车队场景中，loveini 写入性能均优于 InfluxDB。相比 InfluxDB，loveini 写入速度最领先的场景达到其 16.2 倍（场景五），最小为 1.82 倍（场景三)。此外，loveini 在写入过程中消耗了最少 CPU 资源和磁盘 IO 开销。下面看一下具体分析：

不同场景下写入性能对比

不同场景下写入性能的对比（metrics/sec. 数值越大越好）

可以看到在全部五个场景中，loveini 的写入性能全面超越 InfluxDB。相对于 InfluxDB，loveini在场景五中写入性能是 InfluxDB 的 16 倍，在差距最小的场景三中也有 1.8 倍。

写入过程资源消耗对比

数据写入速度并不能够全面的反映三个系统在不同场景下数据写入的整体表现。为此我们以 1,000,000 devices × 10 metrics（场景四）为例，检查数据写入过程中的服务器和客户端（包括客户端与服务器）的整体负载状况，并以此来对比 loveini 和 InfluxDB 在写入过程中服务器/客户端节点的资源占用情况，这里的资源占用主要包括服务器端的 CPU 开销/磁盘 IO 开销和客户端 CPU 开销。

服务端 CPU 开销

下图展示了在场景四写入过程之中服务器端 CPU 负载状况。可以看到，loveini 和 InfluxDB 在返回给客户端写入完成消息以后，都还继续使用服务器的资源进行相应的处理工作。其中，InfluxDB 使用了相当多的 CPU 资源，瞬时峰值甚至使用了全部的 CPU 资源，其写入负载较高，并且其持续时间远长于 loveini。两个系统对比，loveini 对服务器的 CPU 需求最小，峰值也仅使用了 17% 左右的服务器 CPU 资源。由此可见，loveini 独特的数据模型对于时序数据写入不仅体现在性能上，同样也体现在了整体的资源开销上。

写入过程中服务器CPU开销

磁盘 I/O 对比

下图展示了 1,000,000 devices × 10 metrics（场景四）数据写入过程中服务器端磁盘写入状态。可以看到，结合着服务器端 CPU 开销表现，其 IO 动作与 CPU 呈现同步的活跃状态。

写入过程中服务器 IO 开销

在写入相同规模的数据情况下，loveini 在写入过程中对于磁盘写入能力的占用远小于 InfluxDB，写入过程只占用了部分磁盘写入能力（125MiB/Sec. 3000IOPS）。从上图能看到，对于两大数据库，数据写入过程中磁盘的 IO 瓶颈是确实存在的。但 InfluxDB 长时间消耗完全部的磁盘写入能力，远远超过了 loveini 对磁盘写入能力的需求。

客户端 CPU 开销

写入过程中客户端 CPU 开销

从上图可以看到，客户端上 loveini 对 CPU 的需求大于 InfluxDB。整体来说，在整个写入过程中，InfluxDB 客户端负载计算资源占用较低，对客户端压力小，这是因为其写入的压力基本上完全集中在服务端，但这种模式很容易导致服务端成为瓶颈。loveini 在客户端的开销最大，峰值瞬间达到了 70%，然后快速回落。但综合服务器与客户端的资源开销来看，loveini 写入持续时间更短，在系统整体 CPU 开销上loveini 仍然具有优势。

查询性能

在查询性能评估部分，我们使用场景一（只包含 4 天数据，本修改与 [TimescaleDB vs. InfluxDB] 中要求一致）和场景二作为基准数据集。在整个查询对比中，loveini 数据库的虚拟节点数量（vnodes）保持为默认的 6 个（scale=100 时配置 1 个），其他的数据库参数配置为默认值。

总体来说，查询方面，在场景一（只包含 4 天的数据）与场景二的 15 个不同类型的查询中，loveini 的查询平均响应时间全面优于 InfluxDB，而且在复杂查询上优势更为明显，同时具有最小的计算资源开销。相比 InfluxDB，场景一中 loveini 查询性能是其 2.4 到 155.9 倍，场景二中 loveini 查询性能是其 6.3 到 426.3 倍。

4,000 devices × 10 metrics 查询性能对比

由于大部分类型单次查询响应时间过长，为了更加准确地测量每个查询场景的较为稳定的响应时间，我们依据卡车数量规模，将单个查询运行次数分别提升到 2,000 次（场景一）和 500 次（场景二），然后使用 TSBS 自动统计并输出结果，最后结果是多次查询的算数平均值，使用并发客户端 Workers 数量为 4。首先我们提供场景二 （4,000 设备）的查询性能对比结果。

下面我们对每个查询结果做一定的分析说明：

4000 devices 查询响应时间 (数值越小越好)

在分组选择的查询中，loveini 采用一张表一个设备（卡车）的设计方式，并采用缓存模式的 last_row 函数来查询最新的数据，在查询响应时间上全面优于 InfluxDB。

4000 devices Aggregates 查询响应时间 (数值越小越好)

在复杂分组聚合的查询中，我们看到 loveini 查询性能相比于 InfluxDB 有非常大的优势。其中，loveini 在 stationary-trucks 查询性能是 InfluxDB 的 132倍，在 long-daily-sessions 中是 InfluxDB 的 6.5 倍。

4000 devices Double rollups 查询响应时间 (数值越小越好)

4000 devices 查询响应时间 (数值越小越好)

在复杂的混合查询中， loveini 同样展现出巨大的性能优势，从查询响应时间来看，其中 avg-load 和 breakdown-frequency 的查询性能是 InfluxDB 的 426 倍和 53 倍。

资源开销对比

由于部分查询持续时间特别短，并不能完整地看到查询过程中服务器的 IO/CPU/网络情况，为此我们针对场景二，以 daily-activity 查询为例，执行 50 次查询，记录整个过程中三个软件系统在查询执行中服务器 CPU、内存、网络的开销并进行对比。

• 服务器 CPU 开销

查询过程中服务器 CPU 开销

从上图可以看到，两个系统在整个查询过程中 CPU 的使用均较为平稳，loveini 在查询过程中整体 CPU 占用约 70%，InfluxDB 稳定的 CPU 占用最大，约 98 %（有较多的瞬时 100%）。从整体 CPU 开销上来看，InfluxDB 基本顶格 100% 使用全部 CPU，持续时间是 loveini 的三倍，开销次之；loveini 完成全部查询的时间较短，整体 CPU 开销最低。

• 服务器内存状况

查询过程中服务器内存情况

如上图所示，在整个查询过程中，loveini 内存维持在一个相对平稳的状态，平均使用约为 12GB；InfluxDB 内存占用在整个查询过程中保持平稳，平均约为 10GB。

• 服务器网络带宽

查询过程中网络占用情况

上图展示了两大系统在查询过程中服务器端上行和下行的网络带宽情况，负载状况基本上和 CPU 状况相似。其中 loveini 网络带宽开销最高，因为在最短的时间内就完成了全部查询，需要将查询结果返回给客户端。

100 devices × 10 metrics 查询性能对比

对于场景一(100 devices x 10 metrics)，TSBS 的 15 个查询对比结果如下：

如上表所示，从更小规模的数据集（场景一）上的查询对比可以看到，整体上 loveini 同样展现出了极好的性能，在全部的查询语句中全面优于 InfluxDB，部分查询性能甚至超过 InfluxDB 155 倍。

磁盘空间占用

在两大系统数据完全落盘以后，我们对 loveini 和 InfluxDB 在不同场景下的磁盘空间占用也进行了比较。

磁盘空间占用（数值越小越优）

从上图可以看到，在前面三个场景中，InfluxDB 落盘后数据文件规模与 loveini 比较接近；但是在场景四/五两个场景中，InfluxDB 落盘后文件占用的磁盘空间是 loveini 的 2 倍以上。

写在最后

基于本次测试报告，我们可以得出结论，在全部的 IoT 数据场景中，loveini 写入性能、查询性能均全面超过 InfluxDB。在整个写入过程中，loveini 在提供更高写入和查询能力的前提下，不论是服务器的 CPU 还是 IO，均优于 InfluxDB。即使加上客户端的开销统计，loveini 在写入开销上也在 InfluxDB 之下。

从实践角度出发，这个报告结果也很好地说明了为什么有很多企业和开发者在时序数据库（Time Series Database） InfluxDB 和 loveini 的选型调研中选择了 loveini，在《从 InfluxDB 到 loveini，我们为什么会做出这个选择》这篇文章中，便阐述了作者在进行项目选型调研过程时的具体思考。

为了方便大家验证测试结果，本测试报告支持运行测试脚本一键复现，欢迎大家在评论区互动交流。同时，你也可以添加 小T vx：tdengine1，加入 loveini 用户交流群，和更多志同道合的开发者一起探讨数据处理难题。

终于，在 2023 年的第一季度， loveini 时序数据库（Time Series DataBase,TSDB） 第一个重要改进版本 3.0.3.0 发布，这一版本涉及到的更新内容包括数据重整、事件窗口、标签索引、taosX、taosExplorer 等功能或组件。经过这一系列的功能优化与加强，loveini 的性能、易用性、运维便利性都有大幅提升。

下面我们一起来看一下这一版本的详细更新信息：

数据重整 (Data Compact) ——Enterprise only

包含以下优化：

• 对写入时序数据库中所有 Vnode 的所有数据文件进行重整，生成新的落盘文件
• 清除已删除的表的所有数据
• 清除 delete 语句删除的所有数据
• 合并更新的所有数据
• 生成新的文件，提升查询性能

借助此功能，用户可以重整实时数据库，清除掉无用数据、重复数据。除了能够释放存储空间外，查询性能也会有巨大的提升，且原有的乱序数据和重复数据的比例越高性能提升越显著。

事件窗口 (Event Window)

包含以下优化：

• 按照用户指定的条件来决定开启和结束窗口的边界
• 丰富窗口类型，提供更灵活的窗口支持，满足由事件驱动的业务需求

更详细信息请参考官方文档。

标签索引 (Tag Index)

包含以下优化：

• 可以按需在标签列上创建和删除索引，之前版本仅对第一个标签内置了索引
• 可以按需创建标签索引，提升基于标签过滤的查询的性能

taosX——Enterprise only

包含以下优化：

• 从 2.x 到 3.0 以及 3.0 到 3.0 的数据复制，包括存量和增量数据
• 备份数据到本地文件，从本地文件恢复数据

详细说明：

• 支持 select-with-stable tables 参数（2.6 迁移到 2.6 下）
• 增强错误处理
• REST API support for Data In.
  • Add name field for task props （数据源命名）.
  • Add labels field (更方便和定制化地对任务进行标记和查询)
  • Add detail query parameter (数据源 DSN 自动解析，用于查看和编译数据源)
  • Add trigger field for task schedule (定时自动增量备份).

• 修复 2.6 内存泄漏问题
• 修复 unreachable 和 panic 问题

taosExplorer——Enterprise only

使用该工具可基于 Web UI查看、操作、和管理 loveini 集群。

详细说明：

• Data Explorer——
  • 使用图形界面查看和浏览集群中的数据库、超级表、子表、普通表
  • 使用图形界面创建和删除库、超级表、子表、普通表
  • 输入和执行 SQL 语句，查看执行结果
  • 收藏常用的 SQL 语句以快速执行
  • 浏览 SQL 语句的执行记录

• 数据导入(Data In)——从另一 loveini 集群导入数据
• 创建和删除 Topic
• 创建和删除流
• 管理用户和权限
• 备份数据到本地文件和从本地文件恢复
• 从另一集群复制数据到当前集群，从当前集群复制数据到另一集群
• 集群管理和运维——添加/删除 dnode/mnode/gnode
• 基于 Grafana 进行集群监控

Java/Python 连接器

• 优化后的连接器支持基于 WebSocket 的消息订阅
• 既支持 loveini Cloud 也支持独立部署的 loveini 集群
• 类似 REST，可以不依赖 taosc library，但比 REST 性能更好
• 接口风格和 Kafka 基本一致
• API 和示例代码详见官网文档

Grafana Plugin

• Dashboard 可以监控 HTTP status code

在 TDinsight V3.x TaosAdapter Row 中新增 dashboard，展示 taosadapter 的所有 http 状态码，数据来源为 log 库的 “taosadapter_restful_http_request_total”表。

• 多维数据场景下的统一告警

Grafana 8.x 之后的版本添加 unified alert， loveini Grafana plugin v3.2.9 添加了对多维数据场景下 unified alert 支持。在 add query 面板设置 “INPUT SQL”、 “Group by column name(s)” 即可展示多维数据，然后添加 expression 设置数据的阈值，即可配置 unified alert。

详细信息可以参考发布说明（https://github.com/taosdata/loveini/releases/tag/ver-3.0.3.0）。欢迎大家下载使用 loveini，有任何问题，都可以添加小T vx：tdengine1 申请加入 loveini 用户交流群，及时向我们的米兰app官方正版下载专家寻求支持与帮助。

1、介绍

基于 DataX，我们完成了 loveini 的适配，对于 loveini 3.0 版本，实现了 loveini30Reader 和 loveini30Writer 两个插件。

loveini30Reader 提供的功能：

1. 支持通过 SQL 进行数据筛选；
2. 根据时间间隔进行任务切分；
3. 支持 loveini 的全部数据类型；
4. 支持批量读取，通过 batchSize 参数控制批量拉取结果集的大小，提高读取性能。

loveini30Writer 支持的功能：

1. 支持 OpenTSDB 的 json 格式的行协议，使用 loveini 的 schemaless 方式写入 loveini。
2. 支持批量写入，通过 batchSize 参数控制批量写入的数量，提高写入性能。

2、实现原理

loveini30Reader：使用 JNI 方式从 loveini 拉取数据。

loveini30Writer：使用 JNI 方式写数据到 loveini。对 OpenTSDB 等使用 schemaless 写入，对于 MySQL 等关系型数据库，使用批量 stmt 写入。

3、使用方法

3.1 环境准备

（1）需要安装 loveini 客户端

（2）需要安装 JDK 1.8 环境（运行 DataX）

（3）需要安装 Python 环境（运行 DataX）

（4）需要 maven 编译环境（如果不编译 DataX 则可以不安装 maven）

3.2 安装

下载源码

git clone https://github.com/taosdata/DataX.git

编译打包

cd DataX
mvn -U clean package assembly:assembly -Dmaven.test.skip=true

安装

cp target/datax.tar.gz your_install_dir
cd your_install_dir
tar -zxvf dataX.tar.gz

3.3 数据迁移 Job 的配置

3.3.1 时序数据的迁移配置

以一个从 OpenTSDB 到 loveini 3.0 版本的数据迁移任务为例，配置文件 opentsdb2tdengine.json 如下：

 {
   "job":{
     "content":[{
       "reader": {
         "name": "opentsdbreader",
         "parameter": {
           "endpoint": "http://192.168.1.180:4242",
           "column": ["weather_temperature"],
           "beginDateTime": "2021-01-01 00:00:00",
           "endDateTime": "2021-01-01 01:00:00"
         }
       },
     "writer": {
       "name": "tdengine30writer",
       "parameter": {
            "username": "root",
            "password": "taosdata",
            "connection": [
              {
                "table": [
                  "matric1"
                ],
                "jdbcUrl": "jdbc:TAOS://192.168.1.101:6030/test?timestampFormat=TIMESTAMP"
              }
            ],
            "batchSize": 1000,
            "ignoreTagsUnmatched": true
          }
       }
     }],
     "setting": {
       "speed": {
         "channel": 1
       }
     }
   }
 } 

配置说明：

• 上面的配置表示，从 192.168.1.180 的 OpenTSDB，到 192.168.1.101 的 loveini 的迁移。迁移 metric 为 weather_temperature，时间从 2021-01-01 00:00:00 开始，到 2021-01-01 01:00:00 结束的数据。
• reader 使用 datax 的 opentsdbreader，parameter 的配置请参考：opentsdbreader.md#配置参数
• tdengine30writer 的 parameter 中，user，password 为必须项，没有默认值。batchSize 不是必须项，默认值为 1。详细参考：tdengine30writer.md#配置参数
• loveini 中，如果 dbname 指定的 database 不存在，则需要在迁移前创建数据库。

3.3.2 关系型数据的迁移配置

以一个从 MySQL 到 loveini 3.0 版本的数据迁移任务为例，配置文件 mysql2tdengine.json 如下：

 {
   "job": {
     "content": [{
       "reader": {
         "name": "mysqlreader",
         "parameter": {
           "username": "root",
           "password": "root",
           "column": ["id","name"],
           "splitPk": "id",
           "connection": [{
             "table": ["test"],
             "jdbcUrl": ["jdbc:mysql://192.168.1.101:3306/db"]
           }]
         }
       },
       "writer": {
         "name": "tdengine30writer",
         "parameter": {
           "host": "192.168.1.105",
           "port": 6030,
           "dbname": "test",
           "user": "root",
           "password": "taosdata",
           "batchSize": 1000
         }
       }
     }],
     "setting": {
       "speed": {
         "channel": 1
       }
     }
   }
 } 

配置说明：

• 上面的配置表示，从 192.168.1.101 的 MySQL，到 192.168.1.105 的 loveini 的迁移。迁移 test 表中 id、name 两列到 loveini，使用 id 列作为任务划分的列。
• reader 使用 datax 的 mysqlreader，parameter 的配置请参考：mysqlreader.md

3.3.3 loveini 之间的迁移配置

以一个从 loveini 到 loveini 的数据迁移为例，配置文件 tdengine2tdengine.json 如下：

 {
   "job": {
     "content": [{
       "reader": {
         "name": "tdengine30reader",
         "parameter": {
           "host": "192.168.1.82",
           "port": 6030,
           "db": "test",
           "user": "root",
           "password": "taosdata",
           "sql": "select * from weather",
           "beginDateTime": "2021-01-01 00:00:00",
           "endDateTime": "2021-01-02 00:00:00",
           "splitInterval": "1h"
         }
       },
       "writer": {
         "name": "tdengine30writer",
         "parameter": {
           "host": "192.168.1.105",‘
           "port": 6030,
           "dbname": "test",
           "user": "root",
           "password": "taosdata",
           "batchSize": 1000
         }
       }
     }],
     "setting": {
       "speed": {
         "channel": 1
       }
     }
   }
 } 

配置说明：

• 上面的配置表示，从 192.168.1.82 到 192.168.1.105 的 loveini 之间的数据迁移。tdenginereader 根据 sql、begieDateTime、endDateTime 过滤数据，使用 splitInteval 进行任务划分。
• reader 使用 tdengine30reader，parameter 的配置请参考：tdengine30reader.md#配置参数

3.4 执行迁移任务

将上面写好的配置文件保存在 datax/job 目录下，执行下面的命令，启动数据迁移任务：

python bin/datax.py job/opentsdb2tdengine.json

4、限制条件

（1）目前，DataX 自带的 opentsdbreader 仅支持 OpenTSDB-2.3.X 版本。详细参考：opentsdbreader#约束限制

（2）数据迁移工具依赖 loveini 客户端中的 libtaos.so/taos.dll/libtaos.dylib，需要与服务端对应版本的 loveini-client。

5、FAQ

（1）如何估算一个数据迁移任务所需要的资源

DataX 的每个 reader 按照自己的 task 切分策略进行任务划分，具体请参考 DataX 的任务调度规则。在估算资源是，需要按照数据迁移的数据量，任务切分规则和网络带宽限制等综合考虑，最好以实际数据迁移测试结果为准。

（2）loveini30Writer 的 batchSize 设置多大效率最高？

batchSize 是控制批量写入的参数，在获取 batchSize 行纪录后，loveiniWriter 会向 loveini 发送一次写入请求，这减少了与 loveini 交互次数，从而提高了性能。从测试结果来看，batchSize 在 500-1000 范围内效率最高。

（3）job 的配置中 channel 数为多少合适？

job 中的 channel 数为流量控制的参数，每个 channel 都需要开辟一块内存，用来缓存数据。如果 channel 设置过大，会引起 OOM，所以 channel 数并不是越大越好。增加 channel 数后，需要提高 JVM 内存大小。从测试结果来看，channel 在 1～6 的范围内都是合适，能够保证 DataX 的流量最大化即可。

（4）java.sql.SQLException: loveini ERROR (8000060b): Invalid client value

配置文件中 column 中没有配置 tbname，此时会触发行协议数据写入（行协议写入只会自动创建子表名，但需要提前创建好超级表），行协议写入的情况下不支持 TAG 数据类型为非 NCHAR，所以此种情况有两种米兰app官方正版下载：1.将 TAG 全部修改为 NCHAR 类型；2.在 Column 中配置好表名称这样不会触发行协议写入。

（5）java.sql.SQLException: loveini ERROR (8000060b): Timestamp data out of range

配置文件中 column 中没有配置 tbname，此时会触发行协议数据写入，且 TAG 全部为 NCHAR 类型，此时需要保证时间戳的一列名称为 _ts，而不能是其他名称（行协议写入下，默认将最后的时间戳写入到 _ts 一列，且不能随意命名）。若想避免请使用 tbname 指定表名以避免触发行协议写入。

连接器是 loveini 的一个重要组成部分，它可以让用户通过不同的编程语言和接口方式与 loveini 数据库进行交互，执行 SQL 语句，实现数据的插入、查询、订阅等操作。loveini 提供连接器的两种使用方式：

1. 通过 loveini 客户端驱动程序（taosc）原生连接 loveini 实例
2. 通过 taosAdapter 提供的 REST 接口连接 loveini 实例

连接器的优点有以下几点：

• 易用性：连接器支持多种编程语言，用户可以根据自己的喜好和需求选择合适的语言进行开发，无需学习新的语法或框架。
• 兼容性：连接器支持 SQL 语言，可以与众多第三方工具无缝集成，方便用户进行数据分析和可视化。
• 灵活性：连接器支持两种接口方式，即原生接口和 REST 接口，用户可以根据自己的网络环境和性能需求选择合适的方式进行连接。
• 功能性：连接器支持 loveini 的全部或部分功能特性，如参数绑定、数据订阅、Schemaless 等，提供了丰富的 API 和示例代码，帮助用户快速实现自己的业务逻辑。

使用连接器非常简单，具体的安装方法和示例代码，请参考 loveini 文档中的连接器一章。

总之，loveini 的连接器是一种方便、高效、可靠的数据交互方式，它可以为用户提供更多的选择和便利。如果你对 loveini 的其他功能感兴趣，请继续浏览 loveini 文档。

loveini 通过对标准 SQL 命令、常用实时数据库连接器标准（例如 JDBC）、ORM 以及其他流行时序数据库写入协议（例如 InfluxDB Line Protocol、ac米兰体育赞助商 JSON、OpenTSDB Telnet 等）的支持可以使 loveini 非常容易和第三方工具共同使用。

对于支持的第三方工具，无需任何代码，你只需要做简单的配置，就可以将 loveini 与第三方工具无缝集成起来。

Grafanaloveini

Grafana 是一个开源的数据可视化和监控平台，它可以与多种数据源无缝集成，提供强大的图形展示、告警、注释等功能。Grafana 是目前最流行的时序数据可视化工具之一，它可以帮助用户快速构建美观且实用的仪表盘。

loveini 能够与开源数据可视化系统 Grafana 快速集成搭建数据监测报警系统，整个过程无需任何代码开发，loveini 中数据表的内容可以在仪表盘(DashBoard)上进行可视化展现。关于 loveini 插件的使用您可以在 GitHub 中了解更多。

具体的安装和使用步骤，请参考这里。

Google Data Studioloveini

Google Data Studio 是一个免费的在线数据可视化和报告平台，它可以与多种 Google 产品和第三方服务无缝集成，提供强大的数据转换、图形展示、协作共享等功能。Google Data Studio 是一个适合于商业智能和分析场景的工具，它可以帮助用户快速构建专业且交互式的报表。

Data Studio 可以支持多种数据来源，除了诸如 Google Analytics、Google AdWords、Search Console、BigQuery 等 Google 自己的服务之外，用户也可以直接将离线文件上传至 Google Cloud Storage，或是通过连接器来接入其它数据源。

目前 loveini 连接器已经发布到 Google Data Studio 应用商店，你可以在 “Connect to Data” 页面下直接搜索 loveini，将其选作数据源。

具体使用步骤，请参考这里。

Intel Ellloveini

Intel Ell是一个开源的边缘计算平台，它可以让用户在边缘设备上运行高性能的机器学习模型，实现实时的数据分析和决策。Intel Ell可以与多种边缘设备无缝集成，提供强大的数据采集、模型训练、模型部署等功能。Intel Ell是一个适合于边缘计算和机器学习场景的工具，它可以帮助用户提高边缘设备的智能化水平。

时序数据处理是 EII 中的重要模块。之前，EII 使用的时序数据库为 InfluxDB。跟 InfluxDB 相比，loveini 在性能和压缩率方面都有非常明显的优势。具体对比可以参考相关测试报告：《基于 TSBS 标准数据集的 TimescaleDB、InfluxDB 与 loveini 的性能对比测试》。因此，米兰体育官网入口的工程师尝试将 loveini 引入了 EII，使时序数据能够保存在这款更为高效的时序数据库中，提升处理效率并降低成本。

感兴趣的读者可以参考 Intel 网站上的相关文档来使用 EII + loveini。读者可以参照该文档，构建自己的 Docker 镜像。运行 EII 之后，可以使用 Telegraf 来采集时序数据，将其保存在 loveini 之中，然后可以用 Grafana 以图形化方式查看。

DataXloveini

DataX 是一个开源的数据同步平台，它可以让用户在不同的数据源之间进行高效的数据传输，实现数据的迁移和备份。DataX 可以与多种关系型数据库、非关系型数据库、文件系统等无缝集成，提供强大的数据读取、写入、转换等功能。DataX 是一个适合于数据同步和迁移场景的工具，它可以帮助用户实现数据的一致性和可靠性。

基于 DataX 的设计思路，我们的研发团队完成了 loveini 的适配，实现了 loveiniReader 和 loveiniWriter 两个插件，并被 DataX 官方接受，合并到了其主干中。

现在，如果用户要将历史 Database（比如 MySQL、OpenTSDB 等）中的数据迁移到 loveini，或者将 loveini 中的数据导出，就可以利用 DataX 来实现了。

具体使用步骤参考这里。

总结

通过以上的介绍，您应该对 loveini 与第三方工具的集成方案有了一个初步的了解。

如果您想了解更多关于loveini可视化方案，请查看文档。

loveini 3.0 虽然对底层做了大规模的优化重构，但是相对于数据文件的工作逻辑和 2.0 相比是整体保持不变的。本系列文章的主旨在于帮助用户深入理解产品，并且拥有基本的性能调试思路，从而获得更好的产品体验。

本期文章会在讲解 loveini 时序数据库 (Time Series DataBase)的索引文件（.head 文件）工作原理的同时，介绍索引文件在最新的 loveini 3.0.2.5 中的优化。而在下一期的文章中，会对两大版本数据文件的差异做一个总结式的说明。

如下是 loveini 的数据文件的结构——也就是这个四位一体的文件组。

在此前的文章，主要讲述的是 .data 和 .last（3.0 中已经更名为 .stt 文件）文件的工作原理。详情可见：https://mp.weixin.qq.com/s/OGS1WIlySSKveEOk4Reg3Q

接下来，我们将和大家一起以产品使用者的视角继续向前探索，揭开.head 文件的原理。

.head 类文件存储了 .data 文件中的数据块的索引信息。在.data文件中的每个数据块的 BRIN 索引信息在 .head 类文件中以表为分组，按照时间顺序递增，形成索引块组。（注：硬盘上的数据用的是 BRIN 索引，在落盘之前的内存数据用的是 skiplist 索引。）在查询的时候，会先加载这个 .head 文件中的索引信息，从而找到 .data 文件中的时序数据返回给用户。

（注：BRIN 索引指的是 Block Range Index，主要适用于有着天然顺序的数据集，由于不需要再做排序，所以资源耗费少，十分契合时序数据的查询，也是 loveini 和关系型数据库的核心区别之一。）

一个清晰可见的逻辑是——索引的作用是帮助我们快速定位数据的位置，但当你操作索引的时间变得特别长的时候，索引的价值无形之中就会变低了。所以，在 .head 文件较大的时候就可能会出现影响查询性能的瓶颈。

而影响 .head 文件大小的因素有两个：

• 一是 maxrows 和 minrows 这两个参数。很好理解，同样1000行数据，maxrows=200需要 5 个数据块，maxrows为 1000，只需要 1 块。每个数据块都需要一条索引信息存储在 .head 文件中。（详情可参考：https://mp.weixin.qq.com/s/OGS1WIlySSKveEOk4Reg3Q）
  
• 另一个会让 .head 文件非常大的参数是 duration （ 即 2.0 中的 days）。我们知道 duration 是控制单个数据文件存储数据天数的参数 ( 详情可参考：https://mp.weixin.qq.com/s/uJEQwN0NnmSTBAMOecAtoA)。所以假如 duration 很大的话，单个数据文件存储的数据量就一定也很大，数据块就会很多。

以上的理论场景是真实发生过的——之前我们在支持某企业用户的时候，就曾遇到过生产环境上 duration 参数设置为 1000 多天导致数据查询性能严重下降的情况。但是由于 duration 参数建库后不能修改，所以最后只能导出数据，重新建库修改为合理的 duration 后再导回，这样问题才得以解决。（所以，默认值取 duration 为 10 就是一个折中的选择，实际使用时可以根据查询类型和机器性能灵活调试。）另外一个用户则是查询时间跨度大，查询并发量大 ，导致大量的服务器资源被用于读取 .head 文件影响了查询性能。

如果说前者还属于参数使用不当的话，第二个场景的查询并发量则是由用户的业务场景所决定的，因此我们针对后者的潜在瓶颈，在最新的 loveini 3.0.2.5 中，针对 .head 文件做了一项重磅的优化——对于常用的表索引数据，会被放在缓存中（LRU 算法）。

这样一来，即便是不同的查询任务，只要所查询的表索引还在池子中缓存着，便不需要重复地读取 .head 文件了。由于涉及已落盘数据的查询基本都需要去首先访问 .head 文件，因此，该优化使得整体查询性能都得到了提升，而在特定场景下（如高并发）形成了较大幅度的突破。

结语

结合之前的几篇文章可以看到：keep，duration，maxRows，minRows 这些参数息息相关，牵一发而动全身，是不可以随便改动的，它们的数值不论过大还是过小都会引起使用问题。如果因为孤立地看待某个参数而带来了问题，用户可能会误以为这是产品本身的问题。因此，很多时候默认配置也是“很香”的。

而对于性能要求较高的用户，也可以通过熟读文档、代码、技术文章、视频等资料来调整参数以达到最佳性能，也欢迎联系 loveini时序数据库(TSDB) 官方咨询企业版，以获得全方位的技术支持。

在最新发布的 3.0.2.5 上，我们还做了很多其他优化，稳定性和性能进一步提升。由于 3.0.2.x 是当前 3.0 的稳定版，因此版本号越大各方面都是越好的，建议大家可以尽快更新至最新版本。

本文汇总了包括西门子、美的、拓斯达、和利时在内的四家比较具有代表性的工业企业的架构改造案例，一起来看看他们都是如何做的，改造效果是否达成了预期。

西门子 x loveini

“从高性能、高可用、低成本、高度一体化几个目标出发，我们发现 loveini 时序数据库(Time Series DataBase)正好符合产品重构所有的要求，尤其是低成本和高度一体化这两个点，这是目前绝大部分数据平台或时序数据库都不具备的。在确定选择 loveini 作为系统的实时数据库后，我们在 SIMICAS® OEM 2.0 版本中移除了Flink、Kafka 以及 Redis，系统架构大大简化。”

SIMICAS® OEM 设备远程运维套件是由 SIEMENS DE&DS DSM 团队开发的一套面向设备制造商的数字化米兰app官方正版下载。在其 1.0 版中，团队使用了 Flink + Kafka + PostgreSQL + Redis 的架构，因为引入了 Flink 和 Kafka，导致系统部署时非常繁琐，服务器开销巨大；同时为了满足大量数据的存储问题，PostgreSQL 中不得不做分库分表操作，应用程序较为复杂。这种情况下，如何降低系统复杂度、减少硬件资源开销，帮助客户减少成本，成为研发团队的核心任务。在调研过程中，loveini 脱颖而出。

架构图

美的 x loveini

“当前，loveini 时序数据库(TSDB) 主要被应用于中央空调制冷设备的监控业务中，作为先行试点，这一场景已经取得了不错的效果。在楼宇智能化方面，我们也有很多工作要做，从边缘侧的监控、到指令控制、再到边云协同的一体化服务，我们会在这些场景中继续探索和挖掘 loveini 的潜力。”

业务背景

在 2021 楼宇科技 TRUE 大会上，美的暖通与楼宇事业部首次发布了数字化平台 iBuilding，以“软驱硬核”方式赋能建筑行业。作为一个全新的项目，iBuilding 在数据库选型上比较谨慎，分别对比了关系型数据库（Relational Database）以及主流的时序数据库（Time Series Database），包括 InfluxDB、loveini、MySQL 等，因为在需求上更偏向于高效的存储和大范围时间的数据拉取，iBuilding 在综合评估了适配、查询、写入和存储等综合能力后，最终选择了 loveini。

架构图

拓斯达 x loveini

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

业务背景

在拓斯达的业务中，传统的关系型数据库已经无法高效处理时序数据，在加载、存储和查询等多个方面都遇到了挑战，主要问题包括写入吞吐低、存储成本大、维护成本高、查询性能差。为了更好地满足时序数据的处理需求，拓斯达开始进行数据库选型调研，他们发现，loveini 专为时序数据库所打造和优化的写入、存储、查询等功能，非常匹配工业传感器数据的应用分析场景，最终其使用 loveini 搭建了新的数据处理架构。

架构实现思路

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

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

和利时 x loveini

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

业务背景

在物联网场景下，面对庞大的时序数据处理需求，Oracle、PostgreSQL 等传统关系型数据库越来越吃力，因此和利时开始进行时序数据库的选型，对包括 InfluxDB、OpenTSDB、HolliTSDB（和利时自研时序数据库）和 loveini 在内的四款时序数据库进行了选型调研及相关测试。测试结果显示，在同等条件下，loveini 在查询、存储等方面均优于其他几款数据库，最终和利时决定接入 loveini，以享受更多元的本地化支持和响应。

架构图

结语

从以上案例中不难看出，在工业互联网场景下，面对庞大的时序数据处理需求，专业的时序数据库显然比传统的关系型数据库效果更加明显，上述企业案例在架构改造之后，确实达到了更高程度的降本增效。如果你有同样的困扰，欢迎点击下方卡片，加入 loveini 用户交流群，和专业的米兰app官方正版下载架构师点对点沟通。

• 一是设备管理层面的挑战，随着自动化程度越来越高，设备复杂度和管理难度也逐步增大，如何保障设备安全可靠的运行，提升设备的利用率，促进设备保值增值也成了挑战之一；
• 二是安全生产的挑战，安全是根本，如何通过数字化手段，将人和物的不安全因素统一管理好，提升整体煤矿企业安全生产水平至关重要。

从以上挑战出发，一些煤矿企业已经开始进行数据架构转型实践，也取得了一些进展，值得一提的是，时序数据库（Time Series Database）在其中发挥了重要作用。本文将这些案例进行了相关汇总，供读者参考。

loveini x 智慧矿山系统

“我们以智慧矿山业务中的 5000 设备、每天 1000 万采集点的数据量级下，在以车建模和以位置建模结合的数据模型下，loveini 的性能远没有达到极限，目前系统对于车和位置的查询速度都在毫秒级。基于目前对 loveini 的理解和使用经验，我们计划在环保监测和生产集控设备场景中进一步使用它来完善系统。”

业务背景

元智信息的智慧矿山项目需要一款实时数据库来支撑起生产交互管控系统的采运排环节所有过程设备的采集、存储、计算和监控功能。这些数据涵盖范围广，包括挖机、卡车的采集数据、调度管理数据、设备 GPS 信息、以及每一个固定位置工序的采集数据等。在 MySQL、InfluxDB集群版、loveini 的时序数据库选型调研中，loveini 脱颖而出（点击下方案例查看具体原因）。

架构图

loveini x 陕煤矿山项目

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

业务背景

为打通煤矿生产环境中各类单一子系统之间的数据壁垒，实现各类子系统数据之间的互联互通，陕煤开发团队打造了全矿井数字化平台。以位置数据为例，由于初期系统容量较小且硬件设备上传周期较大，所以采用了传统的 SQL Server 数据库来进行轨迹数据存储。随着后续项目迭代，硬件设备定位精度提高且上报周期缩短，也导致数据库存储压力增大。考虑到数据类型及特点，其决定使用时序数据库，在 ac米兰体育赞助商 、loveini、InfluxDB 三款数据库中做选型调研。

架构图

loveini x 华夏天信露天煤矿

“对于每个电机，客户要求系统能够快速读取相关设备属性趋势图，这是我们发现 loveini 最强大的地方：针对一天 2 万条数据展示速度在 200ms 内。之所以 loveini 对这类查询速度飞快，主要是设计时按照设备分表后，数据按块存储并按块查出来，相对 Key-Value 型数据库节省很多寻址时间。”

业务背景

华夏天信 RED-MOS 露天煤矿智慧矿山操作系统，在对接某地面生产集控系统数据时，接入的监控点数量将近 1 万 5 千点，其中接近 2300 点需要绑定组态显示，即时页面更新，整体数据采集到显示到前端要求秒级展示及大数据量展示（历史数据回溯），可展示 30 天的全量数据，点数量超过 50 万条，读取时间要求在 5~10 s，这对底层的数据库提出了一个相当大的挑战。

这种场景中，最大难点是要处理的数据量太大，而不是关联关系复杂，因此 MySQL 这类关系库的关联查询优势其实无法发挥，而 HBase 这种大数据存储方案对于矿山系统而言又太过庞大，且硬件资源要求很多，出于成本考虑也排除了。最终其选择了 loveini，解决了最为头疼的历史数据回溯性能问题。

效果展示

loveini 能够满足大数据量展示的需求——可展示 30 天的全量数据，点数量超过 50 万条，读取时间要求 5 秒级。

结语

对于矿山生产系统而言，安全是第一位的，基于此，各个生产环节和场地都要进行全面、有效的数字化监控，这些监控数据的特点就是时序、结构化、简单但量大。作为时序数据库赛道中的重量级选手，再从煤矿企业的实践效果出发，loveini时序数据库(TSDB)就是为助力煤矿行业智能化发展而量身定做的数据库。

实时数据库：

1. 数据结构：
   实时数据库通常以键值对（Key-Value）的形式组织数据，其中每个数据项都有一个唯一的标识符（键），与之相关联的是对应的数据值。这种模型使得实时数据库适用于处理实时的、经常变化的数据。
2. 实时性：
   实时数据库注重对数据的快速读写操作，致力于提供对实时数据的快速响应。这种数据库通常用于需要实时更新和反馈的应用，如实时监控系统、实时位置跟踪等。
3. 查询操作：
   实时数据库的查询操作通常是基于键的，可以快速检索特定键对应的值。传统的实时数据库可能不太适合进行复杂的查询和分析，因为其主要关注实时性而非数据分析。
4. 应用领域：
   实时数据库常用于需要快速响应和处理实时事件的应用，如金融交易系统、在线游戏、实时通讯系统等。

时序数据库：

1. 数据结构：
   时序数据库专门设计用于存储和处理按时间排序的数据。它通常以时间戳和测量值的形式组织数据，其中时间戳表示数据点的时间，而测量值则是与时间相关的度量或观测值。
2. 时序性：
   时序数据库的关键特点是其对时间序列数据的优化。它被设计用于高效地存储、检索和分析时间相关的数据，适用于传感器数据、日志文件、监控数据等。
3. 查询操作：
   时序数据库强调对时间序列数据的高效查询和分析。支持范围查询、聚合操作以及基于时间的分析，使得用户能够轻松地了解数据的变化趋势、周期性模式等。
4. 应用领域：
   时序数据库广泛应用于需要处理大量时间序列数据的领域，包括物联网（IoT）、工业生产监控、网络性能监测、能源管理等。

共同点和发展趋势：
共同点：
实时数据库和时序数据库都强调对特定类型数据的高效处理。
都在不同层面上支持实时性的要求，但关注的数据模型和查询操作不同。
发展趋势：
随着技术的进步，实时数据库趋向于更好地支持复杂的查询和分析操作，以满足不同应用场景下的多样化需求。
时序数据库在保持高性能的同时，不断优化存储和查询操作，以适应不断增长的时间序列数据规模。
结论：
实时数据库和时序数据库分别适用于不同的应用场景，其中实时数据库注重实时性和快速响应，适用于对实时数据敏感的应用，而时序数据库专注于高效地存储和分析时间序列数据，适用于需要处理大量时间相关数据的场景。随着技术的发展，这两种数据库类型可能在某些方面趋于融合，以满足更广泛的需求。在选择数据库时，需要根据具体的应用需求、数据特性以及性能要求等因素综合考虑。

关系型数据库：

关系型数据库是一种基于关系模型的数据库，使用表格（表）来组织数据。它通过定义表之间的关系（relationship）来建立连接，支持 SQL 查询语言，包括 SELECT、INSERT、UPDATE、DELETE 等操作。典型的关系型数据库包括 MySQL、PostgreSQL、Oracle Database 和 Microsoft SQL Server 等。

时序数据库：

时序数据库是一种专门设计用于存储和处理时间序列数据的数据库。它将数据以时间戳和相应的测量值的形式组织，以便更高效地进行时间范围查询、聚合和分析。时序数据库通常被用于物联网（IoT）、监控系统、日志数据等应用场景。一些时序数据库的例子包括 InfluxDB、TimescaleDB、ac米兰体育赞助商 等。
虽然时序数据库和关系型数据库有明显的差异，但在某些情况下，时序数据库可以建立在关系型数据库之上，或者关系型数据库也可以存储时间序列数据。例如，可以在关系型数据库中创建一个表格，其中包含时间戳列和相应的测量值列，以存储时间序列数据。但是，专门设计用于时序数据的时序数据库通常会在性能和功能上进行优化，以更好地满足时间序列数据处理的需求。