Comments
Description
Transcript
NonStop SQL/MX による超大規模データベースの設計と管理
NonStop SQL/MX による超大規模 データベースの設計と管理 テクニカルホワイトペーパー 目次 はじめに ............................................................................................................................................. 3 プロジェクトの概要 ............................................................................................................................ 3 顧客の課題 ......................................................................................................................................... 4 データベースへのデータの投入........................................................................................................... 4 データベースへのクエリ処理............................................................................................................... 4 データベース管理 ............................................................................................................................. 5 ソリューションの設計 ............................................................................................................................. 5 設計に関する留意点:NonStop の観点から ........................................................................................... 5 実装のオプション .............................................................................................................................. 5 データベース設計.......................................................................................................................... 6 データベースへのデータの投入 ....................................................................................................... 6 データベースに対するクエリの実行 .................................................................................................. 6 データベース管理.......................................................................................................................... 6 ソリューション ................................................................................................................................... 6 問題解決の鍵:データベース設計......................................................................................................... 7 パーティション分割の導入 .............................................................................................................. 7 1 つのサイロの設計 ...................................................................................................................... 8 アプリケーションとデータベースのメンテナンスを考慮した設計 ............................................................ 11 データベースへのデータの投入......................................................................................................... 12 ｢アクティブ｣テーブルのインストール ............................................................................................... 12 ｢安定｣テーブルへのデータの投入 ................................................................................................. 13 ｢アーカイブ｣テーブルへのデータの投入.......................................................................................... 13 データベースへのクエリの実行 ......................................................................................................... 14 データベースへのユーザー接続 .................................................................................................... 14 DP2 ラージブロック I/O................................................................................................................ 14 マルチユニオン機能 .................................................................................................................... 14 OR ロジックの強化 ...................................................................................................................... 15 クエリパフォーマンスの分析.......................................................................................................... 16 データベースの管理 ........................................................................................................................ 16 テープ管理とビジネスコンティニュイティ........................................................................................... 16 オーディットトレイル ..................................................................................................................... 17 高速統計 ................................................................................................................................... 17 定期イベントの自動化.................................................................................................................. 18 まとめ............................................................................................................................................... 18 技術的補足説明:マルチユニオン演算子と制約ベースプルーニング ............................................................ 19 概要 ............................................................................................................................................. 19 問題提議....................................................................................................................................... 19 NonStop ソリューション.................................................................................................................... 20 NonStop 以外のソリューション .......................................................................................................... 20 ある事例での一時パーティション分割................................................................................................. 20 問題の特徴 ................................................................................................................................... 21 ソリューション ................................................................................................................................. 22 制約ベースプルーニング:制約情報を使用したテーブルの除外 ............................................................... 23 マルチユニオン演算子:ユニオンバックボーンを圧縮してデータフローを削減する単一の演算子 ................... 24 詳細情報 .......................................................................................................................................... 25 はじめに 200 テラバイト超級のデータベースに、ほぼリアルタイムにアクセスしなければ業務が成り立たないとした らどうされますか。毎日 1 時間につき最大 19 ギガバイトのデータを、ほとんどリアルタイムにロードしなけ ればならず、同時に、この同じ重要データにほぼ即時のクエリアクセスができるようにしなければならない、 このような環境を想像されたことがあるでしょうか。 また、その環境は、200 テラバイトを超すデータのすべてが連続して使用され続ける中で、データ整合性を 保証し、業務のボリュームの成長とともにデータベース全体をスケールアウトできる、そんなことが本当に 実現可能なのでしょうか。 この難題に解決の糸口はあるのでしょうか。 HP NonStop Advanced Technology Center (ATC) のプロジェクトチームにとって、その答えは｢今までの経験 と実績｣の延長線上にありました。つまり、HP NonStop サーバーは、データベースの保守とクエリの同時実行 を行い、可用性とスケーラビリティが前提のミッションクリティカルなコンピューティングタスク用のために設計さ れていたのです。 実現に至る道筋は決して平たんではありませんでしたが、今回の成果として、このプロジェクトの成功に貢 献したオペレーティングシステムの機能強化は、一般環境でも使用できるようになりました。 SQL/MX では、リリース 2.3.3 以降、複数ユニオン機能 (n-way UNION) 、制約ベースプルーニング、OR 最適化、DP2 のラージブロック (32k) I/O、および FASTCOPY ユーティリティ (高速コピーを実行) を利用で きるようになりました。ただし、以前のリリースにも、｢高速統計｣や、コンパイラとエグゼキューターに関する 各種機能強化をはじめとする、いくつもの有用な機能は含まれています。 NonStop OS のもう 1 つの新機能である BladeCluster ソリューションは、ノード間接続のネットワークトポロ ジで、圧倒的高帯域幅を実現したことでレイテンシを下げ、システムの最新機能にも十分に対応できるよう にしました。 この機能強化によって、SQL/MX を使用するあらゆる規模のアプリケーションの性能を向上できます。ただ し、当然のことながら、ハードウェアとソフトウェアの幅広い構成に対応できるのは、優れたアプリケーション 設計に負うところが大きいのも事実です。 今回のプロジェクトで顧客が直面した問題は、求められるコンピ ューティング性能が突出して高かったことを除き、基本的には、他のどの顧客の問題とそう大きく異なるも のではありません。どのような状況下であっても、業務に合わせて成長し、稼動し続けられるソリューション が求められるという点では同じです。 プロジェクトの概要 ATC がこのプロジェクトに着手することになったいきさつは、顧客のインフラストラクチャが、現状では機能 しているものの、このままではパフォーマンス、可用性、スケーラビリティの面で解決が困難になることが予 想され、その解決を依頼されたことに始まります。それまでに、この顧客のソリューションは、他のプラットフ ォームで検討し尽くされ、いずれも期待に応えられなかったことから、このプロジェクトは、｢最後の挑戦｣、 ｢NonStop で無理なら諦めるしかない｣という状況でスタートしました。 アプリケーションの要件は、ほぼリアルタイムでデータベースをロードする非常に過酷な要求なもので、加 えて、1 つのデータベースインスタンスに対してクエリと挿入が同時に発生し、標準的なクエリの応答時間を 10 秒以下に抑えることが求められました。 また、データは、1 年間はオンラインで使用できる必要があり、たとえアーカイブに保存されたとしても、短 時間でテープからリストアし、クエリに利用できなければなりません。 データ復旧の要件は、オンラインとオフラインのデータボリュームを対象とし、その運用やデータ管理は、ベ ンチマークテスト実行時や、さらに重要な実際の本番環境には無視できない量の負荷として現れてきます。 HP は、NonStop サーバーをプラットフォームとしたデモンストレーションで、顧客から提示された応答時間 内でクエリを実行しつつ、24 時間で 17 億 5 千万件の挿入処理を実行できることを証明することに成功し ました。同時に、この 24 時間内に、システムやデータベースの各種保守作業も実施されました。今回使用 3 したアプリケーションは、ユーザーの受け入れテストが完了した後、本番環境に移行され実装される予定で す。 顧客の課題 どのようなプロジェクトでも、最終的達成目標を書き出した要件リストの検討から始まります。他の多くの顧 客と同様に、今回の要件も大別すると以下の 3 つのカテゴリに分けられました。 データベースへのデータの投入 データベースへのクエリ処理 データベース管理 データベースへのデータの投入 このプロジェクトを際立たせる特徴は、その圧倒的なデータボリュームの存在です。毎日、2 億 5 千万件の 入力レコードが、複数のアプリケーションから複数のフォーマットで到着します。各レコードのデータは約 2 キロバイトで、7 回以上の挿入処理が発生します。この挿入処理を 1 日あたりの合計に換算すると、約 17 億 5 千万件になります。1 時間あたりの平均処理レコード数は約 1 千万件です (オフピーク時)。ピーク時 の 1 時間あたりの｢摂取率｣は、全体、すなわち 2 千万レコードの 8 パーセント強で、1 時間あたり 1 億 4 千万 (毎秒 39,000) レコードの挿入が発生することになります。 処理上、データを連続してロードする必要がありますが、このような大量データが常時到着し、ほとんど瞬 時にクエリで利用できることが必要なため、従来のバッチ処理の利用という選択肢はありません。とは言う ものの、現実のデータは 1 つの単位として扱わなければならないバッチとして到着します。データ整合性ル ールにより、単一障害が発生した場合であっても、｢バッチ｣に含まれるいかなるレコードもデータベースに 残らないことが求められます。 このソリューションはさらに、ある段階までは、遅れて到着するデータにも対応する必要があります。大部分 のデータはソースシステム上で発生するのとほぼ同時に到着しますが、ソースでのイベント完了後でなけ れば到着しないデータもあります。柔軟に設定された時間制限の範囲内で、このように遅れて到着するデ ータをデータベースに受け入れる必要があります。 挿入とクエリは、単一データベースインスタンス上で必ず同時に発生します。ベンチマークでは、ピーク時と オフピーク時、および 1 時間のストレステストで、挿入とクエリ速度が安定することが求められ、｢挿入のみ｣ の場合に至っては、ピーク時の 2 倍の処理速度が求められました。 1 年間はオンラインでデータを利用できる必要があり、その後はデータをテープに移動して、一定期間は保 存しておく必要があります。テープアーカイブに保存される 1 年目には、クエリで利用できるように最長で 2 ヶ月間のデータを短時間でディスクにリストアするように、ユーザーから要求されることも考慮しなければな りません。 データベースへのクエリ処理 データベースに対するクエリの要件は、他の NonStop アプリケーションと同様、24 時間/週 7 日間の連続 可用性から始まり、データロードとオンラインデータベースメンテナンスを並行して同時にできることが求め られました。 ユーザーは ODBC や JDBC のクライアントからデータベースに接続し、終日、特に通常の営業時間内には 大量のクエリを送信します。顧客のデータアクセスの要件は、クライアント接続レベルで適切に解決できた ため、このプロジェクトでデータセキュリティに関して特に考慮するべき点はありませんでした。 顧客の日常のクエリ処理は数千ものさまざまなクエリから生じるもので、エンドユーザーの応答時間の要件 に基づいて 3 つのグループに大別できます。｢標準｣クエリは、日常の処理の半数近くを占め、秒単位の精 度の極めて厳しい応答時間が要求されます。今回のプロジェクトの通常の最長応答時間は 10 秒で、速け れば速いほどよしとされました。アドホックの分析クエリは、日常の処理の約 10 パーセントで、この応答時 4 間は分単位であることが求められます。クエリの 3 つ目のグループは、1 つ目と同様に秒単位の応答時間 が要求されるものでしたが、要件はやや緩和されています。 いずれのグループも、時間帯やその他の検索基準が異なる基本クエリセットが用意されました。大部分の クエリは、最新の月のデータにアクセスしますが、データベース全体のいかなる対象期間の検索も必要とさ れ、これには、テープからリストアされるデータも含まれます。 SQL エンジン内の分析関数のコールはほとんど発生しません。クエリ処理は OLTP と OLAP のいずれの形 態もとらず、通常は、クエリによりユーザークライアントアプリケーション内に多数の結果セットが返され、そ れをアプリケーションが操作する方式で、データベース内の低レベルの集計処理とも言えます。業務トラン ザクションは、分析処理が必要な際にプラットフォーム外で発生します。NonStop データベースは、基本的 にほぼリアルタイムで連続して動作するオペレーショナルデータストア (ODS) として存在し、NonStop サー バー上のソフトウェアコンポーネントは、そのデータベースの内外へとデータを移動するパイプ役として機能 します。 データベース管理 このプロジェクトでは、データ整合性とビジネス継続性に対する通常の要件が求められたため、当然ながら、 Backup/Restore 2 (BR2) と TMF が利用されることになりました。通常と異なるのは、アーカイブに保存され たデータを短時間でオンライン状態にリストアする必要があるという点です。 この要件と、そこに関わるデータ量をあわせて考えると、データ管理と運用に潜在する問題点が浮かび上 がってきます。つまり、アーカイブされたデータは、たとえ短期間であったとしても、運用中の既存のユーティ リティや手法と統合する必要があり、これが解決できないようでは、長期間にわたって利用できるソリューシ ョンとは言えません。 ソリューションの設計 設計に関する留意点:NonStopの観点から 今回の顧客は、前述のとおり、NonStop が候補に挙がった時点で、既に数多くの選択肢を検討し尽くして いました。NonStop が達成できるとする可用性、スケーラビリティ、データ整合性、セキュリティ、パフォーマ ンスは、まるで絵に描いた餅のようですが、NonStop プラットフォームにおける 30 年以上にわたる可用性 とスケーラビリティを備えた並列処理ソリューションに裏打ちされ、ビジョンが現実味を帯びました。このソリ ューションは、新しい発想の推進力と捉えることもできますが、NonStop の開発者にとっては目新しいもの ではありません。 NonStop の低い TCO (総所有コスト) に対して第三者機関が証明するドキュメント類も、NonStop ソリュー ションの信頼性を裏打ちする大きな要因となりました。大量なデータのメンテナンスには顧客のビジネスの 継続を阻むほどの多大な運用コストが必要になることもあり、それによってはソリューションそのものがまた 新たな問題になる恐れもあります。 他の多くの顧客にとってもそうであるように、性能が向上してコストが下がるのであれば、この上ないソリュ ーションと言えます。この実現を目指してプロジェクトが開始しました。 実装のオプション このソリューションでは、プロジェクト開始時に発表されていたハードウェアをベースに、3 台の NS16016 サーバー (48 CPU 構成、各 CPU につき 16GB メモリ搭載) を採用することにしました (ハードウェア選定 後に NonStop Blade が発表され、メモリの上限も引き上げられています) 。 ノード間の接続には、初期バージョンの BladeCluster Solution を使用しました。ブレードを冠する製品名で すが、ブレード以外のインストール環境をサポートしています。 1460 個の内蔵ドライブと 2 つの XP12000 ディスクアレイを組み合わせることで、520 テラバイトのディス ク容量 (ミラー構成で 200 テラバイト超) を構成できます。 5 データベース設計 このプロジェクトのデータボリュームのために、あらゆる新規データベースの開発で共通する設計に、難し い判断が強いられました。テープからの｢迅速なリストア｣という要件は、さらにデータベース設計の開発に 予想外の展開をもたらしました。 論理データベース設計の観点では、どのような方法も可能に考えられますが、データをディスクに格納する 段階になると、特に、これほどの大量データを対象にするのであれば、正しい場所に正しい順序でデータを 置くことが最も望まれます。初期段階での検討事項の 1 つが、データの物理的な配置でした。大量のデー タの中には、新しく一時的なデータと、古くて安定している 2 種類のデータ (オンラインの履歴データとアー カイブに保存されていて短時間でリストアできる履歴データ) があります。このプロジェクトでは、すべてデー タベースを NonStop 上に実装とすることから、ストレージの選択肢としては内蔵 (JBOD) と外部 (SAN/XP) のディスクストレージデバイスと、仮想/物理テープストレージデバイスがストレージの候補に挙がりました。 いずれのストレージデバイスの場合も、このように大量のデータが保存されているテーブルを処理するため には、パーティション分割が必須となるのが大前提です。 プロジェクトチームはデータベース設計にあたり、次の要素を検討しました。 データアクセスの要件に合うストレージデバイスを選択する。 1 つの論理データモデルと複数の物理モデルを使用する。物理モデルは、それぞれがそのストレージデ バイスに格納されるデータのアクセスパターンに対応する。 いずれのストレージデバイスからも、ライフサイクルのいかなる段階においてデータを取りだせるように、 一貫した方法でデータを分割する。 論理的に同一のデータを結合する (物理的には別々のテーブルに配置される)。 繰り返しますが、これらの検討事項は、多くのプロジェクトと大差はありません。このプロジェクトが特異なの は、そのデータ量と、テープからオンライン環境への短時間でのデータのリストアという要件です。 データベースへのデータの投入 使用できるデータベースにはどれもデータが含まれている必要があるため、今回のプロジェクトでは、デー タの投入で問題が 3 倍に増えました。 最初の作業は、新しく到着したアクティブなデータを効果的な方法でロードすること、2 つ目は安定データを XP ストレージに移動すること、3 つ目はアーカイブデータのテープからのアドホックなリロード (すなわち｢高 速リストア｣) でした。それと同時に、1 つの難題、すなわち、山のようなデータを、その物理的な位置にかか わらず、ユーザーが簡単にアクセスできる方法も検討しました。 最初の取り込み処理のオプションには、ステージング環境での挿入から、ほぼ直接のロードまでが含まれ ました。ほぼリアルタイムでロードされるデータ量を考慮して、データベースに対する可能な限り最短のパス を見つけることを目標としました。 データベースに対するクエリの実行 プロジェクトチームは、クエリの設計とパフォーマンスに関する通常の課題に加えて、データサイズに起因 する課題にも取り組みました。論理的には同じテーブルでも、物理的には複数の実体からの中間結果を結 合する必要があるため、当然ながら検索範囲もデータ転送も大きくなることが予測されました。 データベース管理 データベース管理では、データベースのサイズと｢高速リストア｣に対応できなければなりませんでした。作 業の自動化と実践的な既存運用の統合により、ベンチマークまたは概念実証プロジェクトを、そのまま本番 環境へ移行できる可能性が高まりました。 ソリューション 多くの場合、ソフトウェアアプリケーション開発の最初の手順で、データを分析します。今回は、論理データ モデルの設計や、ビジネス的なデータの側面の洗い出しに苦労する必要はありませんでした。既に、顧客 は、過去の実装でこのような作業に地道に取り組んでいました。NonStop チームが参加するより前の段階 6 で、｢大量データのその役割｣レベルまで明確に把握できていたので、この時点で検討が必要だったのはす べて物理面のみ、すなわち、ロード量を測り、クエリを精査して、すべてを無理なく処理できるようにすること でした。今回のプロジェクトは、この点において恵まれており、アーキテクチャとデータベース設計が考え抜 かれていたため、NonStop SQL/MX の能力をより一層生かすことができました。 問題解決の鍵:データベース設計 どのテーブルも 1 つのディスクにまとまれば話は簡単ですが、収まりきらない場合には、効率的なパーティ ション分割の方法を導き出さなければなりません。データ量の増加にともないデータのリロード時間も増加 する点のみを考えても、入念なプランニングの必要性が分ります。 たしかに対象データは膨大ですが、今回のプロジェクトの目標は、他のあらゆるパーティション分割の作業 と同じで、論理データモデルに基づいて処理できるデータの｢塊｣を作成し、各パーティションを正しく配置し、 同様に物理テーブル全体や同じ論理テーブルを構成する物理テーブルも正しく配置することです。分断攻 略のスライスアンドダイスの戦略に則って、繰り返し可能な並列プロセスを構築し、それらがひとまとまりで あるかのようにデータを投入し、バックアップ、再編成、クエリを実行できるようにします。その逆も機能する ようにします。つまり、個別のプロセスがさまざまな重要な局面で 1 つの独立した実体として動作しなけれ ばなりません。 このプロジェクトでは、そのデータ量に加えて、｢データベースの陰と陽｣と言われてきた、設計に関するある 課題が浮き彫りになりました。今回のアプリケーションには、極めて大量のデータの取り込み処理と、それと は相対的に量的には少ないもののクエリ処理の応答時間厳しい基準が科せられます。データの取り込み の比率を考えれば、複数のディスクドライブを使用して作業を遅延なく処理できる高度な並列処理が必要な ことは明らかでした。その一方で、クエリの応答時間基準が求められ、ハードウェアコストを削減しつつ可能 な限り高密度でデータを格納したいという顧客の希望もありました。今回のソリューションでは、これらの相 反する要件と 200 テラバイト超のデータという課題を解決する必要がありました。 パーティション分割の導入 今回のデータベースは、同等な規模のデータベースの集合体でありながら、エンドユーザーにとっては SQL ビューで 1 つのデータベースとして扱えるように作成されました。すなわち、異なるデータベースを UNION ALL で結合する方法でエンドユーザーのビューの構築が可能になりました。これは、複数ユニオン 機能の拡張によって (n-way UNION) 実現しています。 単一の統合されたビューを並列で構成する同等のデータベースにおいては、その数に論理的な制限はあり ません。ここで制限の要因となるのはメモリです。1 つのクエリで使用される UNION 数やパーティション数 は、コンパイラが必要とするメモリに影響するためです。SQL/MX は今回の拡張機能によってさらなる前進 を遂げ、少なくとも今回の 200 テラバイトのデータベースに物理的に迫る、これまでに成し得なかったレベ ルに足を踏み入れました。 マルチユニオン演算子に関する詳細は、このホワイトペーパーの｢技術的な補足説明｣、『SQL/MX Reference Manual』の第 10 章｢Query Optimization and Performance｣、および『SQL/MX Query Guide』の第 7 章｢QL/MX Operators｣を参照してください。この演算子の使用例を、以下の URL の ｢Features and Commands of NonStop SQL/MX for Release 2.3.3｣セクションからダウンロードできま す。 http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=NSH-HELP-PROG 今回の実装の話をスキーマのパーティション分割に戻します。これらの同等規模のデータベースは、それ ぞれが固別のカタログとスキーマ持っており、｢サイロ｣として捉えられます。話を簡潔にするために、これ以 降の説明で、｢サイロ｣という用語の代わりに｢時間のスライス｣という用語も使用します。 7 図 1: 二次元データベース 図 1 に示すように、今回のデータベース設計は、全体が 1 つに統一されたビューとして表すことができ、物 理的には異なるサイロの行列で構成されます。図 1 では、このビューを長方形 (背景色なし) で表していま す。それ以外のオブジェクトの影付きの部分はすべて、実体はないものの、物理的に複製されていることを 表します (図 3 (これよりも後ろに掲載) は、この図にデータベース設計の別の側面が追加された 2 番目の バージョンの図です) 。サイロの複製という特性から｢二次元｣データベースと呼ばれることもありますが、こ れは、｢次元データモデル｣を意味するものではありません。 論理的に同一のサイロには、日付を基準にした、データの特定のスライスが含まれます。各サイロにはそ れぞれに固有の特定の範囲の日付値のデータが含まれ、各サイロが標準の同じ期間 (この場合は 2 週 間) に対応します。各サイロには約 3,400 ギガバイトのデータが含まれます (スラック領域を除く)。 このアプリケーションのサイロのサイクルは、時間スライスを基準にして物理的にデータをグルーピングす る他のアプリケーションの手法と同様に行われています。日付と時刻をトリガーとして使用するサイロが切 り替えられ (あるいは開始し)、新しくなったファイルセットを使用して新しい時間スライスのデータが収集さ れます (ATM や POS の多くのアプリケーションでこのような方法が採用されています) 。新たに有効になり データが収集されるサイロは、そのサイロ内のデータの処理が完了するまで再利用できません。したがって、 必要最小限のサイロの数は次のように算出されます。 [必要とする週の合計数/ (週/サイロ) ] + 1 = 必要になるサイロの数 この計算式の最初の部分は、基本ストレージ要件を表し、“+1” は新しく有効になってデータが収集される サイロ、すなわち、次に有効になるサイロを表します。 サイロを追加することで、このアプリケーションの｢高速リストア｣の要件に対応できます。追加するサイロの 数とサイズは、いずれの段階においてもリストアされる可能性がある時間スライスの最大数とサイズによっ て異なります。 1 つのサイロの設計 今回のプロジェクトのデータベース設計は、リレーショナルモデルの 7 個のテーブルで構成される、顧客の 既存の物理データベースから開始しました。NonStop への実装では 6 テーブルを 1 つのテーブルにまと めたため、1 対多のリレーションシップを持つ 2 つの SQL/MX テーブルだけになりました。多くのクエリは、 内部結合か外部結合を使用して両方のテーブルからデータを選択します。この新しい物理設計によって、 データの取り込み処理に必要となる挿入数と、多くの場合にクエリに必要となる結合数が減少しました。 8 キー: 各サイロの 2 つのテーブルをここではテーブル A、テーブル B と呼ぶことにします。テーブル A は親 テーブルで、図 2 に示すように、マッチングキーカラムは同じ順序です。いずれのテーブルでも、ストレージ キーとプライマリキーが一致しています。 両方のテーブルで、タイムスタンプ (DTG—Date Time Group) カラムがプライマリキーに含まれていますが、 ストレージキーの先頭部分ではなく、4 番目のカラムです。このカラムの値によって、データ取り込みアプリ ケーションがデータを挿入するサイロまたは時間スライスが決まります。 図 2: テーブルのリレーションシップ (1:n) TABLE A Col A Col B Col C Col DTG Col E Col Col Col Col Col Col TABLE B A B C DTG E F レンジ・パーティション分割:2 つの先頭フィールドの分布が把握でき、レンジ・パーティション分割に適してい たため、両方のテーブルをレンジ・パーティション分割して、同じ範囲を使用しました。特筆するほどではな いのかもしれませんが、レンジ・パーティション分割によって、このような規模でも、パーティション ID やハッ シュキー値の生成によるオーバーヘッドを回避でき、各サイロに均等にデータが分布するようになります。 ここで重要なポイントは、各サイロが、ある特定の時間スライスを表すため、 (テーブル A とテーブル B の) パーティションの各ペアがデータの 1 つの独立したスライスを表し、データが日付によって既に分割されて いるという点です。 インデックス: このプロジェクトよりもはるかに小規模のデータベースであっても、テーブル全体のスキャン はできるだけ回避すべきです。各サイロには、合計で 5 つのインデックスが存在し、2 つのテーブルに対す るクエリで使用されます。これらのインデックスは、テーブル全体のスキャンを回避するために作成されたも ので、発生頻度は少ないものの、インデックスのみの読み取りも可能にしました。 制約: DTG キーカラムのそれぞれに制約を設定しました。次の 2 つの重要な方法によって今回の実装に 貢献していますが、制約によって深刻なオーバーヘッドを引き起こすことはありません。 どのサイロにも、そのサイロの時間スライスに属するデータだけが格納されます。 この効果は明らかです。今回のデータベースでは、データサイズと日付属性が処理の鍵をにぎることを考 慮すれば、もしもこれらの制約の作成でオーバーヘッドやメンテナンスが発生したとしても、それに見合う価 値があると言えます。実際のメリットの有効性は、やや捉えにくいかもしれません。 複数のテーブルを 1 つの UNION ALL ビューに結合する場合であっても、制約ベースプルーニング (CBP: Constraint Based Pruning) を使用できます。 CBP によって NonStop SQL/MX は、クエリで指定された DTG 範囲から外れていることが分かっているテ ーブルを排除するようになります。あるテーブルにはクエリで探しているデータが格納されている可能性が ないことを制約から判断できる場合、コンパイラは検索ツリーのプルーニングによって、そのファイルスキャ ン処理をデータが存在する可能性があるテーブルの値ノードへと置き換えます。今回の例では DTG カラム だけに制約が設定されているため、それらのカラムを使用して結果セットを導出するクエリだけに CPB が適 用されます。 制約はオーバーヘッドが生じるため、一定の制限のもとで制約を使用するべきですが、CBP は、制約を使 用したいと考える重要な新しい理由となるでしょう。 9 図 3: データベース設計の概要 制約ベースプルーニングに関する詳細は、このホワイトペーパーの｢技術的な補足説明｣、『SQL/MX Reference Manual』の第 10 章｢Query Optimization and Performance｣、および『SQL/MX Query Guide』の第 1 章｢Compiling and Executing a Query｣を参照してください。この演算子の使用例を、以下 の URL の｢Features and Commands of NonStop SQL/MX for Release 2.3.3｣セクションからダウンロード できます。 http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=NSH-HELP-PROG ストレージ: 多くのアプリケーションでそうであるように、このプロジェクトのデータのライフサイクルも 3 つの フェーズ—アクティブ、安定、アーカイブに分類されます。今回のアプリケーションでは、それぞれのフェーズ に適したストレージデバイスを使用し、データアクセスの特性とデバイスの種類に合わせた物理データベー ス設計を採用しました。現在の XP ディスクは今回のプロジェクトのデータ取り込みの要件に経済的に対応 できないことが分かっていた一方で、クエリの要件には十二分に対応できます。そのため、2 種類のオンラ インストレージデバイス、すなわち、新しいデータには内部接続された (JBOD) ディスクを使用し、流動性が 少なくてクエリにもそれほどは利用されない古いデータには外付けの XP (SAN) ディスクを使用することに しました。 新しいデータは、内蔵ディスクに配置した｢アクティブ｣テーブルに書き込まれ、書き込みと読み取りが並行し て処理されます。これらのテーブルとインデックスは 288 個のパーティション (CPU あたり 6 個) に分割さ れているため、並列処理性能を最大限に引き上げており、挿入のためにスラック領域が確保されているた め、XP の場合よりも高まっています。現行のサイロが新しいデータの大部分を受け取ります。それ以外の サイロには新しく到着するデータが少ないため、書き込み処理はほとんど (あるいはまったく) 発生しません。 時間スライスのすべてのデータが (実際に使用する目的で) 到着した後に、それらのデータは流動性が少 ないフェーズに移行し、一般的には読み取りアクセスのみが発生することになります。この段階で、これら の｢安定｣データが XP ストレージデバイス上のテーブルへと移されます。テーブルが XP ディスク上にロード されてしまえば、挿入や更新は発生しません。これらのテーブルは、48 個のパーティションに分割されてい ます (CPU あたり 1 個)。 ある時間スライスのデータを内部のサイロから外部 (XP) のサイロへと簡単に移動できますが、その理由は、 同じテーブルのパーティション間ではなく、テーブル間の移動であるためです。論理的には同一であるもの の、データが保存されるデータの一般的なアクセスパターンに基づいて物理テーブルが異なります。ただし、 10 時間スライスによる一貫性のあるパーティション分割によって、どこに格納されているかにかかわらず、デ ータを取得できます。 ある段階でオンラインの保存期間が満了すると、XP テーブルが Backup/Restore 2 (BR2) を使用して仮想 テープにバックアップされます。アーカイブされたデータについても、要件にあるように、厳密な制限時間内 にリストアし、クエリに利用できるようにしなければなりません。安定状態にあるテーブルだけが、｢高速リス トア｣の目的でバックアップされます。これは、データのライフサイクルと整合性があり、そうすることで、アー カイブされたオブジェクトとそれがリストアされるサイロとの間のパーティション分割の整合性が保証されま す。 アプリケーションとデータベースのメンテナンスを考慮した設計 この｢二次元｣データベース設計は、異なる時間スライスのサイロの複製によって成り立っており、データベ ース管理も考慮されています。日付でデータが分かれていれば、データベース全体にデータが混在するパ ーティション分割されたスキーマの場合のように、メンテナンスで頭を悩ませることはありません。1 回の効 率的な操作で、サイロとそこに保存されている古いデータを移動あるいは削除できます。新しい時間スライ スのために新しいサイロを作成する場合も、効率的な手順で作成できます。これらの手順は効率的かつ簡 単なため、自動化も可能です。 この方法には、テーブル定義の変更 (たとえば、1 つ以上の新しいカラムの追加) の際にもメリットがありま す。そのような変更は多くの場合、理由はさまざまではあるものの、テーブル変換がほとんど発生すること がなく、長期間にわたって存続する傾向にあるオリジナルテーブルがあって、そのテーブルをアドホックでロ ーテーションさせることで実行されます。 今回の設計は、テーブル構造の変更にも簡単に対応できます。クエリからはビューとしてのみデータベース を使用するため、ビュー定義のみを変更することで、新しいカラムが現行のサイロには存在して古いサイロ には存在しないという状態にできます。既存のクエリも、新しいカラムを使用するクエリと同じビューを引き 続き使用できます。すべてのサイロの物理構造が同じであれば、基底となるテーブル構造の現在の状態を 反映するようにビューを定義し直すことができ、DBA 以外がそれを意識する必要はありません。 同様に、データの取り込みやマイグレーションのためのソフトウェアに対する影響も、複数のフォーマットで データを取得する場合に限られます。古いフォーマットの入力がすべて処理された後にデータベースが変 更されたのであれば、遅れて到着するデータは新しいフォーマットになります。それ以外の段階で変更され る場合は、複数のフォーマットでデータを受け取る期間だけ複数のソフトウェアバージョンを実行して、フォ ーマット変更に関係するデータベースの差異をソフトウェアが考慮しなくてよいようにする必要があります。 このような方法によって、エンドユーザーやクエリ開発者には、要求したとおりにデータベースが変更された ように見え、ローテーションは必要ありません。捉え方によってはさらに好都合なのは、テーブルの複数の バージョンやローテーション型の処理ルールを長期間にわたって使用する場合とは異なり、コーディングの 変更や、その他の対策の範囲と期間を変更そのものだけに限定できることです。 まとめ 今回のデータベースは、論理的には同一の SQL/MX テーブルの集合体から構成され、物理的には別のカ タログとスキーマを使用する｢サイロ｣として実装されます。サイロとはある時間スライスのデータで、それら の集まりが SQL ビューをとおして 1 つのテーブルとしてユーザーに提示されます。各サイロともレンジ・パ ーティション分割が使用されます。いくつかのインデックスがユーザーのクエリをサポートします。 データは日付を基準にして｢スライス｣されますが、その際に、先頭カラムではない DTG タイムスタンプキー カラムの値と 2 週間という固定の測定基準が使用されます。これらのカラムに制約を設定することで、デー タが正しい位置に置かれることが保証され、さらに重要なメリットとして、コンパイラによる実行プランの生成 時に制約ベースプルーニングを利用できるようになります。 データアクセスの要件に合わせて、3 種類のストレージデバイスを使用します。｢アクティブ｣データには内蔵 ディスクを、古い｢安定｣データには外付けディスクを、さらに古い BR2 フォーマットの安定データの｢アーカイ ブ｣には仮想テープを使用します。ストレージデバイスの種類とデータアクセスのパターンに合わせて物理 テーブルを設計しました。 11 ｢二次元｣設計を採用したことで、古くなったデータの削除と将来的に必要になる可能性があるテーブル構 造の変更の両方にスムーズに対応できるため、データベースとアプリケーションのメンテナンスが容易にな ります。 データベースへのデータの投入 データはそのライフサイクルにおいて 3 種類のデバイスに格納されるため、データも 3 とおりの方法でイン ストールすることになります (リストアのフェーズを含めると、実際には 4 種類) 。これらについて、これ以降 のセクションで順番に解説します。 ｢アクティブ｣テーブルのインストール 最初のフェーズではデータの取り込みが実行されますが、この作業はユーザーのクエリ処理と並行して行 わなければなりません。アクティブテーブルには新しいデータが書き込まれ、内蔵 (JBOD) ディスクに配置さ れるため、読み取りと書き込みの両方で並列処理を最大限に活用できます。最も好ましい状況は、ユーザ ーのほとんどのクエリも最も新しいこれらのデータを対象にすることです。 論理的な挿入はそれぞれ、少なくとも 7 つの物理的な挿入 (2 つのテーブルと 5 つのインデックス) が必要 であるため、読み取り/書き込みの回数は膨大であり、多数のボリュームを対象に実行されます。アクティ ブテーブルのパーティション数は、アクセスが少ない XP テーブルのパーティション数の 6 倍になります。た だし、そのブロックサイズはどちらも、MX テーブルで利用できる最大サイズである 32k です。このブロック サイズは、ラージブロック、シーケンシャルアクセス、JBOD 側での XP の最適化と矛盾なく、ブロックスプリッ トの発生が最小限に抑えられます。 このシステムは、外部システムへの FTP サーバーとして動作します。データは、NonStop での準備段階の ステージング環境を経ることなく、アクティブテーブルへとそのまま取り込まれます。サーバー上のデータ取 り込み担当のサブシステムが、最大で 16 の同時データ取り込みを受け付け、CPU 間で負荷が分散されま す。 このデータ取り込み担当のサブシステムには、NonStop のコンポーネントとソースシステムのコンポーネン トが存在します。ソースシステム側では、メタデータが、NonStop テーブルと互換性があるフォーマットへの データの変換をサポートします。そして、その結果データファイルが FTP 経由で NonStop システムへと送信 され、処理されます。NonStop 側では、Pathway サーバーがそのファイルを受け取ってさらに妥当性検査 を実行し、そのデータをデータベースに挿入します。入力を処理するサーバーでは、プログラムによって FTP ベースのデータフィードを制御します。いくつかの基本的な整合性チェックが行われた後に、Pathsend 機能を使用して、レコードが専用のローセット挿入サーバークラスへと渡されます。データは、先頭の 2 つ のキーカラムと、通常はさらに DTG タイムスタンプカラムの順番に到着します。制約を介して DTG タイムス タンプカラムが時間によるスライスに使用され、このキー値の小さい順になるため、極めて効率的に挿入が 実行されます。 この手順全体を自動化することで、通常な状態では人的介入が不要になります。 時間スライスの測定基準は 2 週間のため、2 週間ごとにアクティブテーブルの新しいサイロが自動的に作 成されます。実行プランの最適化の精度を上げるために、以前に生成された統計が新しいテーブルのデー タベースメタデータに追加されます。この処理が行われないと、空あるいはほとんど空と判断されたテーブ ルに対してフルスキャンが実行される可能性があります。 アクティブなオンラインのテーブルセットには現行のサイロが含まれ、新しいデータはほぼすべて、このサイ ロが受け取ることになります。やや古いサイロは、クエリのため、および遅れて到着するデータを受け取る ために、内蔵ディスクに残ります。この時点でのブロックスプリットの発生は何としても回避したいため、現 行のサイロがより新しい時間スライスに置き換えられた段階で、FUP RELOAD によってそのテーブルが再 編成されます。 データは、設定された期間内はアクティブなテーブルセットに残ります。この段階で、その時間スライスのす べてのデータの取り込みが完了し、遅れて到着するデータは事実上存在しないものと考えられます。 12 ｢安定｣テーブルへのデータの投入 時間スライスが、アクティブなデータ取り込みフェーズを過ぎると、その時間スライスのすべてのデータは、 安定状態となり読み取りのみの XP ストレージ上のテーブルへと移動します。高度に並列化された処理によ って、このアクティブなテーブルとインデックスの 288 個のパーティションが、XP ディスク上の読み取りのみ が行われる 48 個のパーティションへと書き込まれます。このロード処理には、両方のデバイスで MX の最 大ブロックサイズ (32k) と新しい SQL/MX ユーティリティである FASTCOPY が使用されます。この処理に は通常、5 つのインデックスに対して 6 時間未満、2 つの実テーブルに対して 13 時間未満を要し、処理中 もシステムをクエリに利用できます。 最初のロード処理の後は、XP テーブルに対する挿入は発生しません。データ変更は発生しないので、いっ たんデータをコピーした後はバックアップの作成だけで十分であり、TMF のオンラインダンプは必要ありま せん。同様に、統計の更新やその他のメンテナンス作業 (再編成など) も、これらの読み取りのみのテーブ ルには必要ありません。 FASTCOPY ユーティリティ:FASTCOPY は SQL/MX の新しいユーティリティで、ソースとなるテーブルやイン デックスのすべてのローを、事前に作成されている同等のテーブルやインデックスにコピーします。可能で あればロー単位ではなくブロック単位でデータがロードされますが、このユーティリティには、高度な並列化 で実行される INSERT (SELECT *) と類似するメカニズムが組み込まれています。名前ではなく位置によっ てカラムが移動され、syskey 値は保持されます。 MX テーブルはすべてがオーディット対象ですが、ターゲットオブジェクトにはオーディットレコードは作成さ れません。ターゲットテーブル内の既存のローは、ソースデータが書き込まれる前に削除されます。これら の削除と後続の挿入のいずれについても、オーディットトレイルには記録されません。 FASTCOPY によって、ターゲットテーブル上のインデックスに、ソーステーブル上の対応するインデックスか ら、ダイレクトにコピーできるようになります。最も効率的なこのコピー処理はキー順に実行されるため、他 の方法では多くの場合に必要となるランダムアクセスの挿入やソート処理が FASTCOPY で発生することは ありません。FASTCOPY では、インデックスのダイレクトコピーを、基本テーブルのコピーと並行して実行で きます。 FASTCOPY ユーティリティでは、テーブルのパーミッションをチェックすることに加えて、すべてのインデック スがコピーされる前に基本テーブルが変更されていないことも検証されます。実テーブルが変更されていた 場合は、SQL/MX によってリカバリまたはキャンセルが強制されます。この場合には、処理のリスタートや その他の面倒な作業が必要になる場合もあります。 2 つのオプション: TABLE および INDEX をコマンド構文で使用できます。どちらの場合にも、ソースとターゲ ットのオブジェクトを指定する必要があります。TABLE オプションの場合は、テーブルのみ、またはテーブル とそのすべてのインデックスにデータを投入できます。INDEX オプションを使用すると、指定されたインデッ クスだけにデータが投入されます。今回のプロジェクトでは、テーブルとコピーを別々に (高速) コピーします。 この方法では、適切な速度を保ち、システムリソースに対する影響を細かく制御できます。 FASTCOPY ユーティリティの詳しい説明は、『SQL/MX Reference Manual』の第 5 章｢SQL/MX Utilities｣と 『SQL/MX Installation and Management Guide』の第 10 章｢Reorganizing SQL/MX Tables and Maintaining Data｣に記載されています。この演算子の使用例を、以下の URL の｢Features and Commands of NonStop SQL/MX for Release 2.3.3｣セクションからダウンロードできます。 http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=NSH-HELP-PROG ｢アーカイブ｣テーブルへのデータの投入 データのライフサイクルの 3 番目のフェーズは、1 年経過した段階の時間スライスから開始します。この段 階でデータをオフラインのストレージ (仮想/物理テープ) に移動可能となり、さらに 1 年間はそこに保存し ておく必要があります。ユーザーはこの 2 年目に、アーカイブデータをオンラインの状態にリストアするよう に依頼できます。現在、データベース内の 2 つのサイロがこの目的のために使用されています。広範にわ たりさまざまなデータを混在させることから、比喩的にサンドボックス (砂場) と呼ばれます。 多くのアプリケーションとは異なり、アーカイブデータをリストアできるようにすることは、今回のプロジェクト の正式な要件であり、｢あれば便利な｣機能でも緊急対応のための機能でもありません。この要件に対応で 13 きるように、内蔵 JBOD ディスクから XP ストレージへとデータを移動する場合と同じパーティション分割方法 を採用して、システム、アプリケーション、データベースを設計しました。ディスク領域も利用可能にしました が、これは、前述のサンドボックスがシステム設計に含まれていたためです。BR2 による高度な並列処理 が可能であることから、データのリストア時間に関する厳しい要件も満たします。テーブルとそのインデック スを別々にバックアップやリストアすることが可能で、パーティション分割されたデータベースオブジェクトは 並列で処理されます。並列化による柔軟性と時間スライスによるデータベース設計が一体になることで、実 テーブルなしではインデックスをリストアできないという制限を守れば、必要なデータを過不足なくリストアで きます。この方式において時間に関する要件が入念に検証され、予測可能で、条件を満たすことが実証さ れた結果、実際にはサイロがそのままの状態でリストアされています。必要なすべてのデータがリストアさ れていると言えます。 データベースへのクエリの実行 優れたデータベース設計とロード処理を実現できましたが、このプロジェクト全体が目指す目的はユーザー のクエリ処理です。 データベースへのユーザー接続 クエリという目的においては、システムは JDBC/ODBC データソースとしての役割を果たします。ユーザー は JDBC または ODBC 経由でデータベースに接続し、データアクセスのルールを強制する、サードパーテ ィのオフプラットフォームのツールからクエリを送信します。 ODBC および JDBC の両方のクライアントを制御する MXCS サブシステムには 3 つのサーバーデータソー スが構成され、それぞれが 3 種類のワークロードクラスのいずれかに適した優先度で動作します。このよう な構成によってエンドユーザーは、自分のクエリパターンや応答時間の要件に合わせて構成された MXCS サーバーのプールからデータベースに接続できるようになります。また、サポート担当者が、ユーザークラ スごとに実行優先度やその他のパラメーターをきめ細かく調整できるようにもなります。データソースレベル での変更は、その接続をとおして実行されるすべてのクエリに適用されます。通常はこれで良いのですが、 もちろん、特殊な状況や新しいユーザークラスのために追加のデータソースを定義することもできます。 当初は、3 つのデータソース/ユーザークラスをすべて同一に設定していました。各グループのクエリパター ンの詳細を把握できた段階で、全体の応答時間が向上するように調整を行いました。たとえば、2 つのユ ーザークラスで、エグゼキューターサーバープロセス (ESP) の並列処理を制御するパラメーター (CQD) を 変更しました。あるユーザークラスでは、ESP が関係するクエリがほとんど送信されたことがありません。そ こで、このユーザークラスの CQD を｢OFF｣に設定すると、並列プランを評価する必要がなくなったため、す べてのユーザーが満足できる応答時間を達成し、コンパイル時間も短縮されました。別のユーザークラス についても、別の理由から、同様の調整が行われました。並列プランを使用して実行されるクエリの数が膨 大であったために、複数の ESP プロセスの起動によるオーバーヘッドによって応答時間を悪化させていまし た。しかし、CQD を｢OFF｣に設定したことで、すべてのユーザーが受け入れられる応答時間が実現しました。 DP2 ラージブロック I/O 今回の壮大な規模のデータベースに対する事実上すべてのクエリは、多数のローを分析のためにクライア ントツールに返すことになり、検索エンジンによって処理されることはほとんどありません。そのため、基底 となるテーブルのスキャンや中間あるいは最終の結果セットの操作のいずれにおいても、すべての I/O プ ロセスに｢重労働｣が課されることになります。クエリで複数のサイロを使用する必要がある場合、その I/O 数は、UNION の 1 つのコンポーネントに対する I/O に、結果セットに含まれるサイロの数が掛け合わさ れた回数になります。ラージブロック I/O に対する DP2 の機能強化は、クエリの応答時間が顧客の要件を 満たす上で重要な役割を果たしました。 それ以外のさまざまな SQL/MX の機能強化がこのプロジェクトの成功に貢献しましたが、その中でも特筆 すべきなのが、制約ベースプルーニング、マルチユニオン機能、および OR ロジックの機能強化でした。 CBP の役割は、データベース設計のセクションで既に説明したとおりです。 マルチユニオン機能 マルチユニオン機能によって、アプリケーションが複数のテーブルからのユニオンを効率的に実行できるよ うになりました。マルチユニオンがクエリ実行で使用されるようにするためには、2 つ以上の UNION が必 14 要です。今回のプロジェクトでは、最大で 27 のユニオンが 1 つのユーザークエリに含まれていたため、こ の条件を難なくクリアしました (マルチユニオンの機能については、データベース設計の章で簡単に説明して います。また、詳細については技術的補足説明で説明します)。 OR ロジックの強化 OR ロジックが使用されるクエリでは、パフォーマンスの問題が頻繁に発生します。インデックスがないと、 すべてのローが検索され、OR 述部がエグゼキューターレベルで適用されます。このような動作は望ましい ことではないため、ターゲットカラムにインデックスを作成することで、応答時間の向上を図ります。ただし、 1 つのクエリで OR 述部を組み合わせて使用すると、改善策と思われたこの方法が裏目に出ることになり ます。 図 4 は、上記のシーケンスを図解したものです。テーブルのフルスキャンによって (1) 2 つのインデックス を作成することになりますが、これは、 (2) クエリ A と B をサポートするためのものです。3 番目の手順で、 クエリ C に注目します。最近の OR ロジックの強化がなければ、クエリ C (3) によってテーブルのフルスキ ャンが実行されることになります。一般的にこれは、データベースのサイズにかかわらず、望ましくないこと です。同程度、あるいはそれ以上に望ましくないのが、たった 1 回しか (あるいは滅多に) 実行されないクエ リのためだけにインデックスを作成することで、インデックスがむやみに増えてしまうことです。貴重なディス クスペースを余分に使用することになり、物理的な挿入から論理的な挿入へと変換する割合が高くなるた め、データ取り込みのパフォーマンスが悪化します。 図 4: OR ロジックの図 OR ロジックが強化されたことで、オプティマイザーがこのようなクエリをさまざまな形で変換できるようにな りました。この例では、クエリ C が、それぞれが既存のインデックスの 1 つを使用する 2 つの結果セット間 のユニオンへと変換されます。変換後のクエリ C は次のようになります。 select * from T where C2 = 1 UNION select * from T where (C4 = 5 OR 6) and C2 <> 1 実際に生成されるプランには統計が影響します。たとえば、カラム C2 には値 1 のローがほとんどないこと を統計から判断できる場合、ユニオンに関係する 2 つのクエリの 2 番目ではなく、ユニオンの位置の重複 を削除する方が、コストが低くなります。ORDER BY 句が含まれているかどうかも、この方法に影響します。 ここで重要なのは、関係するのが 1 つのインデックスではない OR 述部で、テーブルフルスキャンよりも有 効な多くのオプションをコンパイラが検討するようになったという点と、詳細やメリットの程度はそれぞれの 実装やクエリによって異なるものの、OR 最適化の強化のプラスの効果が、サイズにかかわらず、すべての MX データベースにもたらされるという点です。 15 クエリパフォーマンスの分析 1 日あたり数十万ものクエリが実行される場合、特定の応答時間目標を個々のクエリやクエリのバリエーシ ョンに対して設定することは、利用できるリソースが決まっていて不可能である状況を考えれば、厄介な目 標となるのが関の山で、非現実的であることも少なくありません。 これに対して、統計アプローチによって応答時間を測定、評価する方法は、現実的でもあり、効果的でもあ ります。今回は、1 日の実行サイクルの間に個々のクエリの応答時間を記録して、その実行サイクルの終 了時にそれぞれのクエリやクエリグループ (基本クエリとすべてのバリエーション) の統計プロファイル (平 均値、中央値など) を生成しました。この統計プロファイルは、顧客環境の実際の運用特性を表しており、1 日をとおしてクラスが異なるユーザーが入力する、頻度が異なる基本クエリの複数のバリエーションを表し ています。 このプロジェクトのクエリのテストシステムの設計と実装には細心の注意が払われましたが、それは、採用 するモデルが適切でなければテストの価値と有効性を証明できないためです。あらゆるタイプを網羅すると いう観点から、測定するクエリセットには、タイプごとに最小数のクエリが使用されました。さまざまなクエリ を混在させたことで、実際にユーザーが入力するクエリの実行割合が明らかになりました。このホワイトペ ーパーに考慮点のすべてを挙げることはしませんが、採用した要素としては、ユーザー/応答時間クラス、 クエリの数と種類、ピーク時とオフピーク時のクエリ到着割合などがあります。ソリューションの設計と評価 にあたっては、顧客のこの使用モデルを中核として、検証の方法論と準備が進められました。 データベース管理 200 テラバイト超のデータベース管理には、何人の DBA が必要でしょうか。実際の人数は、このアプリケ ーションの本番稼動が開始してある程度の時間が経過してみないと分かりませんが、おそらくその答えは、 ｢意外に少ない｣人数です。現段階では、その答えは、フォールトトレランスな体制を前提として 2 人以下に なると思われます。実際に、定型業務はすべて、データの取り込み処理を含めて自動化されます (前述の とおり)。 このように 1 桁台の人数ですむ理由には、2 つの側面があります。第一に、今回のアプリケーションとデー タベースは、NonStop アーキテクチャの基盤となる概念、すなわち、優れた並列ソフトウェア設計の基本概 念—同時実行性、スケーラビリティ、ローカル性、モジュール性を順守して設計されました。これらすべてが 調和することで、優れた設計にとって重要な簡潔性がもたらされます。 ただし、サードパーティやその他の各種ソフトウェアツールの開発者や実装担当者の方々の功績も大きい とも言えます。 テープ管理とビジネスコンティニュイティ テープに関する (あらゆる種類の) 作業と仮想テープから物理テープへのマイグレーションに使用すること を目的として、仮想テープシステム (VTS) ソリューションが採用されました。サードパーティのテープ管理ユ ーティリティがオフプラットフォームで動作し、テープインベントリをトラッキングします。日常のデータベース 管理で物理テープを使用しなければならない状況は現段階ではありませんが、システム管理/ビジネスコン ティニュイティの目的で使用される可能性があります。 おそらくは新規のアプリケーションであったために、現段階でアーカイブデータ用のオフサイトのテープスト レージはほとんどあるいはまったく存在しません。けれども、このプロジェクトの設計と要件の組み合わせが ビジネスコンティニュイティに興味深い効果をもたらすことが分かりました。 ビジネスコンティニュイティで中心的な役割を果たすのは、内蔵 (JBOD) ディスクに格納されるアーカイブデ ータです。クエリ処理の優に半数以上がアクティブデータだけを使用するものであり、当然ながら、データの 変更はアクティブサイロでのみ発生します。挿入時とテーブルのリロード時にオーディットレコードが生成さ れます。そのため、ビジネスコンティニュイティは、NonStop プラットフォームへの実装によって実現する堅 牢な可用性に大きく依存することになります。 サイロが XP ストレージに移動されれば、仮想テープまたは物理テープへとバックアップでき、データの変更 は発生しないため、｢オンライン｣でなければならない期間が満了するのを待つ必要はありません。すなわち、 安定しているサイロは、冗長性が確保されていれば XP 上に存在でき、同様に冗長性が確保されていれば 16 VTS システムにも存在できることになります。この段階で、仮想テープや物理テープ (オフサイトへの送信が 可能) の問題は、コスト/メリット/リスク評価の 1 つになります。 今回のプロジェクトに関連するデータの量を考えると、高可用性を備えたフォールトトレラントプラットフォー ムの支援なしには、ビジネスコンティニュイティの達成が困難でしょう。このプロジェクトの NonStop 設計で は、安定データには 2 つのタイプのストレージを、また、アクティブデータには TMF の機能を活用することで、 ビジネスコンティニュイティを実現します。 オーディットトレイル MX テーブルはすべてがオーディット対象ですが、アクティブテーブルに対してのみ、オーディットトレイルエ ントリが作成されます (データの取り込み時とリロード時)。安定データは FASTCOPY ユーティリティによって XP ストレージへと移動され、オーディットレコードは生成されず、安定データに対する更新は実行されませ ん。｢二次元｣の時間スライスによるデータベース設計を採用し、FASTCOPY ユーティリティを使用するため、 オーディットデータは、現在アクティブなサイロに対する処理とスケジューリングされているダンプのみで発 生します。 システムが並列構成のため、補助オーディットトレイルは CPU のグループに分かれて構成されており、シス テムでネットワークトランザクションを多用します。 高速統計 高速統計の強化について:どの程度高速なのか 288 パーティションに 35 億ローが格納されているテーブルに対して次のコマンドを実行したとします。 update statistics for table A on every key SAMPLE SET ROWCOUNT 3532800000; “B”について億単位のローカウント数、3,532,800,000 が処理され、1 時間 6 分で完了しました。拡張機 能である｢高速統計｣では、メッセージトラフィックが減少し、DP2 でローのサンプリングが発生するためにサ ンプリングプロセスの所要時間が短縮します。 また、ローカウント値が提供されることで統計生成でローカウントを数える部分がなくなり、サンプルサイズ が指定されない場合のデフォルトのサンプルサイズが 2 百万ローを超えないという点も重要です。このサ ンプルサイズは相対的にかなり小さいものですが、オプティマイザーは統計に反映されている絶対的な数 値よりもデータ分布のパターンを重視するため、データの歪みがない場合には小さいランダムサンプルで 十分です。 ただし、｢高速統計｣をさらに高速にする方法があります。SQL/MX の STATISTICS コマンドには、MX フォー マットのテーブルだけを対象とする、オプションの SAMPLE TABLE 句があります。このオプションには、さら に 2 つのサブオプションがあります。1 つ目は、SQL/MX がソーステーブルと同じパーティション数の一時 サンプルテーブルを作成できるようにするものです。もう 1 つは、以前に作成されたテーブルを使用するよ うに SQL/MX に指示するもので、そのテーブルはソーステーブルと同じパーティション数でなくても構いま せん。どちらの場合も、サンプルテーブルがパーティション分割されていることでサンプルデータの並列挿 入が可能になるため、完了までの経過時間が短縮されます。 ATC チームが、SQL/MX で作成したサンプルテーブル (288 パーティション) を使用してこれと同じ統計を 生成したときの経過時間は、18 分でした。CPU (48) ごとに 1 つのパーティションで作成されたユーザー定 義のテーブルの場合の経過時間は、9 分でした。テーブルが 48 個のパーティションに分割されていること から、処理が高速になるだけでなく、このデータベース内のいずれかのオンライン (アクティブまたは安定状 態) テーブルに利用あるいは再利用できることになります。 実際のところ、今はどのサイロの統計も同じです。したがって、オリジナルのコピーされた統計が変更され て特定のサイロ内の実際のデータ分布が反映されることはありません。サイロ間の統計のばらつきと、統 計が一定である場合と変動する場合の効果の違いがさらに明確になった段階で、統計が変更されることに なると考えられますが、その場合には、｢高速統計｣の機能強化が大きな役割を果たすことになります。 17 定期イベントの自動化 データベースの定期メンテナンスのほぼすべてが、ユーザーが作成したメンテナンスアプリケーションのフ レームワーク内で発生します。このメンテナンスアプリケーションは、今回のアプリケーションのワンストップ 管理ソリューションとして、ユーザーの運用環境に合わせて設計されたものです。このメンテナンスサブシス テムでは、NetBatch を使用してジョブをスケジューリングして実行し、｢トラッキング｣データベースを使用し てイベントとステータスを記録します。情報として参照する目的や問題解決の一部として、このデータベース の内容を表示できます。 大部分のデータベース管理作業は、内蔵の JBOD ディスクに格納されているアクティブデータを対象にしま す。サイロはここに出入りし、細分化されたテーブルが再編成され、最終的には XP ストレージへと移動され てオンラインダンプが取得されます。これに対して、XP は整然とした状態に編成された安定データを受け取 り、このデータはいずれかの段階で仮想テープへと移動されます。アップデートは起こらず、統計は変更さ れず、リロードは必要ありません。 データベース管理作業の自動化には、NetBatch と TACL のスクリプトが全面的に利用されており、日付パ ラメーターを取得した後に適切に実行されます。これらのデータ管理で特に重要な処理を、以下に示します。 NetBatch は、システム管理のさまざまな作業や、JDBC/ODBC クライアント環境外でのいくつかのクエリを 実行するためにも使用されます。 テーブルの再編成:FUP RELOAD が NetBatch にスケジューリングされていて、オフピーク時の指定した時 間枠の間に実行されます。リロード処理は時間ベースで開始、終了し、通常はプロセス全体が完了するま でに数日かかります。進捗状況がトラッキングデータベースに記録され、SQL クエリまたはこのプロジェクト のメンテナンスサブシステムから確認できます。毎回の実行の開始点を確認する場合にも、このトラッキン グシステムを使用します。 ビューのローテーション:時間の経過にともなってサイロが切り替わりますが、ユーザーのクエリは同じデー タウィンドウを参照します。これを可能にするのが、｢ビューのローテーション｣と呼ばれるスクリプト化された プロセスです。このスクリプトによって自動的かつ透過的に新しいサイロが作成され、ビューが調整され、こ のスプリプトの作業がトラッキングデータベースに記録されます。新しいサイロの作成時には、以前に生成 された統計を新しいテーブルのメタデータにコピーし、ビューの基底となるサイロの構成にかかわらず一定 のクエリプランが保たれるようにします。ビューのローテーションは、人的介入をともなわずに実行される NetBatch のジョブです。 XP ストレージへの FASTCOPY:適切に編成された安定データの XP ストレージへのマイグレーションも NetBatch ジョブとして実装され、その進捗状況がトラッキングデータベースに記録されます。 TMF オンラインダンプ:リカバリには人的介入は不要ですが、オンラインダンプが NetBatch に定期的にスケ ジューリングされています。オンラインダンプ処理は、トラッキングデータベースに記録されます。 BR2:BR2 はこれまでと同様に、完全に自動化されています。定期的なバックアップが NetBatch にスケジュ ーリングされていて、トラッキングデータベースに記録されます。リストアは、標準スクリプトをベースにして いますが、現段階では人的介入が必要で、トラッキングデータベースは使用しません。アーカイブデータが クエリのために｢オンデマンドで｣リストアされる機会が今よりも増えれば、この方法が変更されるかもしれま せん。 まとめ SQL/MX による超大規模データベースの設計と管理に関する説明は以上で終了です。データのロードと同 時にクエリの結果も数秒以内で返す 200 テラバイト超のデータベースの構築には、難しい論理が必要だっ たわけではありません。NonStop でのいつもどおりの手順を踏んだだけで、通常よりも規模が大きかった に過ぎません。 このソリューションは、スケーラビリティを備えています。すべての CPU が同じように使用され、スーパーク ラスターのすべての CPU に均等にデータが分散されます。このシステムの半分で今回のワークロードの半 分をサポートできるはずであり、テストしたわけではありませんが、システムを 2 倍にすれば 2 倍のワーク ロードを処理できるはずです。 18 このソリューションは、高可用性を備えています。NonStop アプリケーションであれば、すなわち高可用性 アプリケーションということになります。 このシステムは、優れたパフォーマンスを達成します。すべてのクエリタイプにおいて、顧客の指定した大 半が秒単位の応答時間内で実行されました。それと同時に、24 時間に 17 億 5 千万件の挿入、ピーク時 には 1 時間に 2 千万件のメッセージ (140 件の挿入) が発生しました。 これらが、このプロジェクトの｢大規模｣である部分です。そして、｢卓越した｣部分として挙げられるのが、マ ルチユニオン機能、OR 述部の変換、高速統計、FASTCOPY、制約ベースプルーニングを始めとする SQL/MX の機能強化で、これらによるメリットは、200 テラバイト以上のデータベースでなくてももたらされ るものです。 規模が大きく、高いパフォーマンスが要求されるにもかかわらず、このアプリケーションは正しく動作します。 これは、基底となる NonStop テクノロジーによるものです。また、データベースとそれに関連するプロセス に採用されている設計理念が、NonStop システムのアーキテクチャとこのアプリケーションのベースになっ ている並列ソフトウェア設計の原理に則っているためでもあります。そして、最終的には、200 テラバイト超 のデータベースを大人数の DBA によって管理しなくてもいいためです。 顧客のこれまでの経験からすると、解決不可能とも思える、途方もない難題が NonStop ATC チームに対 して提示されました。リアルタイムのデータのロード、クエリ、管理を同時に実行するというこの顧客の要求 をクリアできた会社はこれまで存在しませんでした。NonStop チームは、かつて経験したことのない高みに 向かって、また、200 テラバイトという記録とさらにいくつかの目標を達成することを目指して、顧客から課さ れた課題に全力で取り組みました。 この顧客の 200 テラバイトという目標を達成するために必要だったのは、難しい理論ではありませんでした。 NonStop 自体によって、目標を達成したのです。 技術的補足説明:マルチユニオン演算子と制約ベースプルー ニング この技術的な補足説明は、HP TSG ESS STSD Shared RD 部門の Sathyanarayanan Manamohan と Krishnaprasad Shastry によって発表された『A Method to Process Temporal Queries on Very Large Partitioned Data Sets』 (超大規模パーティション分割データセットに対する一時クエリの処理方法) をもとに 書かれています。 概要 マルチユニオンと CBP は、多くのデータウェアハウスや大量のデータセットを使用するアプリケーションに 共通する、パフォーマンスとリソース消費の問題を解決するために開発された機能です。 問題提議 データウェアハウスの拡大にともなって、システムの制限から、1 つの論理エンティティを表現するのに複数 のテーブルを使用しなければならなくなることも少なくありません。その場合には、論理エンティティをすべ てのテーブルのユニオンによって得られるビューで表すことができます。通常は、何らかの頻繁に検索で使 用される属性、たとえば、期間、地域、国などに基づいてデータが物理テーブルに分割されます。 しかしながら、従来はコンパイラがクエリとビューの基底となる個々のテーブルの内容の間の意味的関係を 特定する方法がありませんでした。クエリ結果の生成に必要となる有効なテーブルセットを推測できなかっ たため、ビュー内のすべてのテーブルを検査する必要がありました。さらに、ビューを構成する複数のテー ブルからのデータを結合する有効な方法がなく、そのために、システムの使用率が過剰になってしまうこと や、クエリの応答時間が許容範囲を超えてしまうことがありました。 19 NonStopソリューション NonStop SQL/MX はリリース 2.3.3 以降、クエリを書き換えることなくパフォーマンスを向上させるための 最適化技術を採用し、複数のテーブルやデータストリームを 1 つの手順にまとめる新しいマルチユニオン (n 項ユニオン) 演算子を発表しました。 制約ベースプルーニングは、利用可能な制約情報と対応する検索基準値を使用して、クエリで使用するテ ーブルセットを、結果に反映されるテーブルセットだけに制限します。 マルチユニオン (n 項ユニオン) 演算子によって、複数のデータストリームをまとめる効率的な方法が生ま れます。 この方法によって、マルチユニオン演算子のサブツリー全体が並列で実行できるため、超並列システムで のパフォーマンスが向上します。 NonStop以外のソリューション Oracle、IBM、Microsoft などのデータベース、アプリケーションサーバーの主要ベンダーは、制約を使用し て一部のクエリをプルーニングすることで、最適なクエリプランを作成しています。たとえば、Oracle では、 ｢チェック制約｣情報に基づくパーティションのプルーニングをサポートしています。 ただし、これらの商用データベースは、制約情報に基づくパーティションのプルーニングはサポートしていま すが、テーブルのプルーニングはサポートしていません。ベンダーによって、データベース内やアプリケー ションレベルでのクエリを書き換えることでパフォーマンス向上を図るいくつものチューニングテクニックが推 奨されています。テーブル数が増えれば書き換えも複雑になり、データベースを社内では管理できなくなっ てしまうことも考えられます。多くの場合、アプリケーションレベルでの書き換えは顧客に受け入れられない でしょう。 n 項ユニオン演算子をサポートしているデータベースやアプリケーションサーバーのベンダーは他にもいま す。たとえば、IBM WebSphere アプリケーションサーバーは、n 項ユニオン演算子とジョイン演算子をサポ ートしています。 HP が把握している限りでは、マルチユニオン演算子とプルーニングを一緒にサポートしている商用データ ベースはありません。 ある事例での一時パーティション分割 この新しい機能は、ある顧客が直面していたパフォーマンスに関する問題に対応するために開発されたも ので、その顧客は極めて大規模のデータセットを使用していました。その顧客の実際のデータは、わずか 1 年間で 250 テラバイトを超え、多数の超大規模テーブルの 830 億件のローに格納され、日付を基準にし て編成され、管理されています。ユーザーはすべてのテーブルの｢ユニオンされていない｣ビューを参照して いて、1 つの論理エンティティが物理的にはどのように分かれているのかを理解しておく必要がありました。 この顧客のクエリには一時述部 (“where x_date = constant-temporal-value”) が含まれていましたが、クエ リコンパイラはこの情報を使用して効率のよいクエリプランを生成することはできませんでした。 大量のデータがこの方法で編成されることも多く、その理由は、論理テーブル (ビューで表現される) を物理 テーブルに効率的にパーティション分割でき、それぞれに全体の特定のサブセットが格納される方法である ためです。データベース管理を簡単にできるようにするためだけにこの方法を採用することもありますが、 多くの場合は、必要な量のデータを格納するための選択肢が他にありません。日付属性に基づいてパーテ ィション分割されることが多いのは、データのライフサイクルやユーザーの検索パターンと日付属性が合致 していることによります。 これ以降の説明では、日付範囲と一時 (時間ベース) クエリについて取り上げます。ただし、この方法はここ で説明した方法だけに限定されるものではなく、また、日付属性を特別な方法で使用する必要もありません。 20 問題の特徴 論理エンティティが日付やその他の属性に基づいて物理テーブルに分割されているとすると、最初に表面 化する問題には、次のような特徴があります。 1 つの論理エンティティが多数のテーブルで構成されている テーブルに大量のデータが格納されている たとえば、1 年分に相当するトランザクションデータや実データが多数のテーブルに分割されていて、各テ ーブルに 1 週間分のデータが格納されており、52 個のテーブルで 1 年分のデータに対応するものとしま す。52 個のテーブルのそれぞれがとても大きく、数百ギガバイトが含まれているものとします。 これは、多くの大規模データベースによくみられる状況です。テーブルに基づくパーティション分割は、しば しば、データ量が 1 つのテーブルの容量超える場合や、必要となるパーティションが管理上の問題につな がる場合に使用されます。 ただし、データを物理的に分離する場合に利用される属性に関する以下の 2 つの特性も、マルチユニオン と CBP に影響します。 各テーブルを素集合として特定するための制約情報の存在 テーブルを制約するために使用されている同じ属性でクエリが結合されている データを編成するために使用されている属性によってクエリが結合されることが多いのに対し、データベー ス制約がクエリの結合に使用される頻度はあまり多くありません。おそらくその理由は、従来のコンパイラ ではデータベース制約を使用する有力な理由がほとんどなかったためです。そのような状況を理解するた めに、素集合の概念の説明が役に立つでしょう。 制約あるいは分割の情報のいずれかの形の明確な意味的情報が存在する場合、各テーブルが素集合で あると考えられます。つまり、その集合を構成する部分集合間に重なり合う部分がないということです。した がって、部分集合間の共通集合は空で、部分集合は相互に排他的です。これはクエリという観点からみる と、データを制約あるいは物理的に分離するために使用する属性の場合、その属性の特定の値が存在す るテーブルはその集合に 1 つだけであることを意味します。前述のように、日付はこの目的に適しており、 最もよく使用されている属性です。 この問題を図式化すると次のようになります。 21 図 5:関連するデータがテーブルの部分集合に置かれている場合の SQL/MX の処理 第1四半期の 販売データ SalesQuarter ビューの DDL: select * from Month1Week1 UNION ALL select * from Month1Week2 ... UNION ALL select * from Month3Week5 Month 1 Week 5 Month 1 Week 4 Month 1 Week 3 Month 2 Week 5 Month 1 Week 2 クエリ: Month 2 Week 4 Month 1 Week 1 Month 2 Week 3 select avg(sales) from SalesQuarter where date_col between ‘date-value of Month1Week2 begin’ and ‘date value of Month2Week 3 end’ .... Month 3 Week 5 Month 2 Week 2 Month 3 Week 4 Month 2 Week 1 Month 3 Week 3 Month 3 Week 2 色付きのテーブルが有効なデータセット Month 3 Week 1 図 5 に示すように結合されたクエリの結果を導き出す場合、以前のバージョンのクエリコンパイラでは、す べてのコンポーネントテーブルのユニオンが強制されていました。オリジナルのユニオン演算子 (これまで の唯一のユニオン演算子) では 2 項ユニオンだけが許されていたため、大きな 2 項ユニオンバックボーン が処理されることになります。この例では、この問題を 2 つの大きな兆候として捉えることができます。 1 つ目の問題は、クエリの応答時間です。このビューに対するクエリでは、いずれの場合もすべてのテーブ ルのスキャンが必要になりますが、その中の多くが結果には関係ないものである可能性があります。何も 得られないもののためにリソース (I/O および CPU) が費やされることになります。分離されているテーブル すべてを考慮する実行プランのコンパイルでは、さらに多くのリソースが費やされます。 2 つ目の問題は、これらのクエリに多くのリソースが使用されることから、システムの全体的なスループット が低下するという点です。 2 つの要素、すなわち、データセットのサイズとビューを構成するテーブルの数の拡大によって、問題が悪 化します。データボリュームがテラバイトを超えると、この問題はほとんど対処できないほどに深刻になりま す。テーブルの数が増えると、結果を導き出すのに必要となるユニオンバックボーンが深くなるため、問題 が深刻化します。 この問題は、データベース設計の不備によって発生するものではなく、テーブルパーティションを構成する ディスク数やサイズには常に制限があるために、複数のテーブルが存在することによります。別々の物理 テーブルを使用する場合、テーブルのパーティション数がとても多いことでメンテナンスや管理の面で問題 が発生しますが、ユニオンの数や 2 項演算子のシーケンシャル特性によって応答時間やリソース使用の 問題が生まれます。いくつかの問題の解決策によって、データベースを設計し直すことでは解決できない新 たな問題が発生します。 ソリューション このソリューションでは、クエリの処理に関する大きな問題を 2 つに分けて検討しました。 制約の情報と関連 (一時) 述部を使用してテーブルを除外することで、クエリを軽量化する マルチユニオン演算子を使用することでデータフローツリーの深度を浅くし、実行のオーバーヘッドを軽 減する このセクションのこれ以降では、上記の手順を詳しく説明します。 22 制約ベースプルーニング:制約情報を使用したテーブルの除外 コンパイラが、クエリのコンパイル時に既存のセマンティック情報 (カラムに対する制約という形で利用可能) を使用するようになりました。第 1 段階として、この情報を一時述部と一緒に使用して、あるテーブルによっ てクエリの一部となる結果が実際に生成されるのかどうかを判断します。述部の分析時に、あるテーブル やテーブルセットが意味論的に結果に貢献しないと判断されると、それらのテーブルがクエリプランから除 外されます。テーブルをローがない｢タプルリスト｣に置き換えることで、テーブルを除外します。｢タプルリス ト｣は、SQL では理論的なテーブルと同義です。 たとえば、週ごとの販売データが格納される 5 つのテーブルがあり、テーブル T1 にはその月の第 1 週の データが、テーブル T2 には第 2 週のデータが、というように保存されるとします。実際のテーブル数は関 係なく、この方法がテーブルの数によって制限されることはありません。これら 5 つのテーブルが、ユーザ ーには M1 という名前のビューとして提示されます。 次に、それぞれのテーブルに (ANSI SQL の) 制約が設定されていて、XDate という名前の日付属性に基 づいてテーブル内のデータが明確な分離間隔に制限されるものとします。 これらのテーブルの M1 ビューに対するクエリに一時述部が含まれている場合に、コンパイラが、その制約 と述部に指定されている値に基づいて、結果を生成できるテーブルとできないテーブルを判断できるように なりました。 たとえば、この 5 つのテーブルのビュー (M1) に対する次のクエリ (擬似コード) には、一時述部が含まれ ています。 select AVG (sales) from M1 where Region = “AP” and XDate between date “<value of M1.week2 begin>” and date “<value of M1.week4 end>”; 制約と一時述部のこの組み合わせによって、T1 と T5 (1 週目と 5 週目のデータ) からは結果が生成されな いことが分かります。コンパイラはこれらのテーブルのそれぞれをローがない｢タプルリスト｣に置き換えます。 この置き換えは、クエリツリーの整合性を維持する上で欠かせない処理です。将来的には、クエリツリーを 適切な形に直すことによって、このようなダミーのノードも不要になるはずです。 次の図は、この手順を図式化したものです。 図 6: 制約ベースプルーニングでは 必要なテーブルだけが検証される UNION UNION 制約に関する情報: T5 UNION T1-week1 / T2-week2 / T3-week3 / T4-week4 / T5-week 5 Ø UNION T4 T4 クエリ オプティ マイザー UNION UNION T3 T3 UNION UNION クエリ: T2 T1 select AVG (sales) from M1 where Region = “AP” and XDate between date “<value of M1.week2 begin>” and date “<value of M1.Week4 end>”; T2 Ø 23 マルチユニオン演算子:ユニオンバックボーンを圧縮してデータフローを削減 する単一の演算子 このソリューションの 2 番目のパートでは、クエリの長いユニオンバックボーンが 1 つの n ウェイ演算子に 圧縮されます。このような圧縮には、次のような理由があります。 データフローツリー内のデータコピーの量が少なくなります。ユニオンバックボーンにレベルが N 個ある とすると、テーブルの N 番目からデータが (N-1) 回コピーされます。この処理には、移動されるデータの 量が極めて多いと、データポインターだけがコピーされる場合であっても、かなりのコストがかかります。 N レベルのユニオンで最適なプランを探すためには、かなりの時間を要します。バックボーンが真の n ウ ェイ演算子に置き換えられたため、マルチユニオン演算子を使用することで、クエリのコンパイルに必要 となる時間とリソースが少なくなります。コンパイラは、ノードの大きなツリーよりも単一の演算子の方が、 はるかに簡単に処理できます。 この手順を図式化すると、次の図のようになります。真の n ウェイ演算子なしには、これらのメリットはもた らされません。 図 7: 2 項ユニオン演算子に代わるマルチユニオン (n ウェイ) 演算子 MULTI UNION UNION Ø T5 UNION 制約ベースプルーニングを 使用してユニオンバックボ ーンからマルチユニオン ノードを作成 T4 T4 UNION T3 T3 UNION T2 T2 Ø T1 この方法は、次の点を達成することで、上述の問題を解決します。 クエリのコンパイル時間短縮:コンパイラが、ノードの長いバックボーンではなく、1 つの演算子だけを処 理できるようになりました。また、不要なテーブルのプルーニングによって、最適化の複雑さが緩和され、 コンパイル時間が短縮されます。 プランの品質向上:コンパイラが検索スペースをより効果的に使用して、より良いプランを生成できるよう になりました。テーブルのプルーニングは、データアクセスの削減に貢献し、マルチユニオン演算子によ って、ツリーの階層が少なくなります。 優れた実行パフォーマンス:データフローのパスが短縮され、プランの品質が向上するため、クエリのあら ゆるパフォーマンスが向上します。 研究所とアーリーアダプターの協力によって、NonStop SQL/MX ソリューションのあらゆる飛躍的な機能 向上が証明されました。 24 詳細情報 Database tools & software http://h20223.www2.hp.com/NonStopComputing/cache/76708-0-0-0-121.html (英語) テクノロジーはビジネスのより良い成果のために © Copyright 2009 Hewlett-Packard Development Company, L.P. 本書の内容は、将 来予告なしに変更されることがあります。HP 製品およびサービスに対する保証は、当該 製品およびサービスに付属の保証規定に明示的に記載されているものに限られます。 本書のいかなる内容も、新たな保証を追加するものではありません。HP は、本書中の 技術的あるいは校正上の誤り、省略に対して責任を負いかねますのでご了承ください。 本書は、『Designing and managing very large databases with NonStop SQL/MX (4AA2-9588ENW, October 2009)』 (英語) をもとに加筆・修正して日本語で提供する ものです。