Question

我正在Android应用中使用Cloud Firestore数据库，并且集合中有不同的文档，例如：用户uid，餐厅的按键和菜谱编号。

我的数据库：

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

对于我了解的用户，我可以使用uid，但最好为我的餐厅使用Firestore推送的ID？这是惯例还是为什么要使用？

我也尝试使用UUID Class来生成唯一密钥，但是对我来说，更容易在食谱中仅使用数字。这是一个不好的方法吗？

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

Answer 1

首先，Firestore中没有推送的ID。我们在Firebase Realtime数据库中使用push()方法。在Cloud Firestore中，我们将 no参数传递给document()方法，以便为文档生成唯一的ID。

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

与Firebase Realtime数据库不同，在天文学上，两个用户可以在相同的确切时间段内以相同的精确随机性生成推送ID的可能性很小，在Cloud Firestore中，这些ID实际上是纯随机的（没有时间包括组件）。

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

编辑：对于Firebase，使用顺序ID是一种反模式。不建议在Cloud Firestore或Firebase Realtime数据库中使用此技术，因为这会导致可伸缩性问题。要利用Firestore中最重要的功能之一（即可伸缩性），您应该考虑不要这样做。可伸缩性是Firestore的关键功能之一，它来自Firestore如何在其存储层上分发文档。

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

Answer 2

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

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

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

请参阅此discussion on the firebase-talk mailing list，其中一些在Firestore上工作的工程师对此进行了详细说明。

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

2 个答案: