TOP(About this memo)) > 一覧(Firestore) > 制限と課金
使用量と上限
ストレージサイズの計算
- https://firebase.google.com/docs/firestore/storage-size?hl=ja
- 文字列のサイズは、UTF-8 でエンコードされたバイト数 + 1 の値として計算される。
- 文字列は、コレクション ID、文字列ドキュメント ID、ドキュメント名、フィールド名、文字列フィールドの値 に使われる。
- 例: コレクション IDのtasks には、5 バイト + 1 バイト、合計 6 バイトが使用される。
- ざっくり、日本語は3バイト、ASCII文字は1バイト
- ドキュメント ID
- 文字列 ID の場合は文字列のサイズ、整数 ID の場合は 8 バイト
- Cloud Firestore クライアント ライブラリは常に文字列ドキュメント ID を使用。
- ドキュメントサイズは下記で決まる
- ドキュメント名のサイズ
- ドキュメントのパスにある各コレクション ID およびドキュメント ID のサイズ
- 追加の 16 バイト
- 例) users/jeff/tasks なら、 6 + 5 + 6 + 11 + 16 = 44 バイト
- 各フィールド名の文字列サイズの合計
- 各フィールド値のサイズの合計
- 追加の 32 バイト
- IMO: ケーススタディ
- フレンドのデータとしてユーザーのuidを配列に格納したとしたら、何件までいれられる？
- 1MiB(1,048,567) / uidの文字(28文字のため29バイト) = 36157くらい。
- したがって、配列以外の要素を差し引いても、36000件くらいはマックスで入る感じ?
費用のアラート
モニタリング
- https://firebase.google.com/docs/firestore/monitor-usage?hl=ja
- ダッシュボード
- Google Cloud Platform Console と Firebase コンソールの両方でFirestoreのダッシュボードが見れる。
- 使用状況の予想が表示される。課金対象のオペレーションは正確には表示されない。
- 一致しない場合は、請求レポートが使用状況ダッシュボードよりも優先。
- 、Firebase コンソールにはセキュリティ ルールの評価ダッシュボードが用意され、ルール呼び出しを一目で確認できる。
- GCP Console の [App Engine の割り当て] ページでは、読み取り、書き込み、インデックス書き込み、削除、保存データ、ネットワーク下り（外向き）など、日々の Cloud Firestore の使用状況に関する情報が追跡される。
- Cloud Monitoring
- Cloud Monitoring は、Google Cloud プロダクトから指標、イベント、メタデータを収集する。
- Cloud Firestore コンソールの使用状況ダッシュボードにも同じ指標データが表示される。
- カスタム ダッシュボードと使用状況アラートを設定するには、Cloud Monitoring を使用
課金
課金対象
- 読み取り、書き込み、削除を行うドキュメントの数。
- 例えば東京ロケーションの場合は下記。（執筆当時)
- ドキュメント 100,000 点あたり $0.038、$0.115、$0.013（読み取り、書き込み、削除）
- 書き込みが読み取りの3倍くらい。削除は読み取りの3分の1くらい
- ドキュメント 100,000 点あたり $0.115/GiB/月（保存データ）
- set オペレーションまたは update オペレーションを実行するたびに書き込み 1 件としてカウント
- クエリの結果をリッスンする場合、結果セット内のドキュメントを追加または更新するたびに、1 回の読み取りとして課金。
- ドキュメントに変更があったために結果セットから除外される場合も、1 回の読み取りとして課金
- 一方、ドキュメントが削除される場合、こちらは読み取りとして課金されない。
- 変更があったときは、リッスンしている対象全部ではなく「変更があった箇所のみ」という認識であっている？
- オフラインの永続性
オフラインの永続性が有効で、リスナーが 30 分以上切断された場合（たとえばユーザーがオフラインになった場合）、新しいクエリを発行した場合と同様に読み取り料金が課金される。
- リスナーが有効な状態で、30分以上切断された状況になると、1回分の読み取り料金分として課金される、という理解であっている？
- オフセットを含むクエリを送信すると、スキップされるドキュメントごとに読み取り料金が課金。
- コレクション ID リストのリクエストなど、ドキュメントの読み取り以外のクエリは 1 回のドキュメント読み取りとして課金
- クエリが結果を返さない場合でも、実行するクエリごとに 1 回の読み取り分の最小費用が発生
- exists()、get()、getAfter() を使用して 1 つ以上のドキュメントをデータベースから読み取ると、以下のように追加の読み取り料金が課金
- ルールの評価は、リクエストごとに 1 回のみ課金。ドキュメントを 1 つずつ読み取るよりも複数ドキュメントを一度に読み取る方が、必要となるリクエスト数が少なくなり、最終的なコストが低くなる可能性がある。
- クエリの結果をリッスンする場合、クエリの発行、クエリ結果の更新ごとなどに課金される。
- 集約クエリにより照合されたインデックス エントリの数。
- 容量には、メタデータ、自動インデックス、および複合インデックスが含まれる。
- データベースにより使用されるストレージの容量
- ネットワーク帯域幅の使用量
- 課金はすべて日単位で発生
課金の具体例