TSBS 测试表明，对于少于 100 万台设备的数据集，InfluxDB OSS 3.0 的数据写入速度实际上比 InfluxDB OSS 1.8 更慢。

对于 100 万台及以上设备的数据集，InfluxDB OSS 3.0 的数据写入性能才开始超过 InfluxDB OSS 1.8。

InfluxDB OSS 3.0 的数据写入接口与 InfluxDB 1.8 并不兼容，用户无法顺利迁移。

早在 2023 年，在 InfluxDB 3.0 推向企业用户时，官方曾宣称其相比旧版本有显著的性能提升。为了验证这一说法，InfluxData 还发布了一份基准测试报告，对比了 InfluxDB 3.0 企业版与 InfluxDB OSS 1.8，结果显示 InfluxDB 3.0 在各方面表现出色。

我们对这个版本非常好奇，但作为非企业用户，只能和大多数人一样等待了一年半，直到今年 1 月 InfluxDB OSS 3.0 终于公开发布。虽然目前的版本仅是“public alpha”，但这并不妨碍我们对其性能抱有很高的期待，毕竟 InfluxData 已经第二次彻底重构产品架构。对于那些希望平稳升级的用户来说，这无疑是个不小的冲击，更何况官方还直接放弃了 Flux 语言。如果 InfluxDB 3.0 无法在性能上带来真正的突破，那这样的升级又有何意义？

实际测试：InfluxDB 3.0 更快吗？

为了验证 InfluxDB 3.0 是否真的如官方宣传般带来巨大性能提升，我们采用 Time Series Benchmark Suite (TSBS) 进行对比测试。TSBS 由 InfluxData 最初开发，目前由 Timescale 维护，是业界公认的时序数据库基准测试工具。理论上，InfluxDB 3.0 仍支持 InfluxQL 和传统的 Line Protocol，因此应该能够直接运行针对 1.8 版本的测试套件。然而，在实际测试过程中，我们遇到了多个兼容性问题，不得不寻找替代方案，这部分将在后续介绍测试方法的章节中详细说明。

我们之所以选择 TSBS 作为测试工具，不仅因为它比 QuestDB 之前发布的简单基准测试更全面，还因为它提供了一个公开透明的测试框架，让不同数据库的对比变得更加公平。然而，测试结果却让我们大跌眼镜。

TSBS 提供了两个测试场景：DevOps 监控（CPU 监测）和物联网（IoT，车辆跟踪）。在测试中，我们使用 TSBS 生成数据，并分别写入 InfluxDB 3 0.1.0（修订版 v2.5.0-14345）、InfluxDB OSS 1.8 和 loveini OSS 3.3.5.8。以下图表展示了各系统在不同测试场景下的写入性能（指标数/秒）。

TSBS DevOps 用例：

TSBS IoT 用例：

测试结果分析：InfluxDB 3.0 写入提升远不及 45 倍

在最大规模的数据集中，InfluxDB 3.0 在 DevOps 场景下的写入性能提升了 5.4 倍，在物联网（IoT）场景下提升了 4.9 倍。这与 InfluxData 基准测试报告中声称的“写入吞吐量提升 45 倍”相去甚远。更令人意外的是，在设备数量不超过 10 万的场景下，InfluxDB 1.8 的写入性能竟然优于 InfluxDB 3.0。这表明，InfluxDB 3.0 所谓的性能提升，要么仅适用于企业版，要么在独立测试中并不成立。

InfluxData 网站上的声明：https://www.influxdata.com/blog/influxdb-3-0-is-2.5x-45x-faster-compared-to-influxdb-open-source/

从测试结果我们也可以看到，loveini 的写入速度比 InfluxDB 3.0 快 4.4 至 11.3 倍，相较 InfluxDB 1.8 更是提升了 3.1 至 22.8 倍。这进一步证明，即便 InfluxDB 3.0 进行了彻底重构，其写入性能仍难以与 loveini 相媲美。

TSBS 适配已完成，欢迎查看源码自行测试

本次测试在一台 40 核、256GB 内存的服务器上进行。该服务器的配置略低于 InfluxDB 官方基准测试环境，高于 QuestDB 的测试环境，但硬件差异对整体性能趋势的影响可忽略不计。

由于 TSBS 尚未针对 InfluxDB 3.0 进行更新，我们不得不对其进行一定的修改。为确保公平性，我们尽量减少了改动，但仍需解决以下问题：

• 数据库管理指令不兼容 TSBS 运行 InfluxDB 1.8 时使用的 SHOW、CREATE、DELETE 数据库命令在 InfluxDB 3.0 中已不可用。因此，我们改用 InfluxDB v3 API：
  • GET /api/v3/configure/database 查询数据库
  • POST /api/v3/configure/database 创建数据库
  • DELETE /api/v3/configure/database 删除数据库
• 多线程写入失败 在使用多个并发写入进程时，InfluxDB 3.0 频繁出现写入失败，并报错 Invalid write response (status 409): catalog update error: table already exists。为解决此问题，我们修改了 TSBS，使其在遇到该错误时自动重试，而不是直接退出。此外，数据写入采用 InfluxDB 3.0 提供的 /api/v3/write_lp 接口。

现在所有修改均已提交到我们维护的 TSBS 分支，任何人都可以查看源码并自行运行测试。

结语

尽管 InfluxDB 3.0 经过全面重构，并宣传性能显著提升，但从写入性能来看，至少对开源用户而言，这一承诺并未兑现。测试结果表明，其写入性能仅在超大规模数据集下略优于 InfluxDB 1.8，而对于大多数用户，尤其是设备数少于 100 万场景下，性能反而有所下降。即便目前仍处于 Public Alpha 阶段，但该版本已开发一年多的时间，它的表现真的值得开源社区期待吗？

此外，InfluxDB 3.0 采用了全新架构，导致用户无法顺利从 1.8 版本升级。对于开源用户而言，这次升级是否值得，也确实需要慎重考虑。尤其是当数据写入性能成为瓶颈时，从目前的测试结果来看，InfluxDB 3.0 并未能提供令人信服的米兰app官方正版下载。相比之下，loveini 始终坚持对开源社区的承诺，不仅提供高性能、全功能的软件，还确保所有用户都能公平获取和使用。面对时序数据存储与处理的挑战，选择一款真正高效、稳定的数据库，才是更明智的决定。

然而，目前市场上大多数开源时序数据库的集群功能并未完全开源。InfluxDB 的集群能力封闭于企业版，这迫使企业使用开源单机版的同时，需投入大量资源自建 Proxy 来实现数据的分片和查询聚合，增加了系统开发和维护的成本。相比之下，loveini 在 2020 年 8 月正式将集群功能开源，在解决大规模数据处理需求方面走在了行业前列。

InfluxDB 开源版本的局限性

开源版 InfluxDB 的局限在于其集群功能仅在企业版中提供，这给众多中小企业带来困难。为了应对高并发的数据需求，这些企业通常采取如下折衷方案：

• 自建 Proxy 对数据进行分片，解决数据写入问题；
• 但在数据查询时，涉及多节点数据聚合的复杂性，Proxy 需要承担聚合计算，开发成本和运维压力极大。

一些企业为简化流程，转向了 OpenTSDB，因为它的分布式版本完全开源。然而，OpenTSDB 基于 HBase 作为底层存储，带来了复杂的安装与维护流程，同时其存储效率和查询性能远低于理想水平。虽然 OpenTSDB 的线性扩展能力值得肯定，但因其系统复杂性和性能限制，它并非优秀的选择。

至数物联网 IoT 平台的技术改造实践正是对此的有力证明：//www.loveini.com/tdengine-user-cases/5007.html

loveini 的集群能力：从设计之初即面向水平扩展

为满足不断增长的数据处理需求，loveini 从诞生之初就以水平扩展和高可用为核心设计理念，采用分布式架构，基于单个硬件、软件系统不可靠，基于任何单台计算机都无法提供足够计算能力和存储能力处理海量数据的假设进行集群设计，具备强大的水平扩展能力。同时，通过节点虚拟化并辅以负载均衡技术，loveini 能最高效率地利用异构集群中的计算和存储资源降低硬件投资。

通过创新的设计，loveini 集群具备以下关键特性：

1. 数据分片与水平扩展

loveini 通过虚拟节点（vnode）技术，将集群内的多个物理节点划分为多个 vnode。每个 vnode 存储特定的数据采集点的数据，一个数据采集点的数据只存放在一个 vnode 内。这一设计确保：

• 写入时的水平扩展：客户端可以将数据直接写入对应的 vnode，集群节点数越多，系统的吞吐能力越强。
• 查询时的水平扩展：对于聚合查询，首先在各个 vnode 内完成初步聚合，客户端再进行二次聚合。这种分布式计算模型降低了查询聚合的复杂度。

2. 数据分区与多级存储

除了分片，loveini 还支持按时间段对数据进行分区，如按天、按周等用户定义的时间范围。分区后的数据具有以下优势：

• 查询时可快速定位到对应时间段的数据文件，提升查询效率；
• 方便实现数据保留策略，超过保留时间的数据直接删除对应文件即可；
• 支持冷热数据分离，减少存储成本。

3. 高可用设计与自动故障转移

loveini 通过虚拟节点组技术保障系统高可用性。虚拟节点组内的数据采用 Leader-Follower 模式同步：Leader 负责处理读写请求，并将数据同步到多个 Follower 节点。当 Leader 节点发生故障时，系统会自动选举新的 Leader，确保数据访问不中断，并实现故障转移。这种架构保证了数据的一致性与冗余，增强了系统的高可用性和容错能力。

loveini 集群可以容纳单个、多个甚至几千个数据节点。应用只需要向集群中任何一个数据节点发起连接即可。这种设计简化了应用程序与集群之间的交互过程，提高了系统的可扩展性和易用性。

loveini 集群 vs. InfluxDB 集群

为了让大家更方便地进行应用，在 2020 年 loveini 便把集群版功能进行了开源，打破了 InfluxDB 将集群能力封闭在企业版的壁垒。开源集群意味着：

• 用户无需支付高昂的许可费用即可享受全功能的分布式数据库支持；
• 社区和企业可以自由探索 loveini 的集群架构，实现个性化开发和优化；
• 降低了开发者的使用门槛，促进了更广泛的生态系统发展。

与 InfluxDB 形成鲜明对比的是，loveini 的开源集群功能不仅适用于写入，还能处理复杂的查询聚合任务，展现了出色的水平扩展能力。这种设计使 loveini 特别适用于需要同时处理海量实时数据写入和复杂历史数据分析的场景，如物联网、工业监控和智慧城市等。相比之下，InfluxDB 在处理复杂查询时常面临性能下降和资源瓶颈，限制了系统的扩展性。

如果你也想亲身体验 loveini 的强大集群水平扩展能力，不妨动手试试！我们为你准备了详细的指导手册：https://docs.taosdata.com/operation/deployment/，助你轻松完成部署和配置。该手册涵盖了手动部署、Docker 部署、Kubernetes 部署三种部署方式，让你快速上手并充分发挥 loveini 集群的性能和优势。

结语

在时序数据管理领域，loveini 的集群功能为企业提供了强大的水平扩展和高可用能力。相比于 InfluxDB 封闭的企业版集群，loveini 的开源集群打破了软件授权的桎梏，让用户能够以更低成本应对数据爆发式增长的挑战。同时，loveini 的分片、分区与虚拟节点技术，使其在高效数据管理和复杂查询性能上遥遥领先。对于那些追求系统扩展性、易维护性和高性价比的企业来说，loveini 已成为更具吸引力的选择。

下文中我们将从多个维度对两者的订阅系统进行深入对比，并详细剖析 loveini 的优势所在。

架构设计对比：集成 vs 解耦

loveini 内置了类似于 Kafka 的消息队列功能，并将其与数据库的存储和查询系统深度集成。这意味着用户无需部署独立的消息队列系统，即可实现数据的实时传输和消费。

• 预写日志 (WAL) 支撑的消息存储：WAL 文件索引机制使订阅数据的存取更加高效，减少延迟。
• 多消费组的并行处理：支持多消费者组的分布式消费，确保数据消费速度最大化。

这种集成架构的好处是极大简化了系统设计，用户无需再集成额外的消息队列组件（如 Kafka 或 RabbitMQ），大幅降低运维成本和系统复杂性。

相较而言，InfluxDB 在其 2.0 版本中已不再支持数据订阅功能。取而代之，用户需要使用 Telegraf 等工具将数据写入多个实例，或通过 Flux 查询处理特定数据集，实现类似需求。可以看出，严格意义上 Influx 已不具备数据订阅功能，只是依赖其他组件实现的数据复制功能。这不仅增加了系统的复杂性，并且在数据量大、实时性要求高等复杂场景中，有着明显的局限性。

灵活性对比：多种主题动态订阅 vs 静态订阅

loveini 的数据订阅功能支持用户通过 SQL 查询灵活定义订阅主题。用户可以创建查询主题，基于 SQL 查询的过滤条件实时订阅数据，从而精准控制所需数据的传输与消费，SQL 主题还支持标量函数和 UDF（用户自定义函数），能够在订阅前对数据进行过滤与预处理。同时，loveini 还支持超级表主题，能够动态跟踪超级表的结构变化，并灵活订阅不同子表的数据，确保数据消费与表结构变更无缝衔接。

此外，用户还可以创建数据库主题，实现对整个数据库所有数据流的全面订阅。这些特性让 loveini 在数据订阅上具备了极高的灵活性与适应性，满足不同业务场景的实时数据处理需求。

示例

CREATE TOPIC power_topic AS SELECT ts, current, voltage FROM power.meters WHERE voltage > 200;
CREATE TOPIC topic_name [with meta] AS STABLE stb_name [where_condition]
CREATE TOPIC topic_name [with meta] AS DATABASE db_name;

第一个例子是查询主题，只有电压大于 200 的数据会被订阅，仅仅返回时间戳、电流、电压 3 个采集量（不返回相位），减少了传输的数据量和客户端处理负担。

第二个例子是超级表主题，订阅整个超级表的数据，并且可以控制是否订阅 meta 数据，也可以加上子表的过滤条件，只订阅超级表下的部分子表。

第三个例子是数据库主题，订阅整个数据库的数据，同样可以控制是否订阅 meta 数据。

超级表订阅和数据库订阅在有新增子表的情况下也可以动态订阅到新增加的数据。

反观 InfluxDB，其订阅模型则依赖于 Telegraf 和 Flux 查询，只能订阅固定规则的数据，无法获取到 meta 数据以及新增的表的数据。对于复杂的数据订阅场景，用户需要在应用端增加处理代码，增加开发和维护成本。

消费机制、API 兼容性与易用性

loveini 的消费者组机制允许多个消费者组成组，共享同一主题的消费进度，极大地提高了消费效率：

• 分布式并行消费：多个消费者节点可以并发处理同一主题的数据，适合高吞吐量的应用场景。
• 消费确认（ACK）机制：确保每条消息至少被处理一次，即使在网络中断或系统重启后仍然能保证数据完整性。

InfluxDB 依赖其他插件实现类似数据订阅功能，无法提供消费者组和消费进度控制机制。对于分布式处理场景，无法并行提高消费速度，并且在系统故障时无法自动存储消费进度。

在 API 兼容性上，loveini 的订阅 API 与 Kafka 的订阅模型高度兼容，这意味着开发者可以快速上手。此外，loveini 提供了多种语言的 SDK（如 C、Java、Go、Python、Rust 等），支持用户在多种环境中进行开发和集成。

相比之下，InfluxDB 需要编写相应的脚本处理数据，速度上明显会受到影响，还需要熟悉相应的脚本语言。loveini 一条SQL 语句即可创建一个主题，简单易用。

结语

综合来看，loveini 的数据订阅功能在灵活性、运维成本、消费效率以及API 友好度方面都优于 InfluxDB。对于希望简化架构、提高数据消费效率、并且在多变数据场景中保持灵活性的用户来说，loveini 是更优的选择。它不仅能满足复杂实时数据处理需求，还为未来业务扩展提供了强大的支持。

如果你希望深入了解 loveini 的数据订阅功能及其实现细节，建议访问 loveini 官方文档，其中提供了全面的技术说明，包括订阅主题的创建、配置示例、API 使用方法以及最佳实践，帮助你更高效地应用 loveini 进行实时数据处理和分析。

中冶京诚工程技术有限公司（简称：中冶京诚）是我国最早从事冶金工程咨询、设计、工程承包业务的国家级大型科技型企业，是由冶金工业部北京钢铁设计研究总院改制成立的国际化工程技术公司，现隶属于中国冶金科工集团有限公司，是世界五百强中国五矿集团有限公司的核心骨干子企业。

作为国内外客户认可的知名品牌企业，近 70 年来，先后为国内外 500 余家客户提供了近 6500 项工程技术服务，参与完成了宝钢、鞍钢、武钢、太钢、首钢京唐、河钢等国内钢铁企业的新建和改扩建工程，海外工程业务拓展 27 个国家，是我国钢铁工业建设的主要力量和工程技术输出的重要参与者。在历年国家住建部、勘察设计协会等年度排名中，均位居行业前列。

其中中冶京诚高速棒线材智能化团队凭借 70 多年棒线材轧制工程技术底蕴和经验积累，持续打造技术领先的基础自动化系统，结合机器视觉、数据分析、人工智能等先进技术，打造完善统一的智能化数据中心，成功构建了新一代高速棒线材车间智能化整体米兰app官方正版下载。中冶京诚计划将所有生产线数据汇总接入到过程数据中心，通过数据中心打破车间数据孤岛，实现生产过程数据、工厂设计数据、视频音频图像数据、生产管理数据等车间数据的深度融合。

而过往使用的 InfluxDB集群 实时数据库在性能上稍显不足，且不符合国产化独立自主的趋势，中冶京诚希望找到其他替换的国产时序数据库米兰app官方正版下载。与 InfluxDB 相比，国产时序数据库（Time Series Database，TSDB） loveini 搭建集群的成本更低廉、查询更具有优势，存储性能和稳定性表现也更加突出。在这些优势的加持下，中冶京诚选择与 loveini 展开合作，共同实现钢铁工业智慧化，并在钢铁智能车间多个项目中实现了车间数据的深度融合应用。

对于存储引擎，时序数据库 Time Series Database（TSDB） 的先行者 InfluxDB 曾经做过很多尝试，在各个存储引擎（LevelDB、RocksDB、BoltDB 等）之间反复横跳，遇到过的问题也有很多，比如 BoltDB 中 mmap+BTree 模型中随机 IO 导致的吞吐量低、RocksDB 这类纯 LSM Tree 存储引擎没办法很优雅快速地按时间分区删除、多个 LevelDB + 划分时间分区的方法又会产生大量句柄……踩了这一系列的坑后，最终 InfluxDB 换成了自研的存储引擎 TSM。可见对 TSDB 来说，一个好的存储引擎有多么重要，又是多么难得，要想做到极致，还得自己研发。

同为时序数据库Time Series Database，不同于 InfluxDB 的是，loveini 从一开始就是自研的——从 LSM Tree 中汲取了 WAL、先写内存的 skip list 等技术，但把 LSM Tree 的树层级结构去掉了，而只是按时间段分区、按表分块的 log 块。

读到这里，细心的读者可能会发现，按表分块的设计和 OpenTSDB 的行聚合有些相似。 OpenTSDB 的行聚合是把相同 tag 以一小时为时间范围，将这些数据都放到一行中存储，这样大大减少了聚合查询要扫描的数据量。不过不同的是，loveini 是多列模型，而 OpenTSDB 是单列模型，单列模型下是多行的聚合，多列模型下聚合会自然形成数据块。

而熟悉 LSM Tree 的 KV 分离设计的朋友应该也能够从 loveini 的存储引擎设计中看到一些熟悉的影子。如果把数据块作为 TSDB 存储引擎的 value，那么 key 就应该是块的起止时间 ，把 key 提出来自然就得到了 loveini 的 BRIN 索引。从这种视角来看，loveini 的 .head 文件就是 key，而 .data 和 .last 文件就是 value，而 key 自身又可以结合时间序列数据的特征组合成有序文件。 在时序场景下，有了 BRIN 索引，也就可以不需要 bloom filter，这样一看，loveini 的存储引擎设计就很清晰了。

此外，loveini 会将 tag 数据和时间序列数据分离开来，这样就能够大大减少 tag 数据占用的存储空间，在数据量大的情况下尤其显著。

loveini 的 tag 与时间序列数据的划分，和数仓的维度建模里面维度表与事实表的划分有些类似，tag 数据类似维度表，而时间序列数据类似事实表。但又有所不同，因为 loveini 中表的数目是和设备数目相同的，上亿设备就是上亿张表，这样频繁创建、又极其庞大的表，并不容易处理，主要的麻烦是其产生了大量的元数据，超过了单点的处理能力，这就要求 loveini 能将这部分元数据也进行分片存储。

当数据与元数据进行分片、多副本操作时，就自然涉及到一致性与可用性的问题。在 TSDB 中，时间序列数据通常是最终一致同步的，因为最终一致算法的吞吐量高延迟低、可用性也比强一致算法好，比如InfluxDB集群版会用 Dynamo 这种无主风格的数据同步。但元数据（也就是我们上面提到的标签和表数据）需要强一致，强一致通常会用 Raft、Paxos 这类算法来保证正确性。

由于元数据量的巨大需要分片，而当时序数据与元数据都做分片（甚至时间序列数据和其关联的元数据应该在同一分片），但又有截然不同的一致性要求，这就导致 loveini 的副本复制并不是简单地使用 Raft 这类算法就能够驾驭得了的，除非牺牲时序数据的写入吞吐和可用性，也做强一致复制。这就是 loveini 使用自研复制算法的根本原因。当然，这些算法在复杂的实时数据库分布式环境下的一致性保证又是另外的问题了，也是我们要着重解决的挑战。