Fast Track Data Warehouse Reference Guide for SQL Server 2012

SQL Server 2012 Fast Track Data Warehouse リファレンス ガイド

SQL Server 技術記事

執筆者: Eric Kraemer、Mike Bassett、Eric Lemoine、Dave Withers

技術校閲者: Claude Lorenson、Susan Price、Ralph Kemperdick、Henk van der Valk、Alexi Khalyako、Oliver Chiu

発行日: 2012 年 3 月

適用対象: SQL Server 2012

概要: このホワイト ペーパーでは、Fast Track Data Warehouse と呼ばれるリファレンス構成モデルについて詳しく説明します。このモデルでは、リソースのバランスに重点を置いた手法を使用し、対称型マルチプロセッサ (SMP) ベースの SQL Server データベース システム アーキテクチャを導入することで、データ ウェアハウスのワークロードに対して高いパフォーマンスとスケーラビリティを発揮することが知られています。Fast Track Data Warehouse のリファレンス アーキテクチャの目的は、SQL Server のデータ処理能力とコンポーネント ハードウェアの実効スループットの間でバランスを取りながら、効率的にリソースを配分することです。

著作権

このドキュメントは現状有姿で提供されます。このドキュメントに記載されている情報や見解 (URL 等のインターネット Web サイトに関する情報を含む) は、将来予告なしに変更されることがあります。お客様は、その使用に関するリスクを負うものとします。

このドキュメントは、Microsoft 製品の無体財産権に関する法的な権利をお客さまに許諾するものではありません。内部的な参照目的に限り、このドキュメントを複製して使用することができます。

© 2012 Microsoft. All rights reserved.

目次FTDW の変更履歴6概要6対象読者6Fast Track Data Warehouse6Fast Track7なぜ FTDW か7手法7総合的なコンポーネント アーキテクチャ7ワークロードに合わせて最適化された手法8検証済みの SQL Server Fast Track リファレンス構成9概要9FTDW のワークロード9データ ウェアハウスのワークロード パターン9ワークロードの評価10データ ウェアハウスのワークロードの定性的な特性12FTDW リファレンス構成の選択13方法 1: 基本評価14手順 1: 顧客のユース ケースを評価する14手順 2: 公開 FTDW リファレンス アーキテクチャを選ぶ15方法 2: 完全評価15プロセスの概要15手順 1: 顧客のユース ケースを評価する16手順 2: 評価のメトリックを決定する16手順 3: Fast Track Data Warehouse リファレンス アーキテクチャを選択する17方法 3: ユーザー定義のリファレンス アーキテクチャ18手順 1: ワークロードを定義する18手順 2: コンポーネント アーキテクチャのベンチマークを測定する18FTRA 選択のまとめ19FTDW の標準構成19ハードウェア コンポーネント アーキテクチャ19コンポーネントの要件と構成20アプリケーション構成22Windows Server 2008 R222SQL Server 2012 Enterprise23ストレージ システム24FTDW における SQL Server のベスト プラクティス29データ アーキテクチャ30テーブルの構造30テーブルのパーティション分割31インデックス作成31xVelocity インメモリ列ストア インデックス32データベースの統計34圧縮35データの断片化の管理35ファイル システムの断片化35複数のファイル グループ38データの読み込み38増分読み込み38データの移行41ベンチマークと検証43ベースライン FTDW 検証の実行44SQLIO を使用したベースラインのテスト45Fast Track データベース ベンチマークの実行48MCR の計算49BCR の計算50公開 FTDW リファレンス アーキテクチャ53結論53付録55FTDW システム サイジング ツール55ユーザー定義の FTRA の検証55架空 I/O テスト55SQLIO を使用したテスト ファイルの生成55ワークロードのテスト58サーバーの MCR の測定 (省略可能)58ワークロードの BCR の測定59クエリの消費率に影響する要因63

FTDW の変更履歴

次の表は、『Fast Track Data Warehouse リファレンス ガイド』の過去のバージョンからの主な変更点をまとめた履歴の一覧です。

説明

バージョン

注

場所

SQL Server 2012 で新たに追加

4.0

SQL Server のベスト プラクティスに関連した他のドキュメントへのリンク

重要

SQL Server 2012 で新たに追加

4.0

ベンチマークと検証

注意

SQL Server 2012 で新たに追加

4.0

メモリ要件

RAM

SQL Server 2012 で新たに追加

4.0

xVelocity メモリ最適化列ストア インデックス

列ストア インデックス

SQL Server 2012 で新たに追加

4.0

ソリッド ステート ストレージ

ソリッド ステート ストレージ

SQL Server 2012 で新たに追加

4.0

検証と列ストア インデックス

検証

SQL Server 2012 で新たに追加

4.0

ベースライン I/O の検証

SQLIO

表 1: 変更履歴

概要

このドキュメントでは、SQL Server Fast Track Data Warehouse (FTDW) プログラムのコンポーネント アーキテクチャと操作方法について解説します。最終的には、データ ウェアハウスのさまざまなワークロードに対応するベースライン レベルのパフォーマンスを、運用開始時点で達成し維持するために必要な、Microsoft SQL Server データベース システムの最小アーキテクチャ (ソフトウェアとハードウェアを含む) について検証します。

対象読者

このドキュメントの対象読者は、IT プランナー、設計担当者、DBA、ビジネス インテリジェンス (BI) ユーザーです。FTDW に適合した SQL Server のワークロードに対応する、実績ある標準的なシステム アーキテクチャの導入に関心のある方を想定しています。

Fast Track Data Warehouse

SQL Server Fast Track Data Warehouse プログラムは、データ ウェアハウスのワークロードに対応するために、ハードウェアとデータベースをバランスよく導入する基本的な手法と具体例を示します。詳細については、このドキュメントの「FTDW のワークロード」のセクションを参照してください。

バランスは、SQL Server の主要なシステム コンポーネント (ストレージ、サーバー、ストレージ ネットワーク、データベース、オペレーティング システム) に対する 1 つの基準です。これらのコンポーネントをそれぞれ調整することで、最適な構成を目指します。目標は、運用を開始した時点で、SQL Server のデータ処理能力とハードウェア コンポーネント リソースが効率よく機能するバランスを達成することです。理想とされるのは、データ ウェアハウスのワークロードに求められるストレージ容量とパフォーマンスを、最低限のシステム ハードウェアで実現する構成です。

Fast Track

SQL Server Fast Track ブランドは、FTDW リファレンス アーキテクチャ (FTRA) の原則に適合したコンポーネント ハードウェア構成に与えられます。それぞれの FTRA には、主要な構成、検証、およびデータベースのベスト プラクティス ガイドラインとワークロードが定められています。Fast Track プログラムを構成する基本原則を次に示します。

· ワークロード固有のベンチマーク。システムの設計と構成は、実際の同時実行クエリのワークロードを基準に行います。

· ハードウェア コンポーネントの細部にわたる検証済みの仕様。

· データベースの機能と主要ハードウェア リソースの関係における、コンポーネント アーキテクチャのバランス。

なぜ FTDW か

FTDW が顧客にもたらす高い価値は、以下の原則によって支えられています。

· 主要なシステム コンポーネントの全体的なバランスをあらかじめ決める。これによって、CPU やストレージ リソースが浪費されるリスクが最小限に抑えられます。このようなことは、アプリケーション レベルでは決して実現できません。

· 運用開始時点で予測可能なパフォーマンスを実現する。選択されたサーバーやワークロードに合わせて、SQL Server アプリケーションの機能に適合するような処理能力で Fast Track が事前に構成されます。

· ワークロード本位である。FTDW は、データベース構成に汎用的に対応するのではなく、データ ウェアハウスのユース ケースに合わせて調整されます。

手法総合的なコンポーネント アーキテクチャ

SQL Server FTDW リファレンス アーキテクチャは、データベース システム アーキテクチャの主要コンポーネント間の複雑な関係に最適なバランスを確保するための実用的なフレームワークです。図 1 に示したのは、通称スタックと呼ばれるコンポーネント アーキテクチャです。

図 1: Fast Track データベース コンポーネント アーキテクチャの例

スタックのコンポーネントはそれぞれ、SQL Server 内でデータを処理するために必要な一連の過程を分担しています。統合されたシステムとしてスタックを評価することで、各コンポーネントの実際の帯域幅を判断するベンチマークを作成できます。これを利用して、所定のスタックに関して、SQL Server アプリケーションの機能に十分対応できるスループットを個々のコンポーネントで提供することができます。

ワークロードに合わせて最適化された手法

データベース アプリケーションのワークロードが変われば、最適なリソース バランスを得るために必要となるコンポーネント アーキテクチャも大きく変わる場合もあります。その典型的な例が、要求の規模が小さいルックアップ ベースのオンライン トランザクション処理 (OLTP) のワークロードと、スキャンを多用し要求が大量に発生する分析データ ウェアハウスとの違いです。OLTP のユース ケースでは、少数の行をデータセットから短い待機時間で取得するために、インデックスの構築が頻繁に発生します。多くの場合、このデータセットには履歴データ ボリュームがほとんど存在しません。この種のデータベース操作はディスク ヘッドの移動が激しく、典型的なランダム I/O のスキャン パターンを発生させます。データ ウェアハウスなどの分析関連のユース ケースでは、OLTP に比べてはるかに多くのデータ要求が発生する可能性があり、シーケンシャルなディスク スキャンの合計スループットを向上することができれば、大きなメリットが期待できます。

この対照的なユース ケースでは、バランスのとれたコンポーネント スタックを実現することが重要になります。最新の SAS ディスク ドライブの平均的なディスク単位のランダム I/O スキャン速度は、同一ハードウェアのシーケンシャルなスキャン速度の 10 分の 1 にとどまる場合があります。従来は 1 秒あたりの操作の回数 (IOPS) が重視されがちでしたが、Fast Track データ ウェアハウスのワークロードで重視されるのは、高い I/O スキャン速度 (MB/秒) を安定して達成することです。

ワークロードがまったく異なるという問題は、ユーザーのワークロードの特性を明確に把握することで解決します。SQL Server Fast Track のワークロードによって、一般的なデータベース アプリケーションのユース ケースを個別に定義する、性質を表す複数の属性が構成されます。また、各ワークロードは、標準的なベンチマーク クエリを含む量的な尺度によって表されます。ワークロード別のベンチマークを使用して、データベース構成、ベスト プラクティス、および推奨コンポーネント ハードウェアを検証します。

検証済みの SQL Server Fast Track リファレンス構成

すべての公開 Fast Track リファレンス アーキテクチャは、このリファレンス ガイドに記載された一連の原則とガイドラインへの適合が確認されています。そのプロセスについては、このドキュメントの中でいくつかの例を紹介しています。

概要

このリファレンス ガイドで取り上げる SQL Server FTDW の仕様では、ワークロードを基準にコンポーネントのバランスが調整されています。この仕様の背景には、汎用的なプロビジョニングはデータベースの多様なユース ケースに向かず、コストも大きくなる場合があるという認識があります。ビジネス要件が複雑化し、データ ボリュームが急増する中で、より現実的な手法が求められています。このドキュメントでは、基本となるリファレンス アーキテクチャ、ハードウェア コンポーネントおよびソフトウェア コンポーネントのベンチマーク、そして対象を明確に定めたワークロードを組み合わせて説明し、バランスのとれたコンポーネント アーキテクチャを達成するための現実的な手法を紹介します。

FTDW のワークロードデータ ウェアハウスのワークロード パターン

通常、データ ウェアハウスが受け付けたクエリを処理するには、大量のデータにアクセスする必要があります。データ ウェアハウスは、さまざまな利用者 (財務部門、マーケティング、事業部門、リサーチ チームなど) からの多様なクエリに対応することが求められます。

これまでは、従来のデータ ウェアハウス システムの限界を克服するために、インデックスの構築、データの事前集計、低レベルのデータに対するアクセスの制限などの従来型の RDBMS 最適化手法に頼ってきました。こうした手法はメンテナンスの負荷が大きく、十分な保守時間帯を確保しても時間が足りなくなることが少なくありません。データ ウェアハウスが膨張し、利用者が急増すると、このようなユース ケースに特化した最適化が困難になります。特に、後からデータが追加されたり訂正されたりする場合、その傾向が顕著になります。

この問題に対処するためによく行われるのは、単純にドライブを増やすという対策です。スキャン中心のワークロードにシーク中心の I/O インフラストラクチャを割り当てることで生じた I/O パフォーマンスの問題を解決するために、比較的小規模のデータ ウェアハウスを数百台のディスクでまかなっているケースも少なくありません。このようなケースが多いのは、従来からシーク中心で最適化されることの多い大規模共有ストレージ エリア ネットワーク (SAN) 環境です。多くのストレージ I/O で基準となっているパターンや手法の多くではランダム I/O アクセスが推奨されていますが、スキャンの比重が大きいデータ ウェアハウスのワークロードに対しては、ディスクの待機時間が増加し、ストレージ サブシステムの全体的なスループットが低下します。

Fast Track Data Warehouse は、それとは異なる方法でデータ ウェアハウスのワークロードに対する最適化を実現します。シークではなく、効率的なディスク スキャン アクセスに合わせてデータベース ファイルとデータベース構成を調整することで、個々のディスクのパフォーマンスを何倍も向上させることができます。その結果、ディスクあたりのパフォーマンスが向上し、SQL Server で特定のワークロードのデータを処理するために必要な I/O スループットを少数のディスクで十分に確保できます。さらに、ディスク シークを改善するために使用されるインデックス ベースの最適化手法も、一部は使用せずに済みます。

ワークロードの評価

FTDW ベースのシステムのワークロードを分析する際は、このドキュメントで取り上げているベスト プラクティスやシステム構成に準拠することを考慮してください。データ ウェアハウスの要件は顧客によって異なります。FTDW ベースで設計されたシステムに、特定の要件 (データベース レプリケーションなど) が適合しない場合もあります。このタイプのワークロード評価の主要な基準を以下に示します。

スキャン中心

データ ウェアハウスのワークロードに伴うクエリは、大量の行を頻繁にスキャンします。そのため、ディスクのシーク タイムを重視する従来のワークロードと比べ、ディスク スキャンのパフォーマンスに対する優先度が高くなります。FTDW リファレンス アーキテクチャは、ディスク スキャンのパフォーマンスを最優先に、ハードウェア コンポーネントとデータベース ソフトウェア コンポーネントを最適化します。それにより、シーケンシャルなディスク読み取りの効率が向上し、それに伴ってドライブあたりのディスク I/O のスループットも向上します。

不揮発性 (変更の頻度が低い)

書き込み後のデータが変更されることはほとんどありません。同じデータベース テーブルに関連付けられたページを連続した記録位置から移動するような DML 操作 (SQL の更新操作など) は、慎重に扱う必要があります。そのような変更を頻繁に行うワークロードは、FTDW に適しているとは言えません。高い頻度で変更が生じる場合は、定期的にメンテナンスし、断片化を最小限に抑えることをお勧めします。

インデックスが軽量

非クラスター化インデックスを追加すると、一般的には 1 件から数件程度のレコードをルックアップする際のパフォーマンスが向上します。しかし、大量の行が取得対象となるようなテーブルに非クラスター化インデックスが適用された場合、ランダムなディスク シーク操作が発生し、全体的なシステム パフォーマンスが低下するおそれがあります。インデックスのメンテナンスでもデータ管理のオーバーヘッドが著しく増大し、サービス レベル契約 (SLA) を達成できなくなるリスクや、所定の時間内にデータベースの読み込みが完了しなくなるリスクが発生します。

これに対し、シーケンシャルなスキャンの速度は、ランダム アクセスよりも 10 倍以上高速です。セカンダリ インデックスを導入してランダム シークの使用を最小限に抑えたシステムは、一般的に、I/O の連続平均速度が非常に高くなります。つまり、ストレージの I/O リソースを効率よく利用し、大規模なスキャン型のクエリに対応する予測可能なパフォーマンスを向上できることになります。

FTDW では、対象となるワークロードの性質に合ったデータベースの最適化手法が規定されています。効率的なスキャン ベースのディスク I/O をサポートするデータ構造には、"クラスター化インデックス" と "範囲パーティション" があります。データのアーキテクチャに応じて FTDW 環境を最適化する際に、この 2 つのデータ構造を活用することをお勧めします。

パーティションがアラインメントされている

FTDW のワークロードに共通する特徴は、SQL Server のパーティション分割を有効活用できる点です。パーティション分割によって、データのライフサイクル管理が容易になり、時間の経過に伴う断片化を極力減らすことができます。さらに、大規模なスキャンのクエリ パターンでは範囲パーティション条件を利用でき、断片化やディスク I/O のスループット低下を招くことなく、テーブル スキャンを大幅に減らすことができます。

その他の考慮事項

データベースのワークロードを評価する際は、他にも次の点を考慮する必要があります。

· データベースを最適化するための方法である軽量インデックスの実装と管理は、FTDW のワークロードの基本要件です。

· データ ウェアハウス内のデータの断片化が最小限に保たれていることが前提条件となります。そのためには、次のことが必要になります。

· 最も注意が必要な断片化の種類は、フラグメント サイズで評価することができます。1 つのフラグメントは 8K のデータベース ページの連続する割り当てを表します。

· ストレージの増設によってサーバーを拡張する場合、高いパフォーマンスが要求されるテーブルについては、すべてこのホワイトペーパーのガイドラインに従った方法でデータを再投入する必要があります。

· 行レベルの更新処理が定期的に発生するテーブルなど、変化しやすいデータ構造を実装する場合は、メンテナンス (最適化、インデックスの再構築など) を定期的に行い、断片化を解消する必要があります。

· 一連のクラスター キー ID が既存の範囲と重複しているクラスター インデックス テーブルを読み込むと、断片化の大きな原因となります。このリファレンス ガイドに示しすベスト プラクティスに従って、注意深く監視、管理する必要があります。

· データ ウェアハウスの利用目的は、顧客によってさまざまです。顧客の要件が FTDW ワークロードの特性に適しているかどうか、十分に検討する必要があります。

データ ウェアハウスのワークロードの定性的な特性

FTDW のワークロードは、データベース操作に関連した各種の性質によって定義できます。それらの性質は、大きく次の領域に分けることができます。

· ユーザーの要件とアクセス パターン

· データ モデル

· データのアーキテクチャ

· データベースの最適化

次の表は、OLTP または ODS (Operational Data Store) のワークロードを比較対象として、データ ウェアハウスのワークロードの特性をまとめたものです。

特性

ワークロードの親和性:

データ ウェアハウス

OLTP/ODS

ユース ケースの説明

· 読み取りがほとんど (9 : 1)

· 更新はほぼデータの品質要件に限定される

· 大量の一括挿入

· クエリ全体の同時実行性は中～低。ピーク時の同時クエリ要求は 10 ～ 30 個

· 同時クエリのスループットは分析とレポートのニーズによって特徴付けられる

· 広範囲のスキャンまたは集計

· 複雑なクエリ (フィルター、結合、グループ化、集計)

· 読み取りと更新の比率は均等 (6 : 4)

· 同時クエリのスループットは運用ニーズによって特徴付けられる

· 粒度の細かい挿入と更新

· 高いトランザクション スループット (毎秒数万件など)

· ユーザー全体の同時実行性は中～高。ピーク時の同時クエリ要求は 50 ～ 100 個またはそれ以上

· 通常、トランザクションは非常に短い (ごく少数の不連続の行をルックアップするなど)

データ モデル

· 高度に正規化された一元的データ ウェアハウス モデル

· レポート作成要件をサポートするための非正規化は BI アプリケーション (SQL Server Analysis Services など) によって実施されることが多い

· ディメンション データ構造を持ち、同時実行性はさほど高くないものの大量の分析要求を処理するデータベースでホストされる

· 広範囲のスキャンが一般的

· アドホック分析に使用される

· 高度に正規化された運用データ モデル

· 意思決定を支援するために非正規化が頻繁に行われる。同時実行性が高く、待ち時間の短い不連続ルックアップ

· データの履歴の保存は限定的

· 運用上の意思決定を支援するために、他のソース システムから非正規化データ モデルが抽出される

データのアーキテクチャ

· ヒープ テーブル構造を多用する

· パーティション分割された大きなテーブルと、範囲を限定したスキャンを可能にするクラスター化インデックス

· 非常に大きなファクト テーブル (数百 GB ～数 TB)

· 非常に大きなデータ サイズ (数百 TB ～ 1 PB など)

· ヒープ テーブル構造の使用は最小限

· クラスター化インデックス テーブル構造による詳細なレコード ルックアップのサポート (1 回の要求で 1 行から数行)

· ファクト テーブルは比較的小さい (100 GB 未満)

· データ サイズが比較的小さい (数 TB など)

データベースの最適化

· セカンダリ インデックスの使用は最小限 (「インデックスが軽量」を参照)

· 一般にパーティション分割される

· セカンダリ インデックスによる最適化に強く依存

表 2: データ ウェアハウスのワークロードの特性

FTDW リファレンス構成の選択

このドキュメントで取り上げる FTDW の手法には、大きく 3 種類の利用方法があります。最初の 2 種類は、データ ウェアハウス用として公開されている適合 Fast Track リファレンス アーキテクチャの使用に関するものです。この 2 種類の方法では、FTDW プログラムの一環として公開されている事前設計されたシステムを選ぶことができます。3 つ目の方法は、ユーザー定義のデータ ウェアハウス システムの作成時に Fast Track の中心的手法をガイドラインとすることです。この場合、購入または展開の前に、ワークロードのプロファイリングとシステムのベンチマーク測定を綿密に行う必要があります。エンタープライズ サーバー、ストレージ構成、さらに SQL Server データベースの最適化に関する高度な技術知識が要求されます。

方法 1: 基本評価

このシナリオは、顧客が FTDW リファレンス構成の採用を既に決定しているか、それ以外の方法でサーバーと CPU の要件を決定していることを前提とします。この方法を選んだ場合、詳細なプラットフォーム評価 (実証試験) は不要です。

手順 1: 顧客のユース ケースを評価する

Fast Track Data Warehouse のリファレンス構成は、ソフトウェアとハードウェアの汎用的な構成ではなく、データ ウェアハウスのワークロードの特性に合わせて構成されます。構成を選択する際には、最初にこうした特性を見極めます。まず、顧客の主な要件や使用パターンを調査します。

ワークロード

FTDW のワークロードの定義には、ユース ケースを評価するうえで重要なポイントが 2 つあります。1 つは、ワークロードの主要要素を SQL Server のパフォーマンスとの関連で定義する一連の基本原則です。この原則は、特定のユース ケースと比較しながら慎重に評価する必要があります。原則が満たされない場合、対象ワークロードが FTDW リファレンス アーキテクチャに適合しない可能性があります。

2 つ目のポイントは、対象ユース ケースの概要です。これによって、ワークロードの適合性を評価するための合理的な評価基準が得られるだけでなく、ユース ケースの大まかな枠組みを把握することができます。

ワークロードの評価

以下、顧客のワークロードを評価する基本的な流れを箇条書きで示しています。これは性質に基づく評価であり、あくまでガイドラインと考えてください。

1. 対象となるワークロードの要件を明らかにする。FTDW のワークロードの特性と比較します。詳細については、このドキュメントの「FTDW のワークロード」のセクションを参照してください。

2. FTDW のベスト プラクティスを評価する。データベースの管理、データ アーキテクチャの最適化、システムの最適化に関連したベスト プラクティスを、対象のユース ケースや運用環境と比較して評価する必要があります。

意思決定

ワークロードを評価する目的は、検証済みの FTDW リファレンス アーキテクチャを十分な根拠に基づいて選択できるようにすることです。データ ウェアハウスの使用事例の大半は、FTDW のワークロードに適合する特性と適合しない特性が混在しているのが実情です。Fast Track リファレンス構成との親和性が強い優先度の高いワークロード特性について、以下に箇条書きで示しています。顧客の主要なユース ケースがこれらの特性と相反する場合は、Fast Track の手法がそのユース ケースに適合しない可能性があるため、慎重に評価する必要があります。

ワークロード

優先度の高いワークロード特性は次のとおりです。

· 主要なワークロードのデータ アクセス パターンがスキャン中心である (つまり、シーケンシャルなデータ配置のときに効率が高まる)。一般的には、1 回のクエリ要求で数万行から数百万行 (またはそれ以上) の読み取りが発生します。

· 一般的な OLTP ワークロードに比べてデータ容量が大きく、同時実行性が低い。

· データの変更頻度が低い。データ ウェアハウス全体の使用率に占める更新/削除の DML 操作の比率を低く抑える必要があります。

データベース管理

データベースの管理、データ アーキテクチャ (データ モデルとテーブル構造)、およびデータ統合の手法が含まれます。

· インデックスが軽量な、パーティション分割されたデータ アーキテクチャ。

· 適切な読み込み、ETL 手法、定期的なメンテナンスによってデータベースの断片化が適切に管理されている。

· データ増加要件が事前に把握できる。FTDW システムは、容量のバランスを考慮して事前に構築されています。ストレージを増設するためには、データの移行が必要となります。

手順 2: 公開 FTDW リファレンス アーキテクチャを選ぶ

顧客が事前にサーバーを想定しており、予算や経験に基づいて単純な評価を実施するケースがあります。また、帯域幅要件の分析の基準となる、ワークロードの容量や既存のシステムについて十分な情報が顧客から提供される場合もあります。いずれにしても、FTDW の基本評価としてプラットフォームをゼロから評価する必要はありません。そのようなときは、顧客の想定する要件に適合した FTDW 構成を選択してください。

方法 2: 完全評価

Fast Track 適合リファレンス アーキテクチャは、特定された顧客のワークロードに適合するハードウェア コンポーネント構成を示します。以降で紹介する手法を使って、データベース コンポーネントのアーキテクチャを合理的に選択することができ、ユース ケースの要件、パフォーマンス、スケーラビリティの最適なバランスを運用開始時点から実現できます。この手法を実行するには、データベース システム アーキテクチャとデータ ウェアハウスの展開に関する高度な知識と経験が必要です。通常、このプロセスには、Fast Track パートナーと Microsoft のテクニカル セールス リソースが携わります。

プロセスの概要

次のプロセス フローは、完全評価に基づく FTDW 選択プロセスをまとめたものです。

1. 対象となる使用シナリオで、Fast Track のワークロード特性を評価します。

2. 顧客のユース ケースに適合するサーバーと帯域幅の要件を特定します。評価を開始する前に、公開 FTDW リファレンス構成を選択してください。

3. 顧客のワークロード要件から、代表的なクエリを特定します。

4. そのクエリについて、SQL Server の BCR (Benchmark Consumption Rate) を計算します。

5. 必要な UDC (User Data Capacity) を計算します。

6. 適合する Fast Track リファレンス アーキテクチャの公開されている MCR (Maximum CPU Consumption Rate) および容量と、BCR および UDC の評価を比較します。

以降、完全評価プロセス フローの各ポイントについて説明します。

手順 1: 顧客のユース ケースを評価するワークロードの評価

このプロセスは「方法 1: 基本評価」と同じです。

FTDW 評価用ハードウェアの選択

システムの完全評価を始める前に、テストに使用する公開 FTDW リファレンス構成を選択して展開する必要があります。適切なリファレンス構成は、いくつかの方法で決定できます。一般的な方法は次のとおりです。

· 予算。予算の範囲内で最も容量が大きい (またはパフォーマンスが高い) システムを選択します。

· パフォーマンス。入手できる最もパフォーマンスの高いシステムを選択します。

· 社内分析。既存のハードウェアで実施したワークロード分析に基づいて決定します。

· アドホック分析。FTDW サイジング ツールを使用すると、対象となるデータベース ワークロードについての基本的な想定を基に、FTDW のシステム要件を簡単に計算することができます。このスプレッドシート ツールは、http://download.microsoft.com/download/D/F/A/DFAAD98F-0F1B-4F8B-988F-22C3F94B08E0/Fast%20Track%20Core%20Calculator%20v1.2.xlsx からダウンロードできます。

手順 2: 評価のメトリックを決定する

FTDW の完全評価には、次の 3 つのメトリックを使用します。これはハードウェア評価の意志決定における重要な基準となります。

· MCR (Maximum CPU Core Consumption Rate)

· BCR (Benchmark Consumption Rate)

· 必要な UDC (User Data Capacity)

各メトリックの計算の詳細については、このドキュメントの「ベンチマークと検証」のセクションを参照してください。

MCR

このメトリックは、特定のサーバーと CPU の組み合わせに対し標準的なクエリとデータセットを想定した、SQL Server の最大データ処理速度の尺度です。コアあたりの処理速度として得られ、メモリ キャッシュからのクエリに基づくスキャンとして測定されます。MCR は、Fast Track システム設計の出発点となります。MCR によって表されるのは、サーバー、CPU、ワークロードに対して必要な最大 I/O 帯域幅の推定値です。最小限のローカル ストレージとデータベース スキーマで特定の CPU の潜在的スループットを推測できるため、MCR は初期設計の目安となります。MCR は、あくまでシステム設計の出発点です。システム パフォーマンスの尺度ではありません。

BCR

BCR は、FTDW のワークロードと判断される一連のクエリによって評価されます。MCR の計算のようにキャッシュだけでなく、ディスクとキャッシュからの合計読み取り帯域幅に基づいて計算されます。顧客のワークロード パターンに合致した一連のクエリを評価基準とすることで、特定の顧客のユース ケースに合わせたインフラストラクチャを構築することができます。FTRA をパートナーが検証する場合は、一連のベンチマーク クエリを使用することで、負荷の大きいワークロードに対応したシステム設計を行います。まとめると、BCR は非常に大きいデータ ボリュームに対してワークロードを同時実行する際に複数のクエリを使用するデータ処理の実測指標と言えます。

UDC (User Data Capacity)

これは、SQL Server データベースに対して予想されるデータベース容量です。Fast Track UDC は、読み込み後にデータベースが圧縮されるときに、Fast Track システムに読み込むことのできる未圧縮のユーザー データ ファイルまたはストリームの推定量を表します。FTDW に使用される標準的な圧縮率は 3.5:1 です。

初期展開量を超えてストレージを増設した場合、データの移行が必要になる可能性があり、既存のデータが実質的に新しいデータベース ファイルの位置に書き込まれることになります。そのため、適切なリファレンス アーキテクチャを選択する際に、データベースの予想増加量とシステムの予想耐用年数を考慮しておくことが重要です。

手順 3: Fast Track Data Warehouse リファレンス アーキテクチャを選択する

BCR を計算したら、公開されている MCR および容量の評価 (公開 FTRA ごとに Fast Track パートナーによって提供されます) と比較します。パートナーの詳細については、「Fast Track データ ウェアハウス (http://www.microsoft.com/sqlserver/en/us/solutions-technologies/data-warehousing/fast-track.aspx)」を参照してください。

BCR メトリックは、テスト/評価システムの結果を、公開されている構成と比較して評価する際の共通基準として使用できます。顧客は BCR データを基に、テスト結果に最も適合した Fast Track オプションを選択することができます。

方法 3: ユーザー定義のリファレンス アーキテクチャ

FTDW の手法を利用して、特定のワークロードまたは一連のハードウェアに合わせたシステムを構築します。この方法を採用する場合は、SQL Server とそれを実行するハードウェア コンポーネントを深く理解している必要があります。以下の手順で、FTDW の原則に沿ってユーザー定義のリファレンス アーキテクチャを開発するための一般的な方法を簡単に紹介します。

手順 1: ワークロードを定義する

対象となるデータベースのユース ケースを把握することは、FTDW の構成の基本です。これは、このドキュメントで取り上げているガイダンスのカスタム アプリケーションにも同様に当てはまります。ワークロードの評価をコンポーネント アーキテクチャの設計に取り入れる際は、FTRA のガイダンス (具体的にはワークロードについてのトピック) を参考にしてください。

手順 2: コンポーネント アーキテクチャのベンチマークを測定する

以下に示したのは、定義済みのワークロードに対するリファレンス アーキテクチャを開発する際の基本的枠組みです。

1. 選択したサーバーと CPU の MCR (Maximum CPU Core Consumption Rate) を算出します。このドキュメントの「ベンチマークと検証」のセクションで示した方法で MCR を計算してください。FTDW 構成で公開されている MCR 評価を使用してもかまいません。一般的には、同じファミリの CPU は SQL Server データベースの CPU コア消費率も近い数値になります。

2. MCR 値を基にストレージおよびストレージ ネットワークの要件を見積もり、初期システム設計を作成します。

3. 初期システム設計に基づいてテスト システムを調達します。可能であれば、指定された構成をすべて反映するようにします。

4. BCR (Benchmark Consumption Rate) を算出します。ワークロードの評価に基づいて、クエリ (可能であれば代表的なクエリ一式) を特定します。このドキュメントの「ワークロードの BCR の測定」のセクションで説明した手法に従ってください。

5. その結果に基づいてシステム設計を調整します。

6. 最終的なサーバーとストレージの構成を決定します。

手順 3: システムの検証

システムのベンチマークを測定する目的は、手順 2. で特定されたハードウェア コンポーネントの構成とスループットを検証することです。このプロセスの詳細については、このドキュメントの「ユーザー定義の FTRA の検証」のセクションを参照してください。システムを検証するには、次の手順を実行します。

1. 決定したパフォーマンス要件と比較して、コンポーネントのスループットを評価します。実際のスループットが予測値と一致していることを確認してください。

2. 最終的な構成となるように再調整し、最終的なベンチマーク測定を行って、システムのスループットを検証します。一般的には、最終的な BCR がシステム MCR の 80% 以上を達成することが求められます。

FTRA 選択のまとめ

次の表は、FTRA 選択の 3 つの方法をまとめたものです。

方法

長所

短所

基本評価

· システムのセットアップと調達にかかる期間がきわめて短い (数日から数週間)

· 設計と評価のコストが最小限

· インフラストラクチャ スキル要件が比較的低い

· ストレージ容量が過剰になる場合や、CPU 速度が低くなりすぎる場合がある

完全評価

· 予想されるワークロードに合わせたリファレンス アーキテクチャを事前に定義できる

· ハードウェアのコストを削減できる可能性がある

· ソリューションの信頼度が高い

· 評価に要する時間と労力が大きい (数週間から数か月)

· 対象となるワークロードを詳細に把握する必要がある

ユーザー定義のリファレンス アーキテクチャ

· 既存ハードウェアを再利用できる

· 最新のハードウェアを導入できる

· ユース ケースに合わせてシステムを自由に構築できる

· 作業に数か月かかる

· インフラストラクチャに関する高度な専門知識が必要

· SQL Server に関する高度な専門知識が必要

表 3: 各評価方法の比較

FTDW の標準構成ハードウェア コンポーネント アーキテクチャ

現行の FTDW リファレンス アーキテクチャは、専用のストレージ構成をベースとします。現在公開されているオプションには、スイッチ SAN、直接接続 SAN、直接接続 SAS、SAS-RBOD、iSCSI などがあります。ディスク I/O のスループットは、独立した専用のストレージ エンクロージャとプロセッサを使用することによって確保されます。さらに詳しい情報と構成は、それぞれの Fast Track ベンダーから公開されています。図 2 に示したのは、SAN ストレージを利用した FTDW リファレンス アーキテクチャの、コンポーネント レベルの構成要素です。

図 2: ストレージ構成の例 (2 ソケット、12 コア サーバー)

コンポーネントの要件と構成サーバーのメモリ

合計 RAM: FTRA の RAM 容量は、論理上の最大スループット (一定時間にディスクやバッファーから読み取られる総ページ数) と CPU 使用率が最適なバランスとなるように、ベンチマークの結果に基づいて割り当てられます。表 4 は、SQL Server 2012 のリファレンス アーキテクチャに対して推奨されるメモリ割り当ての一覧です。ここに記載されている最大メモリの値は、物理的な限界を表しているのではなく、検証を経たシステムの平均値を表しています。

サーバー サイズ

最小メモリ

最大メモリ

1 ソケット

64 GB

128 GB

2 ソケット

128 GB

256 GB

4 ソケット

256 GB

512 GB

8 ソケット

512 GB

768 GB

表 4: SQL Server 2012 に推奨されるメモリ割り当て

以下に、システム メモリの要件を評価する際に重要となるその他の考慮事項を示します。

· キャッシュからのクエリ: キャッシュからのクエリを多く処理するワークロードについては、ワークロードの増加に応じて RAM の割当量を増やすことで、全体として大きなメリットが期待できます。

· ハッシュ結合と並べ替え: 大規模なハッシュ結合に依存したクエリや、大規模な並べ替え操作を行うクエリは、物理メモリの量を増やすことで効率が向上します。このような操作は少ないメモリ量では処理しきれず、ディスクへの書き込みが発生し、tempdb が頻繁に利用されます。その結果、サーバー上のデータ ドライブ全体にランダム I/O パターンが発生します。

· 読み込み: 使用可能なメモリ内で一括挿入を処理できない場合も、tempdb を利用した並べ替え処理が発生する可能性があります。

· xVelocity メモリ最適化列ストア インデックス: 列ストア インデックスのクエリ プランを頻繁に利用するワークロードは、表 4 に示した上限近くまで増強したメモリ プールを使用することで、効率的な実行が可能になります。

ファイバー チャネル SAN

HBA – SAN: HBA および SAN ネットワークのすべてのコンポーネントは、メーカーやモデルによって多少異なります。加えて、ストレージ エンクロージャのスループットは、SAN 構成や PCIe バスの能力に大きく左右される場合があります。この推奨事項は一般的なガイドラインであり、FTDW リファレンス構成の開発中に実施されたテストに従ったものです。

ゾーニングが利用される場合、Fast Track で使用されているポートだけがそのゾーンに存在する必要があります。FC ネットワークのトポロジと構成の詳細は、各 Fast Track パートナーから提供される技術構成ガイドに記載されています。その内容は、公開 FTRA ごとに異なります。

マルチパス I/O (MPIO): MPIO が構成されている必要があります。専用ストレージ アレイ上でホストされる各ボリュームには、少なくとも 1 つのアクティブ パスが必要です。

Fast Track の構成に使われる既定のポリシーは "サブセットを含むラウンド ロビン" ですが、それよりも適した構成が FTDW パートナーのエンジニアリング チームによって指定されるため、パートナーのリファレンス アーキテクチャで既定のポリシーが使用されることはほとんどありません。各パートナーのデバイス固有モジュール (DSM) やドキュメントで、それぞれ異なる設定が指定されている場合も多いため、構成する前に確認しておくようにしてください。

ストレージ

ローカル ディスク: Windows Server と SQL Server のインストール環境では、2 ディスクの RAID1 アレイが最小構成となります。仮想 RAM とページングの要件を満たす十分なディスク領域を確保する必要があります。通常は、システム RAM の 1.5 倍 (1.5 倍しても 250 GB 未満であれば 250 GB) の容量を空きディスク領域に確保してください。それ以外のディスク構成は、ユース ケースと顧客の希望に応じて決定します。

論理ファイル システム: 多くの Fast Track システムでは、ボリューム数が多いため、LUN はドライブ文字ではなく Windows フォルダーのパス (マウント ポイント) にマウントすることをお勧めします。

また、Windows オペレーティング システムのドライブ割り当てと、ストレージ エンクロージャ内の LUN (ボリューム)、RAID ディスク グループ、Windows Server マウント ポイントとの対応関係を把握しておくこともお勧めします。LUN を Windows のフォルダーにマウントする際に、マウント ポイントとボリュームに一定の命名規則を適用してもよいでしょう。デバイスの命名規則の詳細については、Fast Track パートナーの技術構成ガイダンスを参照してください。

ベンダー固有のツールを使用して、推奨されるボリューム命名規則を適用できる場合もあります。適切なツールが用意されていない場合は、Windows から 1 回に利用できるストレージ アレイ内のディスクを 1 つとし、ドライブ名を割り当てるようにすることで、物理上と論理上のトポロジを正しく作成することができます。

物理ファイル システム: 詳細な情報や詳しい手順については、このドキュメントの「アプリケーション構成」のセクションを参照してください。

ストレージ エンクロージャの構成: Fast Track パートナーの技術ドキュメントに特別な記載がない限り、エンクロージャの設定はすべて既定のままになっています。ファイル システムの構成に関する FTDW の仕様上、RAID グループや LUN 割り当てを目的に合わせて構成できるストレージ エンクロージャが必要です。FTDW のリファレンス構成とは異なるハードウェアやカスタム ハードウェアを評価する際には、この点を考慮する必要があります。

アプリケーション構成Windows Server 2008 R2

特に指定されていない限り、Windows Server 2008 R2 Enterprise オペレーティング システムは既定の設定を使用してください。最新のサービス パックと重要な更新プログラムをすべて適用してください。リファレンス アーキテクチャの多くは、マルチパス I/O 機能を必要とします。MPIO 構成の詳細については、特定のリファレンス アーキテクチャを対象とした Fast Track パートナーの技術構成ガイドを参照してください。.NET framework のインストールと既定の設定を適切な状態にするために、Windows Server 2008 R2 がアプリケーション サーバーの役割としてインストールされていることを確認してください。

SQL Server 2012 Enterpriseスタートアップ オプション

スタートアップ オプションとして -E を追加します。これにより、データベース テーブルの拡大に応じて、データベース テーブルに割り当てられる、各ファイルの連続エクステントの数が増えます。これによってシーケンシャル ディスク アクセスが改善されます。このオプションの詳細については、サポート技術情報の資料 329526 (http://support.microsoft.com/kb/329526) を参照してください。-E オプションが、データベースの起動時に確実に適用されるようにすることが重要です。このオプションは、大文字と小文字が区別されるほか、形式の違いも区別されます。オプションの前後に空白が入っていると、初期化の妨げになる場合があります。

スタートアップ オプションには、-T1117 も追加する必要があります。これは、自動拡張が有効になっている場合に、ファイル グループ内のすべてのファイルを均等に増加させるトレース フラグです。データベース ファイルの拡張に関して、FTDW の標準的な推奨構成は、領域を事前に割り当てる設定になっており、自動拡張は使用されていません (tempdb を除く)。詳細については、このドキュメントの「ストレージ構成の詳細」のセクションを参照してください。

"メモリ内のページのロック" オプションは有効にします。詳細については、「Lock Pages in Memory オプションの有効化 (Windows)」(http://go.microsoft.com/fwlink/?LinkId=141863) を参照してください。

- T834 は、ケース バイ ケースで検討してください。このトレース フラグを指定すると、データ ウェアハウスのさまざまなワークロードでスループット レートが向上する可能性があります。このフラグは、SQL Server のバッファー プール用メモリのラージ ページ割り当てを有効にします。このトレース フラグを含め、各種トレース フラグの詳細については、サポート技術情報の資料 920093 (http://support.microsoft.com/kb/920093) を参照してください。

注: 現時点の SQL Server 2012 では、データベースで列ストア インデックスが使用されている場合、–T834 の使用がサポートされません。列ストア インデックスを使用する予定がある場合は、このトレース フラグを使用しないでください。

SQL の最大メモリ

SQL Server に割り当てるメモリ量は、SQL Server 2012 ではサーバーの合計 RAM の 92% までとします。サーバーを利用するアプリケーションが他にも存在する場合、オペレーティング システムで利用できる RAM の残量が適宜調整されます。この設定は、Max Server Memory オプションで制御されます。検証済みリファレンス アーキテクチャに使用されているメモリ設定の詳細については、FTDW パートナーのドキュメントを参照してください。

リソース ガバナー

一般的なデータ ウェアハウスのワークロードには、大量のデータを扱う複雑なクエリが含まれています。こうしたクエリは大量のメモリを消費するため、メモリが不足し、ディスクへの書き込みが発生する場合があります。この動作は、リソース管理によって調整できます。SQL Server 2012 のリソース ガバナー テクノロジを使用して、リソース使用率を管理することができます。

SQL Server の既定の設定では、SQL Server のメモリ リソースの最大 25% がリソース ガバナーによって個々のセッションに割り当てられます。つまり、最悪の場合、使用可能なメモリの 25% 以上を消費するクエリが 3 つ実行されただけで、メモリを必要とする他のクエリがブロックされます。このとき、大きな Memory Grant を必要とする他のクエリは、リソースに空きが生じるまで待ち状態となります。

リソース ガバナーを使用すると、1 件のクエリに消費される最大メモリを減らすことができます。ただし、その結果、大量のメモリを消費するはずだった同時実行クエリが tempdb を利用するようになり、ランダム I/O が増加し、全体的なスループットが低下する可能性があります。多くのデータ ウェアハウス ワークロードでは個々のセッションが利用できるシステム リソースの量を制限することで効率が向上する場合がありますが、同時実行クエリのワークロードを分析して評価することをお勧めします。リソース ガバナーの使用方法の詳細については、「リソース ガバナーを使用した SQL Server ワークロードの管理」(http://msdn.microsoft.com/ja-jp/library/bb933866.aspx) を参照してください。

Fast Track ソリューションの各ベンダーのガイダンスやベスト プラクティスも参考にしてください。特に、比較的大きな 4 ソケットや 8 ソケットの Fast Track ソリューションは、リソース ガバナーの特定の設定を調整して、最適なパフォーマンスを確保している場合があります。

まとめると、制約を少なくすると個々のクエリのパフォーマンスを高めることができる一方で、制約を厳しくすると同時実行可能なクエリ数を保証できるという、トレードオフの関係が存在することになります。

リソース ガバナーのベスト プラクティスと一般的なシナリオの詳細については、ホワイト ペーパー『リソース ガバナーの使用』(http://msdn.microsoft.com/ja-jp/library/ee151608.aspx) を参照してください。

ストレージ システム

プライマリ データベースのストレージをハード ディスク ドライブ (HDD) に格納する FTDW リファレンス アーキテクチャでは、長期的にシステム パフォーマンスを維持するために、断片化の管理が欠かせません。このため、ストレージとファイル システムの構成が詳細に指定されています。

ストレージ システム コンポーネント

図 3 は、ストレージ構成の 3 つの主要レイヤーが組み合わさって統合データベース スタックを形成している環境を示しています。これはあくまで参考事例と考えてください。実際のトポロジは、Fast Track パートナーによって大きく異なります。代表的なデータベース スタックは、次の要素で構成されます。

· 物理ディスク アレイ: 4 スピンドルの RAID 1+0 が、標準の手法です (図 3)。一部のパートナーでは SQL Server 2008 R2 および SQL Server 2012 のリファレンス アーキテクチャに RAID 5 および RAID 6 を使用している場合もあります。

· オペレーティング システム ボリューム割り当て (LUN)

· データベース: ユーザー、システム Temp、システム ログ

図 3: 各ディスク グループで 1 つの LUN (ボリューム) を使用した、3 台のストレージ エンクロージャを基づく FTDW システムのサンプル ストレージ アーキテクチャの全体像

ストレージ構成の詳細

それぞれのストレージ エンクロージャについて、次の手順を実行します。

1. 4 台のディスクで構成されるディスク グループを、RAID 1+0 (RAID 10) を使用して作成します。ストレージ エンクロージャ 1 台あたりの実際のディスク グループ数は、ベンダーによって異なります。詳細については、ベンダーのドキュメントを参照してください。一般的には、LFF (Large Form Factor) エンクロージャの場合は RAID10 ディスク グループで 2 つ、RAID1 ディスク グループで 1 つになります。SFF (Small Form Factor) エンクロージャの場合は、RAID10 ディスク グループで 5 つとなります。プライマリ データのファイル グループの格納場所として使用されるボリュームの総数が 32 を超えないようにしてください。ストレージ システムの LUN 数の合計がそれを超える場合は、より大きなディスク グループを使用することで、同等の I/O スループットを維持しながら LUN 数を減らすことができます。たとえば、4 ディスクの RAID 10 ディスク グループを 1 LUN で使用する代わりに、8 ディスクの RAID 10 ディスク グループを 1 LUN で使用します。ディスク グループが大きくなると、スループットや効率が若干低下します。この点は、ストレージ テクノロジによって異なります。

2. 1 つを除くすべてのディスク グループをプライマリ ユーザー データ (PRI) 専用にします。SQL Server データベースのファイル グループの場所として代表的なものが、プライマリ ユーザー データの場所です。すべての FTRA で、1 つの PRI ディスク グループにつき 1 ～ 2 個の LUN が必要となります。選択したリファレンス アーキテクチャのベンダーのガイダンスを参照してください。これらの LUN は、SQL Server のデータベース ファイル (.mdf および .ndf ファイル) の格納場所として使用されます。

3. ストレージ エンクロージャ内でプライマリ データに割り当てられた各ディスク ボリュームに、プライマリ ストレージ プロセッサが均等になるように割り当てます。たとえば、ストレージ エンクロージャ内の 4 つのディスク ボリュームがプライマリ データ用に割り当てられている場合、ストレージ プロセッサ "A" とストレージ プロセッサ "B" にそれぞれ 2 つずつボリュームが割り当てられます。

4. 残りのディスク グループに、データベースのトランザクション ログをホストするための LUN を 1 つ作成します。より大規模な Fast Track 構成では、システム内の最初の数台のストレージ エンクロージャにログの割り当て先を限定します。この場合、その他のディスク グループは、データベース以外のステージングに使用するか、コストを削減するために不使用とします。

データベースごとに次の手順を実行します。

1. PRI LUN ごとに 1 つのデータ ファイルを含んだファイル グループを少なくとも 1 つ作成します。すべてのファイルのサイズが等しくなるようにしてください。1 つのデータベース内で複数のファイル グループを使用してオブジェクト (データの読み込みを支援するステージング データベースなど) を分離する場合、各ファイル グループの場所として、すべての PRI LUN を含めるようにします。

2. 各ファイル グループに使用するファイルを作成したら、それを予想される最大のサイズに事前割り当てします。予想されるオブジェクトを十分に保持できるサイズを確保してください。

3. データ ファイルの自動拡張オプションは無効にし、現在のサイズの上限に達したときはすべてのデータ ファイルを手動で拡張するようにします。

4. ユーザー データベースとファイル グループの推奨事項の詳細については、このドキュメントの「データの断片化の管理」のセクションを参照してください。

tempdb について、次の手順を実行します。

1. 領域を事前割り当てした後で、各 LUN に 1 つずつデータ ファイルを追加します。すべてのファイルのサイズが等しくなるようにしてください。

2. ログ ファイル専用の LUN の 1 つに一時ログ ファイルを割り当てます。

3. 自動拡張を有効にします。データ ウェアハウスのワークロードの場合、拡張増分を多めにするのが一般的です。最初は、初期ファイル サイズの 10% に相当する値をお勧めします。

4. データベースや tempdb のサイズを検討する際は、SQL Server の標準的なベスト プラクティスに従ってください。データ ウェアハウスの初期データ読み込み時や移行フェーズ時に、領域の割り当てを増やさなければならない場合があります。詳細については、SQL Server オンライン ブックの「tempdb に使用するディスク領域の計画」(http://msdn.microsoft.com/ja-jp/library/ms345368.aspx) を参照してください。

トランザクション ログについて、次の手順を実行します。

1. トランザクション ログ領域に割り当てた LUN の 1 つに、データベース別に 1 つのトランザクション ログ ファイルを作成します。利用可能な複数の LUN に各種データベースのログ ファイルを分散させるか、ログの増大に対応するために必要に応じて複数のログ ファイルを使用します。

2. ログ ファイルの自動拡張オプションを有効にします。

3. ログの容量は、表 5 に記載した要件を満たしている必要があります。システム設計の特定の性質に応じて、ある程度逸脱してもかまいません。

システム RAM (GB)

FT 定格容量 (テラバイト)

推奨される最小ログ割り当て

ミラーリングされた空き領域 (GB)

<= 96

<=10

300 GB x 1 ボリューム

<= 128

>10

<=40

300 GB x 2 ボリューム

または

600 GB x 1 ボリューム

表 5: 推奨されるログ割り当て

SQL Server のトランザクション ログの割り当てと管理については、既存のベスト プラクティスを参照してください。

ソリッド ステート ストレージ

プライマリ (PRI) データにソリッド ステート ストレージを利用する FTDW リファレンス アーキテクチャは、管理のシンプルさ、低い運用コスト、保守計画の立てやすさなど、さまざまな利点があります。

管理がシンプル: ソリッド ステート ストレージは断片化の管理が不要です。SQL Server のスタートアップ オプション –E は使用する必要がありますが、それ以外の最適化やページ割り当ての管理は不要です。このシンプルさが、FTDW 環境の長期的管理を大幅に省力化しています。また、ディスク グループを大きくしたり、ボリューム/LUN 数を小さくしたりする際のパフォーマンス低下も発生しません。ファイル グループの作成と保守を楽に行うことができます。

I/O の安定性: ソリッド ステート ストレージは、同時実行の負荷が大きい状況やページが断片化している状況でのパフォーマンスの低下がごくわずかで済みます。また、ランダム読み取り (シーク) の混在するワークロードが、大規模な要求 (スキャン) の I/O パターンに悪影響を及ぼすこともありません。

保守計画が立てやすい: ソリッド ステート ストレージは、多くの場合、書き換え寿命をソフトウェアで監視することができるため、予測困難な物理的故障の発生頻度を低く抑えることができます。

運用コストが低い: ソリッド ステート ストレージは高価ですが、単位容量あたりの I/O スループットが非常に優れています。FTDW ワークロードの実効 I/O 速度は、300 GB、1 万 RPM の SAS HDD で平均 50 MB/秒です。これに対し、エンタープライズ クラスの MLC SSD では、容量 600 GB で 150 ～ 200 MB/秒が実現されています。さらに、ソリッド ステート ストレージは消費電力がきわめて低く、発生する熱量も小さいため、多くは高密度設置ソリューションに対応しています。

ソリッド ステート ストレージの構成

ソリッド ステート ストレージを PRI ボリュームに使用する場合は、FTDW ストレージ構成の標準ガイドラインに以下の調整を加えることができます。

· ミラーリングが必要な場合、RAID1+0 または RAID5 を使用できます。ソリッド ステート ストレージでの FTDW ワークロードについては、パフォーマンスが低下せず、容量面でも有利な RAID5 が最適です。

· LUN とボリュームの数を減らすことができ、ストレージ ユニットあたりの PRI ボリューム数を最小で 1 つにすることができます。状況によっては、PRI ボリュームの数を CPU コア数の倍数にすると効果的です。最小 PRI ボリューム数は 2 です。

· トランザクション ログはソリッド ステート ストレージに置くこともできますが、通常、FTDW のワークロードでログがボトルネックになることはありません。ログを従来の HDD に格納することでコストを削減することができます。ローカル ストレージに Windows Server と SQL Server をインストールする場合についても、同じことが言えます。

· データベースの論理的な断片化はソリッド ステート ストレージの I/O パフォーマンスに影響しないため、ページの断片化管理やクラスター インデックスの並列読み込みに関する推奨事項は無視することができます。

FTDW における SQL Server のベスト プラクティス

ここでは 2 つのケースについて、Fast Track のワークロードに対するベスト プラクティスを検証し、まとめています。1 つ目のケースは、Fast Track のベスト プラクティスが、確立されている SQL Server のベスト プラクティスと実質的に異なる場合です。2 つ目のケースは、ベスト プラクティスがそもそも存在しない場合や、実施が難しい場合です。SQL Server データベースの導入に関するドキュメントは豊富に存在しているため、ここですべてのベスト プラクティスを紹介することはしません。FTDW の導入に関連するさまざまな事柄については、SQL Server の既存の技術ドキュメントやベスト プラクティスを参考にしてください。

重要: このガイドには、SQL Server 2008 R2 向けに執筆されたドキュメントへのリンクがいくつか紹介されています。その内容の多くは SQL Server 2012 にも該当すると思われますが、最新版のドキュメントが公開されれば、そちらを参照してください。そのようなリンクについては、このリファレンス ガイドの今後のリリースで更新されます。

データ アーキテクチャテーブルの構造

データベースのデータを格納するために使用するテーブルの種類は、シーケンシャル アクセスのパフォーマンスに大きく影響します。クエリ プランでシーケンシャル I/O のパフォーマンスを限界まで高めるには、この点を踏まえて物理スキーマを設計することがきわめて重要です。

選択したテーブルの種類によって、テーブルのデータの通常のアクセス方法が変わります。以下の情報を参考に、格納するデータの特性に基づいてテーブルの種類を検討してください。

ヒープ テーブル

ヒープ テーブルは、純粋なシーケンシャル I/O によるテーブル スキャンを実現します。一般的に、テーブルの断片化に伴うオーバーヘッドは小さくなります。クラスター化インデックス テーブルに見られるような最適化された (直接アクセスによる) 範囲ベースのスキャンは本質的に発生しません。ヒープ テーブルの一定範囲をスキャンする状況では、テーブル全体 (パーティション分割が適用されている場合は該当する範囲パーティション) がスキャンの対象となります。

ヒープ テーブルのスキャンは、32 ファイルで最大スループットに達します。そのため、LUN 数が 32 を超えるシステムや、コア数が 16 を超えるシステムで大きなファクト テーブルにヒープを使用するためには、リソース ガバナー (DOP 制約) を使用するか、または標準的な Fast Track データベース ファイルの割り当てへの変更が必要になる場合があります。

ヒープ テーブルが最も適しているのは次のケースです。

· テーブル参照に対して実行される優先度の高いクエリのほとんどで、述語で参照される列が不揃いであるか、列述語がまったく使用されていない。

· クエリで通常実行されるのが、範囲の限定されたスキャンではなく、大規模なスキャンである。たとえば、Analysis Services キューブにデータを入力するためだけに使用されるテーブルなどです (その場合、ヒープ テーブルは、入力先の Analysis Services キューブと同じ粒度で分割する必要があります)。

· インデックス管理の増分オーバーヘッドがなく、クエリ ワークロードの要件が満たされている。または、読み込みのパフォーマンスが何より重要である (ヒープ テーブルは読み込みが速い)。

クラスター化インデックス テーブル

データ ウェアハウス環境でクラスター化インデックスの効果が最も期待できるのは、そのキーが範囲限定列 (日付列など) であり、対応するクエリのワークロードの制限条件に使用される頻度が高いときです。この場合、インデックスを使用してスキャン対象のデータを大幅に絞り込み、最適化することができます。

クラスター化インデックス テーブルが最も適しているのは次のケースです。

· 範囲限定列がテーブルに存在し、そのテーブルに対する優先度の高いクエリ ワークロードを実行するシナリオの多くで、その範囲限定列がクエリの範囲を絞り込むために使用されている。FTDW の構成では、パーティション分割されたクラスター化インデックスの日付列は同時に、クラスター化インデックスのキーになっている必要があります。注: クラスター化インデックス テーブルについては、日付パーティション列以外のクラスター化インデックス キーを選択すると効率が向上する場合があります。ただし、既存のクラスター化インデックスのキーの範囲と重なる新しいデータによってページ分割が発生するため、パーティション全体が読み込まれない限り、断片化が進行するおそれがあります。

· 範囲を限定した粒度の細かいルックアップを行うクエリをテーブルに対して実行することが多い (テーブル全体や、複数の範囲にまたがる大規模なスキャンは行われない)。

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

テーブルのパーティション分割は、FTDW のデータベースの断片化を管理する重要な手段として利用できます。たとえば、パーティション分割を使用すると、テーブル内の一定の範囲のユーザー データを大きなブロック単位で更新または削除でき、テーブルの他の部分を参照する必要がありません。一方、クラスター インデックスから 1 行ずつ削除した場合、エクステントが著しく断片化する可能性があります。一般的には、時間が経過して特定範囲のデータに対する DML 操作の頻度が減った後で、新しいパーティションを再構築します。それ以降、そのパーティションは DML 操作で変更されることが少なくなり、エクステントの断片化は最小限で済みます。

また、主に SQL Server Analysis Services キューブへのデータ入力に使用される大きなテーブルをヒープ テーブルとして作成し、キューブのパーティションに合わせて分割することができます。データにアクセスする際は、大きなテーブルの中の、関連するパーティションだけをスキャン対象とすることができます (Analysis Services の ROLAP モードをサポートするパーティションは、クラスター化インデックスとして構築した方がよい場合もあります)。

テーブルのパーティション分割の詳細については、ホワイト ペーパー『SQL Server 2008 を使用したパーティション テーブルとパーティション インデックス』(http://msdn.microsoft.com/ja-jp/library/dd578580(v=SQL.100).aspx) を参照してください。

インデックス作成

FTDW のインデックス作成では、次のガイドラインを考慮してください。

· 日付範囲または一般的な制限条件にクラスター化インデックスを使用する。

· 列ストア インデックスを可能な限り使用する。FTDW 環境で列ストア インデックスを扱う際のベスト プラクティスについては、次のセクションで説明します。

· 非クラスター化インデックスは、粒度の細かいルックアップが必要であり、テーブルのパーティション分割で十分なパフォーマンスが得られない状況でのみ予約する。可能であれば、非クラスター化インデックスではなく列ストア インデックスを使用してください。

· データ ウェアハウスの一部のワークロードでは、非クラスター化カバリング インデックスが適している場合がある。この点は、ケース バイ ケースで評価し、列ストア インデックスと比較して判断する必要があります。

xVelocity インメモリ列ストア インデックス

SQL Server 2012 には、"列ストア インデックス" という、列指向のテクノロジを使った新しいデータ ウェアハウス クエリ アクセラレーション機能が導入されています。この新しいインデックスに加え、クエリ処理機能が強化されたことで、さまざまな分析クエリにおけるデータ ウェアハウス クエリのパフォーマンスが向上しています。

xVelocity のメモリ最適化列ストア インデックスでは、対象となる列のすべてのデータが別個のページに格納されるため、"純粋" な列ストア型と言えます (ハイブリッド型ではありません)。列ストア インデックスは、I/O のスキャン パフォーマンスとバッファー ヒット率を高め、FTDW の設計手法とも高い親和性があります。

ベスト プラクティス

列ストア インデックスのオブジェクトはテーブルと併存し、非クラスター化インデックスと同様の方法で作成されます。この事実は、漸増的なストレージ容量の必要性を示しています。列ストア インデックスを別個のファイル グループに作成する必要はありませんが、インデックスの対象となるテーブルが頻繁に変更されると予想される場合は例外です。変化の激しい環境では、列ストア インデックスを別のファイル グループで管理することで、長期的なページの断片化を効率的に管理することができます。

正規化されたデータ モデルに対する列ストア インデックスの作成

標準的なデータ モデル (3NF) は、複数の大きな (ファクト) テーブルの結合を伴うことが少なくありません。現在こうしたタイプの結合は列ストア インデックスの処理には適しておらず、列ストア インデックスを使わないクエリ プランと比べて、パフォーマンスが低くなる場合があります。標準的なデータ モデルで生じるこの問題は、次の手法で回避できる可能性があります。

· クエリ レベルのヒントを使用して、列ストア インデックスの処理が使用されないようにする。

· OPTION(IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX) を使用する。

· クエリを書き換える。詳細については、このドキュメントの「列ストア インデックスの一般的なベスト プラクティス」のセクションに示したリソースを参照してください。

· 列ストア インデックスを使わないクエリ プランでパフォーマンスが低くなる SQL 結合操作に共通する結合キーを、その結合操作に関与する 1 つのテーブルから試験的に省略する。1 つのテーブルの列ストア インデックスから結合キーを省略すると、その省略された列で結合操作を実行するクエリに、その列ストア インデックスが使用されなくなる場合があります。この手法は、クエリ レベル オプションを適用できない環境で活用できます。ただし、列ストア インデックスから列を省略しても、クエリ プランが改善されるとは限りません。列ストア インデックスによってパフォーマンスが向上している他のクエリに影響を及ぼす可能性もあります。この手法を使用する場合、小さいテーブルの列を選択することで、他のクエリへのパフォーマンスの影響を抑えることができます。列ストア インデックスには、宣言された (DDL の) 主キーを含める必要があるため、使用できる結合列が制限される場合があります。列ストア インデックスの定義から主キー列を省略した場合でも、列ストア インデックスには、その作成時にすべての主キー列が自動的に追加されます。

現行リリースでは、標準的なデータ モデルは列ストア インデックスに完全には最適化されていませんが、FTDW のベンチマークは、正規化されたモデルである修正版の TPC-H に基づいています。列ストア インデックスと非列ストア インデックスの両方のクエリ プランが混在した同時実行ワークロードでも、大幅なパフォーマンス ゲインが測定されています。たとえば、FTDW の定格スループットが、全体的なワークロード パフォーマンスの 2 倍近くに達するケースもありました。

ディメンショナル データ モデルに対する列ストア インデックスの作成

ディメンショナル モデル (スター スキーマなど) では、列ストア インデックスの標準的なベスト プラクティスに従ってください。これは、列ストア インデックス処理のベスト ケースのシナリオと考えることができます。

列ストア インデックスのメモリ管理

SQL Server 2012 向けに検証された FTRA のほとんどは、SQL Server 2008 R2 向けの同様の構成と比べて合計システム RAM が多くなります。その主な理由は、列ストア インデックスが適用されるワークロードは、メモリ プールが大きいほど効率よく実行できるためです。列ストア インデックスの利用を計画している FTDW 環境では、必ずリソース ガバナーを使用して、セッションごとの最大メモリ量を設定する必要があります。検証済みの FTRA では、FT の定格パフォーマンスを得るために使用されたリソース ガバナー設定が記録されています。その値は、顧客のワークロードの基礎となる数値と言えます。システムのインストール後に、その設定を評価し、顧客のワークロードに合わせて具体的に調整することをお勧めします。

次の SQL コマンドでは、以上の推奨事項に従って、SQL Server のリソース ガバナーを構成します。このケースでは、セッションあたりの最大メモリ量を 19% に設定しています。

ALTER RESOURCE GOVERNOR RECONFIGURE;

ALTER WORKLOAD GROUP [default] WITH(request_max_memory_grant_percent=19);

xVelocity メモリ最適化�