InfluxDB 与 Elasticsearch 在时间序列数据和指标方面的基准测试

作者：Chris Churilo / 产品, 用例
2018 年 2 月 6 日

导航至

此博客文章已于 2020 年 7 月 17 日更新，包含 InfluxDB v1.8.0 和 Elasticsearch v7.8.0 的最新基准测试结果。为了向您提供最新的发现，本博客会定期更新最新的基准数据。

在 InfluxData，我们经常被开发者和架构师问到的一个常见问题是：“对于时间序列工作负载，InfluxDB 与 Elasticsearch 相比如何？” 提出这个问题可能有几个原因。首先，如果他们正在启动一个全新的项目，并且正在尽职调查地对几个解决方案进行正面比较，这有助于创建他们的比较网格。其次，他们可能已经在现有的监控设置中使用 Elasticsearch 来摄取日志，但现在想了解如何将指标收集集成到他们的系统中，并认为可能有一个比 Elasticsearch 更好的解决方案来完成这项任务。

在过去几周，我们着手比较 InfluxDB 和 Elasticsearch 在时间序列工作负载方面的性能和功能，特别关注数据摄取率、磁盘数据压缩和查询性能。在两项测试中，InfluxDB 的性能优于 Elasticsearch，写入吞吐量高出 3.8 倍，而与 Elastic 的时间序列优化配置相比，磁盘空间使用量减少 9 倍。与 Elasticsearch 的缓存查询的响应时间相比，InfluxDB 的测试查询的响应时间快 7.7 倍。

同样重要的是要注意，为时间序列配置 Elasticsearch 并非易事 —— 它需要预先决定 索引、堆大小调整 以及如何 使用 JVM。另一方面，InfluxDB 开箱即用，无需额外配置，模式和查询语言专为处理时间序列而设计，可直接用于时间序列工作负载。

我们认为，这些数据对于评估这两种技术在他们的用例中的适用性的工程师来说将证明是有价值的；具体而言，时间序列用例涉及自定义监控和指标收集、实时分析、物联网 (IoT) 和传感器数据，以及容器或虚拟化基础设施指标。基准测试练习没有研究 InfluxDB 适用于时间序列以外的工作负载的适用性。InfluxDB 并非旨在满足全文搜索或日志管理用例，因此超出范围。对于这些用例，我们建议坚持使用 Elasticsearch 或类似的全文搜索引擎。

要阅读基准测试和方法的完整详细信息，请下载“InfluxDB 与 Elasticsearch 在时间序列数据和指标管理方面的基准测试”技术白皮书，或观看录制的网络研讨会。

我们的首要目标是创建一个一致的、最新的比较，反映 InfluxDB 和 Elasticsearch 的最新发展，并在后期涵盖其他数据库和时间序列解决方案。我们将定期重新运行这些基准测试，并使用我们的发现更新我们详细的 技术白皮书。所有这些 基准测试的代码都可以在 Github 上找到。如果您有任何问题、意见或建议，请随时在该存储库上打开 issue 或 pull request。

现在，让我们来看看结果...

测试版本

InfluxDB v1.8.0

InfluxDB 是用 Go 编写的开源时间序列数据库。它的核心是一个名为 时间结构化合并 (TSM) 树 的自定义构建存储引擎，该引擎针对时间序列数据进行了优化。InfluxDB 由一种名为 InfluxQL 的自定义类 SQL 查询语言控制，为跨时间范围的数学和统计函数提供开箱即用的支持，非常适合自定义监控和指标收集、实时分析以及物联网和传感器数据工作负载。

Elasticsearch v7.8.0

Elasticsearch 是用 Java 编写并构建在 Apache Lucene 之上的开源搜索服务器。它提供了一个适用于企业工作负载的分布式全文搜索引擎。虽然 Elasticsearch 本身不是时间序列数据库，但它采用了 Lucene 的列索引，用于聚合数值。结合查询时聚合和按时间戳字段索引的能力（对于存储和检索日志数据也很重要），Elasticsearch 提供了存储和查询时间序列数据的基础。

在构建具有代表性的基准测试套件时，我们确定了使用时间序列数据时最常评估的特征。我们研究了三个向量的性能

  • 数据摄取性能 – 以每秒值数衡量
  • 磁盘存储要求 – 以字节为单位衡量
  • 平均查询响应时间 – 以毫秒为单位衡量

由于 Elasticsearch 是一种专用搜索服务器，并非旨在开箱即用地用于时间序列数据，因此 Elastic 建议进行一些配置更改以存储这些类型的指标。在我们的测试中，我们发现这些更改

  • 对写入或查询性能没有影响
  • 确实对存储要求产生了影响

关于数据集

对于此基准测试，我们专注于一个数据集，该数据集模拟了常见的 DevOps 监控和指标用例，其中服务器集群定期以规则的时间间隔报告系统和应用程序指标。我们每 10 秒对 9 个子系统（CPU、内存、磁盘、磁盘 I/O、内核、网络、Redis、PostgreSQL 和 Nginx）的 100 个值进行采样。对于关键比较，我们查看了一个数据集，该数据集代表 100 台服务器在 24 小时内的数据，这代表了一个相对适度的部署。

  • 服务器数量：100
  • 每台服务器测量的数值：100
  • 测量间隔：10 秒
  • 数据集持续时间：24 小时
  • 数据集中的总数值：每天 8700 万

这只是整个基准测试套件的一个子集，但它是一个具有代表性的示例。如果您对更多细节感兴趣，可以在 GitHub 上阅读有关测试方法的更多信息。

写入性能

在数据摄取方面，InfluxDB 的性能比 Elasticsearch 高出 3.8 倍。

磁盘压缩

在时间序列方面，InfluxDB 的压缩性能比 Elasticsearch 高出 9 倍。

查询性能

在返回缓存查询时，InfluxDB 在时间序列方面的性能提高了 7.7 倍。

总结

最终，你们中的许多人可能不会感到惊讶，即专门构建的时间序列数据库（旨在处理指标）在这些类型的工作负载方面将大大优于 搜索数据库。尤其引人注目的是，当工作负载需要可扩展性时（实时分析和传感器数据系统的常见特征），像 InfluxDB 这样的专用时间序列数据库会产生很大的不同。

总之，我们强烈建议开发人员和架构师 自行运行这些基准测试，以独立验证他们在选择的硬件和数据集上的结果。但是，对于那些正在寻找一个有效的起点，以确定哪种技术可以“开箱即用”地提供更好的时间序列数据摄取、压缩和查询性能的人来说，InfluxDB 在所有这些维度上都是明显的赢家，尤其是在数据集变得更大且系统运行时间更长的情况下。

下一步是什么？