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倍，与Elasticsearch针对时间序列优化的配置相比，磁盘空间使用减少了9倍。与Elasticsearch缓存查询的响应时间相比，InfluxDB为测试查询提供了7.7倍更快的响应时间。

值得注意的是，为Elasticsearch配置时间序列并不是一件简单的事情——它需要事先对索引、堆大小以及如何与JVM协作做出决定。另一方面，InfluxDB为时间序列工作负载提供开箱即用的功能，无需额外配置，并附带一个专为处理时间序列数据而设计的模式和查询语言。

我们认为这些数据将对评估这两种技术适用性的工程师非常有价值；特别是，涉及自定义监控和指标收集、实时分析、物联网（IoT）和传感器数据以及容器或虚拟化基础设施指标的时间序列用例。基准测试没有考虑InfluxDB对非时间序列工作负载的适用性。InfluxDB不是为满足全文搜索或日志管理用例而设计的，因此不在范围之内。对于这些用例，我们建议继续使用Elasticsearch或类似的全文搜索引擎。

要阅读基准测试和方法的完整细节，下载“基准测试InfluxDB与Elasticsearch的时间序列数据与指标管理”技术论文，或观看录制的网络研讨会。

我们的主要目标是创建一个一致且最新的比较，反映InfluxDB和Elasticsearch的最新发展，并随后涵盖其他数据库和时间序列解决方案。我们将定期重新运行这些基准测试，并更新我们的详细技术论文。所有这些基准测试的代码都可在Github上找到。如果您有任何问题、评论或建议，请在该存储库中提出问题或拉取请求。

现在，让我们看看结果……

测试版本

InfluxDB v1.8.0

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

Elasticsearch v7.8.0

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

在构建一个代表性的基准测试套件时，我们确定了与时间序列数据交互时最常评估的特性。我们考察了三个维度的性能

  • 数据摄入性能 – 以每秒的值来衡量
  • 磁盘存储需求 – 以字节来衡量
  • 平均查询响应时间 – 以毫秒来衡量

由于Elasticsearch是一个专门的搜索引擎服务器，而非直接用于时间序列数据，Elastic推荐进行一些配置更改以存储这些类型的指标。在我们的测试中，我们发现这些更改

  • 对写入或查询性能没有影响
  • 对存储需求有影响

关于数据集

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

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

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

写入性能

在数据摄入方面，InfluxDB的表现优于Elasticsearch 3.8倍。

磁盘压缩

InfluxDB在时间序列数据方面表现优于Elasticsearch，提供了9倍更好的压缩。

查询性能

当返回缓存查询时，InfluxDB的时间序列查询性能比Elasticsearch提高了7.7倍。

总结

最终，许多人可能并不惊讶于专门设计来处理指标的时序数据库在处理这些类型的工作负载时明显优于搜索引擎数据库。特别是当工作负载需要可扩展性时，这是实时分析和传感器数据系统的常见特征，专门设计的时序数据库如InfluxDB就发挥了至关重要的作用。

总之，我们强烈鼓励开发人员和架构师通过运行这些基准测试来自行验证他们选择硬件和数据集上的结果。然而，对于寻找一个有效的起点，以确定哪种技术将提供更好的“开箱即用”时间序列数据摄入、压缩和查询性能的用户，InfluxDB在这些维度上都是显而易见的赢家，特别是在数据集变得更大并且系统运行时间更长的情况下。

接下来是什么？