Firestore Enterprise Editionのクエリを徹底解説！パフォーマンスと柔軟性を最大化するインデックス戦略

データベースにおいて、構造化されたデータをクエリできることは、それが「データベース」である理由の根幹をなします。例えばFirebase Cloud Storageのような製品とは異なり、データを効率的に検索し、活用できることが重要です。本記事では、Firestore Enterprise Editionにおけるクエリ機能に焦点を当て、その拡張された機能、パフォーマンスへの影響、そして柔軟なアプリケーションアーキテクチャを実現する方法について詳しく解説します。

FirestoreにはStandard EditionとEnterprise Editionの2つのエディションがあります。Standard Editionのクエリについては既にご存知の方もいらっしゃるかもしれませんが、Enterprise Editionでは新たなクエリ機能が追加されており、より優れたパフォーマンスと柔軟なアプリケーションアーキテクチャが可能になります。この解説を通して、Enterprise Editionを実際に利用する前に、その直感的な理解を深めていただければ幸いです。

Firestoreのデータモデルの基礎

まず、Firestoreがデータをどのように保存・整理しているかについて説明します。Enterprise Editionのデータモデルは、Standard Editionから一切変更されていません。したがって、Firestoreのベテランユーザーであれば、このセクションをスキップしてインデックスに関するセクションに進んでいただいても問題ありません。Firestore初心者の方は、ぜひこのままお読みください。

Firestoreはドキュメントデータベースです。リレーショナルデータベースにおける古典的な「行とテーブル」とは異なり、FirestoreはJSON互換のドキュメントにデータを保存します。これらのドキュメントには、オブジェクトにマップされた名前付きフィールドが含まれています。

ドキュメントはコレクションの中に格納されます。コレクションとは、その名前が示す通り、ドキュメントの集まりです。コレクションはドキュメントの下にネストすることも可能です。Firestoreのクエリは、ドキュメントをフェッチする際にサブコレクションをフェッチしない、という特性を持っています。これは、コレクションが無制限の数のドキュメントを含む可能性があるため、非常に良い点です。

コレクションをクエリする際に明示的に順序を指定しない場合、返されるドキュメントの順序は保証されません。これについては後ほど詳しく説明します。また、コレクションは異種混合であることも可能です。つまり、コレクション内のすべてのドキュメントが同一のフィールドを持つ必要はありません。

データ読み込みとパフォーマンスの鍵：インデックス

データの基本的な構造を理解したところで、実際にデータをどのように読み込み、そして高速化するのかという「楽しい部分」に進みましょう。データの読み込みは、クエリを通じて行われます。最も基本的なレベルでは、クエリはデータベースから受け取りたいデータを記述するだけであり、データベースがそれを取得してくれます。

しかし、実際にデータの取得はどのように行われるのでしょうか？データベースは、巨大なforループですべてのドキュメントを検索するだけなのでしょうか？そこで登場するのがインデックスです。

インデックスは、特定のクエリに対して関連するドキュメントを簡単に見つけられるように、ドキュメントデータを格納する補助的な構造です。Standard EditionとEnterprise Editionの両方で、Firestoreはオーダー型単一フィールドインデックスを広範に利用しています。これらは、特定のドキュメントの単一フィールドを順序付けして格納するインデックスです。そのため、「オーダー型単一フィールドインデックス」と呼ばれます。

さらに、Firestoreでは、複数のフィールドのデータを単一の順序付きインデックスに結合するインデックスを作成することも可能です。これは、複数のフィールドにわたる一致する値に基づいてコレクション内のドキュメントをフィルタリングする場合に役立ちます。例えば、「評価順、次に名前順に並べられたすべてのレシピをください」といったクエリに対応できます。

また、Firestoreはコレクション グループ インデックスも提供しています。これらは、類似の名前を持つ複数のコレクションを、コレクション グループと呼ばれる単一のクエリ可能な構造に結合するインデックスです。これはコレクション グループ名によって行われるため、サブコレクションの名前には注意を払う必要があります。

まとめると、Firestoreのインデックスとは、ドキュメントIDにマップされたフィールドデータの順序付きリストであると言えます。

Standard EditionとEnterprise Editionのクエリ能力の比較

Standard EditionとEnterprise Editionは同じ種類のインデックスを使用しますが、Enterprise Editionはコレクション内のすべてのドキュメントをスキャンしてクエリを実行するコレクション スキャンが可能です。また、Firestoreは、同じコレクションに対してインデックスのスキャンとドキュメントのルックアップを組み合わせることもできます。これらはパフォーマンスに大きな影響を与えます。

Standard EditionとEnterprise Editionの主な違いは以下の通りです。

• Standard Edition: すべてのドキュメントフィールドに対して自動的にインデックスを作成します。しかし、既存のインデックスを使用して実行できるクエリのみをサポートします。
• Enterprise Edition: デフォルトではインデックスを一切作成しません。その代わり、すべてのクエリにインデックスを使用する必要もありません。これにより、あらゆる種類のクエリを実行できる柔軟性が得られるとともに、データベースのストレージ、書き込み、読み込みのパフォーマンスをより細かく管理できるようになります。

Enterprise Editionでは、最終的にインデックスを作成しないフィールドに関するストレージコストを削減できる傾向があります。また、Firestoreがそれらの単一フィールドインデックスをすべて最新の状態に保つ必要がないため、多くのフィールドを持つドキュメントの書き込みレイテンシと書き込みパフォーマンスのスケーリングが大幅に向上します。しかし、これはクエリについて少し異なる考え方をすることを求められます。

コア操作クエリの詳細

Standard Editionで利用可能なFirestoreクエリ、すなわちコア操作についておさらいし、その後Enterprise Editionについて見ていきましょう。詳細に入る前に、いくつかの用語を説明します。

コア操作とは、Firestore Standard Editionで利用可能なあらゆる種類の読み取りまたは書き込み操作を指す総称です。読み取りについて言えば、これはSDKのクエリAPI（queryメソッド）を使用して記述できるすべてのクエリを意味します。これらはFirestore Enterprise Editionでも利用可能ですが、Enterprise Editionでは異なるクエリ解決戦略が採用される場合があります。

本シリーズはクエリに焦点を当てているため、ここでは「コア操作」を読み取り操作のみを指すものとして使用します。コア操作クエリは、インデックスが作成されたコレクションに対して実行できるクエリです。つまり、インデックスを作成すれば、クエリは常に高速になります。

Standard Editionデータベースに対して実行されるクエリは常にインデックスを使用して実行されます。Enterprise Editionでは、利用可能なインデックスがあればそれを利用し、なければコレクション スキャンにフォールバックします。

Standard Editionのクエリ戦略

Standard Editionでは、Firestoreは一般的にいくつかのバリエーションはあるものの、同じ戦略を使用します。

1. インデックスの特定: クエリのコレクションと、ソートやフィルターの指定に基づいて、クエリをサポートするインデックスを特定します。
2. インデックスの走査: スキャンを開始できる最初のエントリを見つけるまでインデックスを走査します。インデックス内の順序付けにより、このステップは高速に保たれます。
3. ドキュメントのスキャン: 最後に、インデックスエントリをスキャンして、返すべきドキュメントを見つけます。スキャン方法はクエリのニーズによって異なりますが、クエリによって返される必要のあるすべてのドキュメントを常にスキャンします。

この理由から、クエリのパフォーマンスはコレクションのサイズではなく、返されるドキュメントセットのサイズに比例してスケーリングします。これは、Standard Editionで任意のクエリを実行するには、そのクエリの結果が、そのクエリをサポートするために使用されるインデックス内で明確に定義された上限と下限内に収まっている必要があることを意味します。

たとえば、単純な順序付きフェッチの場合、Firestoreはすべてのインデックスエントリを順序通りにスキャンするだけです。一方、制限付きの複数順序付けのようなより複雑なクエリの場合、Firestoreはインデックス内の上限と下限を決定し、その範囲内をスキャンしてクエリに一致しないドキュメントをスキップすることができます。

集計機能 (Count, Sum, Average)

「Count（数）」「Sum（合計）」「Average（平均）」といった集計はどうなるのでしょうか？これらの単純な集計は、ドキュメントを読み込むのではなく、インデックスをイテレートすることによって計算されます。なぜなら、これらのインデックスには、合計、平均、数を計算するために必要なすべての情報が含まれているからです。コレクション内のドキュメント数をカウントすることは特殊なケースです。技術的にはインデックスデータは一切必要なく、インデックスのサイズがコレクションのサイズと同じであることだけが必要です。

コア操作クエリの強力な機能

インデックスを持つことがかなり大きな制約に聞こえるかもしれませんが、コア操作クエリは依然として強力です。以下の機能を提供します。

• 1つのフィールドに対するあらゆるソートまたはフィルタリング
• 複数のフィールドに対する任意の数の等価フィルタリング
• 複合インデックスの助けを借りて、複数のフィールドに対する範囲フィルタリング

返されるドキュメントの順序は、インデックス内の順序に依存します。そのため、複数フィールドのインデックスを作成する際には、昇順または降順のどちらでエントリを希望するかをFirestoreに尋ねられることになります。

まとめ

本記事では、Firestore Enterprise Editionのクエリ機能に焦点を当て、その基盤となるデータモデル、インデックスの重要性、そしてStandard Editionとの決定的な違いを解説しました。Enterprise Editionは、デフォルトでインデックスを強制しないコレクション スキャン機能や、インデックス管理の柔軟性により、より高度なクエリ要件やパフォーマンスチューニングに対応できる強力なツールです。特に、ストレージコストの削減や書き込みパフォーマンスの向上が期待できるため、大規模なアプリケーションや特定のパフォーマンス要件を持つプロジェクトにおいて、Enterprise Editionの導入は大きなメリットをもたらすでしょう。

この解説が、Firestore Enterprise Editionのクエリ機能に対する理解を深め、皆様のプロジェクトにおけるデータ管理とパフォーマンス最適化の一助となれば幸いです。

参考動画

• Queries on Firestore Enterprise Edition: https://www.youtube.com/watch?v=t7HDqt1jtW8