作者meteor007 (meteor007是：)
看板AndroidDev
标题[问题] Firebase realtime 效能问题
时间Sun Sep 23 00:13:35 2018
这几天在做测试，发现效能问题，想上来问一下有没有人也遇到
因为结构很简单却还是慢，让我不得其解
我有一个叫做User的Node，记录所有User
User里面只有8个属性，全都是字串，
也完全没有nested，非常简单的Modeling
现在假设我产生一万个随机User，其中有一个属性是"所在城市"
然後强制指定这一万人都在台北
Query也很简单，就是orderbychild("city).equalto("台北")
回传结果是对的，但是竟然要花上30秒?! 区区一万笔资料而已
加上indexon也没差多少，整个莫名其妙
我整个结构单纯的程度就像这篇文章一样
https://medium.com/@jasonbyrne/benchmarking-firebase-indexon-565182c723de
但是所花的时间却和他测试的结果天差地远..
不知道大家测试的效率都是多少? 有人有遇过类似问题吗?
(是在实机里测试，满新款的手机)
感谢。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 115.82.112.198
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/AndroidDev/M.1537632819.A.E12.html
1F：推 tentenlee: 以sql的概念来看，你建立一万笔都是同样资料的栏位为in 09/23 06:19
2F：→ tentenlee: dex，有建跟没建一样，并不会比较快速。 09/23 06:19
3F：→ tentenlee: 而且你又在同样栏位上做order,你直接全抓咖实在 09/23 06:20
我又尝试建立"10组"在台中的User，然後一样的Query，把台北改成台中
其实一样是慢的，感觉起来是跟"整体数量有关"，
虽然你提的有道理，但是总觉得可能还有其他因素
4F：推 hijamoya: 一万笔有点多 分page拿吧 09/23 07:56
测试过如果一次拿20笔，确实是快的，不到一秒 分page也是解法之一，
只是无法理解只是一万笔就会慢这件事情
那篇文章的case，有两万多笔都花不到一秒
※ 编辑: meteor007 (115.82.112.198), 09/23/2018 14:35:45
5F：推 taco2548: 请问什麽情况下会用order? 09/23 19:47
???
不就是希望达到像SQL 里的where的效果吗?
你是想说我的语法有问题?
※ 编辑: meteor007 (115.82.112.198), 09/23/2018 20:50:20
6F：推 taco2548: 因为我从未使用到Query类别,只是好奇了解一下 09/23 21:54
7F：推 taco2548: 刚看了一下,文件是有写使用orderbychild速度会很缓慢 09/23 21:57
9F：推 taco2548: 你可以考虑使用DatabaseReference将整个node取下後再筛 09/23 22:10
感谢热心，其实我之前有看过这文件了，
刚刚重看一遍还是没看到有提到效率的部分
另外，因为实际上的资料量会很多，不太可能全部载下来
未来解法会重新Denormalize整个结构以加速效能。
那篇Medium的评测，暂时就当作都市传说吧...
※ 编辑: meteor007 (115.82.112.198), 09/24/2018 00:26:06
12F：→ taco2548: 如此就能避免你提到下载过多资料的问题 09/24 10:16
感谢。
※ 编辑: meteor007 (49.217.245.152), 09/24/2018 15:06:52