在 Cloud Firestore 中使用顺序 ID 的限制

Question

我在stackoverflow帖子中读到（链接在这里）

通过为文档使用可预测的（例如顺序的）ID，您可以增加到达后端基础设施热点的机会。这降低了写操作的可扩展性。

我想如果有人能更好地解释使用顺序或用户提供的 ID 时可能发生的限制。

Answer 1

Cloud Firestore 通过为机器分配键范围来水平扩展。当单台机器上的负载增加超过某个阈值时，它将拆分它所服务的范围并将其分配给 2 台机器。

假设您刚刚开始向 Cloud Firestore 写入数据，这意味着单个服务器当前正在处理整个范围。

当您使用随机 ID 编写新文档时，当我们将范围拆分为 2 时，每台机器最终的负载大致相同。随着负载的增加，我们继续分成更多的机器，每台机器得到大致相同的负载。这很好地扩展。

当您使用连续 Id 编写新文档时，如果您超过了单台机器可以处理的写入速率，系统将尝试将范围拆分为 2。不幸的是，一半将空载，另一半满载！这不能很好地扩展，因为您永远无法获得超过一台机器来处理您的写入负载。

在单个机器运行的负载超出其最佳处理能力的情况下，我们称之为“热点”。顺序 ID 意味着我们无法扩展以处理更多负载。顺便说一句，同样的概念也适用于索引条目，这就是我们警告顺序索引值（例如时间戳）的原因now。

那么，过多的负载是多少？我们通常说 500 次写入/秒是一台机器可以处理的，尽管这自然会因很多因素而异，例如您正在编写的文档有多大，事务数量等。

考虑到这一点，您可以看到更小更一致的工作负载不是问题，但是如果您想要基于流量扩展的东西，顺序文档 ID 或索引值自然会限制您在数据库中的单个机器可以保留的内容起来。