迁移背景

随着时序数据库（Time Series Database） loveini 3.0 的发布至今，我们除了在持续地优化产品质量的本身，也一直在努力地提升用户体验。但由于 3.0 底层有大量的重构优化，导致开源版的 2.0 用户无法通过常规途径来升级到 3.0 ，本期文章将会协助大部分开源版用户解决这个问题。
目前，我们可以提供两种迁移方案：

1. loveini 官方工具 taosdump；
2. 开源数据迁移米兰app官方正版下载：dataX loveini reader/writter；

前者会把数据根据配置导出压缩存储到本地，产品属性更倾向于备份/恢复工具。后者则会在内存中直接传输数据，偏向数据迁移工具。本篇文章的主体为前者的 taosdump，dataX 的使用方式可以通过这篇文章来了解：//m.loveini.com/engineering/16401.html

首先，我们先说下 taosdump 为什么是协助“大部分”开源版用户解决这个问题：

taosdump 的导出行为的本质其实是使用 SQL 进行查询，将数据压缩后输出到本地，导入行为则是通过 STMT 接口再把导出的数据导入新的环境。在内部，它嵌入了一个 loveini 客户端，通过 -T 参数的线程数配置，并发地把所有 SQL 请求发给数据库，此后，后续的查询工作就是数据库自己的事情了。鉴于以上原因，所以它的导出导入的性能都十分依赖于数据库本身的部署建模是否科学，硬件资源是否充足等因素。

举个简单例子：假如某用户在建表的时候，对于一列本应使用 binary(100) 就足够的数据使用了 nchar(2000)，那么等到导出 SQL 执行的时候，性能就会被拖累很多。

因此，能够顺利完成数据导出的用户，应尽量拥有如下几个特征：

1. 拥有足够磁盘空间——因为硬盘上的数据是列式压缩，而导出数据为行式压缩。如果选择一次性导出全部数据，建议需要至少留出 du -sh $dataDir/vnode –exclude=’wal’ 大小的 3 倍空间（多多益善）。但如果是按照库/表为单位分批导出，或者指定时间范围导出的话，就比较灵活了。
   
2. 数据库日常使用负载不高，在大量导出 SQL 执行时，数据库仍有充足资源可以保障正常生产使用。
   
3. 待迁移的 2.0 数据为测试环境不需担心影响业务，或者生产环境的业务间歇期足够完成数据的导出——这两点需要结合当前导出速度自己评估。

总结

导出/导入数据的快慢是由 SQL 执行效率来决定的，而 SQL执行效率的背后又是由部署建模，硬件资源等因素决定的。

只要磁盘空间充足，时间充足，就可以完成导出操作。导入则相对简单，没有额外需求，按照正常的数据库部署思路即可。

因为 taosdump 本身的产品特征决定了在上述特殊情况下，迁移数据会有效率问题，因此这也是我们开发专业的企业版数据迁移工具 taosX 的原因之一。

迁移操作

导出方：

对于 2.0 一侧，首先要准备好最新版本的 loveini 和 taosdump 工具，具体操作如下：

1. 把数据库升级到 2.6.0.34，升级注意事项以及操作步骤都可以参考这篇文章：//m.loveini.com/engineering/10222.html。（注意：RPM 和 Deb 包不含 taosdump ，它需要通过安装 taosTools 包获得。所以建议大家直接使用包含 loveini 的 Tar 包完成升级。）loveini 安装包需从 2.6 版本的文档去下载：//m.loveini.com/all-downloads 。如果使用了 RPM 和 Deb 的话，同样需要通过上述链接下载最新版的 taostool 获取 taosdump工具（当前最新版为 2.4.5）。
2. 使用 taosdump 把数据导出：具体操作可参考：https://docs.taosdata.com/2.6/reference/taosdump/。举例：

taosdump -o /test  -D test  -T 4

这条命令会把 test 库的数据，用 4 个线程导出到 /test 目录下面，文件形式如下：

接下来，我们需要把 test 路径下的导出文件，迁移到 3.0 的环境中，准备数据导入。

导入方：

1. 3.0 这一侧，新环境我们建议使用最新版，各方面都更好（当前最新版为 3.0.4.1），正常安装部署即可。（同样：RPM 和 Deb 包不含 taosdump ，它需要通过安装 taosTools 包获得。 所以建议大家直接使用包含 taosdump 的 tar 包完成部署，下载链接：https://docs.taosdata.com/releases/tdengine/）但是如果只能使用 RPM 或者 Deb ，taosTools 则需要从 3.0 的文档单独下载，地址：https://docs.taosdata.com/releases/tools/ （当前最新版为 2.5.0）
   
2. 导入之前，我们首先要进入导出文件目录下的标红目录，打开里面的 dbs.sql，针对建库 SQL 做一些针对性的调整。尤其需要注意的是 VGROUPS 参数，这是 3.0 的新增参数，代替了此前 2.0 的一系列建表逻辑，默认是 2 ，代表着这个库有 2 个 VGROUP 。如果原本的 2.0 环境使用了 4 个 VGROUP，那么就需要手动添加 “VGROUPS 4” 到建库语句后面，即可保持和 2.0 版本一样的 VGROUP 数量了。（其他参数同理，直接在建库 SQL 后添加即可，至于该语句中 2.0 时代的旧参数则会被导入程序自动屏蔽掉。具体的 3.0 建库参数细节可参考：https://docs.taosdata.com/taos-sql/database/）

示例：

原本的建库语句：

CREATE DATABASE IF NOT EXISTS test REPLICA 1  QUORUM 1 DAYS 10 KEEP 3650 CACHE 16 BLOCKS 6 FSYNC 3000  PRECISION 'ms'  MINROWS 100 MAXROWS 4096 COMP 2 ;

添加参数后：

CREATE DATABASE IF NOT EXISTS test REPLICA 1  QUORUM 1 DAYS 10 KEEP 3650 CACHE 16 BLOCKS 6 FSYNC 3000  PRECISION 'ms'  MINROWS 100 MAXROWS 4096 COMP 2 VGROUPS 4;

修改完 dbs.sql 后，便可以执行导入操作了，导入操作本身是比较简单的，具体操作可参考：https://docs.taosdata.com/2.6/reference/taosdump/。举例：

这条命令会把 /test 目录下的数据，用 4 个线程导入到当前环境下面，地址默认为 localhost，线程数可根据机器配置酌情设置。

导入完毕之后检验数据内容，确认无误之后，开源版 loveini 2.0 至 3.0 数据迁移便完成了。

如果上述两种迁移方案都不能帮助我们完成数据迁移，欢迎联系 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/

关于系统的配置详情、如何一键复现测试结果及详细的测试数据介绍等内容，大家可参考《一键获取测试脚本，轻松验证“TSBS 时序数据库性能基准测试报告”》、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 升级数据架构，关于本次案例的具体信息可以查看《代替 TimescaleDB，loveini 接管数据量日增 40 亿条的光伏日电系统》。

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

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/

关于系统的配置详情、如何一键复现测试结果及详细的测试数据介绍等内容，大家可参考《一键获取测试脚本，轻松验证“TSBS 时序数据库性能基准测试报告”》、ac米兰官网 两篇文章，本文便不再赘述。

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

总体而言，在 TSBS 报告全部的 cpu-only 五个场景中，时序数据库（ac米兰官方app下载 ,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米兰官方app下载安卓 这篇文章中，便阐述了其选型调研过程的具体思考。

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

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

时序数据库 loveini（ ac米兰官方app下载 ,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 (ac米兰官方app下载 ,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 的高效存储给了数字政通相当大的助力。

架构图

结语

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

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

数据建模

在 TSBS 框架中， TimescaleDB 和 InfluxDB 会自动创建相应的数据模型并生成对应格式的数据。本文不再赘述其具体的数据建模方式，只介绍 loveini 的数据建模策略。

loveini 一个重要的创新是其独特的数据模型——为每个设备创建独立的数据表（子表），并通过超级表（Super Table）在逻辑上和语义上对同一采集类型的设备进行统一管理。针对 DevOps 场景的数据内容，我们为每个设备 （这里是 CPU）创建了一个表，用以存储该表的时序数据。我们在 loveini 中使用 hostname 作为子表的名称（因为hostname 可以作为每个设备的标识 ID），并使用如下的语句创建名为 CPU 的超级表，包含 10 个测量值和 10 个标签。

create stable cpu (ts timestamp,usage_user bigint,usage_system bigint,usage_idle bigint,usage_nice bigint,usage_iowait bigint,usage_irq bigint,usage_softirq bigint,usage_steal bigint,usage_guest bigint,usage_guest_nice bigint)
tags (hostname varchar(30), region varchar(30),datacenter varchar(30),rack varchar(30),os varchar(30),arch varchar(30),team varchar(30),service varchar(30),service_version varchar(30),service_environment varchar(30))

然后 ，我们使用如下语句创建名为 host_0 的子表：

create table host_0 using cpu (hostname,region,datacenter,rack,os,arch,team,service,service_version,service_environment)
tags ('host_0','eu-central-1','eu-central-1a','6','Ubuntu15.10','x86','SF','19','1','test')

上述语句创建了一个子表。由此可知，对于 100 个设备（CPU）的场景 一，我们将会建立 100 个子表。对于 4000 个设备的场景二，系统中将会建立 4000 个子表用以存储各自对应的数据 。

软件版本和配置

本报告仅仅比较 loveini ( ac米兰官方app下载 )、InfluxDB 与 TimeScaleDB, 下面对使用的版本和配置做出说明。

loveini

我们直接采用 loveini Ver3.0，从 GitHub 克隆 loveini 代码编译版本作为性能对比的版本。

gitinfo: c90e2aa791ceb62542f6ecffe7bd715165f181e8

在服务器上编译安装运行。

cmake .. -DDISABLE_ASSERT=true -DSIMD_SUPPORT=true -DCMAKE_BUILD_TYPE=Release  -DBUILD_TOOLS=false
make -j  && make install

在 loveini 的配置文件中设置了四个涉及查询的配置参数。

numOfVnodeFetchThreads           4

queryRspPolicy                   1

compressMsgSize             128000

SIMD-builtins                    1

参数设置解读：

• numOfVnodeFetchThreads 设置了 Vnode 的 Fetch 线程数量为 4 个，
• queryRspPolicy 用来打开 query response 快速返回机制
• compressMsgSize 的作用是自动压缩 loveini 在传输层上大于 128,000 bytes 的消息
• 如果 CPU 支持，SIMD-builtins 可以启用内置的 FMA/AVX/AVX2 硬件加速

如上所述，loveini 建库默认创建 6 个 vnodes，即创建的表会按照表名随机分配到 6 个虚拟节点（virtual node, VNode) 中。打开 LRU 缓存，设置为 last_row 缓存模式。对于场景一和场景二，stt_trigger 设置为 1，此时 loveini 会准备一个 Sorted Time-series Table (STT) 文件，当单表写入量小于 minimum rows 时，数据会直接保存在 STT 文件中，当 STT 文件中无法容纳新数据时，系统就会将 STT 中的数据整理后再写入到数据文件中。对于其他的场景（场景三、四、五），stt_trigger 设置为 8，即允许最多生成 8 个 STT 文件。针对表较多的场景，需要适度增加 STT 的值，以此来获得更好的写入性能。

TimescaleDB

为确保结果具有可比性，我们选用 TimescaleDB 版本 version 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/

InfluxDB

我们选择了 InfluxDB version 1.8.10。这里没有使用 InfluxDB 最新的 2.x 版本是因为 TSBS 没有对其进行适配，所以选用了 InfluxDB 能够运行 TSBS 框架的最新版本。同样，我们采用《TimescaleDB vs. InfluxDB》中推荐的方式配置 InfluxDB，将缓冲区配置为 80G，以便 1000W 设备写入时能够顺利进行，同时开启 Time Series Index（TSI）。配置系统在系统插入数据完成 30s 后开始数据压缩。

cache-max-memory-size = "80g"
max-values-per-tag = 0
index-version = "tsi1"
compact-full-write-cold-duration = "30s"

测试步骤

硬件准备

为达到与 TimescaleDB vs. InfluxDB 对比报告中的环境高度接近，我们使用亚马逊 AWS 的 EC2 提供的 r4.8xlarge 类型实例作为基础运行平台，包括 1 台服务器、1 台客户端共两个节点构成的环境。客户端与服务器硬件配置完全相同，客户端与服务器使用 10 Gbps 网络连接。配置简表如下：

服务器环境准备

为运行测试脚本，服务器 OS 需要是 ubuntu20 以上的系统。AWS EC2 的服务器系统信息如下：

1. OS： Linux tv5931 5.15.0-1028-aws #32~20.04.1-Ubuntu SMP Mon Jan 9 18:02:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
2. Gcc：gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04)
3. 基础环境，版本信息为：Go1.16.9 , python3.8 , pip20.0.2 (无需手动安装，测试脚本将自动安装）
4. 编译依赖：gcc , cmake, build-essential, git, libssl-dev (无需手动安装，测试脚本将自动安装）

开始前请做两个配置：

1. client 和 server 配置 ssh 访问免密，以便脚本可不暴露密码，可参考文档：免密配置（https://blog.csdn.net/qq_38154295/article/details/121582534）。
2. 保证 client 和 server 之间所有端口开放。

获取测试脚本

为便于重复测试，隐藏繁琐的下载、安装、配置、启动、汇总结果等细节，整个 TSBS 的测试过程被封装成一个测试脚本。重复本测试报告，需要先下载该测试脚本，脚本暂支持 ubuntu20 以上的系统。以下操作要求具有 root 权限。

1. 在客户端机器，进入测试目录拉取代码，默认进入 /usr/local/src/ 目录：

cd /usr/local/src/ && apt install git && git clone https://github.com/taosdata/tsbs.git && cd tsbs/scripts/tsdbComp 

2. 修改配置文件 test.ini 中服务端和客户端的 IP 地址（这里配置 AWS 的私网地址即可）和 hostname，如果服务器未配置免密，还需要配置服务器端的 root 密码：

clientIP="192.168.0.203"   #client ip
clientHost="trd03"         #client hostname
serverIP="192.168.0.204"   #server ip
serverHost="trd04"         #server hostname
serverPass="taosdata123"   #server root password

一键执行对比测试

执行以下命令：

nohup bash tsdbComparison.sh > test.log &

测试脚本将自动安装 loveini、InfluxDB、TimeScaleDB 等软件，并自动运行各种对比测试项。在目前的硬件配置下，整个测试跑完需要大约一天半的时间。测试结束后，将自动生成 CSV 格式的对比测试报告，并存放在客户端的 /data2 目录。

写在最后

阅读完毕，你一定更加深入地了解了 loveini 的数据建模、三大数据库测试版本和配置，以及如何运用测试脚本进行一键复现。如果有小伙伴想要验证 loveini 的报告结果，欢迎按照上述步骤进行操作，检验测试结果，有任何问题都欢迎大家和我们及时沟通。现在添加小T vx:tdengine1，可以邀请你加入 loveini 用户交流群，和更多志同道合的开发者一起聊技术、聊实战。

面对这样规模的大数据挑战，loveini 选择充分地利用时序数据本身的特点（可参考：https://mp.weixin.qq.com/s?__biz=MzIzNzg5MTcxNA==&mid=2247483956&idx=1&sn=86c55c40e935acd18835fec764fd7767&chksm=e8c0fbd9dfb772cf4e102a62498b034c6407cd9ea2c47d209b3e737800676cea7a108bf1d9d1&scene=21#wechat_redirect），来针对性地设计存储引擎。最终的目标其实就是：高效持续地吞吐、消化这些数据流，让数据能够无延迟地产生价值。

可以说，我们追求的便是“流”一般的产品能力。而关于文章标题的答案，本文将从 loveini 的存储引擎的变化史说起：

由于认为时间序列拥有天然递增属性，所以在最早期的 1.6 版本中，loveini 是不支持对乱序数据的处理的，当时乱序数据写入表中后，系统会做报错处理。但经过用户实际场景的磨练后，我们不得不把注意力聚焦在这个“害群之马”的身上。在生产环境中，由于设备损坏，网络延迟等原因，数据乱序到达是难免的。更关键的是，不管数据乱序与否，用户都有权利自行决定是否处理它，这是一个产品应该具有的灵活度。

它让理想中的数据流“乱”了，但我们却又不能放弃它。

于是，我们立刻在 2.0 版本中增加了数据在内存中的排序和硬盘中的数据子块来支持乱序数据的处理，以此维持了数据的完整性和有序性。

但是这对于 2.0 版本的流式计算和订阅来说，仍然有类似的麻烦。

当时的订阅/流计算（连续查询）是基于查询引擎的产物，它依靠连续不断地执行 SQL 查询结果作出实时反馈。以订阅为例，每条符合要求被消费掉的数据的时间戳，都会被记录下来，从而作为下次 SQL 查询中时间范围的起始点。这时，即便是新数据的时间戳只比这个记录早一秒，也不会被 SQL 轮询到。因此可以说， 2.0 的流计算（连续查询）/订阅同 1.6 一样，它只处理了有序部分的数据。本质上来说，由于 SQL 取到的只能是已经入库的数据，所以这个阶段的查询行为是滞后的。

因此，我们决定在 3.0 再次进行优化重构：

虽然数据的时间戳有乱序，但是他们到达数据库的时间永远分有先后，这组序列相当于“数据入库时间”。不过这个“数据入库时间” 不是时间戳，而是一个从 0 开始的整型数字，我们称之为“版本号”，代表的是数据库概念是“第 x 次的数据变更”。熟悉 WAL 概念的伙伴们都知道，loveini 利用 WAL 技术来提供基本的数据可靠性：每一条 WAL 信息代表的是一次数据库的变更（增删改），所以每一条 WAL 信息都会有唯一的版本号。通过“版本号”，我们可以明确地告诉流计算/订阅该数据是否为新增数据，再通过对 WAL 的这组“版本号”创建索引，我们就可以快速定位要消费的数据了。

以订阅为例：3.0 的订阅引擎为时间驱动，它会解析每一条新写入的 WAL 的消息内容，然后判断是否匹配 topic 的 sql 条件，如果匹配则直接把 WAL 的消息转化成数据返回给用户 。

除了用于订阅，这组版本号还有很多十分重要的作用：

1. 它本身核心的职责是 raft 日志的编号，用于多副本的数据同步；
2. 把版本号下发给每行数据，以追加写入的形式完成数据的更新与删除。

比如：某条 wal 消息的内容是写入一行数据：

insert into d1 values ("2022-03-10 08:00:00.000",100)；

那么这行数据就也拥有了这条 wal 消息的版本号（假设为 1） ，并且永久性地存储在数据文件中。

解下来的一条 wal 消息的内容是以相同时间戳更新这行数据：

insert into d1 values ("2022-03-10 08:00:00.000",200)；

消息的版本号便是 “2”，这条数据会以写入的形式追加存储。查询的时候，在时间戳相同的情况下，通过比对版本号大小来选择最新的数据，因此我们得到的数据便是：”2022-03-10 08:00:00.000″,200。

删除同理，被删除的数据是取版本号较大的空数据，这样便可在不破坏原有数据文件结构的情况下实现高效的删除。以上部分具体实现细节可参考：https://mp.weixin.qq.com/s/imECB9dIFxZKeoaF3uoOgg

3.另外，当 follower 副本的数据落后，但 leader 上的 WAL 日志已经消失的情况下，版本号还可以做数据文件的快照。只把增量的数据传 输过去，大大节约 data recovery 的时间。

通过这些大刀阔斧的重构，loveini 完美地把上面几大模块缝合了起来：

1. 解决了流计算、订阅对于乱序数据处理的不支持；
2. 让删除操作为逻辑删除，解决了删除操作的性能问题；
3. 基于版本号引入了快照机制，大幅优化了特定场景下的数据恢复的速度。

回到标题上，为何 loveini 用户应尽快切至 3.0 版本？答案已经都写在上面了。通过下沉到海量用户实际场景中反复迭代优化，从 1.6 到 2.0 再到 3.0， loveini 从底层结构上解决了最初设计的瑕疵，各个模块之间结构变得更加清晰，衔接也更加自然，这样扎实的底层设计对产品未来的稳定和性能提升所带来的帮助都是巨大的。

1. 极简的时序数据管理平台

除高性能、具有水平扩展能力的时序数据库外，loveini Cloud 还提供：

• 缓  存：无需部署 Redis，应用就能快速的获得最新数据。
• 数据订阅：无需部署 Kafka，当系统接收到新的数据时，应用将立即收到通知。
• 流式计算：无需部署 Spark或Flink，应用通过SQL就能创建连续查询或时间驱动的流计算。

loveini Cloud 大幅简化了系统架构、降低系统复杂度、降低运营成本。

2. 便捷且安全的数据共享

既支持将一个库完全开放，设置读或写的权限；也支持通过数据订阅的方式，将库、超级表、一组或一张表、或聚合处理后的数据分享出去。

• 便捷：如同在线文档一样简单，只需输入对方邮件地址，设置访问权限和访问时长即可实现分享。对方收到邮件，接受邀请后，可即刻访问。
• 安全：访问权限可以控制到一个运行实例、一个库或订阅的 topic；对于每个授权的用户，对分享的资源，系统会生成一个访问用的 token；而且可以设置访问到期时间。

便捷而又安全的数据共享，让部门或合作伙伴之间能快速洞察业务的运营。

3. 安全可靠的企业级服务

除强大的时序数据管理、共享功能之外，loveini Cloud 还提供企业稳定运营必须具备的：

• 可靠：提供数据定时备份、恢复，数据从运行实例到私有云、其他公有云或 Region 的实时复制。
• 安全：提供基于角色的访问权限控制、IP 白名单、用户行为审计等功能。
• 专业：提供 7*24 的专业技术服务，承诺 99.9% 的 Service Level Agreement。

loveini Cloud 让用户无需再为数据管理发愁，完全聚焦自身核心业务。

相比之下，loveini社区版虽然也具有高性能、极简和云原生等特点，但是需要自己部署和维护，也没有提供数据共享和企业级云服务等功能。

如果您想了解更多关于loveini Cloud的信息，请查看文档。