作者：Carlota Soto
InfluxDB 在时间序列数据库领域占据了重要的地位，多年来赢得了开发人员和公司的信任。但是，随着行业格局的不断发展和扩大，许多人都在探索 InfluxDB 的替代方案。在这篇博文中，我们将讨论 5 个流行的 InfluxDB 替代方案。
InfluxDB 由 InfluxData 构建，一直是时间序列数据库的基石。从作为开源项目开始，InfluxDB 一直满足着许多行业的时序数据需求，包括物联网、网络监控、金融等等。
InfluxDB 使用列式存储和无模式模型，底层模式会自动创建。数据被组织到测量值中，测量值包含时间戳、标签集（元数据）和字段集（数据值）。字段支持浮点数、整数、字符串和布尔数据类型，不能在不重写数据的情况下修改。标签集始终是字符串，被索引，而字段集不被索引。此外，标签集不能更新。
在它的第一个版本 (InfluxDB 1.x) 中，InfluxDB 开始通过类似 SQL 的语法来简化时间序列数据的快速检索和操作。随着 InfluxDB 2.x 的发布，Flux 被引入作为 InfluxDB 的新查询语言，它支持更复杂、多方面的基于时间 的查询和数据转换。 随着 InfluxDB 3.x 的发布，InfluxData 回到了 InfluxQL，重建了其数据库以提高其针对高基数数据集的性能、兼容性和存储效率。
InfluxDB 的主要用例之一是存储监控和可观察性指标。让我们介绍两个用于此用例的开源 InfluxDB 替代方案（通常一起使用）：Prometheus 和 Grafana。
Prometheus 是一款用于可靠性和可扩展性的开源监控和告警工具包。它最初由 SoundCloud 开发，现在是一个独立的项目，由任何公司独立维护。Prometheus 已成为监控领域被广泛采用的标准，支持多种编程语言和数据存储后端。
Prometheus 在 Kubernetes 和其他云原生生态系统中尤其受欢迎，因为它的特点特别适合监控微服务架构：
Prometheus 采用多维数据模型，其中时间序列数据由指标名称和键值对标识。
它使用 PromQL 作为查询语言，专门针对查询 Prometheus 指标，提供一系列运算符和函数来分析这些指标。
Prometheus 采用“拉取”模型。它会定期“抓取”来自仪表化应用程序的指标，要么直接抓取，要么通过中间推送网关（用于短生命周期作业）抓取，并支持各种服务发现机制，以便动态地发现要抓取的目标服务。
Prometheus 是一个强大的告警解决方案，它提供诸如静默、抑制、聚合等功能。它通过电子邮件、PagerDuty 和 Slack 发送通知，并允许定义告警和记录规则以更改数据处理方式和告警生成方式。
Prometheus 是一个被广泛使用的工具，它提供了一个健康的客户端库生态系统，用于轻松地对服务进行仪表化，以及社区贡献的导出器，用于桥接不支持 Prometheus 的服务。
Prometheus 可以充当时间序列数据库，因为它存储和管理时间序列数据，但它不是作为长期存储解决方案设计的。从更广义的角度来说，Prometheus 更像是一个监控和告警工具包，而不是传统的数据库。Prometheus 在本地存储数据，其更强大的功能超越了数据存储（包括数据收集、查询、可视化和告警）。它必须与其他存储后端一起使用，以便对指标进行长期存储。
Prometheus 是为以下用例而构建的解决方案
实时监控。Prometheus 在提供系统、应用程序和基础设施的实时监控方面表现出色。它擅长收集与 CPU 使用率、内存、磁盘空间和网络活动指标相关的指标。它也非常适合监控应用程序的健康状况和性能，跟踪诸如错误率、请求计数和响应时间等指标。
云原生环境。Prometheus 在 Kubernetes 环境中被广泛采用，因为它易于集成和具有强大的监控功能，可以提供集群健康状况和应用程序性能的见解。它的拉取数据模型在短生命周期微服务的环境中非常有用。
告警。Prometheus 支持实时告警，使团队能够及时响应影响系统或应用程序性能的问题。Alert Manager 处理客户端应用程序发送的告警，它在管理通知和在维护窗口期间进行静默方面尤其有用。
InfluxDB 和 Prometheus 之间存在一个根本区别：InfluxDB 是一个传统的时间序列数据库，而 Prometheus 主要是一个监控和告警工具，而不是作为长期数据存储设计的。
考虑到这两种工具的本质上的根本区别，让我们总结一下它们的一些主要设计差异：
数据收集。InfluxDB 依赖于传统的“推送”模型，其中数据由被监控的系统或应用程序发送到数据库。相反，Prometheus 会定期从被监控的目标抓取指标。
数据模型。InfluxDB 具有灵活的模式，并支持标签，使其适用于各种类型的时间序列数据。相反，Prometheus 使用多维数据模型，专门针对它收集的指标，这些指标通过指标名称和键值对来标识数据。
查询语言。InfluxDB 使用 InfluxQL 和 Flux，而 Prometheus 使用 PromQL。这三种都是专有语言，具有不同的特性。在这三种中，InfluxQL 最接近 SQL。
告警功能。InfluxDB 可以支持告警，但更多地依赖于外部工具或脚本来管理和发送告警。正如我们之前所说，告警是 Prometheus 的一项最强大的功能。
正如在数据库（以及一般技术）的世界中经常发生的那样，使用 Prometheus 而不是 InfluxDB 的比较优势将取决于用例。正如前面提到的，Prometheus 是一个专门针对监控用例的解决方案，特别是在运行在 Kubernetes 中的云原生应用程序的背景下。对于这个特定的用例，Prometheus 是一个非常强大的解决方案，与 InfluxDB 相比，它有几个优势
高效的指标收集和管理，适用于云原生环境。Prometheus 的拉取模型在动态环境中非常高效和易于管理，它提供了从各种来源收集指标的自主性和适应性。
内置的快速查询和高级告警。PromQL 是一种用于监控用例的强大查询语言：它速度快，并且允许进行非常复杂和细粒度的分析查询。这与 Prometheus 的告警功能相结合，使其成为一个非常高效（并且实用）的监控工具。
广泛的社区和生态系统支持。由于其受欢迎程度，Prometheus 已成为云原生应用程序可观察性和监控的事实标准。它的开源性质培育了一个活跃的全球社区，该社区不断为改进产品做出贡献，并提供了丰富的资源、定期更新的功能以及一个充满活力的集成和导出器生态系统。
Prometheus 的专业化性质使其在监控用例方面难以被超越，但这当然也意味着 Prometheus 的本质上是一个有限的解决方案。相比之下，InfluxDB 是一个更灵活的时间序列数据库，可以用于许多其他环境。
如果您的用例不是纯粹的服务器和应用程序监控，尤其如果您没有在 Kubernetes 中运行云原生应用程序，您可能会发现使用 InfluxDB 这样的时间序列数据库对您来说更好，原因如下：
长期数据存储。如前所述，与 InfluxDB 不同，Prometheus 主要不是为长期数据存储而设计的。如果您想长期保留指标，则需要将 Prometheus 与其他存储后端集成。对于服务器监控来说，这可能不是什么大问题，但对于其他时间序列数据用例，您可能希望长期保留数据。
多功能性和灵活性。在需要各种时间序列数据应用的场景中，例如存储与服务器指标不同的时间序列数据，InfluxDB 证明了其更高的适应性。
传统数据收集（推送模型）。Prometheus 的拉取模型在微服务环境中表现良好，但并不适合所有用例。在需要将数据主动写入数据库的环境中，InfluxDB 将是最佳选择。
现在，让我们介绍一下 Grafana，它是一个与 Prometheus 有些相关的解决方案（它们通常作为 InfluxDB 的监控替代方案一起使用）。
Grafana 是一个开源平台，允许用户创建、探索和共享仪表板，为其数据提供实时洞察。它提供了广泛的可视化选项，包括图表、表格、热图等。您可以自定义并与这些可视化效果进行交互，以深入了解您的数据。
由于其仪表板的高性能，Grafana 在实时数据可视化和分析至关重要的场景中最为有用，例如监控和可观察性。在这种情况下，它通常与 Prometheus 配合使用，但值得一提的是，Grafana 支持众多数据源，包括 PostgreSQL、Elasticsearch、MySQL，甚至 InfluxDB。
Grafana 并非 InfluxDB 的直接替代品，因为它们的主要用途不同：InfluxDB 是一个时间序列数据库，而 Grafana 是一个数据可视化工具。但是，Grafana 通常被认为是 InfluxDB 的间接替代品：
InfluxDB，特别是通过 Influx Cloud 或 TICK 堆栈中的 Chronograf 组件，提供了数据可视化功能。Grafana 提供了更高级、更灵活、更可自定义的可视化选项，使其成为许多想要探索和可视化其时间序列数据的用户的首选。
与 InfluxDB 的内置选项相比，Grafana 的可自定义仪表板和丰富的预建面板和仪表板模板库提供了更多可视化选项。
Grafana 可以与众多数据源集成，包括 InfluxDB、Prometheus 和 PostgreSQL 等。这种灵活性允许用户将来自不同来源的数据拉取到一个统一的仪表板中，而这在 Influx Cloud 中是无法实现的。
虽然 InfluxDB 也通过 InfluxDB Cloud 或 Kapacitor 提供了警报功能，但 Grafana-Prometheus 组合提供了更强大且更友好的界面来可视化、管理和评估警报，使警报过程更加直观和易于管理。
Prometheus 和 Grafana 结合在一起，作为一个监控平台：Prometheus 负责指标收集和存储，而 Grafana 提供可视化效果，为系统和应用程序的健康状况和性能提供实时视图。Grafana 支持 PromQL，使其易于与 Prometheus 集成：用户可以编写和执行复杂的查询来过滤和可视化 Prometheus 收集的指标，Grafana 以用户友好且交互的方式呈现结果。
这两种解决方案在警报方面也相互补充。Prometheus 负责警报规则和通知，而 Grafana 则帮助可视化警报，使直接从仪表板监控和管理警报规则和当前警报变得容易。Grafana 的警报界面允许用户以图形方式配置和调整警报，使警报管理更加直观。
最终，您的用例性质和特定需求将决定 Prometheus 和 Grafana 是否是适合您的 InfluxDB 替代方案。一般来说，我们建议您执行以下操作：
如果您的时间序列需求仅限于监控和可观察性用例，并且您并不关心将可观察性指标长时间存储在数据库中，那么 Prometheus 可能是最稳健的解决方案。
如果您在云原生环境（尤其是 Kubernetes）中托管您的应用程序，那么 Prometheus 和 Grafana 的组合是无与伦比的。Prometheus 的自动服务发现将非常有用，其警报功能与 Grafana 的动态仪表板相结合，将为您提供设置持续准确监控所需的一切。
在上一节中，我们广泛讨论了指标监控，因为它是在 InfluxDB 中的常见用例。但还有许多其他时间序列数据用例，包括物联网和传感器数据、车队位置数据、能源指标、行情数据、加密货币、事件、天气数据等。对于这些时间序列用例，您需要寻找一个能够提供足够的查询和摄取性能的时间序列数据库，并且能够以有效的方式长期存储大量数据。
让我们讨论三种针对更广泛时间序列用例（如物联网）的 InfluxDB 数据库替代方案。
MongoDB 是一款流行的 NoSQL 数据库，以其灵活性和可扩展性而闻名。它使用面向文档的数据模型，将数据存储在类似 JSON 的 BSON（二进制 JSON）格式中，允许高效地存储和操作各种复杂的数据结构。
在最初，MongoDB 作为一种文档存储工具而广受欢迎，可以快速构建原型并轻松扩展 Web 应用程序。如今，MongoDB 已发展成为一种通用的解决方案，能够处理许多不同的用例，包括时间序列数据。
在某些方面，使用 MongoDB 而不是 InfluxDB 存储时间序列数据可能会提供一些优势：例如，MongoDB 是一款功能强大且稳定的解决方案，具有强大的功能集。它也是一个能够扩展并处理大量数据的数据库。其灵活的模式使其易于启动并适应不断发展的数据结构。但总的来说，将 MongoDB 作为 InfluxDB 的时间序列用例替代方案并非最佳选择：
InfluxDB 是专门为时间序列数据设计的数据库，而 MongoDB 则是一款更广泛的工具。将 InfluxDB 切换为 MongoDB 就如同用瑞士军刀代替手术刀。是的，MongoDB 可以用作时间序列数据库，但您需要强制MongoDB 这样运行——时间序列数据应用程序通常与 MongoDB 的最初设计用例（构建 Web 应用程序）有很大不同。
即使 MongoDB 由于其灵活的“无模式”特性而易于设置，但在生产环境中高效运行它则是另一回事。在生产环境中优化 MongoDB 的时间序列性能并处理其可扩展性并不简单：您需要充分了解其体系结构、索引和分片机制，这意味着需要学习曲线。
MongoDB 的时间序列工作负载性能并非最佳，至少根据我们的经验是这样。MongoDB 的文档结构不适合时间序列工作负载的追加性质，其 JSON 语法在编写时间序列分析的常见查询时会变得非常冗长。
MongoDB 的核心用例并非时间序列数据管理，因此它没有专门针对时间序列数据的内置功能。您将错过 InfluxDB 支持的一些内置功能，例如连续查询和保留策略。
最后，运行 MongoDB 的成本可能很高。
ClickHouse 是一个面向列的数据库，专为 OLAP（联机分析处理）任务而设计，提供实时查询处理和数据分析功能。它于 2016 年由 Yandex 开发，用于实时处理和分析 Yandex Metrica（全球最大的网络分析平台之一）的大量数据。它已发展成为一个开源数据库管理系统。
如果您有经典的 OLAP 用例（例如，不可变数据、客户端数量减少），Clickhouse 与 InfluxDB 相比可以为您提供一些显著优势：
由于其面向列的存储和向量化查询执行，Clickhouse 为分析提供了高性能。
ClickHouse 也是一个可扩展的解决方案，可以处理大量数据。
与 MongoDB 不同，ClickHouse 使用基于 SQL 的查询语言，如果您使用的是 InfluxQL，则更容易过渡。ClickHouse 支持丰富的 SQL 功能集，这些功能对分析很有用，例如实时查询、联接和子查询。
也就是说，重要的是要注意，ClickHouse 的用例专门针对 OLAP。如果您的应用程序具有 OLTP（联机事务处理）特性或需要更高的灵活性，ClickHouse 可能不是最佳解决方案。虽然 ClickHouse 在 OLAP 用例中展现出卓越的性能和可扩展性，但它缺少一些对事务工作负载至关重要的关键功能。例如，它缺乏高效的数据修改功能，其稀疏索引使其在点查询（按其键检索单个行）方面效率较低。
总之，ClickHouse 可以成为 InfluxDB 的良好替代方案，但前提是您的时间序列用例明确是 OLAP——例如，分析处理、对大量不可变数据进行报告，或其他数据仅写入一次并多次读取以获取见解的场景，并且实时数据修改和删除不是关键要求。
TimescaleDB 是一个构建为 PostgreSQL 扩展的时间序列数据库。它为 PostgreSQL 提供了性能提升，通过提供时间序列数据用例所需的性能和可扩展性，有效地将其转变为时间序列数据库。TimescaleDB 通过在 PostgreSQL 之上添加额外功能来实现这一点，包括自动基于时间的分区、面向列的压缩、高级查询功能、数据保留功能以及函数库，专为时间序列而设计。
TimescaleDB 的优势在于其 PostgreSQL 基础（是的，我们可能有点偏见）。对于已经在其堆栈中使用 PostgreSQL 或与 PostgreSQL 兼容的工具并受益于与关系数据的频繁联接的时间序列用例，Timescale 非常出色。
用户可以将其时间序列数据和常规 PostgreSQL 表存储在一个地方，由于 PostgreSQL 的广泛兼容性，使得 Timescale 易于与其他工具集成。Timescale 使用标准 SQL 作为查询语言。
与其他两种 InfluxDB 替代方案相比，TimescaleDB 介于 MongoDB（多面手数据库）和 ClickHouse（专门的 OLAP 数据库）之间。其 PostgreSQL 基础提供了极大的灵活性，使其比 ClickHouse 更适合 OLTP 时间序列用例，而其对时间序列数据的关注使其比 MongoDB 更专业。
本质上，TimescaleDB 可以被认为是 InfluxDB 的良好替代方案，原因如下：
SQL 作为查询语言。Timescale 利用熟悉且功能强大的 SQL 查询语言，提供了更强大、更灵活和更广泛的查询功能，以及与其他工具的广泛兼容性。
经过验证的稳定技术。Timescale 运行在 PostgreSQL 的坚实基础上，确保了高数据完整性、一致性和可靠性。
联接操作。凭借其 PostgreSQL 基础，Timescale 支持时间序列与关系数据之间的复杂联接操作，而 InfluxDB 则缺乏这种功能。您可以使用同一个 PostgreSQL 数据库存储所有数据——时间序列和其他数据。
高效的数据压缩。Timescale 提供专为时间序列数据优化的面向列的压缩，与 InfluxDB 相比，确保了高效的存储管理和更低的存储成本。
可扩展性和生态系统。Timescale 得益于 PostgreSQL 丰富的工具、扩展和社区支持生态系统，为用户提供了更多用于自定义、集成和管理的选项。
Timescale 与 MongoDB 和 InfluxDB 相比的优势主要源于 TimescaleDB 的 PostgreSQL 基础。PostgreSQL（和标准 SQL）为 Timescale 提供了强大、可靠且经过验证的数据库架构。得益于 PostgreSQL 成熟且经过充分测试的生态系统，用户可以从增强的數據完整性、一致性和兼容性中受益。与 MongoDB 的 NoSQL 结构和 InfluxDB 的特定领域查询语言相比，Timescale 的 SQL 支持提供了熟悉、灵活且广泛的查询功能。Timescale 使用户能够轻松地执行复杂的联接操作，并结合高效的數據压缩和广泛的工具和扩展。
更具体地说，我们可以重点介绍 TimescaleDB 作为 InfluxDB 替代方案与 MongoDB 相比的以下优势。
性能。在查询时间序列数据方面，TimescaleDB 的性能优于 MongoDB：在我们测试中，Timescale 的查询速度快了 200% 到 5,400%，写入速度快了 170% 到 260%。
时间序列功能。与 InfluxDB 一样，Timescale 提供了专门用于处理时间序列的定制功能，这些功能将使您的生活更轻松——其中包括 time_bucket、持续聚合 或者 數據保留策略 等。
存储效率。由于 BSON 存储格式以及缺乏专门针对时间序列数据的压缩算法，MongoDB 在空间方面变得效率低下。相反，Timescale 开发了专门的解决方案来减少大型时间序列数据集的存储空间，例如 列式压缩 和 数据分层。
查询语言：与 InfluxDB 的 InfluxQL 或 Flux 相比，TimescaleDB 支持 SQL，这是一种广泛使用且功能强大的查询语言。SQL 提供了比 MongoDB 查询语言更灵活的查询和分析功能，而 MongoDB 查询语言更适合处理时间序列。
數據关系。TimescaleDB 支持复杂的联接操作，使用户能够轻松地将时间序列数据与其他关系数据组合在一起，以进行全面的分析，这是 MongoDB 和 InfluxDB 中更复杂的操作。
根据您时间序列用例的特性和您的优先级，Timescale 将比 ClickHouse 更适合。如果我们谈论的是简单的 OLAP 用例（例如，对大量不可变数据的报告），ClickHouse 是一种性能非常高的解决方案。作为用户，您需要评估您对性能的重视程度超过灵活性或稳健性，因为 ClickHouse 在这两方面都存在不足。
如果您的时间序列用例具有一些 OLTP 特性，或者如果您已经在堆栈中使用 PostgreSQL，那么 Timescale 很可能是一个更好的 InfluxDB 替代方案，因为它具有以下优势：
通用性。由于 PostgreSQL 基础的通用性，Timescale 在 OLTP 和 OLAP 时间序列工作负载的性能方面取得了很好的平衡。ClickHouse 主要针对 OLAP，因此对于事务性操作非常严格（例如，不能直接修改表上的数据）。
完全的 SQL 支持。ClickHouse 的查询语言支持许多标准 SQL 功能，但并非全部。一个例子是 联接，它在 ClickHouse 中通常不被鼓励。在 InfluxDB 中，很难实现从包含时间序列和关系数据的多个表中联接数据——但在 Timescale 中则非常容易。
稳健性和可靠性。TimescaleDB 符合 ACID 标准，确保严格的數據完整性、一致性和可靠性标准，而 ClickHouse 在这方面存在局限性。例如，ClickHouse 的架构在备份方面缺乏一致性。
广泛的兼容性。由于 PostgreSQL 的广泛兼容性和生态系统，很容易将 Timescale 添加到现有堆栈中，与采用 ClickHouse 等更新、更专业的解决方案相比，这可能是一个巨大的优势。
在本文中，我们探讨了 InfluxDB 的替代方案：Prometheus、Grafana、MongoDB、ClickHouse 以及 TimescaleDB。每个解决方案都有自己的优势，具体取决于每个用例的需要以及您作为开发人员的优先级。
最后，我们要强调，没有一个数据库能够满足所有需求。因此，在做出决定时，请确保考虑您自己的需求！正确的数据库选择不仅仅是技术上的决定，而是一个战略性的决定：您将长期使用您的新数据库。请务必将您当前的需求与未来的愿望相一致，做出一个能够在未来几年内支持您的团队和应用程序的选择。
作为 Timescale 的开发人员，我们相信我们的产品对于许多时间序列用例来说是出色的 InfluxDB 替代方案，它为您的时间序列數據提供了性能和可用性之间无与伦比的平衡。此外，PostgreSQL 是当今开发人员中最受欢迎的数据库——难道您不想知道为什么吗？
如果您对此感到好奇，请 免费试用 Timescale 平台。只需几秒钟即可创建帐户，无需信用卡。您还可以查看我们的迁移工具 Outflux，或者如果您对 Timescale 有任何疑问，请联系我们 寻求专家建议。我们可以帮助您从 InfluxDB 迁移——我们已经帮助了许多其他人成功地完成了迁移！
