[問題] Firebase realtime 效能問題

看板AndroidDev作者 (meteor007是:)時間6年前 (2018/09/23 00:13), 6年前編輯推噓7(705)
留言12則, 3人參與, 6年前最新討論串1/1
這幾天在做測試,發現效能問題,想上來問一下有沒有人也遇到 因為結構很簡單卻還是慢,讓我不得其解 我有一個叫做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://www.ptt.cc/bbs/AndroidDev/M.1537632819.A.E12.html

09/23 06:19, 6年前 , 1F
以sql的概念來看,你建立一萬筆都是同樣資料的欄位為in
09/23 06:19, 1F

09/23 06:19, 6年前 , 2F
dex,有建跟沒建一樣,並不會比較快速。
09/23 06:19, 2F

09/23 06:20, 6年前 , 3F
而且你又在同樣欄位上做order,你直接全抓咖實在
09/23 06:20, 3F
我又嘗試建立"10組"在台中的User,然後一樣的Query,把台北改成台中 其實一樣是慢的,感覺起來是跟"整體數量有關", 雖然你提的有道理,但是總覺得可能還有其他因素

09/23 07:56, 6年前 , 4F
一萬筆有點多 分page拿吧
09/23 07:56, 4F
測試過如果一次拿20筆,確實是快的,不到一秒 分page也是解法之一, 只是無法理解只是一萬筆就會慢這件事情 那篇文章的case,有兩萬多筆都花不到一秒 ※ 編輯: meteor007 (115.82.112.198), 09/23/2018 14:35:45

09/23 19:47, 6年前 , 5F
請問什麼情況下會用order?
09/23 19:47, 5F
??? 不就是希望達到像SQL 裡的where的效果嗎? 你是想說我的語法有問題? ※ 編輯: meteor007 (115.82.112.198), 09/23/2018 20:50:20

09/23 21:54, 6年前 , 6F
因為我從未使用到Query類別,只是好奇瞭解一下
09/23 21:54, 6F

09/23 21:57, 6年前 , 7F
剛看了一下,文件是有寫使用orderbychild速度會很緩慢
09/23 21:57, 7F

09/23 21:58, 6年前 , 8F
09/23 21:58, 8F

09/23 22:10, 6年前 , 9F
你可以考慮使用DatabaseReference將整個node取下後再篩
09/23 22:10, 9F
感謝熱心,其實我之前有看過這文件了, 剛剛重看一遍還是沒看到有提到效率的部分 另外,因為實際上的資料量會很多,不太可能全部載下來 未來解法會重新Denormalize整個結構以加速效能。 那篇Medium的評測,暫時就當作都市傳說吧... ※ 編輯: meteor007 (115.82.112.198), 09/24/2018 00:26:06

09/24 10:12, 6年前 , 10F
是我傳錯篇了~這篇才對 https://goo.gl/aX67sW
09/24 10:12, 10F

09/24 10:14, 6年前 , 11F
另外你的資料結構應該要扁平化 https://goo.gl/tqcbyg
09/24 10:14, 11F

09/24 10:16, 6年前 , 12F
如此就能避免你提到下載過多資料的問題
09/24 10:16, 12F
感謝。 ※ 編輯: meteor007 (49.217.245.152), 09/24/2018 15:06:52
文章代碼(AID): #1RfcepuI (AndroidDev)
文章代碼(AID): #1RfcepuI (AndroidDev)