Cloud Firestoreのインデックスの種類
Cloud Firestoreには2種類のインデックスがあります。
2種類といってもどっちも同じインデックスで、データ取得を効率化するという基本的性質は変わりません。
この2つで違うのは自動でインデックスされるかどうかだけです。
- 単一フィールドインデックス
- 複合インデックス
自動でつけてくれる単一フィールドインデックス
フィールドとはドキュメント内のキーのことを指します。Cloud Firestoreは基本的にこのフィールド全てに自動でインデックスをつけてくれます。
インデックス管理を減らして開発に専念してもらうのがCloud Firestoreに思想みたいですね。インデックスがどうつけられるか下記にまとめました。
- 配列とマップを覗くフィールド全てに昇順と降順のインデックスを自動でつける
- ドキュメント内のマップに対しては、マップの中の配列でもマップでもないサブフィールドに昇順と降順のインデックスを自動でつける
- ドキュメント内の配列に対しては、要素に対してインデックスがつけられる。配列の中まで検索できる。
こんなに自動でインデックスをつけてくれる逆に大丈夫かな?と不安になりますね。
実際、検索に使用しないフィールドに大量のデータがある場合はインデックスを意図的に外さないとデータ量がかかってしまうので注意が必要です。
複合インデックス
複合インデックスはMySQLなどのRDBと同じで複数のフィールドに対してwhere句で検索したり、whereで検索したフィールドとは別フィールドでorderByで並び替えを行うときに必要になります。
Cloud Firestoreの場合、複合インデックスをつけていない検索クエリはエラーで失敗するようになっています。インデックスを全く管理しなくて言い訳ではなく管理の手間を省けるという感じですね。
MySQLの場合、インデックスがなくてもクエリを発行してDBに負荷をかけてしまうことがあるのここは大きな違いですね。
インデックスと価格
インデックスの数ではなくてインデックスで増えるデータがストレージを使うので、ストレージ使用量に対して課金されるみたいです。
データ量の計算は複雑なのでこちらをご覧ください。
インデックスマージで価格を安く抑える
Cloud Firestoreにはインデックスマージという機能があります。
これは複数のフィールドに対する等式句(where A = a and B = b、 where B = b and C = c)またはoderbyによる並び変えの場合、複合インデックス(AとB、BとCの複合インデックス)を使わずにインデックスのデータ量を削減することができます。
上記例の場合、A、B、Cに単一フィールドインデックスをつけるだけで効率的にインデックスを使って取得することができます。
インデックスの数とデータ量の制限
データベースとドキュメントに対するインデックスの数とデータ量はきっちり決まっています。
よっぽど一つのドキュメントに大量のフィールドを設定しなければ問題ないです。例えばフィールドが1万個のドキュメントの場合、インデックスエントリの最大数に達します。
検索に使用しないフィールドが多かったり、フィールドに大きいデータを入れている場合はそのフィールドにインデックスをつけない設定をしてデータ量を節約できるので試してみてください。

公式ドキュメント
髙妻智一
最新記事 by 髙妻智一 (全て見る)
- Polkadot(Substrate)のアドレスとトランザクションについて - 2023-03-09
- 【無料公開】「Goで始めるBitcoin」3章 Bitcoinノードとの通信 技術書典8 - 2020-03-08
- エンジニアがゼロから技術ブログを書くための方法をまとめました - 2019-05-25
コメントを残す