コストベースの最適化 - Advanced SQL Engine - Teradata Database

コストベースの最適化について

特定のリクエストが完了するのにかかる時間が長いほど、コストも多くかかります(すべての最適化ルーチンのコスト測定単位はミリ秒です)。

最適化ルーチンは、列とインデックスのデモグラフィックと、COLLECT STATISTICS文によって収集された統計を使用します。この情報により最適化ルーチンは、単一テーブルと結合アクセスのリレーションのカーディナリティを見積もり、テーブル内のスキューを識別できるようになります。これらの要因に関する豊富な情報を活用し、コスト見積もり機能を使用することで、最適化ルーチンはクエリーを満たすためのより良い計画を生成できます。COLLECT STATISTICS (最適化ルーチン形式)の詳細については、<Teradata Vantage™ - SQLデータ定義言語-構文規則および例、B035-1144>および<Teradata Vantage™ - SQLデータ定義言語 - 詳細トピック、B035-1184>を参照してください。

次のテーブル、table_xの一部について考えてみてください。

次のクエリーを行なうと、フル テーブル スキャンが実行されるとします。

SELECT *
FROM table_x
WHERE state IN (28, 51)
AND   serial_num IN (12345, 23456);

ここでリクエストを次のように修正します。

SELECT *
FROM table_x
WHERE (state=28 AND serial_num=12345)
OR (state=51 AND serial_num=23456)
OR (state=28 AND serial_num=23456)
OR (state=51 AND serial_num=12345);

意味的に同一な修正済みの問合わせにより、4つのプライマリ インデックス アクセスが行なわれます。これにより、最初の問合わせを解決するために使用されるフル テーブル スキャンのパフォーマンスが著しく向上します。

パスの選択

最初の形式は、論理積標準形、すなわちCNFとして知られています。この形式では、オペランドのペアは、かっこ内でOR演算され、かっこで囲まれたグループの間でAND演算されます。CNFを使用する利点は、式の中の個々の条件がFALSEと評価されるとすぐに、式全体がFALSEと評価され、最適化ルーチンのそれ以降の考慮対象から外せるという点です。

2番目のものは、非論理積標準形、またはDNFと呼ばれます。これらの2つの形式を基にして、さまざまなアクセス パスを選択することができます。状況に応じて、適切な方を選択します。

A、B、CおよびDが単一テーブルの列または単一列パーティションの列を参照する場合は、問合わせに指定された形式に基づいてアクセス パスが最適化ルーチンによって生成されます。最適なパスを見つけるために、ある形式が別の形式に変換されることはありません。これに対して、A、B、CまたはDが結合条件を指定している場合には、2番目の形式が最初の形式に変換されます。

以下の式を考慮してみます。

(NUSI=A OR NUSI=B) AND (X=3 OR X=4)

この場合は、AとBの値をもつ2つのNUSIのSELECTリクエストでアクセス パスが構成されているため、CNFの方がパフォーマンスが良くなります。そのあとで、条件(X=3 OR X=4)が適用されます。DNFを使用すると、NUSIを使用した4つのSELECTリクエストが必要になります。

次の式では、(NUSI_A, NUSI_B)の組合わせでNUSIが構成されています。

(NUSI_A=1 OR NUSI_A=2) AND (NUSI_B=3 OR NUSI_B=4)

この場合には、4つのNUSIを使用した4つのSELECTでアクセス パスが構成されているため、DNFの方が適しています。CNFを使用したアクセス パスでは、全件検索が必要になります。

次のように、INを使用した単一の列の比較操作が含まれている式を考えてみましょう。

column IN (value_1, value_2, …)

この場合には、式を内部的にCNFへ変換します。

column=value_1 OR column=value_2 OR …

したがって、どちらの形式を使用しても同じアクセス パスが生成されます。

次の例のように、INリストを使用した複数列の比較操作が式に含まれているとします。

column_1 IN (value_1, value_2, …)
AND column_2 IN (value_3, …)

この場合には、最適化ルーチンは、内部でこの構文を次のような論理積標準形に変換します。

(column_1=value_1 OR column_1=value_2 OR …)
 AND (column_2=value_3 OR …)

変換された形式、つまり論理積標準形(CNF)が、2番目の形式とどのように異なっているかに注意してください。2番目の形式は、次の例で示されている通り、非論理積標準形(DNF)になっています。

(column_1=value_1 AND column_2=value_3)
OR (column_1=value_2 AND column_2=value_4)
OR …

重要なのは、意味的に同じ問合わせを異なる構文で表わすと、そのアクセス方法が違ってくる場合があるということです。

最適化ルーチンのコスト予想について

コスト予想の目的は、最適化ルーチンに正確なコストの見積もりを提供して、さまざまな操作をさまざまな方法で実行することです。そうすることで、最適化ルーチンはコスト ベースの決定を下すことができます。

操作のコストは、サブシステムが無負荷のシステム上で操作を実行する際に必要とするサービス時間です。最適化ルーチンは、CPU、I/O、およびBYNETコンポーネント サービス時間の見積もりに基づいて、操作の実行方法を比較し、総コストが最も低い方法を選択します。予想コスト値を増やすことによって、特定のアプローチを除外するか、その可能性を大きく減らす必要があるような状況があるため、経験則的コスト コンポーネントも、さまざまなサブシステム コスト コンポーネントの集合に含まれます。

全体のコストは、サブシステム コストの一次結合であり、最適化ルーチンが利用可能なさまざまな方法を比較する際に使用する値です。コスト予想公式と方法では、個々のサブシステム レベルの値が保持されます。これは、CPU、I/O、BYNET、および経験則的コンポーネント値によって計算される所定の全体コストを確認するためです。この情報を使用して、I/O集約アプローチとCPU集約アプローチを区別することができます。こうすることにより、予想されたコスト値がひどく不正確である場合に、アナリストがエラーの原因を明確に特定することができます。

詳細については、問合わせ獲得機能および<Teradata Vantage™ - SQLデータ定義言語-構文規則および例、B035-1144>の「INSERT EXPLAIN」を参照してください。

詳細については、<Teradata Vantage™ - データベースの管理、B035-1093>および<Teradata Vantage™ - SQLデータ定義言語-構文規則および例、B035-1144>の「BEGIN QUERY LOGGING」を参照してください。

対応する全体コスト値は、QCD QueryStepsテーブルのコスト列と、DBQL DBQLStepTblテーブルのEstProcTime列でそれぞれ取得されます。

コストを予想する場合、2つの入力データ カテゴリがあります。1つ目は、実行時環境を特徴付ける値で、2つ目は、最適化されるリクエスト内に含まれるデータベース エンティティを特徴付ける値です。実行時環境にはハードウェア プラットフォーム、オペレーティング システム、I/Oサブシステム、およびデータベース アルゴリズムが含まれています。これらは、基本的にTeradataデータベース システムのすべての製品セット要素です。I/Oスループット レート、CPU速度、BYNET能力、およびコード パスの長さすべてが、実行時環境パフォーマンスの要素の例です。CPUとI/Oの両方のコスト見積もりは、最適化対象のリクエストを通してアクセスされるデータを含むデータ ブロックのサイズによって異なります。

問合わせ計画中、最適化ルーチンは、統計、動的AMPサンプル、およびデータベース ソースから導出されるさまざまな見積もりを含む、さまざまな種類のメタデータを使用して、データベース エンティティの特徴を見積もります。

最適化ルーチンのコスト プロファイル

コスト プロファイルは、Teradata Databaseが最適化ルーチンの原価計算係数、特定の機能の有効化と無効化、およびその他のシステム設定に使用するステム固有の値(コスト プロファイル定数)のセットです。コスト プロファイルは、システム全体に適用したり、プロファイルに関連付けてそのプロファイルが割り当てられているユーザーにのみ適用したりできます。

次のテーブルは、最適化ルーチンのコスト プロファイル定数とその実行内容の一部をまとめたものです。

統計およびコストの見積もり

使用できる統計がない場合、あるいはテーブルにプライマリ インデックスがない場合、最適化ルーチンは動的に選択したAMPから取り出した情報に基づいて、テーブル内の合計行数を見積もります(動的AMPサンプリングを参照)。

上記のいずれかの特性が真である場合は、平均から大きくかけ離れた行数をもつAMPが存在している可能性があります。

行数を見積もるときに、そのようなAMPが選択された場合には、最適化ルーチンが間違った見積もりを行なうので、もっとも効率的な処理を行なうための最適な方法(結合、アクセス パス、その他)を選択できないこともあります。

古い統計が使用されると、最適化ルーチンは、動的に取り出されたAMPから得た見積もり情報に基づいて作成される結合計画よりも、さらに悪い結合計画を作成する場合があります。

唯一異なっているのは、古い統計に基づく計画は常に間違っていますが、動的AMPサンプルに基づく計画はある程度正確な統計的見積もりを提供する可能性があるという点です。

インデックスによるアクセスを行なわせる

リクエストを処理する際に必ずインデックスが使用されるようにするには、インデックス付きの列の値に、問合わせのWHERE句で制約を指定します。

このようなWHERE制約に複数のNUSIが適用される場合で、対象となるテーブルが非常に大きい場合には、ビット マッピングによって、もっとも効率的な検索が行なわれます。テーブルが小さい場合には、最適化ルーチンは、選択性がもっとも高い(インデックス値あたりの行がもっとも少ない)と見積もられたインデックスを選択します。

NUSI列の統計情報を利用できない場合には、最適化ルーチンは、インデックス値が均等に分散されていると仮定します。最適化ルーチンは、テーブルIDに基づいて動的に1つのAMPを選択し、そのAMP上の対象になるテーブルの行の総数をそのAMP上の固有のインデックス値の数で割ることで、インデックス値あたりの行数を見積もります。インデックス値が均等に分散されていない場合は、その見積もりは正しくないため、アクセス パフォーマンスが低下する原因となります。

インデックスによるアクセスのための指針

EXPLAINリクエスト修飾子またはクライアントVisual Explainユーティリティを常に使用して、最適化ルーチンがクエリーを実行するために生成する計画を確認するようにしてください。