Firestore 和自动增量 ID

Posted 2023-03-10

【中文标题】Firestore 和自动增量 ID

【英文标题】：Firestore and Auto Increment Ids

【发布时间】：2019-03-09 20:26:10

【问题描述】：

我目前正在为一个小型应用程序使用 firestore。我正在尝试查看可以用于自动增量 ID 的内容。一个常见的简单用例是订单号。我不想使用文档 ID 的人类消耗品标识符。这不是人类的消耗品。

【问题讨论】：

不要使用自定义 ID，这可能会影响未来的可扩展性。而不是增量文档ID，您可以在文档中使用增量字段。更多信息可以在这里查看link.medium.com/JBLoRkvgz3

附带说明，由于 hotspotting 导致自动递增 ID 存在问题 - 对数据库特定部分的请求过多。 Firestore 中任何类型的递增 ID 都可能发生这种情况（例如，“doc1”、“doc2”等）。这些被称为“单调递增的文档 ID”。热点会导致延迟，在最坏的情况下会导致超时或冲突。简而言之，您应该只使用随机 ID，这是您抵御热点的第一道防线。最佳做法是允许 Firestore 使用 push 或其“创建 ID”方法创建 ID。

【参考方案1】：

Firestore 中没有内置的自动增量运算符。如果你想要这样的东西，你将不得不自己构建它。

这通常涉及跟踪您在已知位置的文档中使用的最新 ID，然后在事务中从客户端读取和更新该文档。

但请认真考虑您是否不能使用 Firestore 的内置标识符，因为 Firestore 带有内置标识符而不是自动增量运算符的原因有很多。

我强烈建议您查看以下一些相关问题：

Incrementing Number as Firestore Document Name? Firestore generated key versus custom key in a collection? How to create auto incremented key in Firebase?（关于Firebase的其他数据库，但原因大体相同）

而这个页面在Firestore documentation in distributed counters。

【讨论】：

谢谢。我看到大多数推荐推送 ID 的解决方案。但是，如果我将推送 ID 作为确认不向用户提供。问题是可用性。如果他们调用操作，他们两个都很难重复推送 ID。例如 pushid JhQ7APk0UtyRTFO9-TS 似乎很难让用户在电话上重复操作。

考虑使用只对用户唯一的代码，这会大大降低复杂性。然后考虑对 ID 使用更简单的方案，例如基于日期/时间，因为单个用户不太可能同时从多个设备下达多个订单。如果这些不起作用，您可以采用我在答案顶部描述的事务方法。我自己会认为这是最后的手段。

不幸的是，Firestore 中缺少“唯一字段”约束使得随机 ID 变得不切实际：ID 是文档中唯一保证唯一的字段。