Teradata DBMSのストレージ構造の物理設計

ストレージ構造の物理設計とは

物理データモデルの開発中に追求する主な目標は、主な負荷を作成するクエリ/アプリケーションの最大パフォーマンスを達成する特定のプラットフォーム/ DBMSのオブジェクトを作成し、追加のインデックスのサポートや派生物の実現などの追加コストを削減することですデータなど。
すべてのリレーショナルDBMSは同じ原則に基づいて構築されていますが、各プラットフォームには、さまざまなタイプのオブジェクトの形で独自の機能とその実装の機能があります。 このため、物理モデリングのプロセスは、論理モデリングとは異なり、プラットフォームに依存しています。論理モデリングの主な目的は、データおよびビジネスプロセスを確実に記述することです。

Teradata DBMSのデータストレージ

Teradataプラットフォーム上のデータベースの物理設計については、とりわけ、これはすべてのデータがシステムコンポーネント（AMP）に分散され、ユーザークエリを並列実行するときにそれらによって処理されるMPP（Massive Parallel Processing）プラットフォームであることに言及する必要があります（参照最初の記事 ）。 このようなアーキテクチャは、データの均一な分散と同様に、生産性を確保するための追加要素がない場合でも処理を効果的にします。 この機能により、Teradataは物理モデルの開発者が提供していないアドホックリクエストを完全に処理できます。
しかし、混合負荷の場合、戦術的な（OLTPのような）要求と戦略的な（OLAP、DSS、データマイニング）の両方の要求がシステムで同時に実行されるとき、これは明らかに十分ではありません。 これは、応答時間と帯域幅の要件がかなり高い戦術的な要求に特に当てはまります。 戦術クエリのパフォーマンスを向上させるための主な物理設計手法は、インデックスの作成です。これは、クエリが完全に表示せずにテーブルの目的の行をすばやく見つけるために使用できるデータアクセスパスです。 インデックスを使用すると、クエリを実行する際のI / O操作の数を大幅に減らすことができます。これにより、応答時間が短縮され、結果としてシステムのスループットが向上します。 並列アーキテクチャを考慮して、Teradataでインデックスがどのように配置されるかを見てみましょう。

データにアクセスする方法

Teradata DBMSは、テーブル行にアクセスするさまざまな方法をサポートしています。

プライマリインデックスによるアクセス（ 最初の記事で説明したプライマリインデックスは何でしたか）

これは、Teradataのデータにアクセスするための最速かつ最も安価な方法です。
Teradata DBMSのデータは、プライマリインデックス列の値をハッシュした結果を使用して配布されることを思い出してください。 同じプライマリ列値を持つ行は常に同じAMPに分類されます。

行がテーブルに挿入されるときに配置されるAMPを決定するために使用されるアルゴリズムは、プライマリインデックス列の既知の値を持つ行を見つけるために同じ成功で使用されます。

検索文字列が配置されているAMPが決定されると、Teradataはインデックス構造を使用して必要なデータブロックを見つけます。 順次表示：

• 必要なデータブロックを含むシリンダーを検索するためのマスターインデックス（常にAMPのメモリに読み込まれます）。
• 必要なデータブロックを検索するためのシリンダーインデックス（ほとんどの場合、AMPのメモリにロードされます）。

必要なデータブロックが見つかると、読み取られ、行ポインターの配列（行参照配列）を使用して行が検索されます。

このアルゴリズムは、一意（一意のプライマリインデックス-UPI）と非一意（非一意のプライマリインデックス-NUPI）プライマリインデックスの両方で同じように動作します-唯一の違いは、UPI経由でアクセスする場合、常に1つのデータブロックのみが読み込まれ、一方、NUPI経由でアクセスする場合、これらの値はインデックスの非一意性の程度に依存します。

ベーステーブルの行の形式


Teradataのデータストレージの特性は、各AMPでテーブルの行がランダムな順序で保存されるのではなく、プライマリインデックスのハッシュ値でソートされることです。 この方法では、データを挿入するときに追加の労力が必要になります。これは、「行末」ではなく、ハッシュソートを維持するために新しい行を挿入する必要があるためです。 そうすることで、2つの利点が得られます。

• プライマリインデックス列で結合する場合、行は既に順序付けされているため、有効なMERGE JOIN結合をすぐに適用できます。
• プライマリインデックス列の自動インデックス付け。 上記のファイルシステムの内部インデックス（マスターインデックスとシリンダーインデックス）には、データブロックに格納されているデータのハッシュ値の範囲が含まれています。 行が順序付けられているという事実により、これらの範囲は交差しません。 その結果、データブロックのディスク領域のレイアウトを作成することにより、実際にこのパーティション化だけでなく、プライマリインデックス列のインデックスも取得します。これは、プライマリインデックスのハッシュ値に基づく古典的なBツリーインデックスです。 プライマリインデックスはAMPディスクシステムにデータを格納するための「マスターインデックス」および「シリンダーインデックス」構造の一部であることを念頭に置いて、ディスクスペースを占有せず、メンテナンスを必要としないことさえあります。

このアルゴリズムの機能は、固有の制限も決定します。つまり、プライマリインデックスによるアクセスは、次の条件下でのみ可能です。

• プライマリインデックス列でフィルタリングするためにクエリで条件「等しい」を使用します。
• プライマリインデックスを構成するすべての列を検索条件に含めます。

セカンダリインデックスアクセス

セカンダリインデックスは、データにアクセスするための代替方法です。 インデックスサブテーブルの形式で実装され、インデックス列の値がベーステーブルの対応する行識別子を決定できるようにします。

一意（一意のセカンダリインデックス-USI）と非一意（非一意のセカンダリインデックス-NUSI）のセカンダリインデックスのインデックスサブテーブルの実装は異なります。

USIインデックスサブテーブル行形式


USIインデックスサブテーブルの行は、インデックス列のハッシュを使用してAMP間で分散されます。 高い確率で、インデックステーブルの行は、ベーステーブルAMP'eの対応する行に関連して別の行になります。 ベーステーブルの各行は、インデックスサブテーブルの行に対応します。 USIを使用してデータにアクセスするには、2つのAMPの関与が必要です（1つ目はインデックス内の行を検索し、2つ目は識別子によってベーステーブルの行を読み取ります）。 USIを使用したデータへのアクセスは、プライマリインデックスを使用するのと同じくらい効果的と考えることができます。 USIの主な目的は、インデックス列の値によってデータにアクセスすることです。 プライマリインデックスの場合と同じように、式「WHERE」は、条件「EQUAL」でインデックスを構成するすべての列を示す必要があります。



NUSIインデックスサブテーブル行フォーマット



NUSIインデックスサブテーブルの行は、ベーステーブルの行に対してローカルに（同じAMP上に）配置され、デフォルトでは、セカンダリインデックス列のハッシュ値によって論理的にソートされます。 このようなストレージは、同じインデックス列値を持つ行がシステム内の任意のAMPで見つかるため、すべてのAMPがインデックスサブテーブル内の必要な行の検索に関与することを意味します。 さらに、インデックスサブテーブルの行が選択されているAMPのみが、ベーステーブルから行を選択するために使用されます。 オプティマイザーがNUSIを使用してデータにアクセスするかどうかは、インデックスの選択性に依存します。 値として、オプティマイザーが全表スキャンを選択すると、1％に集中できます（照会中に1％未満の表行が選択された場合、索引が使用されます）。 ルールは次のとおりです。NUSIの統計を収集します。統計なしでは、オプティマイザーはFTSを選択します。



PIおよびUSIと同様に、デフォルトでは、値によって行にアクセスするためにNUSIが使用されます（条件は「WHERE」式のすべてのNUSI列で「EQUAL」です）。 しかし、これに加えて、NUSIはテーブル行への範囲アクセスを持つクエリにも使用できます。このオプションには、インデックス列の値でインデックスサブテーブルの行を論理的にソートするオプション「ORDER BY VALUES」があります。 この方法で作成されたインデックスを使用すると、「EQUAL」以外のインデックス列の条件でパフォーマンスを改善できます。<、>、> =、<=、BETWEEN。

また、インデックスサブテーブルの行形式からわかるように、ベーステーブルの複数のRowIDがインデックス列の1つの値に該当する可能性があります。 これにより、NUSIインデックスサブテーブルが自動的に圧縮可能になり、ディスク使用量が最小限に抑えられます。

全表スキャン（全表スキャン、またはFTS）
このアクセス方法について特に言及することはありません。 Teradataは、オプティマイザーの観点からデータにアクセスする他の方法が効果的でない場合に使用します。 多くのAMPがそれらに分散されたテーブルのフラグメントを同時にスキャンするため、Teradataでのフルビューによる行の検索はMPPアーキテクチャにより非常に効果的です。 多くの場合、数百万の行を含むテーブルを完全に読み取るには、各AMPがほんの数回のI / O操作を完了する必要があります。

プライマリ/セカンダリインデックステーブルのデータへのアクセスのこのレビューの最後に、代替がある場合、Teradataはセカンダリプライマリよりもプライマリインデックスを優先し、非ユニークにユニークであることに注意してください。



1.オプティマイザは、セカンダリよりもプライマリインデックスを優先し、非ユニークよりもユニークインデックスを優先します。 1つのデータブロックが要求された場合（1 I / O）にのみ、NUPIが優先されます。
2.選択性に応じて、オプティマイザーはNUSI、NUSI Bit Mapping、またはFTSを使用する場合があります。
3.それはすべて、インデックスの選択性に依存します。

テーブル結合アクセス

データにアクセスする別の方法は、2つ以上のテーブルを結合することです。 このプロセスには、MPPプラットフォーム固有の非常に重要な機能が1つあります。 テーブルの結合はAMPによって実行され、結合に参加するデータは対応するAMP上に存在する必要があるという事実にあります。
覚えているように、AMPによるテーブル行の分布はプライマリインデックスに依存し、結合列の値が同じ結合テーブルの行は、常に同じAMPにあるとは限りません。 したがって、常にではありませんが、多くの場合、テーブルの結合の前に準備操作が行われます。 例外は、プライマリインデックス列の2つのテーブルの組み合わせです。この場合、プライマリインデックス列と同じ値を持つ行は既に同じAMPにあるためです。 PIカラムによるテーブルの結合が最速です。

他のすべての場合にテーブルの結合を実行するために、Teradataは、次の方法で同じAMPに同じ結合列の値を持つ行があることを確認できます（重要：派生データセットはすべて、中間クエリ結果の一時記憶領域であるSPOOLでマテリアライズされます）：

• すべてのAMPの小さなテーブルの行の複製。
• 結合列に沿った結合ステップの一方/両方のテーブルの行の再分配（PI変更）。 この場合、テーブル自体はそのまま残り、クエリに参加する行の一時コピー（必ずしもテーブル全体ではない）が異なるプライマリインデックスで作成されます。
  上記のどの方法がオプティマイザーによって選択されるかは、データの人口統計、収集された統計およびインデックスの可用性に依存します（Teradataは接続パフォーマンスを改善するために、NUSIなどのいくつかのタイプのインデックスを使用できます）。

AMPで必要なデータが提供されると、Teradataは次のような従来のテーブル結合戦略を使用できます。

• MERGE JOIN：
  • 行ハッシュ;
  • 包含物
  • 除外
• PRODUCT JOIN;
• ネストされた参加;
• HASH JOIN。

高品質の物理設計を完了するために必要なもの

論理モデル

物理モデリングの直接的な方法は、伝統的に論理モデルの作成が先行しており、これは後にデータベースオブジェクトを作成するためのテンプレートとして機能します。 優れた論理モデルの構造は、1対1のデータベースに実装できます。
企業のデータウェアハウスに関連して、論理モデルはすべての組織のビジネスプロセスの記述です。 ビジネスの既存の問題を解決するだけでなく、さらなる発展をサポートするような方法で実装する必要があります。 このようなモデルをゼロから作成することは非常に簡単で時間のかかる作業であり、主題分野とモデリング技術に関する優れた知識が必要です。 この記事では、論理モデリングの問題については説明しません。プロジェクトでは、時間と多数の実装でテストされた業界で実績のあるTeradataの論理モデルを使用しようとしていることにのみ注意します。 欧米のモデルをロシア市場での使用に適さないと考える人にとって、実際にはローカリゼーションの作業量（または、同じプロセスを持つ組織は一般的ではないため、モデルを顧客プロセスに適応させる）は小さく、多くの場合、属性構成の拡大に帰着することに反対しますモデルに既に存在するエンティティ。

データ

もちろん、「真空」でシミュレートすることもできますが、物理モデルの場合、後でモデルにロードされるデータを目の前で確認することが非常に重要です。 これにより、論理モデルから物理モデルへの移行方法を決定できます。 1対1の物理モデルは論理モデルに対応すると考えている人もいますが、これは常にそうではありません。 たとえば、データ分析の結果として、論理テーブルの複数のエンティティを物理テーブル内の単一テーブルの形式で実装することが決定される場合があります。 これはほんの一例です。

人口統計

論理モデルがどれほど優れていても、エンティティと関係のセットだけでは高品質の物理設計を実行するには不十分です。データの詳細とその使用の性質を理解する必要があります。 通常、いくつかの人口統計を分析します。

• データ人口統計-データ量、頻度図など。
• 変動の人口統計-テーブルの特定の列のデータが変更される頻度。
• 使用統計-値（単一または値の範囲）または接続によってデータにアクセスするために列が使用されるかどうか。

上記の人口統計を知ることで、物理モデルの作成者は意識的な選択をすることができます。
明らかに、これらの人口統計のすべてがモデルを使用する前に知られているわけではありません。 特に、データにアクセスする方法と、特定のモデル列に100％99％アクセスする頻度は、長期間のストレージ操作の後で初めてわかります。 ただし、モデル自体の実装のロジックに基づいて、かなり多数のアクセス方法を事前に検討することができます。

忍耐とマインドフルネス

物理モデリングは魅力的なプロセスですが、必ずしも明確にアルゴリズム化されているわけではありません。 ソビエトの有名な漫画の性格を言い換えると、「物理モデリングは正確な科学ではありません。」 一方で、これは創造性の機会を提供しますが、一方で、時間、注意、そしてしばしば反復的なアプローチが必要です。そのため、大規模なデータモデルを扱う際の詳細と忍耐への注意が物理モデリングで重要な役割を果たします。

インデックス選択

インデックスは、特定の使用パターンに合わせて物理モデルを最適化する主な方法の1つとしてよく使用されます。 インデックスの選択が明らかな場合があります。 明らかなことが必ずしも真実ではない例を見てみましょう。
次の表を想像してください：ACCOUNT（1,000,000行）

Acct_id	Acct_num	Acct_open_dt	Acct_close_dt	Acct_pty_id
PK	NOT NULL、一意	NOT NULL		NOT NULL、FK
UPI	USI	NUSI	NUSI？	NUSI

3行目には、提案されたインデックスの選択が含まれています。
凡例：

• UPI（一意のプライマリインデックス）
• NUPI（非ユニークプライマリインデックス）
• USI（一意のセカンダリインデックス）
• NUSI（非ユニークセカンダリインデックス）

この選択が正しいものであると確実に言えますか？ 特定のDBMSの物理モデルを作成した経験から正しい選択が示唆されると思いますが、一般的な場合、選択が正しいと言うことはできません。 上記の例について言えば、たとえば、次の質問をすることができます。このテーブルでの検索はアカウント識別子によって実行されますか？ 答えが「いいえ」の場合、プライマリインデックスの候補からAcct_id列を除外できます。
単純な例は、最高の論理モデルでさえ物理モデルを作成するには不十分であることを示しています。 データ人口統計の理解が必要です（上記を参照）。 上記の例を人口統計で補完し、これによりタスクが簡単になるかどうかを確認します。
同じACCOUNTテーブル（1,000,000行）

	Acct_id	Acct_num	Acct_open_dt	Acct_close_dt	Acct_pty_id
	PK	NOT NULL、一意	NOT NULL		NOT NULL、FK
値によるアクセス頻度	800	10K	1K	500	1K
接続アクセス頻度	3K	0	0	0	5K
ユニークなライン	1000K	1000K	731	256	40万
マックス 値ごとの行数（NULL以外）	1	1	2056	1K	7
値ごとの典型的な行数	1	1	1235	400	2
NULL行の数	0	0	0	900K	0
推定選択	UPI	USI	NUSI	NUSI	NUSI
人口統計ベースの選択	NUSI	USI	NUSI	NUSI？	ヌピ

ご覧のとおり、インデックスの最初の選択が変更されています。 これには非常に客観的な理由があります。

• 列Acct_pty_idの場合
  プライマリインデックスアクセスは、Teradataで最も効率的なデータアクセス方法です。 例からわかるように、この列の値によるアクセスは頻繁に発生します。 さらに、別のテーブルに接続するために同じ列が最も頻繁に使用されます。 プライマリインデックス列に沿って2つのテーブルを結合することも、Teradataに最も適しています。
• 列Acct_idの場合
  この列は、アクセスにも頻繁に使用されます。 プライマリインデックスの選択は既に行われているため、値によってテーブルの行を最も効率的に読み取るための一意でないセカンダリインデックスを作成し、接続のパフォーマンスを向上させることができます。
• 列Acct_close_dtの場合
  インデックスの選択は、特定の値（NULL）に対して選択性が不十分なためTeradataがインデックスを使用しないという事実により、疑問視されています。

Teradataのテーブルのパーティション分割

テーブルのボリュームが大きい場合、テーブルを完全に表示するのではなく、テーブルを複数の部分（パーティション）に分割し、これらのパーティションのみをスキャンするのが自然な欲求です。
Teradataでは、次の2つのメカニズム（AMPの配布とパーティション化）が相互に効果的に補完します。 パーティションテーブルは、非パーティションテーブルと同じ方法でAMP間で分散されます。 さらに、各AMPでは、行がパーティションごとに最初にソートされ、パーティション番号がデータブロックのアドレス指定のためにマスターインデックスとシリンダーインデックスに記録されます。 そして、パーティション内では、行はすでにプライマリインデックスのハッシュ値と、パーティション化されていないテーブルでソートされています。
したがって、「partition_ column BETWEEN value1 AND value2」タイプのクエリを実行すると、すべてのAMPが並行して動作し、テーブルの各フラグメントをスキャンしますが、完全ではなく、必要なパーティションのみをスキャンします。
複数の列がある場合は、マルチレベルのパーティションもあります-同時にパーティション内にサブパーティションが作成されます。
通常、すべての大きなテーブルはパーティション分割されます。 この物理的な設計手法により、パーティションフィールドでフィルタリングされる特定のクエリのパフォーマンスを向上させることができます。

おわりに

この記事では、Teradata DBMSのデータベースの物理設計で使用される基本原則と要素の説明に限定することにしました。 作業でこれらのプラクティスのみを使用すると、大規模並列DBMSで作業を始めたばかりの人たちにとって、最初の段階で「レーキ」を踏まないようにすることができます。
次の記事「Teradataの高度な物理モデリング技術」では、Teradataのデータのインデックス作成と圧縮の追加機能について説明する予定です。
質問を待っています。