除脱机可用性之外，分批写入是否对交易有任何好处？
这是假设事务比批量写入更安全。
我正在考虑将Cloud Functions代码从分批写入迁移到交易。最初的想法是，它会更安全。
我担心批量写入失败时云功能将无法捕获，并且至关重要的是，实际上要应用所有写入（在不同集合中更改许多文档）。
我read this answer很高兴听到以下消息：
如果您不需要或不想在离线状态下写东西，只需使用常规交易即可：它将处理您是否在线，如果离线则失败。您没有义务阅读交易中的任何内容。
这基本上表明批量写入的唯一要点是离线可用性。这证实了我的最初想法，但是，我也阅读了文档。
"Transaction and batched writes" documentation指出，分批写入“失败案例少于事务”。
现在，我有些困惑。就我的情况而言，关于transaction failure的唯一有效担忧是：
交易记录读取了在交易记录之外修改的文档。在这种情况下，事务将自动再次运行。重试该交易次数。
由于我的Cloud Functions使用的写入操作完全是 update 操作，我想知道这是否适用于我的情况，即批量写入是否会遇到这样的问题？问题。按照我的想象，批量写入只会更新一千个文档，而所有这些更新仅会修改一个字段。
当事务执行相同操作时，何时会发生此故障？
而且由于我使用的是 Cloud Functions （我一直在线），所以批量写入是否会遇到任何问题？
+交易：更安全，不会失败
+批量写入：更少的失败案例，不会失败
您能看出我的困惑吗？
关于代码的简单性：我认为批处理写入看起来更加简洁，但是，就我而言，实际上是更多的代码。因此，对我来说没关系。
答案 0 :(得分：0)
事务与批处理写入没有真正的可比性。您应该选择适合手头工作的工具。他们唯一的共同点是，当操作完成时，所有文档都将在同一时刻写入（它们是原子的）。它们也都可能由于违反安全规则而失败，就像来自客户端应用程序的任何其他操作一样。
这是您的决定方式：
批量写入
交易