InfluxData 如何提升 InfluxDB Cloud 和 Flux 的速度
作者：Molly Norris Walker / 用例, 产品, 开发者
2020 年 8 月 19 日
导航至
自一年前推出以来，性能一直是 InfluxDB Cloud 用户的首要关注点和投资领域。
我们最近性能提升的主题是聚合；我们从后端平台到前端用户界面进行了垂直切片，以改进整个堆栈的聚合。
我们最近突破了关键性能阈值，并希望与我们的早期采用者分享这些成果：包括探索者和付费客户，他们拥抱了 InfluxDB 最新的云原生数据库即服务形态。Flux 是我们新的查询语言，它使我们能够为时间序列数据库运行时定义一个全新的前沿。
我们已经从您那里学到了很多，希望您能在最新的聚合性能改进中看到许多您关心的事情得到了优化。
达到的关键性能阈值
- 对于标准时间序列工作负载，常见 Flux 聚合查询的响应时间为亚秒级，而对于平台上看到的最大工作负载，响应时间仅为几秒。这表示查询持续时间缩短了 2 到 60 倍，具体取决于数据的复杂性。
- 查看组织的使用情况速度提高了 25 倍，并且 使用情况 页面的平均加载时间现在为亚秒级。
- InfluxDB Cloud 仪表板现在的速度是原来的两倍（去重查询万岁！）。仪表板体验的许多方面都得到了显著加速，包括打开仪表板、配置单元格、更改时间范围以及渲染可视化。
- 优化使以前无法实现的可视化成为可能，例如查看包含 20,000 到 300,000 个序列的原始数据图表。绘制少于 20,000 个序列的小型图表也快了 45%。
绝对运行性能只是“速度衡量标准”的一部分；价值实现时间也是用户是否认为平台速度快的因素之一。
这就是为什么您现在可以通过另外两种方式更快地获得查询结果
1. 默认构建优化的查询
我们在查询构建器中引入了一系列自动优化。这意味着您不会浪费时间过度获取数据，然后再迭代缩小到可管理的大小。
我们获取时间范围（无论是一个小时还是一个月），并自动选择一个时间窗口，该窗口将根据可用像素返回可显示的结果。为了填充时间窗口，查询构建器还应用自动聚合，例如平均值、中位数或最后一个值，以匹配您的数据类型。这意味着数据浏览器可以防止您构建导致用户界面崩溃的查询；您始终可以切换到脚本编辑器来编写那些破坏浏览器的查询 😉。
让我们探索查询构建器中自动聚合的示例。假设我有一个设备每秒流式传输数据，我想查看一个月的数据。查询构建器自动应用平均值聚合和一小时的时间窗口。换句话说，您现在可以获得设备在一个月内的行为的高级概览，数据窗口化为可管理的一小时块，并具有平均值。您无需进行任何思考。
物联网设备经常因连接问题而遭受数据丢失。查询构建器现在还通过创建空时间窗口来平滑数据，这样，如果设备失去连接并且没有值存在，它就不会使数据的整体形状人为地变得尖峰。随着越来越多的物联网应用程序开发者涌向 InfluxDB Cloud，我们需要越来越多地解决稀疏数据问题。
能够快速撤消我们默认应用的“自动魔法”也很关键。因此，所有这些自动聚合都可以通过单击一下来删除或重新应用。
更进一步，我们经常希望同时查看最小值、最大值和平均值。因此，我们简化了将多个聚合添加到一起并将它们默认应用于单个时间序列的过程。为了表示这一点，我们引入了带状图可视化，该可视化显示最小值和最大值之间的阴影范围，平均值或中位数从中穿过。
<figcaption> 用于表示平均值或中位数聚合值周围的最小值和最大值的阴影范围</figcaption>
2. 更快地返回查询聚合结果（如果您认为时间过长，可以让您放弃）
为什么 Flux 聚合更快？答案主要归功于数据局部性突破。
我们现在在数据存储的位置执行聚合，而不是移动所有数据来执行聚合。我们过去常常在查询层中运行许多查询，这很有道理，但我们现在检查查询，看看哪些可以在存储层中运行，然后再将数据集拖过网络。
以下是我们优化的聚合函数列表
- First (第一个)
- Last (最后一个)
- Count (计数)
- Sum (总和)
- Min (最小值)
- Max (最大值)
- Mean (平均值)
除了 Mean (平均值) 之外，这些函数可以用于以下代码的任何排列组合中
|> range
|> filter
|> group
|> aggregateWindow(fn: first/last/count/sum/min/max)虽然我们希望您的响应时间更快，但我们也构建了一个新的逃生舱口。您现在可以通过单击在没有粉碎浏览器后退按钮且丢失所有内容的情况下在一秒钟后出现的 取消 按钮来暂停查询。
竞争作为性能改进驱动力的作用
在功能工作和持续性能改进之间存在真正的权衡。对于我们的云原生服务，我们一如既往地致力于充分实现可扩展且高性能的堆栈。我们不会撒谎。当 InfluxDB 是唯一定义这个新兴时间序列数据库类别的解决方案时，事情要容易得多。今天，我们在性能方面的竞争比以往任何时候都更加激烈，最终，即使环境变得更加复杂和拥挤，这也是推动我们尽最大努力的绝佳动力。拥有更多的参与者使我们能够针对真正的替代方案重新测试我们是否是时间序列用例的最佳解决方案。
我们遇到的许多性能问题不是关于 InfluxDB Cloud 本身，而是关于相关技术如何在平台上相互作用。这意味着我们的团队不仅要优化平台的每个细节，还要努力学习数十个集成点的所有细微最佳实践，我们需要保持对开源价值的忠诚。
我们感谢我们的竞争对手和忠实粉丝如此努力地推动我们。“好”可能对某些人来说足够好，但我们大多数人想要更多。我们将继续进行性能工程，同时我们还将发布新的、定义类别的大赌注，例如发明一种新的编程语言 (Flux!) 或从头开始重写我们流行的数据库 (InfluxDB OSS 2.0!)。我们的业绩记录表明 InfluxData 不会“照常营业”——我们敢打赌这就是您如此喜欢我们的原因。
