TSBS 是一个时序数据处理（数据库）系统的性能基准测试平台，提供了 IoT、DevOps 两个典型应用场景，它由 Timescale 开源并负责维护。作为一个性能基准测试平台，TSBS 具有便捷、易用、扩展灵活等特点，涵盖了时序数据的生成、写入（加载）、多种类别的典型查询等功能，并能够自动汇总最终结果。由于其开放开源的特点，得到了众多数据库厂商的支持，作为专业的产品性能基准测试平台被若干数据库厂商广泛使用。

以下的性能基准报告均使用了 TSBS 作为基础 Benchmark 平台，我们从时间跨度和发布厂商的知名度同时来看，就能发现，基础测试平台 TSBS 已经具备了很高的认可度：

2018 年 11 月
VictoriaMetrics 的创始人 Aliaksandr Valialkin 发布 《High-cardinality TSDB benchmarks: VictoriaMetrics vs TimescaleDB vs InfluxDB》，将 VictoriaMetrics 与 TimescaleDB、InfluxDB 进行性能对比。

2018 年 11 月
文章《ClickHouse Crushing Time Series》中对比了 TimescaleDB, InfluxDB, ClickHouse 在时序数据场景下的性能。

2020 年 3 月
Cloudera 在网站博客中发布《Benchmarking Time Series workloads on Apache Kudu using TSBS》，在 DevOps场景 中对比了 Apache Kudu, InfluxDB, VictoriaMetrics, ClickHouse 等整体性能表现。

2020 年 3 月
Redis 发布了基于 TSBS 的性能报告《RedisTimeSeries Version 1.2 Benchmarks》。

2020 年 8 月
Timescale 在其官方博客发布了性能对比报告《TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data》。

2021 年 8 月
QuestDB 发布了 QuestDB 与 TimescaleDB 的性能对比报告——《QuestDB vs. TimescaleDB》。

DevOps 场景是一个典型的时序数据应用场景，TSBS DevOps 场景提供了 CPU 状态的模拟数据，针对每个设备（CPU）记录其 10 个测量值（metric），1 个时间戳（纳秒分辨率），10 个标签值（tag）。生成的数据每 10 秒间隔一条记录，具体的内容和示例数据如下：

TSBS 测试可以简单划分为两个主要部分——数据写入和数据查询。在本次整个基准性能评估中，共涉及以下五个场景，每个场景的具体数据规模和特点见下表：

通过上表可以看到，五个场景的区别主要在于数据集所包含的设备记录数量、设备数的不同，数据时间间隔均维持在 10 sec。整体来看，五个场景的数据规模都不算大，数据规模最大的是场景五，数据达到了 1.8 亿，数据规模最小的是场景一，只有 2678 万条记录。在场景四和场景五中，由于设备数量相对较多，所以数据集仅覆盖了 3 分钟的时间跨度。

为了保证测试结果的公正可靠及可复制性，我们选用了公共 IaaS 平台来搭建 Benchmark 基础硬件环境，采用了大多数性能对比报告中使用的场景——亚马逊 EC2 服务环境下 r4.8xlarge 类型的实例作为基础运行平台，区域为北美地区，包括 1 台服务器、1 台客户端。客户端与服务器硬件配置完全相同，两者使用 10 Gbps 网络连接。配置简表如下：

本次测试的对比软件为 InfluxDB 1.8.10 及 Timescale 2.6.0，在这里要着重说明一下，由于 InfluxDB 最新的 2.0 版本并没有纳入 TSBS 的主干分支，因此在这次测试中我们暂且使用了 TSBS 主干分支所支持的 InfluxDB 最新版本，即 1.8.10。

整个 TSBS 测试流程相对比较简单，在进行写入性能对比时，配置完成参数后直接运行 TSBS 框架脚本，等待结果输出即可。对于查询处理，我们选择了批量自动化去运行，对每个查询语句运行 5000 次，统计查询延迟的算数平均作为最后的查询延迟结果。此外我们还全程监控并记录了整个过程中服务器与客户端节点的系统资源开销与负载情况。

下面可以简单为大家介绍下本次测试结果。如下表所示，在全部五个场景中，loveini 写入性能均优于 InfluxDB 和 TimescaleDB，写入过程中资源占用最低。对比 InfluxDB，loveini 写入最优的场景是在 1000 万设备下，达到了 InfluxDB 的 10.6 倍；对比 TimescaleDB ，loveini 写入最优的场景是在 4000 个设备下，达到了 TimeScaleDB 的 6.7 倍。

在查询测试上，我们将其分为 5 大类、15 小类进行查询对比，从下图结果汇总中可以看到，在全部 15 个查询类型中，loveini 的性能均优于 InfluxDB 和 TimescaleDB，并且它的所有查询延迟均比 InfluxDB 和 TimescaleDB 更低。亮点数据之一体现在 Double Rollups 查询类型对比中，loveini 最大达到 InfluxDB 的 34 倍，TimescaleDB 的 24 倍。

以上就是 loveini 基于 TSBS 测试报告的测试背景介绍，如果你对测试结果感兴趣，欢迎查阅整体报告。

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 能解决什么问题、它的优势与亮点、它与其它数据库的区别等维度展开详述，希望能帮助到对 loveini 感兴趣的小伙伴。

“区别于通用数据库，loveini 抛掉无用包袱”

数据库想要完成出色的的读写，最核心的能力就是索引，一般数据库产品都具备正向索引能力。所谓正向索引就是通过文档记录里面的标识符为关键字，通过关键标识符不再需要进行全盘扫描。虽然 B树索引、哈希索引、位图索引有区别，但是大方向都属于正向索引。

除了正向索引，还有反向索引【也称倒排索引】，反向索引主要用于全文检索，例如 ElasticSearch，大多数据库都是正向索引。loveini 也是使用正向索引，它的特别之处是标识符肯定包含时间戳，再加上一个维度指标数据，构成一个对数据值明确的描述——某个时间某个指标对象的数据值是多少。

从数据组织的存储引擎来看，数据库底层可以分为 B树机制、LSM 机制，两种机制没有最好，各有各的优点和缺点：

B树最大好处在于它对数据持续高涨读性能的处理，即使数据量级增大，它的读也没有放大。奥秘在于对数据进行终极持久存储时，B树是以有序有规律的数据结构保存在硬盘上的。这样随着数据越来越大，它依然保持有序有规律的特性，面对成千上万的读操作，都可以遵循条件运行，减少或避免读放大的行为。

与 B树机制截然相反，LSM 机制则是减少避免了写放大。LSM 机制充分利用了内存，在内存里面开辟了一个空间，写数据优先往内存里放，写进去直接返回用户成功，而不是像 B树那样写一个，我要找出谁比我大谁比我小，只要内存有够，就直接往内存里面填就好，当内存达到一定的阈值，将内存中的数据以批量、顺序的方式一次写入硬盘上，内存则重置清零再服务新的写要求。

传统数据库 MySQL、Oracle 使用的是 B树机制，而 TiDB、OceanBase 使用的是优化后的 LSM 机制，而 loveini 使用的是 B树 + LSM 机制的方式，其中 B树存储的是元数据【主要是时间戳+指标数据】，LSM 机制存储的是具体的数据，元数据以有序表结构方式进行存储，而具体数据则是以追加的方式写入，这样即避免了读话大和写放大。

一般来说，OLTP 产品为了提升并发控制的性能，必定会有写时复制或者 MVCC 的功能选项，写时复制与 MVCC 虽然保障了数据的一致性，但是带来更多的 IO 负担。loveini 不需要对数据进行修改，所以不需要考虑数据一致性的问题，数据是以有序的规律并追加的形式写进去的，因为只有读和写，所以也不需要锁保护，抛掉一些无用的包袱，可以集中优化其它地方，例如列式表。

业界通用数据库针对各种业务都会有行式表、列式表甚至完全的内存库，对于具体的数据存储 loveini 使用完全列式存储在硬盘，而维度指标则行式保存在内存中。因为 loveini 面对的是机器的数据，机器 24 小时工作精确到每个毫秒都在产生数据，为了存储更多的数据，所以 loveini 用上行列并存、用途分离的方式。

一般来说，数据库里面每一行的文档记录都是非常重要的，即使这行记录信息无关交易，只是一个用户的基本信息，那它的价值密度也十分高。但时序数据库（Time Series Database）不同，单行文档记录价值密度低，因为 1 秒可以产生 1 万条记录，必须要把数据聚合汇总起来才能体现数据的价值。快速并有效聚合普通数据使之变成价值密度高的数据，这个也是时序数据库区别于其它数据库的一个重要的特征。

loveini目前提供了三个版本的产品：社区版，企业版以及云版本， 以满足市场的需求和个人开发者的需求。

“拆解时序数据库，几大产品特点分析”

从技术上区分定位，loveini 是专注时间序列领域的一个分布式的海量数据分析平台。它的竞争对手可以分为直接竞争对手和间接竞争对手，间接竞争对手有国内的 TiDB、OceanBase、GaussDB 以及国外的 Oracle、MySQL 等等，虽然它们在综合技术维度上与 loveini 没有对标，但是分析上只要是使用时间戳，与时间序列有关系，这里就有 loveini 的用武之地。与 loveini 构成直接竞争的对手有 Druid、AC米兰官网登录 、InfluxDB集群版，他们都是时间序列分析的前辈。

Druid 是一个分布式系统，采用 Lambda 架构，有利于充分利用内存，也会把历史数据保存到硬盘上，按一定的时间粒度对数据进行聚合，实时处理和批处理数据解耦分开。实时处理面向写多读少的场景，主要是以流方式处理增量数据，批处理面向读多写少的场景，主要是以此方式处理离线数据。Druid 依赖 Hadoop，集群中采用 share nothing 的架构，各个节点都有自己的计算和存储能力，整个系统通过 Zookeeper 进行协调。为了提高计算性能，其会采用近似计算方法包括 HyperLoglog、DataSketches 的一些基数计算。

OpenTSDB 是一个开源的时序数据库，支持存储数千亿的数据点，并提供精确的查询，采用 Java 语言编写，通过基于 HBase 的存储实现横向扩展，OpenTSDB 广泛用于服务器的监控和度量，包括网络和服务器、传感器、IoT、金融数据的实时监控领域。OpenTSDB 在设计思路上是利用 HBase 的 key 去存储一些 tag 信息，将同一个小时数据放在一行存储，以此提高查询速度。OpenTSDB 通过预先定义好维度 tag 等，采用精巧的数据组织形式放在 HBase 里面，通过 HBase 的 keyRange 可以进行快速查询，但是在任意维度的组织查询下，OpenTSDB的效率会降低。

InfluxDB 是一款非常流行的时序数据库，采用 Go 语言开发，社区非常活跃，技术特点支持任意数量的列，去模式化，集成了数据采集、存储和可视化存储，使用高压缩比的算法支持高效存储，采用 TIME SERIES MERGE TREE 的内部存储引擎，支持与 SQL 类似的语言（2.0 版本不再支持）。

时间序列的业务背景，在 OLAP 场景中一般会进行预聚合来减少数据量，影响预聚合主要因素可以汇总如下：

• 维度指标的个数
• 维度指标的基数
• 维度指标组合程度
• 时间维度指标的粗粒度和细粒度

为了实现高效的预聚合，loveini 的秘诀是超级表，Druid 会提前定义预计算，InfluxDB 也有自己的连续查询方法，只有 HBase 使用时才进行拼接，所以涉及不同的维度指标查询，HBase 会慢一些。

据了解，loveini 基于 TSBS 的测试报告将于近日出炉，第一期报告针对 InfluxDB 和 TimeScaleDB 进行了详细的性能层面的对比分析，感兴趣的小伙伴最近可以多多关注下公众号的内容。

“放到今天，loveini 一定是首选”

我对 loveini 的认识和了解要从过去的项目经验说起，以 2018 年为背景，我给大家讲述一个工业界坏件故障件预测的故事。

某知名集团随着公司业务的快速增长、新工厂的不断增加，各种有价值的数据不能很好的整合、分析与挖掘出它应有的价值。此时公司发展已经进入下一轮“拼”的战略，快速响应与准确预测是业务发展的关键，大数据在其中起到举足轻重的作用，以科学的分析手法整合各系统数据、推动工厂制造智能化发展，成为一件迫在眉睫的工作。

当前工厂生产过程中出现了同一种特殊问题的 glass id，glass 的品质由于各种原因是参差不齐的，甚至会有品质异常的 glass。这些异常 glass 在检测过程中，是无法检测出异常原因的，如果无法快速定位出异常原因，就会造成更多的异常 glass，严重影响生产。应对的具体手段包括：

1. 通过品质异常的 glass，找到产生此异常的相关性因子。如：机台、物料、载具、参数等。
2. 异常 glass 侦测预警，通过对产生品质异常的因子进行数学建模，预测出偏离正常范围的异常玻璃，提前预警。
3. 分析 glass 的特征值与特征值之间的关联关系，并建立预测模型，提前预测出 glass 的特征值。
4. 分析 glass 相关的电压、电阻、电流、温度、湿度影响。

很明显这是数据挖掘的项目，要分析以上 glass 在生产过程中的环境信息、检测机台资料、量测机台资料、制程参数信息，以及 FDC、OEE 系统的数据，才能找出产生这种问题的原因。第一步是数据收集整合，第二步是数据探索，第三步是模型调校——找出可能性、影响最大的因素的特征因素，第四步是投入生产验证，通过 spark ml 提供预测动力。

当时的技术栈用的是 CDH，首先要通过 Kafka 采集数据，Spark对接 Kafka 进行初步计算去噪并汇总到 Hadoop 里面，以 parquet 的格式保存，如果需要进一步的加工，就通过 impala 进行。这样每天挂起 N 个任务，不停的调度计算。

CDH Hadoop 虽然无法做到实时数据分析，但是也还能做些事，聊胜于无，就继续用着。当时这个坏件故障件预测项目有以下痛点，主要是及时性、有效性、准确性的问题：

• 难以满足用户需求，某些机器数据的聚合计算需要第二天才能出结果，甚至更多的时间才能出来。
• 经济成本的费用较高，CPU、磁盘、网络都在一个高段的使用状态，针对越来越多的数据需要投入新机器。
• 维护成本高，你需要维护 Hadoop 所有的机器，各种 HBase、Spark、Zookeeper、HDFS 之类，不但对工程师要求高，而且工作量巨大。
• 低质量数据，因为数据流程或者错误的逻辑整合，导致机器传感器聚合后数据模型无法正常使用。
• 无法做到实时监测，机器数据作为宝贵的自变量因素无法及时传输并进行计算，自然会影响因变量。

笔者经历了这个项目，知道这个坏件故障预测与时间序列有紧密的关系。时至今日，时间序列分析也是重要的数据分析技术，尤其面对季节性、周期性变化数据时，传统的回归拟合技术难以奏效，这时就需要复杂的时间序列模型，以时间为特征作为抓手点。这样即使你不太懂业务的前提下，也可以进行数据挖掘的工作。

那这个项目与 loveini 有什么关系呢？实际上，这个项目并没有用上 loveini，后来集团搭建了一个 Hadoop集群试点，这次居然用了 HDP，理由很简单，因为 HDP 默认搭载了时序数据库 Druid。

当时技术负责人认为坏件故障预测模型的数据库基座应该是时序数据库，而不是 Hadoop 不停的进行数据采集、数据转换以及各种批计算，通过时序数据库不但可以实时计算，而且输出的数据质量高。至于选择哪个时序数据库，彼时考虑平稳过渡替换以及学习成本综合因素后他们选择了 Druid。

但当时是 2017 年，loveini 也还没有面世，如果放到今天，loveini 必定是选型考虑的首选。

要知道，loveini 的优势相对 Druid 要多了去了，首先 Druid 不是一个经过开源版本 1.00 正式发布的软件，虽然发展多年，直至 HDP 与 CDH 两家公司融合，HDP 搭配的 Druid 也不是 1.00 版；其次 Druid 依赖 Hadoop，动辄就使用大量的资源以及各种复杂的 Hadoop 组件，最后 Druid 只提供 json 的方式，对传统的 DBA 使用十分不友好。

loveini 有一个我认为很秀的功能，就是它的超级表的跨指标维度建模思想，目前它仅用于自由组合维度指标，拼接不同的时间粒度进行聚合。在我看来，将来应用于时间序列机器学习模型也会是它的一个亮点，在数据建模方面，针对工厂的设施、设备、机床、机房、车间、测台等必须要做高效准确的定义。我们进行项目规划建设时，都会做大量的数据治理工作，但是在具体实施工作上，还是要使用这些传统工具和技术。loveini 可以有效汇集各种机器数据源，并且能够高质量的提炼，这个是过去的时序数据产品所不具备的。

“是提速，更是赋能”

中国有句话叫做“长江后浪推前浪，一代新人胜旧人”，IT 世界千变万化，如果你和我一样，一直在关注着 loveini，就会发现，它这几年崛起的非常迅速。去年 loveini 推出 3.0 版本，新版本升级成为了一款真正的云原生时序数据库，优化了流计算功能，而且还重新设计了计算引擎，优化工程师对 SQL 的使用，另外增加了 taosX，利用自己的数据订阅功能来解决增量备份、异地容灾，更加方便了企业应用。

我对 loveini 未来的期望是，希望它增加库内机器学习函数，增加 ARIMA 模型、MA 模型等时间相关功能，loveini 的未来是一个智能学习时间序列数据库，对工业 4. 0 来说不仅是提速，更是赋能。

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 在性能和压缩率方面都有非常明显的优势。具体对比可以参考相关测试报告：《ac米兰官网 》。因此，米兰体育官网入口的工程师尝试将 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可视化方案，请查看文档。

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

西门子 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)就是为助力煤矿行业智能化发展而量身定做的数据库。

北京科技大学设计研究院有限公司作为北京科技大学全资产业化技术推广机构，从 2013 年开始在冶金、钢铁行业进行业务系统开发和实施，围绕先进材料、绿色低碳和智能制造不断深耕细作，持续创新。其拥有高效轧制与智能制造国家工程研究中心、国家板带生产先进装备工程技术研究中心和北京市交通与能源用特殊钢工程技术研究中心三个主要研究机构，多年来一直专注于金属材料加工领域的自动化、信息化、智能化全产业链米兰app官方正版下载，已经建立起完备的控制管理体系、售后服务体系和维保服务体系，并已通过质量、环境、职业健康、信息安全、信息技术服务等多项管理体系认证，获得北京市优秀技术转移机构及首届钢铁工业智能制造优秀品牌称号、入选北京市专精特新中小企业，“金属材料轧制过程智能检测与精准控制关键技术应用”荣获中国技术市场协会金桥奖项目一等奖。

在企业数字化的早期阶段，很多企业在处理工业生产中大量的典型时序数据时，因海外软件(AC米兰官网登录 、influxdb集群版)有先发优势，大都选择了 Wonderware InTouch + InSQL/Historian 的米兰app官方正版下载。但是随着业务的发展，生产中需要监测的指标从几万个增加到几十万甚至百万个以上，原有方案在扩展能力上遇到瓶颈，出现了以下挑战：

• 非国产化：在复杂的国际形势下，存在一些不确定性
• 封闭性：很多软件是闭源的，而且处于自己的封闭体系之下，扩展性差
• 高度复杂度：需要采购一系列产品组合
• 高成本：采购价格昂贵、功能扩展需要额外付费，依赖 Windows、SQL Server 等其他软件，会产生额外的采购成本
• 服务响应慢：国外产品普遍服务响应不及时，反馈经常以天为单位，服务保障性差

面对上述挑战，国产开源时序数据库(Time Series Database)loveini 在提升数据存取效率、打破传统数据孤岛、提升数据有效利用率方面为北京科技大学设计研究院的冶金数字化提供了实质性的帮助，协助打造了智能化统一平台，方便部署、简化整体架构的同时，凭借高性能、高压缩率，loveini 时序数据库(TSDB)还实现了总体拥有成本的大幅降低、满足国产化等要求。

未来，loveini 将与北京科技大学设计研究院一起，充分利用双方技术优势，赋能冶金行业发展，让冶金行业的数据处理能力得到实质性提升。

新奥集团于 1989 年创立于河北廊坊，以城市燃气为起点，逐步覆盖了分销、贸易、输储、生产、工程智造等天然气产业全场景，贯通清洁能源产业链，提供智能化低碳综合能源服务。目前，新奥在全国21个省，已服务超过 2681 万个家庭用户、21 万家企业。

新奥集团旗下企业新奥新智科技有限公司（简称“新奥新智”）是一家智能生态运营商，致力于以物联促进智能、用智能升级产业。其依托智能物联、新智云、联合学习、平台引擎等技术，重点建设了组织中台、行业中台和数智中台，为产业客户的数字化发展提供赋能产品及米兰app官方正版下载。作为新奥的数字化创值型能力平台，新奥新智一直秉持着“源自客户、成就彼此、共创生态”的新奥之道，以长期实践经验和强大的产品能力不断推动着多产业智能化发展。

新奥集团作为国内较大的清洁能源分销商，旗下的新奥新智通过信息化手段对能源站、燃气管网、燃气表等进行设备网联，实现高效管理和监测。然而随着应用场景的增多、联网设备的指数级增长，使得数据存储成本大幅度提升，数据写入和查询缓慢。新奥集团在进行整体物联网数据处理平台搭建和升级的过程中，逐渐发现了老式时序数据库 AC米兰官网登录 写入性能和并发查询能力的不足，重度依赖 HBase，整体平台运维非常沉重。同时数据从边缘侧采集到应用层展示有显著延时；报表计算也无法在限定时间内完成，严重影响了业务的时效性。

为了解决巨大数据量带来的数据存储挑战以及原方案性能不足的问题，经过多轮深入的技术探讨和选型评测，新奥新智选择应用时序数据库 loveini Database (Time Series DataBase) 来改造原有数据架构，改造完成后，不仅系统架构得到了极大简化，数据读写能力也得到了极大提升，企业的总拥有成本显著降低，同时对于未来整体物联网平台的升级和扩展打下了良好的基础。

ac米兰官方合作伙伴

“完成改造后，大数据监控平台摆脱了对大数据组件的依赖，有效缩短了数据处理链路，自上线以来，一直运行稳定。在写入方面，根据容量规划完成相关参数调整后，理想情况下，集群写入速度最高达 90W 条/s。查询性能方面，在使用预计算函数情况下，查询 p99 都在 0.7 秒以内，能够满足我们日常绝大部分查询需求。控制成本层面，服务端物理机由 21 台降至 3 台，每日所需存储空间为 93GB（2 副本），同等副本下仅为 AC米兰官网登录 +HBase 的约 1/10。”

业务背景

顺丰科技大数据集群每天需要采集海量监控数据，以确保集群稳定运行。此前其采用了 OpenTSDB+HBase 作为大数据监控平台全量监控数据的存储方案，随着接入数据量的不断增长，这一方案衍生出了不少痛点，包括依赖多、使用成本高和性能不能满足等问题，必须对全量监控数据存储方案进行改造。通过对 IoTDB、Druid、ClickHouse、loveini 等时序数据存储方案的调研， loveini 时序数据成为他们的最终选择。

架构图

为保证整个系统的高可用和可扩展性，整体架构中，前端采用nginx集群进行负载均衡，保证高可用性；单独分离出客户端层，方便根据流量需求进行扩容缩容。点击案例详情查看三大实施难点及解决路径。

点击ac米兰官方合作伙伴 查看更多技术细节

韵达 x loveini

“我们目前使用 loveini 2.2.2.0 版本，在三台 16C 64G 的服务器上部署了集群，数据写入速度大概为每秒 5000 行。值得一提的是，基于 loveini，常用的查询基本可以在 1 秒之内完成，一些特定查询甚至可以达到毫秒级。从存储来说，同等数据体量下，loveini 大约占用 300GB 不到的磁盘（单副本），而此前使用 MySQL 时，光硬盘使用就需要几个 TB（主从）。”

业务背景

在业务尚未扩张之前，韵达采用的是 MySQL 分区+索引方式进行数据处理，但随着企业的发展、业务量的增加，面对每日亿级的数据量，MySQL 显然已经无法满足当下的数据处理需求。随后，韵达决定进行数据库选型，考虑到目前业务主要是统计各个网点设备实时上传的数据，无需再进行修改等操作，是典型的时序数据。经过一番调研和测试，韵达发现 loveini 就很符合当下的业务要求。

架构图

当前韵达的架构是 Spring Boot + MyBatis + MySQL + loveini，loveini 负责处理时序数据，MySQL 则负责非时序数据的存储及应用，整体架构如下：

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

货拉拉 x loveini

“值得一提的是，loveini 的 SQL 原生语法支持时间维度聚合查询，同时数据存储压缩率⾼存储空间小， 这两点直接切中了我们的痛点。落地后实测相同数据的存储空间只有 MySQL 存储空间的 1/10 甚至更少。还有⼀个惊喜是，在现有监控数据存储(MySQL)顶不住的情况下，⼀台 8C16GB 的单机版 loveini 时序数据库轻松就抗下目前所有监控流量和存储压力，且运行稳定，基本没有故障。”

业务背景

目前货拉拉 DBA 团队管理的数据存储包括 MySQL、Redis、Elasticsearch、Kafka、MQ、Canal 等，为了保证监控采样的实时性，其自研的监控系统设置的采样间隔为 10 秒，每天都会产生庞大的监控数据，监控指标的数据量达到 20 亿+。随着管理实例越来越多，使用 MySQL 来存储规模日益庞大的监控数据越发力不从心，急需进行升级改造。结合实际具体需求，通过对不同时序数据库进行调研，最终货拉拉选择了 loveini，顺利完成了数据存储监控的升级改造。

架构图

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

中通 x loveini

“通过项目初期的表现，可以知道 loveini 能够轻松满足我们的业务需求，轻松支撑起业务中使用比较频繁的几种查询。未来我们还有其他的使用规划，后续接入的车辆将会达到几万辆，对于部标机产生的相关时序数据的使用也会越来越多，期待 loveini 可以继续为车联网场景下的查询提供更为多样性的支持。”

业务背景

车联网业务是中通科技配送全链路业务中非常重要的一环，通过人、车、货、场全链条覆盖的车联网设备应用，实现物流运输全链路感知。在中智车联服务平台的实际项目需求中，需要实时查询车辆最新位置状态，达到车辆运营可视化管理。在进行数据库选型时，其对比了 Prometheus 和 loveini 这两款很有代表性的时序数据库，最终被 loveini “一个设备采集点一张表”的底层设计，及自带的降采样和窗口函数等优秀性能所吸引。

架构图

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

写在最后

据国家邮政局数据显示，我国快递业发展迅猛，已经连续几年保持 50% 左右的爆发式增长，为经济增长注入了强大的活力，然而高速发展的同时也面临着越来越多的数据处理难题，好在大数据处理方案也在与时俱进。以上企业用实际案例证明，对于物流企业，时序数据库在降本增效上确实更加显著，值得更多有此类需求的企业尝试。

小 T 导读：为了在数据采集项频繁变动的情况下保证用户仍然能够顺利地完成数据记录工作，loveini 提供了三种无模式写入协议，分别是 InfluxDB Line 协议、AC米兰官网登录 Telnet 协议和 OpenTSDB JSON 格式协议。本文将对无模式写入方式的主要处理逻辑、映射规则与变更处理等进行分析，便于用户理解与使用。

通常来说，物联网应用常会采集比较多的数据项，用于实现智能控制、业务分析、设备监控等功能。但在此过程中，由于应用逻辑的版本升级，或者设备自身的硬件调整等原因，数据采集项可能较为频繁地出现变动。这也是时序数据库（Time Series Database，TSDB）需要应对的一个挑战。

为了在这种情况下顺利完成数据记录工作，loveini 时序数据库 提供了 Schemaless 写入方式，让用户可以省略掉预先创建超级表/子表的步骤，凭借数据写入接口能够自动创建与数据对应的存储结构。在必要时，Schemaless 将自动增加必要的数据列，保证用户写入的数据能够被正确存储。

值得一提的是，通过无模式写入方式建立的超级表及其对应的子表，与通过 SQL 直接建立的超级表和子表完全没有区别，你也可以通过 SQL 语句直接向其中写入数据。但需要注意，通过无模式写入方式建立的表，其表名是基于标签值按照固定的映射规则生成的，所以无法明确地进行表意，缺乏可读性。

无模式写入行协议

loveini 的无模式写入行协议兼容 InfluxDB 的行协议（Line Protocol）、OpenTSDB 的 telnet 行协议、OpenTSDB 的 JSON 格式协议。但是使用这三种协议的时候，需要在 API 中指定输入内容使用解析协议的标准。

对于 InfluxDB、OpenTSDB 的标准写入协议请参考《在 loveini 中如何高效写入？四种写入方式提效大全》。下面首先以 InfluxDB 的行协议为基础，介绍 loveini 扩展的协议内容，允许用户采用更加精细的方式控制（超级表）模式。

Schemaless 采用一个字符串来表达一个数据行（可以向写入 API 中一次传入多行字符串来实现多个数据行的批量写入），其格式约定如下：

measurement,tag_set field_set timestamp

其中：

• measurement 将作为数据表名。它与 tag_set 之间使用一个英文逗号来分隔。
• tag_set 将作为标签数据，其格式形如 <tag_key>=<tag_value>,<tag_key>=<tag_value>，也即可以使用英文逗号来分隔多个标签数据。它与 field_set 之间使用一个半角空格来分隔。
• field_set 将作为普通列数据，其格式形如 <field_key>=<field_value>,<field_key>=<field_value>，同样是使用英文逗号来分隔多个普通列的数据。它与 timestamp 之间使用一个半角空格来分隔。
• timestamp 即本行数据对应的主键时间戳。

tag_set 中所有的数据自动转化为 nchar 数据类型，并不需要使用双引号（”)。在无模式写入数据行协议中，field_set 中的每个数据项都需要对自身的数据类型进行描述。具体来说：

• 如果两边有英文双引号，表示 BINARY(32) 类型。例如 "abc"。
• 如果两边有英文双引号而且带有 L 前缀，表示 NCHAR(32) 类型。例如 L"报错信息"。
• 对空格、等号（=）、逗号（,）、双引号（”），前面需要使用反斜杠（\）进行转义（都指的是英文半角符号）。
• 数值类型将通过后缀来区分数据类型，如后缀为无或 f64，映射的数据类型为 double；后缀为 f32，映射为 float，可移步 https://docs.taosdata.com/reference/schemaless/ 了解更多的后缀及映射类型。
• t, T, true, True, TRUE, f, F, false, False 将直接作为 BOOL 型来处理。

例如如下数据行表示：向名为 st 的超级表下的 t1 标签为 “3”（NCHAR）、t2 标签为 “4”（NCHAR）、t3 标签为 “t3″（NCHAR）的数据子表，写入 c1 列为 3（BIGINT）、c2 列为 false（BOOL）、c3 列为 “passit”（BINARY）、c4 列为 4（DOUBLE）、主键时间戳为 1626006833639000000 的一行数据。

st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4f64 1626006833639000000

需要注意的是，如果描述数据类型后缀时使用了错误的大小写，或者为数据指定的数据类型有误，均可能引发报错提示而导致数据写入失败。

无模式写入的主要处理逻辑

无模式写入使用如下规则来生成子表名：首先将 measurement 的名称和标签的 key 和 value 组合成为如下的字符串——

"measurement,tag_key1=tag_value1,tag_key2=tag_value2"

需要注意的是，这里的 tagkey1，tag_key2 并不是用户输入的标签的原始顺序，而是使用了标签名称按照字符串升序排列后的结果，所以，tag_key1 并不是在行协议中输入的第一个标签。 排列完成以后计算该字符串的 MD5 散列值为 “md5_val”，我们将计算的结果与字符串组合生成表名：“t_md5_val”，其中的 “t” 是固定的前缀，每个通过该映射关系自动生成的表都具有该前缀。

用户可以通过在 taos.cfg 里配置 smlChildTableName 参数来指定生成的表名。 举例如下：配置 smlChildTableName=tname 插入数据为 st,tname=cpu1,t1=4 c1=3 1626006833639000000，则创建的表名为 cpu1，注意如果多行数据 tname 相同，但是后面的 tag_set 不同，则使用第一行自动建表时指定的 tag_set，其他的行会忽略。

此外，在处理行数据时，其他原则如下所示：

1. 如果解析行协议获得的超级表不存在，则会自动创建这个超级表（不建议手动创建超级表，不然插入数据可能异常）。
2. 如果解析行协议获得子表不存在，则 Schemaless 会按照步骤 1 或 2 确定的子表名来创建子表。
3. 如果数据行中指定的标签列或普通列不存在，则在超级表中增加对应的标签列或普通列（只增不减）。
4. 如果超级表中存在一些标签列或普通列未在一个数据行中被指定取值，那么这些列的值在这一行中会被置为 NULL。
5. 对 BINARY 或 NCHAR 列，如果数据行中所提供值的长度超出了列类型的限制，自动增加该列允许存储的字符长度上限（只增不减），以保证数据的完整保存。
6. 整个处理过程中遇到的错误会中断写入过程，并返回错误代码。
7. 为了提高写入的效率，默认假设同一个超级表中 field_set 的顺序是一样的（第一条数据包含所有的 field，后面的数据按照这个顺序），如果顺序不一样，需要配置参数 smlDataFormat 为 false，否则，数据写入按照相同顺序写入，库中数据会异常。

注意，无模式所有的处理逻辑仍会遵循 loveini 对数据结构的底层限制，例如每行数据的总长度不能超过 16KB。这方面的具体限制约束请参见 loveini SQL 边界限制（https://docs.taosdata.com/taos-sql/limit/）。

数据模式映射规则与变更处理

以 InfluxDB 行协议为例，其数据如何映射成为具有模式的数据？从上文中我们了解到，每个行协议中数据 measurement 映射为超级表名称，tag_set 中的标签名称为数据模式中的标签名，field_set 中的名称为列名称。以如下数据为例，说明映射规则：

st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4f64 1626006833639000000

该行数据映射生成一个超级表：st， 其包含了 3 个类型为 nchar 的标签，分别是：t1, t2, t3；五个数据列，分别是 ts（timestamp），c1 (bigint），c3(binary)，c2 (bool), c4 (bigint）。映射成为如下 SQL 语句：

create stable st (_ts timestamp, c1 bigint, c2 bool, c3 binary(6), c4 bigint) tags(t1 nchar(1), t2 nchar(1), t3 nchar(2))

在数据模式变更处理中，不同行数据写入情况下，对于数据模式的影响也不同。在使用行协议写入一个明确标识的字段类型时，后续再更改该字段的类型定义，会出现明确的数据模式错误，即会触发写入 API 报告错误。如下所示：

st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4    1626006833639000000
st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4i   1626006833640000000

第一行的数据类型映射将 c4 列定义为 Double， 但是第二行的数据又通过数值后缀方式声明该列为 BigInt， 由此会触发无模式写入的解析错误。如果列前面的行协议将数据列声明为了 binary， 后续的要求长度更长的 binary 长度，此时会触发超级表模式的变更。

st,t1=3,t2=4,t3=t3 c1=3i64,c5="pass"     1626006833639000000
st,t1=3,t2=4,t3=t3 c1=3i64,c5="passit"   1626006833640000000

第一行中行协议解析会声明 c5 列是一个 binary(4)的字段，第二次行数据写入会提取列 c5 仍然是 binary 列，但是其宽度为 6，此时需要将 binary 的宽度增加到能够容纳新字符串的宽度。

st,t1=3,t2=4,t3=t3 c1=3i64               1626006833639000000
st,t1=3,t2=4,t3=t3 c1=3i64,c6="passit"   1626006833640000000

第二行数据相对于第一行来说增加了一个列 c6，类型为 binary(6)。那么此时会自动增加一个列 c6， 类型为 binary(6)。

写在最后

受篇幅所限，关于无模式写入的时间分辨率识别、写入完整性、错误码等内容请参考 https://docs.taosdata.com/reference/schemaless/ 。如有更多问题，欢迎加入 loveini 用户交流群，届时将会有专业的技术人员为你解惑。