2024/01/13
ついに2024年に突入してしまった。
フォルダ管理機能の実装を続けるなかで、Firebase Realtime Databaseについて気付いた点が２つある。
１．RealtimeDBの”クエリ”が思った以上に弱い
並び替えは降順指定すら出来ないし、並び替えとWhereによる絞り込みとが一体化しているのもとても不便。
たとえば「特定のフォルダIDを持つキャンバス一覧」を”更新日付順”で取得しようとしても出来ない。やるとすればクライアント側でソートするか、始めから絞り込み（または並び替え）したデータをDB上に持っておく必要性がある。これは不便だ。
全文検索的なことも出来ない。
そもそもNoSQL型のDBの特性という前提はありつつも、Firestoreよりもさらに不便な印象がある。
２．RealtimeDBのストレージは思った以上にシビアに考える必要性あり
Firestoreから頑張ってRealtimeDBに移行したことで、データの書き込み”回数”は気にしなくて良くなった。しかしストレージは割高だ。
開発中のidea Laneは現時点で画像をまだ扱えず、テキストのみを保存する。ユーザは私１人。なのに、消費しているデータ量が思ったより大きいことに気づいた。（下記は12月18日時点)
ストレージ使用量452KBというと数字的には大したことはないが、短いテキストの集合体だけを格納しているのにこんなにストレージを消費しているとは予想外だった。
1人で使う分には問題無い。しかし今後無償公開して1人あたり1Mも消費したら、たった1000ユーザで1Gを超えてしまう。それだけで継続的に$5の持ち出しだ。
基本無料公開して一部は有料にするつもりでいるが、それでもなるべく安くしたい。仮に有料ユーザの値段を月200円としたとき、1000人中に有料ユーザが3人居てもまだ赤字から脱却できない。（それもRealtimeDBのストレージだけで……）
さらにまずいことに、現時点では機能がとても少なく、DBへのログ反映なども付けていない。それなのに452KBも利用している。今後機能が増えれば１人あたりのデータ量が増大していくことは確実。
原因を探るためDB全体をJSON出力してみた。その結果、アイディアやレーンごとに毎回push()でIDを振っていることが大きな要因に見える。複数人同時利用に備えてわざわざこういった構造にしているのだが、思った以上にコストへ影響してしまうということか。
うーむ。。。これでは多くの人が利用すると、そこそこ費用の持ち出しになってしまうかも。
長期的な観点でコストを抑えるにはどうすれば良いか。
RealtimeDBは高いので、利用するタイミングを絞るか。例えばキャンバス編集中など頻繁にアイディアを書き込む時だけRealtimeDBを使い、作業が終わったらFirestoreに移動する…とか？（うまく出来る気はしないが）
そもそも全てのアイディアにIDを降って管理するのはコスト高だ。格納するデータを減らすか。
RealtimeDBのpushで振られるIDが大量にあり、それが容量の多くを占めていることは分かった。残念ながら桁数は20桁固定で変更出来ないようだ。やるとしたら自分で採番するしか無さそうに見える。（参考：javascript – how to generate custom push id in firebase – Stack Overflow）
そもそもアイディアごとにIDを振らなければ大幅にデータは減らせる。今の構造は、将来付けたい複数人同時編集機能に備えたものだったが、いったんそれは崩すか。そのうえで複数人同時編集をONにするユーザだけ管理方法を変えて、そこは別料金という形にするなどの方が現実的かも。
Firebase自体は無料で使い始められるし大変便利だが、たくさんの人に安く提供できるソフトを作ろうと思うと、その活用方法には気を使うことを実感。
2024/01/14～1/20
フォルダ周りの機能を中心に実装。ついにフォルダの削除も出来るようになり、これで基本的な最低限の動作は揃った。
他にはアイディアの操作感を調整したり、不具合修正などを実施。
そして「キャンバス内検索」の実装にも着手した。
※開発日記は当時の記録をもとに作成し、必要に応じて加筆・補足しています
この記事はアイディア整理ソフト「idea Lane」の開発記録です
↓どなたでも、ユーザ登録だけで無料ですぐに使えます↓
テキストベースの思考整理ツール「idea Lane」
コメント