Dwh-tuning

提供:Dev Guides
移動先:案内検索

データウェアハウジング-チューニング

データウェアハウスは進化し続けており、ユーザーが今後どのクエリを投稿するかは予測できません。 そのため、データウェアハウスシステムの調整が難しくなります。 この章では、パフォーマンス、データロード、クエリなど、データウェアハウスのさまざまな側面を調整する方法について説明します。

データウェアハウスチューニングの難しさ

データウェアハウスのチューニングは、次の理由により難しい手順です-

  • データウェアハウスは動的です。一定のままになることはありません。
  • ユーザーが今後どのクエリを投稿するかを予測することは非常に困難です。
  • ビジネス要件は時間とともに変化します。
  • ユーザーとそのプロファイルは変化し続けます。
  • ユーザーは、あるグループから別のグループに切り替えることができます。
  • ウェアハウスのデータ負荷も時間とともに変化します。

-データウェアハウスの完全な知識を持つことが非常に重要です。

性能評価

ここにパフォーマンスの客観的尺度のリストがあります-

  • 平均クエリ応答時間
  • スキャン率
  • 1日あたりのクエリ時間
  • プロセスごとのメモリ使用量
  • I/Oスループットレート

覚えておくべきポイントは次のとおりです。

  • サービスレベル契約(SLA)で対策を指定する必要があります。
  • 応答時間が既に必要なものより優れている場合、応答時間を調整しようとしても意味がありません。
  • パフォーマンスを評価する際には、現実的な期待をすることが不可欠です。
  • ユーザーが実行可能な期待を持っていることも重要です。
  • システムの複雑さをユーザーから隠すには、集計とビューを使用する必要があります。
  • また、ユーザーが調整していないクエリを作成できる可能性もあります。

データロードチューニング

データロードは夜間処理の重要な部分です。 データのロードが完了するまで、他に何も実行できません。 これは、システムへのエントリポイントです。

注意-データの転送、またはデータの到着に遅延がある場合、システム全体が悪影響を受けます。 したがって、最初にデータロードを調整することが非常に重要です。

以下で説明するデータロードのチューニングにはさまざまなアプローチがあります-

  • 非常に一般的なアプローチは、* SQLレイヤー*を使用してデータを挿入することです。 このアプローチでは、通常のチェックと制約を実行する必要があります。 データがテーブルに挿入されると、コードを実行して、データを挿入するのに十分なスペースがあるかどうかを確認します。 十分なスペースが利用できない場合、これらのテーブルにより多くのスペースを割り当てる必要があります。 これらのチェックは実行に時間がかかり、CPUに負荷がかかります。
  • 2番目のアプローチは、これらすべてのチェックと制約をバイパスし、データを事前にフォーマットされたブロックに直接配置することです。 これらのブロックは、後でデータベースに書き込まれます。 最初のアプローチよりも高速ですが、データのブロック全体でのみ機能します。 これは、スペースの浪費につながる可能性があります。
  • 3番目のアプローチは、すでにテーブルを含んでいるテーブルにデータをロードするときに、インデックスを維持できることです。
  • 4番目のアプローチでは、すでにデータを含んでいるテーブルにデータをロードするには、データのロードが完了したら*インデックスを削除して再作成*します。 3番目と4番目のアプローチの選択は、すでにロードされているデータの量と、再構築する必要があるインデックスの数によって異なります。

整合性チェック

整合性チェックは、負荷のパフォーマンスに大きな影響を与えます。 覚えておくべきポイントは次のとおりです-

  • 整合性チェックは大きな処理能力を必要とするため、制限する必要があります。
  • データ負荷のパフォーマンス低下を回避するために、ソースシステムに整合性チェックを適用する必要があります。

チューニングクエリ

データウェアハウスには2種類のクエリがあります-

  • 固定クエリ
  • アドホッククエリ

固定クエリ

固定クエリは明確に定義されています。 以下は、固定クエリの例です-

  • 定期報告
  • 定型クエリ
  • 一般的な集約

データウェアハウスでの固定クエリのチューニングは、リレーショナルデータベースシステムと同じです。 唯一の違いは、照会するデータの量が異なる場合があることです。 固定クエリのテスト中に最も成功した実行計画を保存しておくと便利です。 これらの実行計画を保存すると、実行計画が変更されるため、変化するデータサイズとデータスキューを見つけることができます。

-ファクトテーブルでこれ以上行うことはできませんが、ディメンションテーブルまたは集計の処理中に、SQL調整、ストレージメカニズム、およびアクセスメソッドの通常のコレクションを使用して、これらのクエリを調整できます。

アドホッククエリ

アドホッククエリを理解するには、データウェアハウスのアドホックユーザーを知ることが重要です。 各ユーザーまたはユーザーのグループについては、次のことを知る必要があります-

  • グループ内のユーザー数
  • 定期的にアドホッククエリを使用するかどうか
  • アドホッククエリを頻繁に使用するかどうか
  • 不明な間隔で時々アドホッククエリを使用するかどうか。
  • 実行する傾向があるクエリの最大サイズ
  • 実行する傾向があるクエリの平均サイズ
  • 基本データへのドリルダウンアクセスが必要かどうか
  • 1日あたりの経過ログイン時間
  • 毎日の使用のピーク時間
  • ピーク時間ごとに実行されるクエリの数

注意事項

  • ユーザーのプロファイルを追跡し、定期的に実行されるクエリを識別することが重要です。
  • また、実行されるチューニングがパフォーマンスに影響を与えないことも重要です。
  • 頻繁に実行される同様のアドホッククエリを特定します。
  • これらのクエリが識別されると、データベースが変更され、それらのクエリに新しいインデックスを追加できます。
  • これらのクエリが識別された場合、効率的な実行につながるクエリ専用に新しい集計を作成できます。