当每秒超过15次写入时,Firestore写入流会耗尽。

3

我们最近开始收到写入流耗尽错误:

@firebase/firestore: Firestore (8.10.0): FirebaseError: [code=resource-exhausted]: 8 RESOURCE_EXHAUSTED: Write stream exhausted maximum allowed queued writes.
@firebase/firestore: Firestore (8.10.0): Using maximum backoff delay to prevent overloading the backend.

每15秒以500个交易为一批次地发送数百万笔交易到Firestore集合中。如果我们频率过高,就会出现上述错误。如果超出限制太多,它最终会崩溃。Firebase支持建议我们改为写入一堆子集合,但即使顺序写入单个集合时,它们的限制清楚地显示每秒500次写入。我们的文档ID不是完全顺序的,但通常很接近,例如client-id:guid,其中客户端ID在大多数写入中通常相同。 有没有什么建议可以解决这个问题?我们尝试发送更小、更频繁的批处理和更大、更少的批处理。我们创建了一个新项目,并没有创建任何索引,以查看它们是否存在问题。我们从不同的客户端发送请求,都没有超过资源限制。
2个回答

1

我们的问题最终是批处理大小。我们开始发送50个批次而不是500个,能够写入约400/s。我们仍然看到退避错误,但我们没有丢失任何数据。我还没有时间测试并行单独写入以查看是否可以获得更多的写入速度,但一旦我测试完成,我会更新这个答案。

此外,我们尝试使用他们推荐的500/50/5方法来增加批量写入速度,但仍然出现了资源耗尽错误。


0

云 Firestore 不会阻止您超过以下门槛,但这样做会影响性能,因此“500 个一批”来自于此 硬限制 和此 软限制

这里的主要问题是 热点化问题, 因为文档 ID 是 client-id:guid,其中客户端 ID 经常相同。我建议遵循最佳实践,否则您的请求将会排队,并最终返回 RESOURCE_EXHAUSTED


最初我们也怀疑热点问题,但我运行了一些替换了顺序 ID 为真正 GUID 的数百万个样本,结果没有任何区别。如果调用堆积到足够的数量,它实际上会完全耗尽流并使服务器崩溃。我们正在使用500个文档运行batch.commit(),但我们将其降低到50个,现在我们能够处理近400个/秒。我们仍然会收到资源耗尽错误,但是所有内容都已写入且没有崩溃,所以我想这就是进展。 - Adam

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接