【要約】NoSQLでJOINする日が来た：Firestore Pipelines API（コレクション間JOIN）を実機で試してみた【Next '26】 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
Firestoreを利用する開発者は、NoSQL特有の構造的制約により、データの突合や集計において以下の問題に直面してきた。
- ・過剰な非正規化によるデータ整合性の維持コスト。
- ・アプリ側でのJOIN実行に伴うN+1問題と通信レイテンシの増大。
- ・分析基盤（BigQuery等）へのエクスポートに伴うETLパイプラインの構築・保守コスト。
// Approach
Google Cloudは、Firestore Enterprise editionにおいてPipelines APIを導入し、サーバー側での高度なクエリ処理を実現した。検証ではPythonを用い、以下の手法で実装を行っている。
- ・
define関数で親ドキュメントの値を変数に束縛する。 - ・
add_fields内で相関サブクエリを実行し、別コレクションの値を結合する。 - ・
aggregateを用いて、結合後のフィールドに対する集計やグルーピングを行う。
// Result
検証の結果、Pipelines APIを用いることで、従来のETLプロセスを介さずに以下の成果が得られた。
- ・「顧客別売上ランキング」等の集計を、Firestore単体で完結可能。
- ・バッチ遅延のない、ライブデータに対するリアルタイムな集計結果の取得。
- ・MongoDBのaggregationパイプラインからの移行パスの確保。
Senior Engineer Insight
> ライブデータへの直接集計は、管理画面のダッシュボード実装において極めて強力な武器となる。ETLコストを削減できる点は大きなメリットだ。ただし、相関サブクエリはスキャン量に直結し、課金増を招くリスクがある。また、マテリアライズされるデータには128 MiBの上限がある。DWHとしての利用は避け、アプリ層の軽量な運用クエリとして適用範囲を厳格に見極めるべきである。