在 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"
         }
      }
   }
}

我想检索按创建时间按限制 2 排序的userid_1"以下用户的帖子(每个 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).

如何在node中实现fire-store查询?

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.

我希望我们可以通过 SQLJOIN"查询轻松实现这一点

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集合，和也写入提要 关注他们的每个用户的集合.此操作称为扇出数据，虽然它使写入操作复杂化并复制数据，但它使读取数据的代码更简单，更具可扩展性.由于在许多应用程序中，读操作比写操作更常见，因此许多 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.

这个话题非常广泛，很难在一个单一的答案中做到公正，这就是为什么我也推荐你:

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屋！