JP4801761B2

JP4801761B2 - データベース管理方法およびシステム並びにその処理プログラム

Info

Publication number: JP4801761B2
Application number: JP2009186956A
Authority: JP
Inventors: 裕紀杉本
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2009-08-12
Filing date: 2009-08-12
Publication date: 2011-10-26
Anticipated expiration: 2029-08-12
Also published as: US8346744B2; JP2011039800A; US20140019430A1; US20110040725A1

Description

本発明は、データベース管理技術に関わり、データベース管理システム(DBMS)に広く適用することができる。

従来、特許文献１に開示されているような技術が利用され、データベース処理要求に対して、CPUリソースを動的に割り当てて実行するような処理が行われる。

また、近年大規模分析のニーズ増大に伴い、特許文献２に開示されているような技術が利用され、データベース管理システム内部でプロセスやスレッドなどのリソースを多数利用して並列処理することで、処理を高速化する技術が必要とされている。

さらに、データベース管理システムのインデクスの作成やデータ挿入、更新などのデータ操作についても、ユーザやアプリケーションからのひとつの処理要求に対して並列に処理を行うことで処理を高速化する技術も広まっている。

特開2007-249468号公報特開2007-34414号公報

このような処理ではプロセスやスレッドなどのリソースを多数使用する必要があるが、例えば記憶装置の入出力性能によっては、いくら多数のリソースを割り当ててもそれ以上性能が上がらなくなる状態が存在する。このような状態で多くのリソースを割り当てても、例えばプロセスやスレッドの場合、プロセスやスレッドの切り替えなどにかかるコストが増大し、一定数以上増やしてもかえって性能が劣化する場合がある。

また、オペレーティングシステムなどのシステム全体には、使用できるリソースの上限値があることが一般的であり、複数の処理要求が実行された場合に、最初に実行された処理要求がシステムの上限までリソースを使用してしまうと、次の処理要求に必要なリソースが十分に割り当てられず、低い性能しか出せない場合がある。

一方、データベース管理システムにおいて、例えば格納されているデータに対するアクセスごとにスレッドを作成してアクセスする場合を考えると、データが少ない場合には少数のスレッドでアクセスすることができる。つまり、最適なプロセスまたはスレッド数で動作するためには、プロセスまたはスレッド数の上限値を決定することが重要である。

本発明の目的は、記憶装置などのハードウェアの構成や処理要求の内容に応じて、処理要求ごとに適切なリソース数の上限を設定することにより、処理性能を向上発揮することにある。

本発明は、
データの問い合わせである処理要求を受け付ける処理要求受付処理部と、
データを記憶するデータベースを格納する格納領域が配置される補助記憶装置と、
前記受け付けた処理要求を解析し、該解析の結果に基づいて前記複数のデータ操作を行うデータ操作実行処理部と、
生成されたプロセスやスレッドに割り当て当てられる前記データ操作のそれぞれを管理するリソース管理処理部と、
前記データ操作を行った際に前記データ操作の対象となるデータを前記補助記憶装置から前記メモリ上にキャッシュし前記データ操作の対象となるデータがキャッシュ上に存在するかどうかを判別するバッファ管理処理部とを有し、
さらに、前記データ操作実行処理部は、前記データ操作を実行する際に、
前記バッファ管理処理部による判定が前記キャッシュ上にデータが存在するか否かを判断し、
前記キャッシュ上にデータが存在しない場合は、
当該データ操作における前記プロセス数や前記スレッド数の空きの判断を前記リソース管理部により行い、
前記プロセス数や前記スレッド数が空いている場合は前記プロセスや前記スレッドに前記データ操作を実行するために、前記実行したデータ操作の処理対象となるデータをメモリ上にキャッシュするためのアクセス要求を前記補助記憶装置に送り、
前記プロセス数や前記スレッド数の該空きがない場合は該空いた後前記データ操作を実行し、前記キャッシュ上にデータが存在する場合は、前記データ操作を実行することによって課題を解決するものである。

本発明によって、データベース管理システム内で一つの処理要求に割り当てるリソース上限を設定することによって、効率的なリソース利用が可能となる。

本発明の処理要求毎リソース数決定処理部を説明するための概念図である。本発明の実施形態に係るコンピュータシステムの概略構成を示す図である。処理要求毎リソース数決定処理部の詳細を説明するためのフローチャートである。スキーマ定義情報を説明するための概念図である。ストレージ構成情報を説明するための概念図である。ストレージ装置の階層が複雑化した場合のストレージ構成情報を説明するための概念図であるスキーマとストレージ構成のマッピング情報を説明するための概念図である。ストレージ構成情報として、I/O性能を用いた場合の処理要求毎リソース数決定処理部の詳細を説明するためのフローチャートである。 I/O性能をストレージ構成情報として扱った場合のストレージ構成情報の例を説明する概念図である。結合処理における操作対象テーブルごとのリソース数を割り当てる処理について説明するためのフローチャートである。ディスクへのI/Oを伴う操作などを実行するデータ操作実行処理部を説明するためのフローチャートである。基準リソース数とディスク装置の対応表を説明するための概念図である。性能統計情報を説明するための概念図である。結合処理におけるリソース数割り当ての効果を説明するための概念図である。結合処理における結合順を考慮したリソース数割り当てを説明するためのフロー図である。結合順係数管理表を説明するための概念図である。

本発明の実施の形態について、図面を参照しつつ第１の実施例を説明する。
図２は本発明の実施形態に係るコンピュータシステムの概略構成の一例を示す図である。

コンピュータシステム201は、CPU202、主記憶装置203、ストレージエリアネットワーク204により接続されたストレージサブシステム205からなり、データベースアクセス処理部206を持つ多数のクライアントホスト207とネットワーク208を介して接続している。

ストレージサブシステム205内部には複数のディスク装置209からなる領域に、データベース管理システム101が管理するデータを格納するデータベース格納領域210が置かれる。また、このストレージサブシステム205はデータ格納領域215とディスク装置209の対応などのストレージ構成情報212を管理する制御部214を持つ。

前記のストレージサブシステム205はコンピュータシステム201に内蔵のディスクとして構成されていても構わない。
また、管理サーバ211はストレージエリアネットワーク環境を管理するためのサーバ装置であり、ストレージの構成情報212を管理する、ストレージ管理ソフトウェア213が格納されている。
このストレージ管理ソフトウェア213はストレージサブシステム205に内蔵されていても構わない。
さらに、主記憶装置203上にはデータベース管理システム101を配置する。

データベース管理システム101には、クライアントホスト206からデータ検索をはじめとする処理要求を受け付ける既存処理である処理要求受付処理部216と、
データベース格納領域210に配置されたデータの操作をデータベース管理システム101が実行する既存処理であるデータ操作実行処理部218と、
データベースのテーブル構成などの情報であるスキーマ定義情報219と、
データベース管理システム101がプロセスやスレッドなどのリソースを保持して処理への割り当てを行うリソース管理部221と、
処理要求ごとのリソース数を決定する処理要求毎リソース数決定処理部217と、
テーブルなどの定義と、それが格納されているデータ管理領域がどのディスク装置に配置されているかを表すスキーマとストレージ構成のマッピング情報 220と、
ディスク装置1台当たりのI/O性能を最大限に引き出すためのスレッド数である基準リソース数222と、を配置する。

基準リソース数222は、ハードウェア構成が同じであれば実験値などから導き出すことができるものであり、本実施例ではディスク装置209の種類を表す型番などのID1201と基準リソース数222の対応を持つ、基準リソース数とディスク装置の対応表223を記録する。

上述した各処理部は、ＣＰＵ２０２で実行されることにより、各処理が実現される。また、上述した各処理部は、各手段と言い換えてもよい。各処理部は、ハードウェア（例えば回路）、コンピュータプログラム、オブジェクト、或いはそれらの組み合わせ（例えば、一部をコンピュータプログラムで実行し一部をハードウェア回路で実行すること）によって実現することもできる。各コンピュータプログラムは、コンピュータマシンに備えられる記憶資源（例えばメモリ）から読み込むことができる。その記憶資源には、ＣＤ−ＲＯＭやＤＶＤ（Digital Versatile Disk）等の記録媒体を介してインストールすることもできるし、インターネットやＬＡＮ等の通信ネットワークを介してダウンロードすることもできる。

図１２は基準リソース数とディスク装置の対応表223を説明するための概念図である。この対応表は、ディスク装置の種類を表す型番などのID1201と基準リソース数222の対応を記録する。

この基準リソース数とディスク装置の対応表223は、データベース管理システム101によるデータ操作実行時に性能統計情報224を取得し、あるディスク装置209の性能統計情報からそのディスク装置209に対応した基準リソース数222を決めても良い。

このような性能統計情報は、一般にデータベース管理システム101やオペレーティングシステムが取得できるもので、例えば1秒あたりのI/Oの数(IOPS)を測定し、1リソースで動いた時のIOPSと、リソース数を上げてもIOPSが上がらなくなった状態を検知して、IOPSが上限に達する時のリソース数を基準リソース数とすることができる。

図１３は性能統計情報224を説明するための概念図である。
本実施例での性能統計情報224は格納領域ID403とこれまでに発生した最大のIOPS1301、さらにその最大IOPSを取得した際に当該領域にアクセスしていたリソースの数1302からなる。

なお、本実施例ではリソース数をスレッド数として扱っているが、プロセス数など他のリソースの場合も同様の処理を行うことができる。

また、データベース管理システム101は、データ操作の性能を向上させるためにメモリ上にディスク上のデータをキャッシュし、データがDBバッファ227上に存在するかどうかを管理するバッファ管理機能226を持つことが一般的である。

図１は本発明の処理要求毎リソース数決定処理部を説明するための概念図である。データベース管理システム101はクライアントホスト207から処理要求を受け付け実行する処理要求実行処理部105を持つ。
処理要求は通常他の業務アプリケーション等が発行されるものであるが、ユーザがクライアントホスト207端末などからデータベース管理システム101に対して処理要求の処理を命じることも可能である。

処理要求実行処理部105は、処理要求を受け付ける処理要求受付処理部216によって処理要求を受け取り、構文解析や最適化などを行った上で、テーブル内のデータへの更新または読み込みといったデータ操作の命令群である実行ロジックに変換する。データ操作実行処理部218はこの実行ロジックを読み込んでデータ操作を実行する。

処理要求毎実行リソース数決定処理部は、スキーマ定義情報219を元に、処理要求の解析結果から検索対象テーブルを決定し(ステップ102)、
ストレージ構成情報212、スキーマとストレージ構成のマッピング情報 220を元に、どのテーブルのデータがどのディスク装置209上に配置されているかといった、操作対象テーブルのストレージ構成を取得し(ステップ103)、
これを元にストレージ構成に対応した処理要求ごとの適切なスレッド最大数を決定する(ステップ104)。

図３は処理要求毎リソース数決定処理部217の詳細を説明するためのフローチャートであり、図１の処理要求毎リソース数決定処理部を詳細化したものである。

処理要求毎リソース数決定処理部217は
スキーマ定義情報219を読み込み(ステップ301)、
処理要求解析結果に含まれる操作対象テーブル一覧を作成する(ステップ302)。
次に、ストレージ管理ソフトウェア213あるいはストレージサブシステム205の制御部214からストレージ構成情報を読み込む(ステップ303)。
ストレージ構成情報212は、利用している領域が何台のディスク装置の上に構成されているかという物理的な構成台数であり、ストレージサブシステム205の制御部214や、ストレージサブシステム205を管理するストレージ管理ソフトウェア213から取得することができる。

さらに、データベース管理システム101が持つスキーマとストレージ構成のマッピング情報220を読み込み(ステップ304)、
スキーマとストレージ構成のマッピング情報220とステップ303で得られたストレージ構成情報とを合わせることで、操作対象テーブルが格納されている部分のストレージ構成情報212を得る(ステップ305)。
ここで、ディスク装置1台あたりのスレッド数である基準リソース数を読み込み(ステップ306)、
ステップ305で得られたストレージ構成情報212、すなわちディスク装置209の構成台数と、基準リソース数222を掛け合わせることで処理要求ごとの適切なスレッド数を決定する(ステップ307)。
なお、ストレージ構成情報212としては、ディスク装置の台数の代わりに、ディスク装置の回転数や入出力のスループット性能、レスポンス性能を用いて同様の処理を行うこともできる。

図４はスキーマ定義情報219を説明するための概念図である。
スキーマ定義情報219は操作対象となるテーブル名402と、テーブルを処理内部で特定するためのテーブルID401や、テーブルが実際に格納されている格納領域のIDである格納領域ID403などから構成されている。
ここで、テーブル名や格納領域名がIDを兼ねていても構わない。

また、検索を高速化する目的で作成されるインデクスについても同様にインデクス名405やそのID404と格納されている領域のID403、インデクスが定義されているテーブルのID401などから構成される情報を持つ。

本実施例では、スキーマ定義情報をメモリ上に格納しているが、リソース数決定処理部の実行時に読み込み可能な場所であれば、ディスク装置上に格納するなど、他の場所に格納されていても良い。

図１１はディスク装置へのI/Oを伴う操作などを実行するデータ操作実行処理部218を説明するためのフローチャートである。

データ操作実行処理部218は、
まず実行ロジックを読み込み(ステップ1101)、
実行ロジックが事前に定義された並列化可能なロジックであるかどうかを判断する(ステップ1107)。
並列化可能であった場合には、操作対象がバッファ上にキャッシュされておらずディスク上にのみ存在しているかどうかを確認する(ステップ1701)。
操作対象がバッファ上にキャッシュされていない場合には、現在使用しているスレッド数が上限に達していないかどうかを確認し(ステップ1102)、
利用しているスレッド数が上限に達している場合にはスレッドの空きを待ち(ステップ1103)、
利用しているスレッド数が上限に達していない場合には、スレッドにデータ操作を割り当て(ステップ1104)、データ操作を実行する(ステップ1106)。

実行ロジックが並列化可能でない場合、および操作対象がバッファ上にキャッシュされている場合には、単純にデータ操作を実行する(ステップ1105)。
そして、上記のステップを実行ロジックが完了するまで繰り返す(ステップ1105)。
DBバッファ227を用いてキャッシュされたデータに対して読み込みを行う場合、多数のスレッドを割り当てても大きな効果は得られない。

そこで、処理要求実行時、データ操作対象がキャッシュされているかどうかを判別し、DBバッファ227上にキャッシュされているデータであればそのまま読み込み、キャッシュされていないデータであれば、スレッドを割り当てて操作を実行することが考えられる。
データ操作実行処理部218で前記のような処理を行うことで、データのキャッシュ状態を考慮したリソース割り当てを行うことが可能である。

図５はストレージ構成情報212を説明するための概念図である。
ストレージ構成情報212は、データベースサーバから認識できるLogical DeviceのID502と、その領域が何台のディスク装置から構成されているかというディスク台数501とからなる。
なお、ディスク台数については、ストレージ装置の仮想化などにより、階層が複雑になっている場合には、複数の関連を重ねた関係を保持し、複数領域にまたがった領域の場合には、その領域間の平均で近似することもできる。

図６はそのようなストレージ装置の階層が複雑化した場合のストレージ構成情報212を説明するための概念図である。
この例では、複数台のディスク装置209をまとめてRAID Group601を構成し、それぞれのRAID Group601をLogical Device602に分割し、分割されたLogical Device602を複数のRAID Group601上から取り出して1つの結合されたLogical Device603を構成している。
このような場合、全てのRAID Groupを構成する平均ディスク装置台数をデータベース格納領域210に対応するディスク台数501であるとする。

また、利用しているディスク容量の比率から、それぞれのディスク台数の重み付けをして、データベース格納領域210に対応するディスク台数501を決定してもよい。

図７はスキーマとストレージ構成のマッピング情報220を説明するための概念図である。

スキーマとストレージ構成のマッピング情報220は、データが格納されている領域を表す格納領域ID403と、
その格納領域に対応する、Logical DeviceのID502と
からなる。
この時、1つの格納領域は複数のLogical Deviceから構成されていてもよく、また、複数の格納領域を1つのLogical Deviceから構成していても良い。

この例以外でも、ストレージサブシステムやオペレーティングシステムの機能を用いて様々な構成が考えられるが、同様の考え方でデータベース格納領域210に対応するディスク台数501を決定することができる。

ここで、ストレージ構成情報212については、単に格納領域のI/O性能をもって、ディスク装置の台数と同じようにストレージ構成情報212として扱っても良い。

図８は図３と同様の処理要求毎リソース数決定処理部217の詳細を説明するためのフローチャートであるが、ストレージ構成情報として、I/O性能を用いた場合の例である。

このフローチャートでは、ステップ301からステップ305までは図３で説明した内容と同様である。

図３のステップ306における、ストレージ1台あたりのスレッド数である基準リソース数を読み込みに代わり、単位I/O性能あたりのスレッド数を基準リソース数として、それを読み込む(ステップ801)。
また、図３のステップ307に代わり、単位I/O性能あたりのスレッド数に格納領域のI/O性能を掛け合わせることで、処理要求毎の最適なスレッド数を導き出す(ステップ802)。

図９はI/O性能を、ストレージ構成情報212として扱った場合のストレージ構成情報の例を説明する概念図である。
ここでストレージ構成情報212は、データベースサーバから認識できるLogical DeviceのID502と、その領域がどれだけのI/Oを単位時間内に出せるかというI/O性能901とからなる。

なお、データ配置に偏りがある場合、理論通りの性能が出ない可能性はあるが、本発明は検索対象がほぼ一様に分布している場合に特に高い効果を発揮するものである。格納されているデータが十分に大規模である場合には一様に分布していることが期待される。

第２の実施例は、複数のテーブルのデータを関連付けて処理する結合処理を持つ場合の実施形態であり、コンピュータシステムの概略構成は図２と同様である。
このような結合処理を持つ場合、複数のテーブルに対して同時に操作を実行するため、操作対象テーブルそれぞれに対して適切なリソース数を割り当てる必要がある。

図１０は、結合処理における操作対象テーブルごとのリソース数を割り当てる処理について説明するためのフローチャートである。
このフローチャートでは、ステップ301からステップ307までは図３で説明した内容と同様である。

こちらのフローチャートでは、ステップ307のディスク装置の構成台数と基準リソース数を掛け合わせることで処理要求毎の適切なリソース数を決定する処理を、操作対象テーブルの数だけ繰り返す(ステップ1001)。
そして得られたテーブル毎のリソース数を操作対象テーブルごとのリソース数上限として記憶する(ステップ1002)。

この時のデータ操作実行処理部は図１１と同様であるが、ステップ1102の、現在使用しているスレッド数が上限に達しているかのチェックをテーブル単位に実行し、1つのテーブルに割り当てられている上限をこえた場合には、空きを待つステップ(ステップ1103)が実行される。

図１４は結合処理におけるリソース数割り当ての効果を説明するための概念図である。
ここでは4台のディスク装置209から構成されている格納領域210と、2台のディスク装置209から構成されている格納領域210があり、それぞれにデータを格納するテーブル1401が配置されている。

このような状況で2つのテーブルのデータを付き合わせる結合処理を行う場合、単に全てのテーブルごとのリソース数上限を合計したものを全体のリソース数上限として動作しても良いが、上記実施例で述べているように、テーブルAとテーブルBの検索それぞれについてリソース数上限を設定することで、テーブルAについてはディスク装置4台分のリソースを用いた検索が実行され、テーブルBについてはディスク装置2台分のリソースを用いた検索が実行される。このように本実施例によれば、1つのデータベース処理要求で複数の格納領域にアクセスが実行される場合でも、領域ごとに適切なリソース数割り当てを行うことができる。

さらに、結合処理を持つ場合、一般に結合順が先となるデータよりも、結合順が後になるデータの方がより多く読み込まれる傾向があるため、結合順が先となるデータよりも後になるデータにより大きなリソース数条件を設定する方式をとっても良い。

図１５は結合処理における結合順を考慮したリソース数割り当てを説明するためのフロー図である。
このフローチャートでは、ステップ301からステップ307と、ステップ1001、ステップ1002については、図１０で説明した内容と同様である。

ステップ1501はディスク装置の構成台数と基準リソース数を掛け合わせることで処理要求毎の適切なリソース数を決定するステップ307の後に、結合順1601に対応した結合順係数1602をかけることで、リソース数を変更する。

結合順係数は、システムで一定の値を保持しておき、利用するものであり、1未満の値となる。なお、結合順が先か後かは従来処理である処理要求受付部で判断しており、容易に判別できる。

図１６は結合順係数管理表225を説明するための概念図である。
結合順係数管理表225は結合順1601と結合順係数1602の対応表になっており、結合順係数225は最後の結合であれば１を、それより前であれば１未満の値を設定し、結合順が前であるほど小さくなる。

結合順係数は、テーブルの中でアクセスされるデータの個数に依存するため、アクセス要求実行前に判断することはできない。例として、単純に結合順を元に例えば結合順が最終結合の1つ前の結合であれば0.9、そのさらに1つ前であれば0.8とし、0.1未満は0.1としておく形が考えられる。

以上によれば、複数の記憶装置内にデータが格納されており多数のリソースを利用する場合、リソースの効率的な利用が可能となり、全体として高速な動作が可能となる。

本発明の実施形態を説明したが、この実施形態は本発明の説明のための例示にすぎず、本発明の範囲をその実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱することなく、その他の様々な態様でも実施することができる。

101・・・データベース管理システム
105・・・処理要求実行処理部
202・・・CPU
203・・・主記憶装置
204・・・ストレージエリアネットワーク
205・・・ストレージサブシステム
206・・・クライアントホスト
207・・・データベースアクセス処理部
208・・・ネットワーク
209・・・ディスク装置
210・・・データベース格納領域
211・・・管理サーバ
212・・・ストレージ構成情報
213・・・ストレージ管理ソフトウェア
216・・・処理要求受付処理部
217・・・処理要求毎リソース数決定処理部
218・・・データ操作実行処理部
219・・・スキーマ定義情報
220・・・スキーマとストレージ構成のマッピング情報
221・・・リソース管理部
222・・・基準リソース数

Claims

データを記憶するデータベースを格納する格納領域を有する補助記憶装置を備えたデータベース管理システムにおけるデータベース管理方法において、
記憶部は、前記データベースのテーブル構成などの情報を格納したスキーマ定義情報と前記データベースのデータを格納する格納領域と前記補助記憶装置の領域とのマッピングを記憶するストレージ構成情報と、前記スキーマと前記ストレージ構成情報のマッピング情報と、前記補助記憶装置に対しスレッド数を変化させた場合に所定の性能が出せるスレッド数を表す基準リソース数とを保持し、
処理要求受付処理部は、データの問い合わせである処理要求を受け付け、
データ操作実行処理部は、前記受け付けた処理要求を解析し、該解析の結果に基づいて前記複数のデータ操作を行い、
リソース管理処理部は、生成されたスレッドに割り当てられる前記データ操作のそれぞれを管理し、
処理要求毎リソース数決定処理部は、前記補助記憶装置の台数と前記基準リソース数に基づいて、前記受け付けた処理要求の実行ごとに当該処理要求が利用するスレッド数上限を決定する
ことを特徴とするデータベース管理方法。
前記処理要求毎リソース数決定処理部は、過去の処理要求実行時に取得した前記データベース管理システムの性能統計情報から算出される前記基準リソース数に基づいて前記スレッド数における上限数を決定することを特徴とする請求項１に記載のデータベース管理方法。
前記処理要求毎リソース数決定処理部は、前記格納領域のI/O性能から算出される前記基準リソース数に基づいて前記スレッド数における上限数を決定することを特徴とする請求項１に記載のデータベース管理方法。
前記処理要求毎リソース数決定処理部は、前記複数の前記格納領域に前記データ操作の対象となるデータが格納されている場合、それぞれの前記格納領域ごとに、前記データ操作の対象となるデータが格納されている前記補助記憶装置の台数から算出される前記基準リソース数に基づいて前記スレッド数の上限を決定する
ことを特徴とする請求項１に記載のデータベース管理方法。
前記処理要求毎リソース数決定処理部は、それぞれの前記複数の格納領域から算出される前記基準リソース数に基づいて前記スレッド数の上限の合計値を処理要求全体の上限とする
ことを特徴とする請求項４に記載のデータベース管理方法。
データを記憶するデータベースを格納する格納領域を有する補助記憶装置を備えたデータベース管理システムにおいて、
前記データベースのテーブル構成などの情報を格納したスキーマ定義情報と前記データベースのデータを格納する格納領域と前記補助記憶装置の領域とのマッピングを記憶するストレージ構成情報と、前記スキーマと前記ストレージ構成情報のマッピング情報と、前記補助記憶装置に対しスレッド数を変化させた場合に所定の性能が出せるスレッド数を表す基準リソース数とを保持する記憶部と、
前記データの問い合わせである処理要求を受け付ける処理要求受付処理部と、
前記受け付けた処理要求を解析し、該解析の結果に基づいて前記複数のデータ操作を行うデータ操作実行処理部と、
生成されたスレッドに割り当てられる前記データ操作のそれぞれを管理するリソース管理処理部と、
前記補助記憶装置の台数と前記基準リソース数に基づいて、前記受け付けた処理要求の実行ごとに当該処理要求が利用するスレッド数上限を決定する処理要求毎リソース数決定処理部と
を備えたことを特徴とするデータベース管理システム。
記憶部を備え、データを記憶するデータベースを格納する格納領域を有する補助記憶装置を備えたデータベース管理システムを機能させるためのデータベース管理プログラムにおいて、
前記データベースのテーブル構成などの情報を格納したスキーマ定義情報と前記データベースのデータを格納する格納領域と前記補助記憶装置の領域とのマッピングを記憶するストレージ構成情報と、前記スキーマと前記ストレージ構成情報のマッピング情報と、前記補助記憶装置に対しスレッド数を変化させた場合に所定の性能が出せるスレッド数を表す基準リソース数とを前記記憶部に保持させる記憶部格納ステップと、
前記データの問い合わせである処理要求を受け付る処理要求受付処理ステップと、
前記受け付けた処理要求を解析し、該解析の結果に基づいて前記複数のデータ操作を行わせるデータ操作実行処理ステップと、
生成されたスレッドに割り当てられる前記データ操作のそれぞれを管理するリソース管理処理ステップと、
前記補助記憶装置の台数と前記基準リソース数に基づいて、前記受け付けた処理要求の実行ごとに当該処理要求が利用するスレッド数上限を決定する処理要求毎リソース数決定処理ステップと
を有し、前記データベース管理システムを機能させることを特徴とするデータベース管理プログラム。
データを記憶するデータベースを格納する格納領域を有する補助記憶装置を備えたデータベース管理システムにおけるデータベース管理方法において、
記憶部は、前記データベースのテーブル構成などの情報を格納したスキーマ定義情報と前記データベースのデータを格納する格納領域と前記補助記憶装置の領域とのマッピングを記憶するストレージ構成情報と、前記スキーマと前記ストレージ構成情報のマッピング情報と、前記補助記憶装置に対しスレッド数を変化させた場合に所定の性能が出せるスレッド数を表す基準リソース数とを保持し、
処理要求受付処理部は、前記データの問い合わせである処理要求を受け付け、
データ操作実行処理部は、前記受け付けた処理要求を解析し、該解析の結果に基づいて前記複数のデータ操作を行い、
リソース管理処理部は、生成されたスレッドに割り当てられる前記データ操作のそれぞれを管理し、
処理要求毎リソース数決定処理部は、前記補助記憶装置の台数と前記基準リソース数に基づいて、前記受け付けた処理要求の実行ごとに当該処理要求が利用するスレッド数上限を決定し、
前記処理要求毎リソース数決定処理部は、複数の関連するデータを突き合わせる結合処理の実行要求を受け付けると、前記結合処理を実行する際に、突き合わせるデータそれぞれが別な前記格納領域に格納されている場合、前記結合処理の結合順が先となるデータよりも結合順が後となるデータの方に数を多く前記スレッド数の上限数を設定する
ことを特徴とするデータベース管理方法。