SQL Server 技術資料

著者: Erik Veerman (Solid Quality Mentors)

技術レビュー担当者: Mark Theissen、Scotty Moran (Val Fontama)

公開日: 2009 年 2 月

対象: SQL Server 2008

要約: このホワイト ペーパーでは、SQL Server® Fast Track Data Warehouse の概要とガイドを提供します。Fast Track Data Warehouse は、(SMP) SQL Server ベースのデータ ウェアハウスのスケールアップ ソリューション向けに作成された一連の新しい参照アーキテクチャです。ここでは、この参照構成で使用可能なリソース、このアプローチの特徴的機能、および新しいアーキテクチャを最大限に活用するために必要な手順の概要について説明します。

はじめに

アプリケーション ソリューションのパフォーマンスと安定性は、基幹業務でも、トランザクションでも、ビジネス インテリジェンス (BI) でも、ソリューションの設計とハードウェア プラットフォームによって決まります。適切なソリューション アーキテクチャを選択する際 (特に BI ソリューションのアーキテクチャを選択する際) は、アプリケーション本来の目的や想定される使用法と、ハードウェア プラットフォームのコンポーネントとのバランスを取る必要があります。多くの場合、計画が不十分だったり、設計に問題があったり、ハードウェアの構成や規模が不適切だったりすると、絶えず不要なコストが発生し、さらに悪くすればプロジェクトが失敗します。

このホワイト ペーパーは、マイクロソフトの新しい SQL Server Fast Track Data Warehouse 参照アーキテクチャに付属するリソースです。この参照アーキテクチャでは、構成済みかつテスト済みのアーキテクチャと、BI ソリューションのデータベース コンポーネントとハードウェア システムに関するアーキテクチャ ガイダンスを提供します。Fast Track 参照構成のリソースによって、計画ツール、アーキテクチャ上の意思決定のためのガイダンス、設計とチューニングのベスト プラクティス、Dell と HP が提供する具体的なハードウェア構成、およびあらゆるハードウェア プラットフォームで新しい参照構成を作成するために必要なツールが提供されます。

Fast Track 参照構成の最終目的は、Microsoft SQL Server ベースの BI ソリューションのデータベース層向けのハードウェアとアーキテクチャを、憶測ではなく、正当な理由に基づいて決定できるようにすることです。Fast Track 参照アーキテクチャを使い始め、そのアプローチと価値を理解し、最適なソリューションを実装できるようにするために、このホワイト ペーパーでは以下の点について説明します。

• 新しい Fast Track 参照アーキテクチャの概要
• BI の基本原理とハードウェアに適用可能な考慮事項の確認
• Fast Track 参照アーキテクチャのテスト済みコンポーネントとオプション
• ソリューションの設計と最適化に関する規範的なガイダンス
• 新しいハードウェア構成を選択または作成するのに役立つリソース

Fast Track Data Warehouse 参照構成では、一般に "データ ウェアハウス" または "データ マート" と呼ばれる、BI ソリューションの中心的データベース コンポーネントに重点を置いています。Fast Track 参照構成は、1 台のサーバーに推定で最大 32 TB のデータが格納されるソリューションを対象とします。

このホワイト ペーパーの対象読者は、IT 役員とマネージャー、ソリューション アーキテクト、IT インフラストラクチャ プランナー、プロジェクト マネージャーなどです。BI ソリューションの所有、管理、計画、または設計を担当している方は、このホワイト ペーパーをお読みいただくと、ソリューションについて最善の意思決定を行うために必要なスキルとリソースを得られます。

Fast Track Data Warehouse アーキテクチャの概要

既存のアプリケーションでパフォーマンスやスケーラビリティの問題に直面したとき、あるいは新しいソリューションのテストの段階で、「もっと容量の大きなサーバーを購入するか、高速なハード ドライブを入手するか、メモリを追加しませんか」という提案を耳にしたことがあるでしょう。

ハードウェアで問題を解決しようとしても、コスト削減や長期的な成功につながることはめったにありません。核心となる問題に対処せず、包括的な調査や計画を実施しないで処理速度の速い大型コンピューターを反射的に導入しても、深刻な問題が一時的に棚上げされるだけです。

では、BI ソリューションのパフォーマンスを計画したり、パフォーマンスの問題に対処したりする場合は、どのようにするのが適切でしょうか。もちろん、その答えはソリューションの種類、使用目的、および実際上または想定上の使用負荷によって異なります。メモリの使用量はそのアプリケーションに固有になりますが、大半のアプリケーションの使用方法は、さまざまな一般的カテゴリに分類されます。種類が共通するアプリケーションには定量化できるアクティビティのパターンがあるため、その種類のアクティビティ専用に設計および構成できます。

たとえば、BI ソリューションのアクティビティと、ERP システムなどのトランザクション ソリューションのアクティビティはまったく異なります。BI システムでは、大きなデータ セットを集計、フィルター処理、およびピボット処理するクエリへの応答に重点を置きます。それに対して、トランザクション システムでは、アクティビティやイベントの詳細レコードが管理されるため、ほとんどの場合、BI システムに比べて小さなデータ セット (通常、個別のレコード) が扱われます。

BI ソリューションの設計で最もよくある間違いは、ハードウェアとアーキテクチャをトランザクション システムの場合と同様に構成してしまうことです。Fast Track 参照構成では、アーキテクチャ ガイダンスとハードウェアの設計パターンを用意することで、この間違いを防げるようにしています。このような参照構成を使用することで、"ビジネスに付加価値をもたらす" という BI システム本来の目的に力を注ぐことができます。

Fast Track 参照構成には、次の 3 つの主要リソースが付属しています。

• 背景情報と計画ツール: このホワイト ペーパー (「Fast Track Data Warehouse アーキテクチャの概要」) では、Fast Track 参照アーキテクチャを使用するための全般的な背景情報と価値について説明しています。また、別のより詳しいホワイト ペーパー (「SQL Server Fast Track Data Warehouse の実装」) では、構成済みのハードウェア アーキテクチャについてまとめているだけでなく、参照アーキテクチャのアプローチについてわかりやすく詳細に説明しています。
• ハードウェア参照構成の選択肢: データ ウェアハウスのワークロード (シーケンシャル データ アクセス) には、5 つの詳細参照構成が適しています。このような Fast Track 参照構成は、Dell と HP のプラットフォームを基盤として構築されており、BI ワークロード用に最適化されたすべてのシステム コンポーネント (サーバーと CPU の構成、ストレージの設計、I/O チャネルの構成など) のバランスを取ります。また、提供される SMP Reference Calculator (SMP 参照計算) と呼ばれる Microsoft Excel 構成スプレッドシートを利用して、さまざまなハードウェア コンポーネントを使用して、新しいハードウェア参照アーキテクチャに基づく構成を作成することもできます。
• 最適化とメンテナンスに関する規範的なガイダンス: 参照アーキテクチャに関する詳細ホワイト ペーパー (「SQL Server Fast Track Data Warehouse の実装」) により、インデックス作成、パーティション分割、およびデータ読み込みのベスト プラクティスと、継続的なメンテナンスによってデータ ウェアハウスを最適化する方法についての詳細なガイダンスが提供されます。

ここからは、Fast Track Data Warehouse 参照アーキテクチャの価値、重点を置いている対象、提供するツール、および参照構成を最大限に活用して組織向けに最適な BI ソリューションを構築する方法の概要について説明します。

Fast Track アーキテクチャのメリット

Fast Track 参照構成の目的は、BI ソリューションに適したアーキテクチャと構成を特定するのに役立つガイダンスとリソースを提供することです。これらのベスト プラクティスとガイダンスによって、以下のような、明確なコスト削減が実現され不満の少ない投資収益率 (ROI) がもたらされます。

• テスト済みハードウェア構成を使って短期間でデータ ウェアハウス プロジェクトを構築する
• バランスの取れたハードウェア ソリューションを購入し、そのソリューションを BI ワークロードに合わせて最適化することで、ハードウェアとメンテナンスにかかるコストを削減する
• Fast Track 参照アーキテクチャのベンダー ハードウェアの一覧を使用するか、新しいハードウェア構成を特定するツールを使用することで、計画やセットアップにかかるコストを削減する
• 適切なスケール モデルの選択、正しいシステム構成、およびチューニング ガイダンスの活用によってパフォーマンスが向上することで成功要因を増やす
• スケーラビリティの課題に対処するために行うソリューションの再設計作業を制限することで将来のサポート コストを削減する

Fast Track 参照アーキテクチャを使用する最も重要なメリットは、おそらく、システムの設計と構成を不適切に行ってしまうという落とし穴に陥らないようにすることでしょう。ハードウェアの構成を誤ると、システムの能力やスループットが制限されることになります。また、ユーザーがシステムから分析データを収集するときに遅延やタイムアウトが発生することにもつながります。これはソリューションの導入に直接影響するでしょう。

Fast Track 参照アーキテクチャの対象範囲

Fast Track 参照構成は、BI システムのソリューション アーキテクチャを正しく設計するというニーズに対処します。具体的に言うと、Fast Track 参照構成は BI ソリューションのデータベース層を対象とし、ユーザーが SQL Server を使用して BI に重点を置くクエリをサポートするデータ ウェアハウスを構築するときに必要なツールとアーキテクチャ ガイダンスを提供します。

図 1: BI ソリューションのデータベース層に重点を置いた Fast Track 参照アーキテクチャ

図 1 は、BI アーキテクチャ全体を示しています。このアーキテクチャでは、まず、ソース システムからの抽出プロセスが行われます。データがステージングされて、データ ウェアハウス環境に統合されます。多くの場合、BI ソリューションでの集計と分析には、データ ウェアハウスまたはデータ マートから取得されるキューブが使用されます。プレゼンテーション層では、Web ポータルでホストされることの多いレポート ツール、分析ツール、およびダッシュボード ツールによって、データ ウェアハウスとキューブのデータが公開されます。図 1 で点線で囲んで強調しているように、Fast Track 参照構成は、BI ソリューションのデータ ウェアハウス層またはデータ マート層に重点を置いています。次の「BI アーキテクチャとデータ ウェアハウジングの設計」では、データ ウェアハウスの設計についてさらに詳しく説明します。

Fast Track 参照構成は、BI ソリューションのデータ ウェアハウス層に重点を置いているだけでなく、ウェアハウスのスケールアップ ハードウェア モデルを提供することも目的としています。このようなスケールアップ システムは、共有メモリ サーバーまたは対称型マルチプロセッシング (SMP) サーバーとも呼ばれます。こうしたシステムでは、同じサーバー ハードウェアに搭載される複数のプロセッサ (多くの場合、マルチコア プロセッサ) とメモリが使用されます。

超並列プロセッシング (MPP) システムでは、各サーバーが同じクエリの解決に参加できるスケールアウト アーキテクチャに、複数のサーバーが参加します。

64 ビット プロセッサとマルチコア プロセッサの最近の進化により、ストレージ ソリューションが正しく構成されている単一 SMP システムのスケールが拡張され、最大 32 TB のデータが格納されるデータ ウェアハウスなどの大規模アプリケーションを処理できるようになりました。今後 CPU の機能強化が進み、より高速かつ高密度のメモリが登場して、ドライブのパフォーマンスや容量が向上することで、この能力はますます向上していきます。

SMP ベースの BI ソリューションが 500 GB であっても 32 TB であっても、データ ウェアハウスのワークロードの同時実行、量、および複雑さに対処するようにシステムを最適化する必要があります。Fast Track 参照構成では、適切なシステムを選択してから、適切なワークロードに合わせてそのシステムを構成するためのガイダンスを提供します。

Fast Track アーキテクチャのプロセス

Fast Track 参照アーキテクチャの 7 つの主要ハードウェア プロファイルは、このアーキテクチャ ガイダンスの取り組み結果の 1 つです。しかし、ハードウェア プロファイルに関するガイダンスがなければ、プロファイル自体にはほとんど価値がありません。今までどおり、選択するシステムとその構成方法を特定する必要があります。

実際に、主要ハードウェア構成と提供されるリソースは、特定のニーズに基づくカスタム参照アーキテクチャを開発するためのフレームワークとして使用できます。たとえば、データ ウェアハウスには、異なるハードウェア プラットフォーム向けの構成が必要になったり、適切なハードウェア構成を選択する際に考慮する必要がある固有の要件が生じたりすることがあります。Fast Track 参照構成に付属するリソースとプロセスによって、独自の参照アーキテクチャを構築するための背景情報、ガイダンス、および手順が提供されるため、柔軟に対処できます (カスタム参照アーキテクチャの作成の詳細については、「独自のハードウェア構成の構築」を参照してください)。

一般に、適切な Fast Track 参照アーキテクチャを選択するプロセスでは、まず、システムで想定するクエリの使用方法を把握します。図 2 は、Fast Track 参照アーキテクチャのリソースと推奨事項を使用する際のワークフロー プロセスを示しています。

図 2: ソリューションの評価、購入、構成、および最適化を実行するための Fast Track 参照アーキテクチャ プロセス

図 2 で示しているプロセス全体で、一部の入力、システム スループットの計算、そしてハードウェアとソリューションの選択、構成、および最適化が必要になります。以下に、このプロセスの概要を示します。詳細については、「適切な Fast Track アーキテクチャの選択と実装」を参照してください。

1. Fast Track 参照 構成を特定するプロセスでは、主に、スループットのニーズを特定できるようにデータ ウェアハウスのクエリ アクティビティを見積もります。たとえば、クエリの種類、クエリの種類ごとにスキャンされるデータの推定量、想定される同時実行数などを見積もります。
2. 提供されるテスト済みの Fast Track 参照構成とは異なるハードウェア コンポーネントを使用することを計画する場合は、この手順を実行する必要があります。この手順では、サーバーの CPU コアのスループットのテストと、ストレージ システムの能力のテストが必要です。Fast Track リソースには、SMP 参照計算と呼ばれる Microsoft Excel スプレッドシートが含まれています。これは、新しい参照アーキテクチャ プラットフォームを作成するためのビルド ブロックです。
3. 適切なハードウェア参照構成は、主に、クエリの目的を果たすためにデータ ウェアハウスで必要な CPU コア数の推定に基づいて特定します。データ ストレージの容量を推定することが主な要素だと考えるかもしれませんが、Fast Track アーキテクチャはバランスが取れているため、参照構成では、まず CPU コアの要件を計算します。
4. 既存のハードウェア構成のいずれかを選択するか、テスト済みの新しいプラットフォームを使用することができます。テストする Fast Track 参照構成は、CPU コアの数、実現可能なスループット、およびストレージ アレイの種類によって異なります。
5. Fast Track 参照アーキテクチャの推奨事項には、SQL Server のユーザー データベースとシステム データベース用にストレージを分割する方法など、ストレージ アレイに対する非常に明確な構成が含まれています。こうした構成は、データ ウェアハウスのシーケンシャル データ アクセスのワークロードに重点を置いているため、Fast Track 参照構成のきわめて重要な構成要素です。
6. 最後の手順では、パーティション分割、インデックス作成、およびデータのステージングに向けてデータ ウェアハウス ソリューションを最適化します。通常、データ ウェアハウスに対して実行される種類のクエリでは、集計を行うために、テーブルをチューニングして広範囲のデータを対象とするクエリ要求を処理する必要があります。

Fast Track Data Warehouse アーキテクチャのコンポーネント

既に説明したように、Fast Track 参照アーキテクチャには、ハードウェア構成、適切なシステムを特定するためのツール、およびソフトウェアとデータベースの構成に関するベスト プラクティスが含まれています。

計画のリソース

Fast Track のサンプル参照アーキテクチャを選択したり、独自の参照アーキテクチャを構築したりするには、まず、予想されるユーザー数、クエリの複雑さ、クエリの種類ごとにスキャンされるデータの推定量、同時実行、データ量など、ソリューションの推定値を特定する必要があります。これらの推定値を特定すると、用意されている計算機能を利用して CPU コアの数と必要なシステム スループットを判断できます。

独自のハードウェア参照構成を構築する場合は、選択するハードウェアでの CPU コアの使用率を判断する必要があります。この使用率は、システムの最大 I/O 飽和点を判断する際に手掛かりとなる指標で、適切なストレージ アレイとその最適な構成方法を特定するために使用されます。また、ストレージ アレイと I/O チャネルで処理できるスループットを判断することも必要になります。独自の Fast Track 参照アーキテクチャを構築する詳細手順については、「独自のハードウェア構成の構築」を参照してください。

構成済みかつテスト済みの SMP ハードウェア

ハードウェア アーキテクチャについては、あらゆるサーバー ハードウェアとストレージ システムを使用できます。参照構成には、あらゆるハードウェア プラットフォームで SMP アーキテクチャをモデル化するのに必要なすべての計算式が含まれています。ただし、Fast Track 参照構成は、サンプルおよびモデルとして、Dell と HP の 2 社のハードウェア ベンダーから提供されています。他のベンダーの参照構成もまもなく公開する予定です。

Fast Track の各サンプル参照アーキテクチャには、システムの全般的な概要と共に、以下の詳細が含まれています。

• Fast Track 参照アーキテクチャのバージョンごとに全システム仕様を含む、構成ワークブック。購入手順を簡単にするために、SKU、数量、説明、および価格を含めています。
• サーバー、ストレージ スイッチ、ストレージ プロセッサ、ストレージ アレイ、およびコンポーネント間の配線を含む、システム図。サーバー室の計画用にシステムのメモリ使用量も示しています。

参照構成の詳細については、「SQL Server Fast Track の使用可能なアーキテクチャ」を参照してください。

SQL Server とシステムの構成

構成の最終局面では、システムやサーバーの設定とデータベース チューニングによってソリューションを最適化する作業について、規範となるガイダンスが必要になります。このガイダンスは、データ ウェアハウスのデータベース エンジンとして SQL Server を使用するすべてのハードウェア プラットフォームに当てはまります。

ガイダンスでは、以下の内容について説明します。

• Windows OS メモリの設定、および SQL Server の起動とデータ復旧の設定
• データベース ファイルとログの初期化、およびストレージ アレイ上のユーザー データベースとシステム データベースの物理レイアウト
• データベース テーブルのパーティション分割、インデックス作成、およびデータ読み込みに関するベスト プラクティス
• データベース テーブルの断片化と統計メンテナンス

これらのベスト プラクティスは、ファイルとテーブルの初期設定、データの抽出、変換、および読み込み (ETL)、パフォーマンスを確保するために長期にわたって継続的に行われるシステムのメンテナンスなど、複数のシステム層に関連します。「適切な Fast Track アーキテクチャの選択と実装」では、最適化アプローチ全体をさらに明確にし、Fast Track 参照アーキテクチャに含まれ、このプロセスに役立つリソースを示しています。

では、BI ソリューション全体におけるデータ ウェアハウスの役割をまとめ、データ ウェアハウスの設計に関するベスト プラクティスを見ていくことにしましょう。

BI アーキテクチャとデータ ウェアハウジングの設計

ほとんどの場合、データ ウェアハウス ソリューションは大規模 BI 戦略に関連付けられます。Fast Track アーキテクチャの利用を計画するときは、BI 戦略に関与するシステムに関連するアーキテクチャの全体像を把握することが重要です。ここでは、企業環境におけるデータ ウェアハウスの全体的な役割と、こうした環境向けのデータベースの設計に関するベスト プラクティスを確認します。

BI とデータ ウェアハウス アーキテクチャの概要

上記の図 1 では、BI 環境の代表的なソリューション アーキテクチャ (ETL プロセス、ステージング環境でのデータの一時ストレージ、データ ウェアハウスまたはデータ マート、キューブ、プレゼンテーション層のレポート、ダッシュボード、および分析ビューなど) に注目しました。

小規模ソリューションの場合、これらのコンポーネントの一部を同じ物理コンピューターに共存させることはできますが、独立したサーバーに分散する方が優れたアーキテクチャと言えます。

図 3 では、BI 環境に参加している独立した物理サーバーに注目しています。

図 3: さまざまな役割を果たす複数のシステムを含む、企業 BI 環境のハードウェア インフラストラクチャ

この環境は、データ ウェアハウスが 1 台のサーバーで一元管理される、データ ウェアハウスのスケールアップ SMP モデルを表しています。Fast Track 参照構成は、SMP ベースのアーキテクチャのデータ ウェアハウス サーバーとストレージ コンポーネントを対象とします。

データ ウェアハウスとデータ マートの違いは、データの対象範囲の違いです。データ ウェアハウスでは、企業全体のデータを一元管理します。一方、データ マートでは、1 つの部署や 1 つの対象領域のデータを扱います。多くの場合、データ マートは一元管理されるデータ ウェアハウスから一部取り出す形式で構築されたり、企業の Operational Data Store (ODS) を基に構築されたりします。多くのエンタープライズ環境には、複数のデータ マートが存在します。また、データ ウェアハウスを構築しないでデータ マートだけを構築することも、データ マートを拡張してデータ ウェアハウスを構築することもできます。

データ ウェアハウスにもデータ マートにも、Fast Track 参照構成を適用できます。多くの場合、データ マートはデータ ウェアハウスより小規模になりますが、データ マート自体のサイズが数テラバイトになることもあるため、完全なデータ ウェアハウスと同じようにチューニングやアーキテクチャに注意が必要です。

データ ウェアハウスの設計

"データ ウェアハウス" という用語は、一般的には、ビジネスに関する履歴データが格納されているデータ リポジトリを指すために使用されます。これは間違いではありませんが、データ ウェアハウス環境内で使用されるべき設計手法を的確には表していません。最もよくある間違いは、以下のソリューションをデータ ウェアハウスに分類してしまうことです。

• レプリケートなどの手法によるトランザクション システムのオフライン コピーは、データ ウェアハウスではありません。このようなデータベースのコピーでは、履歴の追跡や効率的なレポート処理のニーズには応えられません。トランザクション処理用に設計されたシステムからレポート処理を取り出して利用しても、複雑さやパフォーマンスに関する課題が発生し、多くの場合、データの履歴は格納されません。
• 多くのテキスト記述子と数値列が混在し、全テーブルがフラットで正規化されない形式で含まれているデータベースは、データ ウェアハウスではありません。このようなシステムでは、テーブルに対してクエリを実行した直後からパフォーマンスの問題が発生し、テーブルの使用領域と結び付いているレコードの量が圧倒的に増加します。もちろん、データ ウェアハウスの設計パターンには、データの正規化手法のバリエーションなど、さまざまなパターンがあります。しかし、目的は 1 つです。つまり、長期にわたってデータの履歴を追跡しながら、データのレポートと分析を最適化に行うことです。

多くの場合、データ ウェアハウスは、"ディメンション モデリング" と呼ばれるモデリング技法を使用して設計されます。この技法は、パフォーマンスと履歴の目標に効果的に対処します。ディメンション モデリングでは、テキスト列に冗長なデータ ("属性" と呼ばれます) をいくらか作成し、分析する数値指標からそれらの列を切り離して、レポート用に構造を最適化することに重点を置きます。

ディメンション モデリングでは、ディメンション テーブルとファクト テーブルという、2 種類の主要テーブルを使用します。

• ディメンション テーブルは、製品、店舗、請求書、日付などのビジネス エンティティに注目した関連属性の集合です。履歴を保持し、"代理キー" と呼ばれる新しい主キー列を含めることで、ディメンション データの変化が処理されることがあります。ディメンション テーブルに多くの列が含まれることもよくありますが、通常、2 種類目のテーブル (ファクト テーブル) に比べればレコード数ははるかに少なくなります。
• ファクト テーブルには、"メジャー" または "ファクト" と呼ばれる、分析対象の指標が含まれています。また、属性と関連付けるために、関連ディメンション テーブルの外部キー (代理キー) も含まれています。ファクト テーブルは、測定の種類、または販売、勘定残高、イベントなどのトランザクションの種類別に編成されます。ファクト テーブルには、多くの場合、膨大な行数が含まれますが、非効率なテキスト列は含まれていないため、レポート処理には最適です。

図 4 は、Store Sales および Store Inventory という 2 つのファクト テーブルの例を示しています。図の中央にあるこれらのファクト テーブルでは、店舗、日付、バイヤーなどの共通ディメンション リレーションシップが共有されます。この設計では、ディメンションが類似しているため、販売トランザクションと在庫量を同時に分析してクエリすることができます。

図 4: 2 つのファクト テーブルと、関連ディメンション テーブルを示す、ディメンション モデルの例

ディメンション テーブルと同様に、ファクト テーブルでも販売履歴、在庫量、勘定残高、イベントなどの履歴が追跡されます。たとえば、Store Inventory ファクト テーブルでは、各店舗の製品在庫量の 1 週間分の履歴を追跡できます。この情報により、ユーザーは在庫レベルの傾向の把握や分析を長期にわたって実行できます。この機能は、基になるトランザクション システムではめったに使用できません。

Fast Track Data Warehouse 参照アーキテクチャのインデックス作成とパーティション分割に関する推奨事項 (「適切な Fast Track アーキテクチャの選択と実装」で概要を説明しています) では、データ ウェアハウス設計を代表するテーブルに重点を置いています。

SQL Server Fast Track の使用可能なアーキテクチャ

マイクロソフトがデータ ウェアハウスの SMP ベースの Fast Track 参照構成を作成する際に使用したアプローチは、あらゆるハードウェア プラットフォームに当てはめることができます。後半の「独自のハードウェア構成の構築」では、既存のハードウェアの使用目的を変更する必要がある場合、または希望するハードウェア プラットフォームが、この第一次テスト済み Fast Track 参照アーキテクチャに含まれていない場合に、独自の Fast Track 参照アーキテクチャを作成するための手順の概要を説明しています。

ただし、新しいデータ ウェアハウスやデータ マート BI ソリューションを構築する場合、または新しいシステムを選択できる場合は、既存の Fast Track 参照構成を使用すれば、ハードウェア コンポーネント間のバランスを取るために膨大なテストを行う必要がなくなります。

では、このような新しい Fast Track Data Warehouse アーキテクチャの特徴的な機能を調べて、構成済みの各ソリューションの詳細を確認し、ソリューションに適したハードウェア構成を選択できるようにしましょう。

SQL Server Fast Track Data Warehouse アーキテクチャの特徴的な機能

"参照アーキテクチャ" という用語をインターネットで簡単に検索してみると、さまざまな分野を対象とする数百とおりのシステム設計パターンを示す、数千件のページがヒットします。これでは目的を見失うのも当然です。閲覧するサイト、探している情報、または信頼できる人物がよくわからない場合は、どうしたらよいのかわからなくなりがちです。

Fast Track Data Warehouse アーキテクチャを他の参照アーキテクチャと区別するものとして、主に次に示す 2 つの特徴的な機能があります。

 データ ウェアハウスのクエリ ワークロードのチューニング

Fast Track 参照構成の特徴的要素の 1 つ目は、データ ウェアハウスのアクティビティのメモリ使用量 (つまり、シーケンシャル I/O) に重点を置いている点です。

SQL Server をエンジンに使用してシステムを構築しているからといって、常に同じ方法でシステムを構成する必要はありません。たとえば、SQL Server 上で実行される Microsoft Dynamics や SAP などの大規模 ERP システムがあり、そのシステムの目的がレコード処理のトランザクション タスクを実行することだとします。この種のシステムでは、小さなトランザクションが管理され、独立した挿入タスク、更新タスク、または削除タスクが実行されます (多くの場合、何百または何千ものタスクが一度に実行されます)。そのため、こうした "ランダムな I/O 読み取りと書き込み" を処理するために、インデックス作成とストレージの構成を最適化する必要があります。

データ ウェアハウスのアクティビティは、実にさまざまです。まず、ユーザーがクエリを実行するときのアクティビティは、ほぼ例外なく読み取りで、書き込みのアクティビティは限定さ れます。また、データ ウェアハウスのアクティビティをさらに分類するならば、何百または何千ものデータ行を集計するレポート クエリまたは分析クエリに対応するために、データベースから大量のデータを一度に読み取る大規模一括操作を行う "シーケンシャル I/O" を行うことが多いと言えます。

以下に、SQL Server Fast Track Data Warehouse 参照構成が採用している、実装の詳細をいくつか示します。

• Fast Track 参照構成では、I/O 要求がシーケンシャルに行われるという性質を考慮し、データが基になるドライブからランダムに抽出されるのではなく、連続する一連のデータとして読み取られると仮定して、基になるドライブからのデータ読み取りが最適になるようにストレージ アレイを構成しています。データが断片化していない状態で、クエリが範囲をスキャンしている場合、このような構成でのスループットが非常に高くなります。
• シーケンシャル I/O パターンでは、ドライブが正しく構成されていると、読み取りの待機時間が大幅に短縮される可能性もあります。これにより、ドライブのストライピングが少なくなり、論理ユニット番号 (LUN) と呼ばれる専用ハードウェア ボリュームが減少します。つまり、要求に応答するためにドライブ ヘッドがディスク上を移動しなければならないと、I/O ブロックの読み取りにかかる時間 (待機時間) が大幅に長くなります。ドライブ ヘッドの移動も、ディスクの回転待ちも必要なく、絶えず読み取りを実行できれば (複数のボリュームで LUN を共有し、いくぶんデータ ストライピングが生じます)、ドライブに重点を置いて最適化することができます。
• データ ウェアハウスの一般的なクエリは読み取りであるという性質から、これらの Fast Track 参照構成では、ストレージ アレイのデュアル読み取り機能も使用されます。EMC CX4-240 と HP MSA-2000 では、1 つのミラーの両方のドライブから個別にデータを読み取ることができます。つまり、これらの Fast Track 参照アーキテクチャ ソリューションは、エラーが発生した場合に備えてデータが 2 台のドライブに格納されている、ミラー化されたドライブに依存しています。これらのテクノロジから得られるメリットの 1 つは、1 つのミラーの両方のドライブから送信される I/O 要求にオーバーラップしないで応答できるということです。この機能により、LUN の I/O スループットが 2 倍近くに向上します。

ストレージ システムを正しく構成することは、データ ウェアハウス システムの構成に必要な要素の 1 つにすぎません。しかし、ストレージ システムでは誤った構成が行われることも多く、正しく構成することができれば、大幅なコスト削減やパフォーマンスの向上を実現できます。

バランスの取れたハードウェア アプローチを使用した設計

次に紹介する、新しい Fast Track 参照構成の特徴的要素は、バランスの取れたハードウェア アプローチです。ほとんどのシステム アーキテクチャでは、システムを計画するときにメモリ、データ ストレージ容量、およびプロセッサを個別に検討します。

一方、Fast Track 参照構成では、ハードウェア コンポーネントとソフトウェア コンポーネントの複数の層でスループットが一致するように、システム全体のバランスを取る必要があると考えています。CPU とドライブ自体の間には、次のようないくつかのスループットの層が存在します。

1. CPU とサーバーのスループット。CPU コア、OS の機能、SQL Server 先読みキャッシュなどが、これに該当します。
2. サーバーとストレージ システム間の I/O チャネルのスループット。ホスト バス アダプター (HBA) カードとスイッチ機能のスループットを組み合わせたものが、これに該当します。
3. ストレージ システムのスループット。ストレージ プロセッサのスループット処理能力、シーケンシャル I/O 読み取りの LUN とディスクの機能などが、これに該当します （データ ウェアハウスに重点を置く場合）。

これらのコンポーネントのいずれかが他のコンポーネントに対する制約となり、最大スループット処理能力を実現できないようにしている可能性があります。図 5 は、スループット処理能力の性質を示しています。

図 5: 構成に誤りがありスループットに制約があるシステムの例

システムのボトルネックとなるのが最も多いのは、ストレージ アレイです。図 5 の例 1 は、I/O パスのサーバーとスループット処理能力をスケール変換できますが、ストレージ サブシステムがスループットを制限しているシステムを示しています。ドライブがデータ ウェアハウスのワークロードに合わせて最適化されていない場合、ドライブの数と速度が十分でない場合、またはストレージ プロセッサのスループットが制限されている場合に、この問題が発生します。

例 2 は、HBA カードまたはカードのスループットが十分でないか、(スイッチがある場合に) スイッチが制限されているために、HBA または I/O スイッチの処理能力を制限しているシステムを示しています。このボトルネックは、直接接続型ストレージを使用するウェアハウス ソリューションで発生することがあります。LUN がドライブ アレイからサーバーに直接割り当てられるため、複数のカード間で I/O のバランスを取ることができません。HBA が複数ある場合でも、1 つの HBA がボトルネックになる可能性があります。

例 3 は、ストレージ システムのスループットとストレージの I/O パスのスループットは十分ですが、サーバーがボトルネックになっているシステムを示しています。このような状況では、ソフトウェアでスループットを処理できなくなったり、CPU コアの組み合わされた I/O 使用率が制限されたりする (こちらの可能性の方が高くなります) 可能性があります。

上記の例とは対照的に、新しい Fast Track 参照構成では、CPU からディスク アレイに至るまで、ハードウェアのバランスが保たれます。このアプローチにより、すべてのシステム コンポーネントで最大のスループット処理能力を実現できます。図 6 は、システム コンポーネントのバランスを取るメリットを示しています。

図 6: 効率の高いスループットを実現する、バランスの取れたシステム

図 6 に示すこのアプローチ特有の点は、バランスの取れたシステムの性質は CPU コアから始まるという点です。そのため、このシステム アーキテクチャを "コア分散型アーキテクチャ" と呼びます。このようにバランスの取れたアプローチは、いわゆる CPU コア使用率から始まります。CPU コア使用率とは、各 CPU コアにデータが供給されるときに、そのコアで処理できる入力の容量のことです。

SQL Server Fast Track のテスト済みハードウェア構成

テスト済みの Fast Track 参照構成は、3 台の HP 製サーバーと 2 台の Dell 製サーバーを基盤として構築されています。Dell の構成では EMC CX4-240 が使用され、HP の構成では EMC CX4-240 と HP MSA-2000 の両方のストレージ アレイが使用されます。

表 1 は、サーバーの構成をまとめたものです。

サーバー	CPU	コアの総数	SAN	ドライブ数	容量
HP Proliant DL 385 G5p	(2) AMD Opteron Shanghai クアッド コア 2.7 GHz	8	(2) HP MSA2000	(16) 300 GB 15k SAS	4 TB (テスト済み) 8 TB (最大)
(2) EMC CX4-240	(16) 300 GB 15k FC	4 TB (テスト済み) 10 TB (最大)
HP Proliant DL 585 G5	(4) AMD Opteron Shanghai クアッド コア 2.7 GHz	16	(4) HP MSA2000	(32) 300 GB 15k SAS	8 TB (テスト済み) 16 TB (最大)
(4) EMC CX4-240	(32) 300 GB 15k FC	8 TB (テスト済み) 16 TB (最大)
HP Proliant DL 785 G5	(8) AMD Opteron Shanghai クアッド コア 2.7 GHz	32	(8) HP MSA2000	(64) 300 GB 15k SAS	16 TB (テスト済み) 32 TB (最大)
(8) EMC CX4-240	(64) 300 GB 15k FC	16 TB (テスト済み) 32 TB (最大)
Dell Power Edge 2950 MLK	(2) Intel Xeon Harpertown クアッド コア 2.66 GHz	8	(2) EMC CX4-240	(16) 300 GB 15k FC	4 TB (テスト済み) 8 TB (最大)
Dell Power Edge R900	(4) Intel Xeon Dunnington 6 コア 2.67 GHz	24	(6) EMC CX4-240	(48) 300 GB 15k FC	12 TB (テスト済み) 24 TB (最大)

表 1: HP と Dell のテスト済み Fast Track 構成

参照構成ではコア分散型のアプローチが使用されるため、システムの実際のストレージを推定することが構成の中心ではありません。コアの総数とシステムの容量には相関関係がありますが、これは単に、すべてのコアを組み合わせた CPU 使用率に基づいて、ストレージ システムに必要なスループットが決まるためです。ストレージの最適なスループットは、300 GB 15K RPM のドライブで実現されました。

以下で、表 1 に示した容量の値について明確にします。

• テスト済み "容量" の値は、CPU コアの使用率に相当するバランスの取れたドライブの数を表しています。システムのスループット率は該当の構成で最適化されるため、必要なストレージ容量が少ない場合でもドライブの数を減らすべきではありません。たとえば、データ ウェアハウスのサイズがわずか 1 TB で、テスト済みシステムの容量が 4 TB であれば、ステージングなどの他の目的のために、または将来サイズを大きくするために、3 TB のストレージを残しておくべきです。システム全体のコア分散型の性質を維持しながらスループットを維持するために、ドライブの数、およびドライブの数と CPU コアとの割合や関係を維持することが重要です。
• "容量" の最大値は、HP または EMC によって使用されるアレイ キャビネットのストレージ アレイのさまざまな容量を考慮して、ストレージ アレイが保持できるドライブの最大数を表しています。テスト済みの容量を上回るドライブを追加すると、保存されるデータの容量は増加しますが、システムのスループットは増加しません。これは、コア分散型のアプローチによって既にシステムが最適化されているためです。
• "容量" の数値には、ホット スペアとログ ドライブが含まれていません。また、"容量" の数値が示しているのは、ドライブのミラーリングが適用される前の未処理の領域ではありません。そのため、この数値は、ユーザー データベースの空き領域を表します。さらに、SQL Server 2008 での圧縮の平均値を基に、2.5 倍の圧縮率でユーザー データを圧縮したことを反映する数値です。

表 1 からわかるように、Fast Track の各参照アーキテクチャには、特定のサーバー ハードウェア、指定されたプロセッサの種類とコアの総数、正確な SAN ハードウェア、およびドライブの数と種類が含まれます。この推奨ハードウェア構成を変更できますが、変更したシステムをテストして、スループットのバランスが崩れていないことを確認する必要があります。たとえば、ドライブの種類を 400 GB 10K RPM ドライブに変更すると、スループット処理能力が低下し、システムのバランスが崩れ、ストレージ システムで I/O のボトルネックが発生します。

サーバーのメモリについては、小規模システムの場合 CPU コアごとに 4 GB 以上のメモリまたは 64 GB の RAM がシステムに搭載されることを想定していますが、中規模システムや大規模システムの場合は 128 GB または 265 GB のメモリを搭載する方が適しています。これらの構成は、1 TB ～ 32 TB のデータ ウェアハウス ソリューションを対象としています。SQL Server によってデータ キャッシュでサーバーのメモリが使用されるので、メモリのサイズは大きければ大きいほど適しています。

適切な Fast Track アーキテクチャの選択と実装

次に、自身のソリューションに適した Fast Track 参照アーキテクチャ構成を判断します。ソリューションのニーズを評価し、テスト済み Fast Track 参照構成のいずれかを選択するか、異なるハードウェアに基づく新しい Fast Track 参照アーキテクチャを構築する必要があります。

ここでは、まず、新しい Fast Track 参照アーキテクチャを作成する手順を細かく確認していきます。テスト済み Fast Track 参照アーキテクチャのいずれかを使用する場合は、「CPU コア数の計算とハードウェア ソリューションの選択」まで途中の手順を省略できます。

独自のハードウェア構成の構築

新しい SMP ハードウェア構成の作成に関わるすべての手順では、CPU コアの使用率から始まる、システムとコンポーネントのスループット処理能力をテストすることに重点を置いています。

同じプロセッサが搭載された HP 製または Dell 製のいずれかのテスト済みサーバーを使用する場合は、ストレージ システムまたはドライブを変更するときでも、コアの使用率を計算する必要はありません。コアの使用率は、およそ 200 MB/秒になると既に計算されています。ただし、ストレージ アレイのスループット処理能力は特定する必要があります。

反対に、テスト済み Fast Track ストレージ アレイとドライブのいずれかを使用する場合は、サーバーのコア使用率とコア数を計算する必要があります。特定の CPU のコア使用率はサーバーによって異なるので、使用予定のシステムのコア使用率を計算するようにします。手順を開始する前に、サーバー ベンダーに連絡してサポートを依頼するか、新しい Fast Track 参照アーキテクチャがテスト済みかつ公開済みかどうかを確認します。

コアの使用率の計算

CPU コアの使用率はサーバーに固有で、ストレージ システムとは無関係なので、目標は、ディスクを利用せずにできるだけ多くのデータをいずれかの CPU コアに読み込むテストを使用することです。

「SQL Server Fast Track Data Warehouse の実装」 ホワイト ペーパーの「CPU 使用率を特定する方法」では、CPU コアの使用率を計算する一連の手順のサンプルを提供しています。その一部を以下に示します。

1. クラスター化インデックスが指定されているテーブルと指定されていないテーブルの 2 つのテーブルを含む、データベースを作成します。

2. (MAXDOP = 1 という接続設定を指定して 1 つの CPU コアで実行することを目的とした) テーブルに対して一連の SELECT * クエリを実行して、テーブルのスキャンにかかる時間を判断します。

3. CPU の最大使用率は、テーブルのサイズ (MB) を、テーブルのスキャンにかかった秒数で割って計算します。

使用される CPU コアの数と MAXDOP の設定値を増やして、この計算をテストできます。CPU コアを追加するたびに、CPU コアの使用率は線形的に増加します。また、2 つのテーブルを結合および集計して、集中的なクエリの実行をシミュレーションしたり、さまざまな種類のアクティビティの使用率を収集したりすることができます。このことは、予想されるソリューションの複雑さを、平均的な使用率に割り当てるのに役立ちます。

ストレージ アレイとドライブのスループット率の計算

次に必要な一連のスループット率は、ストレージ アレイ システムに関係します。この値の多くは、ストレージ システムの資料で提供されますが、システムをテストしてスループットを確認することをお勧めします。ここでも、ストレージ ベンダーに連絡し、データ ウェアハウス システムの新しい Fast Track 参照アーキテクチャ ガイドを使用して、システムのテストが既に行われているかどうかを確認します。

表 2 は、システムのスループットを特定するために必要な数値と計算を示しています。参考までに、EMC CX4-240 と HP MSA-2000 のテスト済みの数値も表に含めています。

SAN の計算率	EMC CX4-240	HP MSA-2000
1 ストレージ システムあたりのストレージ プロセッサの最大数	2 基	2 基
1 ストレージ システムあたりのドライブ アレイの最大数	2 基	1 基
1 ドライブ アレイ (DAE) あたりの 3.5 ドライブの最大数	15 台	12 台
1 ストレージ プロセッサあたりの最大レート	500 MB/秒	550 MB/秒
ストレージ システムの各 LUN RAID 1 の最大レート	240 MB/秒	150 MB/秒
ストレージ システムの各 1/2 DAE の最大レート	370 MB/秒	600 MB/秒
ドライブの推定容量	272 GB	272 GB
ドライブの推定スループット	250 MB/秒	250 MB/秒

表 2: ストレージ システムのスループットを計算するためのストレージの数とレート

おわかりのように、アーキテクチャで必要になるストレージ システムの数を確認するには、LUN とドライブ アレイのスループット率だけでなく、1 ストレージ システムあたりのストレージ プロセッサ (SP) と DAE の数も必要です。たとえば、単一の HP MSA-2000 システムでは、それぞれに 12 台のドライブが搭載された 2 台のドライブ アレイしか使用されないので、SAN プラットフォームを使用する大規模データ ウェアハウスでは、複数の HP MSA-2000 システムを使用する必要があります。

CPU コアの使用率とストレージ システムの統計を収集したら、新しい Fast Track 参照アーキテクチャのストレージ容量に対して、コア分散型の CPU コアのサーバー マトリックスを作成できるようになります。

新しいハードウェア構成の SMP 参照計算スプレッドシートの更新

カスタム参照アーキテクチャを構築する最後の手順では、コア分散型のアプローチを使用して、ストレージのスループットに CPU コアを割り当てます。SMP 参照計算スプレッドシートは、この割り当てを行うのに役立ちます。

CPU コアとストレージの関係を示す新しいマトリックスを作成するには、まず、(EMC CX4 システムまたは HP MSA システムの) Excel ドキュメントのいずれかのワークシートを新しいワークシートにコピーして、使用している新しいストレージ プラットフォームの名前に変更します。次に、CPU コアの使用率、すべてのストレージ システムの数値など、すべてのデータを変更します。

図 7 に、スプレッドシートの計算式からの出力をまとめました。

図 7: 必要なコアの数をシステムのスループットと処理能力に割り当てるスプレッドシートの計算式

この表から、コアの数と、ストレージ システムの数、SP 数、DAE 数、ドライブ数、最適なストレージ量とのバランスが取れた一連のシステムがわかります。

では、データ ウェアハウスの具体的な要件を満たすコア数の計算例を細かく確認していきましょう。

CPU コア数の計算とハードウェア ソリューションの選択

構成済みかつテスト済みの Fast Track 参照アーキテクチャを使用する場合でも、新しいアーキテクチャを作成する場合でも、適切なシステムを選択するには、まず、システム要件を満たすために必要な CPU コア数を判断する必要があります。その後、データ ウェアハウス ソリューションに適したハードウェア プラットフォームを特定できます。

CPU コア数の計算

必要なコア数を計算するには、次の 4 つのデータを使用します。

1. CPU コアの使用率。テスト済みの Fast Track 構成の場合、この値は既に計算されており、200 MB/秒です。

2. 平均的なクエリでスキャンされるデータの量。たとえば、平均的なクエリによって、1 日あたり平均 1,000 万行が含まれているファクト テーブルの 1 か月分のデータがスキャンされ、ファクト テーブルの各行に 60 バイト使用されているとすると、スキャンされるデータ量はおよそ 18,000 MB になります。

3. 平均的なクエリ 1 回あたりの目標応答秒数 (60 秒など)。

4. 想定同時実行数。平均して、この割合はユーザー数の 10% です。したがって、100 人のユーザーが利用するシステムの場合、同時実行ユーザーの範囲は 10 人になります。

必要なコア数を計算する数式は、次のとおりです。

 (平均的クエリでスキャンされるデータ量/CPU コアの使用率)

 * アクティブな同時セッション数/目標応答時間

先ほど説明した値の例を使用すると、次のような計算式になります。

((18,000 MB/200 MB/秒) * 10)/60秒 = 15 個の CPU コア

もちろん、15 個のコアを搭載したシステムは存在しません。また、結果は推定値なので、コアの数を 1 レベル切り上げる (16、24、32 などにする) ことをお勧めします。

計算の詳細と拡張例については、「SQL Server Fast Track Data Warehouse の実装」ホワイト ペーパーを参照してください。

適切なハードウェアの選択

先ほど確認した CPU コアの例の計算式に基づくと、推定値は 16 個の CPU コアを搭載したシステムを指すことになります。コアの使用率が 200 MB/秒であると仮定すると、このシステムは、4 基のクアッド コア プロセッサを装備した 4 CPU のソケット システム、または 8 基のデュアル コア プロセッサを装備した 8 CPU のソケット システムのいずれかにすることができます。

ただし、選択した Fast Track 参照アーキテクチャに適したシステムを選択するには、データ ウェアハウスの容量の推定値も必要です。Fast Track 参照構成では CPU コアの数に重点を置いていますが、適切なストレージ システムとドライブ数を選択するには、必要なストレージの容量を把握する必要があります。

データ ウェアハウスを既に実装している場合、既存のシステムから簡単にこのデータを取得できます (将来拡張されるサイズを必ず概算してください)。まだ実装していない場合は、概算を行う必要があります。概算は、ソリューションで想定されるファクト テーブルの行数と行の平均幅を乗算して、インデックス作成とディメンション テーブルに 30 ～ 40% のオーバーヘッドを加算する程度の単純さでかまいません。また、SQL Server 2008 では、平均の 2.5 倍の圧縮率を適用することもできます。

CPU コアの数を特定し、ストレージ容量の概算を行ったら、ハードウェアの選択方法を確認できます。

先ほど示した表 1 では、テスト済み Fast Track 参照構成、および 300 GB 15K RPM のドライブでテストされた容量とスループットをまとめています。テスト済み容量は使用可能なストレージの容量なので、必要なストレージが、必要なコアの数に基づくテスト済みの容量の範囲内にある限り、ハードウェアの選択は簡単です。

Fast Track アーキテクチャの実装手順

Fast Track Data Warehouse の最後の手順は実装です。この段階に必要な手順には、ハードウェアの実装とシステムのチューニング、システム設定と SQL Server 設定の両方への対応、データベース オブジェクトや読み込みプロセスへの対応などがあります。

これらの手順の詳細については、「SQL Server Fast Track Data Warehouse の実装」ホワイト ペーパーの「アーキテクチャの詳細」を参照してください。以下では、推奨事項について簡単にまとめます。

システムの構成

システムを構成する際最も重要な手順は、ストレージ アレイに適度の冗長性を持たせ、適切な数の LUN を作成することです。SMP ベースの Fast Track 参照アーキテクチャのアプローチでは、ドライブのセットアップ手順に従う必要があります。

以下に、非常に重要なストレージ アレイのセットアップ手順をまとめます。

1. RAID 1 ミラー セットでドライブを構成します。
2. RAID 1 ドライブ セットを直接 LUN に割り当てます。これらを組み合わせることはしないでください。
3. Windows OS のボリュームまたはマウント ポイントに LUN を割り当てます。

Windows メモリ ページの設定

システム構成の 2 つ目は、Windows Server のメモリに関する設定です。グループ ポリシーを使用して、"メモリ内のページのロック" 設定を有効にします。これにより、オペレーティング システムのディスク I/O オーバーヘッドが全体的に減少し、メモリ内のデータが LUN から復旧されるのを待たずに、そのデータをすぐにプロセッサで使用できるようになります。

SQL Server データベースの設定とファイル レイアウト

既定では、新しいデータベースの復旧モードは完全復旧モードに設定されます。完全復旧モードでは、一括操作など、トランザクションのすべてのアクティビティがログ ファイルにキャプチャされます。多くの場合、データ ウェアハウス アプリケーションは定期的に読み込まれるだけであり、アクティビティの大半は読み取り操作なので、データベースの復旧モードを単純復旧にして、完全バックアップまたは増分バックアップを夜間に実行するように設定できます。これにより、ログ管理のオーバーヘッドとログ ファイルの拡張が最小限に抑えられます。

データベース ファイル (ログ ファイルとデータ ファイルの両方) は、最初の作成時に初期化し、拡張しておきます。これにより、ETL 操作中にパフォーマンスを低下する自動拡張操作が回避され、復元操作が必要な場合でも高速化されます。

Fast Track 参照構成を使用するには、次のように、LUN 上のデータベース ファイルを明確なファイル レイアウトで構成することも必要です。

• 各ユーザー データベースでは、LUN ごとに 2 つのファイルを作成します。
• TempDB システム データベースとステージング データベースの場合は、プライマリ データベース ファイル グループの LUN ごとに 1 つのファイルを作成します。
• 各ユーザー データベースの場合は、すべてのデータ ファイルを拡張して、AUTOGROW データベース設定を無効にします。
• ステージング データベースと TempDB データベースは、4 MB 間隔で AUTOGROW 設定を有効にします。

ユーザー データベースのパーティション分割とインデックス作成

データ ウェアハウス アクティビティ向けの一般的なインデックスの作成方法は、大量のデータ スキャンを返すクエリを迅速に取得できるように最適化することです。トランザクション システムの場合、独立したレコードを特定することが目標です。そのため、トランザクション テーブルのインデックスを設計する場合、join 句や where 句で使用される列を、できるだけ多くのデータをフィルター処理するように選択します。データ ウェアハウスの場合は、日付 (タイムスタンプなし) など、データの範囲を対象とする適切な列を選択することが目標です。多くの場合、インデックス作成に対する考え方を変える必要があります。

インデックスの作成とパーティション分割を行う場合、次の一般的手法に従う必要があります。

• ユーザーが頻繁にクエリを実行するほとんどのテーブルで、クラスター化インデックスを使用します。ただし、テーブルに日付コンポーネントが含まれていない場合、またはクエリ パターンでフィルター処理や結合がそれほど実行されない場合は除きます。データのフィルター処理やスキャンに最もよく使用される列の場合、ファクト テーブルのクラスター化インデックスでは、日付列が最もよく使用されます。
• テーブルで非クラスター化インデックスを使用して、より細かなクエリ参照をサポートします。ディメンション テーブルのサイズが大きい場合は、いくつかの非クラスター化インデックスからメリットを得ることができます。INCLUDE ステートメントの一部としてディメンションの代理キーをカバリング インデックスに含めて、ファクト テーブルへの結合を最適化することを検討してください。
• ほとんどの場合、サイズの大きなファクト テーブルは日付の範囲でパーティション分割します。このようにすると、古いデータの削除だけでなく、クエリの最適化にも役立ちます。また、データを削除するときに、断片化が軽減されます。

データベースとファイルの継続的なメンテナンス

テーブルとファイルのメンテナンスを継続的に行うと、データ ウェアハウスのクエリのパフォーマンスが安定し、バランスの取れたシステムのスループット処理能力が最大限に維持されます。

一般的な目標は、断片化を軽減することです。断片化が行われると、基になるドライブでデータ ウェアハウスのシーケンシャル I/O のパターンが適切に処理されなくなります。以下の継続的なメンテナンスの操作を計画するようにしてください。

• データベース統計を定期的に更新します。ほとんどの場合、データの読み込みが行われた直後に更新するのが適切です。毎週または毎月定期的に行う更新には、テーブルのインデックスのデフラグまたは再構築も含めます。
• Windows のデフラグ ツールを使用して、システム ファイル レベルでのデフラグを検討します。

データ読み込みのベスト プラクティス

最後に、すべてのデータ ウェアハウス ソリューションまたはデータ マート ソリューションでは、データを一括して追加または更新する必要があるため、テーブルの読み込みとインデックスの更新を効率的に行う方法を検討することが重要です。特にデータが大量の場合、ETL 操作の実行に数時間もかかることがよくあります。そのため、読み込みプロセスをチューニングすると、クエリでのデータベースの可用率が向上します。

「SQL Server Fast Track Data Warehouse の実装」ホワイト ペーパーでは、ステージング環境を読み込む方法、クラスター化インデックスが指定されていないテーブルへのデータの追加方法、およびパーティション分割されたテーブルへのデータの読み込み方法について詳しく説明します。

まとめ

まとめると、SQL Server Fast Track Data Warehouse のリソースにより、スケールアップ SMP データ ウェアハウス ソリューションの選択と構成にかかる時間を短縮する、背景情報、ツール、およびテスト済みハードウェア構成が提供されます。

テスト済み Fast Track 構成だけでなく、データ ウェアハウス ソリューションも、この新しい Fast Track アーキテクチャ アプローチを使用して、新しいハードウェア プラットフォームに実装することができます。

この新しい Fast Track 参照アーキテクチャ モデルは、データ ウェアハウス ソリューションのクエリ アクティビティの使用方法に基づいており、コア分散型のアプローチを使用してハードウェアとソリューションを統合するため、コンポーネントの選択と構成プロセスを担当するすべての関係者を対象にトレーニングを実施することが重要です。構成のすべての推奨事項に完全に従わないと、システムのスループットとパフォーマンスの機能が制限されることになります。

データ ウェアハウスは、ソフトウェアの設計や設定を含めることで、そのハードウェア構成を上回るパフォーマンスを発揮します。そのため、Fast Track 参照構成には、ファイル、インデックス、読み込みプロセス、および継続的なメンテナンスを構成してデータベースを最適化する際の規範となるガイダンスも提供して います。

関連情報:

SQL Server Fast Track Data Warehouse ホーム ページ (英語)

SQL Server Fast Track Data Warehouse の実装

SQL Server 2008 Data Warehousing Web サイト (英語)

Project codename "Madison" Web サイト (英語)

SQL Server TechCenter Web サイト

SQL Server デベロッパー センター Web サイト

SQL Server Customer Advisory Team Web サイト (英語)

SQL Server を使用してハブとスポーク型のエンタープライズ データ ウェアハウス アーキテクチャを構築する

Hub-And-Spoke:Building an EDW with SQL Server and Strategies of Implementation (英語)

このホワイト ペーパーはお役に立ちましたか? フィードバックをお寄せください。1 (役に立たなかった) ～ 5 (非常に役に立った) の 5 段階で評価してください。また、その評価の理由もお知らせください。以下に例を示します。

• 評価が高いのは、例が適切、図がわかりやすい、説明が明快といった理由からですか。
• 評価が低いのは、例が少ない、図がわかりにくい、説明があいまいといった理由からですか。

このようなフィードバックをお寄せいただくと、今後のホワイト ペーパーの品質向上につながります。

フィードバックは、こちら (英語) までお送りください。