(57)【要約】【課題】データベースの問い合わせ処理を、効率的に分散処理すること。【解決手段】ストレージ３Ａに格納されるデータベース８に対する問い合わせの実行をノードに指示するデータベース管理方法であって、ノード４Ａが、問い合わせの入力を受け付け、入力された問い合わせを、並列に実行することができる単位である処理フェーズに分け、処理フェーズの特徴、および、処理フェーズを実行する時間における各ノードの稼動状況に基づき、問い合わせの処理フェーズを各ノードに分配することを特徴とする。【選択図】図１
2007199804.tif 000002
【特許請求の範囲】
【請求項１】
ストレージに格納されるデータベースに対する問い合わせの実行を複数のノードに指示するデータベース管理方法であって、
コンピュータが、
前記問い合わせの入力を受け付け、
入力された前記問い合わせを、並列に実行することができる単位である処理フェーズに分け、
前記処理フェーズの特徴、および、前記処理フェーズを実行する時間における各ノードの稼動状況に基づき、前記問い合わせの処理フェーズを各ノードに分配することを特徴とするデータベース管理方法。
【請求項２】
前記処理フェーズの分配は、各ノードにあらかじめ定められた使用目的、および、前記問い合わせの種別から特定される前記問い合わせの用途を比較することにより、前記処理フェーズの分配先となるノードを特定することを特徴とする請求項１に記載のデータベース管理方法。
【請求項３】
前記処理フェーズの分配は、前記稼動状況としてノードのＣＰＵ稼動率を参照し、ＣＰＵ負荷の高い前記処理フェーズを、ＣＰＵ稼動率の低いノードに分配することを特徴とする請求項１または請求項２に記載のデータベース管理方法。
【請求項４】
前記処理フェーズの分配は、前記稼動状況としてノードのＩＯ稼動率を参照し、ＩＯ負荷の高い前記処理フェーズを、ＩＯ稼働率の低いノードに分配することを特徴とする請求項１または請求項２に記載のデータベース管理方法。
【請求項５】
前記処理フェーズの分配は、単位時間あたりに処理可能なトランザクション数が少ないノードについては、前記稼働状況の更新頻度を低くすることを特徴とする請求項１ないし請求項４のいずれか１項に記載のデータベース管理方法。
【請求項６】
前記処理フェーズの分配は、前記稼動状況更新時刻からの経過時間が長いときよりも、経過時間が短いときには、前記稼動状況の更新頻度を低くすることを特徴とする請求項１ないし請求項４のいずれか１項に記載のデータベース管理方法。
【請求項７】
前記処理フェーズの分配は、前記問い合わせにおいて指定されたノードに対して、前記問い合わせの処理フェーズを優先的に分配することを特徴とする請求項１ないし請求項６のいずれか１項に記載のデータベース管理方法。
【請求項８】
前記複数のノードは、１つの共有ディスクに格納される前記データベースにアクセスして、前記問い合わせの処理フェーズを実行することを特徴とする請求項１ないし請求項７のいずれか１項に記載のデータベース管理方法。
【請求項９】
請求項１ないし請求項８のいずれか１項に記載のデータベース管理方法を、コンピュータに実行させるためのデータベース管理プログラム。
【請求項１０】
ストレージに格納されるデータベースに対する問い合わせの実行を複数のノードに指示するデータベース管理装置であって、
前記問い合わせの入力を受け付ける問い合わせ要求部と、
入力された前記問い合わせを、並列に実行することができる単位である処理フェーズに分ける問い合わせ解析部と、
前記処理フェーズの特徴、および、前記処理フェーズを実行する時間における各ノードの稼動状況に基づき、前記問い合わせの処理フェーズを各ノードに分配する処理分配部、
を有することを特徴とするデータベース管理装置。
【請求項１１】
請求項１０に記載のデータベース管理装置、前記問い合わせの処理フェーズを実行するノード、および、前記ノードから前記処理フェーズの処理結果を受け取り、前記問い合わせの要求についての処理結果を出力するクライアント装置を有することを特徴とするデータベース管理システム。
【請求項１２】
前記複数のノードは、ノードが着脱可能に構成されるブレードサーバに収容されることを特徴とする請求項１１に記載のデータベース管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース管理方法、データベース管理プログラム、データベース管理装置、および、データベース管理システムに関する。
【背景技術】
【０００２】
ＤＢＭＳ（DataBase Management System：データベース管理システム）は、データベースのデータに対する問い合わせに応えるシステムである。特に、データベースが表形式であるＲＤＢＭＳ（Relational DataBase Management System）が一般的である。データに対する問い合わせを記述した言語としては、ＳＱＬ（Structured Query Language）がよく使用される。
【０００３】
多くの問い合わせに対応するために、問い合わせの処理時間を短縮化することが求められている。そこで、従来は、問い合わせの処理を複数のフェーズに分け、各処理フェーズを複数のノード（計算機資源）に分配して、パイプライン処理など並列的な処理を行っていた。
【０００４】
なお、処理フェーズをどのノードに分配するかを決定する分配アルゴリズムが重要である。例えば、非特許文献１に記載された技術は、ＤＢＭＳのディクショナリに保管された、処理対象となる問い合わせに関する各種統計情報を基にして、各処理フェーズを分配していた。
【非特許文献１】Joel L. Wolf,John Turek, Ming-Syan Chen and Philip S. Yu著、“A Hierarchical Approach to Parallel Multiquery Scheduling”、IEEE Transactions on Parallel and Distributed Systems, 6(6):578--590, June 1995.
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、非特許文献１などに記載された従来の分配アルゴリズムでは、処理効率を充分に高めることはできなかった。例えば、問い合わせの処理フェーズを処理するための処理負荷を考慮して、問い合わせの処理を複数のノードに分配するだけでは、ノードの現在の処理負荷が考慮されていない。現在の処理負荷は、ノードが現在処理中の他のトランザクションなどにより発生している。
【０００６】
ノードの現在の処理負荷を考慮せずに処理フェーズを分配した結果、同一の処理負荷となる処理フェーズを、異なるノードに対して同時に分配しても、現在の処理負荷が処理フェーズの処理に影響するので、処理フェーズの終了時刻にばらつきがでる。よって、リソースに余裕のあるノードがあるにも関わらず、異なる問い合わせの処理が同一のノードに分配され、システムに存在する複数のノードを負荷が均等になるように利用することができなかった。
【０００７】
そこで、本発明は、前記した問題を解決し、データベースの問い合わせ処理を、効率的に分散処理することを主な目的とする。
【課題を解決するための手段】
【０００８】
前記課題を解決するため、本発明は、ストレージに格納されるデータベースに対する問い合わせの実行を複数のノードに指示するデータベース管理方法であって、コンピュータが、前記問い合わせの入力を受け付け、入力された前記問い合わせを、並列に実行することができる単位である処理フェーズに分け、前記処理フェーズの特徴、および、前記処理フェーズを実行する時間における各ノードの稼動状況に基づき、前記問い合わせの処理フェーズを各ノードに分配することを特徴とする。その他の手段は、後記する。
【発明の効果】
【０００９】
本発明によれば、各ノード間の稼動状況を考慮してフェーズを分配するので、各ノード間に稼動状況の偏りがなくなる。よって、データベースの問い合わせ処理を、効率的に分散処理することができ、ＤＢＭＳとして、問い合わせの処理の高速化を実現することができる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明する。まず、第１実施形態について、説明する。
【００１１】
図１は、本発明の第１実施形態であるＤＢＭＳの構成を示すものである。本実施形態では、ネットワーク９で接続された１台以上のクライアント１Ａ、クライアント１Ｂ、１台以上のブレードサーバ２、およびブレードサーバ２と接続されたストレージ３Ａで実現されている。ストレージ３Ａは、データベース８を有する。
【００１２】
クライアント１Ａは、問い合わせ要求部１０を有し、クライアント１Ｂには、ノード使用目的登録部２０を有する。ブレードサーバ２は、１台以上のノード４Ａを収容する。このノード４Ａは、ブレードサーバ２に対して着脱可能に構成されており、必要に応じてノード４Ａを追加することもできる。なお、近年のブレードサーバ２の登場と相まって、ハードウェア的なノードの構成変更が容易になってきており、ブレードの追加時や、取り外し時に、システムに存在するノードを有効に利用することができるソフトウェア技術が注目されている。
【００１３】
また、ノード４Ａが収容される先は、ブレードサーバ２に限定されることはない。例えば、ノード４Ａが棚に収容されてもよい。また、ノード４Ａは、物理的な計算機でもよいし、仮想計算機としてもよい。ノード４Ａが仮想計算機のときには、ブレードサーバ２の代わりに仮想計算機を実現するための物理的な計算機を用いる。
【００１４】
ノード４Ａは、問い合わせ解析部３０、処理分配部４０、問い合わせ実行部５０、ノード情報管理部７０、および、ノード稼動状況取得部６０を有する。
【００１５】
図２は、図１で示した構成の各要素をさらに詳細化したものである。
【００１６】
ノード使用目的登録部２０は、ユーザがシステムに存在するノードを使用する際の使用目的を登録可能なインタフェースを提供し、登録したノード使用目的をノード情報管理部７０に出力する。ノード稼動状況取得部６０は、ノード情報管理部７０の要求により、各ノードに問い合わせることで各ノードの稼動状況を取得し、ノードの稼動状況をノード情報管理部７０に出力する。ノード情報管理部７０は、ノード使用目的登録部２０から入力したノード使用目的、およびノード稼動状況取得部６０から入力したノード稼動状況をノード情報管理テーブル７１にて管理する。
【００１７】
問い合わせ要求部１０は、問い合わせ入力部１１および問い合わせ発行部１２を有する。問い合わせ入力部１１は、ユーザに問い合わせを入力させる。問い合わせ発行部１２は、問い合わせ解析部３０に対して、入力された問い合わせを通知する。
【００１８】
問い合わせ解析部３０は、構文解析部３１、問い合わせ用途予測部３２、および、処理フェーズ分割部３３を有する。構文解析部３１は、問い合わせ要求部１０から発行された問い合わせを構文解析する。構文解析とは、例えば、ＳＱＬの字句解析である。問い合わせ用途予測部３２は、問い合わせの用途を予測する。処理フェーズ分割部３３は、問い合わせの処理を複数ノードで並列に処理するために、複数の処理フェーズに分ける。
【００１９】
処理分配部４０は、処理フェーズ分配部４１を有する。処理フェーズ分配部４１は、問い合わせ解析部３０で分けた各処理フェーズを、各処理フェーズの特徴（処理付加情報など）およびノード情報管理部７０から取得したノード情報に基づいて各ノードに分配し、問い合わせ実行コードを分配先ノードの問い合わせ実行部５０に出力する。
【００２０】
問い合わせ実行部５０は、データ取り出し部５１、データ演算部５２、および、結果返却部５３を有する。データ取り出し部５１は、データベース８からデータを取り出す。データ演算部５２は、分配された問い合わせ実行コードを実行するために、問い合わせに指定された演算を行う。結果返却部５３は、演算結果をクライアントへ返却する。
【００２１】
図３は、ノード情報管理テーブル７１で保持する情報を示す。ノード情報管理テーブル７１は、システムに存在する全てのノードについて、稼動状況１１１、および、ノード使用目的１２１を保持する。稼動状況１１１は、処理分配部４０にて、問い合わせの処理の各フェーズを、主な用途１１２に従ってノードに分配する際に用いる。例えば、稼動状況１１１が「ＴＰＳ（Transaction Per Second：１秒（単位時間）あたりに処理可能なトランザクション数を表す）」であり、主な用途１１２が「ＴＰＳの低いノードについては、稼動状況の再取得を行わない」とは、処理分配部４０がＴＰＳというパラメータを参照することにより、ＴＰＳの低いノードについては、稼動状況の再取得を行わない旨を示す。
【００２２】
図４は、ノード情報管理テーブル７１で保持する情報を示す。ノード使用目的１２１は、処理分配部４０にて、問い合わせの処理の各フェーズを、処理対象となる問い合わせ１２２に従ってノードに分配する際に用いられる。例えば、ノード使用目的１２１が「オンライン業務」に設定されたときには、「ソート処理や結合処理の不要な、比較的処理負荷の低い問い合わせ」が処理対象となる問い合わせ１２２となる。
【００２３】
図５は、問い合わせ用途予測部３２における問い合わせ用途予測の条件を示す。問い合わせ用途予測部３２は、構文解析部３１の出力となる問い合わせの解析結果を入力として、問い合わせの特徴１３１に従って、問い合わせ用途１３２を出力する。例えば、問い合わせの特徴１３１が「問い合わせ実行予測コスト：小」であるときには、問い合わせ用途１３２が「オンライン業務」となり、同じ「オンライン業務」がノード使用目的１２１として設定されているノードに、その問い合わせが割り当てられる。
【００２４】
図６は、ノード情報管理部７０におけるノード使用目的登録の流れを示す。ノード情報管理部７０は、ノード情報管理テーブルが存在するか否かを判定し（Ｓ６０１）、ノード情報管理テーブルが存在しなければ（Ｓ６０１，Ｎｏ）、ノード情報管理テーブルを作成する（Ｓ６０２）。
【００２５】
次に、ノード情報管理部７０は、ノード使用目的をノード情報管理テーブルにノード使用目的を登録する（Ｓ６０３）。次に、ノード情報管理部７０は、ノード使用目的を登録したノードについて、ノード稼動状況を取得していないノードか否かを判定し（Ｓ６０４）、ノード稼動状況を取得していないノードであれば（Ｓ６０４，Ｙｅｓ）、ノード稼動状況を取得し、ノード情報管理テーブルにノード稼動状況を登録し（Ｓ６０５）、稼動状況更新時刻を登録する（Ｓ６０６）。一方、ノード稼動状況を取得しているノードであれば（Ｓ６０４，Ｎｏ）、処理を終了する。
【００２６】
図７は、ノード情報管理部７０におけるノード情報取得の流れを示す。ノード情報管理部７０は、ノード情報管理テーブルが存在するか否かを判定し（Ｓ７０１）、ノード情報管理テーブルが存在しなければ、ノード情報管理テーブルを作成する（Ｓ７０２）。
【００２７】
次に、ノード情報管理部７０は、着目しているノードについて稼動状況を取得していないノードか否か判定し（Ｓ７０３）、ノード稼動状況を取得していなければ（Ｓ７０３，Ｙｅｓ）、ノード稼動状況を取得し、ノード情報管理テーブルにノード稼動状況を登録し（Ｓ７０５）、稼動状況更新時刻をノード情報管理テーブルに登録する（Ｓ７０６）。このＳ７０６の登録処理により、Ｓ７０４でＮｏとなる情報がある場合、ノード稼動状況を取得するための、ノード間通信によるオーバーヘッドを削減できる。
【００２８】
また、ノード情報管理部７０は、稼動状況を取得していないノードではない（Ｓ７０３，Ｎｏ）、つまり、稼動状況を取得しているノードの場合についても、稼動状況更新時刻と現在時刻の差分から、（稼動状況更新時刻−現在時刻）＞（１／ＴＰＳ）の判定式によって、現在の状況を示した新しい情報であるかを判定する（Ｓ７０４）。
【００２９】
判定式を満たすときには（Ｓ７０４，Ｙｅｓ）、取得済みの稼動状況の情報は古いので、再取得が必要と判断する。ノード情報管理部７０は、前記の処理を、稼動状況を取得していないノードが存在しなくなるまで繰り返す（Ｓ７０７）。
【００３０】
図８は、処理フェーズ分配部４１が、問い合わせの各処理フェーズをノードに分配する処理を示す。処理フェーズ分配部４１は、ノード情報管理部７０から入力したノード情報をノード毎に参照し、ノード使用目的の処理対象となる問い合わせの処理フェーズか否かを判定する（Ｓ８０１）。
【００３１】
処理フェーズ分配部４１は、処理対象となる問い合わせの処理フェーズである場合（Ｓ８０１，Ｙｅｓ）、問い合わせ解析部３０における問い合わせ解析の結果に基づき、ＣＰＵ負荷の低い処理フェーズか否かを判定する（Ｓ８０２）。処理フェーズ分配部４１は、ＣＰＵ負荷が低い処理フェーズでない場合（Ｓ８０２，Ｎｏ）、ノード情報を参照しているノードが、ＣＰＵ稼動率の低いノードであるか否かを判定する（Ｓ８０３）。
【００３２】
処理フェーズ分配部４１は、ＣＰＵ負荷が低い処理フェーズである場合（Ｓ８０２，Ｙｅｓ）、または、ノード情報を参照しているノードが、ＣＰＵ稼動率の低いノードである場合（Ｓ８０３，Ｙｅｓ）は、ＩＯ負荷の低い処理フェーズどうかかを判定する（Ｓ８０４）。
【００３３】
処理フェーズ分配部４１は、ＩＯ負荷が低い処理フェーズでない場合（Ｓ８０４，Ｎｏ）、ノード情報を参照しているノードが、ＩＯ稼動率の低いノードであるか否かを判定する（Ｓ８０５）。処理フェーズ分配部４１は、ＩＯ負荷が低い処理フェーズである場合（Ｓ８０４，Ｙｅｓ）、または、ノード情報を参照しているノードが、ＩＯ稼動率の低いノードである場合（Ｓ８０５，Ｙｅｓ）は、ノード情報を参照しているノードを、処理フェーズの割当先のノードとして決定する（Ｓ８１０）。
【００３４】
処理フェーズ分配部４１は、ノード使用目的の処理対象とならない問い合わせの処理フェーズである場合（Ｓ８０１，Ｎｏ）、ＣＰＵ稼動率の低くないノードである場合（Ｓ８０３，Ｎｏ）、または、ＩＯ稼動率の低くないノードである場合は（Ｓ８０５，Ｎｏ）、参照していないノード情報が存在するか否かを判定する（Ｓ８０６）。処理フェーズ分配部４１は、参照していないノード情報が存在する場合（Ｓ８０６，Ｙｅｓ）、Ｓ８０１からの処理を繰り返す。参照していないノード情報が存在しない場合は、公知の技術により、処理フェーズを分配するノードを選択する（Ｓ８０７）。例えば、公知の技術では、ノードの稼働状況は考慮せずに、ランダムに処理フェーズを分配するノードを選択する。ランダムに分配することにより、負荷が分散することが期待される。
【００３５】
図９は、シェアードナッシング型アーキテクチャのＲＤＢＭＳで適用した場合のシステム構成を示す。ここで、ＤＢＭＳは、ブレードサーバ２に挿入された３枚のブレード（ノード４Ｂ、ノード４Ｃ、ノード４Ｄ）で稼動する。
【００３６】
クライアント１Ｃは、ネットワーク９を介して、ＤＢＭＳに対して、同一時間帯に、問い合わせを行うものである。大量のクライアント１Ｃが要求する問い合わせ１００Ａをノード４Ｂの問い合わせ実行部５０で実行しており、かつ、複数のクライアント１Ｄが要求する問い合わせ１００Ｂをノード４Ｃ、およびノード４Ｃの問い合わせ実行部５０で実行している時間帯に、クライアント１Ｅが要求する問い合わせ１００Ｃを、ノード４Ｂが受け付けたときの動作を説明する。
【００３７】
問い合わせ１００Ａ、および問い合わせ１００Ｂは、例えば以下の式１のようになる。
ＩＮＳＥＲＴ  ＩＮＴＯ  Ｔ１（Ｃ１，Ｃ２）  ＶＡＬＵＥＳ  （‘ＡＡＡ’，‘ＢＢＢ’）…（式１）
【００３８】
問い合わせ１００Ｃは、例えば以下の式２のようになる。
ＳＥＬＥＣＴ  Ｔ２．Ｃ１  ＦＲＯＭ  Ｔ２  ＯＲＤＥＲ  ＢＹ  Ｔ２．Ｃ２…（式２）
【００３９】
ノード４Ｂの問い合わせ解析部３０は、問い合わせ１００Ｃを、２つの処理フェーズに分ける。１つめの処理フェーズは、「ＳＥＬＥＣＴ  Ｔ２．Ｃ１  ＦＲＯＭ  Ｔ２」に対応するデータ取り出しフェーズ（ストレージ３Ｂに存在するデータベース８からデータを取り出すフェーズ）である。２つめの処理フェーズは、「ＯＲＤＥＲ  ＢＹ  Ｔ２．Ｃ２」に対応するデータマージフェーズ（列Ｔ２．Ｃ２に関するソート処理を行う）である。
【００４０】
以上、問い合わせ解析部３０が、問い合わせを、処理フェーズに分割する処理を説明した。なお、問い合わせ１００Ｃをもとにした本説明はあくまで一例であり、分割された処理フェーズは、データ取り出しフェーズおよびデータマージフェーズに限定されることはない。問い合わせ解析部３０は、さまざまな種別の処理フェーズを扱ってもよい。例えば、非特許文献１は、様々な問い合わせについて、処理フェーズに分割される一例を示している。また、問い合わせ解析部３０は、問い合わせを高速に処理することができる公知の技術（非特許文献１などを参照）を用いて問い合わせを処理フェーズに分割してもよい。
【００４１】
そして、問い合わせ解析部３０は、データ取り出しフェーズを、ストレージ３ＢへのアクセスのためのＩＯ負荷の高い（低くない）処理フェーズであると解析する。また、問い合わせ解析部３０は、データマージフェーズを、ソート処理を伴うＣＰＵ負荷の高い処理フェーズであると解析する。
【００４２】
次に、ノード４Ｂの処理分配部４０は、各処理フェーズをノードに分配する。そのために、ノード情報管理部７０は、ノード情報を取得し、ノード４Ｂのノード情報管理テーブル７１に登録する。ここで、ノード４Ｂは、問い合わせ１００Ａを大量に処理しているために、ＣＰＵ稼動率、およびＩＯ稼動率が高い。一方、ノード４Ｃ、ノード４Ｄは、問い合わせ１００Ｂを処理しているものの、ＣＰＵ稼動率が低く、またＩＯ稼動率も低い（図１３参照）。
【００４３】
ノード４Ｂの処理分配部４０は、ノード情報管理部７０から入力したノード情報を用いて、図８に示した処理分配の流れに従い、データ取り出しフェーズをノード４Ｃに分配し、データマージフェーズをノード４Ｄに分配する。これにより、問い合わせ１００Ａの処理負荷に影響を受けることなく、問い合わせ１００Ｃの処理は、ノード４Ｃ、およびノード４Ｃの問い合わせ実行部５０にて処理される。
【００４４】
以下、第２実施形態を説明する。図１０は、図９に示すシステム構成に示すリソースに対して、ノード４Ｅを追加した時のシステム構成を示す。なお、ノード４Ｄは、集計業務処理を実行するときの性能が図９に示すシステムでは不足しているために、追加されたノードである。よって、ＤＢＭＳは、ブレードサーバ２に挿入された４枚のブレード（ノード４Ｂ、ノード４Ｃ、ノード４Ｄ、ノード４Ｅ）で稼動する。このように、適宜ノード４Ｅをブレードサーバ２に追加することによって、ノード数を必要に応じて増減させることができ、設備コストを節約できる。
【００４５】
クライアント１Ｇは、図６に示したノード使用目的登録の流れに従い、システムに存在する全ノードのノード情報管理テーブル７１に対して、ノード４Ｄのノード使用用途１４１およびノード４Ｅのノード使用用途１４２として「集計業務」を登録する。ここで、クライアント１Ｃから、オンライン業務の問い合わせ１００ＡをＤＢＭＳに対して要求した場合の動作を説明する。
【００４６】
ノード４Ｂの問い合わせ解析部３０は、図５に示した条件に従って、問い合わせ１００Ａの問い合わせの用途をオンライン業務と判断する。ノード４Ｂの処理分配部４０は、ノード情報管理部７０から入力したノード情報（図１４参照）を用いて、図８に示した処理分配の流れに従い、問い合わせ１００Ａの各処理フェーズをノード４Ｂ、あるいは、ノード４Ｃに分配する。ここで、ノード４Ｂの処理分配部４０は、オンライン業務の問い合わせである問い合わせ１００Ａの処理負荷が、集計業務の処理性能に影響を与えないように、各処理フェーズを分配する。
【００４７】
次に、ここで、クライアント１Ｆから、集計業務の問い合わせ１００ＤをＤＢＭＳに対して要求した場合の動作を説明する。問い合わせ１００Ｄは、例えば以下の式３および式４のようになる。
【００４８】
ＳＥＬＥＣＴ  Ｔ３．Ｃ１…（式３）
ＳＵＭ（Ｔ３．Ｃ２）  ＦＲＯＭ  Ｔ３  ＷＨＥＲＥ  Ｔ３．Ｃ３＞＝‘２００５−０４−０１’  ＧＲＯＵＰ  ＢＹ  Ｔ３．Ｃ１  ＯＲＤＥＲ  ＢＹ  ２…（式４）
【００４９】
ノード４Ｂの問い合わせ解析部３０は、図５に示した条件に従って、問い合わせ１００Ｄの問い合わせの用途を集計業務と判断する。ノード４Ｂの処理分配部４０は、ノード情報管理部７０から入力したノード情報（図１４）を用いて、図８に示した処理分配の流れに従い、問い合わせ１００Ｄ（集計業務）の各処理フェーズをノード４Ｄ、あるいは、ノード４Ｅに分配する。
【００５０】
以降、処理フェーズを分配された各ノードは、クライアント１Ｇから、図６に示したノード使用目的登録の流れに従い、ノード使用目的に「指定なし」を登録するまでの間、集計業務の問い合わせを、その他のトランザクションの処理負荷に影響を受けることなく処理する。
【００５１】
以下、第３実施形態を説明する。第３実施形態は、あらかじめユーザが指定しておいたノードに、問い合わせの処理の各フェーズを分配することを特徴とする。これにより、問い合わせを行う際に、他のトランザクションの処理負荷による影響を意図的に抑えることができる。図１１は、図１０において、問い合わせを要求するユーザが、問い合わせを処理するノードを指定する場合のシステム構成を示す。
【００５２】
問い合わせ１００Ｄは、問い合わせ要求部１０（図２参照）を介してユーザから入力されたものである。この問い合わせ１００Ｄは、ユーザより、問い合わせを処理するノードとして、ノード４Ｄおよびノード４Ｅが明示的に指定されている。そして、クライアント１Ｆは、問い合わせ１００Ｄを受付の窓口的役割を担うノード４Ｂに送信する。
【００５３】
ノード４Ｂの処理分配部４０は、ノード情報管理部７０から入力したノード情報（図１５参照）を用いて、図８に示した処理分配の流れに従い、問い合わせ１００Ｄの各処理フェーズを明示的に指定されたノード４Ｃまたはノード４Ｄに分配する。
【００５４】
以下、第４実施形態を説明する。図１２は、第１実施形態をシェアードディスク型アーキテクチャのＲＤＢＭＳで適用した場合のシステム構成を示す。ここで、ＤＢＭＳは、ブレードサーバ２に挿入された３枚のブレード（ノード４Ｂ、ノード４Ｃ、ノード４Ｄ）で稼動する。シェアードディスク型アーキテクチャのシステム構成と異なる点は、ストレージ３Ｃ、データベース８、ノード情報管理テーブル７１を、複数のノードで共有していることである。このように、ＤＢＭＳのストレージ３Ｃを各ノードが共通に使用することにより、データベース８を集中管理することができ、管理コストを抑制できる。
【００５５】
ノード４Ｂの処理分配部４０は、問い合わせ１００Ｃの各処理フェーズをノードに分配する。そのために、ノード情報管理部７０は、ノード情報を取得し、ストレージ３Ｃのノード情報管理テーブル７１に登録する。ノード４Ｂは、問い合わせ１００Ａを大量に処理しているために、ＣＰＵ稼動率、およびＩＯ稼動率が高く、ノード４Ｃ、ノード４Ｃは、ＣＰＵ稼動率、およびＩＯ稼動率が低い（図１６参照）。
【００５６】
ノード４Ｂの処理分配部４０は、ノード情報管理部７０から入力したノード情報を用いて、図８に示した処理分配の流れに従い、データ取り出しフェーズをノード４Ｃに分配し、データマージフェーズをノード４Ｄに分配する。これにより、問い合わせ１００Ａの処理負荷に影響を受けることなく、問い合わせ１００Ｃの処理は、ノード４Ｃ、およびノード４Ｄの問い合わせ実行部５０にて処理される。
【００５７】
図１７〜図１８は、データベースシステムを構成する各装置のハードウェア構成を示す図である。図１７のクライアント１Ａ（他クライアントも同様）は、ＣＰＵ（Central Processing Unit）２０３、メモリ２０２、ＨＤＤ（Hard Disk Drive）２０４、および、ＮＩＦ（Network interface）２０５を備えたコンピュータである。ＣＰＵ２０３は、メモリ２０２に読み込まれたプログラム２０１を実行することで、図１に記載された各構成要素を実現する。
【００５８】
図１８のノード４Ａ（他ノードも同様）は、ＣＰＵ２１３、メモリ２１２、ＨＤＤ２１４、および、ＩＦ（interface）２１５を備えたコンピュータである。ＣＰＵ２１３は、メモリ２１２に読み込まれたプログラム２１１を実行することで、図１に記載された各構成要素を実現する。また、ＩＦ２１５は、ブレードサーバ２と着脱可能なインタフェースであり、ブレードサーバ２とのデータの送受信を仲介する。
【図面の簡単な説明】
【００５９】
【図１】本発明の第１実施形態に関するデータベース管理システムの概要を示す構成図である。
【図２】本発明の第１実施形態に関するデータベース管理システムを示す構成図である。
【図３】本発明の第１実施形態に関するノードの稼動状況とその主な用途を示す説明図である。
【図４】本発明の第１実施形態に関するノード使用目的とその処理対象となる問い合わせを示す説明図である。
【図５】本発明の第１実施形態に関する問い合わせの特徴と用途を示す説明図である。
【図６】本発明の第１実施形態に関するノード使用用途目的登録処理を示すフローチャートである。
【図７】本発明の第１実施形態に関するノード情報取得処理を示すフローチャートである。
【図８】本発明の第１実施形態に関する処理分配処理を示すフローチャートである。
【図９】本発明の第１実施形態に関するデータベース管理システムを示す構成図である。
【図１０】本発明の第２実施形態に関するデータベース管理システムを示す構成図である。
【図１１】本発明の第３実施形態に関するデータベース管理システムを示す構成図である。
【図１２】本発明の第４実施形態に関するデータベース管理システムを示す構成図である。
【図１３】本発明の各実施形態に関するノード情報管理テーブルを示す構成図である。
【図１４】本発明の各実施形態に関するノード情報管理テーブルを示す構成図である。
【図１５】本発明の各実施形態に関するノード情報管理テーブルを示す構成図である。
【図１６】本発明の各実施形態に関するノード情報管理テーブルを示す構成図である。
【図１７】本発明の各実施形態に関するデータベース管理システムのハードウェア構成を示す構成図である。
【図１８】本発明の各実施形態に関するデータベース管理システムのハードウェア構成を示す構成図である。
【符号の説明】
【００６０】
１Ａ〜１Ｇ  クライアント
３Ａ〜３Ｃ  ストレージ
４Ａ〜４Ｄ  ノード
２      ブレードサーバ
８      データベース
９      ネットワーク
１０    問い合わせ要求部
２０    ノード使用目的登録部
３０    問い合わせ解析部
４０    処理分配部
５０    問い合わせ実行部
６０    ノード稼動状況取得部
７０    ノード情報管理部
【図１】
2007199804.tif 000003
【図２】
2007199804.tif 000004
【図３】
2007199804.tif 000005
【図４】
2007199804.tif 000006
【図５】
2007199804.tif 000007
【図６】
2007199804.tif 000008
【図７】
2007199804.tif 000009
【図８】
2007199804.tif 000010
【図９】
2007199804.tif 000011
【図１０】
2007199804.tif 000012
【図１１】
2007199804.tif 000013
【図１２】
2007199804.tif 000014
【図１３】
2007199804.tif 000015
【図１４】
2007199804.tif 000016
【図１５】
2007199804.tif 000017
【図１６】
2007199804.tif 000018
【図１７】
2007199804.tif 000019
【図１８】
2007199804.tif 000020