新Firestore的限制说明 [英] A limit clarification for the new Firestore

问题描述

因此在限制"部分中( https://firebase.google.com/docs/firestore/配额)，它来自Firebase的新Firestore产品，内容为:

包含文档的集合的最大写入率 索引字段中的连续值:每秒500个

对于实际需要的内容，我们感到很困惑.

例如，如果我们有一个名为users的根级集合，其中有1000万个条目，此速率是否会以这种方式影响此集合，因此在给定的每秒内只有500个用户可以更新其数据? /p>

任何人都可以澄清吗?

解决方案

很抱歉造成混乱；一个例子可能会有所帮助.

如果您的用户文档包含最近更新的时间戳，并且您在该时间戳上建立了索引，则每个新写入将最终聚集在相同的值(现在)附近，从而在索引中创建一个热点.

类似地，如果您以某种方式为用户分配了顺序值(例如，排队的位置)或类似的值，这也会创建一个热点.

这就是为什么生成的文档ID是随机字符串的原因.这样可以将写操作平均分配到主键索引上.

如果您避免使用此类模式，那么天空就是极限，尽管在beta期间您已经达到了数据库范围的极限.

So in the limits section (https://firebase.google.com/docs/firestore/quotas) of the new Firestore product from Firebase it says:

Maximum write rate to a collection in which documents contain sequential values in an indexed field: 500 per second

We're pretty confused as to what that actually entails.

If we have, say, a root-level collection called users with 10 million entries in it, will this rate affect this collection in such a way, so only 500 users can update their data in any given second?

Can anyone clarify?

解决方案

Sorry for the confusion; an example might help.

If your user documents contained a last-updated timestamp and you index on that timestamp then each new write would end up clustering around the same value (now) creating a hotspot in the index.

Similarly if you somehow assigned users a sequential value like a place in line or something like that this would also create a hotspot.

Incidentally this is why generated document IDs are random strings. This evenly distributes the writes on the primary key index.

If you avoid these kinds of patterns the sky's the limit, though during beta you'd hit the database-wide limit.

这篇关于新Firestore的限制说明的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！