【发布时间】：2022-01-23 11:03:45
【问题描述】：
因此，消息大小限制为 10Mb。
我一直使用 Pub/Sub 作为数据管道的输入和输出，因为它具有低延迟。这里的假设是 Pub/Sub 是 Google Cloud 上将数据拉入 Compute Engine 实例并一次将一个（或几个）数据点（不是以批处理方式）推出该实例的最快机制。然后具有 pub/sub 推送订阅的 Cloud Function 将输出写入 BigQuery。
我处理的 99% 的数据不超过 1MB。但也有一些异常值超过 10MB。
我能做些什么呢？利用某种压缩？将输出写入 Cloud Storage 而不是 Pub/Sub？也许到一个持久的SSD？我想确保我的计算实例一次消化一个数据点，并以最少的时间拉取和推送数据以及最多的转换时间来输出输出。
【问题讨论】：
-
如果您的消息大于几 KB，那么您的设计不正确。发布一条消息，其中包含指向存储在 Cloud Storage 上的数据的链接。 PubSub 是一个消息传递系统，而不是数据传输系统。性能会提高，成本会降低。请参阅@guillaume-blaquiere 正确答案。除非您有大量 CPU 周期可以浪费，否则不要使用压缩。
-
正如我所说，超过 99% 的消息小于 1MB。将 GCS 添加到这种组合中会引入许多不必要的复杂性和延迟。我 99% 的数据处理成本 98% 用于计算，0.5% 用于 Cloud Pub/Sub，1.5% 用于其他东西。让我的计算实例等待 GCS 上传/下载会花费更多。你还觉得我的设计不对吗？
-
极端案例决定了设计是否正确。您回答了自己的问题。
标签： google-cloud-platform google-cloud-pubsub