可以将用户 ID 存储为 Firestore 文档中字段的键吗？答案

【问题标题】：Is it ok to store a user id as the key of a field in a Firestore document?可以将用户 ID 存储为 Firestore 文档中字段的键吗？
【发布时间】：2019-01-18 21:13:43
【问题描述】：

Firestore 对使用的索引数量收费。如果我有一个结构，其中有大量不同用户给出的评分列表，并且将键作为用户 ID，将值作为评分，这会占用太多自动创建的索引吗？有没有一个好的结构。

例如，在“ratings”集合中，我使用我制作的复杂分片机制将每个用户给出的单个评分分片到不同的文档中，该机制将文档填充到最大文档大小约为 20k，然后开始填充另一个文档。假设我有 5 个文档，每个文档都包含 20k 个字段。其中一个文档如下所示：

uid1: 3.3
uid2: 5
uid3: 1.234
...

我应该使用另一种结构来存储 Firestore 中单个“字段”的负载吗？我也不想为每个评级使用大量文档，因为这太贵了。数组也不够大，无法存储大量评分。

【问题讨论】：

您能否编辑问题以更清楚地了解您的收藏的文档结构是什么？
当然！我更新了问题
我从未听说过有人试图通过逐个填写文档来分片集合。我不确定这是推荐的模式，我也不清楚实际节省的金钱是多少。 Firestore 甚至可能不是您要解决的任何问题的最佳解决方案。
我的意思是希望能够在自己的应用程序中拥有一个简单的评级系统似乎是一件很常见的事情。 facebook 如何在帖子中存储所有喜欢的内容 - 可能有数百万。由于firestores查询能力较弱，我已经使用mongodb，我真的很想坚持使用firebase产品。
@DougStevenson，在我的用例中，我想回答他的第一个查询“......这会占用太多自动创建的索引吗？”......你能回答一下吗？我打算制作一个小文档（不需要分片），但数量很多，并且以类似的方式构建 UID 是关键 ... { uid1 : data1, uid2, data2, ... } 我很担心索引成本！！

标签： firebase google-cloud-firestore

【解决方案1】：

数组也不足以存储大量评分

问题不在于数组，问题在于文档有限制。因此，在您可以将多少数据放入文档时存在一些限制。根据usage and limits的官方文档：

文档的最大大小：1 MiB（1,048,576 字节）

如您所见，单个文档中的数据总量限制为 1 MiB。当我们谈论存储文本时，您可以存储几乎所有内容，但随着您的数组变得越来越大，请注意这个限制。

根据有关modelling data in Cloud Firestore的官方文档：

Cloud Firestore 针对存储大量小文档进行了优化。

因此，尝试通过逐个填写文档来对集合进行分片并不是一个好主意。

如果您尝试在单个文档中添加来自多个用户的 raiting，换句话说，您尝试在单个文档中存储大量用户可以更新的大量数据，那么您需要另一个限制照顾。因此，每个文档每秒只能写入 1 次。因此，如果您遇到很多用户都试图一次将数据写入相同文档的情况，您可能会开始看到其中一些写入失败。所以，也要小心这个限制。

我的建议是将这些 raitings 存储在一个数组中，如果您认为文档的大小将在 1MiB 限制内，否则为每个对象单独使用标签集合。

【讨论】：

嗯。我想确实没有合适的解决方案。为了解决这个问题，我将把每个评分作为它自己的单独文档，然后使用云函数将每个文档映射到每个用户的评分数组，在 mongo db 中。这样，我可以读取用户的每一个评分并仅在服务器上计算平均值，然后只返回平均值。 Alse mongo 每个文档有 16mb 的限制，更理想。一开始就应该使用 mongodb ...:/ 被炒作骗了
MongoDb 有其自身的优势，但我认为 MongoDb 中没有什么是 Cloud Firestore 无法实现的，但您可以尝试一下。
当然。我忍不住纠正你。我已经深入研究了 firestore 和 mongo db 的来龙去脉，可以 100% 确定 mongodb 提供的功能集比 firestore 更令人印象深刻。 mongodb 可以比作 SQL，而 firestore 可以比作......嗯......我不知道还有什么功能受限......实时数据库？使用 firestore 的唯一优势是速度、易用性和文档，以及与其他令人惊叹的产品（如云功能、存储等）的集成。
@AlexMamo，在我的用例中，我想回答他的第一个查询“......这会占用太多自动创建的索引吗？”......你也能回答一下吗？我打算制作一个小文档（不需要分片），其结构类似于 UID 作为关键 ... { uid1 : data1, uid2, data2, ... } 我担心索引的成本因为此类文件的数量巨大。
@kernelman 请使用自己的MCVE 发布另一个新问题，以便我和其他 Firebase 开发人员可以帮助您。