使用带有重复字符的修改后的 UUID 作为 Firestore 文档 ID 会产生 performance/hotspotting 风险吗？

Question

我正在使用 Google Cloud Firestore。对于特定的文档 ID，我使用的是修改后的 UUID。在这个修改后的 UUID 中，最后 4 个字符始终是 0000-2000 之间的整数的字符串。

示例 IDS 为：

• 633F7A4A-7A63-400F-932C-97ADF-DC70000
• FDA1D934-91E2-418D-8BD6-BAD39-3120001
• D33B861F-E497-40CD-96A0-5D391-7E90002
• 5AE69E78-2039-4223-AC89-CD5EB-0E60003
• 等等

我很清楚这并不理想，而且我知道最后一个字符会在数据库的整个生命周期中重复多次（例如，数百万条以 0000、0001、0002 结尾的记录）

随着数据库的扩展，这是否会产生任何我应该注意的重大问题（例如热点）？或者剩余的 28 个字符是否足够独特以至于我的查找不会受到影响，尽管在最后 4 个中有已知的重复？

我最关心的是大规模性能，而不太关心全局唯一性的近乎完美保存（我知道从 32 到 28 个随机字符会增加重复的风险）。

Answer 1

Firestore 中的任何类型的限制只会因特定 activity 而触发，包括添加到索引的数据、数据的性质以及添加数据的速率.问题中没有足够的信息来确定是否会出现问题。

如果您查看 documentation，您会看到规定的限制：

Maximum write rate to a collection in which documents contain sequential values in an indexed field

并且限制500/秒。

因此，首先，如果您不以每秒 500 条的速度添加新文档数据，则不会有超过任何已知限制的风险。

其次，据说对添加数据的限制是顺序。如果您的文档 ID 的尾随字符未按大致顺序添加（也就是说，例如 0001、0002、0003 等），则您不会有超出任何已知限制的风险。

reading/querying Firestore 中的现有数据没有记录在案的限制。您会注意到所有限制都针对写操作。我确实建议研究整页文档并将已知限制与应用程序的预期行为进行比较。