複数のソースにデータが複製されている条件下での最適なソースの選択

スタースキーマでの作業では、ファクトテーブルがデータベースに保存され、そのファクトテーブルのディメンションが他のデータベースに保存されていることが考えられます。クエリのパフォーマンス向上を図るために、スタースキーマを構成するすべてのデータベースにディメンションが複製されている場合があります。これにより、どのディメンションが関係する結合であっても、同じデータベースで実行できます。

Virtual DataPort では、同じデータが複数のソースに保存されていることを示すように基本ビューを構成できます。「代替ソース」と呼ばれるこの機能により、複数のデータベースにデータが複製されている状態を有利に活用できます。

実行時、この基本ビューを指定したクエリを実行すると、ソースにプッシュダウンできる操作の数が最大になるソースが、オプティマイザーによって基本ビューのデータソースとして選択されます。

たとえば、以下の例を考えます。

  • データベース DB1 にあるテーブルを使用する JDBC 基本ビュー V1 があります。

  • データベース DB2 にあるテーブルを使用する JDBC 基本ビュー V2 があります。そのテーブルのコピーがデータベース DB1 に存在します。

  • ビュー V2 の代替ソースとしてデータベース DB1 を定義しています。

V1 と V2 の結合を実行すると、V2 のテーブルが V1 のデータソースにも存在することがオプティマイザーによって認識されます。これにより、DB1 と DB2 からデータを取得して Denodo で結合が実行されるのではなく、V1 と V2 の結合が DB1 データベースにプッシュダウンされます。

重要

この最適化が適用されるようにするには、基本ビューの代替ソースを定義できるのであれば、そのように定義する必要があります。その手順については、「 代替ソース 」を参照してください。

この機能は、JDBC 基本ビューでのみ使用できます。