您可以透過幾種不同方式提升應用程式的Firebase Realtime Database 效能。如要瞭解如何改善Realtime Database效能,請使用各種監控工具收集資料,然後視情況變更應用程式或Realtime Database使用這些資料。Realtime Database
監控Realtime Database成效
您可以透過幾種不同的工具收集有關Realtime Database成效的資料,視您需要的精細程度而定:
- 高層級總覽:使用分析器工具查看未建立索引的查詢清單,以及讀取/寫入作業的即時總覽。
- 預估帳單用量:使用 Firebase 控制台提供的用量指標,查看帳單用量和概要成效指標。
- 詳細的深入分析:使用 Cloud Monitoring,更精細地瞭解資料庫在一段時間內的效能。
依指標提升成效
收集資料後,請根據您想改善的成效領域,參考下列最佳做法和策略。
成效改善策略一覽 | ||
---|---|---|
指標 | 說明 | 最佳做法 |
負載/使用率 | 盡量減少資料庫容量在任何時間點處理要求時的使用量 (反映在「負載」或「io/database_load」指標中)。 |
將資料結構最佳化 在資料庫之間分片資料 提升接聽程式效率 使用以查詢為準的規則限制下載次數 將連線最佳化 |
有效連線數 | 請平衡資料庫的有效連線數,確保不超過 20 萬個連線的上限。 |
在資料庫之間分片資料 減少新連線 |
連出頻寬 | 如果資料庫的下載次數似乎高於預期,您可以提高讀取作業的效率,並減少加密負擔。 |
最佳化連線 最佳化資料結構 使用以查詢為準的規則限制下載次數 重複使用 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 代管儲存的資料。
發布可更新的擴充性程式碼
內建於物聯網裝置的應用程式應包含可擴充的程式碼,方便您輕鬆更新。請務必徹底測試用途,考量使用者人數可能大幅增加的情況,並內建將更新部署至程式碼的功能。如果您決定將資料分片,請仔細考慮日後可能需要進行的重大變更。