1 つの SQL ステートメント すべてのデータベース.
注文データはMySQLに保存されています。顧客データはPostgreSQLに保存されています。皆が議論している目標値は、本社にあるSQL Serverサーバーに保存されています。 フェデレーションクエリ 普通の文章を書くことができます セレクト これは3つのファイルすべてを一度に読み込み、1つのテーブルとして出力します。エクスポートもコピーも不要で、ファイアウォール上で新たに開く必要もありません。
On every plan, including Free · Free runs 2 sources and 250 result rows — the ceilings grow with your tier
38 データベースコネクタ - 任意の組み合わせで、それらの間で結合できます
クエリ ストリームでは、それらに加えて次のものが表示されます。 8 APIコネクタは、同じSQLでクエリされます。
53 ソースの総数。API コネクタは他のすべてと同様に SQL でクエリされ、フェデレーション ステートメントが結合されます。 データベース つながり。 APIコネクタを参照してください
テーブルの前に接続名を記述してください
これがこのページにおける唯一の新しいアイデアです。以下にハイライト表示されている各名前は、それぞれ異なる場所に存在する異なるデータベースであり、異なるネットワークエージェントによってアクセスされますが、それでもクエリは1つです。
-- 1つのフェデレーションクエリ · どこにもコピーされません
セレクト c.領域、
カウント(*) AS 注文、
合計(o.total) AS 収益、t.ターゲット
フロム mysql_prod.shop.orders1 o
ジョイン pg_crm.一般顧客2 c オン c.id = o.customer_id
ジョイン mssql_erp.dbo.region_targets3 t オン t.region = c.region
どこ o.placed_at >= 日付 '2026-07-01'
GROUP BY c.領域、t.ターゲット
ORDER BY 収益 DESC;mysql_prod, pg_crm そして mssql_erp これらは単にあなたが自分のつながりに付けた名前です。3つの部分は 接続、スキーマ、テーブルこれは人々が言うところの 連合データベース3つの独立したデータベースが1つの質問に答えており、何も統合も移動もされていません。これは例示的なスキーマです。実際のテーブルは、お客様のテーブルになります。
各名前が解決される場所
mysql_prod
MySQL · shop.orders
クラウドエージェント
7月のみに絞り込み、その後、顧客一人当たりの収益を合計してから、何も送信します。
pg_crm
PostgreSQL · public.customers
地域代理店
クエリ名に含まれるのは、idとregionの2つの列のみです。
mssql_erp
SQL Server · dbo.region_targets
本社代理店
地域ごとにターゲットを渡す。ネイティブに実行できるようにT-SQLで記述されている。
3人のエージェント、3つのネットワーク、1つの声明――しかし、そのどれもがそれを実行するためだけにポートを開放することはなかった。
露出を増やすのではなく、リーチを増やす。
2つのデータベースを同時に読み込む場合、1つのデータベースを読み込む場合と全く同じ経路が使用されます。そのため、新たにデータベースを開く必要はありません。
発信専用
エージェントはQuery Streamsへの暗号化された接続を1つ開き、リクエストと結果の両方をその接続経由で送信します。受信ポートもVPNもファイアウォールの変更も不要で、認証情報がネットワーク外に持ち出されることはありません。
読み取り専用、すべての
クエリの各要素は、送信される前に必ずチェックされます。 セレクト, と そして 説明する フェデレーションクエリは、お客様のデータベースに書き込むことはできません。また、拒否されたデータは、お客様のデータベースに一切届きません。
それはあなたのサーバーと共に逃げることはできません
1 つのデータベースが単一のクエリで渡せるデータ量には上限があり、エージェントはその上限に達した瞬間に停止します。 どこ その条項によって発生するコストはエラーメッセージだけで、半日を無駄にすることはない。
3つのステップがあり、そのどれもがデータパイプラインではない。
つながりを選びましょう
チームが既に設定済みの接続を2つ以上選択してください。最低でも2つ必要です。2つ以上選択することで、クエリがフェデレーションされます。何もコピーされず、新しいパスワードも作成されません。
1つの文を書いてください
各テーブルに名前を付ける 接続スキーマテーブル次に、通常のSQL文を記述します。実行前に実行プランを確認することで、どのデータベースにどのようなクエリが送信されているかを把握できます。または、クエリを記述してNovaに実行プランを作成させることも可能です。
他のクエリと同様に保存してください。
一度正常に動作すれば、それは保存されたクエリとなるため、共有したり、フィルターを適用したり、週次レポートとして送信したり、APIエンドポイントとして公開したり、スプレッドシートに取り込んだりすることができます。
各データベースはそれぞれ独自の役割を担う
2つのデータベースを結合する手っ取り早い方法は、両方のテーブルをネットワーク経由でドラッグして、後で整理することです。しかし、これは時間がかかり、必要なデータ量よりもはるかに多くのデータが外部に流出することになります。
そこで私たちはその逆を行います。フィルタリング、列の選択、合計のカウントアップは 各データベースに戻って、それぞれ自身で処理する独自の言語で。数百万行をグループ化したレポートは、 少数の集計結果 ―彼らの後ろにある何百万もの列のことではない。
残ったものは何でも使います。そして、どれがどれなのかをお見せします。 データベース間の結合は私たちの仕事です。なぜなら、どのデータベースも他のデータベースを直接参照できないからです。プランには各データベースに要求された内容と完了した処理が明記されているため、コストのかかるクエリもすぐにわかります。 前に あなたが運営するのです。
黙って間違っていると認めるよりは、拒否する方がましだ。
別々のデータベースを統合する際の厄介な真実は、それらが必ずしも互いに一致するとは限らないということです。2つのデータベースに同じ質問を与えても、小数点以下の最後の桁が異なったり、等しいとみなす基準が異なったり、「最初の10」の意味が異なったりする可能性があります。
もしあなたがこの分野に不慣れなら、簡単に説明すると次のようになります。 データベースは単なる行の集まりではありません。金額の計算方法、単語の並べ替え方法、空の値の配置場所などについて、独自の考え方を持っています。同じ顧客名のリストを2つの異なるデータベースに並べ替えるよう依頼すると、実際に2つの異なる注文結果が返ってくる可能性があります。これは、一方のデータベースが壊れているからではなく、それぞれ異なるルールに基づいて構築されているためです。データベースを結合するツールは、こうした問題に対処しなければなりません。ほとんどのツールは、どちらか一方の答えを静かに選んで、あとは運任せにしています。しかし、私たちはそうはしません。
代わりに私たちが行うことには、正確には2つの結果があります。 クエリビルダーは、入力に応じて「準備完了」または「拒否」と表示されるプランピルと、完全な作業内容が表示されるプランタブによって、どちらのプランが得られたかを示します。
意見の相違が どうやって 計算が完了すると、データベースにその処理を依頼するのをやめ、一貫したルールセットが存在するステッチングステップで処理します。処理速度は若干低下しますが、精度や注意力は一切必要ありません。お客様には何もしていただく必要がないからです。
- 金と正確さ。 データベースは、合計値が大きくなると、小数点以下の桁数を調整したり、丸めたりする方法が異なる場合があります。ソース内での合計値と中央での合計値が異なる可能性がある場合は、数値をデータベースに戻して、独自に合計値を計算し直します。
- テキストを並べ替えています。 かどうか
a前に来るBアクセントの比較方法などは、データベースごとの設定です。これに依存する比較は中央で処理され、下位データベースには反映されません。 - ランキングと累計順位。 ウィンドウ関数（行番号、累計、地域ごとの上位3件など）は、個々のデータが到着した後に必ず計算されます。なぜなら、単一のソースからは他のデータが見えないからです。
続けると変わる どの行 結果がどうなるかは、単に速さだけでなく、確実に予測する方法はありません。そのため、クエリは実行されず、メッセージには、編集すべき箇所がわかるように、独自の SQL で正確な式とデータベース名が表示されます。
- ソースコードでは実行できない機能。 フィルターが、そのデータベースの言語で正確に表現できないものを使用している場合、他に選択肢は、記述したクエリよりも広範囲なクエリを送信するか、同等のクエリを考案するかのどちらかです。どちらも間違った解決策なので、お断りします。
- 作品内の行数制限。 A
リミットまたはトップ結合前に一方のソースに適用すると、任意の少数の行が返され、それらを結合すると、もっともらしく見えるが意味不明なテーブルが作成される。制限は最終結果に適用される。 - ゴールポストが移動した。 クエリの計画以降に接続先が別のデータベースに変更された場合、保存されている計画は古くなっているため、昨日の計画を今日のデータに対して実行するのではなく、再計画を要求します。
3つの拒否、そしてそれぞれがあなたに伝えようとしていること
押すことができません LOWER(c.email_domain) = ? mssql_erp までダウン: 関数がプッシュダウン許可リストにありません。
言い換えると： フィルターは列を関数でラップしていますが、ソース側ではその関数が弊社と同じ方法で適用されるとは限らないため、同じ行が返されることを保証できません。 何をするか： 代わりにプレーンな列を比較するか、その条件をソースの外に移動してください。メッセージには、参照すべきソースが示されています。
制限100 結合前に単一のソースに適用することはできません。結果として、回答の最初の 100 行ではなく、任意の 100 行が生成されます。
言い換えると： 「上位100件」というのは、すべてが結合され、並べ替えられた後に初めて意味を持つようになる。 何をするか： 制限は文全体にそのまま残しておきます。そうすれば、期待どおりに動作します。
ソース2は、このクエリを計画した時とは異なる接続先またはデータベースを指しています。
言い換えると： 誰かが変更した pg_crm 参照する。 何をするか： クエリビルダーで開いて再プランを作成すると、ワンクリックで実行前に新しいプランを確認できます。
その根底にあるルール： クエリが返ってきた場合 間違っている私たちは拒否します。それが単に戻ってくるだけなら ゆっくり弊社では、データを実行して警告を発します。誤ったデータを使用することは、お客様のために決して妥協することはありません。
拒否された場合も、あなた一人で解決する必要はありません。 Novaはクエリビルダーのエディターの横に座り、このシステム全体を流暢に操作します。質問すれば、拒否理由を分かりやすく説明し、実行可能なステートメントに書き換え、新しい実行プランをチェックしてくれます。SQL文を一切書きたくない場合は、質問内容を説明すれば、Novaがフェデレーションステートメントを自動的に作成してくれます。
安心感よりも詳細を知りたい方のために、クエリビルダーのプランタブには、すべてのソース、実際に送信されたクエリ、適用された条件、および中央で処理を完了した部分が一覧表示されます。より時間のかかる安全な方法を選択した部分も含め、決定に関するあらゆる情報が隠されることはありません。
フェデレーションクエリは単なるクエリです
これは独自のルールを持つ独立した製品ではありません。一度保存されると、Query Streams の他のすべての部分は、あなたが書いた他のすべてのものと同様にそれを扱います。
クエリビルダー
同じエディタで、同じスキーマツリーを横に表示しながら記述してください。「プラン」タブには各データベースに要求された内容が表示され、「インサイト」タブには各データベースのパフォーマンスがグラフで表示されます。
ノヴァAI
質問を英語で記述すると、Novaがスキーマを読み込み、各テーブルがどの接続に属しているかを含めたステートメントを作成します。さらに、ステートメントを実行して結果をグラフ化することもできます。
グーグル シート
アドオンで保存済みのクエリを選択すると、結合された結果がセルに表示され、フォーマット済みで更新も可能です。これは、単一データベースのクエリと同様です。
エクセル
Excelでも同様です。1つのシートだけを実行することも、シート全体を実行することもできます。その際、ヘッダー、フィルター、インプレース更新は固定され、独自の数式列はそのまま残ります。
データベースREST API
クロスデータベースの結果をキー付きのJSONエンドポイントとして公開すれば、それを利用する側は、それが3つのシステムから取得されたものであることを知る必要は一切ありません。
AIアシスタント向けMCP
クロードや他のアシスタントは、MCP を通じてフェデレーションクエリを一覧表示して実行できるため、「先週、各地域はどのような状況だったか」といった質問にチャットで回答できます。
レポートとアラート
スケジュールを設定すれば、集計された数値がSlack、Google Chat、Discord、Telegram、またはメールで届きます。あるいは、しきい値を設定して、何らかの動きがあった場合にのみ通知を受け取るようにすることもできます。
自動化と共有
結果をスケジュールに基づいてスプレッドシートに同期したり、クエリを同僚と共有したりできます。同僚にはフィルターと実行ボタンのみが表示され、SQL文や接続情報は一切表示されません。
以前は2つのエクスポートとVLOOKUPで構成されていたレポート
単一のデータベースを持っている企業はほとんどありません。ERP、店舗管理システム、CRM、そして最後に買収した企業が使用していたシステムなど、複数のデータベースが存在します。
注文はこちら、顧客はあちら
店舗は注文情報をMySQLに書き込み、CRMは顧客情報と地域情報をPostgreSQLに保存します。「地域別売上高」の算出は、2つのエクスポートと1つの検索処理から解放され、誰でも再実行できる1つの保存済みクエリで済むようになります。
買収後
2つの会社、2つのデータスタック、1つのボードパックが金曜日までに提出されます。初日から統合されたビューが表示されますが、実際の移行作業は従来通り18ヶ月かかります。
在庫対販売比率
在庫状況は別の国の倉庫システムに保存され、売上データは店舗データベースに保存されています。これらを1つの明細書にまとめて表示することで、毎週月曜日にレポートとして受け取ることができます。
サイトごとにデータベース1つ、番号1つ
国別、テナント別、店舗フロア別に同じスキーマを展開します。クエリを5回実行して手作業で合計するスクリプトを維持する代わりに、1つのステートメントで合計します。
フェデレーションデータベース、データフェデレーション、データ仮想化
重複する概念を表す3つの名称があり、多くのマーケティング活動によってその意味が曖昧になってきています。ここでは、それぞれの名称の意味と、私たちが実際に行っている業務内容について説明します。
連合データベース
A 連合データベース （またはフェデレーテッドデータベースシステム）は、複数の独立したデータベースを統合することなく、あたかも1つのデータベースであるかのように動作させます。各データベースは独自のストレージ、エンジン、所有者を持ち、それらの上位レイヤーがクエリを受け取り、どの部分に誰が応答するかを判断します。
その層こそがクエリストリームの本質です。その下に新たなデータベースは存在せず、何もコピーされることはありません。
データ連携
データ連携 アプローチそのものが重要です。つまり、データを最初に中央のコピーに抽出するのではなく、書き込まれた場所にそのまま残し、必要なときにクエリを実行するということです。代替案としては、パイプラインとデータウェアハウスを組み合わせる方法があります。これは、すべてのデータを夜間に移動させ、その後はコピーに対してのみクエリを実行するというものです。
どちらも正当な選択肢です。複数のシステムにまたがる問題、データを固定する必要がある場合、またはデータウェアハウスプロジェクトのコストが回答の価値を上回る場合は、フェデレーションが有利になります。一方、膨大なデータ量に対する詳細な履歴分析には、データウェアハウスが依然として適しています。
データ仮想化
データ仮想化 これは、フェデレーションを基盤としたより大規模なエンタープライズ向けカテゴリであり、通常はフェデレーションクエリに加えてモデリングレイヤー、キャッシング、ガバナンスツールを備え、独自のプラットフォームとして販売されます。
私たちは、その中のごく一部、つまり正直な部分だけを意図的に切り取っているのです。 既存の接続を介したフェデレーションクエリチームが既にクエリを作成しているツール内で完結します。モデリングプロジェクトも、自社サーバーの実行も、コンサルタントも不要です。
フェデレーションクエリに関するよくある質問
フェデレーションクエリとは何ですか？
フェデレーションクエリとは、複数の独立したデータベースからデータを読み込み、単一の結合結果を返す1つのSQLステートメントです。最初に何もコピーされることはありません。ステートメントはデータベースごとに小さなクエリに分割され、それぞれが可能な部分について回答し、それらが結合されて最終的な回答が生成されます。クエリストリームでは、ステートメントが2つ以上の接続を指定するとすぐにフェデレーションクエリになります。
データベースは同じ場所に置く必要がありますか？
いいえ。それらは異なるオフィス、異なるクラウドアカウント、異なる国、あるいはこれらすべてが混在した場所に設置できます。例えば、1つはサーバー室、1つはプライベートクラウドネットワーク、もう1つは倉庫内のマシンなどです。各拠点でネットワークエージェントが実行され、各エージェントはダイヤルアウト接続によってクエリストリームにアクセスします。ファイアウォールから見ると、これは通常の送信接続に過ぎないため、何も開く必要はなく、VPNを構築する必要もありません。
1台のサーバー上の複数のデータベースを同じエージェントに接続することも可能です。通常、データベースごとに1つのエージェントではなく、場所ごとに1つのエージェントを使用します。
データウェアハウスやETLパイプラインも必要ですか？
この場合はそうではありません。読み込むものも、監視するスケジュールもありません。クエリは実行時に稼働中のデータベースを読み込むため、昨晩のコピーのように回答が古くなることはありません。フェデレーションが置き換えることができないのは、非常に大量のデータに対する詳細な履歴分析です。これは依然としてデータウェアハウスの役割です。大まかなテスト：質問が複数のシステムにまたがり、最新の情報が必要な場合は、フェデレーションを使用してください。
どのデータベースを結合できますか？
SQL Server、PostgreSQL、MySQL、MariaDB、Oracle、Snowflake、BigQuery、SQLite、Access、DuckDBなど、あらゆるデータベース接続を自由に組み合わせて使用できます。各データベースは独自のダイアレクトで要求されるため、同じステートメントでも、 トップ SQL Server へ リミット 意識することなくPostgreSQLに移行できます。
データベースは、計算できる内容やソート・丸め処理の方法がそれぞれ異なるため、あらゆる式の組み合わせに対して正確な回答が得られるとは限りません。そのような場合、ほぼ正しい数値ではなく、式名を示す具体的なメッセージが表示されます。
単一のデータベースにクエリを実行するよりも遅いですか？
処理量は、各データベースがどれだけの作業を自身で処理できるかによって異なります。まさにそれが、私たちが最適化するポイントであり、実行プランに表示される内容です。フィルタリングとグループ化がすべてデータベース内で行われる場合、データ移動はごくわずかで、通常のクエリのように感じられます。一方、大規模な結合処理を弊社が行う必要がある場合は、データ移動量が増えますが、実行前にプランでその旨が示されます。また、各データベースにはクエリごとの上限が設定されているため、エラーが発生した場合でも処理が長引くことなく早期に停止します。
1つのクエリを複数の本番データベースに向けて実行するのは安全でしょうか？
ここで実行する他のすべてのクエリと同じセキュリティ モデルを使用します。各ピースは、独自のネットワーク エージェントを介して 1 つの暗号化されたアウトバウンド接続を介して送信されます (インバウンド ポート、VPN、ファイアウォールの変更はありません)。データベースの認証情報はネットワークから出ることはありません。各ピースは読み取り専用でチェックされます (セレクト, と, 説明する) フェデレーションクエリはどこにも書き込むことができず、各データベースは指定した列にアクセスするクエリのみを認識します。
これはTrino、Presto、Denodoとどう違うのですか？
基本的な考え方は、TrinoやPrestoが普及させたものと同じです。つまり、1つのSQL文を複数のソースにプッシュダウンするということです。違いは、実行と学習が必要な部分です。これらは、デプロイ、チューニング、ネットワークへの接続が必要なクラスタであり、データ仮想化プラットフォームはモデリングレイヤーとそれに合わせたライセンスを追加します。一方、当社のソリューションは、チームが既にクエリに使用しているツール内で同じ機能を提供し、既に設定済みの接続にアクセスできるため、独自のサーバーを運用する必要はありません。
もう一つの違いは、我々が拒否するという点です。データベース間で数値が変わる可能性のある矛盾が生じた場合、我々は処理を停止し、妥当な値を返すのではなく、処理できなかった式に名前を付けます。
結果をどのように活用できますか？
保存済みのクエリはまさにクエリなので、保存、チームとの共有、フィルターの適用、Slackやメールへのレポートとしてのスケジュール設定、RESTエンドポイントとしての公開、ExcelやGoogleスプレッドシートへの結果の取り込みなど、あらゆる操作が可能です。また、結合式を記述するよりも質問を記述したい場合、Novaはスキーマを読み込んでステートメントを作成することもできます。
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish