我正在尝试找出一种可靠的策略来处理Firestore中的架构更改。我的想法是，架构更改通常需要读取然后写入集合中的每个文档（或者可能写入其他集合中的文档）。
这是我的担忧：
此外，请随时告诉我您是否认为这是实施方案更改的完全错误方法，并提出了更好的解决方案。
答案 0 :(得分：0)
我不知道将来的收藏数量会是多少。在一次查询中可以读取多少个文档，我会遇到任何限制吗？
如果文档数量太大而无法在单个查询中处理，则可以开始对结果进行分页。
我当前的计划是从Cloud Build运行模式更改脚本。可能会超时吗？
现在还不能说。
进行实际更新的最有效方法是什么？ （例如，读取文档，向文档写入更新，重复...）
如果您需要文档的现有内容来确定其新内容，那么您确实需要阅读它。如果您不需要现有内容，则只需要路径即可，并且可以考虑仅将Node.js API仅用于retrieve the document IDs。
我应该使用批量写入吗？
批量写入没有性能优势。实际上，它们通常比从您的代码中并行发送各个更新调用要慢。