firestore 子集合中的单调 ID
Monotonic Ids in firestore subcollection
我正在创建一个数据库集合,该集合将包含一个包含旧版本根级内容的子集合。集合结构看起来与 :
中的结构非常相似
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
google 云拆分此数据是否会比我在子集合中使用类似单调的 ID 更好:
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
最后,建议是硬性规定,还是根据 collection/subcollection 的使用方式存在细微差别?所以说我预计 history
子集合不会有那么多 read/writes,这是否意味着可以使用类似单调的 ID。
What is not clear to me is if this advice remains the same for ids for documents in subcollections.
避免单调 ID 的建议适用于所有集合,无论它们是如何嵌套的。它只是无法按 Firestore 要求的方式进行扩展。确实没有解决方法。
如果您确定吞吐量不会高到会导致问题,那么请按照您的意愿进行操作。但最好使用随机生成的 ID,并仅根据文档的字段进行排序。
一般而言,对于必须大规模扩展的云服务,ordering is hard。
Cloud Firestore 写入中的热点几乎总是 Firestore 必须更新其索引的结果,它需要更新其索引才能满足其 read/query 性能保证。
如果您对文档使用非随机 ID,则会增加 Firestore 在更新其索引时遇到热点的可能性。这取决于它必须更新的索引,而不以任何方式决定集合是全局集合还是子集合。
虽然使用子集合可能会将对索引的写入次数减少到仅对该子集合的写入次数,但如果您使用集合组查询(因为所有同名集合都有一个索引),这可能会被抵消.
我正在创建一个数据库集合,该集合将包含一个包含旧版本根级内容的子集合。集合结构看起来与
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
google 云拆分此数据是否会比我在子集合中使用类似单调的 ID 更好:
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
最后,建议是硬性规定,还是根据 collection/subcollection 的使用方式存在细微差别?所以说我预计 history
子集合不会有那么多 read/writes,这是否意味着可以使用类似单调的 ID。
What is not clear to me is if this advice remains the same for ids for documents in subcollections.
避免单调 ID 的建议适用于所有集合,无论它们是如何嵌套的。它只是无法按 Firestore 要求的方式进行扩展。确实没有解决方法。
如果您确定吞吐量不会高到会导致问题,那么请按照您的意愿进行操作。但最好使用随机生成的 ID,并仅根据文档的字段进行排序。
一般而言,对于必须大规模扩展的云服务,ordering is hard。
Cloud Firestore 写入中的热点几乎总是 Firestore 必须更新其索引的结果,它需要更新其索引才能满足其 read/query 性能保证。
如果您对文档使用非随机 ID,则会增加 Firestore 在更新其索引时遇到热点的可能性。这取决于它必须更新的索引,而不以任何方式决定集合是全局集合还是子集合。
虽然使用子集合可能会将对索引的写入次数减少到仅对该子集合的写入次数,但如果您使用集合组查询(因为所有同名集合都有一个索引),这可能会被抵消.