Firebase用のNoSQLデータベース

改善してほしいポイント

Cloud Firestoreは実際にどれだけのデータを保存しているかではなく、どれだけのRead/writeをするかによって課金が増えるため、ユーザー数が増えてくると、結構コストがかかるようになります。
弊社はユーザー数の規模が数百万人レベルまで到達し、Read/writeがすごい走っていた時期がありました。従量課金モデルで、ユーザー数が増えるとコストがかかるのは仕方がないところではありますが、何とか抑えたいので、課金モデルを改善していただけたら嬉しいです。

また、Indexを貼って運用するのが前提というのがあります。ドキュメントを検索する際に、Where句が複雑になってくると（複合条件になってくると）、それだけではクエリが走らず、Indexのビルドを求められるようになります。なので、SQLの管区でクエリを書くと、意外と制約が多く、柔軟にクエリを回せないのが、痒いところです。

どのような課題解決に貢献しましたか？どのようなメリットが得られましたか？

弊社では、ウェブ系の知識管理・プロダクティビティツールをB2C向けに開発・展開しているのですが、Cloud FirestoreとCloud Storageがデータベースになっています。画像や動画、音声ファイルなどのユーザーが一度アップロードしてしまえば、変更が必要ない静的なデータはCloud Storage、テキストやユーザープロファイル、ホームフィードなど、ユーザーや外的要因によって変更が常に必要なデータはCloud Firestoreに保存しています。柔軟にとりあえず必要になりそうなデータを貯めておけるので、素早い開発が可能になっています。

プロダクト開発の最初期から使用しており、ユーザー数数百万人までは問題なく使用できています。Firebaseを導入する時に、他のCTO達からユーザー数10万人ぐらいまではFirebaseだけでいけると聞いていたのですが、実際はReadの部分をCloudflareなどでキャッシュさせることによって、Readの回数を劇的に減らし、コストもかなりカットすることができました。