在Google Cloud Firestore中执行JOIN查询 [英] Perform JOIN query in google cloud firestore

问题描述

{  
   "users":{  
      "userid_1":{  
         "following":{  
            "userid_2":{  
               "name":"user2"
            },
            "userid_3":{  
               "name":"user3"
            }
         }
      },
      "posts":{  
         "postid1":{  
            "createdTime":"111",
            "postedBy":"userid_2"
         },
         "postid2":{  
            "createdTime":"112",
            "postedBy":"userid_3"
         },
         "postid3":{  
            "createdTime":"113",
            "postedBy":"userid_2"
         },
         "postid4":{  
            "createdTime":"114",
            "postedBy":"userid_1"
         }
      }
   }
}

我要检索"userid_1"的以下用户的帖子，这些帖子按创建时间按限制2排序(每个api调用2个帖子).

I want to retrieve the posts of "userid_1"'s following users sorted by created time by the limit 2 (2 posts per api call).

如何在节点中进行火灾存储查询?

How to achieve in fire-store query in node?

如果以下用户少于100位并且他们有10条帖子，则可以提取以下所有用户的帖子并按创建时间对帖子进行排序.

Its ok to fetch all the following user's post and sorting the post by created time if following users are less than 100 and they have 10 posts.

如果用户有1000个关注者，而1000个用户有100个帖子，则无法按照创建的时间获取以下所有用户的帖子并进行排序.

If a user have 1000 following people and the 1000 people have 100 posts then its not ok to fetch all the following user's post and sorting by the created time.

我希望我们可以通过SQL"JOIN"查询轻松实现这一目标

I hope we can achieve this easily by SQL "JOIN" query

如何在节点的fire-store中实现此实现查询?

How to achieve this implementation query in fire-store in node?

推荐答案

Firestore没有服务器端JOIN的概念.一次读取操作中的所有文档必须来自同一集合.

Firestore does not have the concept of a server-side JOIN. All documents in a single read operation must come from the same collection.

这意味着要从多个集合中获取数据，您将需要执行多个读取操作-每个集合至少一个，但可能还要更多.在大多数NoSQL数据库中，这都是正常现象，对于您应该从客户端应用程序读取的数据量来说，速度并不像许多开发人员所想的那么慢.

That means that to get data from multiple collections, you will need to perform multiple read operations - at least one per collection, but possibly more. This is normal in most NoSQL databases, and not nearly as slow as many developers think for the amount of data you should read from a client-side app.

如果对于您的应用程序来说，您需要阅读的文档数量过多，请考虑更改数据模型以减少阅读次数.通常，这意味着您最终会将一些数据复制为更易于阅读的格式.

If the number of documents you need to read is prohibitive for your application, consider changing your data model to require fewer reads. Typically this means that you'll end up duplicating some of the data into a format that is more easy to read.

例如，在您的用例中，您似乎有一个社交网络.常见的解决方案是为每个用户存储完整的提要，以便将他们关注的人员的所有帖子作为单独的集合存储在数据库中.

For example in your use-case you seem to have a social network. A common solution there is to store the complete feed for each user, so all the posts for people they follow, as a separate collection in the database.

因此，当用户撰写帖子时，您可以将该帖子写到主要的 posts 集合中，将和也写到 feed中跟随他们的每个用户的集合.此操作称为扇出数据，虽然它使写入操作复杂并复制数据，但使读取数据的代码更简单，并且可伸缩性更高.由于在许多应用程序中读取操作比写入操作更为常见，因此许多NoSQL数据建模人员都认为这是一种有效的折衷方案.

So when a user writes a post, you write that post to the main posts collection, and also to the feed collection of each user that follows them. This operation is known as fanning out your data, and while it complicates the write operation and duplicates data, it makes the code that reads the data simpler, and much more scalable. Since in many applications read operations are far more common than write operations, many NoSQL data modelers consider this a valid trade-off.

这个主题范围之广，难以一justice而就，这就是为什么我还建议您:

This topic is incredibly broad and hard to do justice in a single answer, which is why I recommend you also:

• 阅读 NoSQL数据建模
• 观看了解Cloud Firestore

这篇关于在Google Cloud Firestore中执行JOIN查询的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！