Firestoreを使いこなすための勘所をつらつらと書いていきます。パート1の本記事ではFirestoreの全体観を掴んでいただけたらと思います。Platform)のサービス群の1つという捉え方がありますが、本記事ではFirebase経由で使うことを前提に書いていきます。Functionsなど関連サービスとして言及するものも同様です。Firebaseはざっくり言うとGCPのクライアントアプリ向けサービスを使いやすく提供しているラッパーサービスなので、それで足りるものはFirebase経由での利用をお勧めします。ドキュメントも次のように2箇所にあるのですが、Firebase経由で使う場合は基本的に前者の方を見るだけで充分です。FirebaseのFirestoreドキュメントGCPのFirestoreドキュメントまず、そもそもFirestoreとは何?ということに関しては、次の記事の前半に書いたので、ご覧ください。Firestoreが発表されました。medium.comFirestoreを使うと何が嬉しい?まずはFirestoreの利点をざっと紹介します。サーバーレス(サーバーの管理不要)Firestoreに限らずFirebase配下のサービスすべてに言えることですが、サーバーの管理が不要で、主に次の恩恵を受けられます。(SLA)が定義されたことだと思います。品質要件が厳しいサービスでも選択しやすくなったはずです。to...cloud.google.comまた、これに合わせて、2019年3月3日から非マルチリージョンの料金が半額くらいになります。以下のベータ版はそれ以前の状態でしたがしばらく残しておきます。—ただ、Firestoreは現状ベータ版なので、以下の注意が必要です。SLA(サービス品質保証)適用外ということが気になると思いますが、筆者が使っている限りは特に最近はとても安定して動いています。2017年まではたまに挙動不審になったり遅延が大きくなる感じもありましたが、最近は全然体感できないです。過去1週間のサービスステータスは以下から確認できますが、ご覧の通り障害ゼロです。current...status.firebase.google.comこの前の期間も含めて、少なくとも過去数週間はFirestoreの障害ゼロですFirestoreはまだSLA適用外なものの、筆者はプロダクション利用に充分耐え得ると感じて使っていますが、これは個人の感覚や運用しているサービスポリシーにもよるので、ベータ版な時点で使いものにならないと見なされることもあると思います。公式ドキュメントに、世界規模の大きなアプリにも耐え得るスケーリング性能を持つと明記されています。普通に書けば普通に実質青天井にスケールするサービスを作れます。apps.https://firebase.google.com/docs/firestore/次の記事も参考になります。Qiitaクックパッドの新規サービスKomercoを設計した@1amageekです。...qiita.comデータの高速な同期処理をクライアントコードのみで容易に実現できるこのあたりから、実利用する時の観点になってきます。APIを介するサーバー・クライアント間の処理を、クライアントコードだけで簡単に実現できます。模様)と同期されます。SDKが自動的にやってくれます。API含めて自力で正確かつ高速な実装をしようとすると大きな労力がかかりますし、スケーリング性能を考慮するとさらに難易度が上がります。これまでの少人数開発ではそのあたりの何かしらを妥協しながら開発進めざるを得ないことが多かったですが、Firestore(や類似技術)の登場により短期間で極めて品質の高いアプリを作ることが可能となりました。Functionsを併用することで次のようにクラウド上のロジックを組み合わせることも容易にできるという柔軟性も持ち合わせています。Functionsを叩いて、そこからいくつかの処理を組み合わせながらデータ更新(HTTPSトリガーを利用)Firestoreの不利な点ここまで良い点ばかり挙げていましたが、もちろん不利な点もあります。NoSQLデータベースであることに起因するものが挙げられます。複雑なクエリ・集計処理が困難まず、Firestoreでは「クエリがまったくできない」というわけではないです。Databaseから大きく改善された点でもあります。コレクションから取得するドキュメントを指定するための強力なクエリ機能を提供します。...firebase.google.comざっくり次のことは対応されています。単一フィールドによる、単純な絞り込み・ソート複数のフィールドの組み合わせによる、単純な絞り込み・ソートデフォルトでは、すべての単一フィールドにインデックスが貼られているため前者のクエリはできるものの、後者の複数のフィールドの組み合わせによるクエリをしたい場合、その組み合わせによってその都度あらかじめインデックスの作成が必要なことにも注意です。最高のパフォーマンスを実現するには、すべてのクエリにインデックスが必要です。フィールドにインデックスが自動的に作成されるため、equality...firebase.google.comインデックス未定義のフィールドの組み合わせのクエリを投げると、次のような実行時エラーが発生してインデックス定義を促されます。https://console.firebase.google.com/project/PROJECT_ID/database/firestore/indexes?create_index=EghtZXNzYWdlcxoNCgljcmVhdGVkQXQQAxoQCgxzZW5kZXJVc2VySWQQAxoMCghfX25hbWVfXxAD"記載のURLを踏むと、次のように定義の足りないインデックスの作成画面に飛びます。CLIを利用することをおすすめします。インデックスをコード管理できたり、複数環境のインデックス更新をミス無く行えるようになります。)すると、手動操作した場合と同じ結果になります。firestore.index.jsonの例2つ以上のキーによるクエリ・ソートの度にインデックス定義が強制されるのはやや面倒と思うかもしれませんが、これによりすべてのクエリにはインデックスが使われることになり、つまり基本的に重いクエリを投げることが不可能となっていて、むしろ優れた点だと捉えています。単純な絞り込み・ソートそれぞれ「単純な」と注釈付きなのは、一般的なRDB(リレーショナルデータベース)では当たり前にできることも、FIrestoreではできないことが多いからです。ドキュメントの「クエリの制限事項」に5つほど記載されているものを眺めるとイメージが湧くはずです。集計操作などは概念さえ存在しません。次のような考え方の変化が必要です。BigQueryへロード・クエリー、というやり方が公式にサポートされたので、かなり解消されました。詳しくは以下の一連のツイートなどご覧ください。and...cloud.google.comただ、RDBはエクスポート・ロードなどの手順無しにすぐにクエリーできるので、その手軽さには劣るはずですし少しコストが嵩むのも気になります。いえ、RDBでもデータ分析用にリードレプリカ追加したり分析に適したデータベースに適宜移すなどして別途分析基盤を整えることも普通なので、それと同等のことを簡単にできるようになったと言えます。APIおよびgcloudコマンドが提供されました:そのため、次のようにそれらを組み合わせて、バックアップ・リストアの仕組みを構築可能です。Cloud...medium.com以前と比べると大きく改善されはしましたが、いわゆるフルマネージドなバックアップサービスはまだ提供されていません。Storage(GCS)にバックアップされます。新しいスケーラブルで、フレキシブルなデータベースを利用できるようになりました。Overflowなどでも質問があり、その回答の通り、現時点ではFirestoreにマネージドなバックアップサービスが存在しません。Jobなどで実行することでバックアップは可能です(もちろん自前で別のバックアップ処理を書いてもOKです)。toolgithub.com本記事で述べたFirestoreの特性をまとめると、次のような感じでしょうか。RDBではできてFirestoreではできないこと(苦手なこと)をきちんと把握して、アプリ要件に適したデータ構造・使い方の工夫が大事Firestoreでも単純なクエリ・ソートは可能なものの、それで解決困難な要件では外部サービスの併用が必要まだベータ版なことに注意(SLA適用外・マネージドなバックアップサービスが無い、など)NoSQLデータベースであることに起因する不利な点は、強力なスケーリング性能とのトレードオフとして割り切るしかないですね。個人的には、単純なクエリができるだけでもありがたいと感じています。本記事のパート1ではFirestoreの概要説明だけとなりましたが、パート2では実践的な使い方をなぞっていきます。製品などに関連するコミュニティが記載したテクニカル記事集。ものを反映するものではありません。製品などに関連するコミュニティが記載したテクニカル記事集。ものを反映するものではありません。UpgradeAboutHelpLegal。