搭配使用 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。 使用 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 資料庫。

確保資料安全

無論您是使用 Cloud Firestore Security Rules 處理 Android、Apple 或網頁用戶端，還是使用身分與存取權管理 (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 控制台中，依序前往「Databases & Storage」> 「即時資料庫」
    2. 在「Data」(資料) 分頁中，選取資料庫的根層級節點，然後從選單中選取「Export JSON」(匯出 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 設定。