Firebase Realtime Database

解決する課題

サーバーのポーリングや WebSocket 基盤を自前で組まずに、複数クライアント間で状態を即時に共有する仕組みを提供します。

• チャット・プレゼンス（オンライン状態）・共同編集など、変更を全員へ即座に届けたい
• ネットワークが切れてもオフラインで動き続け、再接続時に自動同期したい
• モバイル/Web から直接DBに読み書きし、サーバーコードを最小化したい
• リアルタイム配信のための接続管理・差分配信を自分で実装したくない

主要概念と用語

• JSONツリー: データベース全体が1つの大きな JSON オブジェクト。テーブルやコレクションの概念はなく、すべてが階層パスで表現される
• ノード / パス: ツリー上の各要素と、それを指す階層パス（例 rooms/room1/messages）。パス単位で読み書き・購読する
• リアルタイムリスナー: 指定パスの変更を購読し、初期値とその後の差分を継続的に受信する仕組み（value や child_added などのイベント）
• オフライン永続化: クライアント側にデータをキャッシュし、切断中も読み書きでき、再接続時にサーバーと同期する機能
• プレゼンス / onDisconnect: クライアント切断時にサーバー側で実行する処理を事前登録し、オンライン状態の管理などに使う
• Security Rules: パスごとに読み書き可否やデータ形式を宣言的に定義する、Realtime Database 専用のルール言語
• インスタンス: 1つの Realtime Database（既定のほか、追加インスタンスを作成可能）。Firestore とは別サービスである点に注意

仕様・制限・クォータ

• データモデルは単一の JSON ツリーで、結合や集計を伴うクエリ・複合条件クエリは苦手。基本は単一パスの取得とソート/フィルタに限られる
• クエリは1度に1つのプロパティでのみ並べ替え・絞り込みが可能で、複数条件の組み合わせはクライアント側やデータ構造の工夫で対応する
• 1インスタンスあたりの同時接続数やスループットには上限があり、それを超える規模ではインスタンス分割やシャーディングを検討する
• ロケーションはリージョン単位で選択する（Firestore のマルチリージョン構成とは異なる）
• データを深くネストすると、親パスの取得で子全体を読み込んでしまうため、構造はできるだけ浅く保つことが推奨される
• 具体的な接続数・サイズの上限値や料金は変動するため、最新値は公式ドキュメントで確認する

内部の仕組み

Realtime Database はサーバー上に保持する JSON ツリーへの変更を、そのパスを購読しているクライアント全員へ差分としてプッシュ配信します。クライアント SDK はローカルにデータのコピーを保持し、書き込みはまずローカルに即時反映してから（楽観的更新）サーバーへ送るため、体感レイテンシが小さくなります。切断中の書き込みはキューに溜められ、再接続時にサーバーと突き合わせて同期します。Firestore がドキュメント/コレクションとインデックス前提のクエリでスケールするのに対し、Realtime Database は1つのツリーへの低遅延な同期に特化している点が本質的な違いです。

設計パターン / ベストプラクティス

• データはフラットに非正規化し、読み取り単位ごとにパスを分けて不要なサブツリーの転送を防ぐ
• 一覧表示や検索のために読み取り用のインデックスとなるパスを別途用意し、必要なデータだけを浅く取得する
• オンライン状態は onDisconnect とプレゼンス用パスで管理し、切断検知をサーバー側に任せる
• 重い集計や複雑なクエリは Realtime Database で行わず、Cloud Functions で別パスへ集計結果を書き出すなどで前計算する
• 大規模化が見込まれる/複雑なクエリが要るなら、最初から Firestore を選択肢に入れて使い分ける

運用・監視

• Firebase コンソールの Usage/メトリクスで、同時接続数・送受信データ量・ストレージ・負荷を監視する
• 同時接続数とデータ転送量が主要な指標。接続数が上限に近づく場合はインスタンス分割やシャーディングを検討する
• Security Rules のシミュレータでルールの読み書き判定を事前検証し、意図しない拒否/許可を防ぐ
• バックアップは自動/手動のエクスポート機能で取得し、構造変更前のスナップショットを残す
• 遅い読み取りはネストの深いパスの取得を疑い、データ構造のフラット化やパス分割で改善する

コスト

課金は主に保存データ量（ストレージ）と、クライアントへ送受信するデータ転送量に基づきます。Firestore のような読み書き「回数」課金ではなく、転送バイト数とストレージ量が中心になる点が特徴です。

下位プランには無料枠や上限があり、規模に応じて従量課金プランへ移行します。具体的な単価や無料枠は変動するため最新の料金ページで確認してください。

セキュリティ

• 保存時暗号化・転送時の暗号化（TLS）はデフォルトで有効
• クライアント直結のアクセスは Security Rules でパスごとに制御する。Firebase Authentication のユーザー情報（auth 変数）を使い、所有者チェックやデータ形式の検証を記述する
• ルールは既定で拒否にし、必要なパス・操作だけを明示的に許可する（全開放のルールを残さない）
• サーバーからの管理アクセスは Admin SDK とサービスアカウントで行い、最小権限を付与する

関連サービス・比較

最も比較されるのは同じ Firebase / Google Cloud のドキュメント型 NoSQL である Firestore です。リアルタイム同期という共通点はありますが、データモデルとクエリ能力、スケール特性が異なります。

ハンズオン / CLI例

Realtime Database の主な操作は Firebase コンソールと Firebase CLI（firebase）で行いますが、有効化やプロジェクト操作は gcloud でも扱えます。

# Firebase / Realtime Database 関連 API を有効化
gcloud services enable firebasedatabase.googleapis.com

# 既存の Google Cloud プロジェクトを Firebase プロジェクトとして登録
gcloud firebase projects add-firebase PROJECT_ID

# Firebase CLI で Security Rules をデプロイ（database.rules.json を反映）
firebase deploy --only database --project PROJECT_ID