TL;DR InfluxDB 技术小贴士：迁移到 InfluxDB Cloud

作者：Anais Dotis-Georgiou / 开发者，产品
2022年7月14日

导航到

如果您是 InfluxDB 用户，您可能会考虑将您的作业迁移到 InfluxDB Cloud。您可能希望摆脱与管理和提供服务相关的责任。也许您发现您无法垂直扩展您的 OSS 实例以满足需求。也许您想使用 InfluxDB Cloud 中可用的所有 Flux 函数。也许您已经决定需要一个集中的实例来存储来自边缘 OSS 实例的物联网数据，并想利用 InfluxDB Edge Data Replication 功能。无论情况如何，在迁移时了解扩展考虑因素都很重要。

如果您是轻量级 OSS 用户，迁移不应成为问题，并且您应该能够无问题地遵循 OSS 到 Cloud 迁移指南。但是，如果您已经垂直扩展您的 OSS 实例以处理令人印象深刻的查询和写入工作负载，那么在迁移到 Cloud 时您需要调整一些思考方式。具体来说，您需要从“我只是给我的 InfluxDB 实例提供更多资源来查询大量数据”转变为“我需要考虑如何利用 InfluxDB 的任务系统来获得预期的查询性能。我需要创建一个连续计算解决方案，以便 InfluxDB 将我的昂贵查询分解成组件部分”。

InfluxDB-cloud-vertical-scaling

以上是描述用户在 InfluxDB Cloud 中执行重查询时必须采取的方法变化的图表。通过利用任务系统通过连续计算解决方案的使用，使用户能够返回与之前使用低效查询获得相同的数据。

迁移到 InfluxDB Cloud 的用户面临的问题

有三种类型的用户会迁移到 Cloud

  1. 企业用户

  2. 开源软件（OSS）用户

  3. Cloud 1 用户

这些用户在迁移到 InfluxDB Cloud 时面临的最常见问题是他们在 InfluxDB Cloud 中遇到查询超时。对于企业和 Cloud 1 用户来说，这是因为在企业和 Cloud 1 中支持垂直和水平扩展。InfluxDB Cloud 或 Cloud 2 不提供垂直扩展。此外，查询超时时间为 2.5 分钟。同样，许多 OSS 用户通过提供额外的计算和存储资源或增加查询超时时间来垂直扩展他们的 OSS 实例，以容纳查询和转换大量数据的 Flux 脚本。然而，这些用户仍然想利用 InfluxDB Cloud 的以下独特功能

  • InfluxDB OSS v2 和 InfluxDB Cloud 的统一 API

  • 边缘数据复制功能

  • 使用 Flux 的巨大数据处理和转换能力

  • 托管的无服务器和弹性服务

  • 多租户、水平可扩展的时间序列存储。要了解InfluxDB Cloud如何通过Kafka提供水平可用性，请阅读这篇博客。

  • 统一的开发者体验。企业版、Cloud 1版或OSS 1.x版用户不再需要管理一系列产品来管理他们的时间序列数据（Telegraf、InfluxDB、Chronograf和Kapacitor）。他们也不再需要学习多种查询语言（InfluxQL、连续查询和TICKscripts）。相反，他们只需使用InfluxDB Cloud和Flux。

避免查询超时和持续计算

为了避免查询超时，迁移用户必须利用任务系统来卸载查询工作负载。例如，假设你是OSS用户。你使用Flux查询过去30天的数据，对其进行下采样，然后进行计算。你的Flux查询可能如下所示

from(bucket: "<bucket>")
  |> range(start: -30d)
  |> filter(fn: (r) => r["_measurement"] == "<measurement>")
  |> aggregateWindow(every: 1h, fn: mean, createEmpty: false)
  |> yield(name: "mean")
  |> map(fn: (r) => ({ r with _value_celcius: (float(v: r._value) - 32.0)*(5.0/9.0) }))  
  |>  yield(name: "converted to celsius")

在这种情况下，用户感兴趣的是

  1. 查询大量数据

  2. 查看该数据的下采样数据，或1小时周期的平均值

  3. 对该下采样数据进行计算，例如将华氏度转换为摄氏度。

可能这个用户能够通过将查询持续时间延长到默认的10秒以上以及使用查询管理设置来执行此查询。或者，也许他们扩大了虚拟机规模，为OSS实例提供更多资源以更快地执行此查询。但无论如何，InfluxDB Cloud中不再提供这些选项。相反，他们必须将这项工作分成一系列任务。这些任务将在单独的步骤中执行这项工作，并将中间值写入新的桶中。除了使用户能够执行此查询外，将查询拆分为任务还提供以下额外优势

  • 更快地查询执行

  • 更快地加载依赖于这些中间任务输出的仪表板

  • 不同桶之间的一些数据冗余

用户必须完成这项工作需要两个任务

  1. 第一个任务将在更高的频率下进行下采样，并将输出写入新的桶。此外，用户应考虑为每个标签创建一个下采样任务，而不是同时下采样所有数据，以减少查询并将查询进一步分解。

  2. 第二个任务将执行计算，并将计算结果写入新的桶或新的度量。

这样，用户只需查询第二个任务的输出。

第一个任务可能如下所示

option task = { name: "downsample", every: 1h0m0s, offset: 5m0s }
from(bucket: "<bucket>")
  |> range(start: -task.every)
  |> filter(fn: (r) => r["_measurement"] == "<measurement>")
  |> filter(fn: (r) => r["<takKey1>"] == "<tagValue>")
  |> aggregateWindow(every: 1h, fn: mean, createEmpty: false)
  |> to(bucket: "<downsampled and calculation bucket>"

第二个任务可能如下所示

option task = { name: "calculation", every: 1h0m0s, offset: 5m0s }
from(bucket: "<downsampled and calculation bucket>")
  |> range(start: -task.every)
  |> filter(fn: (r) => r["_measurement"] == "<measurement>")
  |> filter(fn: (r) => r["<takKey1>"] == "<tagValue>")
  |> map(fn: (r) => ({ r with _value_celcius: (float(v: r._value) - 32.0)*(5.0/9.0) }))  
// this will overwrite your downsampled points to include the downsampled value and your celsius calculation
  |> to(bucket: "<downsampled and calculation bucket>"

在任务运行一段时间后，用户将能够使用以下方式查询其数据

from(bucket: "<downsampled and calculation bucket>")
  |> range(start: -30d)
  |> filter(fn: (r) => r["_measurement"] == "<measurement>")
  |>  yield(name: "fast query”)

并且返回数据而不出现查询超时。如果您想要能够查询从开始到现在的长时间范围，您可能需要单独执行一些下采样操作。您可以在不使用任务的情况下这样做。通过查询特定标签、逐步改变范围并将结果写入您的“下采样和计算桶”来处理此操作。

关于迁移用户查询超时的最后想法

我希望这篇博客文章能激发您利用任务系统来减少查询负载并充分利用InfluxDB Cloud。如果您是InfluxDB开源用户并需要帮助，请通过我们的社区网站或Slack频道联系。如果您在InfluxDB之上开发酷炫的物联网应用程序，我们非常乐意了解相关信息，确保在社交媒体上使用#InfluxDB分享！此外，您可以直接在我们的社区Slack频道联系我，分享您的想法、关注点或问题。我很乐意获取您的反馈并帮助您解决遇到的问题！