哪個是使用 firebase 實時數據庫更好的性能查詢

Question

我有一個用戶列表，可能會增加到數千條記錄。

我有 2 個檢索特定用戶數據的實例。

第一個是通過 userId(key) 檢索它，如下圖所示：

代碼是：

 firebaseDatabase.getReference("users")
         .child(userId)
         .get()
         ...

第二個是將 userId 保存為字段值，以便我可以在規則中對其進行索引，以便在用戶過多的情況下獲得更好的性能。 見下圖

代碼是：

firebaseDatabase.getReference("users")
        .orderByChild("userId")
        .equalTo(theSpecificUserId)
        .get()
        ...

我還沒有使用第二個版本，但是我創建了一個 function 增加了大約 100k 用戶並且我收到了錯誤 - Firebase -Out of Z4789F23283B3A61F858B641A1A 異常導致應用程序崩潰。

哪個性能更好？當您的應用程序投入生產時，您如何處理數據庫的擴展？

Answer 1

如果您可以創建指向特定用戶節點的引用，請執行此操作。 不要執行查詢！ 看到您的示例，創建指向用戶節點的數據庫引用對象非常簡單，因為節點的鍵是 UID。

僅當您需要過濾和/或排序數據庫中的元素時，查詢才有用。 所有操作都被視為限制。 如您所說，如果一個節點有“數千條記錄”，則不會產生問題。 但是嘗試訪問包含數百萬的節點可能會創建。 但是，訪問單個用戶永遠不會產生任何問題。

僅為子節點的子集查詢“用戶”節點始終需要實時數據庫考慮這數千個用戶中的每一個。 如果您從 1000 個用戶中請求一個用戶，您基本上是在要求 Firebase 考慮 999 個您絕對沒有興趣閱讀的用戶。 如果您只指向一個用戶，則不會以任何方式考慮其他 999 個用戶。

如果您是 NoSQL 數據庫的新手，請注意最好以適合您的應用用例的方式對數據進行建模。 話雖如此，例如，如果您需要顯示加入您應用的最新 10 位用戶，則將這 10 位最新用戶的 UID 存儲在單獨的節點中。 為什么？ 因為我們總是根據我們想要執行的查詢來構建數據庫。

Answer 2

將您用於查詢的userId字段添加到實時數據庫規則。

例如

{
  "rules": {
    ".read": "auth.uid != null",
    ".write": "auth.uid != null",
    "v1": {
            "users": {
                ".indexOn": "userId"
            }   
        }
    }
}