FirestoreのJOINの罠
Firestoreでよくある問題に直面することがあります。Firebase関数が最大バッチサイズエラーをスローします。ダッシュボードのために、orders（注文）とcustomers（顧客）を結合（JOIN）する必要があります。通常、これを解決するためにデータを重複させますが、そうするとデータが古くなり、不整合が生じます。
Googleはこれを解決するためにPipelines APIを発表しました。これにより、データを重複させることなく、コレクション間でJOIN操作が可能になります。一部の開発者は、小規模なテストで高速なクエリ時間を報告しています。
私は高負荷環境下でこのAPIを1週間テストしました。ドキュメントには書かれていない事実をここに記します。
高額なコスト パイプラインの実行ごとに、関与するすべてのコレクションから読み取りが行われます。2つのコレクション間のJOINでは、両方のコレクションの読み取り料金が発生します。50,000件のドキュメントを持つ2つのコレクションをJOINする場合、コストは急激に増大します。単純な線形コストではありません。
パフォーマンスの限界 私のテストでは、10,000件のドキュメントに対するパイプラインは380msかかりました。100,000件のドキュメントでテストしたところ、クエリは30秒でタイムアウトしました。問題を解決しているのではなく、単にバッチエラーをタイムアウトエラーに置き換えているだけです。
コールドスタートの問題 Pipelinesは個別の実行コンテキストを作成します。Cloud Functionsのようなサーバーレス環境では、これにより2〜4秒の遅延が追加されます。ユーザーはアプリが遅いと感じるでしょう。
Pipelines APIは、プロトタイピングや5,000件未満の小規模なコレクション向けのツールです。リレーショナルデータベースの代わりになるものではありません。Googleがこれを提供しているのは、PostgreSQLやSpannerに移行するのではなく、Firebaseエコシステム内に留まるのを助けるためです。
Pipelinesを使用する場合は、以下のルールに従ってください：
• コレクションのサイズを監査する。コレクションが20,000件を超える場合は、まずJOINのコストを計算してください。 • 複雑さを制限する。3つ以上のコレクションにわたるJOINは、設計が悪い兆候です。 • 読み取りコストを毎週追跡する。Pipelinesの読み取りは、請求書に異なる形で表示されます。 • 非正規化データを保持する。Pipelinesは完全な置き換えではなく、補完として使用してください。 • 本番のトラフィックでテストする。静かなコレクションでのベンチマークは、本番環境の現実を反映していません。
真のアーキテクチャ上の決定を避けるために、その場しのぎの対策を使わないでください。
Firestoreでのリレーションシップをどのように扱っていますか？非正規化を使用していますか、それともクライアントサイドでのJOINを使用していますか？コメントで教えてください。