GCP环境下每秒10次请求数据存入GCS的推荐方案咨询

现有存储路线合理性判断 #

你当前的存储路线是合理的：

• 每秒10次的请求量级极低，单条数据大小约2KB，全年写入数据总量不到630GB，完全在GCS的性能阈值范围内，不会出现写入瓶颈
• 异步非等待写入的方式不会阻塞CloudRun的主请求链路，不会影响服务响应耗时，适配你当前的业务场景

两种存储路径方案对比 #

优先选择按metadata1枚举值分文件夹存储的方案，优势如下：

• 机器学习训练阶段筛选数据更方便：如果后续需要按某个metadata1的类别训练子集，直接读取对应前缀的文件夹即可，不需要全量扫描文件过滤字段，能大幅减少IO开销和数据处理时间
• 不会额外增加写入复杂度：100个枚举值的前缀数量很少，完全不会触发GCS的前缀性能限制，写入性能和单文件夹方案没有差异
• 运维管理更灵活：后续如果要做生命周期管理、权限细分，按前缀配置规则也比单文件夹要方便很多

单文件夹方案仅在写入路径拼接的代码复杂度上有极其微小的优势，但后续使用和管理的劣势会非常明显，不推荐选择。

Pub/Sub方案冗余性判断 #

你的判断是正确的，当前场景下引入Pub/Sub属于过度设计：

• Pub/Sub的核心价值是削峰填谷，应对高并发写入场景，你每秒仅10次的写入请求完全没有流量波动需要缓冲的需求
• 引入Pub/Sub后需要额外维护消费逻辑，增加了链路复杂度和故障点，同时也会产生不必要的成本开销
• 只有当后续你的请求量级上涨到每秒数千次以上，或者出现明显的流量尖峰、写入成功率下降的情况，再考虑引入Pub/Sub做中间缓冲即可。

内容的提问来源于stack exchange，提问作者Kevin Danikowski