はじめての個人開発には、Firebase を使ってみよう（２）～ Cloud Firestore 編～
こんにちは。地図パズル製作所では Firebase を使っています。今日は、個人開発で Firebase を使うといい理由を説明する第二弾で、データベースサービスの Cloud Firestore について解説します。私自身 Cloud Firesotre は勉強中なのですが、頑張って解説していきたいと思います。間違っている部分がありましたら、ぜひコメントでご指摘お願いします！
第一弾の記事を読んでない方はぜひそちらもお読みになってみてください。地図パズル製作所についてはじめて知ったという方は、ぜひ地図パズル製作所のウェブサイトも見てみてください！
Cloud Firestore とは
Cloud Firestore は Firebase に二つあるデータベースサービスのうちの一つで、今は「Firebase といえば、Cloud Firestore」と言ってもいいような重要なシステムです。では、Cloud Firestore の特徴をどんどん説明して行きましょう！
Firestore の特徴
Firestore は NoSQL？NoSQL ってどんなの？難しい？
Firestore は NoSQL データベースの一つです。NoSQL は、リレーショナルデータベース以外のデータベースの総称で、さまざまな種類があります。かなり前から NoSQL は話題になっていますが、やはりリレーショナルデータベースを脅かすような存在になることはなく、適材適所で用いられている、という印象です。Firestore や MongoDB のようなドキュメント指向データベース、Realtime Database のような JSON 型、Redis のような キーバリューストアなどがあります。
NoSQL が難しいかについてですが、自信満々で書いている私も使ったことがあるのは、Firestore と Realtime Database の二つだけ、ということで、他の NoSQL データベースが難しいかどうかは正直なところよくわかりません(笑) 確かに私が学生時代に MongoDB を勉強しようと思った時には、英語の資料ぐらいしか情報源がなくて、ほとんど理解できませんでした。でも、今は Firestore については簡単に勉強できます。日本語の情報もとても充実しているので、分からなかったことはたいてい調べれば解決できます。私も半月ほど勉強してから、実装を始めたのですが、困ることはほとんどなかったように思います。Firestore を勉強しようか迷っている方は、ぜひ勉強してみてください。おすすめです。
ちなみに、わたしは Firestore の勉強の始めに、「実践Firestore」という本を一通り読みました。とても良かったです。今は Firebase Javascript SDK の新しいバージョンが出たので、ソースコードは書き換える必要がありますが、基本的な部分は十分勉強できると思います。
管理が不要？
Firestore はサーバーレスなので、面倒な管理がほとんどありません。開発者はアプリケーションの構築に全力を注いで、インフラはお任せです！
自動でスケールする！
個人開発をするときには、自分が作ったシステムがたくさんの人に使われることを夢見るものです（私もです(笑)）。それなのに、たいてい最初はほとんどアクセスがありません(笑) そんなときに、AWS で EC2 + RDS などの構成で構築すると、ほとんどアクセスがないのに、毎月とても高い値段を払うことになります。でも、Firestore ではそんなこと必要ありません！自動でスケールするため、アクセスの増加に対応できますし、アクセスが少なければほとんどお金を払う必要がありません。
値段が安い！
Firestore は他のデータベースより値段が安いと言われています。一般的な RDB を使うと最低でも月に何千円かかかってしまいます。それに対して、Firestore は小規模なシステムでしたら、無料枠内に収まるため、とてもいいです。特に私のように個人開発をされる方にとっては、0円から始められるのはとても魅力的です。ユーザが増えてきたときの料金が安いかということも気になるところですが、それも大丈夫なようです。公式サイトでは、一日のアクティブユーザ数が 5万ユーザで、$12/月 と書かれていました。詳細が気になる方は下の URL から見てみてください。
また、Firestore では、データの読み取り数や書き込み数に応じて課金されていきます。普通のシステムでは書き込みよりも読込のほうが多いので、うまく非正規化をして、無駄なデータを読み取ることがないように、スキーマ設計をしていくことが大切です。
クライアントサイドから直接アクセスする？
Firestore の特徴の一つは、クライアントサイドから直接アクセスするというものです。別の言い方をすると、コレクション（リレーショナルデータベースでいうところのテーブル）を作成すると、自動で対応する API が作成されるような感じです。でも、直接クライアントサイドからアクセスするなんてセキュリティ的にどうなのか、、、と思われる方もいらっしゃると思います。それが、大丈夫なんです。Firestore Authentication というユーザ認証システムと組み合わせ、「セキュリティルール」というものを書くことで、コレクションやドキュメント（リレーショナルデータベースでいうところのレコード）への読み込み、書き込みをユーザごとに制限することができます。また、セキュリティルールを書くことで、データのバリデーションもすることできます。これらの機能のおかげで、Firestore を使うことでアプリのバックエンドを本当に簡単に実装することができてしまいます。私も Firestore を勉強したときは、実装が楽で本当にびっくりしました。
リアルタイムにデータが取得できる！
最近のシステムでは、チャットや Google Spread Sheet などリアルタイムにデータを共有するシステムが多くなっているように思います。最近まで私もこういうシステムがどうやって実現されているかわかっていませんでした。PHP などを長くやってきたものからすると、「1分に一回 Ajax でサーバーからデータを取ってきてるのかな？？」とか考えてしまいますが、たいていはそうではないようです。WebSocket などを使ってリアルタイム通信を実現しているようです。でも、この WebSocket 通信をするシステムを作るのって、とても大変そうですよね。そこで、Firestore を利用します。Firestore が WebSocket を使っているかは分かりませんが、Firestore を利用することでとっても簡単にリアルタイム通信（リアルタイムアップデート）をすることができるようになります！
リアルタイムアップデートを実装するのはとても簡単で、onSnapshot() というメソッドを実行するだけです。もっと詳しく知りたい方は、以下の URL から調べてみてください。
Firestrore の難しい点
マイグレーションをどうする？
Firestore のようなスキーマレスデータベースではマイグレーションの考え方が難しいです。でも、できないというわけではないようです。この点については、私はまだ勉強中なので、よく説明された Qiita の記事を見つけたので、リンクを張っておきます！
スキーマ設計は大変？
Firestore のスキーマ設計ですが、あくまでも個人的な意見ですが、リレーショナルデータベースよりも大変です。リレーショナルデータベースについては、正規化など理論がきちんと決まっているため、基本的にはそれに従ってスキーマ設計をしていけばいいだけです。でも、Firestore など NoSQL のスキーマ設計は理論がきちんと決まっていないように思います。例えば、Firestore にはサブコレクションというデータ構造を作ることができるのですが、これがとても強力で、でも同時に悩みの種になったりします（あくまでも、素人の私の意見ですが。。。）。サブコレクションの説明は下の URL にも書かれていますが、コレクション（≒テーブル）のドキュメント（≒レコード）の中にさらにコレクションを持つことができ、それをサブコレクションと呼びます。
このため、例えば建物情報のデータを作ろうとした場合、リレーショナルデータベースだと、buildings、floors、rooms という三つのテーブルを設けることになると思いますが、Firestore だと buildings コレクションのドキュメントに floors サブコレクションを作成して、その下に rooms サブコレクションを作成して、というやり方ができてしまいます。もちろん参照型を用いてリレーショナルデータベースと同じように設計することもできるので、それでいいような気もするのですが、Firestore らしくサブコレクションを使ったスキーマ設計にしたほうがいいような気もして、、初心者抜けきらない私には、未だにどうしたらいいのか分かりません。
他にもリレーショナルデータベースとの違いとして、テーブルを結合することができないことや、集計関数を利用できないことがあります。テーブルを結合することができないため、テーブル結合が必要になった場合は、クライアントサイドに両方のテーブルを持ってきて結合します。また、集計関数を利用できないため、集計が必要になった場合は別途集計用のテーブルやカラムを設けておいて集計結果が変わる変更があったときにはそちらを同時に更新するなどします。
それに加えてもう一つリレーショナルデータベースとの違いとして、リレーショナルデータベースだったら一つのテーブルにできるものでも、Firestore ではコレクションを分ける必要がある場合がある、というものがあります。ユーザ情報を保存する場合を考えると、ユーザのアカウント名については誰から見れてもいいけれども、ユーザの電話番号は管理者と本人しか見れないという場合が多いと思います。こういうふうにしようと思うと、Firestore ではアカウント名保存用のコレクションと電話番号保存用のコレクションを分ける必要が出てきます。リレーショナルデータベースとの違いはこんな感じです。
最後に
今日は Firestore を個人開発で使うといい理由を書いていきました。毎週投稿することに決めて、3記事目ですが、もう息切れ気味。。。。(笑) という感じです。でも、今後も頑張って投稿していきますので、よろしくお願いいたします！
それと、アメブロとツイッターもよろしくお願いします！（ツイッターはアシスタントの霧島さんが投稿してくれています。）
番外編：Realtime Database について
Realtime Database は Firebase のもう一つのデータベースサービスで、Cloud Firestore より古くからあります。Cloud Firestore と同じで、NoSQL データベースですが、key-value 形式になった JSON データを保存して使います。この二つは違うデータベースですが、Firestore が Realtime Database の高機能版と言われているように、似た部分がたくさんあり、どちらもリアルタイムアップデートができたり、クライアントサイドから直接アクセスして使ったりします。
私はほとんど利用したことはないのですが、Cloud Firestore より、Realtime Database のほうがいい場合もあるようです。下のリンクから説明をご覧ください。
特に、上の URL にも書かれていますが、チャットなどでユーザがオンラインかどうか判別する機能（プレゼンス機能といいます）を作る場合は、Firestore では実現できないため、Realtime Database を利用する必要があるようです。他にも Realtime Database のいい使い方などありましたら、コメントでぜひ教えてください！
Discussion