您可以透過幾種方式改善應用程式中的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 |
最佳化連線
GET
和 PUT
等 RESTful 要求仍需要連線,即使該連線的生命週期很短也一樣。這些頻繁且短暫的連線,實際上會比資料庫的即時有效連線,產生更多連線成本、資料庫負載和傳出頻寬。
盡可能使用應用程式平台的原生 SDK,而非 REST API。SDK 會維持開放連線,降低 SSL 加密成本和資料庫負載,這些都會隨著 REST API 增加。
如果您使用 REST API,建議您使用 HTTP 保持連線功能來維持開放連線,或使用伺服器傳送事件,這樣可以降低 SSL 握手的成本。
在多個資料庫中分割資料
將資料分割至多個 Realtime Database 執行個體 (亦稱為資料庫區塊) 有三項優點:
- 將這些連線分散到各個資料庫執行個體,以便增加應用程式允許的同時有效連線總數。
- 在資料庫執行個體之間平衡負載。
- 如果您有獨立的使用者群組,且只需要存取個別資料集,請使用不同的資料庫執行個體,以提高處理量和降低延遲。
如果您使用的是 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 裝置內建的應用程式應包含可輕鬆更新的可擴充程式碼。請務必徹底測試用途,考量可能會讓使用者群急遽成長的情況,並內建部署程式碼更新的功能。請仔細考量日後可能需要進行的重大變更,例如決定將資料分割。