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

您可以在應用程式中使用 Firebase Realtime Database 和 Cloud Firestore，並根據需求運用每個資料庫解決方案的優點。舉例來說，您可能想利用 Realtime Database 對在場狀態的支援，如「在 Cloud Firestore 中建立在場狀態」一文所述。

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

正在將資料移至「Cloud Firestore」

如果您決定要從 Realtime Database 遷移部分資料至 Cloud Firestore，請參考下列流程。由於每個資料庫都有獨特的需求和結構考量，因此沒有自動遷移路徑。不過，您可以按照下列一般進度操作：

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

  2. 移動歷來資料。 在 Cloud Firestore 中設定新的資料結構時，您可以將 Realtime Database 中的現有資料對應並移至新的 Cloud Firestore 執行個體。不過，如果您在應用程式中同時使用這兩個資料庫，則無須將歷來資料移出 Realtime Database。

  3. 將新資料即時鏡像到 Firestore。 使用 Cloud Functions 將新資料寫入新Cloud Firestore資料庫，因為資料會新增至 Realtime Database。

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

請務必將 Realtime Database 和 Cloud Firestore 的帳單費用納入考量。

對應資料

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

需要考量的主要差異

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

  • 淺層查詢可讓您更靈活地處理階層式資料結構。
  • 複雜查詢可提供更精細的資料，並減少重複資料的需求。
  • 查詢游標可提供更穩定的頁面分頁功能。
  • 交易不再需要所有資料的通用根目錄，效率也更高。
  • Realtime Database 和 Cloud Firestore的帳單費用不同。在許多情況下，Cloud Firestore可能比 Realtime Database 更昂貴，特別是當您依賴許多小型作業時。建議減少資料庫的作業數量，並避免不必要的寫入作業。進一步瞭解 Realtime Database 和 Cloud 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

確保資料安全

無論您是使用適用於 Android、Apple 或網頁用戶端的 Cloud Firestore Security Rules，還是適用於伺服器的 Identity Access Management (IAM)，請務必保護 Cloud Firestore 和 Realtime 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 Database 和 Cloud Firestore，可以略過這個步驟。

為避免舊資料覆寫新資料，建議您先新增歷史資料。如要同時將新資料新增至兩個資料庫 (如下一個步驟所述)，請務必優先處理新增至 Cloud Firestore 的新資料 (透過 Cloud Functions)。

如要將歷史資料遷移至 Cloud Firestore，請按照下列步驟操作：

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

  2. 在 Cloud Firestore 中建立新資料庫，然後新增資料。

    將部分資料移至 Cloud Firestore 時，請考慮下列策略：

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

將新資料新增至「Cloud Firestore」

如要維持資料庫之間的同等性，請即時將新資料新增至兩個資料庫。每當用戶端寫入 Realtime Database 時，請使用 Cloud Functions 觸發寫入 Cloud Firestore。請確保系統會優先處理來自 Cloud Functions 的新資料，而非您從歷史資料遷移作業寫入的資料。Cloud Firestore

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

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

如果您決定將 Cloud Firestore 做為部分資料的主要資料庫，請務必考量您設定的所有資料鏡像功能，並驗證 Cloud Firestore Security Rules。

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

  2. 確認資料受到妥善保護。驗證 Cloud Firestore Security Rules 或 IAM 設定。