有幾種方法可以改善應用程式中的 Firebase 即時資料庫效能。如要瞭解要如何最佳化即時資料庫效能，請透過不同的即時資料庫監控工具收集資料，然後據此變更應用程式或即時資料庫的使用情形。
監控即時資料庫效能
視您需要的精細程度而定，您可以透過幾種不同工具收集即時資料庫的效能資料：
- 高階總覽：使用分析器工具取得未建立索引的查詢清單，以及讀取/寫入作業的即時總覽。
- 預估用量：使用 Firebase 控制台提供的用量指標查看計費用量和高階成效指標。
- 詳細細查：使用 Cloud Monitoring 即可更精細地查看資料庫長期執行的效能。
依指標改善成效
收集資料後，請根據您要改善的效能領域，探索下列最佳做法和策略。
| 一覽成效提升策略 | ||
|---|---|---|
| 指標 | 說明 | 最佳做法 |
| 負載/使用率 | 在任何指定時間點，將資料庫的容量用量最佳化 (以「載入」或 **io/database_load** 指標表示)。 |
最佳化資料結構 跨資料庫資料分割資料 提高事件監聽器效率 利用以查詢為基礎的規則限制下載作業 最佳化連線 |
| 有效連線數量 | 平衡資料庫同時有效連線的數量，不要超過 200,000 個連線限制。 |
跨資料庫分割資料 減少新連結 |
| 連出頻寬 | 如果從資料庫的下載量看起來比預期高，您可以改善讀取作業的效率並減少加密負擔。 |
最佳化連線 最佳化資料結構 利用以查詢為基礎的規則限制下載作業 重複使用 SSL 工作階段 改善事件監聽器效率 限制資料存取權 |
| 儲存空間 | 請確認您並未儲存未使用的資料，或平衡其他資料庫和/或 Firebase 產品間的儲存資料，以免用量超出配額。 |
清除未使用的資料 最佳化資料結構 在不同資料庫中分割資料 使用 Cloud Storage for Firebase |
最佳化連線
即使連線時間短，GET 和 PUT 等符合 REST 樣式的要求仍須連線。相較於即時、有效連線，這些常態性的短連線實際上可能會大幅增加的連線費用、資料庫負載和連出頻寬。
請盡可能為應用程式平台使用原生 SDK，而非 REST API。SDK 會維持開放連線，降低 SSL 加密成本和資料庫負載，減少 REST API 可能會增加多少負載。
如果您使用 REST API，請考慮使用 HTTP 保持運作來維持開放連線，或使用伺服器傳送事件，以降低 SSL 握手的費用。
將資料分散至多個資料庫
將資料分割至多個即時資料庫執行個體 (又稱為資料庫資料分割) 可提供以下三種好處：
- 將執行個體拆分至各個資料庫執行個體，藉此增加應用程式允許的同時連線總數。
- 平衡所有資料庫執行個體的負載。
- 如果您有獨立的使用者群組，且只需要存取獨立的資料集，請使用不同的資料庫執行個體，以獲得更高的總處理量及更短的延遲時間。
如果您採用 Blaze 定價方案，可以在同一項 Firebase 專案中建立多個資料庫執行個體，利用跨資料庫執行個體相同的使用者驗證方法。
進一步瞭解資料分割的方式和時機。
建立高效率的資料結構
由於即時資料庫會從路徑的子節點和路徑擷取資料，因此請盡可能保持資料結構簡單。這樣一來，您就能選擇性地擷取資料，而不必下載不需要的資料。
特別是在建構資料時，請考慮寫入及刪除資料。舉例來說，如果路徑含有數千葉，刪除路徑可能相當昂貴。將其分割成含有多個子樹狀結構的路徑，且每個節點的樹葉越少，即可加快刪除速度。
此外，每次寫入最多可佔資料庫總使用率的 0.1%。建構資料結構時，您可以透過 SDK 中的 update() 方法或符合 REST 樣式的 PATCH 要求，以多路徑更新的形式將單一作業進行批次寫入。
如要最佳化資料結構並改善效能，請遵循資料結構的最佳做法。
防範未經授權的存取行為
運用即時資料庫安全性規則，防範資料庫中未經授權的作業。舉例來說，使用規則可避免發生惡意使用者重複下載整個資料庫的情況。
進一步瞭解如何使用 Firebase 即時資料庫規則。
使用以查詢為基礎的規則限制下載次數
即時資料庫安全性規則會限制對資料庫中的資料存取，但也可做為透過讀取作業傳回的資料限制。當您使用由 query. 運算式 (例如 query.limitToFirst) 所定義的以查詢為基礎的規則時，查詢只會擷取該規則所限定的資料。
舉例來說，以下規則會將讀取權限限制為查詢結果的前 1000 個，並依優先順序排序：
messages: {
".read": "query.orderByKey &&
query.limitToFirst <= 1000"
}
// Example query:
db.ref("messages").limitToFirst(1000)
.orderByKey("value")
進一步瞭解即時資料庫安全性規則。
索引查詢
為資料建立索引可以減少應用程式執行的每項查詢總頻寬。
重複使用 SSL 工作階段
發出傳輸層安全標準 (TLS) 工作階段票證，以減少恢復連線時的 SSL 加密負擔。如果您確實需要頻繁且安全的資料庫連線，這個方法就能派上用場。
改善聽眾效率
將事件監聽器放置在路徑最下方，以限制同步的資料量。事件監聽器應靠近您希望取得的資料。請勿監聽資料庫根目錄，因為這麼做會導致下載整個資料庫。
新增查詢，限制監聽作業傳回的資料，並使用僅下載資料更新的事件監聽器，例如 on()，而非 once()。將 .once() 保留給真正不需要更新資料的動作。此外，請盡可能使用 orderByKey() 排序查詢，以獲得最佳效能。使用 orderByChild() 進行排序時，速度可能會變慢 6 到 8 倍，而大型資料集使用 orderByValue() 排序時，速度非常慢，因為系統需要從持久層讀取整個位置。
請務必以動態方式加入事件監聽器，並在不再需要時移除。
清除未使用的資料
定期移除資料庫中未使用或重複的資料。您可以執行備份來手動檢查資料，或是定期將資料備份至 Google Cloud Storage 值區。此外，也建議您使用 Cloud Storage for Firebase 來託管儲存的資料。
推送可更新的可擴充程式碼
IoT 裝置內建的應用程式應包含可擴充的程式碼，而且這些程式碼可以輕鬆更新。請務必徹底測試各種用途，考量會大幅增加使用者數量的情境，並在程式碼部署更新時進行建構。舉例來說，如果您決定對資料進行資料分割，請謹慎思考可能需要進行哪些重大變更。