Teradataの高度な物理モデリングテクニック

Teradata DBMSでの物理モデリングテクニックに関する資料の公開を続けて 、前の記事で約束したように、通常のインデックスに直接関連しない追加のテクニックについて話したいと思います（ただし、この記事では、知っておく必要のある特別なタイプのインデックスについて触れます）。



通常のインデックスに加えて、Teradata DBMSには、物理​​モデリングで使用できる特定の、時には微妙なテクニックが多数含まれています。 以下に、ほとんどのテクニックの説明を示します。質問がある場合、または詳細を知りたい場合は、コメントでお答えします。

結合インデックス

これは特別な種類のインデックスで、SQLクエリの保存および更新された結果です。 クエリにはテーブルの結合が含まれる場合があるため、インデックスにはこのような名前が付いています。 ただし、テーブル結合がない場合があります。この場合、インデックスは単一テーブル結合インデックスと呼ばれます。 この手法は、複数のテーブルを結合したり、集計を実行したりするための頻繁なクエリがある場合に検討する必要があります。 ユーザーからSQLクエリを受信すると、Join Indexデータのみを使用できるため、オプティマイザはこの方法を選択する可能性が高くなります。 たとえば、ユーザーが要求した十分なフィールドがインデックスにない場合、オプティマイザにJoin Index'aとベーステーブルを結合する方法を理解させる方法もあります。 これは、結合インデックスに「ROWID」フィールドを含めることで行われます。DBMSは、必要に応じて、インデックスをベーステーブルに効率的に結合できます。



インデックスは、幅（ベーステーブルの列数）だけでなく、深さによっても制限できます。 結合インデックスを作成するときに、WHERE句を指定すると、必要なデータのみがインデックスに含まれます。 このメソッドは、非常に特定のフィルタリング条件を持つクエリを最適化するのに適しています。 次に、それらをインデックスに含めることで、そのボリュームを削減し、消費されるリソースを最小限に抑えることができます。 ただし、このインデックスは、インデックスの作成時と同じ（またはより厳密な）フィルタリング条件を持つクエリを処理する場合にのみ、オプティマイザによって考慮されることを覚えておく必要があります。



さらに、結合インデックスはテーブルとほぼ同じであるため、インデックスを作成して統計を収集できます。

ハッシュヌシ

デフォルトでは、NUSIインデックスは、構築されたベーステーブルと同じ方法でAMP間で分散されます。 これにより、AMP間でインデックスが均一に分散され、使いやすくなります。 各AMP内で、NUSIはすべての列のハッシュ値でソートされます。 ただし、インデックス内の特定のフィールドのハッシュ値でソートされるようにインデックスを作成することは可能です。 このようなインデックスは、等価条件でクエリのパフォーマンスを大幅に最適化します。 インデックス列と比較された値はハッシュされ、このハッシュはインデックスですばやく検索されます（インデックスはソートされます）。

値順NUSI

ただし、ハッシュによる並べ替えに加えて、特定のフィールドの値によるインデックスの並べ替えを設定できます。 このようなインデックスを使用すると、フィルタリング条件として範囲または不等式条件を持つクエリを最適化できます。 このようなインデックスを作成すると、指定されたフィールドでソートされ、ディスクに保存されます。 ソートされたリストで範囲を見つけることの利点は、コメントを必要としないと思います。

データの意図的な「スキュー」

Shared Nothing MPPシステムは、データを最も均等に分散させて最高のパフォーマンスを実現します。 この問題は、この記事や他の記事で大きな注目を集めています。 しかし、意図的にデータの「スキュー」を作成することが理にかなっている場合があり、これはパフォーマンスにプラスの影響を与えます。



たとえば、144個のAMPがあるシステムがあるとします。 また、小さなディレクトリがあり、たとえば200のレコードがほぼ均等に分散されています。 ディレクトリからデータを選択すると、144個すべてのAMPがディスクを使用して、それぞれ1つまたは2つのレコードを抽出します。 このような些細な操作のために非常に多くのAMPに負担をかけることは理にかなっていますか？ このような状況では、データの人為的な「スキュー」を作成できます。そのためには、ディレクトリに空の列を追加し、プライマリインデックスにして、同じ値を入力する必要があります。 この場合、テーブルにアクセスすると、1つのAMPのみが機能します。これにより、すべてのレコードが迅速に抽出され、他のすべてのAMP間で再配布されます。 このアプローチは、このようなすべての場合に使用することはお勧めできません。これを実行できることに留意してください。 そして、これが特定のケースで利益をもたらすかどうかは、すでに別の問題です。

参照整合性

Teradataは、他のリレーショナルDBMSと同様に、参照整合性のサポートを提供します。 しかし、Teradataには、言及したい多くの機能があります。 最初の機能は、参照される親テーブルの列を主キーとして宣言する必要がないことです。 Teradataでは、これらの列がプライマリまたはセカンダリの一意のインデックスを形成することのみが必要です。 ただし、Teradataの一意性に対する制限は物理的に一意のインデックスに変換されるため、PKの定義は手頃な価格のオプションのままです。



その他の機能は、個々の種類の参照整合性に関連しています。

標準ri

標準の参照整合性チェック。 挿入、変更、または削除された行ごとに実行されます。 次のコマンドによって追加されました。

ALTER TABLE Employee ADD CONSTRAINT fk1 FOREIGN KEY (Dept) REFERENCES Department (Dept);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Teradataでのこのタイプの参照整合性の実装の特性は、既存のテーブルに追加されると、条件に違反した場合でも、制限が作成されてアクティブ化されることです（参照整合性に違反する操作は実行できません）。 この場合、Teradataは、子テーブルの名前に接尾辞「_0」を追加したエラーテーブルを自動的に作成します。このテーブルには、参照整合性の包含時に条件を満たさなかった子テーブルのレコードが配置されます。 将来、ユーザーはこれらの関係の問題を解決し、エラーテーブルを削除する責任があります。 この実装により、参照リンクの整合性を有効にしてアクティブにするためのテーブルリンクの問題の解決を待たずに、問題の存在（エラーテーブルがあります-問題があります）を検出し、その規模を調整し、修正措置を講じることができます（エラーテーブルのすべての問題行）。

バッチri

Teradataでのこのタイプの参照整合性の実装には、機能はありません。 これは、DMLコマンドの実行の最後に実行され、違反の検出はトランザクション全体のロールバックにつながり、作成時の違反の存在はエラーにつながります。 次のコマンドによって追加されました。

 ALTER TABLE Employee ADD CONSTRAINT fk1 FOREIGN KEY (Dept_Number) REFERENCES WITH CHECK OPTION Department (Dept_Number);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ソフトり

このタイプの参照整合性は、Teradataに固有のものです。 上記のいずれのタイプも、オプティマイザーを支援すると同時に、正直にチェックを実行することによりシステムの負荷を増加させます。 Soft RIは、テーブルに追加してもデータ接続を制御するメカニズムが含まれないため、「信頼参照整合性」と呼ぶことができます。 この制限を作成すると、テーブルAとテーブルBの相互関係に関する情報がデータディクショナリに追加されるだけです。 優れたデータ品質で、オプティマイザーにより多くの情報を提供し、コストのかかる参照整合性チェックを除外します。 次のコマンドによって追加されました。

 ALTER TABLE Employee ADD CONSTRAINT fk1 FOREIGN KEY (Dept_Number) REFERENCES WITH NO CHECK OPTION Department (Dept_Number);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

RIはオプティマイザーに何を提供しますか？

テーブル（上記のタイプのいずれか）に定義された参照整合性制約の存在により、オプティマイザーは結合の削除を実行できます。つまり、親テーブルの列部分をSELECTまたはWHEREに含まないクエリを実行するときにテーブルを結合しません。

ビューがあります

 REPLACE VIEW EmpDept AS SELECT Employee_Number, Last_Name, First_Name, E.Dept_Number, Dept_Name FROM Employee E INNER JOIN Department D ON E.Dept_Number = D.Dept_Number;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

、Departmentは親であり、Employeeは参照整合性が定義されているテーブルの子です。



次のリクエストが実行されると、接続は実行されません。 親テーブルの列にはアクセスしません。

 SELECT Employee_Number, Last_Name, Dept_Number FROM EmpDept;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注：Soft RIを使用する場合は、データの品質を確認してください。そうしないと、接続の例外により誤った結果が生じる可能性があります。

データ圧縮

前述のように、物理データモデルを最適化する主なタスクの1つは、入出力操作の数を減らすことです。 データに圧縮が適用されると、ディスク容量が少なくなり、ブロック読み取りが少なくなります。 ただし、その後、データを解凍する必要があり、追加のリソースが必要になります。



データ圧縮は、ソフトウェアとハ​​ードウェアの両方で実装できます。 物理設計のトピックの一部としてハードウェア圧縮を検討するのではなく、ソフトウェアについてさらに詳しく説明します。



圧縮を適用することは、実際にかなりの量を占めるテーブルに意味があることに注意してください。 テーブルが既に小さい場合、圧縮を使用することの重大な利点に気付くことはほとんどありません。

ヌル圧縮

すぐに同意します-このセクションでは、空の値はNULLのみを意味します。 NULLは「無」であり、空の意味ではないという哲学的な議論は歓迎されますが、コメントで。



固定サイズの列に多くのNULLが含まれるテーブルがある場合、テーブル内のエントリの数が多い場合、NULLの圧縮を検討するのは理にかなっています。 これは非常に簡単に行われます-列属性の後にテーブル（またはALTER'e）を作成するためのDDLコードでは、単語「COMPRESS」が示されます。 したがって、システムはテーブルを分析し、NULLが存在するすべての列に特別なビットを配置します。つまり、「NULLでしたが、圧縮してなくなった」という意味です。

特定の値の圧縮

テーブル内のNULLに加えて、値が見つかることがよくあります。 たとえば、統計的な観点から見た姓の場合があります。たとえば、イワノフです。 統計的に頻繁に検出される値を区別できるフィールド（特に文字列）は、圧縮の適切な候補です。 例外がある場合があります-たとえば、クライアントのステータスをテキストで保持することにします（理由を尋ねないでください）。 HDのクライアントテーブルは通常、数千万のレコードです。 「アクティブ」、「非アクティブ」、「ブロック」という限られたステータスのセットを使用すると、数千万件のレコードの圧縮を適用してコストを削減できます（この例では、VARCHAR（16）から2ビットに）。



圧縮の値のリストは、列ごとに個別に指定できます。 このようなリストはテーブルヘッダーに格納され、テーブルにアクセスすると、圧縮された値（フラグ）は実際の値に置き換えられます。 この操作による追加の負荷は非常に小さいため、無視できます。



モデルを設計するときは、この記事で何度か言及したデータ人口統計に注意してください。 テーブルに数百万のレコードが含まれ、一部の値を圧縮できる場合、これを行うことにより、テーブルへのクエリを高速化できます。

ブロックレベル圧縮（BLC）

ブロックレベル圧縮（BLC）は、データのブロック全体がディスクに直接書き込まれる前に、データのブロック全体に適用される圧縮の一種です。 このタイプの圧縮は、システム全体または個々のテーブルのいずれかに使用できます。 このタイプの圧縮では、プロセッサの負荷を増やすことでディスク容量が増加するため、この場合、これがどのように適しているかを理解することが重要です。



テーブルでこのタイプの圧縮を有効にすると、ブロックの物理的な外観に影響するため、無効にすることはできなくなります。圧縮せずにテーブルを上書きしてから完全に置き換える必要があります。

列圧縮

以前の記事（ Teradata DBMSの列およびレコードのハイブリッドストレージ ）で説明したように、Teradata DBMSはレコードの列ストレージと小文字の両方をサポートしています。 物理データモデルを設計する場合、各オプションから最善を引き出す必要があります。 テーブルの列ストレージを使用する場合、自動圧縮の使用が可能です。 そのアルゴリズムは、データブロックに1つの列の値が含まれている場合、それらの圧縮の確率が非常に高いという事実に基づいています（特にこれらが一意でない値である場合）。 1つの列の値はコンテナレベルで圧縮されます（上記の記事を参照）。 圧縮が特定の値に対してゲインを与えないとシステムが判断した場合、単にそれを圧縮しませんが、圧縮する意味があると判断した場合、どの組み込み圧縮アルゴリズムが最大のゲインを与えるかを確認して使用します。 たとえば、「balance」フィールドで自動列圧縮を有効にすることを決定した場合、大きな勝利を得ることはほとんどありません。通常、各クライアント/サブスクライバーは独自のバランスを持ち、これは一意に近いものです。



モデルの作成者にとって、これはただ1つのことを意味します。ストレージの列タイプでテーブルを作成することに決めた場合、これはあなたにとって意味があります。 もしそうなら、人口統計を分析します-おそらくあなたは自動圧縮を有効にする必要があるいくつかの列について。

何を選ぶ？

次の表は、圧縮の種類を決定するのに役立ちます。

	特定の値の圧縮	ブロック圧縮	列圧縮
使いやすさ	よく研究されたデータに簡単に適用できます。	電源を入れて忘れました	電源を入れて忘れました
分析が必要ですか？	データ人口統計を分析する必要がある	CPUコストと引き換えにスペースの増加を分析する必要があります	表のどの列に圧縮を含めるか、どの列に意味がないかを理解する必要があります
柔軟性	多数の状況とデータ型で機能します。	他のタイプの圧縮との組み合わせが可能です。	列ストレージを持つテーブルにのみ適用できます。
影響力	CPU消費への影響は最小限	CPUに影響	各行について、圧縮されているかどうかが判断されます。
応用分野	特定の値を置き換える	すべてのデータを圧縮する	テーブル全体から列のセットを圧縮する

物理設計結果

物理モデリング作業の結果は、システムリソースの最小コストでメインユーザーの負荷に必要なパフォーマンスを提供するDBMSオブジェクトのセットである必要があります。

• まず、これらはテーブル（圧縮パラメーターなどのストレージ属性を含む）とプライマリインデックス（セクショニングパラメーターを含む）であり、システムリソースの追加支出を必要としません。 理想的には、プライマリインデックスは、それらが作成されたテーブルの行にアクセスし、AMPでローカルテーブル結合スクリプトを最大限に使用するための基本的なニーズをカバーする必要があります。 プライマリインデックスの作成は、Teradataプラットフォームの必須の物理設計プログラムの一部です。
• 必要なテーブル行への代替アクセスパスを提供するように設計されたセカンダリインデックス。 プライマリインデックスとは異なり、システムはサポートに追加のリソースを費やす必要があるため、作成を決定するときは、サポートの使用とリソースの支出のメリットを比較検討する必要があります。 未使用のセカンダリインデックスは削除する必要があります。
• 第三に、これらは目的のパフォーマンスを達成するために作成する必要がある他のオブジェクトです。 このようなオブジェクトには、たとえば、さまざまな種類の結合インデックスとハッシュインデックスが含まれます。

生涯を通じて、物理モデルは定期的に改訂される必要があります。 これは、データの人口統計の変化だけでなく、負荷の性質、モデルの拡張などの変化も原因です。

まとめると

注意深い読者は、データモデルの物理設計のプロセスが準備のプロセス（モデルの実装前）と改良のプロセス（実装後の改善）であることをすでに理解しています。 負荷とデータを100％推測することはできませんが、50％では可能です。 次回は60％可能になり、やがて80％になる可能性があります。 したがって、タッピングにかかる​​時間はますます少なくなります。 物理モデルの設計スキルは経験とともに向上するため、実装する実験やプロジェクトが多いほど、将来のモデルの操作方法をよりよく想像できるようになります。



基本を学び、実験することを恐れないでください。 この記事で説明されているデータ、インデックスの選択基準、物理モデリング手法を備えたTeradata DBMS操作メカニズムが、DBMSを既に使用している専門家にとって有用であり、まだ行っていない人に関心をもたらすことを願っています。



そして、いつものように、私たちはあなたが持つかもしれない質問にコメントで答える準備ができています。