Firebase中有多少记录/行/节点？ [英] How many records / rows / nodes is alot in firebase?

问题描述

我正在创建一个应用程序，用于将用户存储在所有要发送的邮政编码/邮编中。结构看起来像这样：

pre $ postalcodes / {{postalcode}} / {{userId}} = true

这个结构的原因是可以轻松地获取所有交付给某个邮政编码的用户。

  ex。 postalcodes / 21121 / 
  

如果所有用户都使用500个邮政编码，而且该应用拥有大约1000个用户，很多记录：

  500x1000 = 500000 
  

Firebase能够轻松处理数据存储中的许多记录，还是应该考虑采用不同的方法/解决方案？你是什​​么人？

亲切的问候，
Elias

解决方案

我很确定Firebase可以毫无问题地返回500k个节点。

更大的担心是检索需要多长时间（特别是在这个移动优先时代），以及您的应用程序将基于多个节点向您的用户显示的内容。

500k行的列表不是很有用，所以很可能会显示一部分数据。

1. 假设您只显示第一个屏幕节点。那将有多少个节点？ 20？那么为什么你已经在这种情况下检索其他节点？我只是简单地检索构建第一个屏幕所需的节点，并在需要时加载剩下的节点。


2. 或者我可以想象你显示节点的摘要（比如节点总数和每个邮政编码区域的平均值）。你需要所有的节点来确定摘要。但是，我很难把它看作是客户端应用程序的任务来确定摘要值。这是更多的服务器端任务。该服务器可以使用与客户端应用程序（即JavaScript API）相同的技术，但不会受到带宽和时间限制的困扰（$）。 b
   

   只是一些想法，我会如何处理这个，所以ymmv。

   
   

   I'm creating an app where i will store users under all postalcodes/zipcodes they want to deliver to. The structure looks like this:

   postalcodes/{{postalcode}}/{{userId}}=true
   

   The reason for the structure is to easily fetch all users who delivers to a certain postal code.

   ex. postalcodes/21121/
   

   If all user applies like 500 postalcodes and the app has about 1000 users it can become alot of records:

   500x1000 = 500000
   

   Will firebase easily handle that many records in data storage, or should i consider a different approach / solution? What are your toughts?

   Kind regards, Elias

   解决方案

   I'm quite sure Firebase can return 500k nodes without a problem.

   The bigger concerns are how long that retrieval will take (especially in this mobile-first era) and what your application will show your user based on that many nodes.

   A list with 500k rows is hardly useful, so most likely you'll show a subset of the data.

   1. Say you just show the first screenful of nodes. How many nodes will that be? 20? So why would you already retrieve the other nodes already in that case? I'd simply retrieve the nodes needed to build the first screen and load the rest on demand - when/if needed.
   2. Alternatively I could imagine you show a digest of the nodes (like a total number of nodes and maybe some averages per zip code area). You'd need all nodes to determine that digest. But I'd hardly consider it to task of a client application to determine the digest values. That's more something of a server-side task. That server could use the same technology as client-apps (i.e. the JavaScript API), but it wouldn't be bothered (as much) by bandwidth and time constraints.

   Just some ideas of how I would approach this, so ymmv.

   这篇关于Firebase中有多少记录/行/节点？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！