Firestore ネイティブ モードの概要

Firestore ネイティブ モードは、Firestore Core オペレーションと Firestore Pipeline オペレーションの 2 つのオペレーション セットで構成されています。

Firestore Core オペレーションは、標準のドキュメントの作成、読み取り、更新、削除(CRUD)機能と、リアルタイム リッスン クエリとオフライン永続性の組み込みサポートを提供します。このエディションの大きな違いは、インデックスが省略可能で、単一フィールドに対して自動的に作成されないことです。これにより、インデックスを事前に構成しなくてもクエリを実行できますが、インデックスが作成されていないクエリはデフォルトでコレクション全体をスキャンします。データセットの増加に伴い、レイテンシと費用が増加する可能性があります。

Firestore Pipeline オペレーションは、Firestore Enterprise エディションの中心的な機能です。高度なクエリエンジン上に構築されており、可能なクエリの範囲を大幅に拡大します。Firestore Pipeline オペレーションでは、柔軟なクエリ構文と独自のインデックス登録方法が採用されています。インデックスは省略可能で、自動的に作成されません。これにより、アプリケーションの高度なデータ取得オペレーションが可能になります。

Firestore Core オペレーションの機能

Core オペレーションでは、標準の CRUD オペレーションとリアルタイム リッスン クエリが可能です。ただし、Enterprise エディションでこれらのオペレーションを使用する場合、インデックス登録と課金に関する基盤となる動作は Standard エディションと比較して大幅に異なります。

機能と継続性

コア オペレーションでは、Standard エディションで使用されるメソッド チェーン構文(.where().orderBy() など)が保持されます。これらのオペレーションは、モバイル クライアントとウェブ クライアントのリアルタイム リッスン クエリとオフライン永続性をサポートします。これらのオペレーションは、標準のトランザクション ワークロード、単純なルックアップ、既存のアプリケーション コードの移行に使用することをおすすめします。

カスタム インデックス

Standard エディションとは異なり、Enterprise エディションの Core オペレーションでは、単一フィールド インデックスは自動的に作成されません。インデックスは省略可能であり、クエリの実行に必須ではありません。特定のインデックスがない場合、クエリはコレクションのフルスキャンを実行します。インデックスなしのクエリを使用すると、迅速なプロトタイピングが可能になりますが、データセットの増加に伴ってパフォーマンスが低下し、コストが増加する可能性があります。デベロッパーは、クエリのパフォーマンスを最適化し、読み取りユニットの使用量を削減するために、インデックスを手動で作成する必要があります。

課金モデル(ユニットベース)

読み取りユニットは、ドキュメント数ではなく 4 KB トランシェで課金されます。大規模なコレクションをスキャンするインデックスなしクエリは、すべてのドキュメントでスキャンされた合計バイト数に基づいて読み取りユニットを消費します。書き込みユニットは 1 KB トランシェで課金されます。ドキュメントの書き込みでは、データのユニットと、更新されたインデックス エントリごとの追加ユニットが消費されます。自動単一フィールド インデックス作成が強制される Standard エディションとは異なり、書き込みコストとパフォーマンスを最適化するために、インデックスを作成する特定のフィールドを選択できるようになりました。

Firestore Pipeline オペレーションの機能

Pipeline オペレーションを備えた Firestore Enterprise エディションでは、Firestore Standard エディションの既存の制限の多くが解消された高度なクエリ エンジンが使用されます。Firestore Pipeline オペレーションには、数百もの追加のクエリ機能が用意されています。Firestore Pipeline オペレーションには次の機能があります。

ステージベースのコンポーズ可能な構文

Pipeline クエリは、順番に実行される一連の連続したステージを定義することで構築されます。これにより、以前は不可能だった集計結果のフィルタリングなどの複雑なオペレーションが可能になります。

次の例は、過去 1 か月間に閲覧された一意のプロダクト ID の数を取得するパイプライン クエリを示しています。

guard let cutoffDate = Calendar.current.date(byAdding: .month, value: -1, to: Date()) else {
  return
}
let snapshot = try await db.pipeline()
  .collection("productViews")
  .where(Field("viewedAt").greaterThan(cutoffDate.timeIntervalSince1970))
  .aggregate([Field("productId").countDistinct().as("uniqueProductViews")])
  .execute()

拡張機能

Pipeline クエリには、次のような多くの新機能が導入されています。

  • 集計: 新しい集計関数(sum(...)min(...)count_distinct(...) など)と任意のグループ化フィールドの組み合わせをサポート。
  • 複雑なフィルタリング: regex_match(...)add(...)str_contains(...) など、任意の複雑な where(...) ステートメントを表現するための数百の追加関数をサポート。すべてハード インデックス要件なし。
  • 部分読み取り / 投影: select(...)remove_fields(...)、その他の多くのドキュメント操作ステージを使用して、ドキュメントの動的サブセットを取得。

これらの機能の詳細については、パイプライン オペレーションでデータをクエリするをご覧ください。

リアルタイムおよびオフライン サポート

リアルタイムとオフラインを利用するために、デベロッパーは Firestore Enterprise エディションで Firestore Core オペレーションを使用できます。

クライアントとツールの統合

Enterprise エディションには、Pipeline クエリを操作して管理するための特別な機能が含まれています。

  • クエリの説明とプロファイリング: Query Explain の結果を使用して、クエリが消費する読み取りまたは書き込みのユニットの数を把握し、その実行を分析できます。
  • Query Insights: Enterprise エディションは Query Insights をサポートしています。Query Insights は、データベースで実行される上位のクエリとそのパフォーマンス特性を可視化することで、パフォーマンスと費用を改善するには、どこにインデックスを作成すればよいかを特定するのに役立ちます。
  • 新しいインデックス タイプ: スパース インデックス、非スパース インデックス、一意インデックスなどのインデックス タイプを含む、Enterprise エディション専用のインデックスを作成できます。また、Enterprise データベースのベクトル検索インデックスを作成、編集することもできます。

Firestore Standard と Firestore Enterprise の違い

Core オペレーションと Pipeline オペレーションの主な運用上の違いは、インデックス作成の管理にあります。これは、パフォーマンスと費用に直接影響します。

Firestore Standard - Core オペレーション Firestore Enterprise - Core オペレーションと Pipeline オペレーション
インデックス作成の要件 クエリにはインデックスが必要です。

個々のフィールドのインデックスは自動的に作成されますが、より複雑なクエリでは、手動で構成する必要がある複合インデックスやコレクション グループ インデックスが使用されます。

インデックスは必須ではないため、クエリでは省略可能です。

必要に応じてインデックスを定義します。Enterprise エディションでは、非スパース インデックス、スパース インデックス、一意インデックスなど、より広範なインデックス タイプもサポートしています。

パフォーマンス インデックス付きクエリ: パフォーマンスと費用は、結果セットのサイズに応じてスケーリングされます。

インデックスなしクエリ: パフォーマンスとコストは、データセットのサイズに応じてスケーリングされます。

インデックス付きクエリ: パフォーマンスと費用は、結果セットのサイズに応じてスケーリングされます。

Query Explain ツールと Query Insights ツールを使用してインデックスを作成し、クエリのパフォーマンスと費用を改善することをおすすめします。

ストレージ費用の影響 自動インデックスと複合インデックスからストレージ オーバーヘッドが発生します。 すべてのフィールドに対してインデックスが自動的に作成されないため、ストレージ費用を節約できます。
費用ベース ドキュメントの読み取り書き込み削除のオペレーションごとに課金されます。 読み取りユニット(4 KB トランシェ)と書き込みユニット(1 KB トランシェ)ごとに課金されます。インデックス エントリの書き込みでは、書き込みユニットが消費されます。

を参考に、新しい料金設定についてご確認ください。

セキュリティ ルール セキュリティ ルールは、読み取り / 書き込み権限を検証してコレクションを保護します。 セキュリティ ルールは、読み取り / 書き込み権限を検証してコレクションを保護します。データモデル ガイドで、パイプライン クエリをサポートするようにデータをモデル化する方法を確認します。