Firestore 料金計算：read コストの見積もりと削減

月間アクティブユーザー数だけでなく、繰り返し使われる画面から計算します。画面ごとのドキュメント数に、セッションごとの表示回数、ユーザーごとのセッション数、月間アクティブユーザー数を掛けます。write、delete、保存データ、ネットワーク転送は別に加えます。

20 件の投稿を読んだ後に投稿者、コメント、カウンターを個別取得するフィードは、画面表示数を大きく超える read を生みます。一部のクエリでは読み取ったインデックスエントリも課金対象になるため、高頻度クエリは返却ドキュメントだけでなく Query Explain で確認してください。

必要に応じて authorName、commentCount、likeCount、thumbnailUrl、lastActivityAt などの表示用フィールドを一覧ドキュメントに保存し、繰り返し取得を減らします。フィード、検索結果、管理テーブルには明確な limit を設け、1 回の操作で発生する read の上限を予測できるようにします。

ページネーションでは offset より cursor を使います。Firestore は offset で読み飛ばしたドキュメントも read として課金しますが、cursor なら最後に表示したドキュメントの次から再開できます。count()、sum()、average() は無料と仮定せず、課金されるインデックス read を見積もりに含めてください。

リアルタイム listener は、結果セットにドキュメントが追加または変更されるたびに read が課金されます。オフライン persistence と切断時間によっては、再接続時にドキュメントとインデックスを再度読み取ります。クエリ範囲を狭くし、画面が非アクティブなら購読を解除し、モバイル回線で再接続を測定してください。

計算機の通常トラフィックと高トラフィックのシナリオを、Firestore コンソールの実利用量と比較します。複雑なレポート、リレーショナルなフィルタ、頻繁な集計、複数エンティティをまたぐ管理画面が read の中心なら、Firestore のみで確定する前に Cloud SQL と比較してください。