動的AMPサンプリング - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - SQLリクエストおよびトランザクション処理

Product
Advanced SQL Engine
Teradata Database
Release Number
17.05
17.00
Published
2020年6月
Language
日本語
Last Update
2021-03-30
dita:mapPath
ja-JP/ykx1561500561173.ditamap
dita:ditavalPath
ja-JP/ykx1561500561173.ditaval
dita:id
B035-1142
Product Category
Software
Teradata Vantage

Vantageでの動的AMPサンプリングの使用

最適化ルーチンは、カーディナリティを見積もるときに、動的AMPサンプルよりも、プライマリ インデックスと行パーティションに対して収集された統計とUDIカウントの組み合わせを使用する傾向があります。これは、UDIカウントから得られるデータの方が動的AMPサンプルから得られるデータよりも正確な場合が多いためです。ただし、動的AMPサンプリングに基づいてカーディナリティを見積もらなければならない場合も依然として存在します。

列セットまたはインデックスのデモグラフィックを定量化するために使用可能な統計が存在しない場合、最適化ルーチンは1つのAMPを選択して、テーブルIDに基づくアルゴリズムを使用した統計用のサンプリングを動的に実行できます。

推測により、これらの数は、列、またはインデックスのグローバル統計を表わすものと見なされます。

動的AMPサンプルによって収集されたカーディナリティの見積もりは、テーブルのファイル システムDBD(Data Block Descriptor)のNumRows列および、テーブルのプライマリ インデックスまたはPARTITION統計から収集された場合は、OneAMPSampleEstフィールドおよびAllAMPSampleEstフィールドに格納されます。

特定のDBDが取り出されるたびにVantageは新しい動的AMPサンプルを収集します。ただし、間隔ヒストグラム統計が該当する列やインデックスに存在する場合、デフォルトでは、その統計が、この動的AMPサンプルによって収集された統計に上書きされます。

動的AMPサンプルによって収集された統計は、インデックスが付けられている列にのみ適用されることに注意してください。インデックスが付いていない列についての統計を収集しない場合、最適化ルーチンは、さまざまな状況特定の経験則を使用して、カーディナリティの任意の見積もりを提供します。

動的AMPサンプルを、フル テーブル統計収集として代用できるとは考えないでください。例えば、動的AMPサンプルは、一般に、列またはインデックス セットのカーディナリティと固有値数の合理的な見積もりを提供しますが、問合わせの特定の述部の最適な選択については、一般に適正な見積もりを生成しません。

この方法を基礎とする仮定

動的AMPサンプリングを基礎とする、密接に関連付けられた基本的な仮定は、次のとおりです。
  • サンプリングされたテーブルには十分の行があり、システム内の1つのAMPのスナップショットが、全AMPに渡るテーブル全体のデモグラフィックを正確に特徴付けている。

    テーブルのカーディナリティがシステムのAMPの数より少ない場合、動的AMPサンプルでは、テーブルの実際の母集団統計の見積もりを生成するのに十分ではないため、この仮定は重要な意味を持ちます。このため、常に小さいテーブルで統計を収集するようにします。

  • サンプル化されたテーブルの行は、ひずみがなく、平均的に分布している。

    データにひずみがあると、動的AMPサンプルはかなりエラーの多いデモグラフィックを提供する可能性があります。システムUDIカウントは、分布にひずみが生じているテーブルの場合に、動的AMPサンプリングよりもはるかに優れたカーディナリティ見積もりを最適化ルーチンに提供します。

  • サンプル化されたテーブルの行は、圧縮されていない。

    インデックスまたは列セットの列が複数値圧縮、アルゴリズム圧縮、ブロック レベル圧縮、または行圧縮ハッシュおよび結合インデックスを使用して圧縮されている場合、最適化ルーチンは圧縮テーブルの読み込みコストを過小評価することが多いため、動的AMPサンプルから返されるデモグラフィックは信頼できません。

    動的AMPサンプリングでさまざまなシナリオに適合するカーディナリティ見積もりが得られる場合でも、アルゴリズム圧縮、ブロック レベル圧縮、列パーティション テーブル、または圧縮ハッシュと結合インデックスを使用して圧縮されたテーブルでは重大なエラーが発生する可能性があり、結果的に使用できません。

    この種のテーブルに対するカーディナリティ見積もりに関して、システムUDIカウントは、最後に統計が更新されたときに基づく正確な変更データを最適化ルーチンに提供できます。

  • 列は、列パーティション化されたテーブルの列ではない。

    前述したように、列パーティション テーブルの行の動的AMPサンプルから得られる統計は、圧縮列セットから得られる統計と同じく、信頼できません。システムUDIカウントは常により正確なカーディナリティ見積もりを提供します。

このような前提が成り立つ場合は、動的AMPサンプリングを使用して見積もられたカーディナリティの多くが非常に正確です。サンプル化された統計は、行パーティション化されたテーブルのパーティション列に対しては正しく機能しません。このため、サンプル統計をそれらのテーブルの統計の収集に使用しないでください。

単一のAMP動的サンプルからのカーディナリティの見積もり

動的AMPサンプルを使用して、インデックス付きの列についての統計を収集するときに使用されるプロセスは次のとおりです。

  1. カーディナリティ見積もりの収集に使用するAMPを選択します。それには、テーブルIDの値をハッシュして、AMP番号を生成します。
  2. マスター インデックスを読み込み、必要なテーブル、列、またはインデックスのデータを含むシリンダを突き止めます。
  3. 必要なデータを含むシリンダ数をカウントします。
  4. これらのシリンダから1つをランダムに選択し、そのシリンダ インデックスを読んで、必要なテーブル、列、またはインデックスのデータを含むデータ ブロックを突き止めます。
  5. 必要なデータを含む、シリンダ内のデータ ブロック数をカウントします。
  6. これらのデータ ブロックの1つをランダムに選択し、含まれている行数をカウントします。
  7. 次の計算式を使用して、テーブルのカーディナリティの見積もりを計算します。

テーブルのカーディナリティ、値ごとの平均カーディナリティ、インデックスについては固有値の数、各インデックスの平均カーディナリティ、各AMP上の各インデックスの平均サイズだけが、動的AMPサンプルによって見積もられる統計値です。


テーブルの見積もりカーディナリティの式

NUSIの場合、カーディナリティ見積もりはインデックス内の固有値の数に対応するインデックス行の数に対するものです。

結果として、小さなテーブル(正確な測定単位を出すにはAMPあたりの行が少なすぎる)、またはひずみのある値セットからの動的AMPサンプリングによってエラーになる可能性は、COLLECT STATISTICS文の最適化ルーチン形式を使用して収集したフル テーブル統計による見積もりよりもずっと高くなります(これらの統計のリストについては、収集されて計算された統計とデモグラフィックを参照)。このスキューの状態であるという用語は統計的な意味での値分布をひずませる外れ値があるという意味です。システムの複数のAMP間における、テーブルの行の不均衡な分布を意味しているわけではありません。

最適化ルーチンは、単一のAMPサンプルを使用して収集する統計とデモグラフィック情報は信頼性が低いことを理解しているので、その結果の信頼性は低い(動的AMPサンプリングが使用される問合わせのEXPLAINで報告される)と想定し、特に結合戦略などの最適化問合わせ計画を進める点で消極的になります。

実際にはEXPLAINは、この例の場合は条件についての統計がないので、信頼度なしとレポートします。リクエストが実際に実行される場合、Vantageは動的AMPサンプリングを実行し、結果のカーディナリティ見積もりは低い信頼性と表現されることになります。最適化ルーチンの信頼度レベルに関する詳細は、最適化ルーチンの信頼度レベルについてを参照してください。

つまり、結果の問合わせ計画は、必要に応じて全統計から収集することで、間隔ヒストグラムに維持されている広範で正確な統計から生成された計画よりもコストが高くなることがあります。

複数のAMP動的サンプルからのカーディナリティの見積もり

単一AMP動的サンプルと複数AMP動的サンプルとの手続き上の唯一の相違点は、テーブルIDをハッシュすることで識別される初期AMPに加え、どのAMPをサンプリングするかの選択が関係しています。

最初のAMPがテーブルID値のハッシュにより識別されると、続くn AMPはそのAMP IDの昇順で選択されます。Vantageは、最も効率的な負荷分散が得られるように、連続するAMP IDを選択します。選択された最初のAMPが一連のAMP IDの末尾付近のものであれば、システムは先頭に折り返して選択します。

複数AMPサンプリングであっても、完全な統計の収集の代わりにはならないことを理解しておくことは重要です。

さらに同じく重要なこととして、AMPの部分集合からサンプリングしても、その部分集合がすべてのAMP間のデータを代表するものとして保証されているわけではないことも理解しておくべきです。部分集合のサンプリングにより、単一のAMPのサンプリングによって生成される統計よりも集団の代表として不適な統計が生成されることも、まれですが起きる可能性があります。

USIの動的AMPサンプリング

動的AMPサンプリングでは、USI内の固有値の数はカーディナリティに等しいと見なされるので、USIの等価条件のインデックス サブテーブルを読み込みません。USIの固有値の数は、プライマリ インデックス上の動的AMPサンプルから取得したテーブルのカーディナリティと同じであると仮定されます。

定義では、固有インデックス上の等価条件は1行のみを返すので、最適化ルーチンは、コストを計算したり統計を使用することなく、直接USIパスを常に選択します。ただし、USIが範囲制約のような非等価述部で頻繁に指定される場合は、USIについての統計を集める必要があります。

NUSIの動的AMPサンプリング

NUSIについて動的AMPサンプリングを行なうことは非常に効率的です。システムは、サンプリングされたAMP上のインデックス サブテーブルの行をサポートするシリンダインデックスを読み込み、そのシリンダで行数を確認します。NUSIが非常に非固有である場合を除き、NUSIには各固有値に1つのサブテーブル行があります。その知識に基づいて、サンプリング プロセスでは、検出される各サブテーブル行が1つのインデックス値に変換されると仮定されます。

サンプリング プロセスでは、データに関する次の条件は真であると仮定されます。
  • すべてのAMPで同じ値が発生する。
  • サンプリングされたAMP上で検出された固有値の数は、NUSIの固有値の総数を表わす。

これらの仮定によって、非常に特異なNUSIの場合、一般的なNUSIの場合よりも、動的AMPサンプルの精度が落ちます。複数AMPがサンプリングされる場合、システムは全サンプルAMPの固有値の平均数を計算します。

NUSIの見積もりは、常に、テーブルの総カーディナリティが見積もられたあとに行なわれます。サンプリング プロセスでは、見積もられた総カーディナリティをNUSIカーディナリティで割り、インデックス内の値ごとのおよその行数を見積もります。要求によって、一致する等価条件内の単一の値がNUSIに渡されます。ひずみが存在している場合でも、広範囲ではないときには、問合わせ計画は非常に良いものになります。

次のテーブルは、データに大きなひずみがない場合の、動的AMPサンプリングしたNUSI見積もりの例をいくつか示しています。インデックス内の値ごとの行数が非常に少ない場合(c_phoneおよびc_acctbal)は、カーディナリティの見積もりの精度が落ちることに注意してください。

テーブル NUSI Col 問合わせテキスト 結果のカーディナリティ Est.結果のカーディナリティ(AMPサンプル) %差 Est.結果のカーディナリティ(完全な統計) %差 見積もり間の%差
parttbl p_type
SELECT *
FROM parttbl
WHERE p_type = ‘economy brushed copper’;
67,103 67,123 0.03 66,667 0.65 0.68
partsupp ps_suppkey
SELECT *
FROM partsupp
WHERE ps_suppkey = 555;
80 82 2.47 81 1.24 0.01
customer c_acctbal
SELECT *
FROM customer
WHERE c_acctbal = 7944.22
10 24 82.35 7 35.29 109.68
customer c_phone
SELECT *
FROM customer
WHERE c_phone = ‘25-548-367-9974’;
1 21 81.82 2 165.22 158.33

インデックス付きでない述部列におけるサンプリングの効率性

動的AMPサンプリングは、UPI、USI、およびNUSIの固有値について合理的なカーディナリティの見積もりを提供する一方で、問合わせ内のインデックス付きでない述部列については有効なカーディナリティの見積もりを提供しません。リクエストのWHERE句がzip_code=90230の述部を指定している場合、zip_code列に統計値がないときには、Vantageはさまざまな経験則を使用して、デフォルトの選択性を適用し、それらの列についてデフォルトのカーディナリティを見積もります。この例の経験則では、カーディナリティはテーブルの行数の10パーセントと見積もられます。

特に値にひずみがある場合は、デフォルトのカーディナリティの見積もりに依存しないで、統計を選択頻度が高い列から収集するようにします。

次のページのテーブルは、単純な選択基準がある3つの問合わせを示しています。問合わせからの実際の応答カーディナリティが、経験則的デフォルト値から導出されたカーディナリティの見積もり、全統計の収集から導出されたカーディナリティの見積もり、および2つの見積もりの間のパーセント差と共に示されています。実際のカーディナリティと経験則的見積もりの間にはすべてのケースでかなりの差が見られ、全統計を収集して行なわれた見積もりは、すべてのケースで現実に非常に近くなっています。

実際のカーディナリティをデフォルトの見積もりと比較する場合、等価条件の単一選択列において、最適化ルーチンではテーブル内の行の約10パーセントが返されると仮定されていることが分かります。2つの選択基準を使用した場合、テーブル内の3番目のリクエストで見られるように、最適化ルーチンでは、行の約7.5パーセントが返されると仮定されます。選択基準の例が複雑な問合わせの一部であり、そのクエリーで追加のテーブルが結合演算に含まれていた場合、すべてのケースにおいて、デフォルトのカーディナリティの見積もりは、返される行数をかなり過剰に見積もるため、統合計画は不正確なものになります。

NUSIがこれらの列で定義されていた場合、最適化ルーチンは、NUSI列が問合わせ計画の開発時に使用されていなかった場合でも、カーディナリティに動的AMPサンプル見積もりを行ないます。

インデックス付きでない列の選択基準では、動的AMPサンプリングが、システム内の1つのAMP、いくつかのAMP、またはすべてのAMPについて定義されているかどうかに関係なく、カーディナリティ見積もりが不正確になります。インデックス付きでない列のカーディナリティの見積もりの正確性は、全AMPがサンプリングされる場合でも向上しません。これは、サンプリングされるAMPの数に関係なく、Vantageが常にテーブルの行の10%をサンプリングするためです。

これらの結果から引き出される重要な結論は、選択述部で頻繁に指定されるインデックス付きでない列で統計を収集することが重要であるという点です。動的AMPサンプルでは、インデックス付きでない列にひずみがない場合でも、それらの列について正確なカーディナリティ見積もりが提供されることはありません。

問合わせテキスト テーブルのカーディナリティ 応答セットのカーディナリティ Est.応答セットのカーディナリティ

(経験則)

%差 Est.応答セットのカーディナリティ

(完全な統計)

%差
SELECT *
FROM lineitem
WHERE l_commitdate = ‘1998-01-06’;
300,005,811 123,959 30,017,594 198.36 124,591 0.25
SELECT *
FROM partsupp
WHERE ps_availqty = 7874;
40,000,000 3,936 3,991,526 199.61 4,000 1.62
SELECT *
FROM parttbl
WHERE p_size = 22
AND   p_brand = ‘Brand#23’;
10,000,000 8,061 750,398 195.75 7,997 0.80