TL;DR InfluxDB 技术提示: 迁移到 InfluxDB 云

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

导航至

如果您是 InfluxDB 用户，您可能正在考虑将您的工作负载迁移到 InfluxDB 云。您可能想要将自己从与管理和维护您的 OSS 账户相关的责任中解放出来。也许您发现您根本无法垂直扩展您的 OSS 实例以满足您的需求。您可能想要使用 InfluxDB Cloud 中提供的所有 Flux 函数。也许您已决定想要一个中央实例来存储来自 边缘 的 OSS 实例的 IoT 数据，并且您想要利用 InfluxDB 边缘数据复制功能。无论如何，在进行迁移时，了解扩展注意事项非常重要。

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

InfluxDB-cloud-vertical-scaling

以上图表描述了用户在 InfluxDB Cloud 中执行繁重查询时必须采取的方法变更。通过利用任务系统使用持续计算解决方案，用户能够返回他们以前通过效率低下的查询获得的数据。

用户迁移到 InfluxDB 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 提供水平可用性的更多信息，请阅读此博客。

  • 统一的开发者体验。Enterprise、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 秒以上，并使用 查询管理器 来执行此查询。或者，他们可能向上扩展了他们的 VM，以便为其 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 之上开发一个很酷的 IoT 应用程序，我们很乐意听到它，因此请务必在社交媒体上使用 #InfluxDB 分享它！此外，请随时在我们的社区 Slack 频道中直接与我联系，分享您的想法、疑虑或问题。我很乐意获得您的反馈并帮助您解决遇到的任何问题！