50万件の一覧を25件ずつ送るとき、「何件目から」で指定すると合計50億件を読むことになりました。
「続きの目印」なら50万件です。10001倍の差が、指定の仕方だけで生まれます。
問い合わせで絞れます。ただし送り方の指定によって、読む件数が桁で変わります。
Firebaseの文書の置き場では、条件で絞って取り出せます。公式はCloud Firestoreでは、個々の特定の文書を取り出したり、条件に合う集まりの中の文書をすべて取り出したりするために、問い合わせを使えると述べています。
取り出し方は1つではありません。送り方を変えて実際に数えて比べました。
一覧 500,000件を 25件ずつ送る
「何件目から」で指定する場合と、「続きの目印」で指定する場合を比べる
ページ 何件目からで指定（読む件数） 続きの目印で指定（読む件数） 比
1ページ目 25件 25件 1倍
10ページ目 250件 25件 10倍
100ページ目 2,500件 25件 100倍
1000ページ目 25,000件 25件 1000倍
4000ページ目 100,000件 25件 4000倍
1ページ目はどちらも25件です。差が出るのは後ろのページでした。
1000ページ目では25,000件を読みます。飛ばす分もいったん数える必要があるためです。
最後まで送りきった場合の合計 何件目からで指定 5,000,250,000件 続きの目印で指定 500,000件 比 10001倍
合計では10001倍です。50万件の一覧を送るのに、50億件を読むことになります。
続きの目印で送れば、何ページ目でも25件です。合計もちょうど50万件で済みます。
この形はデータベース設計の記事でも扱っていて、件数が増えたときに初めて表面化します。
後ろのページほど、読む件数が増え続ける。
In Cloud Firestore, you can use queries to retrieve individual, specific documents or to retrieve all the documents in a collection that match your query parameters.原文Firebase 公式ドキュメント「Cloud Firestore」 この内容の有効期限2027-02-18
入れ子でも下位の集まりでも持てます。入れ子は読みやすい代わりに、書き直しが増えます。
Firebaseの文書は、入れ子の対象を持てます。公式は文書は、下位の集まりに加えて、入り組んだ入れ子の対象を含められると述べています。
どちらで持つかで書く量が変わります。実際に数えて比べました。
親の文書は 400バイト。子を入れ子で持つ場合と、別の集まりに置く場合を比べる
子は1件 60バイト
子の数 入れ子で持つ（1件の大きさ） 子を1件足すのに書く量 別に置く場合に書く量 比
0件 400バイト 460バイト 60バイト 8倍
10件 1,000バイト 1,060バイト 60バイト 18倍
100件 6,400バイト 6,460バイト 60バイト 108倍
1,000件 60,400バイト 60,460バイト 60バイト 1008倍
5,000件 300,400バイト 300,460バイト 60バイト 5008倍
子が10件までなら18倍です。この範囲なら気にする必要はありません。
1,000件になると1008倍です。60バイトを足すために60,460バイトを書きます。
分かれ目は、子の数が上限を持つかどうかです。決まった数なら入れ子で構いません。
履歴や書き込みのように増え続けるものは、下位の集まりに置きます。そうすれば書く量は60バイトのままです。
代わりに、親と一緒に読むには追加の読み取りが要ります。読む回数と書く量の取り替えになります。
Documents can contain complex nested objects in addition to subcollections.原文Firebase 公式ドキュメント「Cloud Firestore」 この内容の有効期限2027-02-18
文書を集まりへまとめる形です。件数を知りたいだけでも、読む必要が出てきます。
Firebaseでは、文書を集まりへまとめて置きます。公式はデータは文書として置き、集まりへまとめると述べています。
この形では、件数を知るのに全部読むことになります。どれだけかかるのか実際に数えてみました。
件数を知る2つのやり方を比べる
件数 ぜんぶ読んで数える 別に数を持っておく
1,000件 1.2ms（1,000件読む） 0.0ms（1件読む）
100,000件 120.0ms（100,000件読む） 0.0ms（1件読む）
10,000,000件 12000.0ms（10,000,000件読む） 0.0ms（1件読む）
1,000件なら1.2msで済みます。この規模では問題になりません。
1000万件では12000.0msです。画面に数字を1つ出すために12秒かかることになります。
別に数を持つ場合、その1件に書き込みが集中する 1秒あたりの更新 1個に分ける 10個に分ける 100個に分ける 1回/秒 1.0回/秒 0.1回/秒 0.0回/秒 10回/秒 10.0回/秒 1.0回/秒 0.1回/秒 100回/秒 100.0回/秒 10.0回/秒 1.0回/秒 1000回/秒 1000.0回/秒 100.0回/秒 10.0回/秒
数を1件で持つと、更新がそのままその1件に集まります。毎秒1000回なら1000回/秒です。
100個に分ければ10.0回/秒まで下がります。読むときは100件を足すことになります。
3つの計測はいずれも手元で書いた模型で、実際のCloud Firestoreを叩いたものではありません。1件1.2マイクロ秒や1件60バイトといった値は置いたもので、実際の課金の単位や速度とは違います。件数を数える専用の手段が用意されている場合、この表よりずっと速くなります。「何件目から」の読み取り件数も、実装によっては途中を飛ばせることがあります。ここで見せているのは、送り方の指定だけで読む件数が桁で変わるという点と、増え続けるものを入れ子で持つと書く量が比例して増えるという点の2つです。
Store your data in documents, organized into collections.原文Firebase 公式ドキュメント「Cloud Firestore」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る