Firestore 生成的密钥与集合中的自定义密钥？

Question

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

我的数据库：

users
  uid1
  uid2
  ...
resturants
  pushedId1
  pushedId2
  ...
recipes
  0001
  0002
  ...

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

我还尝试使用UUID 类生成唯一键但对我来说只使用数字作为我的食谱更容易。这是一个糟糕的方法吗？

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

Answer 1

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

Cloud Firestore 具有用于唯一 ID 的内置生成器，可在您调用CollectionReference.add(...)or CollectionReference.document()（不带参数）时使用。它生成的 ID 是随机且高度不可预测的，这可以防止访问后端基础设施中的某些热点。

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

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

Answer 2

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

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

与 Firebase 实时数据库中两个用户可以在相同的时间段内以相同的随机性生成推送 ID 的可能性极小不同，Cloud Firestore 中的 ID 实际上是完全随机的（不包含时间组件） .

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

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

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