在 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屋！