【问题标题】：modeling a nosql database to achieve maximum performance对 nosql 数据库进行建模以实现最大性能
【发布时间】：2020-12-28 07:31:56
【问题描述】：

我有一个足球联赛，其中有很多球队和赛程。 NoSQL 数据库如下所示：

collection: teams, documents: team1, team2...            //about 50 per league
collection: fixtures, documents: fixture1, fixture2...   //about 300 per league

很快会有更多的联赛，我不知道如何对数据库进行建模以达到最大的性能。

选项 1：保留当前模型

我可以保留当前模型，只需在每个文档中添加一个带有联赛 ID 的字段。

选项 2：为每个联赛创建子集合

我可以为每个联赛创建一个子集合。它看起来像这样：

collection: teams, documents: league1, subcollection: teams, documents: team1, team2...

可能这些数字太小而无法进行性能优化。但我也收藏了每个联赛最多 10k 的文档。

您将如何为 NoSQL 数据库建模？

【问题讨论】：

标签： google-cloud-firestore nosql

【解决方案1】：

集合的大小对性能没有影响。 Firestore 会自动对您的索引和文档进行分片，以在它们之间分配查询成本。唯一重要的是您实际阅读的文档数量。因此，如果您从大小为 10000 的集合中请求 10 个文档，它的执行与从大小为 100000 的集合中查询 10 个文档相同。

由于集合的大小与性能无关，因此您应该以适合您的其他要求或个人偏好的任何方式对数据进行建模。

【讨论】：

"集合的大小对性能没有影响。" -> 可能想明确说明这只是关于 read 性能。写入次数是影响性能的主要因素，并且通常是选择或不选择子集合的主要原因。
@FrankvanPuffelen 假设我想更新特定联赛的所有文档。当所有文档都在一个集合中时，我需要选择要更新的文档。相反，当该特定联赛的文档已经在子集合中时，我可以遍历并更新所有文档。这是你的意思吗？
当前的问题是单个集合中文档的写入限制。如果你不打算超过这个速度，那么就没有问题。我建议通读文档以了解速率限制，然后将其映射到您的特定用例。 firebase.google.com/docs/firestore/…