最佳化資料庫效能

您可以透過幾種方式改善應用程式中的Firebase Realtime Database效能。如要瞭解如何最佳化Realtime Database效能,請透過不同的Realtime Database監控工具收集資料,然後視情況變更應用程式或Realtime Database用法。

監控 Realtime Database 效能

您可以透過幾種不同的工具收集 Realtime Database 效能資料,具體取決於所需的精細程度:

  • 總覽:使用分析工具,取得未編入索引的查詢清單,以及讀取/寫入作業的即時總覽。
  • 已結算的用量估算值:您可以使用 Firebase 控制台提供的用量指標,查看已結算的用量和概要成效指標。
  • 詳細查看:使用 Cloud Monitoring,進一步瞭解資料庫在一段時間內的效能表現。

依據指標改善效能

收集資料後,請根據您想改善的成效領域,探索下列最佳做法和策略。

一覽成效改善策略
指標 說明 最佳做法
負載/使用率 在任何特定時間點,將資料庫的容量用於處理要求的比例最佳化 (反映在「Load」或「io/database_load」指標中)。 最佳化資料結構
在多個資料庫中分割資料
提升聽眾效率
透過以查詢為基礎的規則限制下載次數
最佳化連線
有效連線數 平衡資料庫同時有效連線的數量,以便維持在 200,000 個連線的限制以下。 在多個資料庫中分割資料
減少新的連線
連出頻寬 如果資料庫的下載次數似乎比預期高,您可以提高讀取作業的效率,並減少加密作業的額外負擔。 最佳化連線
最佳化資料結構
使用以查詢為基礎的規則限制下載量
重複使用 SSL 工作階段
提高事件監聽器效率
限制資料存取權
儲存空間 請確認您沒有儲存未使用的資料,或是在其他資料庫和/或 Firebase 產品中平衡儲存的資料,以便維持在配額範圍內。 清除未使用的資料
最佳化資料結構
在多個資料庫中分割資料
使用 Cloud Storage for Firebase

最佳化連線

GETPUT 等 RESTful 要求仍需要連線,即使該連線的生命週期很短也一樣。這些頻繁且短暫的連線,實際上會比資料庫的即時有效連線,產生更多連線成本、資料庫負載和傳出頻寬。

盡可能使用應用程式平台的原生 SDK,而非 REST API。SDK 會維持開放連線,降低 SSL 加密成本和資料庫負載,這些都會隨著 REST API 增加。

如果您使用 REST API,建議您使用 HTTP 保持連線功能來維持開放連線,或使用伺服器傳送事件,這樣可以降低 SSL 握手的成本。

在多個資料庫中分割資料

將資料分割至多個 Realtime Database 執行個體 (亦稱為資料庫區塊) 有三項優點:

  1. 將這些連線分散到各個資料庫執行個體,以便增加應用程式允許的同時有效連線總數。
  2. 在資料庫執行個體之間平衡負載。
  3. 如果您有獨立的使用者群組,且只需要存取個別資料集,請使用不同的資料庫執行個體,以提高處理量和降低延遲。

如果您使用的是 Blaze 定價方案,可以在同一個 Firebase 專案中建立多個資料庫例項,並在各資料庫例項中使用通用使用者驗證方法。

進一步瞭解分割資料的方式和時機。

建構高效的資料結構

由於 Realtime Database 會從路徑的子節點和路徑擷取資料,因此建議您盡可能讓資料結構保持平坦。這樣一來,您就能有選擇地擷取所需資料,而不必將不必要的資料下載至用戶端。

特別是在建構資料時,請考慮寫入和刪除作業。舉例來說,含有數千個葉節的路徑可能會耗費大量資源。將這些路徑分割成包含多個子樹狀結構的路徑,並減少每個節點的葉節點數量,即可加快刪除作業的速度。

此外,每個寫入作業可占用總資料庫使用率的 0.1%。請以可透過 SDK 中的 update() 方法或 RESTful PATCH 要求,將寫入作業以多路更新方式批次處理為單一作業的資料結構。

如要將資料結構最佳化並提升效能,請遵循資料結構最佳做法

防止未經授權的存取

使用 Realtime Database Security Rules 防止未經授權的資料庫作業。舉例來說,使用規則可避免惡意使用者反覆下載整個資料庫的情況。

進一步瞭解如何使用 Firebase 即時資料庫規則

使用以查詢為基礎的規則限制下載

Realtime Database Security Rules 可限制資料庫中資料的存取權,但也可以用於限制透過讀取作業傳回的資料。使用以查詢為基礎的規則 (由 query. 運算式 (例如 query.limitToFirst) 定義) 時,查詢只會擷取受規則限制的資料。

舉例來說,下列規則會限制讀取存取權,只允許查詢的前 1000 個結果,並依優先順序排序:

messages: {
  ".read": "query.orderByKey &&
            query.limitToFirst <= 1000"
}

// Example query:
db.ref("messages").limitToFirst(1000)
                  .orderByKey("value")

進一步瞭解 Realtime Database Security Rules

索引查詢

索引資料可減少應用程式執行每項查詢時使用的總頻寬。

重複使用 SSL 工作階段

透過發出 TLS 工作階段票證,減少在接續連線上執行 SSL 加密的額外成本。如果您需要經常安全地連線至資料庫,這項功能就特別實用。

提高聽眾效率

請盡可能將事件監聽器放在路徑的後端,以限制同步處理的資料量。請務必讓監聽器取得您要的資料。請勿監聽資料庫根目錄,否則會導致整個資料庫下載。

新增查詢以限制監聽作業傳回的資料,並使用只會下載資料更新的事件監聽器,例如 on() 而非 once()。請將 .once() 保留給確實不需要資料更新的動作。此外,盡可能使用 orderByKey() 排序查詢,以獲得最佳效能。使用 orderByChild() 排序的速度可能會慢 6 到 8 倍,而對於大型資料集,使用 orderByValue() 排序的速度可能會非常慢,因為這需要從持久層讀取整個位置。

請務必動態新增監聽器,並在不再需要時移除。

清理未使用的資料

定期移除資料庫中的任何未使用或重複資料。您可以執行備份作業,手動檢查資料,或定期將資料備份到 Google Cloud Storage 儲存桶。您也可以考慮透過 Cloud Storage for Firebase 代管儲存的資料。

提供可更新的可擴充程式碼

IoT 裝置內建的應用程式應包含可輕鬆更新的可擴充程式碼。請務必徹底測試用途,考量可能會讓使用者群急遽成長的情況,並內建部署程式碼更新的功能。請仔細考量日後可能需要進行的重大變更,例如決定將資料分割。