Firebase Summit のすべての発表内容に目を通し、Firebase を活用してアプリ開発を加速し、自信を持ってアプリを実行できる方法をご確認ください。 詳細

FirebaseRealtimeデータベースでCloudFirestoreを使用する

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

アプリで Firebase Realtime Database と Cloud Firestore の両方を使用し、ニーズに合わせて各データベース ソリューションの利点を活用できます。たとえば、Cloud Firestore でのプレゼンスの構築で概説されているように、Realtime Database のプレゼンスのサポートを活用したい場合があります。

データベース間の違いの詳細をご覧ください。

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 を使用して、Realtime Database に追加された新しい Cloud Firestore データベースに新しいデータを書き込みます。

  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 Database と Cloud Firestore で異なります。多くの場合、Cloud Firestore は Realtime Database よりも高価になる可能性があります。特に、多数の小さな操作に依存している場合はそうです。データベースに対する操作の数を減らし、不要な書き込みを避けることを検討してください。 Realtime Database と Cloud Firestore の課金の違いについて詳しくは、こちらをご覧ください。

実際のベスト プラクティス

次の例は、データベース間でデータを移動する際の考慮事項の一部を反映しています。浅い読み取りと改善されたクエリ機能を利用して、Realtime Database で使用していたよりも自然なデータ構造を取得できます。

ユーザーが世界中の都市で注目すべきランドマークを見つけるのに役立つシティ ガイド アプリを考えてみましょう。 Realtime Database には浅い読み取りがないため、次のように 2 つの最上位ノードでデータを構造化する必要がある場合があります。

// /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 ...]
}

ドキュメントの最大サイズは 1MB です。これは、ネストされたリストでドキュメントを肥大化させるのではなく、ランドマークをサブコレクションとして保存し、各都市ドキュメントを小さく保つもう 1 つの理由です。

Cloud Firestore の高度なクエリ機能により、一般的なアクセス パターンでデータを複製する必要がなくなります。たとえば、すべての首都を人口順に表示するシティ ガイド アプリの画面を考えてみましょう。 Realtime Database でこれを行う最も効率的な方法は、次のように、 citiesリストからデータを複製する首都の別のリストを維持することです。

{
   cities: {
    // ...
   },

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

Cloud Firestore では、首都のリストを人口順に 1 つのクエリとして表現できます。

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

Cloud Firestore データ モデルの詳細を読み、Cloud Firestore データベースを構築する方法に関するその他のアイデアについては、ソリューションをご覧ください。

データを保護する

Android、Apple、または Web クライアントにCloud Firestore セキュリティ ルールを使用しているか、サーバーにIdentity Access Management (IAM)を使用しているかに関係なく、Cloud Firestore と Realtime Database でデータを保護していることを確認してください。ユーザー認証は両方のデータベースの Authentication によって処理されるため、Cloud Firestore の使用を開始するときに Authentication の実装を変更する必要はありません。

考慮すべき主な違い

  • モバイル SDK とウェブ SDK は Cloud Firestore セキュリティ ルールを使用しますが、サーバー SDK は Identity Access Management (IAM) を使用してデータを保護します。
  • ワイルドカードを使用しない限り、Cloud Firestore セキュリティ ルールはカスケードしません。それ以外の場合、ドキュメントとコレクションはルールを継承しません。
  • ( 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 に移動するときは、次の戦略を検討してください。

    • データを移植するカスタム スクリプトを記述します。このスクリプトのテンプレートを提供することはできませんが、すべてのデータベースには固有のニーズがあるため、 Slack チャネルまたはStack Overflowで Cloud Firestore の専門家がスクリプトを確認したり、特定の状況についてアドバイスを提供したりできます。
    • サーバー SDK (Node.js、Java、Python、または Go) を使用して、Cloud Firestore にデータを直接書き込みます。サーバー SDK の設定手順については、 「はじめに」を参照してください。
    • 大規模なデータの移行を迅速に行うには、バッチ書き込みを使用し、1 つのネットワーク リクエストで最大 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 セキュリティ ルールを検証してください。

  1. Cloud Functions を使用してデータベース間のパリティを維持している場合は、ループ内の両方のデータベースで書き込み操作が重複していないことを確認してください。関数を単一のデータベースに書き込むように切り替えるか、関数を完全に削除して、まだ Realtime Database に関連付けられているアプリで移行されたデータの書き込み機能を段階的に廃止してください。アプリでこれをどのように処理するかは、特定のニーズとユーザーによって異なります。

  2. データが適切に保護されていることを確認します。 Cloud Firestore セキュリティ ルールまたは IAM 設定を検証します。