良いポイント
Cloud FirestoreはFirebaseから簡単に使え、セットアップも早くでき、開発スピードが出るのが良い点です。
弊社は少人数のチームなのですが、DB周りの運用負担を抑えてプロダクト開発に集中できるので助かっています。この時、スキーマレスで柔軟に開発できるので、初期のプロダクト開発においてはとても良い点だと思います。
また、弊社のウェブアプリをGCP・Firebaseで運用しているので、Cloud Run Jobs/Service、Firebase Authentication、Cloud Storageなどとの相性がよく、面倒な手続きは発生しません。
改善してほしいポイント
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の回数を劇的に減らし、コストもかなりカットすることができました。
生成AI機能
0
