处理 10req/s 并保存到云存储 - 推荐的方法？答案

【问题标题】：Process 10req/s and save to cloud storage - recommended method?处理 10req/s 并保存到云存储 - 推荐的方法？
【发布时间】：2021-11-17 06:36:40
【问题描述】：

我每秒要保存 10 个数据请求，如下所示。 CloudRun 功能完成后，我需要保存这些数据。（我的基础设施在google-cloud-platform）。数据将用作机器学习的数据集。

{ 
  "text": "1k characters", 
  "text2": "1k characters", 
  "metadata1": "enum (100 vals)", 
  "metadata2": "number value" 
}

我计划将此作为非等待函数保存到google-cloud-storage 在一个文件夹中 或 在基于metadata1 enum 的文件夹中时间>。哪个比另一个好？

这是合适的路线吗？

我认为正如this SO answer. 中所建议的那样，pubsub 是矫枉过正

【问题讨论】：

是的，这是正确的选择，因为 Pub/Sub 和 Dataflow 都提供可扩展性、可用性和延迟，如果您决定在未来增加每秒的请求数。您可以在 cloud.google.com/pubsub/architecture 和 cloud.google.com/dataflow/docs/guides/deploying-a-pipeline 中阅读更多相关信息
您想在一个文件中写入多条消息吗？您需要在女巫延迟（或以哪个频率）写入文件？
@guillaumeblaquiere 写入文件的延迟无关紧要，频率取决于我收到的请求数，在这种情况下为 10/s
您认为 Pub/Sub+DF 在什么方面可能是矫枉过正 - 工程工作量、规模、成本等？完成 Cloud Run 函数调用的延迟是否是一个重要的考虑因素？您能否澄清“我计划将其保存为非等待函数”的意思，您的意思是有一个单独的云函数，它只写入云存储？
@SamarthSingal 很好的问题，工程工作量和成本。可扩展性很棒，但我预计不需要超过 10 r/s，实际上如果它可能会下降的话。我在处理程序中添加了一个函数，在它将数据发送到客户端之前，它将 JSON 数据保存到云存储（所以是的，一个单独的函数，只写入云存储）。

标签： google-cloud-platform google-cloud-storage google-cloud-pubsub google-cloud-run cloud-storage

【解决方案1】：

我可以向您推荐 2 种模式，但在这两种情况下您都需要存储消息：

要么使用 PubSub 来堆叠消息。然后，使用 Dataflow 读取 pubsub 并下沉到 Cloud Storage。或者使用按需服务（例如 Cloud Run）来拉取您的 PubSub 订阅并写入一个包含所有已读取消息的文件（例如，您可以使用 Cloud Scheduler 触发您的 Cloud Run，例如每小时一次）
或者将消息存储在 BigQuery 中，然后定期将查询导出到 GCS（再次使用 Cloud Scheduler + Cloud Functions/Run）。这是我的首选解决方案，因为可能有一天，您必须以不同的方式处理您的消息，并获取指标/对其执行分析。

【讨论】：

谢谢@guillaumeblaquiere

【解决方案2】：

@guillaume 的答案绝对是最好的，但为了便于实施，我决定直接将它们保存到 GCS。

const saveData = async ({ text, text2, enum, number }) => {
  try {
      const timestamp = new Date().getTime()
      const folder = enum
      const fileName = `${folder}/${enum}-${timestamp}.json`
      const file = bucket.file(fileName)
      const contents = JSON.stringify({ text, text2, enum, number })
      return file.save(contents)
    }
  } catch (e) {
    console.log(`Failed to save file, ${e.message}`)
  }
}

它增加了一些延迟，但总的来说，我估计服务器成本每月约为 10 美元，而 pubsub 方法在尝试确定成本时，每月大约 50-100 美元（或更多，是很难确定。但它确实假设每条消息小于 1MB 时为 1MB）。

Guillaume 提供的大查询方法appeared to have no cost，因为每个月有 1TB 的传输数据是免费的。我可能错了。稍后我可能会切换到此。

【讨论】：