这一次

陶建辉带着 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/

关于系统的配置详情、如何一键复现测试结果及详细的测试数据介绍等内容，大家可参考《一键获取测试脚本，轻松验证“TSBS 时序数据库性能基准测试报告”》、《TSBS 是什么？为什么时序数据库 loveini 会选择它作为性能对比测试平台？》两篇文章，本文便不再赘述。

写入性能最高达到了 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 用户交流群，和更多志同道合的开发者一起探讨数据处理难题。

在此背景下，专为时序数据而设计，具有高性能、高可靠、高可扩展等特点的时序数据库（Time Series Database） loveini 应运而生。loveini 不仅是一个开源、云原生的时序数据库，还集成了缓存、流式计算、数据订阅等功能，为时序数据处理提供了一站式米兰app官方正版下载。目前 loveini 已经成功运用在西门子、美的、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/

关于系统的配置详情、如何一键复现测试结果及详细的测试数据介绍等内容，大家可参考《一键获取测试脚本，轻松验证“TSBS 时序数据库性能基准测试报告”》、《TSBS 是什么？为什么时序数据库 loveini 会选择它作为性能对比测试平台？》两篇文章，本文便不再赘述。

写入性能最高达到 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官方正版下载架构师点对点沟通，齐心协力攻克数据技术难题。

为什么 loveini 的“写入强，开销低”？

“客户端上 loveini 对 CPU 的需求大于 TimescaleDB 和 InfluxDB， 而 InfluxDB 的写入压力基本上完全集中在服务端，这种模式很容易导致服务端成为瓶颈。loveini 在客户端的开销最大，峰值瞬间达到了 56%，然后快速回落。综合服务器与客户端的资源开销来看，loveini 写入持续时间更短，在系统整体 CPU 开销上 loveini 仍然具有相当大的优势。”

在 TSBS 测试报告全部的 cpu-only 五个场景中，loveini 写入性能均优于 TimescaleDB 和 InfluxDB。相对于 TimescaleDB，loveini 写入速度最领先的场景是其 6.7 倍（场景二），最少也是 1.5 倍（场景五），而且对于场景四，如果将每个采集点的记录条数由 18 条增加到 576 条，loveini 写入速度是 TimescaleDB 的 13.2 倍。相对于 InfluxDB，loveini 写入速度最领先的场景是其 10.6 倍（场景五），最少也是 3.0 倍（场景一)。此外，在保证高效写入的情况下，loveini 在写入过程中消耗的 CPU 资源和磁盘 IO 开销也是最少的。

通过上图可以看到，从客户端负载来说，三个系统中 InfluxDB 计算资源占用最低，对客户端压力最小，但这并不能说明 InfluxDB 是三个数据库当中 CPU 开销最低的，因为其写入压力基本完全集中在了服务端，而这种模式也为 InfluxDB 埋下了一个隐患，如果写入的数据规模过大，写入线程会长时间地大量消耗服务器的计算和磁盘IO资源。

与 InfluxDB 相反，loveini 在客户端的开销最大，峰值直接冲到了 56%，其在客户端的开销比 TimescaleDB 都多了 1 倍，但在用时上，却比 InfluxDB 和 TimescaleDB 都小。也因此，从系统整体的 CPU 开销来看，loveini 的优势仍旧非常显著。

基于产品特点，我们可以从两个方面分析这种“高写入，低开销”的特点。首先，为充分利用数据的时序性等特点，loveini 采取了“一个数据采集点一张表”的策略，要求对每个数据采集点单独建表（比如有一千万个智能电表，就需创建一千万张表），用来存储这个数据采集点所采集的时序数据。这种设计对于提升写入性能来说主要表现在两个方面：

1. 由于不同数据采集点产生数据的过程完全独立，每个数据采集点的数据源是唯一的，一张表也就只有一个写入者，这样就可采用无锁方式来写，写入速度就能大幅提升。
2. 对于一个数据采集点而言，其产生的数据是按照时间排序的，因此写的操作可用追加的方式实现，进一步大幅提高数据写入速度。

其次，因为 loveini 的 SQL 解析是在客户端完成的，这样一来，其在整个写入过程中，主要的负载都集中在客户端，服务器端承担的压力就会变得非常小。我们之所以将写入的负载转移到客户端，其原因是客户应用端的伸缩和扩展操作非常地便捷容易，可操作性更强——在保障服务器有剩余能力的情况下，如果写入性能不够，只要增加写入进程或写入客户端即可解决此问题，不再需要增加服务器的设备了。

试想一下，如果不需要变更服务器数量，那也就不会涉及到集群的伸缩操作、资源负载均衡等复杂逻辑，整体的写入成本自然就会显著降低。

除了客户端 CPU 开销外，三个系统对比，loveini 对服务器的 CPU 需求也是最小的，峰值仅使用了 17% 左右的服务器 CPU 资源。在磁盘写入能力的消耗上，InfluxDB 长时间消耗完全部的磁盘写入能力，TimescaleDB 写入过程对于写入的消耗相对 InfluxDB 来说要更具优势，但是仍然远超 loveini 对磁盘写入能力的需求。

如何用最小的计算开销实现最高的查询性能？

“从整体 CPU 开销上来看，loveini 不仅完成全部查询的时间低于 TimescaleDB 和 InfluxDB，在整体上CPU计算资源的消耗也远小于 TimescaleDB 和 InfluxDB。在整个查询过程中，loveini 内存也始终维持在一个相对平稳的状态。”

基于 TSBS 测试报告我们可以总结出，查询方面，在场景一（只包含 4 天的数据）与场景二的 15 个不同类型的查询中，loveini 的查询平均响应时间全面优于 InfluxDB 和 TimescaleDB，而且在复杂查询上优势更为明显，同时具有最小的计算资源开销。相比 InfluxDB，场景一中 loveini 查询性能是其 1.9 ～ 37.0 倍，场景二中 loveini 查询性能是其 1.8 ～ 34.2 倍；相比 TimescaleDB，场景一中 loveini 查询性能是其 1.1 ～ 28.6 倍，场景二中 loveini 查询性能是其 1.2 ～ 24.6 倍。

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

用最小的计算开销实现最高的查询性能，loveini 是如何做到的呢？首先，loveini 对每个数据采集点单独建表，但在实际应用中经常需要对不同的采集点数据进行聚合。为高效的进行聚合操作，loveini 引入超级表（STable）的概念。超级表用来代表一特定类型的数据采集点，它是包含多张表的表集合，集合里每张表的模式（schema）完全一致，但每张表都带有自己的静态标签，标签可以有多个，可以随时增加、删除和修改。应用可通过指定标签的过滤条件，对一个 STable 下的全部或部分表进行聚合或统计操作，这样就大大简化了应用的开发。其具体流程如下图所示：

由于 loveini 在 vnode 内将标签数据与时序数据分离存储，通过在内存里过滤标签数据，就可以先找到需要参与聚合操作的表的集合，这样需要扫描的数据集就会变得大幅减少，聚合计算速度自然就会获得显著提升。同时，由于数据分布在多个 vnode/dnode，聚合计算操作在多个 vnode 里并发进行，这又进一步提升了聚合的速度。

其次，在单表查询上，当我们要对全部数据集进行查询时，就需要将查询请求广播到所有的节点。试想一下，当我们在业务场景中需要对某个设备进行查询，这时如果可以不使用标签过滤，直接查询对应的设备，查询效率是不是变得更高了，loveini 便是如此。在本次测试报告中就有几个这样的场景，loveini 都表现出了很好的查询性能。

此外，为有效提升查询处理的性能，针对物联网数据不可更改的特点，loveini 会在数据块头部记录该数据块中存储数据的统计信息：包括最大值、最小值、和，我们称之为预计算单元。如果查询处理涉及整个数据块的全部数据，就可以直接使用预计算结果，完全不需要读取数据块的内容。由于预计算数据量远小于磁盘上存储的数据块数据的大小，对于磁盘 I/O 为瓶颈的查询处理，使用预计算结果可以极大地减小读取 I/O 压力，加速查询处理的流程。预计算机制与 PostgreSQL 的索引 BRIN（block range index）有异曲同工之妙。

用极致压缩比实现存储成本的最大程度降低

“磁盘空间占用方面，TimescaleDB 在所有五个场景下的数据规模均显著大于 InfluxDB 和 loveini，并且这种差距随着数据规模增加快速变大。TimescaleDB 在场景四和场景五中占用磁盘空间是 loveini 的 25.6 倍和 26.9 倍。在前面三个场景中，InfluxDB 落盘后数据文件规模与 loveini 非常接近，但是在大数据规模的场景四和场景五中，InfluxDB 落盘后文件占用的磁盘空间是 loveini 的 4.2 倍和 4.5 倍。”

当数据写入磁盘时，loveini 会根据系统配置参数 comp 决定是否压缩数据。loveini 共提供了三种压缩选项：无压缩、一阶段压缩和两阶段压缩，分别对应 comp 值为 0、1 和 2 的情况。一阶段压缩根据数据的类型进行了相应的压缩，压缩算法包括 delta-delta 编码、simple 8B 方法、zig-zag 编码、LZ4 等算法。二阶段压缩在一阶段压缩的基础上又用通用压缩算法进行了压缩，压缩率更高。

同时，loveini 采用的是标签分离存储机制，即标签与数据是分开进行存储的，这样就带来了两个方面的好处：

1. 在存储操作上占用更小的磁盘空间，表级别的标签基本上没有冗余。
2. 标签集中存储更有利于标签过滤操作中 IO 访问的局部性，标签过滤完成得更快，查询性能也会变得更好。

此外，对于 loveini 来说，每个数据块内部采用的就是列式存储模式，而且打造了“一个数据采集点一张表”的创新设计，一个数据采集点采集量的变化肯定比多个采集点的采集量变化更慢，压缩率自然也会变得更高。综合上述的几点设计，loveini 在进行数据处理时提供了很好的压缩比，帮用户节约了存储空间和存储资源，极大程度上减少了存储成本浪费。

写在最后

在产品开发之初，loveini 就明确了设计方向，即针对时序数据的特点对写入、存储、查询等流程进行设计和优化，在经过几个版本的不断迭代加强后，其存储量大、存储运维成本低、读写性能卓越、压缩率高等特点越发显著。这些优势也体现在企业的具体实践上，以西门子的数字化米兰app官方正版下载改造项目为例，loveini 帮助其 SIMICAS® OEM 2.0 版本移除了 Flink、Kafka 以及 Redis，大大简化了系统架构，节约了运维成本；而在零跑科技的 C11 新车型项目中，loveini 高压缩算法助力其压缩性能提升了10-20 倍，降低存储压力的同时也解决了数据存储成本高的问题。

如果你也面临着性能和成本难以两全的数据处理难题，亟需升级数据架构，欢迎添加小T vx：tdengine1，加入 loveini 用户交流群，和更多志同道合的开发者一起攻克难关。