使用“包含数组”查询获取Cloud Firestore社交媒体结构

Question

我有一个数据结构，其中包含一个称为“投票”的集合。 “民意调查”具有随机生成的ID的多个文档。在这些文档中，还有一个名为“答案”的附加收集集。用户对这些民意调查投票，并将所有投票都写入“答案”子集合。我在“答案”节点上使用.runTransaction（）方法，其想法是该子集合（对于任何给定的民意测验）都会不断地被用户更新和写入。

我一直在阅读有关social media structure for Firestore的信息。但是，我最近遇到了Firestore的一项新功能，即“ array_contains”查询选项。

尽管上面的帖子参考讨论了社交媒体结构的“后续”提要，但我的想法有所不同。我设想用户向我的主投票节点进行写入（投票），因此创建另一个“后续”节点，并使用户写入该节点以更新投票（使用云功能）的效率似乎非常低下，因为我必须不断进行复制从计票的主节点开始。

“ array_contains”查询是否会成为社交媒体结构可伸缩性的另一个实用选择？我的想法是：

1. 如果用户A跟随用户B，则在我的“用户”节点中将直接数组子节点写入“跟随者”。
2. 在用户B创建任何轮询之前，用户B的设备会从Firestore读取“关注者”数组，以获取所有关注用户的列表，并将其填充在客户端的Array对象中
3. 然后，当用户B编写新的调查时，请将该“关注者”数组添加到该调查中，以便用户B的每个新调查都将附加一个数组，其中包含以下所有用户的ID。

“ array_contains”查询有哪些限制？在Firebase中存储包含数千个用户/关注者的数组是否可行？

Answer 1

  

“ array_contains”查询是否会成为社交媒体结构可伸缩性的另一个实用选择？

是的。这就是Firebase创建者添加此功能的原因。

看到您的结构，我认为您可以尝试一下，但是可以回答您的问题。

  

“ array_contains”查询有哪些限制？

您存储什么类型的数据没有限制。

  

在Firebase中存储包含数千个用户/关注者的数组是否可行？

与实践无关，与其他类型的限制有关。问题在于文档有限制。因此，在文档中可以放入多少数据方面存在一些限制。根据有关usage and limits的官方文档：

  

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

如您所见，单个文档中的数据总数限制为1 MiB。当我们谈论存储文本时，您可以存储很多东西。因此，在您的情况下，如果您仅存储ID，我认为这没问题。但是恕我直言，随着您的阵列越来越大，请注意此限制。

如果要在数组中存储大量数据，并且这些数组应由许多用户更新，则需要注意另一个限制。因此，每个文档每秒只能写入1次。因此，如果您遇到许多用户都试图一次将数据写入/更新到同一文档的情况，那么您可能会开始发现其中一些写入操作失败。因此，也要注意此限制。

Answer 2

我做了一个实时民意测验系统，这是我的实现：

我做了一个投票集合，其中每个文档都有一个唯一的标识符，标题和答案数组。

此外，每个文档都有一个名为 answers 的子集合，其中每个答案都有一个标题以及其自己的 shards 子集合中的分布式计数器总数。

示例：

polls/
  [pollID]
    - title: 'Some poll'
    - answers: ['yolo' ...]
    answers/
      [answerID]
        - title: 'yolo'
        - num_shards: 2
        shards/
          [1]
            - count: 2
          [2]
            - count: 16

我制作了另一个名为 votes 的集合，其中每个文档都是 userId_pollId 的组合键，因此我可以继续跟踪用户是否已经对投票进行了投票。 每个文档都包含pollId，userId，answerId ...

创建文档时，我触发一个Cloud Function，它捕获pollId和answerId，并使用事务在此answerId的分片子集合中增加一个随机分片计数器。

最后，在客户端，我减少了民意测验的每个答案的每个分片的计数值，以计算总数。

对于以下内容，您可以使用称为“ following”的中间人集合执行相同的操作，其中每个文档都是 userAid_userBid 的组合键，因此您可以轻松跟踪正在关注哪个用户另一个用户而没有违反Firestore的限制。