定义 Firestore 文档 ID 可接受的词典相似性

Question

我在Firebase Firestore 文档的“最佳实践”中看到，您应该：

避免按字典顺序关闭文档的高读取或写入率，否则您的应用程序将遇到争用错误。

给出的如何不写入文档 ID 的示例是：

客户 1、客户 2、客户 3、...

---

我正在将数据从外部服务映射到 Firestore 集合，并且我想保留它们的原始 ID 名称。它们以 为前缀entry_，但以随机/唯一字符串作为后缀，如下所示：

entry_{Unique_String}, entry_{Unique_String}, ... entry_{Unique_String}

每个文档 ID 是否以 为前缀entry_，但后跟一个随机字符串，将文档分类为按字典顺序接近并因此容易成为热点的文档？

或者，只有当它们确实被命名时才会被归类为：

entry_1, entry_2, entry_3, entry_4 ... <and so on>

我当然可以entry_在读取/写入时删除/添加 ID，但这会增加服务器/客户端的复杂性。*

*根据 Alex Mamo 的评论进行编辑以澄清：

由于以下示例，复杂性会增加：

• "entry_"在原始数据集上下文中读取/写入文档或需要发送回外部服务的任何地方，引入剥离/前置功能。
• 可能需要创建文档字段来跟踪（例如type = "entry"）在同一个集合中使用多个类别的文档 ID 的情况——根据用例，这可能不是一个缺点，例如，如果执行类型比较。
• 对于源自相同外部服务且具有相同前缀唯一字符串的其他类别类型（例如foo_， ）重新实现上述内容非常繁琐。bar_

Answer 1

该产品的可扩展性来自于 Firestore 将文档分布在其存储层上。简而言之，顺序 ID 具有更多的哈希冲突，这意味着您可以更快地达到写入限制。具有更随机的 ID 可确保写入均匀地分布在存储层上。我建议您不要使用 1、2、3 或 4 作为节点或其组合的键。对于 Firestore 而言，使用顺序 ID 是一种反模式，因为它肯定会导致可扩展性问题。所以我强烈建议您使用这些随机文档 ID。

有关更多信息，我建议您阅读 Dan McGrath 在以下帖子中的回答：

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

编辑：

正如您在评论之一中显示的那样，那些以常量为前缀的随机 ID 可以按顺序运行。

我为什么这么说呢？

当您在不传递任何参数的情况下调用 CollectionReference 的add()方法或 CollectionReference 的document()方法时， Firestore 中使用的内置唯一 id 生成器会生成随机且高度不可预测的 id，从而防止命中后端基础设施中的某些热点。简单地使用带有一些随机 6 位数字的前缀可能会增加这种变化。因此，这种情况下的 ID 冲突很有可能发生在更大范围内。除此之外，我建议您查看 Frank van Puffelen 在这篇文章中的回答，看看这些唯一的文档 ID 是如何生成的。恕我直言，您不必以任何方式关心该算法生成的那些随机文档 ID。