Firestore 集合具有时间戳字段时的索引查询答案

【问题标题】：Query on Indexing when Firestore collection has Timestamp fieldFirestore 集合具有时间戳字段时的索引查询
【发布时间】：2020-12-14 17:08:57
【问题描述】：

我有一个 Firestore 项目，其中我的集合 feed 有一个时间戳字段 createdDate。当我根据创建时间和其他字段查询提要时，我创建了一个 Composite Index 包括时间戳字段。

在Indexing best practices 文档中提到了以下内容。

如果您索引的字段在集合中的文档，例如时间戳，然后是最大写入对集合的速率是每秒 500 次写入。如果不查询基于具有连续值的字段，您可以豁免该字段从索引绕过这个限制。

由于我已经在 Composite Index 中使用时间戳字段，因此我可以将该字段从 Automatic Index Settings 中排除。这是否会绕过集合中每秒 500 次写入的限制，或者在 Composite Index 正在使用该字段时仍将应用它。请帮助我理解这一点。

【问题讨论】：

【解决方案1】：

限制来自集合中任何索引中存在热点。虽然 Firestore 可以并行更新所有索引，但其吞吐量受到最慢索引的限制。从一个索引中移除热点，但将其保留在另一个索引上，这意味着集合的写入吞吐量不会增加。

请注意，这不是硬编码限制，而是来自必须跨多个数据中心更新集群文件的物理限制。

【讨论】：

感谢@Frank 的解释。我几乎明白了。现在使用时间戳或增加数值是一个非常常见的场景，并且主要使用时间戳以便我们可以使用它进行查询。因此，需要完成索引。对于我的场景是否有任何建议或最佳实践，其中像 Feed 这样的集合将有成千上万的用户写入并且我需要一个时间戳？
另外，我想了解文档何时说时间戳是“按顺序增加或减少”。像 Feed 这样的集合将创建大量的文档，其时间戳会不断增加，但它们显然不是连续的或“单调递增的”。
我看到大多数开发人员高估了他们的用户写入相同位置/集合的需求，所以如果我是你，我会首先研究一下。数以千计的用户，当然是这样，但是每秒有数千个？如果你真的这样做，请通过一个去抖它们的代理集中写入。世界上一些最大的应用程序正在使用 Firestore 或其祖先 Datastore 来处理巨大卷，这是一个支持您的读写量的架构的问题。
感谢@Frank 的建议。我还发现了这份文件，我认为它可以帮助我firebase.google.com/docs/firestore/solutions/shard-timestamp
不错。我不知道我们有分片时间戳的文档，否则我肯定会立即指出这一点。感谢分享！