我的 firebase firestore 数据库有一个名为“blockouts”的子集合，其中每个文档都有一个包含 5 个数字和两个尾随零的 ID。零是重要的默认值。我可以添加具有此 ID 模式的文档，直到昨天。现在它会在添加文档后立即自动删除它。当我手动尝试在 Firebase 控制台上添加文档时会发生这种情况。
例如，我无法添加文档 1234500 或 abcde00。但我可以加 1234560 或 abcdef0。
我认为这个问题是这个项目独有的，因为我尝试在另一个项目中使用控制台上的模式没有问题。但我需要它在这个项目中工作。谁能想到这可能发生的原因？
【问题讨论】：
标签： firebase google-cloud-firestore document
我第一次尝试解决这个问题是使用 7 位数字和两个尾随 9，而不是尾随 0。然后 Firestore 会让我在控制台上添加一个像 1234599 这样的文档。所以我将代码更改为使用尾随 9 而不是 0。然后我运行我的用户启动例程，该例程使用这种命名模式在 for 循环中上传大约 40 个小文档。文件会出现，然后很快变红，然后在我眼前在控制台中删除。之后，我无法再按照尾随 9 的模式在控制台上添加文档。它们会变红并再次被删除。我的代码捕获块中没有出现错误。
红色让我认为撒旦以某种方式参与其中。
但在引入驱魔师之前，我偶然发现了"Best practices for Cloud Firestore"。在这里我发现了我认为的问题。
不要使用单调递增的文档 ID，例如： 客户 1、客户 2、客户 3、... 产品 1、产品 2、产品 3、... 这种顺序 ID 可能会导致影响延迟的热点。
我的模式与此类似，不是连续的，而是不断增加的。
还有：
避免每秒多次写入文档。
这肯定发生在我身上。大约 1 秒内上传了 40 个文档。
所以我尝试在我的 for 循环中延迟 1.5 秒。现在，即使我切换回尾随零，它似乎也可以正确上传。在这一点上，延迟时间对我来说不是问题。但是当我有脑力时，我会研究批量交易选项。
我建议任何考虑使用 Firestore 的人在提交之前查看最佳实践。那里可能有一些交易破坏者。您违反了其中一种做法可能并不明显。我的 MO 是仅在出现问题并且收到错误消息时才阅读文档。在这种情况下没有错误，只是撒旦。
【讨论】：