SQL クエリーの応答時間の最小化

「短いほど速い」と覚えておいてください。他の要因がすべて同じであれば、単純な SQL ステートメントのほうが複雑な SQL ステートメントより短い時間で実行できます。同様に、他のすべての要素が同じであれば、より多くのデータを求めるリクエストは、より少ないデータを求めるリクエストよりも時間がかかる。

レポートが実行されたり、ダッシュボードが開かれたりすると、クエリ・サービスは1つ以上のソースからデータを取得するために必要なSQL文を計画する。 Cognos® Analytics クエリ・サービスは、1 つまたは複数のソースからデータを取得するために必要な SQL 文を計画します。生成される物理 SQL ステートメントは、基礎データベースでサポートされている SQL のセマンティックとデータ型に応じて異なります。生成されるSQL文の複雑さは、基礎となるデータ・サーバーと、ローカルで追加処理を行う必要があるサーバーの両方に、パフォーマンス・コストをもたらす可能性がある。 Cognos Analytics サーバーがローカルで追加処理を行う必要がある場合のパフォーマンス・コストが発生します。

Cognos Analytics オペレーショナル・データベースにレイヤー化されたアプリケーションは、データをナビゲートし、ビジネス用語で値を提示するために、複雑な結合や式を必要とすることが多い。一方、クレンジングされたレポート構造 (スター・スキーマなど) の上に置かれたアプリケーションでは、抽出/変換/ロード (ETL) の発行プロセスで適用されるデータ変換を利用できます。クエリーの結合と式の複雑さを軽減すると、基礎データ・サーバーがクエリーのプランを効率的に作成できるようになり、結果的に、プロセッサーとメモリーの消費量が削減されます。

実行時のパフォーマンスを向上させるための手法として多数のデータ・サーバー・テクノロジー・ベンダーが推奨している手法をいくつか紹介します。

複雑な結合とフィルター式を避ける

SQL ステートメントの WHERE 節と JOIN ON 節の式が複雑であると、データ・サーバーによるプランの作成、マテリアライズ・ビューへのクエリーの書き換え、または他の形式のクエリーの加速化が妨げられる可能性があります。

明示的または暗黙的なデータ型変換を減らす

データ型の変換には、クエリーの応答時間を大幅に長くする原因になる処理が必要になります。計算やフィルターで CAST() などの関数を使用すると、データ型の変換が明示的に行われます。一方、データ型の異なる複数の列に対して特定の操作を実行すると、暗黙的に変換されます。

表間の関係でキーの役割を果たす計算式は、結合関係の反対側の対応するキーと同じデータ型に解決されるのが理想的です。この場合、データ型の不一致のために、ハッシュ結合などの特定の結合戦略をデータ・サーバーで検討する必要がなくなります。

SQL 式で値を置き換えることを避ける

SQL に詳しいユーザーは、表示のためにデータベースの値を巧みに操作する式を作成できます。場合によっては、そのような式は、提供されているデータ型の形式設定、レイアウト、その他の表示オプションを使用して置き換えることができます。

以下の例は、さまざまなオーサリング・インターフェースで提供されているデータ形式の表示オプションを使用する代わりに、複数のデータ型の変換、サブストリング、連結を実行して、特定の方法で日付の値を表示できることを示しています。

Substring(Cast ( dateField, char(10)),6,2) || ‘-‘ || Substring(Cast ( dateField,
char(10)),9,2) || Substring(Cast ( dateField, char(10)),1,4)

不要な外部結合を避ける

外部結合を使用すると、ステートメントに含まれている 1 つ以上の表に関連データが存在していなくても、アプリケーションから結果セットを戻すことができます。外部結合を使用するクエリーでは、内部結合でデータ・サーバーが時折使用する、さまざまな結合最適化戦略や結合並べ替えを使用できません。レポートまたはダッシュボードで提起されるビジネスの質問に実際は必要でないかもしれない外部結合を常に使用するように、モデルが構成されていることがあります。

データ・サーバーの表の制約を使用する

データ・サーバーの表には、結合の排除、クエリーの書き換え、式の最適化などの戦略のためにデータ・サーバー・クエリー・エンジンが考慮できる制約を設定できます。

この目的で、主キー、一意キー、外部キーの制約を宣言できます (Null 制約と表制約は宣言できません)。データ・サーバー・テクノロジーに応じて、これらの制約を「適用なし」または「適用あり」のどちらかとして宣言できます。スノーフレーク・スキーマを含む正規化された表の設計では、主キーでないキーの列は、主キーに機能的に依存します。

データサーバーが処理するSQL文を計画するために、クエリーサービスはメタデータモデルで定義された強制制約を使用します。 Cognos Analytics クエリサービスは、Framework Manger の決定子やデータモジュールのカラム依存関係、テーブル間のリレーションシップなど、メタデータモデルで定義された強制制約を使用します。これらのオブジェクトは、モデル作成の初期段階でよく作成されますが、一般的には、メタデータのモデル作成者が手動で定義します。詳細については、決定要素と列の依存関係を参照してください

索引と表の編成機能を使用する

データベース管理者の一般的な課題として、アプリケーションがどのようにデータベースをナビゲートするのかを予測するという課題があります。例えば、クエリーで結合される表はどれか、述部が適用される表はどれかなどを予測します。

代表的なワークロードを使用することで、データベース管理者は、最もよくアクセスされる表や、特に、表の列のフィルタリングやグループ化で局所的に使用される列のセットを調べることができます。その知識を基に、データベース管理者は、必要な行を効率的にデータベースで選択できるようにするための索引や表の編成戦略を決定できます。

ワークロード候補は、アプリケーションで行われる可能性のあるアドホックなデータの分析や閲覧を表すものでなければなりません。データベース管理者が定義できるカバー索引または表の編成が制限されていると、最も多い事例にソリューションが偏る可能性があるので、これは重要なことです。例えば、アプリケーションの大部分が、データベース管理者が表の設計を最適化できる「時間」、「顧客の地域」、「製品」という観点で数値データを分類するようになる可能性があります。

SQL ビューを使用してアプリケーションのオブジェクトを公開するデータベースの上に、メタデータ・モデルを構成することもできます。データベース管理者は、そのようなビューの中で使用されている式を確認する必要があります。