JP5011006B2 - リソース割当方法、リソース割当プログラム、および、リソース割当装置 - Google Patents

Description

本発明は、リレーショナルデータベース管理システムに適したリソース割当方法、リソース割当プログラム、および、リソース割当を管理する管理サーバに関する技術である。

ＤＢＭＳ（DataBase Management System：データベース管理システム）は、データベースのデータに対する問合せに応えるシステムである。特に、データベースが表形式であるＲＤＢＭＳ（Relational DataBase Management System：リレーショナルデータベース管理システム）が一般的である。データに対する問合せを記述した言語としては、ＳＱＬ（Structured Query Language）がよく使用される。

多くの問合せに対応するために、問合せの処理時間を短縮化することが求められている。そこで従来は、問合せの処理を複数のＳＱＬ処理に分け、各ＳＱＬ処理を複数の計算機に分配して、パイプライン処理など並列に処理を行っていた。

なお、ＳＱＬ処理をどの計算機に分配するかを決定する分配アルゴリズムが重要である。例えば、非特許文献１に記載された技術は、ＤＢＭＳのディクショナリに保管された処理対象となる問合せに関する各種統計情報を基にして、各ＳＱＬ処理を分配していた。

また、非特許文献２には、データベースの処理負荷を複数の計算機に分散させ並列に実行するアーキテクチャが開示されている。非特許文献２に記載のShared everything, Shared disk（共用型）アーキテクチャでは、ＤＢ（データベース）処理を実行する全ての計算機が全てのデータをアクセスすることが可能である。

Shared nothing（非共用型）アーキテクチャでは、自計算機に接続されたディスクに格納されたデータのみアクセス可能である。非共用型アーキテクチャは、共用型アーキテクチャにくらべ、ＤＢ処理を実行する構成単位の間での共有リソースが少なく、スケーラビリティの点で非常に優れている。しかし、各計算機のデータに偏りがある場合、負荷が特定の計算機に偏ってしまい、偏りがなく効率的に並列実行できた時と比べて、処理のオーバヘッドが生じる。

そこで、特許文献１は、同一の計算機内に存在する複数の仮想的な計算機を構築し、計算機のＣＰＵリソースの情報から、計算機の資源の割り当てを行うことで負荷の平準化を行った。
特開２００５−５６３９１号公報 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. David DeWitt and Jim Gray著,"Parallel Database Systems:The Future of High Performance Database Systems",COMMUNICATIONS OF THE ACM, Vol.35, No.6,June 1992,P.85-P.98

分配アルゴリズムにより、ディスクにアクセスするＤＢアクセスサーバ（以下、ＢＥＳ：Back End Serverと表記する）のリソース（ＣＰＵおよびメモリ）の利用効率に大きく影響する。例えば、処理分配がうまくいかず、特定のＢＥＳに処理が集中してしまうと、他のＢＥＳは処理待ちとなってしまう。

つまり、リソースのアンバランスが発生してしまい、ＢＥＳのリソースを有効利用できない。特に、非共用型アーキテクチャは、処理待ちとなるＢＥＳが、アクセス対象のディスクを占有するため、リソースのアンバランスにより、処理のオーバヘッドが大きくなる。

そこで本発明では、前記した問題を解決し、各ＢＥＳへの各ＳＱＬ処理の実行時における負荷のアンバランスを改善することでＳＱＬ実行の高速化を行うことを主な目的とする。

前記課題を解決するために、本発明は、物理計算機上で稼動する仮想計算機で実行されるＢＥＳ（Back End Server）がアクセス可能である記憶装置に格納しているデータベースに基づいて、入力されたＳＱＬを処理するときに使用する物理計算機のリソース割当方法であって、
前記ＳＱＬ処理の対象となる前記データベースへのアクセス権は、それぞれの前記ＢＥＳが、接続する前記データベースに対してアクセスできる共用型アーキテクチャであり、
入力されたＳＱＬを構文解析して、前記ＳＱＬから１つ以上のＳＱＬ処理を抽出し、
前記抽出したＳＱＬ処理のうちの実行先の前記ＢＥＳが決定している前記ＳＱＬ処理を前記ＢＥＳで処理するのに必要な前記データベースのリソースコストをＳＱＬ処理に含まれる処理種別毎に計算し、
前記各ＢＥＳが前記ＳＱＬ処理を実行するために必要とする前記ＢＥＳ毎のリソースコストの比率に応じて、前記物理計算機のリソースを前記仮想計算機へ割り当てる割当率を決定し、
前記抽出したＳＱＬ処理のうちの実行先の前記ＢＥＳが決定していない前記ＳＱＬ処理の実行先として、前記実行先の前記ＢＥＳが決定している前記ＳＱＬ処理に対して前記決定した割当率が最も高い前記ＢＥＳを選択し、
リソースが割り当てられた前記仮想計算機で前記各ＢＥＳを実行し、前記ＳＱＬ処理を処理するように要求することを特徴とする。
その他の手段は、後記する。

本発明によれば、各ＢＥＳの各ＳＱＬ処理の実行時における負荷のアンバランスを改善し、その結果ＳＱＬの実行処理を高速化することができる。

以下、本発明の一実施形態であるＤＢＭＳについて、図面を参照しながら説明する。

図１は、ＤＢＭＳにおける、ＳＱＬ処理の実行例を示す説明図である。図１の（ａ）のＳＱＬは、ＳＱＬ処理に分割され、図１の（ｂ）または図１の（ｃ）に示すように各ＢＥＳに分配され、実行される。

図１（ａ）のＳＱＬは、以下に示すＳＱＬ処理分割される。なお、ＤＢＭＳは、このＳＱＬ処理を以下に示す順番で実行する。
・T1、T2のスキャン：「SELECT T1.C1 FROM T1,T2」から（T1,T2に存在するデータを取り出す）
・T1の条件評価：「T1.C1>1」から（取り出したデータが条件に該当するか否かを判定し、条件に該当する行だけに絞り込む）
・T2の条件評価：「T2.C1>2」から（取り出したデータが条件に該当するか否かを判定し、条件に該当する行だけに絞り込む）
・T1、T2の結合：「T1.C2=T2.C2」から（絞り込んだT1とT2のデータに対して、T1.C2=T2.C2に該当する行に対して結合処理を行う）

なお、T1の条件評価は、T1のスキャンの後に実行される。T2の条件評価は、T2のスキャンの後に実行される。T1、T2の結合は、T1の条件評価、および、T2の条件評価の後に、実行される。よって、T1の条件評価だけが完了し、T2の条件評価が完了していないときには、T2の条件評価が完了するまでの期間、同期のためのアイドル時間が発生する。

まず、図１（ｂ）は、本実施形態によるＣＰＵ割り当て、および、ＳＱＬ実行プランを示す説明図である。ＳＱＬ実行プランは、分割された各ＳＱＬ処理について、どのＢＥＳに、どのアルゴリズムで実行させるかを規定する。

ＢＥＳ「１」、ＢＥＳ「２」はそれぞれ異なるＢＥＳである。各ＢＥＳには、時系列に３つのＳＱＬ処理（スキャン→条件評価→結合）が割り当てられている。なお、「Ｔ１のスキャン（３３％）」は、「Ｔ１のスキャン」というＳＱＬ処理を実行するためのＣＰＵ割当率が、割り当て可能な全ＣＰＵ資源のうちの３３％であることを示す。このＣＰＵ割当率は、図４で詳細に説明するように、決定されている。

ＳＱＬ実行を行う前にＢＥＳ「１」に３３％、ＢＥＳ「２」に６７％のＣＰＵリソースを割り当てる。この割り当てたリソースを用いて（１）スキャン、および、（２）条件評価を行うと、ＢＥＳ「１」、ＢＥＳ「２」ともに、ほぼ同時に（１）スキャン、および、（２）条件評価の処理を終了する。これは、各ＢＥＳの計算が同時に終了するように、高精度の見積もり計算により計算されたＣＰＵ割当率により、バランスの取れたＣＰＵリソースが割り当てられているためである。

その後、図４で詳細に説明するように、ＢＥＳ「１」に６７％、ＢＥＳ「２」に３３％のＣＰＵリソースを割り当て直した上で、（３）結合を行う。高精度なＣＰＵ割当率により、並列実行した処理がほぼ同時に終わる。これにより、Ｔ１、Ｔ２の各データのデータ量に大きなばらつきがある場合でも、ＳＱＬの処理を効率よく並列実行でき、トータルの処理時間を短縮することができる。

一方、図１（ｃ）は、比較例によるＣＰＵ割り当て、および、ＳＱＬ実行プランを示す説明図である。各ＢＥＳには、互いに同じ量のＣＰＵリソースが割当てられており、その割当率は、時間が経過しても変更されず、５０％ずつである。

ＳＱＬ処理（１）スキャンを実行する際、各ＢＥＳのＣＰＵリソースは均等であり、「スキャン」というＳＱＬ処理の種別も同じである。しかし、ＳＱＬ処理の対象データであるＴ１，Ｔ２という各データのデータ量にばらつきがあり、Ｔ２のデータ量がＴ１のデータ量よりも多い。よって、各ＢＥＳがスキャンを終了する時刻にもばらつきが生じる。

Ｔ１のデータ量が少ないために、ＢＥＳ「１」は、（１）スキャンおよび（２）条件評価を早く完了してしまう。一方、Ｔ２のデータ量が多いために、ＢＥＳ「２」は、（１）スキャンおよび（２）条件評価を遅く完了してしまう。そして、ＢＥＳ「１」は、ＢＥＳ「１」の（２）条件評価を完了した時刻から、ＢＥＳ「２」の（２）条件評価が完了するまでの時刻の間、ＳＱＬ処理を実行しない空き時間（図中ではアイドル）が発生する。よって、この空き時間のために、ＢＥＳ「１」のリソースの使用率が悪い。

さらに、ＳＱＬ処理（３）を実行する際、ＢＥＳ「１」およびＢＥＳ「２」の間で分散して処理を行う。ここでも、各ＢＥＳで処理を行うデータ量にばらつきがあった場合、各ＢＥＳが結合を終了する時刻にもばらつきが生じる。その結果、先に（３）結合が終了したＢＥＳ「２」は、ＢＥＳ「１」の（３）結合の終了を待たなければいけないため、ＳＱＬ処理を実行しない空き時間（図中ではアイドル）が発生する。よって、この空き時間のために、ＢＥＳ「２」のリソースの使用率が悪い。

なお、非特許文献１によると、ＳＱＬ実行の高速化のためには、並列実行した処理が同時に終わることがよいとされている。しかしながら、図１（ｃ）の方式では、負荷のアンバランスの改善が十分ではなく、ＳＱＬ問合せ処理の高速化ができていない。

図２は、ＤＢＭＳ全体を示す構成図である。ＤＢＭＳは、データベースを使用するための指示情報であるＳＱＬ要求を入力し、データベースの内容を表示するための端末装置４１、端末装置４１からＳＱＬ要求を受け付ける要求受付サーバ４０（リソース割当装置）、および、要求受付サーバ４０からの指示に従いＳＱＬ処理を実行する要求実行サーバ４２とを含めて構成される。端末装置４１は、通信制御装置４３によってネットワークを介して、ＤＢＭＳ（ＦＥＳ）７０にＳＱＬ要求を送信する。

要求受付サーバ４０は、処理を実行するためのＣＰＵ４４、ネットワークを介して通信するための通信制御装置４３、および、各処理部を実現するためのプログラムを格納するメモリ４５を備える。メモリ４５には、ＯＳ４６、および、ＯＳ４６上で稼動するＤＢＭＳ（ＦＥＳ：Front End Server）７０が搭載され、ＣＰＵ４４を用いて稼動している。

ここで、ＦＥＳ（Front End Server）は、ＤＢＭＳ（ＦＥＳ）７０の一部分で、入力されたＳＱＬ要求を解釈し、ＳＱＬ実行プラン１３（図４参照）を作成し、ＢＥＳ５６（図３参照）に対してＳＱＬ実行プラン１３の実行要求を行う機能を担当する。ＤＢＭＳ（ＦＥＳ）７０は、端末装置４１から入力されたＳＱＬ要求を受け付けるＳＱＬ受付部４７、および、ＳＱＬ受付部４７が受け付けたＳＱＬ要求の処理対象となるデータの統計情報１６を集計する統計情報集計部８０を備える。

ＳＱＬ受付部４７は、ＳＱＬ構文解析部４８、統計情報取得部４９、コスト見積り部５０、リソース見積り部５１、リソース割当要求部６５、ＳＱＬ実行プラン作成部５２、および、ＳＱＬ実行要求部６４を備える。また、メモリには、リソース割当テーブル１５、統計情報１６のテーブル、処理コスト管理テーブル１７、リソース割当管理テーブル１８、および、コスト管理マスタテーブル２１が記憶されている。各処理部および各テーブルの詳細は、図４から図６において明らかにする。

図３は、図２の要求実行サーバ４２の詳細を示す構成図である。要求実行サーバ４２は、通信制御装置４３、ＣＰＵ４４、メモリ４５、および、メモリ５３を備える。メモリ５３には、リソース割当処理部５５を有するサーバ仮想化部５４、および、複数台（図では２台を例示）の仮想化サーバ６６（仮想計算機）を備える。

サーバ仮想化部５４は、同一の計算機内に存在する複数の仮想的な計算機を仮想化サーバ６６として構築し、リソースプールに確保されている計算機の資源であるＣＰＵ４４およびメモリ４５を、各仮想化サーバ６６に割り当てることで、各仮想化サーバ６６の負荷を平準化する。これにより、各仮想化サーバ６６はサーバ仮想化部５４によって割当てられたリソースを用いて稼動する。なお、メモリ４５、および、メモリ５３は例えばフラッシュメモリ、シリコンメモリなどにより実現される。

仮想化サーバ６６は、１つの物理的な計算機を分割することで、複数の論理的な計算機に見せかけるＬＰＥＲ（Logical Pertition）技術により実現される。ＬＰＥＲを実現するソフトウェアとして、例えばVMware社のVMware Serverがあげられる。また、仮想化サーバ６６は、物理的な計算機のＣＰＵ４４、および、メモリ４５を各仮想化サーバ６６で共有する。特許文献１で示されたように、これらのＣＰＵ４４、および、メモリ４５は、サーバ仮想化部５４のリソース割合処理によって各仮想化サーバ６６に任意の割合で割当てられる。

各仮想化サーバ６６は、ＯＳ４６と、ＢＥＳ５６を備え、磁気記憶装置などにより構成される外部記憶装置６０と接続されている。外部記憶装置６０は、ＤＢ格納領域６２，６３を管理している。ＢＥＳ５６「１」はＤＢ格納領域６２と直接接続されており、ＢＥＳ５６「２」はＤＢ格納領域６３と直接接続されている。そして、直接接続の関係を有するＢＥＳ５６のみが、接続先の各ＤＢ格納領域６２，６３へのアクセス権を有する非共用型アーキテクチャとしてもよいし、各ＤＢ格納領域６２，６３へのアクセス権が、複数のＢＥＳで共用される共用型アーキテクチャとしてもよい。

一方、すべてのＢＥＳ５６が、ＤＢ格納領域６２，６３へのアクセス権を有する共用型アーキテクチャとしてもよい。各ＢＥＳ５６は、統計情報取得部５７とＳＱＬ実行部５８を備えている。

なお、図２のＤＢＭＳ（ＦＥＳ）７０を、ＢＥＳ５６と別の計算機である要求受付サーバ４０に配置した。しかし、ＤＢＭＳ（ＦＥＳ）７０とＢＥＳ５６とを同一の計算機である要求実行サーバ４２に配置してもよい。さらに、ＤＢＭＳ（ＦＥＳ）７０を要求実行サーバ４２の仮想化サーバ６６に配置してもよい。

図４は、要求受付サーバ４０が実行するＳＱＬ要求の受け付け処理の概要を示す説明図である。図２を適宜参照して、説明する。なお、説明を簡潔にするためリソースの一例としてＣＰＵに着目して説明を行う。よって、各テーブル（統計情報１６、処理コスト管理テーブル１７、および、リソース割当管理テーブル１８）のメモリなどに関する列は、一部省略しているが、図５および図６において、その省略された列を説明することとする。

ＳＱＬ文１１は、構文解析されると、構文解析情報（ＳＱＬ処理）およびＳＱＬ処理が処理対象とする表の列情報が、それぞれ抽出される。統計情報格納領域６１は、表の列情報などの統計情報１６を格納する。

処理コスト管理テーブル１７は、統計情報１６から取得した件数などの統計情報、および、ＳＱＬ文１１から抽出された構文解析情報（ＳＱＬ処理）をもとに計算された、各ＢＥＳの処理件数を格納する。さらに、処理コスト管理テーブル１７は、各ＢＥＳの処理件数から計算された各ＢＥＳのＣＰＵコストを格納する。

リソース割当管理テーブル１８は、処理コスト管理テーブル１７に格納された各ＢＥＳのＣＰＵコストと、そのＣＰＵコストの比率に基づいて設定されるＣＰＵ割当率を、対応づけて格納する。リソース割当テーブル１５は、リソース割当管理テーブル１８のＣＰＵ割当率を、ＳＱＬ文１１から抽出されたＳＱＬ処理ごとに格納する。

リソース割当テーブル１５のＣＰＵ割当率をもとにＣＰＵ割り当て処理が、要求実行サーバ４２に対して行われた後、リソース割当テーブル１５のＳＱＬ処理をもとにＳＱＬ実行プランが、ＳＱＬ処理の実行要求として要求実行サーバ４２に対して送信される。

ＳＱＬ受付部４７は、ＳＱＬ文１１を受け付け、ＢＥＳ５６に対して実行要求を行い、最終的に端末装置４１に結果を返却する。

ＳＱＬ構文解析部４８は、受け付けたＳＱＬ文１１をＳＱＬの字句解析などの構文解析する。ＳＱＬ構文解析部４８は、ＳＱＬの処理を複数計算機で並列に処理するために、複数のＳＱＬ処理に分ける。ＳＱＬ構文解析部４８は、例えば、図１（ａ）のＳＱＬ要求を、（１）スキャン、（２）条件評価、および、（３）結合という３つのＳＱＬ処理に分ける。さらに、ＳＱＬ構文解析部４８は、ＳＱＬの構文を解析するだけではなくＳＱＬ文１１を処理するために必要な列の情報も分析する。

統計情報取得部４９は、図３の外部記憶装置６０に記憶されている統計情報格納領域６１から、ＳＱＬ文１１を処理するために必要な列情報を基にして、ＳＱＬ文１１を処理するために必要な列の統計情報１６を取得する。図４に示す統計情報１６は、ＢＥＳ毎に、表名、列名、件数、および、Ｉｎｄｅｘを対応づけて管理する。例えば、「＃１」のレコードは、表名「Ｔ１」には「２０００００」件のレコードが存在し、表名「Ｔ１」の列名「Ｃ１」には、高速にアクセスするためのインデクス（Ｉｎｄｅｘ）が付されていないことを示している。

コスト見積り部５０は、ＳＱＬ構文解析部４８により分けられた各ＳＱＬ処理に対して、統計情報取得部４９で取得した統計情報１６を元に、各ＢＥＳ５６の処理件数を見積もる。ここでの処理件数とは、各ＳＱＬ処理において、アクセスされるデータの件数の予測値をいう。

そして、コスト見積り部５０は、各ＢＥＳ５６の処理件数から、ＣＰＵコストを見積もる。ここでコストと呼んでいるものは、ＤＢＭＳが処理を行うために必要となるＣＰＵおよびメモリなどを数値化したものを表したものである。コストが高い数値になるほどより多くのＣＰＵ４４、メモリリソースが必要になる。

ここで、一部の結合、一部のソートなどの処理はある決められたＢＥＳで行う必要がない。そのため、コスト見積り部５０は、このある決められたＢＥＳで行う必要がないＳＱＬ処理に対して、この時点では実行を行うＢＥＳを未決定にしておく。これらの処理により、コスト見積り部５０は、処理コスト管理テーブル１７を作成する。

リソース見積り部５１は、処理コスト管理テーブル１７に記述された各ＳＱＬ処理のＣＰＵコストを参照して、ＣＰＵ割当率を決定する。ＣＰＵ割当率決定後、リソース見積り部５１は、コスト見積り部５０で、実行を行うＢＥＳ５６を未決定にしておいたＳＱＬ処理に対して、ＣＰＵ割当率、ＣＰＵコストから実行を行うＢＥＳ５６を決定する。その結果、リソース見積り部５１はリソース割当管理テーブル１８を作成する。

リソース割当要求部６５は、リソース割当管理テーブル１８を参照して、ＢＥＳ５６毎のＣＰＵ割当率を抽出することにより、リソース割当テーブル１５を作成する。リソース割当要求部６５は、リソース割当テーブル１５をリソース割当処理部５５に送信し、リソース割当要求を行う。

ＳＱＬ実行プラン作成部５２は、リソース割当テーブル１５を参照して、ＳＱＬ実行プラン１３を作成する。ＳＱＬ実行要求部６４は、ＳＱＬ実行プラン１３を各ＢＥＳ５６のＳＱＬ実行部５８に対して送信することでＳＱＬ実行要求を行う。リソース割当処理部５５は、リソース割当テーブル１５を参照して、ＣＰＵリソースの割当を行う。

要求実行サーバ４２のＳＱＬ実行部５８は、リソース割当処理部５５により割当てられたリソースを使用して、ＳＱＬ実行プラン１３に基づいてＤＢ格納領域６２，６３にアクセスして実行し、その結果を端末装置４１に返却する。

図５（ａ）は、統計情報１６の一例を示す。統計情報１６は、各ＢＥＳについて、図４で既に説明した列に加え、表名で示される表の容量が対応づけられている。インデクス（Ｉｎｄｅｘ）が「あり」のときは、実際に格納している値に直接アクセスする代わりに、そのインデクスを辿ることにより、実際に格納している値の詳細な分布状況がわかる。この分布情報から、条件評価したあとの件数がどの程度になるかの見積り精度を上げることができる。

インデクスを有する表へのスキャンの見積件数は、表に格納されたデータの件数に対して１００％の件数よりも減じることができる。これは、インデクスを手がかりにして、スキャンに必要な表のデータの格納位置がわかるため、表のデータを全てアクセスする方式（１００％）を用いなくても済むためである。しかし、インデクスは、特定の場合（ワイルドカード検索、後方一致検索など）には適用できないので、汎用性が下がる。

図５（ｂ）は、処理コスト管理テーブル１７の一例を示す。処理コスト管理テーブル１７は、ＳＱＬ処理ごとに、各ＢＥＳ５６のＣＰＵコスト、メモリコスト、処理件数、および、処理量を管理する。例えば、ＢＥＳ「１」は、（１）スキャンという種別のＳＱＬ処理が２０００００件分割り当てられることで、この割り当てられた２０ＧＢ分の処理量を消化するために、２０のＣＰＵコストと、４０のメモリコストを必要とする。また、実行するサーバが未決定のＳＱＬ処理の情報も同時に格納する。

図６（ａ）は、リソース割当管理テーブル１８の一例を示す。リソース割当管理テーブル１８は、ＳＱＬ処理ごとに、各ＢＥＳ５６のＣＰＵコスト、ＣＰＵ割当率、メモリコスト、メモリ割当率を管理する。各ＣＰＵコストおよびメモリコストは、処理コスト管理テーブル１７から取り出されたデータである。

図６（ｂ）は、コスト管理マスタテーブル２１の一例を示す。ＳＱＬ処理ごとに、ＣＰＵコストとメモリコストを算出するための情報を格納する。ＣＰＵコストを算出するための情報には、キーになる値と、その単位と、単位あたりの値（所定の係数）を格納する。メモリコストを産出するための情報にも同様に、キーになる値と、その単位と、単位あたりの値（所定の係数）を格納する。例えば、（１）スキャンというＳＱＬ処理を消化するのに必要なＣＰＵコストは、キーとなる値である処理件数の１件という単位あたり、０．０００１である。

図７は、ＳＱＬ受付部４７の処理手順を示すフローチャートである。

ＳＱＬ構文解析部４８は、ＳＱＬの処理要求を端末装置４１から受け取ると、処理要求として入力されたＳＱＬ文１１を構文解析し（Ｓ１０１）、問合せの処理を複数のＢＥＳ５６で並列に処理するために、複数のＳＱＬ処理に分ける。また、ＳＱＬ文１１を処理するために必要となる列の情報を作成する。

統計情報取得部４９は、Ｓ１０１で作成したＳＱＬ文１１を処理するために必要となる列の情報を元に、統計情報格納領域６１から、ＳＱＬ文１１を処理するために必要となる列の統計情報１６を取得する（Ｓ１０２）。

コスト見積り部５０は、ＳＱＬ文１１を処理するために必要となる列の統計情報１６を参照して、各ＢＥＳ５６における、各ＳＱＬ処理の処理コストを見積り（Ｓ１０３）、処理コスト管理テーブル１７を作成する。リソース見積り部５１は、処理コスト管理テーブル１７を参照して、各ＢＥＳ５６における、各ＳＱＬ処理のリソースを見積り（Ｓ１０４）、リソース割当管理テーブル１８を作成する。

リソース割当要求部６５は、処理コスト管理テーブル１７を参照して、各ＢＥＳ６６のリソース割当率を決定するリソース割当テーブル１５を作成して、サーバ仮想化部５４のリソース割当処理５５に送信して、リソース割当を要求する（Ｓ１０５）。

ＳＱＬ実行プラン作成部５２は、リソース割当テーブル１５を参照して、ＳＱＬ実行プラン１３（図４参照）を作成する（Ｓ１０６）。ＳＱＬ実行要求部６４は、Ｓ１０６で作成したＳＱＬ実行プラン１３をＢＥＳ５６に送信する（Ｓ１０７）。

図８は、コスト見積り部５０が実行するコスト見積り処理（Ｓ１０３）の処理手順を示すフローチャートである。

まず、処理コスト管理テーブル１７の選択していないＢＥＳを順に一つずつ選択するループ（Ｓ２０１〜Ｓ２０６）を実行する。次に、Ｓ２０１で選択したＢＥＳが実行するＳＱＬ処理のうち、選択していないＳＱＬ処理を順に一つずつ選択するループ（Ｓ２０２〜Ｓ２０５）を実行する。

そして、統計情報１６の件数を参照して、各ＳＱＬ処理の処理件数を算出し、処理コスト管理テーブル１７の処理件数に設定する（Ｓ２０３）。さらに、統計情報１６の容量を参照して、各ＳＱＬ処理の処理量を算出し、処理コスト管理テーブル１７の処理量に設定する（Ｓ２０４）。

まず、選択していないＢＥＳを順に一つずつ選択するループ（Ｓ２０７〜Ｓ２１２）を実行する。次に、Ｓ２０７で選択したＢＥＳが実行するＳＱＬ処理のうち、選択していないＳＱＬ処理を順に一つずつ選択するループ（Ｓ２０８〜Ｓ２１１）を実行する。

そして、処理コスト管理テーブル１７の処理件数を参照して、ＣＰＵコストを算出し、処理コスト管理テーブル１７のＣＰＵコストに設定する（Ｓ２０９）。さらに、処理コスト管理テーブル１７の処理量を参照して、メモリコストを産出し、処理コスト管理テーブル１７のメモリコストに設定する（Ｓ２１０）。

図９は、リソース見積り部５１が実行するリソース見積り処理の処理手順を示すフローチャートである。

まず、リソース割当管理テーブル１８の選択していないＢＥＳを順に一つずつ選択するループ（Ｓ３０１〜Ｓ３０８）を実行する。次に、Ｓ３０１で選択したＢＥＳが実行するＳＱＬ処理のうち、選択していないＳＱＬ処理を順に一つずつ選択するループ（Ｓ３０２〜Ｓ３０７）を実行する。

そして、処理コスト管理テーブル１７に設定したＣＰＵコストを参照して、以下の式によりＣＰＵ割当率を算出し（Ｓ３０３）、その算出結果によりＣＰＵ割当率を決定して、処理コスト管理テーブル１７に設定する（Ｓ３０４）。
・ＣＰＵ割当率＝ＣＰＵコスト÷（全てのＢＥＳにおけるＣＰＵコストの合計）

さらに、処理コスト管理テーブル１７に設定したメモリコストを参照して、以下の式によりメモリ割当率を算出し（Ｓ３０５）、その算出結果によりメモリ割当率を決定して、処理コスト管理テーブル１７に設定する（Ｓ３０６）。
・メモリ割当率＝メモリコスト÷（全てのＢＥＳにおけるメモリコストの合計）。

２つのループの完了後、Ｓ３０４で設定したＣＰＵ割当率、および、Ｓ３０６で設定したメモリ割当率から、未決定のＳＱＬ処理の処理を実行するＢＥＳ５６を決定する（Ｓ３０９）。

図１０は、処理コスト管理テーブルの処理件数および処理量を設定する処理手順を示すフローチャートである。

図１０（ａ）は、Ｓ２０３でＳＱＬ処理の処理件数を設定するフローチャートである。ＳＱＬ処理の種別に応じて、スキャン、条件評価、または、結合に分岐する（Ｓ４０１）。この３種類ではないときには、処理を終了する。

まず、ＳＱＬ処理がスキャンの場合（Ｓ４０１，スキャン）、統計情報テーブル１６から該当する列の件数を取得する（Ｓ４１１）。

次に、ＳＱＬ処理が条件評価の場合（Ｓ４０１，条件評価）、統計情報テーブル１６から該当する列の件数を取得し（Ｓ４２１）、条件評価の述語（図１（ａ）のＳＱＬ文では「＞」）に対応するヒット率「０．２」を取得する（Ｓ４２２）。そして、Ｓ４２１で取得した件数とＳ４２２で取得したヒット率とを乗算して、処理件数を算出する（Ｓ４２３）。

なお、条件評価の述語とそのヒット率との対応情報は、あらかじめ与えられた設定情報から取得する。この設定情報を作成するときには、条件評価の条件が厳しいものほど、ヒット率が小さくなるようにすることが、望ましい。例えば、所定値と同じ値だけがヒットする述語「＝（等しい）」は、所定値より大きいものがヒットする述語「＞（大なり）」よりも、条件が厳しいため、ヒット率を小さく（例えば、０．１）設定する。

そして、ＳＱＬ処理が結合の場合（Ｓ４０１，結合）、各ＢＥＳ５６における条件評価の処理件数を統計情報テーブル１６から取得し（Ｓ４３１）、取得した各ＢＥＳ５６における条件評価の処理件数を、各ＢＥＳ５６の結合の処理件数に決定する（Ｓ４３２）。

さらに、Ｓ４１１、Ｓ４２３、または、Ｓ４３２で決定した処理件数をコスト管理テーブルの該当する処理件数に設定し（Ｓ４４１）、処理を終了する。

図１０（ｂ）は、Ｓ２０４でＳＱＬ処理の処理量を設定するフローチャートである。ＳＱＬ処理の種別に応じて、スキャン、条件評価、または、結合に分岐する（Ｓ５０１）。この３種類ではないときには、処理を終了する。

まず、ＳＱＬ処理がスキャンの場合（Ｓ５０１，スキャン）、統計情報テーブル１６から該当する容量を取得する（Ｓ５１１）。

次に、ＳＱＬ処理が条件評価の場合（Ｓ５０１，条件評価）、統計情報テーブル１６から該当する容量を取得し（Ｓ５２１）、Ｓ４２２と同様にして条件評価の述語（図１（ａ）のＳＱＬ文では「＞」）に対応するヒット率「０．２」を取得する（Ｓ５２２）。そして、Ｓ５２１で取得した容量とＳ５２２で取得したヒット率とを乗算して、処理量を算出する（Ｓ５２３）。

そして、ＳＱＬ処理が結合の場合（Ｓ５０１，結合）、各ＢＥＳ５６における条件評価の処理量を統計情報テーブル１６から取得し（Ｓ５３１）、取得した各ＢＥＳ５６における条件評価の処理量を、各ＢＥＳ５６の結合の処理量に決定する（Ｓ５３２）。

さらに、Ｓ５１１、Ｓ５２３、または、Ｓ５３２で決定した処理量をコスト管理テーブルの該当する処理量に設定し（Ｓ５４１）、処理を終了する。

なお、Ｓ４３２，Ｓ５３２の処理コスト（ＣＰＵコスト、メモリコスト）の見積もり処理について、統計情報１６（図４参照）に記載されているデータをもとに計算する代わりに、ＤＢ格納領域６２，６３（図３参照）に格納されている各表のデータ内容をもとに計算してもよい。

例えば、複数の表のデータをＮ台のＢＥＳに分散させて結合を行う場合、ｉ台目（ｉ＝１〜Ｎ）に割り当てられるレコードは、複数の表の全てのデータのうち、複数の表で共通する列の値を、Ｎで除算した余りがｉ−１であるレコードとする。そして、ｉ台目に割り当てられるレコード数を集計することにより、処理件数および処理量を決定する。このように、表の概要を示す統計情報だけで見積もりを行う方式に比べ、表のデータ内容に踏み込んで見積もりを行う方式は、計算量が増える反面、高い精度の見積もりが可能となる。

図１１は、処理コスト管理テーブルのＣＰＵコストおよびメモリコストを設定する処理手順を示すフローチャートである。

図１１（ａ）は、Ｓ２０９でＣＰＵコストを設定するフローチャートである。まず、処理コスト管理テーブル１７から該当するＳＱＬ処理の処理件数を取得する（Ｓ６０１）。次に、コスト管理マスタテーブル２１から該当するＳＱＬ処理におけるＣＰＵコストの単位あたりの値を取得する（Ｓ６０２）。

そして、Ｓ６０１で取得した処理件数と、Ｓ６０２で取得したＣＰＵコストの単位あたりの値とを乗算することにより、ＣＰＵコストを算出する（Ｓ６０３）。Ｓ６０３で算出した値を処理コスト管理テーブル１７の該当するＢＥＳ５６のＳＱＬ処理のＣＰＵコストに設定する（Ｓ６０４）。

図１１（ｂ）は、Ｓ２１０でメモリコストを設定するフローチャートである。まず、処理コスト管理テーブル１７から該当するＳＱＬ処理の処理量を取得する（Ｓ７０１）。次に、コスト管理マスタテーブル２１から該当するＳＱＬ処理におけるメモリコストの単位あたりの値を取得する（Ｓ７０２）。

そして、Ｓ７０１で取得した処理量と、Ｓ７０２で取得したメモリコストの単位あたりの値とを乗算することにより、メモリコストを算出する（Ｓ７０３）。Ｓ７０３で算出した値を処理コスト管理テーブル１７の該当するＢＥＳ５６のＳＱＬ処理のメモリコストに設定する（Ｓ７０４）。

図１２は、実行サーバ未決定の処理のサーバを決定する処理手順を示すフローチャートである。

まず、リソース割当管理テーブル１８の選択していない（つまり、実行サーバが未決定か否かを判定していない）ＳＱＬ処理を順に一つずつ選択するループ（Ｓ８０１〜Ｓ８０６）を実行する。

次に、Ｓ８０１で現在選択しているＳＱＬ処理が未決定か否かを判定する（Ｓ８０２）。未決定でない場合は（Ｓ８０２，Ｎｏ）、Ｓ８０１で現在選択しているＳＱＬ処理についてのループを完了し（Ｓ８０６）、次のＳＱＬ処理を選択するため、Ｓ８０１に戻る。

Ｓ８０２でＹｅｓなら、リソース割当管理テーブル１８を参照し、ＣＰＵ割当率が最も高いＢＥＳ５６を取得する（Ｓ８０３）。そして、Ｓ８０３で取得したＢＥＳ５６を実行するサーバに決定する（Ｓ８０４）。

さらに、Ｓ８０４で決定したＢＥＳ５６を未決定の処理を実行するサーバであることを示すために、リソース割当管理テーブル１８の該当するＳＱＬ処理の処理コストをＳ８０４で決定したＢＥＳ５６に設定する（Ｓ８０５）。ここで、現在選択しているＳＱＬ処理についてのループを完了し（Ｓ８０６）、次のＳＱＬ処理を選択するため、Ｓ８０１に戻る。

以上説明した本実施形態によれば、ＳＱＬの実行を行う前にリソース割当率を変更することで、各ＢＥＳ５６においてＳＱＬの各処理実行時における負荷のアンバランスを改善することができる。これにより、リソース利用効率が上がることで、処理が早期に完了する。従って、ＳＱＬ処理を高速化することができる。

本発明の一実施形態に関するＤＢＭＳにおけるＳＱＬ処理の実行例を示す説明図である。 本発明の一実施形態に関するＳＱＬ要求の受け付け処理の概要を示す構成図である。 本発明の一実施形態に関するＤＢＭＳ全体を示す構成図である。 本発明の一実施形態に関するＤＢＭＳ全体のうちの要求実行サーバを示す構成図である。 本発明の一実施形態に関する統計情報、および、処理コスト管理テーブルを示す構成図である。 本発明の一実施形態に関するリソース割当管理テーブル、および、コスト管理マスタテーブルを示す構成図である。 本発明の一実施形態に関するＳＱＬ受付部の処理手順を示すフローチャートである。 本発明の一実施形態に関するコスト見積もり処理の処理手順を示すフローチャートである。 本発明の一実施形態に関するリソース見積り処理の処理手順を示すフローチャートである。 本発明の一実施形態に関する処理コスト管理テーブルの処理件数および処理量を設定する処理手順を示すフローチャートである。 本発明の一実施形態に関する処理コスト管理テーブルのＣＰＵコストおよびメモリコストを設定する処理手順を示すフローチャートである。 本発明の一実施形態に関する実行サーバ未決定の処理のサーバを決定する処理手順を示すフローチャートである。

符号の説明

１１ ＳＱＬ文
１３ ＳＱＬ実行プラン
１５ リソース割当テーブル
１６ 統計情報
１７ 処理コスト管理テーブル
１８ リソース割当管理テーブル
２１ コスト管理マスタテーブル
４０ 要求受付サーバ
４１ 端末装置
４２ 要求実行サーバ
４３ 通信制御装置
４４ ＣＰＵ
４６ ＯＳ
４７ ＳＱＬ受付部
４８ ＳＱＬ構文解析部
４９ 統計情報取得部
５０ コスト見積り部
５１ リソース見積り部
５２ ＳＱＬ実行プラン作成部
５４ サーバ仮想化部
５５ リソース割当処理部
５６ ＢＥＳ
５８ ＳＱＬ実行部
６０ 外部記憶装置
６１ 統計情報格納領域
６４ ＳＱＬ実行要求部
６５ リソース割当要求部
６６ 仮想化サーバ
７０ ＤＢＭＳ（ＦＥＳ）
８０ 統計情報集計部

Claims (10)

1. 物理計算機上で稼動する仮想計算機で実行されるＢＥＳ（Back End Server）がアクセス可能である記憶装置に格納しているデータベースに基づいて、入力されたＳＱＬを処理するときに使用する物理計算機のリソース割当方法であって、
   前記ＳＱＬ処理の対象となる前記データベースへのアクセス権は、それぞれの前記ＢＥＳが、接続する前記データベースに対してアクセスできる共用型アーキテクチャであり、
   入力されたＳＱＬを構文解析し、前記ＳＱＬから１つ以上のＳＱＬ処理を抽出し、
   前記抽出したＳＱＬ処理のうちの実行先の前記ＢＥＳが決定している前記ＳＱＬ処理を前記ＢＥＳで処理するのに必要な前記データベースのリソースコストをＳＱＬ処理に含まれる処理種別毎に計算し、
   前記各ＢＥＳが前記ＳＱＬ処理を実行するために必要とする前記ＢＥＳ毎のリソースコストの比率に応じて、前記物理計算機のリソースを前記仮想計算機へ割り当てる割当率を決定し、
   前記抽出したＳＱＬ処理のうちの実行先の前記ＢＥＳが決定していない前記ＳＱＬ処理の実行先として、前記実行先の前記ＢＥＳが決定している前記ＳＱＬ処理に対して前記決定した割当率が最も高い前記ＢＥＳを選択し、
   リソースが割り当てられた前記仮想計算機で前記各ＢＥＳを実行し、前記ＳＱＬ処理を処理するように要求することを特徴とする
   リソース割当方法。
2. 前記データベースのリソースコストを計算する工程の後、さらに、前記データベースのリソースコストをもとに、前記データベースに接続される前記ＢＥＳを実行する前記仮想計算機毎のリソースコストを計算することを特徴とする
   請求項１に記載のリソース割当方法。
3. 前記データベースのリソースコストを計算する工程は、前記ＳＱＬ処理の種別が「スキャン」のときには、前記ＳＱＬ処理の対象となる前記データベースの件数と、所定の係数とを乗算することにより、前記リソースコストを計算することを特徴とする
   請求項１または請求項２に記載のリソース割当方法。
4. 前記データベースのリソースコストを計算する工程は、前記ＳＱＬ処理の種別が「条件判断」のときには、前記ＳＱＬ処理の対象となる前記データベースの件数と、ＳＱＬ命令に含まれる述語の種別に対応するヒット率と、所定の係数とを乗算することにより、前記リソースコストを計算することを特徴とする
   請求項１または請求項２に記載のリソース割当方法。
5. 前記データベースのリソースコストを計算する工程は、前記ＳＱＬ処理の種別が「結合」のときには、結合した結果前記各ＢＥＳに割り当てられる前記ＳＱＬ処理の対象となる前記データベースの件数と、所定の係数とを乗算することにより、前記リソースコストを計算することを特徴とする
   請求項１または請求項２に記載のリソース割当方法。
6. 前記仮想計算機に割り当てられる前記物理計算機のリソースは、前記物理計算機のＣＰＵであることを特徴とする請求項１または請求項２に記載のリソース割当方法。
7. 前記仮想計算機に割り当てられる前記物理計算機のリソースは、前記物理計算機のメモリであることを特徴とする請求項１または請求項２に記載のリソース割当方法。
8. 請求項１ないし請求項７のいずれか１項に記載のリソース割当方法を、計算機に実行させるためのリソース割当プログラム。
9. 物理計算機上で稼動する仮想計算機で実行されるＢＥＳ（Back End Server）がアクセス可能である記憶装置に格納しているデータベースに基づいて、入力されたＳＱＬを処理するときに使用する物理計算機のリソースを割当てるリソース割当装置であって、
   前記ＳＱＬ処理の対象となる前記データベースへのアクセス権は、それぞれの前記ＢＥＳが、接続する前記データベースに対してアクセスできる共用型アーキテクチャであり、
   入力されたＳＱＬを構文解析し、前記ＳＱＬから１つ以上のＳＱＬ処理を抽出するＳＱＬ構文解析部と、
   前記抽出したＳＱＬ処理のうちの実行先の前記ＢＥＳが決定している前記ＳＱＬ処理を前記ＢＥＳで処理するのに必要なデータベースのリソースコストをＳＱＬ処理に含まれる処理種別毎に計算するコスト見積り部と、
   前記各ＢＥＳが前記ＳＱＬ処理を実行するために必要とする前記ＢＥＳ毎のリソースコストの比率に応じて、前記物理計算機のリソースを前記仮想計算機へ割り当てる割当率を決定するリソース見積り部と、
   前記抽出したＳＱＬ処理のうちの実行先の前記ＢＥＳが決定していない前記ＳＱＬ処理の実行先として、前記実行先の前記ＢＥＳが決定している前記ＳＱＬ処理に対して前記決定した割当率が最も高い前記ＢＥＳを選択し、
   リソースが割り当てられた前記仮想計算機で前記各ＢＥＳを実行し、前記ＳＱＬ処理を処理するように要求するＳＱＬ実行要求部と、を有することを特徴とする
   リソース割当装置。
10. 前記コスト見積り部は、前記データベースのリソースコストを計算する工程の後、さらに、前記データベースのリソースコストをもとに、前記データベースに接続される前記ＢＥＳを実行する前記仮想計算機毎のリソースコストを計算することを特徴とする
    請求項９に記載のリソース割当装置。

Images