使用 "array-contains" 查询来处理 Cloud Firestore 社交媒体结构。
使用 "array-contains" 查询来处理 Cloud Firestore 社交媒体结构。
我有一个数据结构，由一个名为“投票”的集合组成。 "投票"中有几个文档，这些文档具有随机生成的ID。在这些文档中，还有一个名为“答案”的附加集合。用户在这些投票中进行投票，投票结果都会写入到“答案”子集合中。我在“答案”节点上使用.runTransaction()方法，因为对于任何给定的投票，这个子集合都在不断被用户更新和写入。
我一直在阅读有关Firestore的社交媒体结构。然而，最近我发现Firestore有一个新功能，即“array_contains”查询选项。
虽然上述帖子讨论了社交媒体结构中的“关注”动态，但我有一个不同的想法。我设想用户将投票写入（投票）到我的主投票节点，从而创建另一个“关注”节点，并且用户还要写入此节点以更新投票计数（使用云函数）。但这种方式似乎效率很低，因为我必须不断从主节点复制，其中投票正在计数。
“array_contains”查询是否是社交媒体结构可扩展性的另一种实用选项？我的想法是：
- 如果用户A关注用户B，在我的“用户”节点中的“followers”下写入一个直接的数组子集。
- 在用户B创建任何投票之前，用户B的设备从Firestore中读取“followers”数组，以获取所有关注用户的列表，并在客户端侧填充一个数组对象。
- 然后，当用户B写入新的投票时，将该“followers”数组添加到投票中，因此用户B的每个新投票都会附带一个包含所有关注用户ID的数组。
“array_contains”查询有哪些限制？在Firebase中存储包含数千个用户/关注者的数组是否可行？
使用"array-contains"查询对于Cloud Firestore社交媒体结构是否是可行的？是的，这正是Firebase创建者添加此功能的原因。
在看到你的结构后，我认为你可以尝试一下，但回答你的问题。
“array-contains”查询有哪些限制？对于存储的数据类型没有限制。
在Firebase中存储包含成千上万个用户/粉丝的数组是否可行？这不是关于可行性的问题，而是关于其他类型的限制。问题在于文档有限制。因此，在放置数据时存在一些限制。根据官方文档关于使用和限制：
文档的最大大小：1 MiB（1,048,576字节）
正如你所看到的，你在单个文档中限制了1 MiB的总数据量。当我们谈论存储文本时，你可以存储很多数据。因此，在你的情况下，如果只存储ID，我认为不会有问题。但在我个人看来，随着数组的增长，你需要注意这个限制。
如果你在数组中存储大量数据，并且这些数组应该由许多用户进行更新，那么你需要注意另一个限制。每个文档每秒只能写入一次。因此，如果有很多用户同时尝试写入/更新数据到相同的文档中，你可能会看到一些写入失败。因此，你也需要注意这个限制。
非常感谢快速的回复。你知道Firestore是否对这些限制发表过评论-可能他们会增加限制吗？我真的不知道他们是否会在将来增加这些限制。你应该问他们。所以，大约1000个字符等于1千字节。你可以做一下计算：）
此外，一个Firestore文档有一个限制，最多有40,000个索引字段。这意味着如果你有一个包含40,0010个字段的文档（数组和映射中的每个元素都被视为索引的字段），最后10个字段将不会被索引，因此你将无法查询这些数据。参考：youtube.com/watch?v=lW7DWV2jST0
还有一个限制是文档内最多可以有20k行。这意味着可以添加大小为19999的数组，而数组名称占用1行，总共20k行。超过此限制后，无法在文档中添加其他字段。解决方案：在此类数组情况下，将数据存储在子集合中。
使用“array-contains”查询来处理云Firestore社交媒体结构的原因是为了能够有效地进行实时投票系统的实现。通过在“polls”集合中创建文档，每个文档包含唯一标识符、标题和答案数组。此外，每个文档还包含一个名为“answers”的子集合，其中每个答案都有一个标题和其自己的“shards”子集合中分布计数器的总数。
为了能够跟踪用户是否已经对一项投票进行了投票，还创建了一个名为“votes”的集合，其中每个文档都是由“userId_pollId”组成的复合键。每个文档包含投票的相关信息，如投票ID、用户ID、答案ID等。
当创建一个文档时，会触发一个云函数，该函数会获取投票ID和答案ID，然后使用一个事务在相应答案ID的“shards”子集合中递增一个随机分片计数器。
最后，在客户端上，对于每个投票的每个答案的每个分片，减少计数值以计算总数。
为了能够更轻松地跟踪用户是否关注了另一个用户，还可以通过创建一个名为“following”的中间集合来处理。其中，每个文档都是由“userAid_userBid”组成的复合键，这样可以在不破坏Firestore限制的情况下轻松跟踪用户之间的关注关系。
通过使用“array-contains”查询和中间集合的方式，可以有效地处理云Firestore社交媒体结构，并实现实时投票系统和用户关注跟踪的功能。