Firebase Realtime Databaseでいろいろやろうとしたときの悩みどころ

Otemachi-Firebase-memo.md

Otemachi Firebase #2 - connpass

先日の6/23に開催されたOtemachi Firebase #2での懇親会で話した内容を、自分なりにまとめた内容になります。

背景

現在、プライベートで「YoroOne - 商業マンガ作品宣伝ツイートまとめ」というWebサービスの企画・開発・運営を行っています。こちらはTwitter上のマンガ家さんの宣伝ツイートをまとめて見るというキュレーション系のサービスで、現在はサイトをHostingで公開し、データはRealtime Databaseを使っています。将来的にはCloud Function、Authenticationの利用も考えているのでFirebaseにどっぷり浸かった構成になっています。ある程度開発が安定してきたら次のFirebase勉強会のネタにもする予定です。 （アプリ、というかAndroid版の開発はWebの開発が落ち着くまで待機）

悩みどころ

いまはまだ実験途中のα版以前の状態ですが、将来的にこのサービスは大まかに3つのメインデータを持つことを想定しています。

• post … ツイート情報
• user … ユーザー（作者）情報
• item … 宣伝している作品情報

現状はツイート情報をメインに各情報を構成すると、だいたいこんな感じになるんじゃないでしょうか。

/
+ posts
   + post001
      + text: "つぶやき"
      + users
         + user001: true
      + items
         + item001: true
   + post002
   + post003
+ users
   + user001
      + name: "作者太郎"
      + twitter_id: "user001"
   + user002
+ items
   + item001
      + name: "テスト1巻"
      + url: "http://~~~"
   + item002
   + item003   

しかしこれだとpost（つぶやき）の一覧からユーザーと作品を見ることが前提の作りになってしまいます。最終的にはユーザーから作品、作品からつぶやきといった形の一覧を実装したい、となった場合…

+ posts
   + post001
      + text: "つぶやき"
      + users
         + user001: true
      + items
         + item001: true
   + post002
   + post003
+ users
   + user001
      + name: "作者太郎"
      + twitter_id: "user001"
      + posts
         + post001: true
         + post003: true
   + user002
+ items
   + item001
      + name: "テスト1巻"
      + url: "http://~~~"
      + users
         + user001: true
      + items
         + item001: true
   + item002
   + item003   

という形であれば、どこを基準にしてもそれぞれのアイテムに他２つの関連アイテムのKeyを保持しているので自由度は上がります。ここまでならどれか１つアイテムを追加する度に、関連する他２つのアイテムにも更新をかけるという手間はあるものの、Firebase Realtime Databaseを使っていける範疇な気がしています。

ただここから関連し、例えば作品に出版社情報を入れて出版社一覧を実装するだとか、作品や作者に「タグ情報」や「カテゴリ情報」を付け加えていくと…？ itemas:{}やusers:{}を入れる部分が膨れ上がりすぎてしまい、リレーショナルでないことが逆に災いしてしまい、データの管理がかなり難しくなってしまうのでは…？　という不安や悩みどころがありました。

リレーショナルデータベースとFirebase Realtime Databaseとの共存

ということで今日の勉強会でちょうどその辺りの質問ができそうな方がいたので、極端な例として「例えば◯ックパッドをFirebase Realtime Databaseで実装するのって可能だと思いますか？」と投げてみましたが、やはりというか答えは「クッ◯パッドのような構成のサービスには向かない」という回答でした。まあ、それもそうだろうなあと。

その後も他の発表者やオーディエンスの方ともその話題ばかりしていたのですが、やはり多くのデータがリレーショナルになってしまうような構造はリレーショナル・データベースでやるべきじゃないか、Realtime Databaseの本来の強みは「Realtime」であるところだし、そこが活きるわけでもなくむしろ他の要素（関連するデータを一気に取り出すだとか、高速な検索だとか）が重要な場所は、別のモノを使って担保していくべきだろうという結論で落ち着きました。本当にこの辺りは「いや実は自分の知識が足りないだけで、Realtime Databaseで十分なことが大半じゃないのか」という不安が払拭されたので安心しました。

となると次に出て来る悩みどころとしては、たとえば実際にRealtime DatabaseとRDB（リレーショナル・データベース）を共存させていく際、両者のデータの同期をどうやって実装していくかという話になっていくかと思うのですが、まだ自分がその状況に突入するのは早くても３ヶ月以上は先だと思うので、先人達の実務の知恵がどんどんインターネット上にアウトプットされていってほしいなあと思いました。