我开发了一个应用程序，可以让人们出售活动门票。每当售出门票时，我都会在 firestore 中更新代表活动门票的文档以更新统计信息。
在高峰时间，此文档会更新很多（可能每秒 10 次）。有时，由于“争用过多”，该项目文档的事务会失败，这会导致统计数据不准确，因为统计更新已被删除。我猜这是文档负载过大的结果。
为了解决这个问题，我正在考虑将项目的统计数据从 firestore 中的项目文档移动到实时数据库。在此之前，我想确保这将真正解决我在项目文档上的争用问题。实时数据库能否比 Firestore 文档更好地处理此类负载？将此类数据移动到实时数据库是否被认为是一种好的做法？
【问题讨论】：
标签： firebase firebase-realtime-database google-cloud-firestore
在高峰时间，此文档会更新很多（可能每秒 10 次）。有时，由于“争用过多”这一事实，对此项目文档的交易会失败
发生这种情况是因为 Firestore 无法处理这样的速率。根据quotas for writes and transactions的官方文档：
对文档的最大写入速率：每秒 1 次
有时它可能每秒写入两次甚至三次，但有时肯定会失败。每秒 10 次写入太多了。
为了解决这个问题，我正在考虑将项目的统计数据从 Firestore 中的项目文档移动到实时数据库。
这是我什至在这种情况下使用它的解决方案。
根据有关usage and limits in Firebase Realtime database 的官方文档，那里没有这样的限制。但它是否符合您的需求由您决定。
您还需要考虑一件事，那就是distributed counter。肯定能解决你的问题。
【讨论】：
您遇到的问题是 Firestore 的 documented limit。对单个文档的持续写入速率限制为每秒 1 个。您可能能够在一段时间内以比这更快的速度突发写入，但最终写入将失败，正如您所看到的。
实时数据库有不同的documented limits。它以写入整个数据库的数据总量来衡量。该限制为每分钟 64MB。如果你想迁移到实时数据库，只要你在这个限制之下，你应该没问题。
如果您在 Firestore 中有效地实现了计数器或其他一些数据聚合，您还应该查看 distributed counter solution，它通过跨多个文档分片数据来解决每个文档的写入限制。然后，您的客户端代码必须使用所有这些文档分片才能呈现数据。
至于其中任何一个是否是“良好实践”，这是一个见仁见智的问题，这与 Stack Overflow 无关。做任何适合您的用例的事情。我听说有人成功地使用了任何一种。
【讨论】：