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

Question

我在Firebase Firestore documentation's 'Best Practices' 中看到你应该这样做：

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

一个不写文档 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 的评论进行编辑以澄清：

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

• 在原始数据集的上下文中读取/写入文档或需要将文档发送回外部服务时，引入了 strip / prepend "entry_" 函数。
• 可能需要创建文档字段来跟踪（例如type = "entry"）在同一个集合中使用多个类别的文档 ID - 这可能不是一个缺点，具体取决于用例，例如如果执行类型比较。
• 对于源自相同外部服务、具有相同前缀唯一字符串的其他类别类型（例如 foo_、bar_）重新实现上述内容很繁琐。

Answer 1

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

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

• Limitations of using sequential IDs in Cloud Firestore

编辑：

您在其中一个 cmets 中显示的那些以常量为前缀的随机 id 可以按顺序运行。

我为什么这么说？

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