搭配使用 Cloud Firestore 與 Firebase 即時資料庫

您可以在應用程式中同時使用 Firebase Realtime DatabaseCloud Firestore,並利用每個資料庫解決方案的優點,以符合您的需求。舉例來說,您可能想利用 Realtime Database 對狀態的支援功能,如「Cloud Firestore 中建構狀態」一文所述。

進一步瞭解資料庫之間的差異

將資料移動至 Cloud Firestore

如果您已決定要將部分資料從 Realtime Database 遷移至 Cloud Firestore,請考慮採用下列流程。由於每個資料庫都有獨特的需求和結構考量,因此沒有自動遷移路徑。您可以按照以下一般流程進行:

  1. 將資料結構和安全性規則從 Realtime Database 對應至 Cloud FirestoreRealtime DatabaseCloud Firestore 都會使用 Firebase 驗證機制,因此您不需要變更應用程式的使用者驗證機制。不過,安全性規則和資料模型不同,因此在開始將資料移至 Cloud Firestore 之前,請務必仔細考量這些差異。

  2. 移動歷來資料。Cloud Firestore 中設定新的資料結構時,您可以將現有資料從 Realtime Database 對應及移至新的 Cloud Firestore 例項。不過,如果您在應用程式中同時使用這兩個資料庫,就不需要將歷來資料從 Realtime Database 中移出。

  3. 即時將新資料同步至 Firestore。使用 Cloud 函式,在新增資料時將資料寫入新的 Cloud Firestore 資料庫,並新增至 Realtime Database

  4. Cloud Firestore 設為遷移資料的主要資料庫。遷移部分資料後,請將 Cloud Firestore 做為主要資料庫,並減少 Realtime Database 對遷移資料的使用。請考量哪些應用程式版本仍與 Realtime Database 連結,以及您打算如何繼續支援這些版本。

請務必為 Realtime DatabaseCloud Firestore 分別計算帳單費用

對應資料

Realtime Database 中的資料結構為單一樹狀結構,而 Cloud Firestore 則透過文件、集合和子集合支援更明確的資料階層。如果您將部分資料從 Realtime Database 移至 Cloud Firestore,建議您考慮為資料採用不同的架構。

需考量的重大差異

如果您將資料從現有的 Realtime Database 樹狀結構移至 Cloud Firestore 文件和集合,請注意以下資料庫之間的主要差異,這些差異可能會影響您在 Cloud Firestore 中建立資料結構的方式:

  • 淺層查詢可在階層式資料結構中提供更多彈性。
  • 複雜查詢可提供更精細的資料,並減少重複資料的需求。
  • 查詢游標可提供更可靠的分頁功能。
  • 交易不再需要所有資料的共同根目錄,因此效率更高。
  • Realtime DatabaseCloud Firestore 的帳單費用不同。在許多情況下,Cloud Firestore 可能比 Realtime Database 昂貴,特別是如果您需要執行許多小型作業時。建議您減少資料庫的作業次數,並避免不必要的寫入作業。進一步瞭解 Realtime DatabaseCloud Firestore 之間的結帳差異。

最佳做法實例

下列範例反映了在資料庫之間轉移資料時,您可能會考量的幾項事項。您可以利用淺層讀取和改善的查詢功能,取得比 Realtime Database 更自然的資料結構。

舉例來說,假設您開發的城市指南應用程式,可協助使用者在世界各地的城市中尋找知名地標。由於 Realtime Database 缺乏淺層讀取功能,您可能必須在兩個頂層節點中建構資料,如下所示:

// /cities/$CITY_KEY
{
  name: "New York",
  population: 8000000,
  capital: False
}

// /city-landmark/$CITY_KEY/$LANDMARK_KEY
{
  name: "Empire State Building",
  category: "Architecture"
}

Cloud Firestore 有淺層讀取功能,因此查詢集合中的文件不會從子集合中提取資料。因此,您可以在子集合中儲存地標資訊:

// /cities/$CITY_ID
{
  name: "New York",
  population: 8000000,
  capital: False,
  landmarks: [... subcollection ...]
}

文件大小上限為 1 MB,這也是將地標儲存為子集合的原因之一,可讓每個城市文件保持小型,而非使用巢狀清單導致文件變大。

Cloud Firestore 的進階查詢功能可減少重複資料的產生,以便處理常見的存取模式。舉例來說,假設城市指南應用程式中的畫面顯示所有首都城市,並依人口數排序。在 Realtime Database 中,最有效率的方法是維護一份首都城市的清單,其中重複 cities 清單中的資料,如下所示:

{
   cities: {
    // ...
   },

   capital-cities: {
     // ...
   }
}

Cloud Firestore 中,您可以將首都清單以人口數量排序,並以單一查詢表示:

db.collection('cities')
    .where('capital', '==', true)
    .orderBy('population')

進一步瞭解 Cloud Firestore 資料模型,並查看我們的解決方案,進一步瞭解如何建構 Cloud Firestore 資料庫。

確保資料安全

無論您是使用 Cloud Firestore Security Rules 為 Android、Apple 或 Web 用戶端,還是使用 身分存取管理 (IAM) 為伺服器,請務必保護 Cloud FirestoreRealtime Database 中的資料。兩個資料庫的使用者驗證作業都由 Authentication 處理,因此您開始使用 Cloud Firestore 時,不必變更 Authentication 的實作方式。

需考量的重大差異

  • 行動和網頁 SDK 會使用 Cloud Firestore Security Rules,而伺服器 SDK 則會使用 Identity Access Management (IAM) 來保護資料。
  • Cloud Firestore Security Rules 不會遞迴,除非您使用萬用字元。否則,文件和集合不會繼承規則。
  • 您不再需要另外驗證資料 (如同您在 Realtime Database 中所做的)。
  • Cloud Firestore 會在執行查詢前檢查規則,確保使用者對查詢所傳回的所有資料皆有適當的存取權。

將歷來資料移至 Cloud Firestore

將資料和安全性結構體對應至 Cloud Firestore 的資料和安全性模型後,您就可以開始新增資料。如果您打算在將應用程式從 Realtime Database 移至 Cloud Firestore 後查詢歷來資料,請將舊資料的匯出內容新增至新的 Cloud Firestore 資料庫。如果您打算在應用程式中同時使用 Realtime DatabaseCloud Firestore,可以略過這個步驟。

為避免新資料遭舊資料覆寫,建議您先新增歷來資料。如果您同時將新資料新增至兩個資料庫,請務必優先將 Cloud Functions 新增至 Cloud Firestore 的新資料。

如要將歷來資料遷移至 Cloud Firestore,請按照下列步驟操作:

  1. Realtime Database 匯出資料,或使用最近的備份
    1. 前往 Firebase 控制台的「Realtime Database部分。
    2. 在「資料」分頁中,選取資料庫的根層級節點,然後從選單中選取「匯出 JSON」
  2. Cloud Firestore 中建立新的資料庫,然後新增資料

    將部分資料移至 Cloud Firestore 時,請考慮採用下列策略:

    • 編寫自訂指令碼,為您轉移資料。由於每個資料庫的需求都不盡相同,我們無法提供這個指令碼的範本,但Cloud Firestore Slack 管道Stack Overflow 的專家可以審查您的指令碼,或針對您的具體情況提供建議。
    • 使用伺服器 SDK (Node.js、Java、Python 或 Go) 將資料直接寫入 Cloud Firestore。如需設定伺服器 SDK 的操作說明,請參閱「開始使用」。
    • 如要加快大量資料遷移作業,請使用批次寫入,並在單一網路要求中傳送最多 500 項作業。
    • 為避免超過 Cloud Firestore 頻率限制,請將每個集合的作業限制為每秒 500 次寫入。

新增資料至 Cloud Firestore

為維持資料庫之間的一致性,請在即時情況下將新資料新增至兩個資料庫。每當用戶端寫入 Realtime Database 時,請使用 Cloud Functions 觸發寫入 Cloud Firestore 的動作。請確認 Cloud Firestore 會優先處理來自 Cloud Functions 的新資料,而非您在歷來資料遷移作業中所做的任何寫入作業。

建立函式,以便在用戶端每次將資料寫入 Realtime Database 時,將新資料或變更的資料寫入 Cloud Firestore。進一步瞭解 Cloud FunctionsRealtime Database 觸發條件

Cloud Firestore 設為遷移資料的主要資料庫

如果您決定使用 Cloud Firestore 做為部分資料的主要資料庫,請務必考量您已設定的任何資料鏡像函式,並驗證 Cloud Firestore Security Rules

  1. 如果您使用 Cloud Functions 來維持資料庫之間的一致性,請確保在迴圈中不會重複寫入兩個資料庫的操作。將函式切換為寫入單一資料庫,或完全移除函式,並開始逐步淘汰仍與 Realtime Database 綁定的應用程式中已遷移資料的寫入功能。您如何處理應用程式的問題,取決於您的具體需求和使用者。

  2. 確認資料已妥善安全防護。驗證 Cloud Firestore Security Rules 或 IAM 設定。