在Cloud Firestore中使用顺序ID的限制 [英] Limitations of using sequential IDs in Cloud Firestore

问题描述

我读了一个stackoverflow帖子(链接此处)

I read in a stackoverflow post that (link here)

通过为文档使用可预测的(例如顺序的)ID，您可以增加在后端基础架构中遇到热点的机会.这降低了写操作的可伸缩性.

By using predictable (e.g. sequential) IDs for documents, you increase the chance you'll hit hotspots in the backend infrastructure. This decreases the scalability of the write operations.

我希望有人能更好地解释使用顺序ID或用户提供的ID时可能出现的限制.

I would like if anyone could explain better on the limitations that can occur when using sequential or user provided id.

推荐答案

Cloud Firestore通过为计算机分配键范围来水平扩展.当一台机器上的负载增加到超过某个特定阈值时，它将分割它所服务的范围并将其分配给2台机器.

Cloud Firestore scales horizontally by allocated key ranges to machines. As load increases beyond a certain threshold on a single machine, it will split the range being served by it and assign it to 2 machines.

比方说，您刚刚开始写入Cloud Firestore，这意味着单个服务器当前正在处理整个范围.

Let's say you just starting writing to Cloud Firestore, which means a single server is currently handling the entire range.

当您使用随机ID编写新文档时，当我们将范围分为2个时，每台计算机最终将承受大致相同的负载.随着负载的增加，我们将继续拆分成更多的计算机，每台计算机获得的负载大致相同.这样可以很好地缩放.

When you are writing new documents with random Ids, when we split the range into 2, each machine will end up with roughly the same load. As load increases, we continue to split into more machines, with each one getting roughly the same load. This scales well.

当您使用顺序ID编写新文档时，如果超出一台计算机可以处理的写入速率，则系统将尝试将范围分成2个.不幸的是，一半将没有负载，而另一半将没有负载.满载！这不能很好地扩展，因为您永远无法获得一台以上的计算机来处理您的写负载.

When you are writing new documents with sequential Ids, if you exceed the write rate a single machine can handle, the system will try to split the range into 2. Unfortunately, one half will get no load, and the other half the full load! This doesn't scale well as you can never get more than a single machine to handle your write load.

如果一台计算机运行的负载超出其最佳处理能力，则我们将其称为热点".顺序ID表示我们无法扩展以处理更多负载.顺便说一句，同样的概念也适用于索引条目，这就是为什么我们还要警告诸如now的时间戳之类的顺序索引值的原因.

In the case where a single machine is running more load than it can optimally handle, we call this "hot spotting". Sequential Ids mean we cannot scale to handle more load. Incidentally, this same concept applies to index entries too, which is why we warn sequential index values such as timestamps of now as well.

那么，过多的负载是多少?一般说来，一台机器可以处理500次写入/秒，尽管这自然取决于许多因素，例如您要写入多大的文档，事务的数量等.

So, how much is too much load? We generally say 500 writes/second is what a single machine will handle, although this will naturally vary depending on a lot of factors, such as how big a document you are writing, number of transactions, etc.

考虑到这一点，您可以看到较小，更一致的工作量不是问题，但是如果您希望根据流量进行扩展，顺序的文档ID或索引值自然会限制您只能使用数据库可以跟上.

With this in mind, you can see that smaller more consistent workloads aren't a problem, but if you want something that scales based on traffic, sequential document ids or index values will naturally limit you to what a single machine in the database can keep up with.

这篇关于在Cloud Firestore中使用顺序ID的限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！