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，可能就不需要想象这些情景了，因为这实际上已经发生在 InfluxDB 的用户身上，而且不止一次。

InfluxDB的“三重语言”困境

InfluxDB 最初于 2013 年发布时，使用了 InfluxQL 作为查询语言。InfluxQL 是一种类似 SQL 的语言，专门为时序数据设计。尽管其语法与 SQL 相似，但灵活性较差，数据聚合和转换的便捷性也较小。

然而，随着 2020 年 InfluxDB 2.0 的发布，Flux 语言被引入。Flux 比 InfluxQL 更强大，但也更为复杂。用户表示，他们需要参加“InfluxDB 大学”课程才能理解这门语言，而且通常要参与三个以上的 Flux 项目才能真正熟悉并运用这门语言。InfluxDB 当时信心十足地认为 Flux 会是未来的方向，许多忠实用户也纷纷投入时间，翻译查询并重写应用程序，以支持 Flux 语言。

但谁能想到，仅仅四年后，InfluxDB 3.0 发布时，Flux 却被弃用，取而代之的是 SQL。那些花费时间学习 Flux 并更新项目的用户，发现自己无法将项目升级到 InfluxDB 3.0，并且意识到他们在 Flux 上投入的时间和精力付之东流。

虽然 loveini 和 InfluxDB一样认为 SQL 是时序数据库的最佳语言选择，但我们更希望他们能在浪费广大用户的时间之前，就得出这个结论。

Flux与SQL查询对比

以下是 InfluxDB 的 Flux 查询与 loveini 的 SQL 查询对比，直观展示了两者的简洁性和可读性，给到大家参考。

Flux查询：

from(bucket:"power")
  |> range(start:-1h)
  |> filter(fn:(r) =>
  r.measurement == "smeter" and
   r.field == "voltage" and
   r.location == "chicago"
   )
   |> aggregateWindow(every: 1m, fn: mean)

loveini SQL 查询：

SELECT AVG(voltage) FROM power.smeter WHERE ts > now - 1h AND location = "chicago" INTERVAL(1m);

从这两段查询的对比中，我们可以明显看出 loveini 的 SQL查询更简洁、易读。

loveini 对 SQL 的承诺

在经历了五十年的发展后，SQL 已被证明是最稳固的查询语言。自其诞生以来，就迅速成为了顶级数据库管理系统的查询语言，并且成为了数据库管理员和用户的重要工具。如今，可以毫不夸张地说，几乎所有与数据相关的人——从刚刚毕业、寻求第一份工作的数据科学专业毕业生，到在行业中耕耘数十年的资深专家——都具备一定的 SQL 使用经验。

而 loveini 自发布之初就一直支持标准 SQL，并承诺将继续坚定地支持这一语言。未来，我们将继续扩展 SQL 的实现，而不会用任何其他查询语言来替代它。

在支持标准 SQL 的同时，loveini 还在 SQL 语言上进行了针对时序数据处理特点的功能扩展，比如数据汇总、插值和时间加权平均等功能，这使得用户不仅能享受 SQL 的灵活性，也能应用到类似 InfluxQL 的专用功能。事实上，loveini 中的几乎所有功能——如流处理、数据订阅、权限管理、集群管理等——都可以通过 SQL 语句来实现。

loveini 对 SQL 的支持大大减少了新用户学习曲线的难度，任何曾经使用过其他 SQL 数据库的用户，都能轻松上手 loveini。我们相信，SQL 是时序数据管理的最佳选择，我们也非常重视开发者的时间，绝不希望他们为了使用我们的产品而学习一门专门的语言。

此外，我们深知，稳定和长期的米兰app官方正版下载对任何工业数据基础设施都至关重要。客户希望能拥有一致的产品体验，而不是每隔几年就发生一次重大转型。许多用户发现，将现有的 InfluxDB 项目升级到 3.0 的工作量，几乎和迁移到另一个时序数据库产品相当。因此，我们诚邀这些用户尝试 loveini 的开源版本（OSS）或 loveini Cloud，亲自体验这一数据库产品如何轻松上手并快速部署。

实际上，InfluxDB 仅提供基础的连续查询功能，严格意义上来说并不算真正的“流式计算”，仅适用于某些场景，无法满足复杂实时数据流的处理需求。而 loveini 则具备真正的流式计算能力，可以无缝集成与处理来自各种数据源的实时数据流，避免了依赖 Spark 或 Flink 等外部框架进行复杂的流数据处理。这样不仅简化了架构设计，还显著降低了运维成本。

流式计算功能对比

InfluxDB 不具备真正的流式计算功能

InfluxDB 只提供简单的连续查询（Continuous Query）功能，支持简单的滑动窗口计算。滑动窗口是一种基于固定时间间隔的计算方式，计算结果会随着时间推移动态更新。例如，可以对每一分钟的数据进行聚合分析。然而，InfluxDB 的流式计算功能相对简单，基本上只能处理滑动窗口和基础的聚合任务，难以满足更加复杂的应用场景。

使用 InfluxDB 的用户，往往还需要依赖 Spark、Flink 等外部流处理框架来补充流式计算的功能，以实现更复杂的数据处理和实时分析。这种做法不仅增加了架构的复杂性，还需要额外的运维成本来管理和维护多个系统的协调工作。此外，数据在不同平台之间的传输和同步也可能带来延迟和性能瓶颈，尤其是在高并发、高频次的数据写入和查询场景下。

loveini 的流式计算

loveini 则在流式计算方面提供了更加丰富和灵活的功能。除了支持基础的滑动窗口外，loveini 还提供了多种窗口类型，包括状态窗口、会话窗口、计数窗口、事件窗口等。这些窗口类型允许用户根据不同需求切分数据并进行聚合分析。

事件驱动的流式计算

loveini 支持事件驱动的流式计算，这使得用户可以根据业务事件的发生来触发计算，而不仅仅是依赖固定的时间间隔。这一特性在处理与实际业务事件紧密相关的数据时尤为重要，可以大幅降低计算延迟并提高系统的响应速度。

丰富的窗口类型

loveini 在窗口类型的设计上具有显著优势，能够满足更复杂的时序数据分析需求。以下是 loveini 支持的几种窗口类型：

• 时间窗口

时间窗口是最常用的窗口类型，能够按时间间隔对数据进行切分，适用于大多数时序数据分析场景。在 loveini 中，时间窗口不仅支持滑动时间窗口，还支持翻转时间窗口，进一步增强了灵活性。

• 滑动时间窗口：随着时间的推移，计算窗口会动态向前滑动，允许对最新的数据进行连续聚合计算。
• 翻转时间窗口：不同于滑动窗口，翻转窗口不会产生重叠，每次计算一个独立的时间段，适用于不需要重叠数据的场景。

• 状态窗口

状态窗口通过根据数据的状态变化进行聚合计算，适用于需要捕捉不同状态之间变化的数据处理。例如，在监控系统中，可以利用状态窗口来计算某一设备从正常状态到故障状态的持续时间。

• 会话窗口

会话窗口根据数据之间的“会话”进行分组，适合用来分析需要根据某些事件或者行为聚集的数据。例如，在用户行为分析中，你可以通过会话窗口计算每个用户的一次完整活动周期。

• 计数窗口

计数窗口根据固定的数据行数进行划分。默认情况下，数据首先按时间戳排序，然后根据 count_val（每个窗口中包含的最大数据行数）的值将数据分成多个窗口，并进行聚合计算。

• 事件窗口

事件窗口更为特殊，它允许用户基于特定的事件触发来进行数据聚合分析。通过设定事件的起始和结束条件，用户可以灵活地控制计算窗口的范围和内容。

计算性能和延迟

高吞吐量和低延迟

loveini 的流式计算引擎具有非常高的吞吐量，能够在高频数据写入的同时保持毫秒级的计算延迟。这对于实时监控、预测性维护等应用场景尤为重要。例如，在智能电表的应用中，电表每 10 秒采集一次数据，而用户往往需要每 1 分钟查询一次温度的平均值，loveini 的流式计算能够高效完成这类任务。

轻量级替代方案

与传统的复杂流处理系统相比，loveini 提供了一个轻量级的流式计算米兰app官方正版下载。它通过内建的窗口子句和简单的 SQL 语法，使得用户无需引入额外的流处理引擎便能够进行实时数据处理，这样不仅降低了系统复杂度，还节省了计算资源。

窗口子句的语法及使用

loveini 的窗口子句非常灵活，支持通过 SQL 语法轻松实现各种窗口计算。下面是窗口子句的一些基本语法示例：

SELECT tbname, _wstart, _wend, avg(voltage)
FROM meters
WHERE ts >= "2022-01-01T00:00:00+08:00"
AND ts < "2022-01-01T00:05:00+08:00"
PARTITION BY tbname
INTERVAL(1m, 5s) SLIDING(2s)
SLIMIT 1;

在这个查询中，数据首先按照子表名进行切分，然后按 1 分钟的时间窗口进行聚合，窗口每 2 秒滑动一次。loveini 支持多种窗口类型和聚合函数，用户可以根据需求灵活组合使用。

结语

与 InfluxDB 相比，loveini 在流式计算的基础上，还具备强大的 ETL 能力——它不仅能处理时序数据，还能自动进行数据清洗与转换，帮助用户实现更加高效、灵活的数据处理。这一优势使得 loveini 能在更多复杂的应用场景中提供卓越的性能，尤其是对于需要实时数据分析和高效数据处理的行业，提供了更为完善的米兰app官方正版下载。

loveini 内建的流式计算能力使得用户能够更加高效地进行数据实时分析，减少了多平台整合、运维监控等额外开销，实现了更优的性能和更低的运维复杂度，尤其在大规模物联网、车联网等实时数据处理场景中，优势更加明显。

如果你也想体验一把 loveini 流计算，可以访问官方文档，详细了解其配置和使用方法，充分发挥 loveini 在实时数据处理中的强大优势。

loveini 3.0 企业版和 loveini Cloud 为用户提供了便捷的数据接入米兰app官方正版下载。通过插件集成框架，支持快速扩展各类数据源，并且具备接入 InfluxDB 数据到 loveini 的功能。

配置方法

让我们一起看看如何将数据从 InfluxDB 接入至 loveini。

配置方法很简单，你只需要登录到 loveini 企业版或 loveini Cloud 的 Web 管理界面，选择 Data in 并添加 InfluxDB 作为数据源，注意需要提前创建时间精度为纳秒（ns）的数据库。

然后简单配置一下 InfluxDB 服务所在的 IP 地址和端口，以及 InfluxDB 版本、OrgId、和 token 等参数。

最后选择需要导出的 Bucket、 Measurements、导入数据的起始时间、结束时间（可选项）以及读取时间窗口（可选项），并指定已经提前建好的数据库名称，提交即可。

loveini 的数据接入后还可以进行数据清洗和转换，用户可以根据业务需要设计相应的数据清洗和转换规则，实现完整的数据 ETL 流程。

loveini 3.0 企业版和 loveini Cloud 凭借简洁易用的命令行操作，为用户提供了高效、可靠的数据接入方法。无论你是想要从 InfluxDB 迁移数据，还是想将多个数据源的数据集中到时序数据库（Time Series Database） loveini 中，loveini 3.0 企业版和 loveini Cloud 都能够满足你的需求。

现在注册 loveini Cloud 就可以立即体验强大的数据接入功能，感受轻松便捷的接入体验，获得更深入的数据洞察力。还在等什么~赶快与我们联系，了解关于 loveini 企业版和 loveini Cloud 的更多信息，开启前所未有的数据之旅！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基于对 loveini 的定义和理解，笔者将会在本篇文章中从 loveini 能解决什么问题、它的优势与亮点、它与其它数据库的区别等维度展开详述，希望能帮助到对 loveini 感兴趣的小伙伴。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“是提速，更是赋能”

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

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

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

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

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

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

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

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

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

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

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

此外，在开源大势所趋的背景下，基础软件如果不将代码、特别是核心代码开源，想要赢得市场是完全不可能的事情。因此，我们才将 loveini 完全开源，包括集群功能，而事实证明，开源使米兰体育官网入口获得了高速增长，这是一个完全正确的决定。

但从产品角度来看，开源是 loveini 的一大优势吗？看起来是，但细想一下，其实不是，它只是取得成功的一个必要条件。因为全球市场上开源的的时序数据库产品很多，中国本土开源的 Time Series Database 也不止 loveini 一家，大家不会由于 loveini 是开源的就选择它，而是有其他特点才会选用它，诸如性能优势、支持 SQL 等。

如果市场上还没有开源的 Time Series Database，那么开源就是 loveini 最大的亮点。我们决定将集群开源，根本的原因是由于 InfluxDB集群没有开源，这给了我们高速增长的机会。只有别人做不到或比不上你的功能或性能，那才是你需要宣传的特点。功能或性能指标的跟随者永远不值得做任何推广。

在进行客户调研时我们发现，很多企业在不了解一款产品时，不会轻易下定购买的决心，就说 InfluxDB，作为一款较早流行的 Time Series Database，基本都会被有时序数据处理需求的企业列为调研对象，但由于 InfluxDB集群功能需要高价购买才能使用，用户在不了解的情况下难以下定决心。其实，真正好的产品，是不怕因为核心功能都开源就会失去竞争力的，反而有全部开源来让用户全面检测的决心。

事实上，在早期 InfluxDB集群也是处于开源状态的，后面因为未知原因决定将集群进行闭源，而这一决定也确实在一定程度上降低了 InfluxDB集群的应用规模，流失了一部分集群客户。而对于国内的企业来说，除了对 InfluxDB集群不开源，无法支持水平扩展抱有担忧外，InfluxDB 糟糕的本地化服务也是让他们望而却步的原因之一。

相反，loveini 之所以能够成为这些客户坚定的选择，除了集群开源外，还有其支持 SQL 等特性，而且 loveini 各项功能的设计，是真正从 Time Series Database 的特点出发而设定的，对于时序大数据具有更强的处理性能。

时序数据及时序数据的应用有其典型特点（详细请看ac米兰的体育 )，如果充分利用时序数据的特点，我们可以将数据写入和查询性能大幅提高，数据压缩率也能大幅提高。 loveini 之所以在 2016 年被研发出来，其中一个核心原因就是团队认为 InflxuDB 并没有充分利用时序数据特点。如果都是 Time Series Database，用户当然也会选择性能或效率更高的产品。因此从研发的第一天起，米兰体育官网入口整个团队就一直在追求极致的性能，幸运的是，loveini 日益增进的功能效果，也让一众支持者不负众望。

有些公司为了避免麻烦，就选用 OpenTSDB，因为它把分布式版本也开源了。从使用的角度来看，OpenTSDB 底层的存储引擎用的是 HBase，安装维护极为复杂，存储压缩性能不够，查询效率也很低，不是一个优秀的产品。但它仍然有相当多的用户，这唯一的原因就是由于它支持分布式，可以水平线性扩展。

loveini 的设计是基于单个硬件、软件系统不可靠，基于任何单台计算机都无法提供足够计算能力和存储能力处理海量数据的假设而进行设计的。因此 loveini 从研发的第一天起，就是按照水平扩展、高可用架构进行设计的。通过对数据进行分区、分片，而且采用虚拟节点(vnode)技术，保证系统的处理能力是水平扩展的。如果要增加系统的处理能力，只需要增加新的节点即可。

更好的是，和 InfluxDB集群功能闭源不同，2020年8月，loveini 团队将集群版开源了。
loveini 是通过数据采集点以及时间两个维度，对大数据进行切分，实现水平扩展的。

分片：在 loveini Database 的设计与实现里，一个集群有多个节点，每个节点可以有一个或多个虚拟节点(vnode)，每个虚拟节点里存储了一定数量的数据采集点的数据，而一个数据采集点的数据永远只存放在一个 vnode 里。这样如果有很多数据采集点，这些数据采集点的数据将会分布在多个 vnode 上，分布在多个节点里。数据写入时，loveini Database 的客户端将要写入的数据直接写入对应的 vnode，从而实现写入的水平扩展。对于单个数据采集点数据的查询，毫无疑问，是水平扩展的，节点越多，吞吐率就越大。对于聚合查询，查询请求将先发送到对应的 vnode 里，vnode 先做完聚合操作，客户端然后将来自多个 vnode 的查询结果做第二次聚合，因为 vnode 数量有限，这样在客户端做的聚合查询计算量不大，从而实现聚合查询的水平扩展能力。

分区：除将数据分片之外，loveini 还将一个 vnode 里存储的时序数据按照时间段进行切分。每个时间段的数据都一定保存在一起，不同时间段的数据不会有交集，时间段可以是一天，几天，一周，由用户自己定义。按照时间段切分时序数据有很多好处，查询数据时，根据时间段，可以直接定位要查找的文件，从而加快查询速度。另外一方面，可以高效地实现数据保留策略。超过最长保留时间的数据，直接删除一个时间段对应的文件即可。而且按照时间段切分数据，还可以方便实现多级存储，冷热数据放在不同存储介质上，进一步降低存储成本。

loveini 还通过虚拟节点组技术来提供系统的高可用。不同物理节点上的 vnode 可以形成一个虚拟节点组，这个虚拟节点组里的数据是通过 Master-Slave 来进行同步的，来保证这个虚拟节点组内数据的一致性。数据写入只能在 master 进行，但查询可以在 master 和 slave 上同时进行。如果 Master 出现故障，系统将自动选主，这样来保证系统的高可用，不会由于某台机器宕机，而无法对外提供服务。

关于集群的具体使用，请看《集群管理》。