能否使用Cloud Firestore同步100MB左右的大型Parquet文件？

分片写入Firestore的可行性 #

技术层面可以实现，但非常不推荐，仅适合极特殊的低频场景临时使用：

• 实现逻辑：你可以将100MB的Parquet文件切分为小于1MiB的分片，每个分片单独写入一个Firestore文档，同时单独维护一个主控文档存储文件元数据（包括总分片数、分片索引映射、文件哈希校验值、原始文件名等）。同步时先拉取主控文档获取元数据，再按索引拉取全部分片，本地拼接后校验完整性即可完成同步，也可依托Firebase的实时同步能力将分片同步给其他授权用户。
• 核心缺陷：
  • 成本过高：Firestore按文档读写次数计费，100MB文件对应至少100次写操作，单次读取也需要100次读操作，多用户同步场景下读操作次数会随用户数线性增长，高频使用成本会远高于常规对象存储方案。
  • 维护成本高：你需要自行实现分片切割、断点续传、完整性校验、分片缺失重试等逻辑，网络波动场景下容易出现同步失败问题。
  • 配额消耗快：Firestore有每秒读写次数的配额限制，批量分片操作很容易触发配额阈值导致业务受阻。

Firebase生态适配方案 #

Firebase体系内有专门适配大型二进制文件存储同步的产品：Firebase Cloud Storage，是该场景的最优选择：

• 单文件支持最大数TB级存储，无需自行实现分片逻辑，官方SDK已经封装了断点续传、进度回调、完整性校验等能力，100MB的Parquet文件可以直接上传。
• 天然和Firebase权限体系打通，你可以通过配置Storage安全规则控制不同用户的读写权限，满足你同步给其他用户的需求。
• 同步完成后仅需要将Storage文件的访问路径存储在Firestore文档中，依托Firestore的同步能力分发路径即可，用户拿到路径后可直接从Storage拉取文件，成本仅为1次Firestore读写+1次对象存储读写，性价比远高于分片存Firestore的方案。

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