搭配使用 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 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 Functions 的Realtime Database 觸發條件。

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

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

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

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