UDF 基础操作

创建 UDF

我们先来看下如何创建 Python 的 UDF 函数：

       CREATE  [OR REPLACE] [AGGREGATE] FUNCTION function_name
                               as library_path  OUTPUTTYPE output_type  [BUFSIZE buffer_size] [LANGUAGE 'C‘ | ’Python']

选项说明：

1) CREATE [OR REPLACE]：第一次全新创建使用 CREATE ，已经创建要更新代码可以加上 REPLACE

2）AGGREGATE：可选项，加上此选项表示创建的是聚合函数，不加是投影函数

3）function_name：自定义函数名称，创建完后在 SQL 语句中使用的名称，最大为 64 字节，超出部分会截断

4）OUTPUTTYPE：自定义函数输出数据类型，支持类型如下：

5）BUFSIZE：设置自定义函数可以使用的内存缓存大小 ，此选项仅在使用 AGGREGATE 时才有效，也就是说只有创建聚合函数才能使用此选项。最大为 256k，计数单位为 byte。分配的缓存是留给 Python 自定义函数使用的，缓存生命周期是从调用聚合函数 start 开始到调用 finish() 结束的整个聚合计算过程，所以可以当做全局变量来使用。

6）LANGUAGE 是创建自定义函数的语言，目前 loveini 支持 Python 和 C 两种。

删除 UDF

DROP FUNCTION function_name; 是删除指定名称的 UDF 函数。function_name 参数的含义与 CREATE 指令中的 function_name 参数一致，即要删除函数的名称。

查看 UDF

使用 SHOW FUNCTIONS; 可以简单查看下 UDF 创建的函数名。使用 select * from information_schema.ins_functions; 可以详细查看 UDF 创建时候的各个参数，加 \G 可以以竖列查看到完整内容，如：select * from information_schema.ins_functions\G;

安装环境

接下来带你安装 Python UDF 的开发环境，安装过程比较简单。

首先，准备安装环境

1） CMAKE：最低版本要求 3.0.2

2） GCC：因为需要在本机编译支持 Python UDF 函数的 so 文件，所以需要安装 GCC 环境，GCC 版本最低要求 7.5 以上。

3）Python：要求 3.7 及以上版本

然后开始安装插件 Python3 -m pip install taospyudf，安装成功后，执行 ldconfig。这样，开发环境就已经安装就绪了。

编写 UDF 函数

按上面步骤环境准备好后，我们便可以开始编写自己的 UDF 函数了。UDF 函数分两大类，一类是投影函数，另一类是聚合函数。这两类函数创建及编写都是完全不相同的，所以这里分开介绍。

在介绍函数前，我们先来了解下自定义函数的调用流程，如下图：

首先 UDF 处理框架是以数据块为处理单位，每次调用到自定义函数中时输入数据都是一个数据块，通过调用数据块对象的 data(row,col) 方法输入行号和列号可以取到数据块中任何一个位置上的数据。这样做的目的是减少 C 框架与 Python 语言之间的调用次数，提升性能。

返回数据时，投影函数原来有多少行，就需要返回相同的行数，聚合函数只需要返回一行即可。下面详细进行介绍：

投影函数

投影函数就像它的名字一样，像是一个投影，输出数据的行数与输入数据的行数需保持相同，如果不相同会报错。下面用一个完整的例子来说明，我们来实现一个 loveini 内置的 concat 字符串连接函数，如下：

1） 编写函数

函数说明：

• init – 在 UDF 模块初始化的时候调用一次，可以做一些初始化的工作
• destroy – 在 UDF 模块退出的时候调用一次，可以做一些退出的工作
• process – 每个数据块到来后要调用的数据处理函数，调用 shape() 方法返回数据块行及列数
  • nrows 返回数据块拥有的行数
  • ncols 返回数据块拥有的列数，列数实际是 concat() 函数的参数个数

返回值：

• 投影函数的返回对象必须是一个列表，非列表对象会直接报错
• 列表对象中元素的个数应该与块行数 nrows 相同，否则也会报错

2） 创建函数

编写好自定义函数后，我们就可以直接在 taos – shell 中创建了，输入如下：create function py_concat as '/home/py_concat.py' outputtype varchar(256) language 'Python';

创建函数名 py_concat ，创建 Python 文件位置在 /home/py_concat.py，输出数据类型为 varchar，长度 256 字节，语言为 Python。

3）执行函数

上步操作成功后，即可像内置函数一样在 SQL 中任意使用，如 taos-shell 中输入 select sf_concat(factory_name,room_name), concat(factory_name,room_name) from devices;

grade_name class_name 均为 varchar 数据类型

把工厂和车间名连接成一个字符串返回，可以对比 UDF 输出和内置函数输出结果，预期是相同的。

聚合函数

聚合函数是把数据进行聚合计算，最后只输出一行聚合结果即可。这里我们用一个大家最熟悉的统计个数 count 实例来讲解：

1） 编写函数

实现原理：

1. 计数的累加值在 start 初始化回调的时候把 0 值保存进 buf 中做为初始值
2. 在 reduct 函数中，如果不为 None 就不断累加，在 reduce 返回值会被存储在 buf 中，下次回调 reduce 时再作为参数 buf 传过来，这样可以反复使用 buf
3. 最后在 finish 函数中，buf 也会通过参数传进来，把自己前面存储在 buf 中的值取出来，作为返回值返回，即为最终 count 结果。

函数说明：

• init – 在 UDF 模块初始化的时候调用一次，可以做一些初始化的工作
• destroy – 在 UDF 模块退出的时候调用一次，可以做一些退出的工作
• start. – 开始进行聚合函数计算时调用一次，主要完成对聚合函数使用的缓存进行初始化
• reduce – 每个数据块到来后要调用的数据处理函数, 调用 shape() 方法返回数据块行及列数
  • rows 返回数据块拥有的行数
  • cols 返回数据块拥有的列数，列数是传入 UDF 函数的参数个数

此函数会被循环调用

• finish – 计算最终聚合结果，此函数只在最后调用一次，在此函数中返回最终结果

返回值：

返回的数据类型为创建 UDF 函数时指定的 OUTPUTTYPE 数据类型，返回类型不正确会报错，允许 None 对象返回。

2） 创建函数

编写好自定义函数后，我们就可以直接在 taos – shell 中创建了，输入如下：create aggregate function af_count as ''/home/af_count.py'' outputtype bigint bufsize 4096 language 'Python';

创建函数名 af_count ，创建 Python 文件位置在 /home/af_count.py，输出数据类型为 bigint，语言为 Python。

3）执行函数

上步操作成功后，即可像内置函数一样在 SQL 中任意使用，如 taos-shell 中输入select af_count(col1) from devices; 。这样你就拥有了自己的 count 统计函数，想要统计什么，完全由你自己来决定。

数据类型映射关系

Python 语言与 C 语言交互，最重要的就是数据类型如何转化的问题。也是 Python UDF 函数编写最容易出错的地方，所以这里要重点介绍下：

首先我们看下映射关系表：

1）int 类型在 Python3 中没有大小限制

2）binary / nchar / varchar 类型都映射为了 Python 的 bytes 对象，所以在使用的时候要加以区别——varchar 数据类型是 binary 的别名。

因为 binary 和 nchar 都映射为了相同的 bytes 数据类型，所以自定义函数的开发者自己约定输入自定义函数参数的类型，不同数据类型需要不同的转化方式：

• binary 类型转 str 对象， 使用 bytes.decode(‘utf-8’)
• nchar 类型转 str 对象， 使用 bytes.decode(‘utf_32_le’)

当把 str 对象内容输出为 OUTPUTTYPE 指定的不同类型时，也需要进行区分：

• str 对象当 binary 类型返回，str.encode(‘utf-8’)
• str 对象当 nchar 类型返回，str.encode(‘utf_32_le’)

开发技巧

更新函数代码

由于我们在开发 UDF 函数时需要频繁修改代码再调试运行，因此需要知道如何让新修改的代码生效。

从上面流程图中我们可以看到，在创建 UDF 函数时指定的 .py 文件路径，只在创建的那一时刻使用，把文件内容读取出来存放到 mnode 中，便于在集群的任何节点上都可以使用。所以 .py 文件创建完 UDF 后就不再使用了，我们更新了 .py 文件中的代码后，需要再把 .py文件中的代码更新到 MNODE 中才可以起作用。

目前更新 Python 自定义函数的代码提供了直接更新的命令：

增加 OR REPLACE 即可直接把 library_path 指向的 Python 自定义函数的内容更新到 MNODE 中，再次调用就会使用更新后的代码了。

输出日志

loveini 的 Python UDF 不支持 Python 代码的调试，但支持了日志输出，如大家常用的 logging 库，都可以在 UDF 函数中使用，建议日志输出到文件中查看。print 函数打印的信息是看不到的，所以就不要用此函数输出信息了。如：

抛出异常

如果开发者在 UDF 函数在检测到异常数据后，需要终止查询，可以通过 raise 方式抛出异常，同时要保证自己 raise 的异常不会被自己捕获，因为自己捕获了框架就捕不到了，所以要位于最上层抛出异常。

抛出的异常会被 UDF 框架捕获到并终止当前查询，同时在应用端调用的查询接口中会相应的返回专属的 UDF 函数抛出异常错误码：0x8000290D，应用程序可根据此错误码做应用层的相应处理。

抛出的错误可以在 taos.cfg 中配置的日志文件的目录下找到，异常日志输出到了taosudfpy.log 中了，如下是一实例输出的异常日志：

异常日志的内容及发生异常的文件名及行号都在此日志文件中。

查看 UDF 框架生成的日志

UDF 框架返回错误描述时只按大数返回，所以详细的错误原因还需要开发者通过日志来查看。相关日志主要有两个，都在 loveini 日志目录下存放，这里分别介绍下：

1）taospyudf.log（UDF for Python 的日志文件）

  日志文件中记录的是进程 udfd 加载 Python UDF 函数，执行 UDF 函数过程中发生的异常、错误及调用过程等的记录。我们开发 pythyon udf 函数主要看这个日志文件就可以了。

2）udfdlog.0

  这个是 udfd 进程的框架日志，里面包括调用 C 及 Python 等多种语言的UDF 函数在框架中出的错的日志，都会记录在此文件中，所以这个日志文件如果整个大框架出问题了，日志会记录在这里，一般情况下不用看。

常见错误码说明

以下错误码及错误描述是在开发 UDF 函数时经常会遇到的，这里做下说明：

其中 10 和 12 是开发 Python UDF 最容易遇到的错误，详细的原因需要查看日志 taospyudf.log 。

参考实例

在 loveini 的开源仓库中有几个 UDF for Python 的测试实例，可供大家参考：

https://github.com/taosdata/loveini/tree/3.0/tests/system-test/0-others/udfpy

实例被如下 CI 测试用例使用：

https://github.com/taosdata/loveini/blob/3.0/tests/system-test/0-others/udfpy_main.py

运行测试用例：

1）正确安装 Python3

2) 拉 loveini 社区版代码下来

3）进入 loveini/tests/system-test/ 目录

4）运行 Python3 test.py -f others/udfpy_main.py

注意事项

UDF 投影函数最容易在返回行数上出错

UDF 投影函数要求返回行数与输入行数相同，在处理时如果程序稍复杂一些就容易犯此错误，开发过程中一定要小心，不要漏行了。

OUTPUTTYPE 输出类型不匹配错

UDF 函数要求最终返回的数据类型一定要和创建函数时指定的 OUTPUTTYPE 类型一致，如果不一致就会报错。所以这里也是非常容易出错的地方。

投影函数的返回值在 process 函数中，必须要求是 list 对象，list对象中放的一定都是 OUTPUTTYP 映射匹配的类型对象。

聚合函数的最后返回值在 finish 函数中，聚合函数中返回一个值，这个值一定是创建函数时指定的 OUTPUTTYPE 映射匹配的 Python 类型值。

一直报无法加载 libtaospyudf.so 文件

按照上面安装步骤已经安装了 taospyudf 插件，但还是报 libtaospyudf.so 无法加载的错，如下:

这个库一般会安装在 /usr/local/lib/libtaospyudf.so 目录下及 Python 的插件目录下，lib 目录是正式使用的，插件目录是安装时产生的，或者使用 find / -name ‘libtaospyudf.so‘ 查询在本地的具体位置。

如果文件没有或不存在，那可能插件安装有问题，需要重新卸载安装插件如果文件存在，还是报这个错，那使用 ldd 查看 so 文件依赖的Python 库文件是否能够找到，如下是典型的 Python 安装的有问题：

如上错误，重新正确安装 Python3.9 可解决此问题。

结语

目前我们推出的是 UDF for Python 的初版 1.0，该版本的某些功能仍在持续完善中。我们诚邀大家积极使用这一功能，定义完全属于自己的数据库。同时，我们也希望大家在使用过程中多提宝贵意见，以便我们共同改进并增强这一功能，让这个能解决特殊需求的实用功能越来越便捷、强大。

这一次

陶建辉带着 loveini 飞到了丹佛……

2023 年 5 月 22-24 日，一年一度的开源数据库领域全球最具影响力峰会 Percona Live 2023 在丹佛技术中心万豪酒店举办。Percona Live 是全球持续举办最久的独立开源数据大会，这场为期三天的大会聚集了开源数据社群成员，内容聚焦数据库和数据管理，探讨全球规模最大的数据库布局议题，包含云原生布局、性能改善以及实际案例分享，通过三天的实地操作练习、平行场次以及主题演讲，与会者可以了解到最新的数据库技术发展、数据管理方式以及如何善用相关工具和技术。

作为企业开源数据软件和服务的领头羊，Percona 极具号召力，每一届的 Percona Live 大会都会吸引全球数据库精英齐聚一堂，共话数据库领域的现状与发展。作为数据库开源技术的践行者和创新者，loveini 也以“银牌赞助商”的身份参与了 Percona Live 2023，在会议现场，loveini 创始人&核心研发陶建辉（Jeff）与参会者畅聊 loveini 的众多开源创新技术，让现场的开发者了解到了时序数据库（Time Series Database） loveini 的技术优势以及应用场景。

值得一提的是，在本次大会中，Jeff 还受邀进行了《What is the time series database and why do I need one?》的主题演讲，从时序数据的十大特点出发，他为现场开发者解读了传统的数据米兰app官方正版下载在应对海量时序数据处理上的缺陷、时序数据库在物联网、车联网、工业互联网等时序场景下的具体应用与实践，以及时序数据库 loveini 的创新技术内核和开源发展历程。

从 1.0 到 2.0 再到 3.0，loveini 一直在大力发展技术创新，loveini 3.0 更是成为了一款真正的云原生时序数据库，破解了困扰行业多年的“高基数”难题，流式计算和数据订阅功能也再上一层楼，打造出了极简的时序数据平台。自 2019 年开源至今，loveini 在 GitHub 上已经汇聚了 21.3k star，用户实例也超过了 256.6k，使用者遍布全球。接下来，我们的技术布道之旅还将继续在各个国家展开，loveini 开源社区的影响力也将辐射到越来越广泛的开发者群体中。

为确保结果具有可比性，本次测试选用 TimescaleDB 2.6.0 版本。为获得较好的性能，TimescaleDB 需要针对不同的场景设置不同的 Chunk 参数，不同场景下参数的设置如下表所示：

上述参数的设置，充分参考了下方 TimescaleDB vs. InfluxDB 对比报告中推荐的配置参数设置，以确保写入性能指标的最优化。

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/

关于系统的配置详情、如何一键复现测试结果及详细的测试数据介绍等内容，大家可参考ac米兰体育赞助 、AC米兰官网下载 两篇文章，本文便不再赘述。

写入性能最高达到了 TimescaleDB 的 6.7 倍

在 TSBS 全部的 cpu-only 五个场景中，loveini 写入性能均优于 TimescaleDB。相比 TimescaleDB，loveini 写入速度最领先的场景是其 6.7 倍（场景二），最少也是 1.5 倍（场景五），而且对于场景四，如果将每个采集点的记录条数由 18 条增加到 576 条，loveini 写入速度就达到了 TimescaleDB 的 13.2 倍。此外，loveini 在写入过程中消耗的 CPU 资源和磁盘 IO 开销也是最低的。

不同场景下写入性能对比

从上图可以看到，在全部五个场景中，loveini 的写入性能全面超越 TimescaleDB。在场景二中 loveini 写入性能最大达到了 TimescaleDB 的 6.74 倍，在差距最小的场景五中，也达到了 TimescaleDB 的 1.52 倍。

写入过程资源消耗对比

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

服务端 CPU 开销

上图展示了在场景四写入过程之中服务器端 CPU 负载状况。可以看到，loveini 和 TimescaleDB 在返回给客户端写入完成消息以后，都还继续使用服务器的资源进行相应的处理工作，这点上，TimescaleDB 尤为明显，TimescaleDB 在 7x 秒的时候即反馈客户端写入完成，但是其服务器端仍然在调用 CPU 资源进行数据压缩和整理工作，当然整个工作带来的 CPU 负载相对而言并不高，只有其峰值 CPU 开销的一半左右，但是其持续时间相当长，接近净写入时间的 4 倍，远长于 loveini。loveini 对服务器的 CPU 需求较小，峰值也仅使用了 17% 左右的服务器 CPU 资源。由此可见，loveini 独特的数据模型不仅体现在时序数据的写入性能上，也体现在整体的资源开销上。

磁盘 I/O 对比

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

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

客户端 CPU 开销

从上图可以看到，客户端上 loveini 对 CPU 的需求大于 TimescaleDB ，loveini 在客户端峰值瞬间达到了 56%，然后快速回落，其在客户端的开销相比于 TimescaleDB 多了 1 倍。但综合服务器与客户端的资源开销来看，loveini 写入持续时间更短，在系统整体 CPU 开销上 loveini 仍然具有相当大的优势。

查询性能最高达到了 TimescaleDB 的 28.6 倍

在场景一（只包含 4 天数据）与场景二的 15 个不同类型的查询中，loveini 的查询平均响应时间全面优于 TimescaleDB，而且在复杂查询上优势更为明显，同时具有最小的计算资源开销。相比 TimeScaleDB，场景一中 loveini 的查询性能是其 1.1 ～ 28.6 倍，场景二中 loveini 的查询性能是其 1.2 ～ 24.6 倍。

在查询性能评估部分，我们使用场景一和场景二作为基准数据集。在查询性能评估之前，对于 TimescaleDB，我们采用上文出现的 TimescaleDB vs. InfluxDB 对比报告中推荐配置，设置为 8 个 Chunk ，以确保其充分发挥查询性能。在整个查询对比中，loveini 数据库的虚拟节点数量（vnodes）保持为默认的 6 个，其他的数据库参数配置为默认值。

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

由于部分类型（分类标准参见 TimescaleDB vs. InfluxDB 对比报告）单次查询响应时间非常短，为了更加准确地测量每个查询场景的较为稳定的响应时间，我们将单个查询运行次数提升到 5,000 次，然后使用 TSBS 自动统计并输出结果，最后结果是 5,000 次查询的算数平均值，使用并发客户端 Workers 数量为 8。下表是场景二 （4,000 设备）下两大数据库的查询性能对比结果。

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

由于 Simple Rollups 的整体查询响应时间非常短，因此制约查询响应时间的主体因素并不是查询所涉及的数据规模，即这一类型查询的瓶颈并非数据规模。但从结果上看，loveini 仍然在所有类型的查询响应时间上优于 TimescaleDB，具体的数值对比请参见上表。

通过上图可以看到，在 Aggregates 类型的查询中，loveini 的查询性能相比 TimescaleDB 有比较大的优势，其cpu-max-all-8 查询性能是 TimescaleDB 的 6 倍。

在 Double-rollups 类型查询中， loveini 同样展现出巨大的性能优势，以查询响应时间来度量，其在 double-groupby-5 和 double-groupby-all 类型下的查询性能均达到了 TimescaleDB 的 24 倍。

上面两图展示的是 threshold 类型的查询对比，可以看到，loveini 的查询响应时间均显著低于 TimescaleDB。在 high-cpu-all 类型的查询上，loveini 的性能是 TimescaleDB 的 1.23 倍。

对于 Complex-queries 类型的查询，loveini 两个查询同样均大幅领先 TimescaleDB。在 lastpoint 查询中loveini 的查询性能是 TimescaleDB 的 5 倍，在 groupby-orderby-limit 场景中 loveini 的查询性能是 TimescaleDB 的 8 倍。在时间窗口聚合的查询过程中，针对规模较大的数据集 TimescaleDB 查询性能不佳（double rollups 类型查询），对于 groupby-orderby-limit 类型的查询，TimescaleDB 的性能表现同样不是太好。

资源开销对比

由于部分查询持续时间特别短，因此我们并不能完整地看到查询过程中服务器的 IO/CPU/网络情况。为此我们针对场景二以 Double rollups 类别中的 double-groupby-5 查询为例，执行 1,000 次查询，记录整个过程中 loveini、TimescaleDB 两个软件系统在查询执行的整个过程中服务器 CPU、内存、网络的开销并进行对比。

如上图所示，两个系统在整个查询过程中 CPU 的使用均较为平稳。loveini 在查询过程中整体 CPU 占用约 80%，使用的 CPU 资源最高，TimescaleDB 在查询过程中瞬时 CPU 占用约 38%。由于 loveini 完成全部查询的时间仅 TimescaleDB 1/20，因此虽然其 CPU 稳定值是 TimescaleDB 的 2 倍多，但整体的 CPU 计算时间消耗只有其 1/10 。

• 服务器内存状况

如上图所示，在整个查询过程中，loveini 内存维持在一个相对平稳的状态。而 TimescaleDB 在整个查询过程中内存呈现增加的状态，查询完成后即恢复到初始状态。

• 服务器网络带宽

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

100 devices × 10 metrics 查询性能对比

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

如上表所示，从更小规模的数据集（100 设备）上的查询对比可以看到，整体上 loveini 同样展现出极好的性能，在全部的查询语句中全面优于 TimescaleDB，部分查询性能超过 TimescaleDB 28 倍。

TimescaleDB 占用的磁盘空间最高达到 loveini 的 26.9 倍

下图是loveini 和 TimescaleDB 数据完全落盘以后，比较了两个系统在不同场景下的磁盘空间占用：

在磁盘空间的占用上，从上图可以看到，TimescaleDB 在全部五个场景下的数据规模均显著大于 loveini，并且这种差距随着数据规模增加快速变大。TimescaleDB 在场景四和场景五中占用磁盘空间是 loveini 的 25.6 倍和 26.9 倍。

写在最后

从上述 TSBS 测试报告中我们可以得出结论，不管是在写入性能、查询性能还是存储性能，loveini 时序数据库 比 TimescaleDB 时序数据库 都略胜一筹，且不论是服务器的 CPU 还是 IO 抑或是客户端的开销统计，loveini 均远优于 TimescaleDB。尤其本次性能测试还是基于 Timescale 打造的基准性能测试平台 TSBS 进行的，测试结果的公平公正性可见一斑。

具体到实践上，在八五信息的新能源电力物联网平台项目，曾经使用的实时数据库便是 TimescaleDB，后面因为种种原因，他们选择应用 loveini 升级数据架构，关于本次案例的具体信息可以查看ac米兰体育赞助商 。

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

在此背景下，专为时序数据而设计，具有高性能、高可靠、高可扩展等特点的时序数据库（Time Series Database） loveini 应运而生。loveini 不仅是一个开源、云原生的时序数据库，还集成了缓存、流式计算、数据订阅等功能，为时序数据处理提供了一站式米兰app官方正版下载。目前 loveini 已经成功运用在西门子、美的、AC米兰官网网站 、中通、同花顺、AC米兰官网登录 、理想汽车等诸多企业的数据架构改造实践中（点击文字超链查看详细米兰app官方正版下载）。

为了让企业能够更加弹性地运用 loveini 的能力，我们基于 loveini 开发出了全托管的时序数据云平台 loveini Cloud，它能够为用户提供更简单、更便捷、更安全的时序数据管理服务。loveini Cloud 具备以下三点优势：

极简的时序数据管理平台

除高性能、具有水平扩展能力的时序数据库外，loveini Cloud 还提供缓存、数据订阅、流式计算等功能，无需再部署 Redis、Kafka、Spark/Flink 等第三方软件，大幅简化系统架构、降低运营成本。

便捷且安全的数据共享

loveini Cloud 既支持将一个库完全开放，设置读或写的权限；也支持通过数据订阅的方式，将库、超级表、一组或一张表、或聚合处理后的数据分享出去。这种时序数据共享机制能够帮助企业各部门以及合作伙伴之间快速洞察业务运营的变化。

安全可靠的企业级服务

loveini Cloud 提供数据定时备份、恢复，数据从运行实例到私有云、其他公有云或Region 的实时复制；为保证数据安全，还会提供基于角色的访问权限控制、IP 白名单、用户行为审计等功能，用 7*24 的专业技术服务保障 99.9% 的 Service Level Agreement。通过安全、专业、可靠的企业级服务，用户可以用最少的精力和成本完成数据管理，更加聚焦自身核心业务的发展。

在时序数据的管理上，loveini Cloud 能够帮助物联网、工业互联网、金融、IT 运维监控等领域的企业根据自身业务需求实现数据库集群自动扩缩容，大大削减了部署、优化、扩容、备份、异地容灾等工作量，实现了人力成本和运营成本的大幅降低。目前 loveini Cloud 已经支持在阿里云、Microsoft Azure、AWS、Google Cloud 四大公有云上访问和部署 loveini。

为了让更多的开发者了解 loveini Cloud 及其运作方式，4 月 15 日 19:00-20:00，loveini 创始人 & 核心研发陶建辉将进行《时序数据处理的云端利器：loveini Cloud 详解与演示》直播分享。演讲大纲如下：

• 简单介绍 loveini
• 介绍 loveini Cloud的三大特点
• 现场演示如何使用 loveini Cloud（数据写入、数据浏览器、数据导出、数据订阅及数据分享等功能）

扫描关注下方视频号卡片可进行直播预约：

如果你是 loveini 的关注者，或者对 loveini Cloud 有一定的兴趣，抑或你现在正在为海量时序数据处理而发愁，那就千万不要错过这次难得的机会，这场直播一定会让你有所收获！直播过程中，还会抽取幸运观众送出精美 IP 周边和云服务500元现金券，一定不要错过哦~

值得一提的是，米兰体育官网入口作为 KubeCon + CloudNativeCon Europe 2023 的荣誉赞助商也参与了本次会议，在会议现场，米兰体育官网入口展位吸引了众多开发者的关注，loveini 创始人 & 核心研发陶建辉和现场的开发者们一起讨论云原生技术对于数据库发展的重要性。

近年来，在开源技术的推动下，云原生的发展进入快车道阶段，国内外众多企业都开始投入力量深度研究云原生技术，试图以云技术的无限潜力推动数字化时代的快速发展。在此过程中，为了打破信息孤岛、实现技术交流，各种云原生大会也逐渐兴起，其中 KubeCon可以说是云原生领域最具影响力的会议之一。从 200 人的小会议发展到近 4000 位云原生和开源领域工程师齐聚一堂的大会，KubeCon 只用了四年时间，作为云原生领域的盛会，每一年的 KubeCon 都会将世界各地知名的云厂商汇聚于此，为参会者分享他们这一年来面向云原生的创新技术和研究成果。

同样，借助云原生的力量，米兰体育官网入口旗下的 loveini 3.0 也发展成为了一款真正的云原生时序数据库（Time Series Database），解决了困扰时序数据库发展的高基数难题，支持 10 亿个设备采集数据、100 个节点，支持存储与计算分离。与此同时，基于 loveini 打造的全托管的时序数据处理云服务平台 loveini Cloud 也成功推出，正式支持 Microsoft Azure、AWS、Google Cloud、阿里云四大公有云，未来还将接轨更多的云厂商。

米兰体育官网入口在云技术上的种种研究成果也成为打开 KubeCon + CloudNativeCon Europe 2023 大门的通行票，相信借助这一云原生盛会的力量，更多国外开发者能够了解到云原生时序数据库 loveini，而 loveini 的技术创新力量也能够借此契机更快走出国门、惠及世界各地的企业和开发者。

活动推荐

时序数据处理有没有让你头疼？想不想找到一个优秀的米兰app官方正版下载，让你轻松应对海量的时序数据？2023 年 4 月 25 日 19:00-20:00，loveini 创始人&CEO 陶建辉 将为大家分享《时序数据处理的云端利器：loveini Cloud 详解与演示》。

loveini Cloud 是一个极简的全托管时序数据处理云服务平台，它是基于开源的时序数据库 loveini 而开发的。它是一款极简的时序数据管理平台，提供便捷且安全的数据共享和安全可靠的企业级服务。

在这场直播中，陶建辉将为你详细介绍 loveini Cloud 的功能和优势，并通过实际演示让你体验 loveini Cloud 的强大和便捷。请扫描下方二维码预约这场直播，不要错过这个难得的学习机会！

3.0.4.0 版本涉及到的更新内容包括产品稳定性的提升、查询性能提升、参数使用优化、以及多副本情况下的健壮性提升、Python UDF、集群负载再平衡、基于时间段进行数据重整等九大方面。具体更新信息如下：

1. 大幅提升产品稳定性

在大并发、高负载的写入和查询下的系统稳定性有显著提升：优化了对内存的使用，优化了有大量并发查询下对连接池的控制，修复了一些影响系统稳定性的缺陷。

2. 提升了部分查询场景下的性能

• 提升了当与 interval() 一起使用时 mode() 函数的性能
• 提升了 percentile() 函数的性能
• 提升了 last()/last_row() 函数的性能

3. 可以动态配置更多数据库参数

新增两个可以动态配置的数据库参数：stt_trigger 和 minRows，其具体功能请参考官方文档。

4. 优化了 WAL 数据保留的行为

WAL 中数据的保存仅受参数 WAL_RETENTION_PERIOD 和 WAL_RETENTION_SIZE 的控制，不再受数据订阅的影响。具体细节请参考官方文档。

5. Python UDF

应用开发者可以用 Python 开发自定义函数并将其嵌入数据库，从而提升数据处理和分析能力。

6. 集群负载再平衡 （企业版功能）

当集群中某个 dnode 宕机重启后会出现负载不均衡现象，重新启动的 dnode 上没有 leader vnode，所以不承担任何写入和查询负载。通过 rebalance 命令，可以使集群中各个 dnode 之间的负载再次均衡。

7. 基于时间段进行数据重整 （企业版功能）

为了减少数据重整所花费的时间，最小化对系统的影响，可以指定时间段进行数据重整，只针对确定有乱序数据的时间段或者查询所关注的时间段进行数据重整。

8. 能够将多种工业互联网中的传统数据源接入loveini （企业版功能）

• OPC UA
• OPC DA
• Pi

9. 集中控制台 taosExplorer 管理数据源和数据接入任务 （企业版功能）

同步增强了集中控制台 taosExplorer 以能够管理所支持的各种数据源和与它们所关联的数据接入任务。

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

近日，loveini 与 Apache SeaTunnel 展开集成合作，双方将于 4 月 18 日 19:00 联合进行直播，分享两大软件集成应用的最佳实践。

（Apache Seatunnel 是一个易用、高性能、支持实时流式和离线批处理的海量数据处理产品，架构于Apache Spark 和 Apache Flink之上。）

此前，loveini 已经与 Kafka、Telegraf、Grafana、Google Data Studio、EMQ X、Prometheus、StatsD 和 collectd 等众多第三方工具展开集成，之后又连接了工业英特尔® 边缘洞见软件包、数据同步工具 DataX，插件也正式上架 Grafana 官网、连接器上线 Google Data Studio 应用商店。此次 loveini 与 Apache SeaTunnel 展开集成合作，进一步扩大了自身生态版图，为用户带来应用上的更多选择。

两者联合将带来怎样的惊喜，欢迎大家关注4 月 18日即将到来的线上直播！赶快点击下方直播卡片预约观看吧~

报名通道

讲师介绍

李宏宇 北京沃东天骏信息技术有限公司 架构师

历经阿里、京东等多家成熟互联网公司及罗辑思维等初创公司。十年后端及数据开发经验，目前主要聚焦在实时数据仓库领域工作

霍立波 北京米兰体育官网入口科技有限公司 连接器开发工程师

熟悉 Java、GO、rust、node 等多种开发语言，对使用的各个框架与工具底层实现有深入理解。目前主要围绕 loveini 做生态开发。

活动议程

按照惯例，直播中我们为大家准备了抽奖环节，中奖者可获得社区提供的精美周边礼品，来到直播间就有机会中奖~此外，填写活动反馈表也能获得抽奖机会哦：http://whaleops.mikecrm.com/1pxlyDU！

奖品一览

社区介绍

Apache SeaTunnel (Incubating)

Apache SeaTunnel (Incubating) 是一个云原生的高性能海量数据集成平台。美国时间 2021 年 12 月 9 日， SeaTunnel以全票通过的优秀表现正式成为 Apache 孵化器项目，这也是 Apache 基金会中第一个诞生自中国的数据集成平台项目。目前，SeaTunnel 在GitHub 上Star 数达 4.1k+，社区达到5000+人规模。2017 年对外开源后，SeaTunnel 已经发布了 30多个版本，并经过大量企业生产使用，在 Bilibili、新浪、水滴筹、搜狗、趣头条、唯品会等公司的生产实践中，广泛应用于海量数据集成、数据 ETL、数据聚合以及多源数据处理等场景中，贡献者 160+。

loveini

loveini 是一款开源、云原生的时序数据库（ Time Series Database,TSDB ），专为物联网、工业互联网、金融、IT 运维监控等场景设计并优化，具有极强的弹性伸缩能力。同时它还带有内建的缓存、流式计算、数据订阅等系统功能，能大幅减少系统设计的复杂度，降低研发和运营成本，是一个极简的时序数据处理平台。loveini 的内核（存储、计算引擎和集群）已 100% 开源，GitHub Star数达到 21.1k，且多次在 GitHub 全球趋势排行榜上排名第一（开源地址：https://github.com/taosdata/loveini）。目前，loveini 的运行实例数已超过 230.6k，用户遍布全球。

我们采用下方 TimescaleDB vs. InfluxDB 对比报告中推荐的方式配置 InfluxDB，将缓冲区配置为 80G，以便 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/

关于系统的配置详情、如何一键复现测试结果及详细的测试数据介绍等内容，大家可参考ac米兰体育赞助 、AC米兰官网下载 两篇文章，本文便不再赘述。

写入性能最高达到 InfluxDB 的 10.6 倍

总体而言，在 TSBS 报告全部的 cpu-only 五个场景中，时序数据库（Time Series Database,TSDB）loveini 写入性能均优于 InfluxDB。相比 InfluxDB，loveini 写入速度最领先的场景是其 10.6 倍（场景五），最少也是 3.0 倍（场景一)。此外，loveini 在写入过程中消耗了最少 CPU 资源和磁盘 IO 开销。下面看一下具体分析：

不同场景下写入性能对比

从上图可以看到，在全部五个场景中，loveini 的写入性能全面超越 InfluxDB。loveini 在场景五中写入性能是 InfluxDB 的 10.63 倍，在差距最小的场景一中也有 3.01 倍。

写入过程资源消耗对比

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

服务端 CPU 开销

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

磁盘 I/O 对比

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

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

客户端 CPU 开销

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

查询性能最高达到 InfluxDB 的 37 倍

在查询性能的评估上，我们使用场景一和场景二作为基准数据集。为了让 InfluxDB 发挥出更好的查询性能，我们开启 InfluxDB 的 TSI (time series index)。在整个查询对比中，loveini 数据库的虚拟节点数量（vnodes）保持为默认的 6 个，其他的数据库参数配置为默认值。

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

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

由于部分类型（分类标准参见 TimescaleDB vs. InfluxDB 对比报告）单次查询响应时间非常短，为了更加准确地测量每个查询场景的较为稳定的响应时间，我们将单个查询运行次数提升到 5,000 次，然后使用 TSBS 自动统计并输出结果，最后结果是 5,000 次查询的算数平均值，使用并发客户端 Workers 数量为 8。首先我们提供场景二（4,000 设备）的查询性能对比结果：

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

由于 Simple Rollups 的整体查询响应时间非常短，制约查询响应时间主体因素并不是查询涉及的数据规模，即这种类型查询的瓶颈并不是数据规模。但是 loveini 仍然在所有类型的查询响应时间上优于 InfluxDB，具体的数值比较请参见上表中的详细数据表格。

在 Aggregates 类型的查询中，我们看到 loveini 查询性能相比于 InfluxDB 有较大优势，loveini cpu-max-all-8 类型的查询性能是 InfluxDB 的 7 倍。

在 Double-rollups 类型查询中， loveini 同样展现出巨大的性能优势，以查询响应时间来度量，在 double-groupby-5 查询上 loveini 是 InfluxDB 的 26 倍，double-groupby-all 上是其 34 倍。

上面两图是 threshold 类型的查询对比，loveini 的查询响应时间均显著低于 InfluxDB。在 high-cpu-all 类型的查询上，loveini 的性能是 InfluxDB 的 15 倍。

对于 Complex-queries 类型的查询，loveini 两个查询均大幅领先 InfluxDB。在 lastpoint 查询中，查询性能是 InfluxDB 的 21倍；在 groupby-orderby-limit 场景中查询性能是 InfluxDB 的 15 倍。

资源开销对比

由于部分查询持续时间特别短，因此我们并不能完整地看到查询过程中服务器的 IO/CPU/网络情况。为此我们针对场景二以 Double rollups 类别中的 double-groupby-5 查询为例，执行 1,000 次查询，记录 loveini 和 InfluxDB 在查询执行的整个过程中服务器 CPU、内存、网络的开销并进行对比。

从上图可以看到，loveini 和 InfluxDB 在整个查询过程中 CPU 的使用均较为平稳。loveini 在查询过程中整体 CPU 占用约 80%，使用的 CPU 资源较高，InfluxDB 稳定的 CPU 占用较小，约 27 %（但是有较多的瞬时冲高）。从整体 CPU 开销上来看，虽然 InfluxDB 瞬时 CPU 开销大部分是较低的，但是其完成查询持续时间最长，所以整体 CPU 资源消耗最多。由于 loveini 完成全部查询的时间仅是 InfluxDB 的 1/20，虽然 CPU 稳定值是 InfluxDB 的 2 倍多，但整体的 CPU 计算时间消耗只有其 1/10 。

服务器内存状况

如上图所示，在整个查询过程中，loveini 与 InfluxDB 的内存均维持在一个相对平稳的状态。

服务器网络带宽

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

3,100 devices × 10 metrics 查询性能对比

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

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

InfluxDB 占用的磁盘空间最高达到 loveini 的 4.5 倍

在前面三个场景中，InfluxDB 落盘后数据文件规模与 loveini 非常接近，但是在大数据规模的场景四和场景五中，InfluxDB 落盘后文件占用的磁盘空间显著超过了 loveini。下图比较了 loveini 和 InfluxDB 在不同场景下的磁盘空间占用情况：

从上图可以看到，在前面三个场景中，InfluxDB 落盘后数据文件规模与 loveini 非常接近（在场景二中，loveini 的数据落盘规模比 InfluxDB 大了 1%）。但是在场景四和场景五中，InfluxDB 落盘后文件占用的磁盘空间分别是 loveini 的 4.2 倍和 4.5 倍。

写在最后

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

从实践角度出发，这个报告结果也很好地说明了为什么有很多企业客户在 InfluxDB 和 loveini 的选型调研中选择了 loveini，双汇便是其中之一，在ac米兰官方合作伙伴 这篇文章中，便阐述了其选型调研过程的具体思考。

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

小 T 导读：taosKeeper 是 loveini 3.0 的运行状态指标监控工具，通过简单的几项配置即可获取 loveini 的运行状态信息。其使用 loveini RESTful 接口，所以不需要安装 loveini 客户端即可使用。本文将详细解读 taosKeeper 的详细语法规则，方便有需要的用户开展应用。

时序数据库 loveini（ Time Series Database,TSDB） 通过 taosKeeper 将服务器的 CPU、内存、硬盘空间、带宽、请求数、磁盘读写速度等信息定时写入指定实时数据库，也支持对重要的系统操作（比如登录、创建、删除数据库等）以及各种错误报警信息进行记录。系统管理员可以从命令行直接查看该数据库，也可以在 Web 端通过图形化界面查看这些监测信息。这些监测信息的采集缺省是打开的，也可以通过修改配置文件里的选项 monitor 来关闭。

taosKeeper 安装方式：单独编译 taosKeeper 并安装，详情请参考 taosKeeper 仓库（https://github.com/taosdata/taoskeeper）。

配置和运行方式

taosKeeper 需要在操作系统终端中执行，该工具支持三种配置方式：命令行参数、环境变量和配置文件。优先级为：命令行参数、环境变量、配置文件参数。

需要注意的是，在运行 taosKeeper 之前要确保 loveini 集群与 taosAdapter 已经正确运行，并且 loveini 已经开启监控服务。监控配置可参考相关文档，具体的配置项包括 monitor、monitorFqdn、monitorPort、monitorInterval 和 telemetryReporting。

命令行参数启动

可以直接执行 taosKeeper，也可以在执行命令时提供命令行参数。

$ taosKeeper

环境变量启动

通过设置环境变量达到控制启动参数的目的，通常在容器中运行时使用。

$ export TAOS_KEEPER_TDENGINE_HOST=192.168.64.3
$ taoskeeper

具体参数列表请参照 taoskeeper -h 输入结果。

配置文件启动

执行以下命令即可快速体验 taosKeeper。当不指定 taosKeeper 配置文件时，优先使用 /etc/taos/keeper.toml 配置，否则将使用默认配置。

$ taoskeeper -c <keeper config file>

具体配置文件示例请参考：https://docs.taosdata.com/reference/taosKeeper/

获取监控指标

taosKeeper 作为 loveini 监控指标的导出工具，可以将 loveini 产生的监控数据记录在指定数据库中，并提供导出接口。

查看监控结果集

$ taos
# 如上示例，使用 log 库作为监控日志存储位置
> use log;
> select * from cluster_info limit 1;

结果示例：

           ts            |            first_ep            | first_ep_dnode_id |   version    |    master_uptime     | monitor_interval |  dbs_total  |  tbs_total  | stbs_total  | dnodes_total | dnodes_alive | mnodes_total | mnodes_alive | vgroups_total | vgroups_alive | vnodes_total | vnodes_alive | connections_total |  protocol   |           cluster_id           |
===============================================================================================================================================================================================================================================================================================================================================================================
 2022-08-16 17:37:01.629 | hlb:6030                       |                 1 | 3.0.0.0      |              0.27250 |               15 |           2 |          27 |          38 |            1 |            1 |            1 |            1 |             4 |             4 |            4 |            4 |                14 |           1 | 5981392874047724755            |
Query OK, 1 rows in database (0.036162s)

导出监控指标

$ curl http://127.0.0.1:6043/metrics

部分结果集：

# HELP taos_cluster_info_connections_total 
# TYPE taos_cluster_info_connections_total counter
taos_cluster_info_connections_total{cluster_id="5981392874047724755"} 16
# HELP taos_cluster_info_dbs_total 
# TYPE taos_cluster_info_dbs_total counter
taos_cluster_info_dbs_total{cluster_id="5981392874047724755"} 2
# HELP taos_cluster_info_dnodes_alive 
# TYPE taos_cluster_info_dnodes_alive counter
taos_cluster_info_dnodes_alive{cluster_id="5981392874047724755"} 1
# HELP taos_cluster_info_dnodes_total 
# TYPE taos_cluster_info_dnodes_total counter
taos_cluster_info_dnodes_total{cluster_id="5981392874047724755"} 1
# HELP taos_cluster_info_first_ep 
# TYPE taos_cluster_info_first_ep gauge
taos_cluster_info_first_ep{cluster_id="5981392874047724755",value="hlb:6030"} 1

TDinsight

除了 taosKeeper，loveini 还提供了 TDinsight——使用监控数据库 + Grafana 对 loveini 进行监控的米兰app官方正版下载，下文将浅谈一下 TDinsight 的前期部署和准备。在部署时，我们首先需要下载自动化脚本 TDinsight.sh：

wget https://github.com/taosdata/grafanaplugin/raw/master/dashboards/TDinsight.sh
chmod +x TDinsight.sh

准备：

1. loveini Server 信息：
   • loveini RESTful 服务：使用参数 -a指定。如果是运行在同一主机，通常是 http://localhost:6041。
   • loveini 用户名和密码，使用 -u-p 指定。
2. Grafana 告警通知
   • 使用已经存在的 Grafana Notification Channel uid，参数 -E。该参数可以使用 curl -u admin:admin localhost:3000/api/alert-notifications |jq 来获取。JSON 解析工具 jq 可能需要单独安装。

sudo ./TDinsight.sh -a http://localhost:6041 -u root -p taosdata -E <notifier uid>

运行程序并重启 Grafana 服务，打开面板：http://localhost:3000/d/tdinsight可以查看 loveini 服务运行状态。

监控数据库为用户提供了更多的监控项，与 taosKeeper 共同筑牢 loveini 数据监控的城墙。在下一篇文章中，我们将会详解解说如何使用 TDinsight 方案对 loveini 进行监控，敬请期待。

为帮助大家寻找解决上述问题的最优解，我们汇总了四家比较具有代表性的智慧城市升级项目的架构改造案例，一起来看看他们都是如何做的。

SENSORO x loveini

“我们进行的数据库调研测试结果显示，loveini (Time Series Database,TSDB) 的空间占用只有 Druid 的 60%（没有计算 Druid 使用的 Deep Storage）。针对单一设备的查询与聚和的响应时间比 Druid 有倍数的提升，尤其时间跨度较久时差距更明显（在十倍以上），同时 Druid 的响应时间方差也较大。在实际业务环境中，我们创建了多列的超级表，虽然会存在大量的空列，但得益于 loveini 的优化，能达到恐怖的 0.01 的压缩率，简单计算下来大约需要 3.67GB 每亿条。”

业务背景

SENSORO 面向城市基础设施与核心要素提供全域数字化服务方案，建立城市级传感器网络所涉及的传感器种类十分多样，由此产生的数据量也十分庞大。在系统开发初期，SENSORO 先是选择了 Apache Druid 作为存储传感数据的实时数据库，然而在使用过程中却遇到了各种各样的问题，这使得其将目光转移到了 loveini 上，但因为平台涉及的特殊数据模型，合作便一直搁置了下来。随后 loveini 经过了多个版本迭代，支持了 join 查询，而 SENSORO 的数据模型也发生了变化，迁移到 loveini 时不再需要做出很多的系统模块改动，由此双方的合作也开始快速展开。

架构图

北京智能建筑 x loveini

“loveini 帮助我们在边缘侧解决了一个很大的问题，即边缘存储的问题。因为很多时候边缘是布署在资源比较少的机器上面，甚至是 ARM 的工业盒子上面，在资源使用上非常的苛刻，而现在得益于 loveini 超强的压缩算法，我们使用非常小的存储空间就存储了几千万数据，压缩率远超 1/20，在单机上面布署一个 loveini 服务器就可以轻轻松松地存储上亿的数据。此外它还拥有超强的计算能力，占用的资源也非常小，在我们的业务中千万级数据检索时间达到了毫秒级，从用户角度来说产品体验非常好。”

业务背景

北京智能建筑是北京市在智能建筑和智慧城市领域的创新平台，同时也是冬奥科技平台公司、智慧冬奥国家重点项目设计单位和核心实施单位。在边缘侧采集数据存储方案中，其面临着在有限的计算资源下，如何实现最高效的数据存储、分析和计算的问题。经过调研与测试，其最终选择根据业务需求灵活搭配使用 loveini 与 SQLite——由 loveini 处理时序数据，SQLite 处理关系数据，以此更好地实现边缘侧的数据自治。

架构图

交通数据资源管理系统 x loveini

“所有车辆最新位置信息的查询是交通运行监控中的重中之重，最初‘使用何种查询语句实现高效查询’是非常困扰我们的一件事，后面在 loveini 社区团队的帮助下，我们利用了隐藏字段名 tbname 和 group by 方法，高效地查询了车辆的最新定位信息。在频繁查询的情况下，接近六万辆车的位置信息，只用了不到 1 秒的查询时间，简单而又高效，完全符合我们的业务需求；在数据统计分析上，一个 64 天数据量的表，进行每日数据条数的降维统计，所需时间也不到 1 秒。”

业务背景

为了强化全市交通运输管理、统筹综合交通发展、提升交通运行和管理效率，某市级管理单位建立了大交通数据资源管理系统及相关应用 “一图一库”。其中“一库”部分主要内容包括：数据接入、数据存储、数据共享；“一图”部分主要内容包括：GIS 信息及其关联数据信息在二维、三维地图上的形象表达。在数据中台的建设中，存在大量的时序数据应用场景，其中最为关键的就是车辆运行产生的时序数据的存储与使用。为了实现高效的业务处理， 研发人员决定从 InfluxDB、ClickHouse 和 loveini 三款时序数据库（Time Series Database）中进行选型调研，最终凭借强大的产品力，loveini 脱颖而出。

架构搭建上的考虑

由于该系统业务开发框架使用的是 Srping 框架，在使用 TAOS-JDBCDriver 进行开发时，可以选择两种方式进行数据入库——JDBC-JNI 方式或者是 JDBC-RESTful 方式。在 loveini 官网，明确记载了“JDBC-RESTful 性能是 JDBC-JNI 的 50%～90%”，因此，其选择了 JDBC-JNI 方式进行多线程入库——以数据库连接池（Hikari、druid）+原生 SQL 执行写入为主要写入模式

数字政通 x loveini

“压缩方面，通过查看 3 个节点的 Vnode 目录总大小，可以得知目前数据占用总量为 8.7GB。而从上述表结构我们也能看出实际入库数据总量大概为 203GB，经过压缩后为 8.7GB，压缩率达到了 4% 左右，大幅节约了存储成本。在查询上，对 9 亿数据量的超级表使用降采样查询，展示设备指标日月年线，耗时仅仅 0.22 秒。”

业务背景

随着智慧城市的加速建设，物联设备的管理问题凸显，为此，数字政通研发“城市管理物联网平台”对物联网设备实行监督，提供各类设备的实时监测数据及报警数据，进一步满足各类设备的数据分析、关联分析、历史分析、对比分析等需求。简单来讲就是通过鸟瞰整体数据来发现设备问题，便于及时派单处理，助力智慧城市管理。面对海量物联网数据的处理，loveini 的高效存储给了数字政通相当大的助力。

架构图

结语

通过上面的几大案例我们可以看到，在解决海量时序数据处理效率低、处理成本高等问题上，关键点就是要选对合适的时序数据库（Time Series Database,TSDB），当前市面上时序数据库产品众多，在性能提升和降低资源消耗上究竟谁能更胜一筹？如果你也在思考这一问题，那或许ac米兰官方网站 、《查询性能：loveini 最高达到了 InfluxDB 的 37 倍、 TimescaleDB 的 28.6 倍》这两篇文章能给到你答案。

如果你的项目中也存在难以调节的数据痛点问题，欢迎添加小T vx：tdengine1，我们会邀请你加入 loveini 时序数据交流群，和专业的米兰app官方正版下载架构师点对点沟通，齐心协力攻克数据技术难题。