Question

我正在创建一个数据库集合，该数据库集合将包含一个子集合，该子集合将包含根级别内容的旧版本。集合结构看起来与this question中的结构非常相似：

Firestore-root
|
--- content (collection)
    |
    --- contentId (google generated) (document)
        |   // latest fields here
        ----|
            --- history (subcollection)
                |
                --- oldContentId
                    // old field/values here
                --- oldContentId2
                    // old field/values here

因此，如果我想获取旧版本的内容，可以致电：


const oldContent = await fs.collection("content").doc(contentId).collection("history").doc(oldContentId).get();

我想对history子集合中的文档ID使用类似单调的ID。我知道the advice会避免使用此类ID以避免热点。对我来说尚不清楚的是，此建议对于子集合中文档的ID是否保持不变。我的猜测是的，但是只是想弄清楚。

例如，说我将Google生成的ID用于子集合并获取：


# ggdId == google generated Id
content/ggdId-1/history/ggdId-1
content/ggdId-1/history/ggdId-2
...
content/ggdId-1/history/ggdId-N

content/ggdId-2/history/ggdId-1
content/ggdId-2/history/ggdId-2
...
content/ggdId-2/history/ggdId-N

与如果我在子集合中使用类似单调的ID相比，Google云将更好地拆分这些数据：

content/ggdId-1/history/1
content/ggdId-1/history/2
...
content/ggdId-1/history/N

content/ggdId-2/history/1
content/ggdId-2/history/2
...
content/ggdId-2/history/N

最后，建议是一个硬性规定，还是有细微差别取决于收集/子收集的使用方式？所以说我不期望对history子集合进行大量的读/写操作，这意味着人们可以使用类似单调的id。

Answer 1

我不清楚目前的建议是否与子集合中文档的ID相同。

避免单调ID的建议适用于所有集合，无论它们如何嵌套。它只是无法扩展Firestore所需的方式。确实没有解决方法。

如果您确定吞吐量不会过高而导致问题，请执行所需的操作。但是最好使用随机生成的ID，并仅根据文档的字段进行排序。

一般而言，对于必须大规模扩展的云服务，ordering is hard。

Answer 2

Cloud Firestore写入中的热点几乎始终是Firestore必须更新其索引的结果，这是其满足读取/查询性能保证所需要的。

如果您对文档使用非随机ID，则会增加Firestore更新索引时命中热点的机会。这取决于它必须更新的索引，而不取决于集合是全局集合还是子集合。

虽然使用子集合可以将对索引的写入次数减少到仅对该子集合的写入次数，但是如果您使用集合组查询（因为那些具有相同名称的所有集合都有一个索引），则可能会被抵消。 / p>

Firestore子集合中的单调ID

2 个答案: