我有一个由称为“民意调查”的集合组成的数据结构。 “民意调查”有几个具有随机生成 ID 的文档。在这些文档中，还有一个名为“答案”的附加集合集。用户对这些民意调查进行投票，所有投票都写入“答案”子集合中。我在“answers”节点上使用 .runTransaction() 方法，其想法是该子集合（对于任何给定的民意调查）不断由用户更新和写入。
我一直在读关于Firestore 的社交媒体结构 https://stackoverflow.com/questions/46979375/firestore-how-to-structure-a-feed-and-follow-system。不过，我最近遇到了 Firestore 的一项新功能，即“array_contains”查询选项。
虽然上面的帖子参考讨论了社交媒体结构的“以下”提要，但我有不同的想法。我设想用户写入（投票）到我的主民意调查节点，因此创建另一个“以下”节点并让用户写入此节点以更新民意调查投票计数（使用云函数）似乎效率非常低，因为我必须不断复制来自正在计票的主节点。
“array_contains”查询是否是社交媒体结构可扩展性的另一个实用选择？我的想法是：
- 如果用户 A 关注用户 B，请写入我的“用户”节点中名为“关注者”的直接数组子级。
- 在用户 B 创建任何轮询之前，用户 B 的设备会从 Firestore 读取“followers”数组，以获取关注的所有用户的列表，并将其填充到客户端的 Array 对象中
- 然后，当用户 B 编写新的民意调查时，将“followers”数组添加到民意调查中，这样用户 B 的每个新民意调查都会附加一个数组，其中包含关注的用户的所有 ID。
“array_contains”查询有哪些限制？在 Firebase 中存储包含数千个用户/关注者的数组是否实用？
“array_contains”查询是否是社交媒体结构可扩展性的另一个实用选择？
是的当然。这就是 Firebase 创建者添加此功能的原因。
看到你的结构，我认为你可以尝试一下，但要回答你的问题。
“array_contains”查询有哪些限制？
对于存储的数据类型没有限制。
在 Firebase 中存储包含数千个用户/关注者的数组是否实用？
与实用与否无关，与其他类型的限制有关。问题是文件有限制。因此，当您可以在文档中放入多少数据时，存在一些限制。根据官方文档有关用途和限制 https://firebase.google.com/docs/firestore/quotas:
文档的最大大小：1 MiB（1,048,576 字节）
如您所见，单个文档中的数据总量限制为 1 MiB。当我们谈论存储文本时，您可以存储很多内容。因此，就您而言，如果您只存储 ids，我认为这不会有问题。但恕我直言，随着您的阵列变得越来越大，请小心这个限制。
如果您在数组中存储大量数据并且这些数组应该由大量用户更新，那么您需要注意另一个限制。因此，每个文档每秒只能写入 1 次。因此，如果您遇到许多用户都尝试同时向同一文档写入/更新数据的情况，您可能会开始看到其中一些写入失败。因此，也要小心这个限制。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
