您可以透過幾種方式改善應用程式中的 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 |
最佳化連線
符合 REST 樣式的要求 (例如 GET 和 PUT) 仍需要連線，即使連線時效短暫也一樣。這些頻繁且短暫的連線，實際上會比連線至資料庫的即時有效連線，大幅增加連線成本、資料庫負載和傳出頻寬。
盡可能使用應用程式平台的原生 SDK，而非 REST API。SDK 會維持開放連線，降低 SSL 加密成本和資料庫負載，這些負載可能會與 REST API 加總。
如果您使用 REST API，建議您使用 HTTP 保持連線功能來維持開放連線，或使用伺服器傳送事件，這樣可以降低 SSL 握手的成本。
在多個資料庫中分割資料
將資料分割至多個 Realtime Database 執行個體 (又稱為資料庫區塊)，可帶來三項好處：
- 將這些連線分散到多個資料庫例項，即可增加應用程式允許的同時有效連線總數。
- 平衡資料庫執行個體的負載。
- 如果您有獨立的使用者群組，只需要存取個別資料集，請使用不同的資料庫執行個體，以提高吞吐量並降低延遲。
如果您使用的是 Blaze 定價方案，可以在同一個 Firebase 專案中建立多個資料庫例項，並在各資料庫例項中使用通用使用者驗證方法。
進一步瞭解分割資料的做法和時機。
建構高效的資料結構
由於 Realtime Database 會從路徑的子節點和路徑擷取資料，因此建議您盡可能讓資料結構保持平坦。這樣一來，您就能有選擇性地擷取所需資料，而不會將不必要的資料下載至用戶端。
建構資料時，請特別考慮寫入和刪除。舉例來說，含有數千個葉節的路徑可能會耗費大量資源。將這些變數分割為包含多個子樹狀結構的路徑，且每個節點的葉子數量較少，可能會加快刪除速度。
此外，每個寫入作業都會占用總資料庫使用率的 0.1%。建立資料結構時，您可以透過 SDK 中的 update() 方法或符合 REST 樣式的 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 裝置內建的應用程式應包含可輕鬆更新的可擴充程式碼。請務必完整測試用途，將可能大幅增加使用者數量的情境納入考量，並建構能將更新部署至程式碼的功能。請仔細考量日後可能需要進行的重大變更，例如決定將資料分割。