Firestore 500+每秒写入一个集合 [英] Firestore 500+ Writes Per Second to One Collection

查看:93
本文介绍了Firestore 500+每秒写入一个集合的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Firestore限制

Firestore has a limit of 500 writes per second to

"一个集合,其中文档包含一个 索引字段"

"a collection in which documents contain sequential values in an indexed field"

https://cloud.google.com/firestore/quotas#writes_and_transactions

假设我使用最佳做法来保存文档ID在整个密钥范围内分布相对均匀.

Assuming I use Best Practices of keeping Document IDs distributed relatively evenly throughout the key range.

A)如果文档不包含任何顺序值怎么办?

例如我在每个文档中仅有的字段如下.

E.g. the only fields I have in each document is below.

  • 字段A:随机字符串
  • 字段B:随机字符串

B)如果文档包含一个顺序字段,但是我从来没有按该字段查询怎么办?

  • 字段A:随机字符串
  • 字段B(顺序):日期

C)如果文档包含顺序字段,

C) What if the document contains a sequential field, but I turn off indexing to the date in Field B?

  • 字段A:随机字符串
  • 字段B(顺序):日期(自动索引关闭)

C)第2部分-如果我关闭对该日期字段的索引编制(这消除了每秒500个的限制),如果我将Collection C随机添加到集合中的SINGLE文档中会发生什么情况?拥有一个带有字段C的文档是否会破坏对集合的每秒10,000写限制?因为现在Firestore不得不担心任何新的Field C的自动索引?

C) Part 2 - If I turn off indexing to that date field (and this removes the 500 per second limitation), what happens if I randomly add a Field C to a SINGLE document in the collection? Does having this one document with a Field C ruin the 10,000 per second write limitation to the collection? Because now Firestore has to worry about automatic indexing of any new Field C?

(然后,每当您向此集合中的任何文档中添加一个随机字段时,每次都会发生这种情况,因此必须关闭对集合中每个可能字段的索引以消除500ps的限制吗?)

(and then does this happen every single time you add a random field to any document in this collection, and therefore have to turn off indexing to every possible field in the collection to remove the 500ps limitation?)

推荐答案

每秒500次写入是对单个服务器可以处理的内容的保守估计.由于Cloud Firestore对文档和索引存储都进行水平行分片;这意味着使用顺序ID编写的文档或顺序添加的索引条目将由单个服务器处理.把这些放在一起(每台服务器500次写入+由1台服务器处理的顺序更新)就是给您带来的限制.

500 writes per second is a conservative estimate of what a single server can handle. As Cloud Firestore does horizontal row sharding for both document and index storage; this means documents written with sequential ids, or index entries being added sequentially will be handled by a single server. Putting these together (500 writes per server + sequential updates handled by 1 server) is what gives you that limit.

当您具有良好分布的数据时,我们的水平行分片可将工作负载拆分为许多服务器.对于本机模式下的Cloud Firestore,这将一直有效,直到您达到实时系统的上限,即大约10K次写入/秒.对于Datastore模式下的Cloud Firestore,没有实际限制,只要您给我们提神(客户可以超过1M写入/秒)

When you have well distributed data, our horizontal row sharding can split for workload into many servers. For Cloud Firestore in Native mode, this will work until you hit the upper limit of our realtime system, which is around 10K writes/second. For Cloud Firestore in Datastore mode, there is no practical limit as long as you give us a heads up (customers can exceed 1M writes/second)

简而言之,A)和C)将受到模式上限(10K或可用容量)的限制. B)将受到单个服务器可以处理的负载的限制.

In short, A) and C) will be limited by the upperbound of the mode (10K or available capacity). B) will be limited by the load a single server can handle.

对于C2),如果仅将其添加到单个文档中,则不会产生任何影响.该限制完全基于传入的负载以及将负载分配给哪些服务器.

For C2), there will be no impact if you are just adding it to a single document. The limit is purely based on the incoming load and what servers it gets assigned to.

这篇关于Firestore 500+每秒写入一个集合的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆