搭配使用 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 驗證機制，因此您不需要變更應用程式的使用者驗證機制。不過，安全性規則和資料模型不同，因此在開始將資料移至 Cloud Firestore 之前，請務必仔細考量這些差異。

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

  3. 即時將新資料同步至 Firestore。將新資料新增至 Realtime Database 時，使用 Cloud Functions 將新資料寫入新的 Cloud Firestore 資料庫。

  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 或 Web 用戶端使用 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 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 Functions 的 Realtime Database 觸發條件。

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

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

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

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