我们如何让InfluxDB Cloud和Flux更快

导航到

性能自去年推出以来一直是InfluxDB Cloud用户最关心的问题,也是我们的投资领域。

我们最近性能提升的主题是聚合;我们从后端平台到前端用户界面进行垂直切割,以改进全栈的聚合。

我们最近已经跨越了关键的性能阈值,并希望与我们的早期采用者分享这些成果:那些拥抱InfluxDB最新版本——作为云原生数据库作为服务的探索者和付费客户。Flux是我们新的查询语言,它允许我们为时间序列数据库的运行时间定义一个新的前沿。

我们已经从您那里学到了很多,希望您将在这次聚合性能改进的最新批次中看到许多您关心的事情得到了优化。

达到关键性能阈值

  • 常见的Flux聚合查询的响应时间对于标准时间序列工作负载来说是在秒以下,对于我们在平台上看到的最大工作负载来说只需几秒钟。这代表了查询持续时间减少了最多2到60倍,具体取决于您数据的复杂程度。
  • 查看组织的使用情况快了25倍,现在使用页面的平均加载时间已经低于秒。
  • InfluxDB Cloud仪表板现在快了两倍(感谢去重查询!)。仪表板体验的许多方面都有了显著的提升,包括打开仪表板、配置单元格、更改时间范围以及渲染可视化。
  • 优化使之前无法实现的可视化成为可能,例如查看20,000到300,000个系列之间的原始数据图表。小于20,000个系列的较小图表也快了45%。

绝对运行性能只是“速度”衡量的一部分;时间的价值也是用户是否认为平台快的贡献因素。

这就是为什么您现在可以通过两种额外的方式更快地获取查询结果

1. 默认构建优化查询

我们在查询构建器中引入了大量自动优化。这意味着您不会浪费时间检索数据,然后再迭代到一个可管理的大小。

我们选择时间范围——无论是一个小时还是一个月——并自动选择一个将返回可显示结果的时间窗口。为了填充时间窗口,查询构建器还应用了自动聚合,如平均数、中位数或最后,这与您的数据类型相匹配。这意味着数据探索器可以防止您构建会导致用户界面崩溃的查询;您始终可以切换到脚本编辑器来编写那些破坏浏览器的查询 ;)。

让我们通过查询构建器中的自动聚合来探索一个示例。假设我有一个每秒流式传输数据的设备,并且我想查看一个月的数据。查询构建器会自动应用平均聚合和一小时的时间窗口。换句话说,你现在可以以每小时一个窗口的平均值,得到设备在整个月内行为的高层次视图。你不需要进行任何思考。

物联网设备经常因连接问题而遭受数据丢失。现在,查询构建器还会通过创建空的时间窗口来平滑数据,这样如果设备丢失连接,且没有值存在,它就不会使数据的整体形状人为地变得尖锐。随着越来越多的物联网应用程序开发人员涌入InfluxDB云,我们需要越来越多地解决稀疏数据的问题。

能够快速撤销我们默认应用的“自动化”功能也是关键。因此,所有这些自动聚合都可以一键删除或重新应用。

更进一步,我们经常想同时查看最小值、最大值和平均值。因此,我们使添加多个聚合在一起并将其默认应用于单个时间序列变得容易。为了表示这一点,我们引入了一种条形图可视化,它显示了最小值和最大值之间的阴影范围,平均值或中位数穿过它。

autoaggregation influxdb cloud flux<figcaption> 用阴影范围表示聚合值周围的平均值或中位数的最小值和最大值</figcaption>

2. 返回查询聚合结果更快(并在你认为它耗时太长时让你退出)

Flux聚合为什么更快?答案主要归功于数据局部性突破。

我们现在在数据存储的地方执行聚合,而不是将所有数据移动到执行聚合的地方。我们过去在查询层运行了许多查询,这是合理的,但现在我们检查查询并查看可以在存储层运行的操作,在将数据集拖到网络之前。

以下是我们的优化聚合函数列表

  • 首先
  • 最后
  • 计数
  • 求和
  • 最小值
  • 最大值
  • 平均值

除了平均值外,函数可以用于以下代码的任何排列组合

|> range
 |> filter
 |> group
 |> aggregateWindow(fn: first/last/count/sum/min/max)

虽然我们希望您的响应时间更快,但我们还构建了一个新的逃生通道。现在,您可以通过点击一个出现在一秒后的“取消”按钮来暂停查询,而不是按下浏览器后退按钮,从而丢失一切。

竞争作为性能改进驱动力

在功能工作和持续性能改进之间存在着真正的权衡。对于我们的云原生服务,我们致力于实现可扩展且高性能的堆栈,就像我们以前一样。我们不会撒谎。当InfluxDB是定义这个新兴时间序列数据库类别的唯一解决方案时,事情要容易得多。今天,我们在性能方面的竞争比以往任何时候都更加激烈,而这最终是我们为了在竞争更加复杂和拥挤的环境中做到最好而不断努力的一个极好的驱动力。有更多的参与者使我们能够重新测试,确保我们是针对时间序列用例的最佳解决方案,与真实替代品相比。

我们遇到的许多性能问题并不是关于InfluxDB云本身,而是有关相关技术如何在平台上相互作用。这意味着我们的团队不仅要优化平台的每个细节,还要努力学习数十个集成点的细微最佳实践,以确保我们坚持开源价值观。

我们很感激我们的竞争对手和忠实粉丝如此努力地推动我们。对于一些人来说,“好”可能就足够了,但大多数人想要更多。在我们发布新的、定义类别的重大赌注的同时,比如发明一种新的编程语言(Flux!)或从头开始重新编写我们流行的数据库(InfluxDB OSS 2.0!),我们将继续进行性能工程。我们的记录显示,InfluxData不做“常规业务”——我们打赌这就是为什么你们如此喜欢我们的原因。