我有一个由名为“polls”的集合组成的数据结构。“polls”有几个随机生成id的文档。在这些文档中，还有一个名为“answers”的附加集合。用户对这些投票进行投票，投票都写入“answers”子集合。我在“answers”节点上使用.runtransaction（）方法，其思想是这个子集合（对于任何给定的轮询）不断被用户更新和写入。
我一直在读关于social media structure for Firestore的书。然而，我最近发现了firestore的一个新特性，“array_contains”查询选项。
虽然上面的帖子引用讨论了一个社交媒体结构的“following”feed，但我有一个不同的想法。我设想用户向我的主投票节点写入（投票），因此创建另一个“following”节点，并让用户向该节点写入以更新投票计数（使用云功能），这看起来效率极低，因为我必须不断地从主节点复制，在主节点上进行投票计数。
“array_contains”查询是否是社交媒体结构可伸缩性的另一个实用选项？我的想法是：
如果用户a跟随用户b，则写入“users”节点中名为“followers”的直接数组子节点。
在用户b创建任何轮询之前，用户b的设备从firestore读取“followers”数组，以获得所有用户的列表，并在客户端的array对象中填充这些用户
然后，当用户b编写新的投票时，将该“关注者”数组添加到投票中，这样来自用户b的每个新投票都将附加一个数组，该数组包含以下用户的所有id。
“array_contains”查询有哪些限制？在firebase中存储一个包含数千个用户/关注者的数组是否可行？
最佳答案
“array_contains”查询是否是社交媒体结构可伸缩性的另一个实用选项？
当然可以。这就是firebase创建者添加此功能的原因。
看到你的结构，我想你可以试试，但要回答你的问题。
“array_contains”查询有哪些限制？
您存储的数据类型没有限制。
在firebase中存储一个包含数千个用户/关注者的数组是否可行？
不是关于实际与否，而是关于其他类型的限制。问题是文件有限制。因此，当涉及到可以将多少数据放入文档时，有一些限制。根据有关usage and limits的官方文件：
文档的最大大小：1 MIB（1048576字节）
如您所见，一个文档中的数据总量限制为1 mib。当我们讨论存储文本时，您可以存储很多内容。所以在你的情况下，如果你只储存身份证，我想这不会有问题。但是imho，随着数组变大，要小心这个限制。
如果您在数组中存储大量数据，并且这些数组应该由许多用户更新，则需要注意另一个限制。所以你只能在每一份文件上每秒写一次。因此，如果您遇到这样一种情况：许多用户都试图同时将数据写入/更新到同一文档，那么您可能会看到其中一些写入操作失败。所以，也要小心这个限制。