RDBとFirebaseのDB両方使ったっていいじゃない

今年Firebaseを使い始めてからちょこちょこ自分の中で議題に上がるのが、RDBとFirebaseのデータベース（Firestore、Realtime Database）のどちらが使い勝手良いのか、ということ。ただ、そもそもどちらかを選ばなきゃいけないというわけではなく、適宜両方使えばいいということが分かったのでそれについての雑記。

そもそもまず、なぜ悩むところがあったのか。

Firebaseのデータベースのデメリット

一番大きいのはやはりリレーショナルでないことと、クエリが弱いということ。集計ができなかったり、欲しいデータがすぐ取れなかったりする。

RDBのデメリット

とりあえずRDBにしておけば何でもできるというのはあるが、デメリットとしてはやはりサーバーもしくはお金が必要になってくるということ。サーバー内に入れると管理やスペックの調整などが気になるし、別途RDSやCloud SQLを使うと当然お金がかかる。

Heroku等のPostgresやJawsを使う手もあるが、あまりにも容量が少なすぎる。

Firebaseへの期待が高まりすぎる

RDBはメリットが高いが、やはりサーバーが不要というFirebaseのデータベースのメリットも同様に非常に高い。そのため、いつかバージョンアップした際にクエリが強くなるのではないか、もっとデータが取りやすくなるのではないか、みたいな期待が高まりすぎてしまった。

多分Datastoreを流用していると思うので、あまり期待しすぎても仕方なく、ひとまず現在は現状のままどうやって使っていくかを考える必要がある。Firebaseのデータベースを使うとなると、それでうまく作り方を考える必要が出てくる。（これはこれで面白いのだが）

どちらかに限定する必要はない

そこで気づいたのが、そもそも元々RDBを使っているアプリケーションであっても、Firebaseのデータベースを併用して使えばもっと便利になるのでは、ということ。

例えばこのCrieitの例だが、先日リアルタイムで下書きをライブ公開できる機能を作成した。

編集中の内容をライブ公開できるリアルタイム投稿機能を実装しました

このサイトはGoogle Compute Engineの永久無料枠で使えるf1-microというインスタンスで動いているのだが、とにかくメモリの使用量も小さく貧弱。Laravelは一応Pusher等と連携してWebSocketを使える機能があるのでLaravel自体でもライブ公開機能は実現可能なのだが、結局状態変化があった時にデータを取得などしようとするとLaravel自体にアクセスが行ってしまう。あまりに頻度が多いと、現在のサーバーのスペックでは厳しくなる可能性がある。

その時に思い出したのがFirebaseのRealtime Databse。これは同時接続数などの制限があるものの、書き込み、読み込み等の回数には特に制限がない。つまり、制限内でライブ公開する機能を付けるのであれば、サーバーの負荷ゼロでライブ公開機能が実現できてしまう。

実際に下書き入力中の内容は特にサーバーに保存する必要がないので、入力した内容はそのままRealtime Databaseに保存し、閲覧者側はそれを受け取るだけになっており、完全にサーバー負荷も費用的な負荷もなくライブ公開の機能が作れてしまった。無料で運営している個人開発サービスとしてはこのやり方はとても相性が良い。流行りすぎて人が増えるとそうはいかなくなるが、とりあえず今の段階では全く心配はない。むしろ遊び道具が一つ増えて楽しみが増えた。

逆で、Firebaseだけで運用しているサービスにRDBの利用を追加する、ということも考えられる。RDSやCloud SQLでは費用が増えてしまうが、とりあえずHerokuのPostgres等でも良いかもしれない。Firestore側が苦手とする集計や柔軟なページングなどを行いたいデータだけ、併用して保存することで、Cloud Functions経由で簡単に集計データなどが取れたりするのではないかと思う。

まとめ

とにかく柔軟に考えて、併用することでパフォーマンス的にも費用的にもベストな形になるような状態を目指していくと面白い。