FirestoreはGoogleが2017年10月にβ公開、2019年にGAとなったクラウドドキュメントデータベースで、Firebaseチームが従来提供していた「Realtime Database」の事実上の後継として設計された。正式名は「Cloud Firestore」だが、Firebase文脈とGCP文脈の両方から利用でき、モバイルアプリ向けバックエンドからWebアプリ、業務システムのオフライン対応まで幅広く採用されている。内部ではGoogleのグローバル分散ストレージ基盤を使っており、強整合（強一貫性）かつスキーマレスなコレクション／ドキュメントモデルを提供する。本記事ではRealtime DBとの違い、データモデル、リアルタイム同期、料金体系を整理する。
この記事の目次
- Realtime Databaseからの世代交代
- コレクションとドキュメント、クエリ言語
- リアルタイム同期とオフライン対応
- 料金とDatastoreモードの位置付け
- まとめ
Realtime Databaseからの世代交代
Firebase Realtime Databaseは2012年から続くJSONツリー型のNoSQLで、スマホアプリのリアルタイム同期用途で大きな成功を収めた。しかしJSONツリーが大きくなるとクエリが書きにくい、スキーマ的な目印が薄く運用が辛いといった課題があり、Googleはコレクション／ドキュメント型のFirestoreを新世代として設計した。Firebaseのコンソールでも長らく両者が並列に提供され、新規プロジェクトではFirestoreが推奨される構図になっている。
Firestoreは内部的にCloud Spannerなどと共通のグローバル分散ストレージ技術を活用しており、複数ドキュメントにまたがるトランザクションを強整合（serializable）で実行できる。Realtime DatabaseのようにJSONツリーを丸ごと書き換えてしまう操作と違い、ドキュメント単位で原子的な更新ができるため、業務的な処理にも適している。結果として「Firestore＝アプリ向けにもSaaSバックエンドにも使える汎用ドキュメントDB」へとポジションが広がった。
コレクションとドキュメント、クエリ言語
Firestoreのデータは「コレクション」と「ドキュメント」が交互に階層化される構造で表現される。コレクションは型を持たない論理グループ、ドキュメントはJSONライクなフィールドの集合だ。ドキュメント配下にさらにサブコレクションを置けるため、「ユーザー > 注文 > 行アイテム」のような階層も自然にモデリングできる。
クエリは「フィールド==値」「>」「array-contains」など型付きの絞り込みが豊富で、複合インデックスを定義すれば複数条件のand検索もまかなえる。ただしJOINや任意の集計はSQLほど自由ではなく、データモデル側で「非正規化」「サブコレクション分割」を駆使する設計が前提になる。リレーショナルDBに慣れたエンジニアにとっては最初に戸惑うポイントだが、慣れるとモバイル／Webの応答性能を引き出しやすい。
リアルタイム同期とオフライン対応
Firestoreの大きな魅力は、クライアントSDKによるリアルタイム同期とオフライン対応である。iOS、Android、Webのクライアントは、ドキュメントやクエリ結果を「listener」として購読でき、サーバ側で書き込みが起きると変更が即座にプッシュ配信される。チャットアプリやコラボツールでよく見る「他人が書いた瞬間に画面が更新される」体験が、サーバ側のWebSocket実装なしで成立する。
また、各クライアントSDKはローカルキャッシュを持ち、オフライン中の書き込みを保留して、復帰時にサーバへ送り直す機能を備える。ネットワーク状況が不安定なモバイル環境でも体感を損なわない設計だ。サーバ側で実行されるトリガとしては、Cloud Functions for Firebaseがあり、ドキュメント書き込み時に集計や通知などの追加処理を非同期に走らせられる。
料金とDatastoreモードの位置付け
Firestoreの料金は「読込・書込・削除の回数」「ストレージ量」「ネットワーク転送量」を組み合わせた従量制で、リレーショナルDBのようなインスタンス時間課金とは性質が異なる。「アクセスが少ない時は本当に安いが、ホットなコレクションをN+1で何百回も読むと意外に高くつく」という挙動が特徴で、データモデル設計と無駄読みの削減が運用コストを左右する。マルチリージョン構成（5マルチリージョンなど）は単価が上がる代わりに、リージョン全体障害に耐える耐久性を得られる。
Firestoreには「Nativeモード」と「Datastoreモード」があり、後者は旧Cloud Datastore互換のAPIを提供する。App Engineの伝統的なPython資産などはDatastoreモードで使い続けるケースが多い一方、新規のスマホアプリやWebアプリ案件は基本的にNativeモードを選ぶのが主流だ。目的に応じてモードを選び、サブコレクション設計と複合インデックスを整えれば、Firestoreは大規模アプリにも十分耐えるバックエンドになる。
まとめ
FirestoreはRealtime Databaseの長所であるリアルタイム同期とオフライン対応を引き継ぎつつ、コレクション／ドキュメントモデルと強整合トランザクションで業務システムにも耐える設計を備えたドキュメントDBである。Firebase文脈ではモバイル／Webアプリの一等地、GCP文脈ではアプリ寄りのバックエンドとして広く採用され、Cloud Functionsとの連携でサーバレスフルスタックの土台にもなる。従量課金とNoSQL特有のモデリングという二つを意識して設計すれば、長期運用にも耐える堅実な選択肢となるだろう。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント