我在我的 Android 应用程序中使用 Cloud Firestore 数据库，并且我在集合中有不同的文档，例如：用户的 uid、餐厅的按键和我的食谱的数字。

我的数据库：

对于我了解使用 uid 但最好为我的餐厅使用 Firestore 推送 id 的用户？这是一个约定还是为什么要使用它？

我还尝试使用 UUID 类生成唯一键，但我更容易在我的食谱中只使用数字。这是一个不好的方法吗？

任何帮助将不胜感激，谢谢！

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

Cloud Firestore 有一个内置的唯一 ID 生成器，当您调用 CollectionReference.add(...) 或 CollectionReference.document()(不带参数)时会使用该生成器。它生成的 ID 是随机且高度不可预测的，这可以防止命中后端基础架构中的某些热点。

为用户的文档使用 UID 可以很好地替代 Firestore 的内置生成器，因为 UID 已经具有高熵：您无法根据已知信息预测下一个用户的 UID当前用户。在这种情况下，使用 UID(或实体的自然键)是一种更好的方法，因为您可以直接查找文档而不必进行查询。

请参阅 firebase-talk 邮件列表中的此讨论，其中一些从事 Firestore 的工程师对此进行了更详细的解释。

首先，Firestore 中没有推送的 id。我们在 Firebase 实时数据库中使用 push() 方法。在 Cloud Firestore 中，我们不向 document() 方法传递任何参数，以便为文档生成唯一 ID。

对于用户，最好的唯一标识符是 uid。对于其他集合，如 resturants、recipes 或任何其他集合，您应该考虑使用 Firestore 生成的 id。

与在 Firebase 实时数据库中，两个用户可以在相同的确切时间段内以相同的确切随机性生成推送 ID 的可能性非常小，但在 Cloud Firestore 中，ID 实际上是纯粹随机的(那里\\' s 不包括时间组件)。

作为答案，您绝对应该使用 Firestore 生成的随机密钥。不要使用简单的数字作为文档的键。

编辑：对于 Firebase，使用顺序 ID 是一种反模式。不建议在 Cloud Firestore 或 Firebase 实时数据库中使用此技术，因为它会导致可扩展性问题。要从 Firestore 中最重要的功能之一(可扩展性)中受益，您应该考虑不这样做。可扩展性是 Firestore 的主要功能之一，它来自 Firestore 如何将文档分散到其存储层。

使用其他技术而不是 Firestore 提供的技术，会增加散列冲突，这意味着您可以在更短的时间内达到写入限制。拥有绝对随机 id 可确保写入在存储层中均匀分布。