我们最近发现了防火库的严重限制
其中文档在索引字段中包含顺序值的集合的最大写入速率-500 /秒
最初，我们并不认为这是一个问题，但是一旦进入开发阶段，我们就遇到了障碍。让我们以一个简单的用例为例。
考虑一个拥有100万玩家的游戏的排行榜。玩家将向此排行榜提交分数。在一周/月的月底，我们希望使用虚拟货币随机奖励所有参与者。
我们将每个玩家的分数存储在分数集合中，默认情况下，它需要根据分数值编制索引（分数可能不是随机数，但更可能是连续数）。在这方面，我们达到了500个写入/秒的限制。
计算奖励分配所花费的时间
1,000,000 / 500次写入/秒= 2000秒= 33.33分钟！
成本：$ 1.8 + 30分钟的函数处理时间
因此，奖励玩家大约需要2000秒（33分钟）才能完成上述更新。
当前，我们通过Cloud任务（如Doug所建议的）来更新上述文档，但是根据docs cloud任务的最大处理时间限制为30分钟（尽管如此，可以拆分任务以避免这种开销）。
我们非常担心，因为每个文档很可能具有创建/更新的时间戳，该时间戳不是随机数，并且受此限制的约束。
GCP上下一个可用的数据库是什么，它可以克服Firestore的局限性并需要处理来自无服务器云功能的流量？