【发布时间】:2018-07-26 13:43:05
【问题描述】:
假设我们想从 questions 节点中检索 15 个随机子节点,该节点的数据库结构如下:
1. 从 Firebase 检索随机子节点的第一种(直观且经过讨论的)方法是检索整个所需的父节点(questions 作为数据快照),然后在客户端上选择一些随机子节点-边。这种方法已经在很多帖子中被指出,比如this one here 。
显然,这种方法有其缺点;例如,当通过大型父节点(例如超过 10,000 个子节点)查询时,每次检索这样的数量会导致巨大的带宽使用以及客户端负担。(当我们实际上只需要少量孩子时)
2. 继续:另一种方法,如 here 所述,它使用迭代器以某种方式绕过了整个客户端的负担,但仍然可能发生巨大的带宽使用因为我们每次都下载整个父节点。
3. Tom 在this firebase discussion 的回答中描述了一种有趣的方法,它建议:
执行此操作的一个 hacky 方法是生成一个随机密钥并使用 startAt().limit(1) 进行查询。我觉得这可能会损害您的火力基地的性能,所以这不应该是您经常执行的操作。我们没有真正的随机样本函数。
这个解决方案实际上听起来不错,但我不确定它会如何影响我的 Firebase。
4. 另一个愚蠢的解决方案实际上可能是手动命名问题 id,可以说是从 0 到 N,因此在客户端处理随机的 id 组并检索问题-通过知道节点的实际名称来开启。
5.最后,我提出了以下解决方案,我询问是否比上面介绍的解决方案或多或少可行: 创建另一个仅包含问题 ID 的父级,并且在需要时,应该检索这个父级,它是比 questions parent 更“轻”。从那里,我将拥有特定的随机 ID,我只需要为这些孩子狙击。为了更好地理解我的意思,请查看下图:
现在,这种方法产生了以下问题:分配(比如说)15 eventListeners 是好的做法吗?这真的可以减慢速度吗? (注意:这也适用于方法 3 和 4)
最终,当从大型数据库中查询一些随机孩子时,哪种方法实际上是最佳方法?
【问题讨论】:
-
分配 15 个事件监听器是什么意思?你想用 15 个事件监听器做什么?
-
@svi.data 我可能还没有说清楚,我想从父母那里检索一些(比如说 15 个)随机孩子。正如我所说,知道特定孩子的确切 ID(在最后一个方法中描述)意味着分配 15 个听众。例如
databaseRef.child("questions").child("id_0001").addSingleValueEventListener(..)我获得的每个随机 id。 -
所以你试图获取每个随机 id 下的详细信息(所以你需要使用 15 个事件监听器)?
-
@svi.data 是的。我确实需要获取每个随机 ID 下的详细信息。
-
那么当然你只使用一个指向你的 (question_ids) 参考的监听器。哪个更好。
标签: android firebase random firebase-realtime-database querying