- 少数の列の部分集合(しかも対象となる列がさまざまに異なる)にアクセスするクエリーは、パーティション化されていないテーブルと比べて、列パーティション テーブルに対するほうが効率的に実行できます。列パーティション テーブルに対するクエリーの大部分は列のさまざまな部分集合に対する選択操作であり、列のさまざまな部分集合を射影するものと想定します。アクセスする部分集合は特定のクエリーのパーティションの10%未満とします。クエリーからアクセスする必要のあるパーティション数は、その文脈で利用可能な列パーティションの数を超えないようにします。
- 以下の特性を持つテーブルに対して、列パーティションを使用します。
- 分析的なクエリーを使用してアクセスするテーブル。
- バルク データ ロード方式による最新情報への更新を頻繁には行わないテーブル。
- 当分の間、パーティションを変更しないテーブル。
- 揮発性の高いデータには、列パーティション テーブルを使用しません。
- COLUMNパーティション化レベルを可能な限り低いレベルに置きます。理想的には、パーティション式の中でどのROWパーティション化レベルよりも低くします。COLUMNパーティション化レベルは、最初に指定するパーティション化レベルにしてください。
列パーティションを低いレベルに置くには、例えば次のような点を考慮に入れます。
- シリンダの移行による改善の可能性
- ホット データとコールド データの両方について温度に基づくブロック圧縮が有効かどうか
- 列を頻繁にアクセスするクエリーで、アクセスする列のセットがリクエストごとに異なる場合は、頻繁にアクセスする列を1つの列パーティションに置いてください。
このようにすると、テーブルに対するクエリーを最適化するために、最適化ルーチンが列パーティションの排除を実行できるようになります。
- 1つのワークロード内のリクエストで同じ列セットを頻繁にアクセスするクエリーの場合は、頻繁にアクセスする列を同じパーティションにグループ化します。
- 自動圧縮が効果的と分かっている列がある場合は、それが頻繁にアクセスされる列でなくても、その列を1つの列パーティションに入れるようにします。
- 自動圧縮が最も効果的なのは、COLUMN形式を指定した、1列で構成されるパーティションの場合です。複数列のパーティションの場合は効果がそれほど高くありません。特に列数が増えるほど効果が下がります。また、ROW形式を指定した列パーティションに対しては効果がありません。
- 次の条件の任意のに当てはまるアプリケーションでは、列を列パーティションにグループ化します。
- 列に頻繁にアクセスするクエリー
- 列に頻繁にアクセスしませんクエリーで、個々の列や列のサブセットの自動圧縮に効果がない場合
- 幅の狭い列パーティションには、COLUMN形式を使用します。自動圧縮に効果があると分かっているパーティションの場合は、特にこれが推奨されます。
列パーティションに対してシステムが決定した形式がCOLUMNでない場合でも、COLUMN形式のほうが適切であると判断できる場合には、テーブルの作成または変更の際に明示的にCOLUMNを指定してください。
COLUMN形式を明示的に指定する必要のある列パーティションとしては、VARCHAR、CHARACTER SET VARGRAPHIC、またはVARBYTEデータ型の列で、大きい最大値が定義されているものの、実際のパーティション値は多くの場合に比較的短いというケースがあります。
このようなケースは、最大値が大きく定義されているためにシステムがROW形式を決定した場合に発生します。
- 幅の広い列パーティションには、ROW形式を使用します。1つまたは少数の値しか保持しないコンテナよりオーバーヘッドが小さいからです。
列パーティションに対してシステムが決定した形式がROWでない場合でも、ROW形式のほうが適切であると判断できる場合には、テーブルの作成または変更の際に明示的にROWを指定してください。
- 最適化ルーチンは、パーティション化されたテーブルへのアクセスの時点で使用できる利用可能なファイル文脈の数を決定するために、DBS制御パラメータPPICacheThrPを使用します。
PPICacheThrPによって決まる利用可能なファイル文脈の数 Teradata Databaseが利用可能と判断するファイル文脈の実際の数 < 8 8 > 256 256 Teradata Databaseは、ファイル文脈の数を、列パーティション テーブルに対して利用可能な列パーティション文脈の数として使用します。
Teradata Databaseは、一部の操作ではファイル文脈を各列パーティション文脈に関連付けることがあります。その他の場合には、各列パーティション文脈にバッファを割り当てることがあります。理想的には、列パーティション文脈の数を、最低でも、1つのリクエストでアクセスする必要のある列パーティションの数と同じにしてください。それより少ないと、必要な列パーティションを一度に読み取ることができないため、パフォーマンスが低下することがあります。
PPICacheThrPを高く設定し過ぎると、パフォーマンスとメモリ使用量が影響を受けます。これは、メモリ スラッシングやシステム クラッシュにつながることがあります。反対に、DBS制御パラメータPPICacheThrPの値を不必要に低く設定すると、パフォーマンスが大幅に低下し、パーティション化する利点がなくなる恐れがあります。
大部分のワークロードに対してはデフォルト値が適切と想定されますが、バランスをとるために調整が必要になることがあります。
- 列パーティション テーブルに対するデフォルトのDATABLOCKSIZE や、DBS制御パラメータPermDBSizeで定義するデフォルトのデータ ブロック サイズは、通常はデフォルトのままで適切です。ただし、パフォーマンス分析の結果によっては、変更が必要です。
- テーブルに対して行を少しずつ追加していくことが想定される場合に、列パーティション テーブルの内部パーティションが小さい時は、追加の空き領域を割り当てることを検討します。このような状況は、たとえば、テーブルが行パーティション化されている場合に起こることがあります。
追加の領域を割り当てるには、テーブルの作成時にシステム デフォルトより大きい値をFREESPACEオプションに指定します。または、データベース管理者がDBS制御パラメータFreeSpacePercentにデフォルト値より大きい値を設定した場合は、その設定を使用します。FreeSpacePercentの詳細については、<Teradata Vantage™ - データベース ユーティリティ、B035-1102>を参照してください。
大規模なINSERT … SELECT文を使用してテーブルに行をロードする予定があり、そのテーブルの内部パーティションが大きいか、データが入っていない場合、追加の空き領域が必要になることはほとんどありません。
空き領域が予約されていると、テーブルのデータを現在のテーブル シリンダ上に拡張して格納できるため、追加のテーブル シリンダを割り当てる必要を回避できるか、遅くできます。これにより、新しいシリンダの割当てに伴うデータ移行を回避できるか、遅くできます。
- 新しいテーブル データを既存のテーブル データと物理的に近接させておき、データの移行を回避すると、システム パフォーマンスを総合的に向上させることができます。
列パーティション テーブルを利用する際には、以下の指針が適用されます。