IBM Red Brick Data Warehouse の 格納域レイアウトおよび I/O 性能チューニング
by user
Comments
Transcript
IBM Red Brick Data Warehouse の 格納域レイアウトおよび I/O 性能チューニング
IBMR Red BrickR Data Warehouse の 格納域レイアウトおよび I/O 性能チューニング Matthias Nicola IBM Silicon Valley Lab [email protected] 要約 Red Brick の性能は論理データベース設計に依存しますが、ディスク・サブシステムにおけるデータ・ファイルの配置 と割り当ても、もう 1 つの重要な性能要因です。物理的なデータベース・レイアウトの構成および設計には多数の選 択肢があります。本論文では、格納域ベンダおよびデータベース・ベンダによって広められた最善慣行についてレビ ューし、Red Brick の各種の格納域レイアウトを比較するための尺度を示します。これは最終的に、IBM Red Brick Data Warehouse に関する具体的な I/O 構成およびチューニング・ガイドラインとなります。 本論文は、読者が Red Brick Data Warehouse に関する基礎知識を持っていることを前提としています。 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 通告および商標 本文書を提供することは、IBM のいかなる特許に対するライセンス供与も意味するものではありません。 本文書内で IBM の製品、プログラム、またはサービスに言及していても、IBM が営業しているすべての国でそれら を供給する意図を示すものではありません。 本出版物に掲載されている情報にはいかなる製品保証も含まれておらず、本文書で行われている陳述を製品保証と して解釈することはできません。 次の用語は、米国または他国、あるいはその両方における International Business Machines Corporation の商標ま たは登録商標です。 AIX Enterprise Storage Server DB2 DB2 Universal Database IBM Informix Red Brick その他の製品名またはサービス名は、各社の商標または登録商標の場合があります。 c Copyright International Business Machines Corporation 2002. All rights reserved. Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 目次 1 はじめに 1 2 ベンダの主張 2 2.1 格納域レイアウトに関するベンダの推奨事項 2 2.2 ストライプ・ユニット・サイズに関するベンダの推奨事項 4 2.3 研究成果 ‐ ストライプ・ユニット・サイズ 4 3 格納域レイアウトによる性能の比較 5 3.1 データ・ウェアハウスのスキーマ 5 3.2 格納域レイアウトの選択肢 5 1. Manual 22 5 2. Manual 14/8 6 3. Stripe 12/4/4/2 （64 KB） 6 4. Stripe 8/8/4/2 （64 KB） 6 5. Stripe 22 （64 KB） 7 6. Stripe 22 （8 KB） 7 7. Stripe 22 （1 MB） 7 3.3 作業負荷 4 測定結果 9 9 4.1 ファクト・テーブルのロード 10 4.2 シングル・ユーザでのクエリ作業負荷 10 4.3 マルチユーザでのクエリ作業負荷 13 5 結論およびチューニングに関する推奨事項 5.1 I/O のチューニングに関する推奨事項 5.2 フォールト・トレランスに関する注意点 参考文献 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 15 .15 17 18 1 はじめに IBMR Red Brick データ・ウェアハウスの性能設計は、格納域レイアウトと I/O チューニングから始まるものではあり ません。優れた格納域レイアウトと精密な I/O 性能チューニングを行っても、不十分なスキーマ設計またはインデッ クス設計に起因する性能の低下を補うことはできません。論理設計の後に、容量計画を検討して、必要な CPU 数 およびディスク数を見積ることも必要です。本論文では、論理設計および容量計画のいずれも取り上げません。 しかし、物理的なデータベース設計とその格納域構成を最適化しなければならないときがいつかやってきます。Red Brick は一般に大量のデータに対する複雑な分析クエリを処理するために使用されるので、多くの場合効率的な I/O が重要な性能要因となります。すべてのテーブルおよびインデックスを一連のデータベース・ファイル (物理格納 ユニット、または PSU と呼ばれる) に関連付ける必要があり、それらのファイルがディスク・サブシステム内に割り当 てられます。次の目標を達成できるようなデータ配置が理想的です： ●I/O スループットを最大化し、I/O 待ち状態を最小化する。 ●個別のディスク上での I/O 競合を最小化する。 ●並列 I/O をサポートする。 ●並列 STARjoin や並列テーブル・スキャンなどの並列クエリ処理をサポートする。 ●許容できる利用効率およびディスク障害からの復旧性能を提供する。 これらの目標を達成するデータベース割当てを設計することは、簡単な仕事ではありません。データベース・ファイル をディスクに割り当てる際には、一般に次のような疑問が生じます：「どのテーブルまたはインデックスが同じディスク を共有すべきか、あるいは共有すべきでないか。利用可能なディスクのうち、何台をこのテーブルまたはインデックス に使用すべきか」 たとえば、ファクト・テーブルと STARindex を別のディスク・セットに配置して、STARindex アクセスとファクト・テーブ ル・アクセスの I/O 競合を回避するのはよいことだと論じることができます。利用可能なディスクが 10 台あるとす れば、たとえば 5 台のディスクをファクト・テーブルに、残りの 5 台をインデックスに使用できます。この構成では I/O 競合を回避できますが、ファクト・テーブル・アクセスまたは STARindex アクセスの I/O 並列度も 5 に制限さ れます。 あるいは、ほとんどの I/O アクセスはランダムになる (STARjoin 時の STARindex およびファクト・テーブルへのア クセスは非順次であるため) という議論もあり得ます。したがって、同じディスク・セット上でテーブルおよびインデック スへのランダム・アクセスを混合してもそれほど差異は出ず、マルチユーザの作業負荷ではその差異が一層小さくな ります。その結果、ファクト・テーブルと STARindex がどちらも 10 台のディスクすべてに分散し、両者の I/O 並列 度が最大限に高まります。 では、どうすればよいでしょうか。経験豊かなデータベース専門家の中には、上記 二つの手法のどちらにも提唱者 がいます。また、このほかにも、次のような選択を行う必要があります： ●ディスクのストライピングまたは手動データ・ファイル配置のどちらを採用した方がよいのか。 ●どのストライプ・ユニット・サイズを使用するか。 ●一時スピル領域をどこにどのように割り当てるか。 上記やその他の疑問に対する最善の解決策は、実際には作業負荷によって決まります。しかし、負荷の分析には長 い時間がかかる場合があり、作業負荷は時とともに変化する可能性があります。クエリの作業負荷を理解していても、 クエリの作業負荷を I/O 作業負荷に (つまり、テーブルおよびインデックスに対する物理的 I/O シーケンスに) 置 き換えることは非常に困難であり、しかもキャッシュの効果などの動的な要因に依存します1。したがって、作業負荷 分析に基づくデータ割当ては理論的には興味深いものの、現実にはほとんどの場合不可能です [Ganger et al. 93]。 1 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 要するに、これら二つの簡単な選択肢のどちらが、より優れた I/O 性能をもたらすかを予想するのは困難な可能性 があります。本論文の目的は、Red Brick におけるデータ割当ての問題に対する実用的な解決策について論じ、そ れらの解決策を特定することです。ここでは、ストライプ化ボリューム (存在する場合!) のレイアウト方法および構成 方法と、ディスクまたは論理ボリュームへの Red Brick データベース・ファイルの割当て方法に重点を置きます。 前提： ●Veritas Volume Manager や AIXR Volume Manager などの格納域マネージャを使って任意のストライプ化ボ リュームを作成できる、ディスクのファームがあると仮定します。 ●また、それらのディスクへのアクセス・パスが最適に構成されており、チューニングを要するボトルネックは存在 しないと仮定します。したがって、ディスク・サブシステムを接続するディスク・コントローラ、ファイバ・チャネル等 の構成には焦点を当てません。 本論文の内容： ● 格納域およびデータベースのベンダ各社によって行われている、割当てに関する推奨事項をレビューします。 ●これを基に、一般的な Red Brick データ・ウェアハウスについて、格納域レイアウトの選択肢をいくつか提案 します。 ●シングルユーザおよびマルチユーザの広範なクエリ性能テストを実施して、格納域レイアウトの各選択肢の利 点と欠点を比較します。 ●性能測定の結果について説明します。 ●IBM Red Brick Data Warehouse に関する具体的な I/O 構成およびチューニング・ガイドラインを提示します。 2 ベンダの主張 IBM、Oracle、InformixR、Sun、Compaq、EMC、Veritas などのハードウェア・ベンダおよびソフトウェア・ベンダは、さま ざまなホワイト・ペーパーやチューニングに関する推奨事項を出しています。その中には、互いに矛盾していて、採用 に当たり注意を要するものもあります。ディスクのストライピング、RAID 技法、およびそれらの応用方法に関する優 れた調査については、 [Chen et al. 94] を参照してください。 2.1 格納域レイアウトに関するベンダの推奨事項 データベース格納域のレイアウトに関する推奨事項は非常に多様な形で提供されており、ベンダのハードウェア製品 またはソフトウェア製品を適格とする詳細な記述をともなうこともよくあります。簡素化するため、格納域レイアウトの ガイドラインを次の二つのカテゴリのどちらかに分類します： ●すべてのデータベース・オブジェクトをすべてのディスクに分散する。 ●共通要素がない (オーバーラップしない) ディスク・セットを使ってデータベース・オブジェクトを分離する。 ここでいうデータベース・オブジェクトとは、テーブル、インデックス、一時領域、ログ、カタログ／システム・テーブル、具体化されたビューなどのこと です。 1 データ・キャッシュが Red Brick の性能に大きな影響を与えることは明らかであり、Red Brick エンジンとディスク・プラッタの間には、データベー ス・ブロック・キャッシュ、OS ファイル・キャッシュ、コントローラ・キャッシュ、そして多くの場合 1 トラック用のオンディスク・キャッシュなど、複数の キャッシュ・レベルが存在します。キャッシュ階層の下層に行くほど、DBA またはシステム管理者がキャッシュのヒット率を特定すること、あるいは システム全体の性能に対するキャッシュの影響を定量化することが困難になります。キャッシュ階層の合計ヒット率が高いほど、ディスク上でのデ ータの組織方法による影響が小さくなることは明白です。したがって、キャッシュが非常に大きく I/O 負荷が比較的小さい場合、格納域レイアウト によって生じる差異が小さくなります。 2 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse “あらゆるもの” をすべてのディスクに分散 基本的な考え方は、すべてのデータベース・オブジェクトを利用可能な格納域サブシステム上にできるだけ均等に分 散して I/O 並列度を最大限に高め、異なるデータベース・オブジェクトが同時にアクセスされる心配をなくすというも のです。 たとえば IBM は、Shark とも呼ばれる IBM Enterprise Storage System (ESS)R 上の DB2R Universal Database™ に ついて、格納域レイアウトの各選択肢を比較する一連の性能実験を行いました [IBM 01]。すべての DB2 データを 可能な限り多数の RAID 配列に分散するのが望ましいという主な結果になりました。テーブル、インデックス、および 一時領域を ESS のディスク・アレイ間で混合して、それらが孤立している場合に発生する非対称または不均衡な I/O 負荷を回避することが提案されています。[IBM 01] には、テーブルをインデックス格納域から分離すると、最適 な性能をもたらすことができないことを示す、具体的なテストが記載されています。 もう一つの例は [Loaiza 00] です。Loaiza は SAME (Stripe And Mirror Everything) という用語を作り出しました。こ れは、1MB のチャンクを使って、すべての利用可能ディスクにわたってすべてのデータベース・オブジェクトをストライ プ化するとともに、信頼性を確保するためミラーリングを行うという意味です。Loaiza は、現在のデータベース・システ ムの作業負荷は複雑すぎ、平行度がそれぞれ大きく異なるため、作業負荷の特性に基づいて格納域の構成を設計 することは不可能であると論じています。SAME は作業負荷に依存せず、I/O 負荷をすべてのディスクに均等に分 散することを意図するものです。 データベースの作業負荷は任意のデータベース・サブセット (テーブル、インデックス、またはテーブルのパーティショ ン) に I/O 動作を集中させる可能性があるので、そのようなディスク・サブセットをできるだけ多数のディスクに均等 に分散する (“極限のストライピング”) 必要があります。ディスク数は少なくとも CPU 数の 8∼10 倍にします。 SAME は、たとえ復旧ログを別個のディスクに配置するためであっても、インデックスをテーブル I/O から分離しよう としないこと、および順次アクセスをランダム・アクセスから分離しようとしないことを推奨しています。その基本原理は、 インデックス・アクセスとテーブル・アクセスの間、およびログ書込みとテーブル間の I/O干渉は、極限のストライピン グが提供する高帯域幅およびキューイングの削減によって補うことができ、かつより多くの効果が期待できるというも のです。[Loaiza 00] は、実際にはストライピングするディスクの数が少なすぎることが、どの I/O 干渉よりも大きな 問題であり、マルチユーザの作業負荷における I/O 要求はいずれにせよ互いに干渉すると論じています。最後に Loaiza は、SAME によって格納域管理者のオーバーヘッドが大幅に削減されると論じており、これは [Larson 00] でも特筆されています。 その他のベンダはおおむね、上記のガイドラインに同意しています [Larson 00]、[EMC 00]。データ・ファイルは手動 でディスク間に均等に分散できますが、これには非常に長い時間がかかる上、データ・ファイル分布の偏りによって性 能が低下する危険が生じます [Ganger et al. 93]。その代わりに、利用可能なすべてのディスクにわたってデータ、イ ンデックス、および一時領域をストライプ化することがユーザに対して推奨されています。IBM の ESS や EMC の Symmetrix などの高度な格納域サブシステムでは、本論文の対象範囲外である追加チューニングの検討が必要な 場合があります。 共通要素がないディスク・セットによるデータベース・オブジェクトの分離 一般的な推奨事項の 1 つは、性能のためだけでなくフォールト・トレランスのためにも、復旧ログをテーブルおよびイ ンデックスとは別のディスクに配置することです。テーブルをインデックスから分離すること、およびテーブルが頻繁に 結合される場合はテーブルを互いに分離することを提案する “分離” ルールもあります。そのほかに、順次アクセ ス・データをランダム・アクセス・データから分離するというガイドラインも見られます [Compaq 98]、[Whalen, Schoeb 99]。たとえば、[Holdsworth 96] は複数の同時並列スキャンの対象となるテーブルに専用のディスク・セットを与える よう助言しています。これは復旧ログについては有益かもしれませんが、テーブルについてはおそらく困難でしょう。 つまり [Larson 00] は、同じテーブルに対してインデックス付きルックアップと同時に実行されるテーブル・スキャンに、 順次 I/O の利点が活かされる可能性は少ないと論じています。また、Red Brick や DB2 などのほとんどのデータ ベースは、いずれにせよ大規模なテーブルの完全スキャンを回避しようと試みます。 3 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse IBM Red Brick Data Warehouse については、[Fung 98] はデータベース・オブジェクトの分離を提唱し、ボリュームの ストライプ構成に関して具体的な推奨を行っています。 ●共通要素がないディスク・セット上にあるストライプ化されたボリュームをいくつか使用して、ファクト・テーブル・デ ータ、ファクト・テーブル・インデックス、ディメンジョン・テーブル、ディメンジョン・テーブル・ インデックス、およびスピル領域を分離します。 ●1 台の物理ディスクに 一つのテーブルまたはインデックスのデータだけを格納するのが理想的です。これは ファクト・テーブルとそのインデックスに関して推奨されますが、小規模なディメンジョン・テーブルについてはそれ ほど重要ではありません。 ●すべてのディスクにわたって 一つの大きなストライプ化されたボリュームにしないようにします。 ●小さなストライプ・ユニット・サイズ・(8 KB または 16 KB) を使用します。チャンク・サイズがそれより大きいと性 能に悪影響が出ます。 ●各論理ボリュームを複数のコントローラにまたがらせます。 このカテゴリでの推奨事項は、各テーブル間の、テーブル・アクセスとインデックス・アクセスの競合を回避することが、 すべてのデータベース・ファイルに対する物理 I/O の並列度を一様に最大化することより重要であるという前提に基 づいています。これは特殊なケースで有効である可能性がありますが、本論文で後に説明する測定結果では、一般 にこれが正しくないことが示されています。 2.2 ストライプ・ユニット・サイズに関するベンダの推奨事項 [Holdsworth 96] は、ストライプ・ユニット・サイズが激しい論争の対象になっていることを特筆しています。Holdsworth は、ストライプ・サイズをデータベース・システムのブロック・サイズに設定すると (Oracle) 性能が低下することが示さ れたため、そのように設定すべきではないと論じています。Holdsworth は、1MB など、データベース・ブロック・サイ ズを大きく上回るストライプ・サイズを推奨しており、非常に大規模なシステムではストライプ・サイズを 5MB にすべ きだとしています。[Veritas 01] は、ストライプ・サイズを OS (または論理ボリューム) のブロック・サイズの倍数にす るように提唱しています。Veritas はほとんどの OLTP データベースについて、64KB というデフォルト・ストライプ・ユ ニット・サイズを推奨し、Decision Support Systems (DSS) の場合はそれより大きなストライプ・サイズ、128KB や 256KB の方が性能が向上する可能性があるとしています。[Loaiza 00] は、ストライプ・サイズを1MB にすることでシ ーク時間に対する転送時間の比率が適正になるため、このサイズがあらゆる種類の作業負荷に適していると論じて います。Loaiza は、シーク時間が短縮されるよりも速くディスクの転送速度が高まるのにともない、将来にはこの値 が増加すると述べています。Red Brick については、[Fung 98] が 8 KB のストライプ・ユニット・サイズを推奨してい ます。 2.3 研究成果 ‐ ストライプ・ユニット・サイズ [Scheuermann et al. 98] は、既存の研究を統合し、確認している比較的最近の研究です。その性能モデルはオープ ン・キューイング・ネットワークに基づいており、これは現在のデータベース・アプリケーション (多数のユーザ、多様な 平行度) に関して適切と思われます。結果は、ストライプ・ユニット・サイズを小さくすると、軽い負荷については優れ た応答時間が得られますが、スループットが著しく制限される可能性があることを示しています。その結果、ストライ プ・ユニットが小さい場合、負荷が重いと応答時間が劇的に長くなります。この場合、ストライプ・ユニット・サイズをよ り大きくすると、ディスク上のファイルの一部がクラスタ化される傾向があります。これによって個別の I/O 要求の性 能が改善されるかどうかは不明です (要求のサイズによる) が、要求が依然としてすべてのディスクに均等に分散し ていると、全体としての I/O スループットが向上することが示されています。たとえば 64KB や 1MB などの大きな ストライプ・ユニット・サイズは、データベースの合計サイズに比べれば非常に小さいので、そのような均一性を前提 にすることは妥当と思われます。したがって理論上の結果は、ストライプ・ユニット・サイズが大きい方が、中程度から 重い作業負荷では性能が改善されることを示しています。データベース・システムでは、マルチユーザ・アクティビティ またはクエリ間の並列度、あるいはその両方によってそのような負荷が発生する可能性があります。 4 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 3 格納域レイアウトによる性能の比較 ここまで読まれたのなら、データ・ウェアハウスの格納域レイアウトについて、次のようにさまざまな推奨が行われて いることがわかります。 ●手動データ・ファイル配置 vs. ディスクのストライピング ●共通要素がないディスク・セット上でインデックスとテーブルを分離 vs. “極限のストライピング” ●ストライプ・ユニットについて、8KB∼1MB のいずれか、あるいはそれより大きいサイズの選択 以上のことから、Red Brick Data Warehouse 6.11 でいくつかの性能実験を行い、それらの推奨事項をテストすること で、実用的な推奨事項を提示できるかどうか調べることにしました。 3.1 データ・ウェアハウスのスキーマ この性能テストでのデータベース・スキーマは、一つの大きなファクト・テーブル (daily_sale) と 五つのディメンジョン・ テーブルのある一般的なスター・スキーマです。ディメンジョン・テーブルとその多重度は、period (2522)、store (63)、 product (19450)、promotion (35)、および customer (1,000,000) です。period テーブルの各エントリは 1 暦日に対応 しますが、ファクト・テーブルでは 638 日しか参照されません。ファクト・テーブルには約 2 億 9500 万行が格納さ れています。完全にロードした場合、データベースの合計サイズは約 50GB です。これは現実世界の多くのデータ・ ウェアハウスに比べれば小規模ですが、各種の格納域レイアウトが性能に及ぼす影響を感知し、分析するには十分 な規模であると考えました。 ファクト・テーブルは、二つの STARindex によってインデックス付けされています。一方のインデックスには 4 つ、も う一方のインデックスには 5 つのディメンジョン外部キーが入っています。各ディメンジョン・テーブルには主キー・イ ンデックスがあり、一般に 1 つまたは複数の副インデックスがあります。ファクト・テーブルと二つの STARindex は、 period 外部キーの値によって範囲パーティション分割 (“セグメント化”) されています。一つのセグメントには 1 週 間分のデータが入っています。つまり、一つのセグメントが 7 つの period キーにまたがっています。したがって、フ ァクト・テーブルと両方の STARindex がそれぞれ 91 のセグメントで構成されています。ファクト・テーブルと STARindex の各セグメントが 22 のデータ・ファイル (PSU) に格納されています。 3.2 格納域レイアウトの選択肢 このデータ・ウェアハウスについて設計した格納域レイアウトの選択肢では、データベースの四つの主要部分が重視 されています： ● ファクト・テーブル ● ファクト・テーブル・インデックス ● ディメンジョン・テーブルとインデックス ● スピル領域 (ソート、インデックス構築などのための一時領域) 使用する格納域サブシステムは 22 のディスクで構成されています。データベース・オブジェクトをディスク上に割り 当てて分散する方法を、次のように 7 通り定義しました (図については図 1を参照のこと)。 1. Manual 22 このレイアウトでは、ストライピングを一切使用せず、PSU を手動で 22 台のディスクに配置します。それぞれ 22 の PSU に格納されているファクト・テーブルおよび STARindex のセグメントについては、各セグメントがすべてのデ ィスクに分散することになります。この基本原理は、一つのセグメントだけにアクセスするクエリでも、ディスク・サブシ ステムの最大限の I/O 並列度を享受できるというものです。 一つの選択肢は、単に各ファクト・テーブル・セグメントおよびインデックス・セグメントの PSU 1∼22 を、各データ・セ グメントおよびインデックス・セグメントの PSU i がディスク i に格納されるように、ディスク 1∼22 に割り当てること です。しかし、現実世界のインストールでは、DBA やコンサルタントは “1-off” 戦略を好むようです。これは、最初に データ・セグメント 1 の PSU 1 を ディスク 2 に、対応する STARindex セグメントの PSU 1 をディスク 1 に割り 5 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 当て、その後も各ディスクを順にペアにして、最後には一回りしてディスク 1 に戻る、という戦略です。これは、ファク ト・テーブル・セグメントとそれに対応するインデックス・セグメントの間の “1-off” ロジックです。 また、ファクト・テーブル・セグメントの間にも “1-off” ロジックを適用できます。つまり、データ・セグメント 1 の PSU をディスク 2、3、4 等に配置した場合、データ・セグメント 2 の PSU をディスク 3、4、5 に配置し、以下同様に続け るというものです。“1-off” ロジックの目的は、インデックス・アクセスとテーブル・アクセスの間、および複数のファク ト・テーブル・セグメントへのアクセス間の I/O 競合を削減することです。 ここでは Manual 22 に “1-off” 戦略を採用します。しかし、より単純な手動によるファイル分散に対する “1-off” ロ ジックの優位性を検証または定量化するための測定は特に行いませんでした。 さらに、22 台のディスクすべてにスピル領域ディレクトリを作成します。小規模なディメンジョン・テーブルを 22 にパ ーティション分割しても意味がないので、各ディメンジョン・テーブルと各ディメンジョン・インデックスを単に別の 1 台 のディスクに配置します。いずれにせよ、それらはおそらく完全にキャッシュされるでしょう。一つの例外は customer テーブルとその主キー・インデックスであり、それらは 10 の PSU と 10 台の異なるディスクに格納します。 2. Manual 14/8 Manual 14/8 では、共通要素がないディスク・セット上でファクト・テーブル・データをファクト・テーブル・インデックスか ら分離します。上記と同様の “1-off” 戦略を使って、ファクト・テーブルのセグメント/PSU をディスク 1∼14 に手動 で分散し、STARindex のセグメント/PSU を残りの 8 台のディスク、つまりディスク 15∼22 に分散します。簡素化 のため (そしてあまり影響がないと思われたため)、スピル領域とディメンジョンは Manual 22 と同様に割り当てます。 ファクト・テーブルに 14 台のディスクを使用し、STARindex にはディスクを 8 台しか使用しないという決定は、 STARindex がテーブルよりも小さいという事実に基づく、単なる直観的な決定です。 3. Stripe 12/4/4/2 (64KB) このレイアウトは [Fung 98] の推奨事項に従っています。つまり、共通要素がないディスク・セット上の異なるストライ プ化したボリューム内に、ファクト・テーブル、STARindex、スピル領域、およびディメンジョンを分離します。ストライプ 化ボリュームのディスク数は、ここでもオブジェクトの相対的サイズに基づいて決定します。ファクト・テーブルは 12 台のディスク、STARindex とスピル領域はそれぞれ 4 台のディスク、ディメンジョンは 2 台のディスクにわたってス トライプ化されます。ストライプ・ユニット・サイズは中程度の 64KB を選択します。これは、使用した Veritas Volume Manager で推奨されるデフォルト値です。 ファクト・テーブル 12 ディスク (ディスク 1∼12) STARindex 4 ディスク (ディスク 13∼16) ディメンジョン・テーブルおよびシステム・テーブル 2 ディスク (ディスク 17 および 18) スピル領域 4 ディスク (ディスク 19∼22) 4. Stripe 8/8/4/2 (64KB) 12/4/4/2 レイアウトを再考すると、STARjoin の性能に対して STARindex I/O がファクト・テーブル I/O と同程度 に重要であるという議論があり得ます。したがって、8/8/4/2 の格納域レイアウトは 12/4/4/2 レイアウトによく似て いますが、ファクト・テーブルの方が STARindex より大きいにもかかわらず、STARindex とファクト・テーブルに同数 のディスク (各 8 ディスク) を割り当てる点が例外です。 ファクト・テーブル 8 ディスク (ディスク 1∼8) STARindex 8 ディスク (ディスク 9∼16) ディメンジョン・テーブルおよびシステム・テーブル 2 ディスク (ディスク 17 および 18) スピル領域 4 ディスク (ディスク 19∼22) 6 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 5. Stripe 22 (64KB) この格納域レイアウトは、[Larson 00] および [Loaiza 00] で提唱されている “SAME” または “極限のストライプピ ング” の概念に従っています。ここでは、22 台のディスクすべてにまたがる一つの大規模なストライプ化ボリューム だけを使用します。すべての PSU がこのボリュームに格納されます。ここでも、Veritas のデフォルト・ストライプ・ユ ニット・サイズ、64KB を使用します。 6. Stripe 22 (8KB) 測定の結果、極限のストライピングはほかのどの格納域レイアウトよりも性能に優れ、管理者のオーバーヘッドが小 さいことが示されたため、このレイアウトを貫いてストライプ・ユニット・サイズの影響を調べることにしました。[Fung 98] の推奨に従い、8 KB のチャンク・サイズを試用しました。 7. Stripe 22 (1MB) これは 5 および 6 と同じですが、[Holdsworth 96]、[Loaiza 00] の推奨に従って 1MB のストライプ・ユニット・サイ ズを使用しました。 7 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 格納域レイアウトの 7 つの選択肢の図 図 1： 格納域レイアウトの選択肢 8 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 3.3 作業負荷 前述した格納レイアウトの選択肢すべてについて、5 種類の作業負荷性能を測定しました。この作業負荷は次のと おりです： 作業負荷 1： ファクト・テーブルのロード この作業負荷では、空のファクト・テーブルに約 2 億 9500 万行がロードされます。このプロセスには、二つのイン デックスの構築と、事前ロードされたディメンジョン・テーブルに対する完全な参照整合性チェックが含まれます。イン デックスの構築ではディスク上のスピル領域が多用されます。 作業負荷 2： シングル・ユーザ、厳密に制約された STARjoin このクエリ・セットは、いくつかのディメンジョンまたはすべてのディメンジョンで制約された STARjoin クエリで構成さ れています。これらのクエリはすべてどちらかの STARindex を使用します。最終的にファクト・テーブルから選択され る行のパーセンテージは非常に低く、1% 未満のこともよくあります。クエリはシングル・ユーザ・モードで、つまり一度 に一つずつ実行されます。 作業負荷 3： シングル・ユーザ、混合クエリ・セット これは、厳密に制約された STARjoin と、中程度および軽度に制約された STARjoin の両方が含まれる、クエリの 拡張セットです。こちらの方がシステムにかかる I/O 負荷が大きくなります。また、最初にファクト・テーブルをスキャ ンした後、ディメンジョン・テーブルを一つずつ調べることで、ファクト・テーブルとディメンジョン・テーブルの結合を評 価することを強制されるクエリがあります。追加制約あり、または追加制約なしでファクト・テーブルの一部を単にスキ ャンするクエリもいくつかあります。このセットに含まれるクエリの中には、ディスクのスピル領域を使用する大規模な ソートおよび集約を実行するものもあります。 作業負荷 4： マルチユーザ、厳密に制約された STARjoin これは作業負荷 2 と同じですが、クエリ・セットが多数の同時実行ユーザによってバッチ実行されます。このテストを、 10 人、25 人、および 50 人の同時実行ユーザで実行しました。シミュレートされた各ユーザがクエリのバッチを複数 回実行し、クエリの実行順序はユーザごとに異なります。 作業負荷 5： マルチユーザ、混合クエリ・セット これは作業負荷 2 と同じですが、クエリ・セットが多数の同時実行ユーザによってバッチで実行されます。このテスト を、10 人 および 20 人の同時実行ユーザで実行しました。シミュレートされた各ユーザがクエリのバッチを複数回 実行し、クエリの実行順序はユーザごとに異なります。 4 測定結果 格納域レイアウトの各選択肢について、結果の再現性と一貫性を確保するために各作業負荷を複数回実行して測定 しました。格納域レイアウトの選択肢による性能への影響を分離し、性能に関するその他の問題によって結果が歪め られることを防止するため、データベース・システムでは 5 つの作業負荷それぞれに対して高度なチューニングが行 われました。また、ある程度までは、データベース構成パラメータの各種セットについても実験を繰り返しました。たと えば、1 クエリ当たりの並列度や、Red Brick によって使用されるメイン・メモリの量などを変更しました。さらに、ファ クト・テーブルのソート済みデータと未ソート・データ、および事前割当てデータ・ファイルとロード・プロセスで展開され るデータ・ファイルを対照させての実験も行いました。これらの変更によって、下に示す結果および結論が堅固なもの であり、それらの構成変更によってそれほど影響を受けないことが確認されました。 測定は、16 個の CPU と 16GB のメイン・メモリを搭載し、Solaris 5.8 (64 ビット) を実行する SunE6500 サーバ上 で行いました。ディスク・サブシステムについては、Veritas Volume Manager によって管理される 22 台のディスクを 備えた Sun A5200 を使用しました。並列度およびクエリ・メモリ制限を下げ、コールド OS ファイル・システム・キャッ シュを使用した特定のテストでは、定量的な結果および結論がハードウェアの容量によって歪められない (あるいは 過度に影響を受けない) ことが確認されました。 9 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 4.1 ファクト・テーブルのロード ロード・テストでは、格納域レイアウトの 7 つの選択肢の性能はほぼ同等でした。図 2 に、ロードの相対経過時間 を最短ロードに対するパーセンテージで示します。最高のロード性能は Stripe 8/8/4/2 レイアウトで測定され、残り のレイアウトではそれより 4% から 12% 長い時間がかかりました。10% というのは取るに足りない差ではありません が、これはテスト間の変動の範囲内であると判断しました。Red Brick ローダでのチューニングの経験から、格納域レ イアウトの詳細が性能にわずかながら影響を及ぼすことが確認されます。その理由は、十分な並列度のあるどのよう な I/O レイアウトでも、ロード手順は一般に CPU にバインドされるからです。主な要件は、I/O 動作を十分な数の ディスクに分散して、ローダを CPU にバインドし続ける必要があるということです。これは、ここでの 7 つの格納域 レイアウトすべてに当てはまります。結論は、ローダ・テストではどの格納域レイアウトにも他のレイアウトに対する優 位性が認められないということです。 図 2： 各種格納域レイアウトのロード性能 4.2 シングル・ユーザでのクエリ作業負荷 格納域レイアウトの各選択肢について、厳密に制約されたすべての STARjoin を順次実行した場合の合計時間を図 3 に示します。Red Brick に対して最適化された STARjoin 技法により、厳密に制約されたスター・クエリでは、非常 に大規模なデータベースでも、応答時間を数秒 (またはそれ以下) にすることができます。したがって、格納域レイア ウトのすべての選択肢で、この作業負荷の完了までにかかった時間は 1 分未満でした。実行時間を非常に短く変 更してこのテストを繰り返し、実験の実行時間が短いにもかかわらず、相対的な性能の差は統計的に有意であること を確認しました。テスト中にシステムの動作と使用率を監視し、この作業負荷によってシステムにかかる I/O 負荷は 軽いものの、格納域レイアウトが性能に影響を及ぼす程度には重大であることが判明しました (作業負荷がCPU に 高度にバインドされている場合は、格納域レイアウトによる影響が生じない可能性があることに注意してください)。 10 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 図 3 は、小さなストライプ・ユニット・サイズを採用した “極限のストライピング” (Stripe 22(8KB)) が最高の性能を示 し、手動のデータ・ファイル割当て戦略がこれに迫っていることを示しています。I/O 負荷が軽く並行度が低いため、 大きなストライプ・ユニット・サイズに対する小さなストライプ・ユニット・サイズの性能の優位性は研究結果と一致して います (たとえば [Scheuermann et al. 98] を参照のこと)。この作業負荷では、インデックスとテーブルを分離しても 重大な差異は発生しない、つまり 中程度のストライプ・ユニット・サイズ (64KB) を使用する Stripe 8/8/42、 Stripe12/4/4/2、および Stripe 22 がすべてほぼ同等の性能を示すことがわかります。この作業負荷では I/O 集約 度が低すぎるため、極限のストライピングによる I/O 帯域幅の増加に対して、インデックス・アクセスとテーブル・アク セスの間の競合削減は重要ではありません。しかしこれは、混合作業負荷および I/O 集約型の作業負荷について は異なります (下の図 4 の説明を参照のこと)。 図 3 で「22 skew」というラベルの付いている結果は、Manual 22 の最初のテスト・シリーズで取得されたものです。デ ータ・ファイルを 22 台のディスクに均等に分散する際には、“1-off” ロジックを実装することと、すべてのデータ・ファ イルのサイズを同程度にすることに特に注意を払いました。これには、単にすべてのものをすべてのディスクにわた ってストライピングするよりも何倍もスキルと時間が必要であることがわかりました。実際、PSU の maxsize パラメー タの推定をわずかに誤っただけで、22 台のディスクへのデータ分散が不均等になり、結果として性能が 35% も低下 しました! これは純然たる偶然によって起こったことですが、ストライピングは、I/O のバランスをとる上で、手動での データ配置よりもはるかに簡単かつ信頼性の高い方法であるという重要な教訓を与えてくれます ([Ganger et al. 93] 参照)。 図 3： 厳密に制約された STARjoin クエリの合計実行時間 すべての混合クエリを順次実行した場合の合計時間を図 4 に示します。これらのクエリは、前の作業負荷より CPU 集約型であり、I/O 集約型でもあります。したがって、この作業負荷の合計実行時間は最長 1 時間でした。結果は、 中程度から大きなストライプ・ユニット・サイズを使ってすべてのものをすべてのディスクにストライピングすると最高の 性能が得られ、管理のしやすさも最大化されることを明確に示しています。重複しないストライプ化ボリュームでファク ト・テーブルの I/O をインデックスの I/O から分離しても、極限のストライピングによって提供される並列度の上昇 の恩恵は相殺されないことがわかります。 11 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse しかし、12/4/4/2 レイアウトの性能が 8/8/4/2 レイアウトを上回ったのは興味深いことです。これは、ファクト・テー ブルの I/O が STARindex の I/O よりも重要であることと、ファクト・テーブル専用の I/O 並列度／帯域幅を多く した方が有利であることを示します。実際、テスト中に 8/8/4/2 レイアウトでの 1 ボリューム当たりの I/O 使用率 を監視すると、ファクト・テーブルのボリュームが STARjoin のボリュームよりも “ホット” であることが判明しました (I/O 待ち時間、キューの長さなどの点で “ホット” であるという意味です)。これは、インデックスをテーブルから分離 することで I/O のホットスポットが生じる可能性があるという [Holdsworth 96]、[Larson 00]、および [Loaiza 00] の 記述を確認するものです。 図 4： 混合クエリ・セットの合計実行時間 図 4 の結果は各種のクエリ (インデックスベースの STARjoin、テーブル・スキャン、スピル領域を使用するソートな ど) の混合に基づくため、この結果がどれか 1 種類のクエリの順次実行によって支配されているのではないかとい う疑問が生じる可能性があります。たとえば、図 4 の結果は、作業負荷の中にテーブル・スキャンが存在するために そうなっているだけではないでしょうか。答えは “ノー” です。厳密に制約された STARjoin (図 3) を除けば、この作 業負荷に含まれるどのタイプのクエリも、図 4 に示す相対的性能特性を (平均として) 持っています。確かに、例外 となる個別のクエリはあります。たとえば、“Stripe22 (1MB)” よりも “22 ,manual” の性能の方が優れているテーブ ル・スキャン・クエリがこの作業負荷の中に 1 つあり、それ以外のテーブル・スキャンでは“Stripe22 (1MB)” の性能 の方が優れています。しかし、ここでの目的はある特定のクエリの性能を最適化する格納域レイアウトを調べることで はなく、典型的な混合作業負荷全体の性能を最適化するレイアウトを調べることです。 これを述べると、ストライプ化ボリューム上のテーブル・スキャンが、Manual 22 のようなレイアウトで連続的に割り当 てられたデータ・ファイルの順次 I/O となぜ張り合えるのかと思われるかもしません。その鍵は、順次 I/O は中間 ディスク・シークを行わずにファイル全体を読み込むことと同等ではないということです。順次 I/O は、データ転送時 間に対するシーク時間のパーセンテージが十分小さいときに行われます。たとえば、各 10 MB のランダム読み込み を 10 回行う場合の効率は、100MB を 1 回スキャンする場合とほぼ同等です。同様に、ストライプ・ユニット・サイズ を大きくすることで (64KB、512 KB、1MB)、連続転送時間に対するシーク時間の比率を徐々に小さくすることができ、 順次 I/O に十分近づけることができます。 12 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 図 3 および図 4 に示した二つのシングル・ユーザ作業負荷の結果を比較する場合、目盛りが図 3 では秒単位、 図 4 では分単位であることに注意してください。どちらの場合も、極限のストライピング・レイアウト、Stripe 22 が最 高の性能を示しています。厳密に制約された STARjoin については 8KBの小さなストライプ・ユニット・サイズが有益 であり、混合作業負荷の場合は中程度から大きなストライプ・ユニット・サイズでの性能が大きく上回ります。しかし、 厳密に制約された STARjoin の性能はどちらの場合にも十分 (秒単位!) ですが、より I/O 集約型のクエリは、“正 しい” 格納域レイアウトにはるかに依存します。多くのデータ・ウェアハウスのインストールでは、クエリの完了までに 秒単位ではなく分単位の時間がかかることがよくあり、緩やかな制約、多くのテーブルにまたがる複合結合、および 非常に大きなデータ・ボリュームが存在する場合はそれが普通です。ほとんどの顧客は、長いクエリで何分も節約で きるのであれば、いずれにせよ非常に高速であるクエリに数秒余分にかかっても満足するでしょう。したがって、作業 負荷が厳密に制約された STARjoin を中心に構成されていることがわかっているのでない限り、最低 64KB という 中程度から大きなストライプ・ユニット・サイズを推奨します。 4.3 マルチユーザのクエリ作業負荷 実験の第 2 段階では、マルチユーザ形式で二つのクエリ作業負荷を実行しました。最大 50 人のシミュレートされ た同時実行ユーザで、厳密に制約されたクエリを実行し最大 20 人のユーザで混合クエリを実行しました。その絶対 的な結果はユーザ数に依存しますが、格納域レイアウト間の相対的な性能の差異は、ユーザ数を変えても同様でし た。したがって、一つの作業負荷につき一つの事例だけの結果を示します。 図 5： 50 人のユーザ全員が作業負荷を完了するまでの合計時間 図 5 は、格納域レイアウトの各選択肢について、50 人の同時実行ユーザが厳密に制約された一連の STARjoin を複数回実行した場合の合計経過時間を示しています。ほかのどれかの格納域レイアウトを大きく下回るか上回る 性能を示しているレイアウトはありません。興味深いことに、シングル・ユーザの場合は Stripe 22 (8KB) の性能の方 が優れていましたが、マルチユーザの場合にはそれに相当する性能の優位性は見られません。並行度が高くなった ことが、図 3 に見られる小さなストライプ・ユニット・サイズによる性能上の利点に優ったと思われます。しかし、全体 としての I/O 集約度は依然として低いので、極限のストライピングと、より大きなストライプ・ユニット・サイズによる性 能上の利点はそれほど重要ではありません。実際、この並行作業負荷によってディスクよりも CPU の方がはるかに 早く飽和することが観察されました。 13 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse マルチユーザ作業負荷の I/O 集約度 -- および性能動作 -- は、より緩やかに制約されたクエリが混合作業負荷 に追加されるにつれて、大きく変動します。図 6 は、混合クエリ・セットが全ユーザによって複数回実行されるマルチ ユーザ・テストの合計経過時間を示しています。システム上の I/O 負荷は中から高であり、クエリ間およびクエリ内 の並行度がかなり高くなっています。ここでは、既に図 4 に見られた定量的結果が増幅されています。高い I/O 転 送速度に対する要求に応じるには、非常に小さなユニット・サイズでは適していません。8KB のストライプでは、転送 時間に対するシーク時間の比率が高すぎるため、過剰なキューイングが発生します。その結果、全体的な性能が非 常に低くなります。64KB または 1MB のストライプ・ユニットを使用すると、この問題が大幅に緩和され、性能がはる かに向上します。これは、小さなストライプ・ユニットによってスループットが著しく制限されるため、負荷が重いときに はキューイングの遅延によって応答時間が悪化すると予想した研究結果と一致しています [Scheuermann et al. 98]。 図 6 では、インデックスをテーブルの I/O から分離すると、ディスクの使用率に不均衡が生じ、したがって使用率が 最適化されないという結果も確認され、増幅されています。ファクト・テーブルの I/O は STARindex の I/O よりも 頻繁に行われるので、ファクト・テーブル専用のディスクが多いほど性能が改善され、8/8、12/4、14/8、22 の順序と なります。データ・ファイルをすべてのディスクに巧みに手動で分散した場合は、Stripe 22 (1MB) または Stripe 22 (64KB) の性能には遠く及ばないものの、破滅的な性能というわけでもありません。これは、この戦略を採用している 既存のデータ・ウェアハウス・インストールにとっては朗報です。Manual 22 は、共通要素がないディスク・セットに各 種のデータベース・オブジェクトを分離せず、非常に小さなストライプ・ユニット・サイズを使用せず、利用可能なすべ てのディスクに I/O 負荷を分散する方法にやや似ているため、十分な性能を示します。しかし、管理の手間は膨大 であり、不注意によってデータ分布の偏りや I/O 負荷の不均衡を招く危険も大いにあり、それが性能を大きく低下さ せる可能性があります。管理のしやすさと性能の結果の両方により、手動データ・ファイル配置よりもストライピングが 推奨されます。 14 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 図 6： 混合クエリ負荷を実行する 50 ユーザ全員の合計時間 5 結論およびチューニングに関する推奨事項 以上の実験は、ストライピングによってすべての Red Brick データベース・ファイル (したがって I/O 負荷も) を利 用可能なすべてのディスクに均等に分散することで、管理オーバーヘッドを低く抑えながら非常に優れた性能を実現 できることを示しています。これは、“極限のストライピング” または SAME (第 2 節参照) として記述される格納域 レイアウト戦略の有効性を裏づけており、研究結果とも一致しています。特に、テーブルをインデックスと分離する必 要はなく、それらを分離すると性能に悪影響を及ぼす可能性があります。 以下に、IBM Red Brick Data Warehouse のチューニングに関する主な推奨事項をまとめます。このチューニング・ガ イドラインには、可能性のあるクエリおよびアプリケーションのシナリオすべてについて最適な性能を提供することは 期待できません。このガイドラインはむしろ、比較的混合された作業負荷の全体的な性能を最適化することを意図し ています。これは大まかなガイドラインにすぎず、個別のデータ・ウェアハウスのインストールまたは特定のコンピュー ティング環境によってこれらの戦略の調整が必要な場合があります。したがって、ここでの推奨事項に盲目的に従う ことはお勧めしません。しかし、本論文を読み終えたときに各種の格納域レイアウトの選択肢とその潜在的な結果に ついて理解が深まっていることを願います。それが、特定のデータ・ウェアハウス実行の格納域レイアウトを設計する 際に、知識に基づく決定を行うための助けとなるでしょう。 5.1 I/O のチューニングに関する推奨事項 ●セグメント化スキーマには十分詳細度の高い細分性を使用 o 少数の大きなセグメントを使用するのではなく、ファクト・テーブルを適切な数のセグメントにパーティション 分割します。数百のセグメントが妥当でしょう。 15 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse o Red Brick の STARjoin とTARGETjoinはセグメント別に並列化されることに注意してください。ほとんどの結合 クエリが 1 ヵ月分のデータにアクセスする場合、ファクト・テーブルを月別にパーティション分割することでデフォ ルトの並列性が回避されます。この場合、週または日単位でパーティション分割した方が適切です。 o Red Brick の各種の演算子は、特定のセグメントにアクセスする必要がない (クエリによる) かどうか,推測可能 です。これを “smart-scan” といいます。詳細度の高い細分性でセグメント化した方が、できるだけ多くのデータ をクエリ評価から除外するのに適しています。 ●十分な数のデータ・ファイル (PSU) にセグメントを格納 o 1 セグメントにつき、非常に大きな少数の PSU を使用するよりも、より小さな PSU を多数使用する方が適切 です。この推奨事項は、テーブル・セグメントとインデックス・セグメントの両方に当てはまります。 o一つのセグメントが一時 I/O ホットスポットになる場合は、性能を最適化するために、ディスク・ファームの幅いっ ぱいに I/O を分散します。 o テーブル・スキャンは PSU 別に並列化されることに注意してください。1 セグメント当たりの PSU 数が少なす ぎると、並列性が阻害されます。 o 大規模なテーブルと、中程度の数の超大容量ディスクがある場合、1 セグメント当たりの PSU 数を、テーブル が格納されているストライプ化ボリューム内のディスク数と同じにすることをお勧めします。ストライピングの方が 性能と管理の面で優位であるにもかかわらず、ストライピングに対して手動ファイル割当てを選択する場合は、こ れが特に重要です。 o ディスクが多数存在する (たとえば 64 ディスク以上) 場合は、非常に小さい PSU が多く作成されすぎるという 結果になる可能性があります。その場合は、PSU の数を少なくともシステム内の CPU 数と同じにします。ファク ト・テーブル・セグメントについてはこれが絶対的な最低限です。その結果非常に大きな PSU (500MB 超または 1GB 超) が作成される場合は、PSU 数をシステム内の CPU 数の 2∼3 倍にします。 ●すべてのものをすべてのディスクにストライプ化 o 利用可能なすべてのディスクにわたる一つの大きなストライプ化ボリュームを使用すれば理想的です。これによ って、最適な I/O 負荷バランス、非常に優れた I/O 性能、および非常に低い管理オーバーヘッドが実現します。 また、すべてのディスクが同じタイプ (同容量、同速度など) であれば理想的です。 o 実際の格納域システムおよび利用可能なボリューム管理ソフトウェアによっては、すべてのディスクにわたる 一つのストライプ化ボリュームを作成できない場合があります。たとえば、ストライプ化ボリュームで許可される最 大デバイス数を超えるディスクが存在する可能性があります。この場合はおそらく、ディスクの半数ずつにわたっ て 二つのストライプ化ボリュームを作成できるでしょう。複数の PSU に格納される各セグメントには、第 1 の ストライプ化ボリュームでは PSU 1、3、5 等、第 2 のストライプ化ボリュームでは PSU 2、4、6 等を割り当てま す。 o 制限によって二つ以上のさらに多くのストライプ化ボリュームを作成せざるを得ない場合は、各ボリュームが同 数のディスクにまたがるようにします。その後、可能であれば第 3.2 節で説明した “1-off” 戦略を採用して、各 セグメントの PSU を各ボリュームに均等に分散します。 o PSU の場合と同様、スピル領域もすべてのディスクに分散します。 o 第 5.2 節で説明したように、フォールト・トレランスを考慮に入れます。 ●中程度から大きなストライプ・ユニット・サイズ (最低 64KB、最大 1MB) を使用 o その特定のケースで性能が改善されるという具体的な証拠がない限り、8KB などの小さなストライプ・ユニット サイズを使用しないでください。 ●TUNE FILE GROUP パラメータおよび TUNE GROUP パラメータの設定 o 例： 96 台のディスクにまたがる大きなストライプ化ボリュームに /data という名前が付いている場合は、 rbw.config ファイルに TUNE FILE GROUP 1 /data および TUNE GROUP 1 96 というエントリを必ず入れてくだ さい。これによって、/data がファイル・グループ番号 1 として定義され、そのボリュームに同時に接続できる並 列プロセスの最大数 (1 クエリ当たり) が 96 に設定されます。 16 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse o TUNE GROUP を設定しないと、/data に対して一度に I/O を実行できるプロセスが1 クエリにつき 1 つと いう状況に陥ります。 o 実際には、クエリのすべてのプロセスが I/O を実行できるようにするには、TUNE GROUP を QUERYPROCS の値に設定するだけで十分です (QUERYPROCS がディスク数以下であると仮定して)。しかし、QUERYPROCS が大きくなったとき TUNE GROUP も大きくすることを忘れると、最終的には最適な I/O 並列性が得られなくな る可能性があります。したがって、TUNE GROUP をディスク数に設定しておいても害はありません。 o QUERYPROCS がディスク数より大きいと、システム構成が不均衡になる可能性があります。一般に、システム には CPU の 4∼5 倍あるいはそれ以上の数のディスクが必要です。QUERYPROCS を CPU 数の 5 倍に設 定すると非常に大きな値と考えられ、過剰なコンテキスト・スイッチングを招く可能性があるため大きすぎるとみな されるでしょう。 5.2 フォールト・トレランスに関する注意点 利用可能なすべてのディスクにわたってすべてのデータ・ファイルをストライピングすることの主な欠点は、フォール ト・トレランスが大きく低下することです。一つのディスクに障害が発生するだけで、すべての PSU が使用できなくな る可能性があります。n 台のディスクのうち 1 台に障害が発生する確率は、n が大きくなると大幅に高まります。ミ ラーリング (RAID 0+1) やデータ・パリティ (RAID 5) などの可用性の概念によってこのリスクを軽減できます。RAID 5 (パリティ) と RAID1 (ミラー) はどちらも、フォールト・トレランスを備えたディスク格納域を提供するものであり、それ ぞれに利点と欠点があります。 ディスクの障害に対する、最もフォールト・トレランスおよび性能に優れた保護はミラーリング (RAID 0+1) です。今日 のミラーリング・ソリューションは、ディスクとそのミラーへの並列書込みをサポートするだけでなく、ミラーリングされた ペアの両ディスクへの読取り要求を均等にします。ミラーリングには見積りの 2 倍のディスク・ドライブ数が必要なた め、これがコスト上の問題になる可能性があります。 RAID5 ディスク・アレイは、書込み性能が犠牲になるものの、よりコスト効率に優れたフォールト・トレランスの形式で す。RAID5 ディスク・アレイは、論理書込みごとに 物理 I/O を複数回実行します。また、ソフトウェアベースのパリテ ィ計算によって、書込み集約型のデータベース操作 (ロード、更新等) に対して大きなオーバーヘッドが生じる可能性 があります。ハードウェアベースのパリティ計算 (RAID コントローラ上の XOR チップ) のオーバーヘッドはごくわず かとされています。RAID5 のフォールト・トレランスは RAID 0+1 を下回ることにも注意してください。RAID5 アレイは 一つのディスク障害にしか耐えられないのに対して、RAID0+1 はミラーリング・ペアの両方のディスクがダウンしない 限り、複数のディスク障害に耐えることができます。 通常、RAID5 ディスク・アレイのディスク数は RAID 0 または RAID 0+1 のボリュームに比べはるかに限られます (たとえば 7 台または 14 台のディスクのみ)。可能性のあるシナリオを挙げると、フォールト・トレランスのために、そ れぞれ 7 台のディスクを使用する 10 の RAID5 アレイとして、利用可能な 70 台のディスクを構成する必要があ るとします。10 の RAID5 アレイのそれぞれについて、たとえば 64KB のストライプ・ユニット・サイズを選択できます。 管理を簡素化するとともに、10 の RAID5 ボリュームに PSU を均等に分散するため、10 の RAID5 ディスク・アレ イにわたる論理ストライプ化ボリュームを定義することを提案します。10 の RAID5 アレイのそれぞれが、論理ボリュ ーム・マネージャから見れば単一のデバイスのように見えます。論理ボリュームのストライプ・ユニット・サイズは、 64KB の 6 倍である 384KB に設定できます。つまり、一つの論理ストライプ・ユニットが一つのRAID5 アレイの 6 ディスクに書き込まれ、パリティ・ブロックが 7 番目のディスクに書き込まれます。これが、非常に適切でバランスのと れた RAID5 アレイの使用方法につながります。このような 2 次元のストライピング (ハードウェア・ストライプ化ボリ ュームにまたがるソフトウェア・ストライピング) は、EMC システムの Plaid に似ています。 17 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse 著者について： Matthias Nicola は 1995 年および 1999 年にそれぞれドイツの Technical University of Aachen (RWTH) でコンピュ ータ・サイエンスの博士号を取得しました。1995 年から 1999 年まで RWTH Aachen の研究員として勤務しました。 Matthias の研究は分散データベース・システムおよびレプリケート・データベース・システムの性能を中心に扱ってい ます。Matthias は 2000 年にカリフォルニアの Informix Software に入社し、2 年以上にわたって Red Brick Data Warehouse の性能を研究しました。現在は、IBM Silicon Valley Lab にてDB2 および XML の性能を研究していま す。 http://www.matthiasnicola.de/ 参考文献 [Bellatreche 00] Ladjel Bellatreche, Kamalakar Karlapalem, Mukesh K. Mohania, M. Schneider: What Can Partitioning Do for Your Data Warehouses and Data Marts?, International Database Engineering and Application Symposium, pages 437-446, 2000. [Chen et al. 94] P. M. Chen, E. K. Lee, G. A. Gibson, R. H. Katz and D. A. Patterson: RAID: High Performance, Reliable Secondary Storage, ACM Computing Surveys, Vol.26, No.2, pp.145-185. June 1994. [Chen, Towsley 96] Shenze Chen, Don Towsley: A Performance Evaluation of RAID Architectures , IEEE Transactions on Computers, Vol. 45, No. 10, pp. 1116-1130,October 1996. [Compaq 98] Configuring Compaq RAID Technology for Database Servers, Compaq White Paper, May 1998. [EMC 00] EMC: Metavolumes and Striping, EMC White Paper, 2000. [Fung 98] Cindy Fung: Disk Striping (Red Brick Warehouse 5.1), Technical Note TN9801, Red Brick. [Ganger et al. 93] G. R. Ganger, B. L. Worthington, R. Y. Hou, and Y. N. Patt: Disk Subsystem Load Balancing: Disk Striping vs. Conventional Data Placement, Proceedings of the 26 th International Conference on System Sciences, Vol. 1, pp. 40-49, 1993. [Griffith et al. 99] Nigel Griffith, J. Chandler, J. Marcos, G. Mueller, D. Gfroere: Database Performance on AIX in DB2 UDB and Oracle Environments, IBM Redbook, December 1999. [Holdsworth 96] Andrew Holdsworth: Data Warehouse Performance Management Techniques , Oracle Services White Paper, 1996. [Larson 00] Bob Larson: Wide Thin Disk Striping, Sun Micorsystems, White Paper, October 2000. [IBM 01] Barry Mellish, John Aschoff, Bryan Cox, Dawn Seymour: IBM ESS and IBM DB2 UDB Working Together, IBM Red Book, http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246262.pdf , October 2001. [Loaiza 00] Juan Loaiza: Optimal Storage Configuration Made Easy, Oracle Corporation White Paper. [Scheuermann et al. 98] Peter Scheuermann, Gerhard Weikum, Peter Zabback: Data partitioning and load balancing in parallel disk systems, VLDB Journal, (7) 48-66, 1998. [Veritas 01] Configuring and Tuning Oracle Storage with VERITAS Database Edition ™ for Oracle, VERITAS Software Corporation, White Paper, 2001. [Whalen, Schoeb 99] Edward Whalen, Leah Schoeb: Using RAID Technology in Database Environments , Dell Computer Corporation Magazine, Issue 3, 1999. 18 Storage Layout and I/O Performance Tuning For IBM Red Brick Warehouse