JP3236999B2 - データベース管理方法およびシステム - Google Patents

データベース管理方法およびシステム

Info

Publication number
JP3236999B2
JP3236999B2 JP2000347725A JP2000347725A JP3236999B2 JP 3236999 B2 JP3236999 B2 JP 3236999B2 JP 2000347725 A JP2000347725 A JP 2000347725A JP 2000347725 A JP2000347725 A JP 2000347725A JP 3236999 B2 JP3236999 B2 JP 3236999B2
Authority
JP
Japan
Prior art keywords
data storage
key
key range
storage area
database management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2000347725A
Other languages
English (en)
Other versions
JP2001175629A (ja
Inventor
正士 土田
一夫 正井
俊一 鳥居
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2000347725A priority Critical patent/JP3236999B2/ja
Publication of JP2001175629A publication Critical patent/JP2001175629A/ja
Application granted granted Critical
Publication of JP3236999B2 publication Critical patent/JP3236999B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Landscapes

  • Multi Processors (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

【発明の詳細な説明】
【0001】
【発明の属する技術分野】本発明は、データベースを複
数の記憶領域に分割して管理するデータベース管理技術
に関する。
【0002】
【従来の技術】例えば、「Devid DeWitt and Jim Gra
y:Parallel Database Systems:TheFuture of High P
erformance Database Systems,CACM,Vol.35,No.6,1
992 」において、並列データベースシステムが提案され
ている。この並列データベースシステムでは、密結合あ
るいは疎結合に複数のプロセッサを接続し、それら複数
のプロセッサに対して、データベース処理を配分してい
る。
【0003】
【発明が解決しようとする課題】従来の複数の記憶領域
を有するデータベースシステムでは、それらの記憶領域
へどのようにデータを格納するかはユーザに任され
か、または、固定的であった。このため、データ量の増
減により負荷の不均衡が発生する問題点があった。そこ
で、本発明の目的は、データを格納する記録領域の割り
付けを操作することで負荷の不均衡を軽減することが出
来るデータベース管理方法およびデータベース管理シス
テムを提供することにある。
【0004】
【課題を解決するための手段】第1の観点では、本発明
は、設定された複数のキーレンジと、記憶装置に設けら
れた複数のデータ格納領域とを対応付け、キーレンジを
追加する要求を受け付けた場合、当該キーレンジ及びデ
ータ格納領域に関する情報を該要求に含み、当該キーレ
ンジ及び当該データ格納領域を対応付けすることを特徴
とするデータベース管理方法を提供する。上記第1の観
点によるデータベース管理方法では、複数のデータ格納
領域に格納されているデータの中で上記追加されたキー
レンジに対応するデータを、追加されたキーレンジに対
応するデータ格納領域へ移動することができるため、各
データ格納領域に対する負荷の不均衡を軽減することが
出来る
【0005】第2の観点では、本発明は、設定された複
数のキーレンジと、記憶装置に設けられた複数のデータ
格納領域とを対応付け、キーレンジを分割する要求を受
け付けた場合、分割される元の第1のキーレンジ及びデ
ータ格納領域、分割する先の複数の第2のキーレンジ及
びデータ格納領域に関する情報を該要求に含み、当該第
1のキーレンジを当該複数の第2のキーレンジに分け、
当該複数の第2のキーレンジ及びデータ格納領域を対応
付けすることを特徴とするデータベース管理方法を提供
する。上記第2の観点によるデータベース管理方法で
は、あるデータ格納領域のデータが他のデータ格納領域
よりも多くなった場合、このデータ格納領域に対応づけ
られたキーレンジを分割し、この分割されたキーレンジ
にデータ格納領域を対応づけることにより、一つのデー
タ格納領域に格納されるデータを少なくすることができ
るため、各データ格納領域に対する負荷の不均衡を軽減
することが出来る
【0006】第3の観点では、本発明は、設定された複
数のキーレンジと、記憶装置に設けられた複数のデータ
格納領域とを対応付け、キーレンジを併合する要求を受
け付けた場合、併合される元の複数の第1のキーレンジ
及びデータ格納領域、併合する先の第2のキーレンジ及
びデータ格納領域に関する情報を該要求に含み、当該複
数の第1のキーレンジを当該第2のキーレンジに合わ
せ、当該第2のキーレンジ及びデータ格納領域を対応付
けすることを特徴とするデータベース管理方法を提供す
る。上記第3の観点によるデータベース管理方法では、
複数のデータ格納領域のデータが他のデータ格納領域よ
りも少なくなった場合、これらのデータ格納領域に対応
づけられたキーレンジを併合し、この併合されたキーレ
ンジにデータ格納領域を対応づけることにより、一つの
データ格納領域に格納されるデータを多くすることがで
きるため、各データ格納領域に対する負荷の不均衡を軽
減することが出来る
【0007】第4の観点では、本発明は、設定された複
数のキーレンジと、記憶装置に設けられた複数のデータ
格納領域とを対応付け、キーレンジを削除する要求を受
け付けた場合、該要求にかかるキーレンジ及びデータ格
納領域のペアを含まないようにデータ格納領域とキーレ
ンジを対応付けることを特徴とするデータベース管理方
法を提供する。上記第4の観点によるデータベース管理
方法では、あるデータ格納領域のデータが他のデータ格
納領域よりも少なくなった場合、このデータ格納領域を
削除し、この削除されたデータ格納領域に対応づけられ
たキーレンジを他のデータ格納領域に割り当てることに
より、データの少ないデータ格納領域を削除することが
できるため、各データ格納領域に対する負荷の不均衡を
軽減することが出来る
【0008】第5の観点では、本発明は、設定された複
数のキーレンジと、記憶装置に設けられた複数のデータ
格納領域とを対応付けて格納する第1の手段と、キーレ
ンジを迫加する要求を受け付けた場合、当該キーレンジ
及びデータ格納領域に関する情報を該要求に含み、当該
キーレンジ及び当該データ格納領域を対応付けする第2
の手段とを備えたことを特徴とするデータベース管理シ
ステムを提供する。上記第5の観点によるデータベース
管理システムでは、複数のデータ格納領域に格納されて
いるデータの中で上記追加されたキーレンジに対応する
データを、追加されたキーレンジに対応するデータ格納
領域へ移動することができるため、各データ格納領域に
対する負荷の不均衡を軽減することが出来る
【0009】第6の観点では、本発明は、設定された複
数のキーレンジと、記憶装置に設けられた複数のデータ
格納領域とを対応付けて格納する第1の手段と、キーレ
ンジを分割する要求を受け付けた場合、分割される元の
第1のキーレンジ及びデ一タ格納領域、分割する先の複
数の第2のキーレンジ及びデータ格納領域に関する情報
を該要求に含み、当該第1のキーレンジを当該複数の第
2のキーレンジに分け、当該複数の第2のキーレンジ及
びデータ格納領域を対応付けする第2の手段とを備えた
ことを特徴とするデータベース管理システムを提供す
。上記第6の観点によるデータベース管理システムで
は、あるデータ格納領域のデータが他のデータ格納領域
よりも多くなった場合、このデータ格納領域に対応づけ
られたキーレンジを分割し、この分割されたキーレンジ
にデータ格納領域を対応づけることにより、一つのデー
タ格納領域に格納されるデータを少なくすることができ
るため、各データ格納領域に対する負荷の不均衡を軽減
することが出来る
【0010】第7の観点では、本発明は、設定された複
数のキーレンジと、記憶装置に設けられた複数のデータ
格納領域とを対応付けて格納する第1の手段と、キーレ
ンジを併合する要求を受け付けた場合、併合される元の
複数の第1のキーレンジ及びデータ格納領域、併合する
先の第2のキーレンジ及びデータ格納領域に関する情報
を該要求に含み、当該複数の第1のキーレンジを当該第
2のキーレンジに合わせ、当該第2のキーレンジ及びデ
ータ格納領域を対応付けする第2の手段とを備えたこと
を特徴とするデータベース管理システムを提供する。上
記第7の観点によるデータベース管理システムでは、複
数のデータ格納領域のデータが他のデータ格納領域より
も少なくなった場合、これらのデータ格納領域に対応づ
けられたキーレンジを併合し、この併合されたキーレン
ジにデータ格納領域を対応づけることにより、一つのデ
ータ格納領域に格納されるデータを多くすることができ
るため、各データ格納領域に対する負荷の不均衡を軽減
することが出来る
【0011】第8の観点では、本発明は、設定された複
数のキーレンジと、記憶装置に設けられた複数のデータ
格納領域とを対応付けて格納する第1の手段と、キーレ
ンジを削除する要求を受け付けた場合、該要求にかかる
キーレンジ及びデータ格納領域のペアを含まないように
データ格納領域とキーレンジを対応付けする第3の手段
とを備えたことを特徴とするデータベース管理システム
を提供する。上記第8の観点によるデータベース管理シ
ステムでは、あるデータ格納領域のデータが他のデータ
格納領域よりも少なくなった場合、このデータ格納領域
を削除し、この削除されたデータ格納領域に対応づけら
れたキーレンジを他のデータ格納領域に割り当てること
により、データの少ないデータ格納領域を削除すること
ができるため、各データ格納領域に対する負荷の不均衡
を軽減することが出来る
【0012】
【発明の実施の形態】以下、本発明の実施形態を図面に
基づいて詳細に説明する。なお、これにより本発明が限
定されるものではない。図1は、本発明の一実施形態の
並列データベースシステム1を示す構成図である。この
並列データベースシステム1は、FES(フロントエン
ドサーバ)ノード,BES(バックエンドサーバ)ノー
ド,IOS(インプットアウトプットサーバ)ノード,
DS(ディクショナリサーバ)ノードおよびJS(ジャ
ーナルサーバ)ノードを、ネットワーク90により接続
した構成である。各ノードは、他のシステムとも接続さ
れている。FESノードは、ディスクを持たない少なく
とも1台のプロセッサから構成されたFES75からな
るノードであり、ユーザからの問合せの解析,最適化,
処理手順作成を実行するフロントエンドサーバの機能を
持っている。BESノードは、ディスクを持たない少な
くとも1台のプロセッサから構成されたBES73から
なるノードであり、前記FES75で作成された処理手
順を基にしてデータベースをアクセスする機能を持って
いる。IOSノードは、少なくとも1台のプロセッサか
ら構成されたIOS70および少なくとも1台のディス
ク80からなるノードであり、ディスク80にデータベ
ースを格納し管理する機能を持っている。なお、IOS
ノードの機能をBESノードに持たせれば、IOSノー
ドを省略できる。この場合、BES73にディスクを接
続すると共に、BES73がディスク80にデータベー
スを格納し管理する機能を持つ。
【0013】データベースは、複数の表からなる。表
は、2次元のテーブル形式であり、複数のロウ(行)か
らなる。1つのロウは、1つ以上のカラム(属性)から
なる。この表は、所定数のロウからなる固定長のページ
単位で物理的に分割されて、ディスク80上に格納され
る。各ページのディスク80上の格納位置は、ディレク
トリ情報を用いて知ることが出来る。
【0014】DSノードは、少なくとも1台のプロセッ
サから構成されたDS71および少なくとも1台のディ
スク81からなるノードであり、データベースの定義情
報を一括管理する機能を持っている。JSノードは、少
なくとも1台のプロセッサから構成されたJS72およ
び少なくとも1台のディスク82からなるノードであ
り、各ノードで実行されるデータベース更新履歴情報を
格納し、管理する機能を持っている。
【0015】図2は、上記並列データベースシステム1
におけるFES75,BES73,IOS70のプロセ
ッサ数およびディスク数およびディスクの分割数を決め
る本発明のデータベース分割管理方法の概念図である。
まず、ユーザが指定するワークロードでデータベース処
理の負荷パターンを決める。負荷パターンには、一件検
索処理、一件更新処理、データ取り出し処理などがあ
る。その負荷パターンに応じて、IOS70でディスク
80を何分割して管理するか決定する(IOSノードの
機能をBESが持つ場合は、BES73でディスクを何
分割して管理するか決定する)。すなわち、スキーマ定
義時、表の分割方法(キー値範囲,範囲毎ロウ数(ペー
ジ数を換算)など)から、格納に必要なディスク数が判
明し、閉塞および再編成の単位が決まれば、BES73
およびIOS70の組み合わせ(閉塞あるいは再編成の
単位がディスク,IOS,BESに依存する)が決ま
る。これにより、BES73,IOS70,ディスク8
0の構成台数が決まる。即ち、次のようになる。 既分割数…全BESで管理する並列アクセス可能なデー
タベース分割単位(動的なBES追加,削除は、この分
割単位で行う) 各分割毎ディスク数…各分割で割り当てられるディスク
数 図2は、ディスク数が“8”、既分割数が“4”、各分
割毎ディスク数が“2”の場合である。なお、プロセッ
サ性能がn倍となれば、分割数を変えずに、各分割で利
用するボリューム数をn倍とする(ただし、IOS70
とディスク80の間の総データ転送レートの制限がある
ため、ディスク数にも制限がある)。また、ここでディ
スクとは、ディスク装置1台に対応させている。本発明
では、必ずしも「ディスク」はディスク装置1台と1対
1に対応させる必要はない。例えば、1ディスク装置に
複数のディスク装置を含む場合(ディスクアレイ装
置)、並列アクセス可能な入出力単位の数を「ディスク
装置」として適用すればよい。
【0016】図2のようにFES:BES:IOS:デ
ィスク=1:4:1:8であるが、初期データロード時
には、FES,BESは1台あればよく、FES:BE
S:IOS:ディスク=1:1:1:8となっている。
そのため、BES731には、既分割#1〜#4のディ
スク811〜842に格納されるデータベースのディレ
クトリ情報を持つ。BES73の負荷が軽くて、BES
731の1台だけでIOS70および8台のディスク8
11〜842を処理可能な場合、BES731の1台だ
けで8台のディスク811〜842に格納されるデータ
ベースをアクセスする。従って、FES:BES:IO
S:ディスク=1:1:1:8のままである。
【0017】BES731の負荷が増加して利用率10
0%の状態が続き負荷アンバランスが検出されると、B
ES732が追加される。既分割数が“4”であるの
で、2つのBES731,732にそれぞれ2つの分割
が対応付けられる。そのため、BES731には、既分
割#1〜#2のディスク811〜822に格納されるデ
ータベースのディレクトリ情報を持つ。また、BES7
32には、既分割#3〜#4のディスク831〜842
に格納されるデータベースのディレクトリ情報を持つ。
FES:BES:IOS:ディスク=1:2:1:8と
なる。
【0018】さらにBES731,732の負荷が増加
して利用率100%の状態が続き負荷アンバランスが検
出されると、BES731,732にそれぞれBES7
33,734が追加される。既分割数が“4”であるの
で、4つのBES731,732,733,734にそ
れぞれ1つの分割が対応付けられる。そのため、BES
731には、既分割#1のディスク811〜812に格
納されるデータベースのディレクトリ情報を持つ。ま
た、BES732には、既分割#2のディスク821〜
822に格納されるデータベースのディレクトリ情報を
持つ。また、BES733には、既分割#3のディスク
831〜832に格納されるデータベースのディレクト
リ情報を持つ。また、BES734には、既分割#4の
ディスク841〜842に格納されるデータベースのデ
ィレクトリ情報を持つ。FES:BES:IOS:ディ
スク=1:4:1:8となる。
【0019】負荷が軽くなり、BES733,734の
利用率が例えば50%未満の状態が続くと、BES73
3,734に割り当ててあるノードを他の処理のために
利用する方が有効である。そこで、利用率が50%未満
のBES733,734を合わせる。すると、FES:
BES:IOS:ディスク=1:2:1:8に縮退す
る。
【0020】以上のように、負荷に応じてBESを増減
すれば、FES:BES:IOS:ディスク=1:1:
1:8〜1:4:1:8の間でスケーラブルなシステム
を実現できる。
【0021】IOS70は、BES73とディスク80
の対応関係に依らず、並列にアクセス可能なディスク数
分の並列なタスクが存在すればよい。このため、データ
の移動を行わず、ディレクトリ情報をBES間で移動す
ることで、BES73とディスク80の対応関係を変更
でき、アクセスの分離および統合が容易に可能となる。
【0022】次に、負荷パターンが一件更新処理の場合
とデータ取り出し処理の場合について、プロセッサ数,
ディスク数,ディスクの分割数を、数値例で説明する。
前提条件は、以下のように仮定する。 FES処理(受取処理) … 30[Kステッフ゜] BES処理(一件更新処理) … 60[Kステッフ゜] (データ取り出し処理)… 220[Kステッフ゜] 送信処理 … 6[Kステッフ゜] 受信処理 …6+4*ページ数[Kステッフ゜] 入出力発行処理 …4+4*ページ数[Kステッフ゜] プロセッサ性能 … 10[Mステッフ゜/秒] 入出力性能(1ヘ゜ーシ゛アクセス) … 20[m秒] (10ヘ゜ーシ゛アクセス) … 30[m秒] A.一件更新処理(1ヘ゜ーシ゛アクセス)の場合 (1)IOSノードがあるシステム構成の場合 FES処理の30[Kステッフ゜]でプロセッサ性能10[Mス
テッフ゜/秒]を割ると、333回/秒まで受取処理が可能
である。また、FESからの実行要求の受信処理6[Kス
テッフ゜]+BESからのデータ取り出し要求の送信処理6
[Kステッフ゜]+IOSからのデータ取り出し結果の受信処
理10[Kステッフ゜]+一件更新処理60[Kステッフ゜]+FE
Sへの実行要求結果の送信処理6[Kステッフ゜]=88[Kス
テッフ゜]がBESでの一件更新処理で必要であるから、こ
れでプロセッサ性能10[Mステッフ゜/秒]を割ると、11
4回/秒まで一件更新処理が可能である。さらに、BE
Sからの入出力要求の受信処理6[Kステッフ゜]+入出力発
行処理8[Kステッフ゜]+BESへの入出力要求結果の送信
処理6[Kステッフ゜]=20[Kステッフ゜]がIOSのディスク
へのアクセスに必要であるから、これでプロセッサ性能
10[Mステッフ゜/秒]を割ると、500回/秒までディス
クへのアクセスが可能である。また、1ページのランダ
ム入出力で20[m秒]を要するので、1台のディスク
には50回/秒までアクセス可能となる。これで前記I
OSでのディスクへのアクセス可能回数500回/秒を
割ると、IOSには10台までのディスクを実装可能で
ある。また、前記BESでの一件更新処理可能回数11
4回/秒で前記IOSでのディスクへのアクセス可能回
数500回/秒を割ると、1台のIOSで4.3台のB
ESに対応可能である。さらに、前記BESでの一件更
新処理可能回数114回/秒で前記FESでの受取処理
可能333回/秒を割ると、1台のFESで3台のBE
Sに対応可能である。以上から、FES:BES=1:
3、BES:IOS=4.3:1、IOS:ディスク=
1:10となる。そこで、総合的には、図3に示すよう
に、FES:BES:IOS:ディスク=1:4:1:
8とすると、ほぼバランスがとれた実装になる(FES
とディスクに多少のアンバランスが生じる)。
【0023】(2)IOSノードの機能をBESノードに
持たせたシステム構成の場合 FES処理の30[Kステッフ゜]でプロセッサ性能10[Mス
テッフ゜/秒]を割ると、333回/秒まで受取処理が可能
である。また、FESからの実行要求の受信処理6[Kス
テッフ゜]+入出力発行処理8[Kステッフ゜]+一件更新処理6
0[Kステッフ゜]+FESへの実行要求結果の送信処理6
[Kステッフ゜]=80[Kステッフ゜]がBESでの一件更新処理
で必要であるから、これでプロセッサ性能10[Mステッフ゜
/秒]を割ると、125回/秒まで一件更新処理が可能
である。また、1ページのランダム入出力で20[m
秒]を要するので、1台のディスクには50回/秒まで
アクセス可能となる。これで前記BESでの一件更新処
理可能回数125回/秒を割ると、BESには2.5台
までのディスクを実装可能である。さらに、前記BES
での一件更新処理可能回数125回/秒で前記FESで
の受取処理可能333回/秒を割ると、1台のFESで
2.6台のBESに対応可能である。以上から、FE
S:BES=1:2.6、BES:ディスク=1:2.
5となる。そこで、総合的には、図4に示すように、F
ES:BES:ディスク=1:4:8とすると、ほぼバ
ランスがとれた実装になる(FESに多少のアンバラン
スが生じる)。
【0024】B.データ取り出し処理(10ヘ゜ーシ゛アクセス)
の場合 (1)IOSノードがあるシステム構成の場合 FES処理の30[Kステッフ゜]でプロセッサ性能10[Mス
テッフ゜/秒]を割ると、333回/秒まで受取処理が可能
である。また、FESからの実行要求の受信処理6[Kス
テッフ゜]+BESからのデータ取り出し要求の送信処理6
[Kステッフ゜]+IOSからのデータ取り出し結果の受信処
理46[Kステッフ゜]+データ取り出し処理220[Kステッフ
゜]+FESへの実行要求結果の送信処理6[Kステッフ゜]
=284[Kステッフ゜]がBESでのデータ取り出し処理で
必要であるから、これでプロセッサ性能10[Mステッフ゜/
秒]を割ると、35回/秒までデータ取り出し処理が可
能である。さらに、BESからの入出力要求の受信処理
6[Kステッフ゜]+入出力発行処理44[Kステッフ゜]+BES
への入出力要求結果の送信処理6[Kステッフ゜]=56[Kス
テッフ゜]がIOSのディスクへのアクセスに必要であるか
ら、これでプロセッサ性能10[Mステッフ゜/秒]を割る
と、179回/秒までディスクへのアクセスが可能であ
る。また、10ページの一括入出力で30[m秒]を要
するので、1台のディスクには33回/秒までアクセス
可能である。これで前記IOSでのディスクへのアクセ
ス可能回数179回/秒を割ると、5.4台までのディ
スクを実装可能である。また、前記BESでのデータ取
り出し処理可能回数35回/秒で前記IOSでのディス
クへのアクセス可能回数179回/秒を割ると、1台の
IOSで5.1台のBESに対応可能である。さらに、
前記BESでのデータ取り出し処理可能回数35回/秒
で前記FESでの受取処理可能333回/秒を割ると、
1台のFESで9.5台のBESに対応可能である。以
上から、FES:BES=1:9.5、BES:IOS
=5.1:1、IOS:ディスク=1:5.4となる。
そこで、総合的には、FES:BES:IOS:ディス
ク=1:10:2:10とすると、ほぼバランスがとれ
た実装になる(ディスクに多少のアンバランスが生じ
る)。
【0025】(2)IOSノードの機能をBESノードに
持たせたシステム構成の場合 FES処理の30[Kステッフ゜]でプロセッサ性能10[Mス
テッフ゜/秒]を割ると、333回/秒まで受取処理が可能
である。また、FESからの実行要求の受信処理6[Kス
テッフ゜]+入出力発行処理44[Kステッフ゜]+データ取り出
し処理220[Kステッフ゜]+FESへの実行要求結果の送
信処理6[Kステッフ゜]=276[Kステッフ゜]がBESでのデ
R>ータ取り出し処理で必要であるから、これでプロセッ
サ性能10[Mステッフ゜/秒]を割ると、36回/秒までデ
ータ取り出し処理が可能である。また、10ページの一
括入出力で30[m秒]を要するので、1台のディスク
には33回/秒までアクセス可能である。これで前記B
ESでのデータ取り出し処理可能回数36回/秒を割る
と、1台だけのディスクを実装可能である。さらに、前
記BESでのデータ取り出し処理可能回数36回/秒で
前記FESでの受取処理可能333回/秒を割ると、1
台のFESで9.2台のBESに対応可能である。以上
から、FES:BES=1:9.2、BES:ディスク
=1:1となる。そこで、総合的には、FES:BE
S:ディスク=1:10:10とすると、ほぼバランス
がとれた実装になる。
【0026】図5は、FES75の構成図である。FE
S75は、ユーザが作成したアプリケーションプログラ
ム10〜11と、問合せ処理やリソース管理などのデー
タベースシステム全体の管理を行う並列データベース管
理システム20と、データの読み書きなどの計算機シス
テム全体の管理を受け持つオペレーティングシステム3
0とを具備している。上記並列データベース管理システ
ム20は、システム制御部21と、論理処理部22と、
物理処理部23と、処理対象となるデータを一時的に格
納するデータベース/ディクショナリ24とを具備して
いる。また、上記並列データベース管理システム20
は、ネットワーク90および他のシステムと接続されて
いる。
【0027】上記システム制御部21は、入出力の管理
等を行う。また、データロード処理210と、動的負荷
制御処理211とを具備している。
【0028】上記論理処理部22は、問合せの構文解析
や意味解析を行う問合せ解析220と、適切な処理手順
候補を生成する静的最適化処理221と、処理手順候補
に対応したコードの生成を行なうコード生成222とを
具備している。また、処理手順候補から最適なものを選
択する動的最適化処理223と、選択された処理手順候
補のコードの解釈実行を行うコード解釈実行224とを
具備している。
【0029】上記物理処理部23は、アクセスしたデー
タの条件判定や編集やレコード追加などを実現するデー
タアクセス処理230と、データベースレコードの読み
書き等を制御するデータベース/ディクショナリバッフ
ァ制御231と、システムで共用するリソースの排他制
御を実現する排他制御233とを具備している。
【0030】図6は、BES73の構成図である。BE
S73は、データベースシステム全体の管理を行う並列
データベース管理システム20と、計算機システム全体
の管理を受け持つオペレーティングシステム30とを具
備して構成されている。なお、IOSノードの機能を持
つときは、ディスクを有し、そのディスクにデータベー
ス40を格納し、管理する。上記並列データベース管理
システム20は、システム制御部21と、論理処理部2
2と、物理処理部23と、処理対象となるデータを一時
的に格納するデータベースバッファ24とを具備してい
る。また、上記並列データベース管理システム20は、
ネットワーク90および他のシステムと接続されてい
る。
【0031】上記システム制御部21は、入出力の管理
等を行う。また、負荷配分を考慮したデータロードを行
うためのデータロード処理210を具備している。上記
論理処理部22は、コードの解釈実行を行うコード解釈
実行224を具備している。上記物理処理部23は、ア
クセスしたデータの条件判定や編集やレコード追加など
を実現するデータアクセス処理230と、データベース
レコードの読み書き等を制御するデータベースバッファ
制御231と、入出力対象となるデータの格納位置を管
理するマッピング処理232と、システムで共用するリ
ソースの排他制御を実現する排他制御233とを具備し
ている。
【0032】図7は、IOS70とディスク80の構成
図である。IOS70は、データベースシステム全体の
管理を行う並列データベース管理システム20と、計算
機システム全体の管理を受け持つオペレーティングシス
テム30とを具備して構成されている。ディスク80に
は、データベース40が格納されている。
【0033】上記並列データベース管理システム20
は、システム制御部21と、物理処理部23と、処理対
象となるデータを一時的に格納する入出力バッファ24
とを具備している。また、上記並列データベース管理シ
ステム20は、ネットワーク90および他のシステムと
接続されている。
【0034】上記システム制御部21は、入出力の管理
等を行う。また、負荷配分を考慮したデータロードを行
うためのデータロード処理210を具備している。上記
物理処理部23は、アクセスしたデータの条件判定や編
集やレコード追加などを実現するデータアクセス処理2
30と、データベースレコードの読み書き等を制御する
入出力バッファ制御231とを具備している。
【0035】図8は、DS71およびディスク81の構
成図である。DS71は、データベースシステム全体の
管理を行う並列データベース管理システム20と、計算
機システム全体の管理を受け持つオペレーティングシス
テム30とを具備して構成されている。ディスク81に
は、ディクショナリ50が格納されている。
【0036】上記並列データベース管理システム20
は、システム制御部21と、論理処理部22と、物理処
理部23と、ディクショナリバッファ24とを具備して
いる。また、上記並列データベース管理システム20
は、ネットワーク90および他のシステムと接続されて
いる。上記論理処理部22は、コードの解釈実行を行う
コード解釈実行224を具備している。上記物理処理部
23は、アクセスしたデータの条件判定や編集やレコー
ド追加などを実現するデータアクセス処理230と、デ
ィクショナリレコードの読み書き等を制御するディクシ
ョナリバッファ制御231と、システムで共用するリソ
ースの排他制御を実現する排他制御233とを具備して
いる。
【0037】図9は、JS72とディスク82の構成図
である。JS72は、データベースシステム全体の管理
を行う並列データベース管理システム20と、計算機シ
ステム全体の管理を受け持つオペレーティングシステム
30とを具備して構成されている。ディスク82には、
ジャーナル60が格納されている。
【0038】上記並列データベース管理システム20
は、システム制御部21と、物理処理部23と、ジャー
ナルバッファ24とを具備している。また、上記並列デ
ータベース管理システム20は、ネットワーク90およ
び他のシステムと接続されている。上記物理処理部23
は、アクセスしたデータの条件判定や編集やレコード追
加などを実現するデータアクセス処理230と、ジャー
ナルレコードの読み書き等を制御するジャーナルバッフ
ァ制御231とを具備している。
【0039】図10は、FES75におけるデータベー
ス管理システム20の処理を示すフローチャートであ
る。システム制御部21は、問合せ分析処理か否かチェ
ックする(212)。問合せ分析処理であれば、問合せ
分析処理400を呼び出し、それを実行した後、終了す
る。問合せ分析処理でなければ、問合せ実行処理か否か
チェックする(213)。問合せ実行処理であれば、問
合せ実行処理410を呼び出し、それを実行した後、終
了する。問合せ実行処理でなければ、データロード処理
か否かチェックする(214)。データロード処理であ
れば、データロード処理210を呼び出し、それを実行
した後、終了する。データロード処理でなければ、動的
負荷制御処理か否かチェックする(214)。動的負荷
制御処理であれば、動的負荷制御処理210を呼び出
し、それを実行した後、終了する。動的負荷制御処理で
なければ、終了する。
【0040】なお、BES73におけるデータベース管
理システム20の処理のフローチャートは、図10から
ステップ212,215,400,211を省いたもの
となる。また、IOS70におけるデータベース管理シ
ステム20の処理のフローチャートは、図10からステ
ップ212,213,215,400,410,211
を省いたものとなる。
【0041】図11は、問合せ分析処理400のフロー
チャートである。まず、問合せ解析220により、入力
された問合せ文の構文解析,意味解析を実行する。次
に、静的最適化処理221により、問合せで出現する条
件式から条件を満足するデータの割合を推定し、予め設
定している規則を基に、有効なアクセスパス候補(特に
インデクスを選出する)を作成し、処理手順の候補を作
成する。次に、コード生成222により、処理手順の候
補を実行形式のコードに展開する。そして、処理を終了
する。
【0042】図12は、問合せ解析220のフローチャ
ートである。ステップ2200では、入力された問合せ
文の構文解析,意味解析を実行する。そして、処理を終
了する。
【0043】図13は、静的最適化処理221のフロー
チャートである。まず、述語選択率推定2210によ
り、問い合せに出現する条件式の述語の選択率を推定す
る。次に、アクセスパス剪定2212により、インデク
ス等からなるアクセスパスを剪定する。次に、処理手順
候補生成2213により、アクセスパスを組み合わせた
処理手順候補を生成する。そして、処理を終了する。
【0044】図14は、述語選択率推定2210のフロ
ーチャートである。ステップ22101では、問合せ条
件式に変数が出現するか否かチェックする(2210
1)。変数が出現しなければステップ22102に進
み、変数が出現すればステップ22104に進む。ステ
ップ22102では、当条件式にカラム値分布情報があ
るか否かチェックする。カラム値分布情報があればステ
ップ22103に進み、カラム値分布情報がなければス
テップ22105に進む。ステップ22103では、カ
ラム値分布情報を用いて選択率を算出し、終了する。ス
テップ22104では、当条件式にカラム値分布情報が
あるか否かチェックする。カラム値分布情報があれば終
了し、カラム値分布情報がなければ、ステップ2210
5に進む。ステップ22105では、条件式の種別に応
じてディフォルト値を設定し(22105)、終了す
る。
【0045】図15は、アクセスパス剪定2212のフ
ローチャートである。ステップ22120では、問合せ
条件式で出現するカラムのインデクスをアクセスパス候
補として登録する。ステップ22121では、問合せで
アクセス対象となる表が複数ノードに分割格納されてい
るかチェックする。分割格納されていなければステップ
22122に進み、分割格納されていればステップ22
123に進む。ステップ22122では、シーケンシャ
ルスキャンをアクセスパス候補として登録する。ステッ
プ22123では、パラレルスキャンをアクセスパス候
補として登録する。ステップ22124では、各条件式
の選択率が既に設定済みか否かチェックする。設定済み
であればステップ22125に進み、設定済みでなけれ
ばステップ22126に進む。ステップ22125で
は、各表に関して選択率が最小となる条件式のインデク
スをアクセスパスの最優先度とする。ステップ2212
6では、各条件式の選択率の最大値および最小値を取得
する。ステップ22127では、プロセッサ性能,IO
性能等システム特性より各アクセスパスの選択基準を算
出する。ステップ22128では、単一あるいは複数の
インデクスを組合せたアクセスパスでの選択率が上記選
択基準を下回るものだけアクセスパス候補として登録す
る。
【0046】図16は、処理手順候補生成2213のフ
ローチャートである。ステップ22130では、問合せ
でアクセス対象となる表が複数ノードに分割格納されて
いるかチェックする。分割格納されていなければステッ
プ22131へ進み、分割格納されていればステップ2
2135へ進む。ステップ22131では、処理手順候
補にソート処理が含まれているか否かをチェックする。
含まれていなければステップ22132へ進み、含まれ
ていればステップ22135へ進む。ステップ2213
2では、問合せでアクセス対象となる表のアクセスパス
が唯一であるかチェックする。唯一であればステップ2
2133へ進み、唯一でなければステップ22134へ
進む。ステップ22133では、単一の処理手順を作成
し、終了する。ステップ22134では、複数の処理手
順を作成し、終了する。
【0047】ステップ22135では、結合可能な2ウ
ェイ結合へ問合せを分解する。ステップ22136で
は、分割格納される表の格納ノード群に対応して、デー
タ読みだし/データ分配処理手順とスロットソート処理
手順を候補として登録する。ステップ22137では、
結合処理ノード群に対応して、スロットソート処理手
順、Nウェイマージ処理手順および突き合わせ処理手順
を候補として登録する。なお、スロットソート処理と
は、ページ内の各ロウがページ先頭からのオフセットで
位置付けされるスロットで管理され、データが格納され
るページを対象とするページ内のソート処理を指し、ス
ロット順に読みだせば昇順にロウがアクセス可能とす
る。また、Nウェイマージ処理とは、Nウェイのバッフ
ァを用いて、各マージ段でN本のソート連を入力にして
トーナメント法で最終的に1本のソート連を作成する処
理をいう。ステップ22138では、要求データ出力ノ
ードに要求データ出力処理手順を登録する。ステップ2
2139では、分解結果に対して評価がすべて終了した
かチェックする。評価がすべて終了していなければ前記
ステップ22136に戻り、評価がすべて終了していれ
ば処理を終了する。
【0048】図17は、コード生成222のフローチャ
ートである。ステップ2220では、処理手順候補が唯
一か否かをチェックする。唯一でなければステップ22
21へ進み、唯一であればステップ2223へ進む。ス
テップ2221では、カラム値分布情報等からなる最適
化情報を処理手順に埋込む。ステップ2222では、問
合せ実行時に代入された定数に基づいて処理手順を選択
するデータ構造を作成する。ステップ2223では、処
理手順を実行形式へ展開する。そして、処理を終了す
る。
【0049】図18は、問合せ実行処理410のフロー
チャートである。まず、動的実行時最適化223によ
り、代入された定数に基づき、各ノード群で実行する処
理手順を決定する。次に、コード解釈実行224によ
り、当処理手順を解釈し、実行する。そして、処理を終
了する。
【0050】図19は、動的最適化処理223のフロー
チャートである。ステップ22300では、動的負荷制
御処理を実行する(22300)。ステップ22301
では、作成されている処理手順が単一か否かをチェック
する。単一であれば、処理を終了する。単一でなけれ
ば、ステップ22302へ進む。ステップ22302で
は、代入された定数を基に選択率を算出する。ステップ
22303では、処理手順候補に並列な処理手順が含ま
れるか否かチェックする。含まれていればステップ22
304に進み、含まれていなければステップ22308
に進む。ステップ22304では、ディクショナリから
最適化情報(結合カラムのカラム値分布情報,アクセス
対象となる表のロウ数,ページ数等)を入力する。ステ
ップ22305では、データ取り出し/データ分配のた
めの処理時間を各システム特性を考慮し、算出する。ス
テップ22306では、当処理時間から結合処理に割当
てるノード数pを決定する。ステップ22307では、
データ分配情報を最適化情報を基に作成する。ステップ
22308では、アクセスパスの選択基準に従って処理
手順を選択し、終了する。
【0051】図20は、コード解釈実行224のフロー
チャートである。ステップ22400では、データ取り
出し/データ分配処理か否かチェックする。データ取り
出し/データ分配処理であればステップ22401に進
み、データ取り出し/データ分配処理でなければステッ
プ22405に進む。ステップ22401では、データ
ベースをアクセスし条件式を評価する。ステップ224
02では、データ分配情報を基に、各ノード毎のバッフ
ァへデータを設定する。ステップ22403では、当該
ノードのバッファが満杯か否かチェックする。満杯であ
ればステップ22404へ進み、満杯でなければステッ
プ22420へ進む。ステップ22404では、ページ
形式で対応するノードへデータを転送し、ステップ22
420へ進む。
【0052】ステップ22405では、スロットソート
処理か否かチェックする。スロットソート処理であれば
ステップ22406へ進み、スロットソート処理でなけ
ればステップ22409へ進む。ステップ22406で
は、他ノードからのページ形式データの受け取りを行
う。ステップ22407では、スロットソート処理を実
行する。ステップ22408では、スロットソート処理
結果を一時的に保存し、ステップ22420へ進む。
【0053】ステップ22409では、Nウェイマージ
処理か否かチェックする。Nウェイマージ処理であれば
ステップ22410へ進み、Nウェイマージ処理でなけ
ればステップ22412へ進む。ステップ22410で
は、Nウェイマージ処理を実行する。ステップ2241
1では、Nウェイマージ処理結果を一時的に保存し、ス
テップ22420へ進む。
【0054】ステップ22412では、突き合わせ処理
か否かチェックする。突き合わせ処理であればステップ
22413へ進み、突き合わせ処理でなければステップ
22416へ進む。ステップ22413では、両ソート
リストを突き合わせ、出力用バッファへデータを設定す
る。ステップ22414では、出力用バッファが満杯か
否かチェックする。満杯であれば、ステップ22415
へ進む。満杯でなければ、ステップ22420へ進む。
ステップ22415では、ページ形式で要求データ出力
ノードへデータを転送し、ステップ22420へ進む。
【0055】ステップ22416では、要求データ出力
処理か否かチェックする。要求データ出力処理であれば
ステップ22417へ進み、要求データ出力処理でなけ
ればステップ22420へ進む。ステップ22417で
は、他ノードからページ形式データの転送があるか否か
チェックする。転送があればステップ22418へ進
み、転送がなければステップ22419へ進む。ステッ
プ22418では、他ノードからページ形式データを受
け取る。ステップ22419では、アプリケーションプ
ログラムへ問合せ処理結果を出力する。
【0056】ステップ22420では、BESで実行中
か否かチェックする。BESで実行中ならステップ22
421へ進み、BESで実行中でないなら終了する。ス
テップ22421では、アクセスページ数,ヒットロウ
数,通信回数等の処理負荷を推定するための情報をFE
Sへ通知し、終了する。
【0057】図21は、データロード処理210のフロ
ーチャートである。各ステップを説明する前に概念を説
明する。データロード方法には、表全体のスキャンに必
要な時間を一定時間内に抑える目標応答時間重視データ
配置と、mページアクセスに最適化した期待並列度重視
データ配置と、ボリューム分割を完全にユーザが指定し
たユーザ制御によるユーザ指定データ配置とがある。目
標応答時間重視データ配置では、まず、表全体のロウを
格納するのに必要なページ数を求める。次に、並列アク
セス可能な各分割のディスクに格納するページ数の上限
を決める。アクセスには、必要となれば一括入力(例え
ば、10ページ)を前提にする。ディスク台数,IOS
台数,BES台数の組み合わせに応じて負荷配分を決め
る。キーレンジ分割がある場合、上限ページ数でキーレ
ンジ分割区間を再分割し、各分割のディスクへ各々格納
する。このキーレンジ分割については、図23を参照し
て後で詳述する。
【0058】期待並列度重視データ配置では、mのサイ
ズに依存するが、かなり大であることな望ましい。キー
レンジ分割がある場合、mのサイズと期待並列度pから
各キーレンジ分割単位のサブキーレンジ格納ページ数s
(=m/p)を決定し、sページ単位で各分割のディス
クへ各々格納する。期待並列度pの算出方法は、応答時
間をノード毎のオーバヘッドで割った比の平方根で算出
する。この比が、10で期待並列度3、100で期待並
列度10、1000で期待並列度32、10000で期
待並列度100となる。算出された期待並列度pが、既
分割数を上回る場合、既分割数を採用する(既分割数で
処理できる最大ディスク数が決まるため)。逆の場合
は、既分割数を上限に期待並列度pを分割数として採用
する。具体的に、100ページアクセスに最適化したデ
ータ配置を試算する。前提として、一括入力は10ペー
ジとする。1回のI/O時間(10ページアクセス)に
300m秒、1回のI/Oオーバヘッドに5.6m秒
(10MIPS性能で56ksが必要)であるので、期
待並列度pが約7(=√{300/5.6})となる。
従って、s=14(=100/7)ページ毎にサブキー
レンジ分割を行う。
【0059】ユーザ指定データ配置は、従来のデータベ
ース管理システムと同様のデータ配置であり、設定パラ
メタ通りに管理する。
【0060】さて、ステップ21000では、目標応答
時間重視データ配置か否かをチェックする。目標応答時
間重視データ配置でなければステップ21001に進
み、目標応答時間重視データ配置であればステップ21
003に進む。ステップ21001では、期待並列度重
視データ配置か否かチェックする。期待並列度重視デー
タ配置でなければステップ21002に進み、期待並列
度重視データ配置であればステップ21010に進む。
ステップ21002では、ユーザ指定があるか否かをチ
ェックする。ユーザ指定があればステップ21016に
進み、ユーザ指定がなければ終了する。
【0061】ステップ21003では、表全体のロウを
格納するのに必要なページ数を求める。ステップ210
04では、表のスキャンに必要な時間を一定とする並列
アクセス可能なディスクに格納するページ数の上限を決
める。ステップ21005では、上記要件を満たすBE
S,IOS,ディスク群を決定する。ステップ2100
6では、キーレンジ分割があるか否かチェックする。キ
ーレンジ分割があるならステップ21007へ進み、キ
ーレンジ分割がないならステップ21009へ進む。ス
テップ21007では、ある上限ページ数でキーレンジ
分割区間を再分割しする。ステップ21008では、キ
ーレンジ分割区間に対応してデータ挿入を行い、終了す
る。ステップ21009では、上限ページ数で区切って
データ挿入を行い、終了する。
【0062】ステップ21010では、推定ワークロー
ドにより最適ページアクセス数mを算出する。ステップ
21011では、期待並列度pを算出し、その期待並列
度pに応じて、BES,IOS,ディスク群を決定す
る。ステップ21012では、キーレンジ分割があるか
否かチェックする。キーレンジ分割があるならステップ
21013へ進み、キーレンジ分割がないならステップ
21015へ進む。ステップ21013では、サブキー
レンジ単位の格納ページ数s(=m/p)を算出する。
ステップ21014では、sページ単位でサブキーレン
ジ分割し、各ディスクへデータ挿入を行い、終了する。
【0063】ステップ21015では、sページ数で区
切ってデータ挿入を行い、終了する。
【0064】ステップ21016では、ユーザ指定のI
OSの管理するディスクへデータ挿入を行い、終了す
る。
【0065】図22は、動的負荷制御処理211のフロ
ーチャートである。ステップ21100では、負荷アン
バランス(アクセス集中化/離散化)の有無を検出す
る。すなわち、ノード毎単位時間当たりに実行されたD
B処理負荷(処理ステップ数(DB処理分,I/O処理
分,通信処理分)、プロセッサ性能(処理時間に換算す
る)、I/O回数(入出力時間に換算する))の分布か
らネックとなる資源(プロセッサ(BES,IOS)、
ディスク)を検出し、DB処理をSQL文に展開し、各
資源へのアクセス状況を表単位に分類する。負荷アンバ
ランスが検出されたらステップ21101へ進み、負荷
アンバランスが検出されなかったら処理を終了する。ス
テップ21101では、アクセス分布情報から、BES
を追加あるいは削除するか、IOS,ディスク対を追加
あるいは削除するかを判断する。追加または削除が必要
ならステップ21102に進み、必要ないなら終了す
る。ステップ21102では、追加か否かをチェックす
る。追加ならステップ21103へ進み、追加でないな
らステップ2112へ進む。
【0066】ステップ21103では、オンライン中か
チェックする。オンライン中なら、ステップ21104
へ進む。オンライン中でないなら、ステップ21105
へ進む。ステップ21104では、対象となるBES群
で管理される表のキーレンジ範囲を閉塞する。ステップ
21105では、新たにBESを割り当る。ステップ2
1106では、ロック情報およびディレクトリ情報の引
き継ぎを行う。ステップ21107では、ノード振り分
け制御に必要なディクショナリ情報の書き換えをDS7
1に指示する。ステップ21108では、IOSが存在
するか否かをチェックする。存在しなければステップ2
1109へ進み、存在すればステップ21110へ進
む。なお、このステップは、IOSが存在するシステム
構成とIOSが存在しないシステム構成の両方に同じソ
フトウエアで対応するために挿入されている。ステップ
21109では、対象となるBES群から新たなBES
群へデータを移動する。ステップ21110では、オン
ライン中かチェックする。オンライン中なら、ステップ
21111へ進む。オンライン中でないなら、処理を終
了する。ステップ21111では、対象となるBES群
で管理される表のキーレンジ範囲の閉塞を解除し、終了
する。
【0067】ステップ21112では、オンライン中か
チェックする。オンライン中なら、ステップ21113
へ進む。オンライン中でないなら、ステップ21114
へ進む。ステップ21113では、対象となるBES群
で管理される表のキーレンジ範囲を閉塞する。ステップ
21114では、縮退するBESを決定する。ステップ
21115では、ロック情報およびディレクトリ情報の
引き継ぎを行う。ステップ21116では、ノード振り
分け制御に必要なディクショナリ情報の書き換えをDS
71に指示する。ステップ21117では、IOSが存
在するか否かをチェックする。存在しなければステップ
21118へ進み、存在すればステップ21119へ進
む。ステップ21118では、縮退するBES群からデ
ータを追い出す。ステップ21119では、オンライン
中かチェックする。オンライン中なら、ステップ211
20へ進む。オンライン中でないなら、処理を終了す
る。ステップ21120では、対象となるBES群で管
理される表のキーレンジ範囲の閉塞を解除し、終了す
る。
【0068】図23は、キーレンジ分割を用いたデータ
ロード処理の概念図である。既分割数は“4”とする。
また、データベースのカラム値v1〜v6は、図11の
ような出現頻度を取るものとする。初期データロード
時、必要なBESは、731の1台でよい。格納するべ
きページ数を各分割810〜840のディスクにそれぞ
れページ数の上限まで対応付けると、カラム値v1〜v
2は分割810のディスクに格納され、カラム値v2〜
v3は分割820および830のディスクに格納され、
カラム値v3〜v5は分割840のディスクに格納さ
れ、カラム値v5〜v6は他のディスク群に格納され
る。初期データロード時には、各ディスクに格納された
ページの管理を行うために、ディスク毎のディレクトリ
情報を作成する。データベースアクセス時には、負荷に
応じてBES732〜734を用いる場合、各BESに
対応するディスク毎のディレクトリ情報を利用し、デー
タベースをアクセスする。
【0069】上記各処理の実装に当たって、次の実施形
態と組合せてもよい。ロウのノード間移動を容易にする
ために、ロウ識別子にBES等の位置情報を含めない。
BESでは、表の分割位置を特定するためのディレクト
リ情報とロウ識別子とを組み合わせて、ロウの物理位置
を特定する。ロウ移動に関しては、ディレクトリ情報の
書き換えで対応する。再編成あるいはロウ移動に対応し
た構造にしておき、BESが動的に追加されても、ディ
レクトリ情報およびロック情報の引き継ぎで処理の分割
を可能とする。また、データベースをレプリカ管理する
場合、2倍の格納領域が必要となる。1次コピーとバッ
クアップコピーが同一IOS、BESで管理されるか否
かにかかわらず、ディスクへのアクセス負荷はほぼ2倍
となるため、既分割数で管理する各分割毎ボリューム数
を1/2とすればよい。さらに、ディスク、IOS、B
ES等の障害時、オンライン処理から切り離し、復旧後
オンラインと接続する。各ノードに応じて閉塞管理方式
が異なる。ディスク障害時、このディスクに格納される
キーレンジ範囲を閉塞する。バックアップコピーが存在
すれば(同一IOS(ミラーディスク)、別IOS(デ
ータレプリカ)の管理下でバックアップコピーを取得す
る必要あり)、処理を振り分ける。IOS障害時、この
IOSに格納されるキーレンジ範囲を閉塞する。バック
アップコピーが存在すれば(別IOS(データレプリ
カ)の管理下でバックアップコピーを取得する必要あ
り)、処理を振り分ける。BES障害時、このBESで
管理されるキーレンジ範囲を閉塞する。IOSが存在す
れば、新たにBESを割り当て、ロック情報引き継ぎ、
ノード振り分け制御に必要なディクショナリ情報の書き
換え後、処理を続行する。
【0070】本発明は、統計情報を用いた規則とコスト
評価との併用に限らず、適当なデータベース参照特性情
報を与える処理手順が得られるものであれば、例えばコ
スト評価のみ、規則利用のみ、コスト評価と規則利用の
併用等の最適化処理を行うデータベース管理システムに
も適用できる。
【0071】本発明は、密結合/疎結合マルチプロセッ
サシステム大型計算機のソフトウェアシステムを介して
実現することも、また各処理部のために専用プロセッサ
が用意された密結合/疎結合複合プロセッサシステムを
介して実現することも可能である。また、単一プロセッ
サシステムでも、各処理手順のために並列なプロセスを
割当てていれば、適用可能である。また、複数プロセッ
サが各々複数のディスクを互いに共用する構成にも適用
可能である。
【0072】
【発明の効果】本発明のデータベース管理方法およびデ
ータベース管理システムによれば、データを格納する記
憶領域の割り付けを操作することで、負荷の不均衡を軽
減することが出来る
【図面の簡単な説明】
【図1】本発明の一実施形態の並列データベースシステ
ムを示す構成図である。
【図2】本発明のデータベース分割管理方法を示す概念
図である。
【図3】本発明のデータベース分割管理方法による最適
ノード配分(IOSがある場合)の概念図である。
【図4】本発明のデータベース分割管理方法による最適
ノード配分(IOSがない場合)の概念図である。
【図5】FESの構成図である。
【図6】BESの構成図である。
【図7】IOSの構成図である。
【図8】DSの構成図である。
【図9】JSの構成図である。
【図10】システム制御部の処理のフローチャートであ
る。
【図11】問合せ分析処理のフローチャートである。
【図12】問合せ解析の処理のフローチャートである。
【図13】静的最適化処理のフローチャートである。
【図14】述語選択率推定の処理のフローチャートであ
る。
【図15】アクセスパス剪定の処理のフローチャートで
ある。
【図16】処理手順候補生成の処理のフローチャートで
ある。
【図17】コード生成の処理のフローチャートである。
【図18】問合せ実行処理のフローチャートである。
【図19】動的最適化の処理のフローチャートである。
【図20】コード解釈実行の処理のフローチャートであ
る。
【図21】データロード処理のフローチャートである。
【図22】動的負荷制御処理のフローチャートである。
【図23】動的負荷制御の概念図である。
【符号の説明】
1…並列データベースシステム 10、11…アプリケーションプログラム、 20…データベース管理システム 21…システム制御部、 210…データロード処理、 210…動的負荷制御処
理 22…論理処理部、 220…問合せ解析、221…静的最適化処理、222
…コード生成、223…動的最適化処理、224…コー
ド解釈実行 30…オペレーティングシステム、 40…データベー
ス 70…IOS、 71…JS 72…DS 73…BES 75…FES、 80、81、82…ディスク 90…相互結合ネットワーク
───────────────────────────────────────────────────── フロントページの続き (72)発明者 鳥居 俊一 神奈川県川崎市麻生区王禅寺1099番地 株式会社日立製作所 システム開発研究 所内 (56)参考文献 特開 昭63−318628(JP,A) 浅野,外3名「高速データベースマシ ンHDMのアーキテクチャ」情報処理学 会研究報告(89−ARC−78−1),V ol.89,No.74,1989(平1−9− 19) 「特集 並列マシン向けDBMS技術 90年代半ばの実用化めざす」日経エレ クトロニクス,No.586,pp.91− 106(平5−7−19) (58)調査した分野(Int.Cl.7,DB名) G06F 17/30 G06F 12/00 JICSTファイル(JOIS)

Claims (18)

    (57)【特許請求の範囲】
  1. 【請求項1】 設定された複数のキーレンジと、記憶装
    置に設けられた複数のデータ格納領域とを対応付け、キーレンジを追加する要求を受け付けた場合、当該キー
    レンジ及びデータ格納領域に関する情報を該要求に含
    み、当該キーレンジ及び当該データ格納領域を対応付け
    することを特徴とするデータベース管理方法。
  2. 【請求項2】 設定された複数のキーレンジと、記憶装
    置に設けられた複数のデータ格納領域とを対応付け、 キーレンジを分割する要求を受け付けた場合、分割され
    る元の第1のキーレンジ及びデータ格納領域、分割する
    先の複数の第2のキーレンジ及びデータ格納領域に関す
    る情報を該要求に含み、当該第1のキーレンジを当該複
    数の第2のキーレンジに分け、当該複数の第2のキーレ
    ンジ及びデータ格納領域を対応付けすることを特徴とす
    るデータベース管理方法。
  3. 【請求項3】 設定された複数のキーレンジと、記憶装
    置に設けられた複数のデータ格納領域とを対応付け、 キーレンジを併合する要求を受け付けた場合、併合され
    る元の複数の第1のキーレンジ及びデータ格納領域、併
    合する先の第2のキーレンジ及びデータ格納領域に関す
    る情報を該要求に含み、当該複数の第1のキーレンジを
    当該第2のキーレンジに合わせ、当該第2のキーレンジ
    及びデータ格納領域を対応付けすることを特徴とするデ
    ータベース管理方法。
  4. 【請求項4】 設定された複数のキーレンジと、記憶装
    置に設けられた複数のデータ格納領域とを対応付け、 キーレンジを削除する要求を受け付けた場合、該要求に
    かかるキーレンジ及びデータ格納領域のペアを含まない
    ようにデータ格納領域とキーレンジを対応付けることを
    特徴とするデータベース管理方法。
  5. 【請求項5】 請求項1から請求項4のいずれかに記載
    のデータベース管理方法において、 データ格納領域に格納されるデータの上限値、下限値、
    値の範囲、及びデータ格納領域の個数から決められる値
    の範囲の少なくとも1つを、キーレンジを特定 する値と
    することを特徴とするデータベース管理方法。
  6. 【請求項6】 設定された複数のキーレンジと、記憶装
    置に設けられた複数のデータ格納領域とを対応付けて格
    納する第1の手段と、 キーレンジを迫加する要求を受け付けた場合、当該キー
    レンジ及びデータ格納領域に関する情報を該要求に含
    み、当該キーレンジ及び当該データ格納領域を対応付け
    する第2の手段とを備えたことを特徴とするデータベー
    ス管理システム。
  7. 【請求項7】 設定された複数のキーレンジと、記憶装
    置に設けられた複数のデータ格納領域とを対応付けて格
    納する第1の手段と、 キーレンジを分割する要求を受け付けた場合、分割され
    る元の第1のキーレンジ及びデ一タ格納領域、分割する
    先の複数の第2のキーレンジ及びデータ格納領域に関す
    る情報を該要求に含み、当該第1のキーレンジを当該複
    数の第2のキーレンジに分け、当該複数の第2のキーレ
    ンジ及びデータ格納領域を対応付けする第2の手段とを
    備えたことを特徴とするデータベース管理システム。
  8. 【請求項8】 設定された複数のキーレンジと、記憶装
    置に設けられた複数のデータ格納領域とを対応付けて格
    納する第1の手段と、 キーレンジを併合する要求を受け付けた場合、併合され
    る元の複数の第1のキーレンジ及びデータ格納領域、併
    合する先の第2のキーレンジ及びデータ格納領域に関す
    る情報を該要求に含み、当該複数の第1のキーレンジを
    当該第2のキーレンジに合わせ、当該第2のキーレンジ
    及びデータ格納領域を対応付けする第2の手段とを備え
    たことを特徴とするデータベース管理システム。
  9. 【請求項9】 設定された複数のキーレンジと、記憶装
    置に設けられた複数のデータ格納領域とを対応付けて格
    納する第1の手段と、 キーレンジを削除する要求を受け付けた場合、該要求に
    かかるキーレンジ及びデータ格納領域のペアを含まない
    ようにデータ格納領域とキーレンジを対応付けする第3
    の手段とを備えたことを特徴とするデータベース管理シ
    ステム。
  10. 【請求項10】 請求項6から請求項9のいずれか記載
    のデータベース管理システムにおいて、 上記第2の手段は、データ格納領域に格納されるデータ
    の上限値、下限値、値の範囲、及びデータ格納領域の個
    数から決められる値の範囲の少なくとも1つを 、キーレ
    ンジを特定する値とすることを特徴とするデータベース
    管理システム。
  11. 【請求項11】 設定された複数のキーレンジと、記憶
    装置に設けられた複数のデータ格納領域とを対応付け、 上記キーレンジの分割が必要な場合、上記キーレンジを
    分割し、上記分割したキーレンジをデータ格納領域に対
    応付けることを特徴とするデータベース管理方法。
  12. 【請求項12】 請求項11に記載のデータベース管理
    方法において、 上記分割したキーレンジの少なくとも一つを、上記キー
    レンジに対応付けられていないデータ格納領域に対応付
    けることを特徴とするデータベース管理方法。
  13. 【請求項13】 請求項12に記載のデータベース管理
    方法において、 上記分割したキーレンジに対応するデータを、上記分割
    したキーレンジに対応付けられたデータ格納領域に格納
    することを特徴とするデータベース管理方法。
  14. 【請求項14】 請求項12に記載のデータベース管理
    方法において、 上記分割したキーレンジに対応するデータを、上記分割
    が必要なキーレンジに対応付けられたデータ格納領域か
    ら削除することを特徴とするデータベース管理方法。
  15. 【請求項15】 設定された複数のキーレンジと、記憶
    装置に設けられた複数のデータ格納領域とを対応付けて
    格納する第1の手段と、 上記キーレンジの分割が必要な場合、上記キーレンジを
    分割し、上記分割したキーレンジをデータ格納領域に対
    応付ける第2の手段とを具備したことを特徴とするデー
    タベース管理システム。
  16. 【請求項16】 請求項15に記載のデータベース管理
    システムにおいて、 上記分割したキーレンジの少なくとも一つを、上記キー
    レンジに対応付けられていないデータ格納領域に対応付
    けることを特徴とするデータベース管理システム。
  17. 【請求項17】 請求項16に記載のデータベース管理
    システムにおいて、 上記分割したキーレンジに対応するデータを、上記分割
    したキーレンジに対応付けられたデータ格納領域に格納
    することを特徴とするデータベース管理システム。
  18. 【請求項18】 請求項16に記載のデータベース管理
    システムにおいて、 上記分割したキーレンジに対応するデータを、上記分割
    が必要なキーレンジに対応付けられたデータ格納領域か
    ら削除することを特徴とするデータベース管理システ
    ム。
JP2000347725A 2000-11-15 2000-11-15 データベース管理方法およびシステム Expired - Fee Related JP3236999B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2000347725A JP3236999B2 (ja) 2000-11-15 2000-11-15 データベース管理方法およびシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2000347725A JP3236999B2 (ja) 2000-11-15 2000-11-15 データベース管理方法およびシステム

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP28927299A Division JP3156199B2 (ja) 1993-11-16 1999-10-12 データベース管理方法およびシステム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2001130602A Division JP3806609B2 (ja) 2001-04-27 2001-04-27 並列データベースシステムおよび分散ファイルシステム

Publications (2)

Publication Number Publication Date
JP2001175629A JP2001175629A (ja) 2001-06-29
JP3236999B2 true JP3236999B2 (ja) 2001-12-10

Family

ID=18821409

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000347725A Expired - Fee Related JP3236999B2 (ja) 2000-11-15 2000-11-15 データベース管理方法およびシステム

Country Status (1)

Country Link
JP (1) JP3236999B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005092862A (ja) * 2003-08-11 2005-04-07 Hitachi Ltd 負荷分散方法及びクライアント・サーバシステム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
「特集 並列マシン向けDBMS技術 90年代半ばの実用化めざす」日経エレクトロニクス,No.586,pp.91−106(平5−7−19)
浅野,外3名「高速データベースマシンHDMのアーキテクチャ」情報処理学会研究報告(89−ARC−78−1),Vol.89,No.74,1989(平1−9−19)

Also Published As

Publication number Publication date
JP2001175629A (ja) 2001-06-29

Similar Documents

Publication Publication Date Title
JP3023441B2 (ja) データベース分割管理方法および並列データベースシステム
US6510428B2 (en) Method and system of database divisional management for parallel database system
US6192359B1 (en) Method and system of database divisional management for parallel database system
US6567806B1 (en) System and method for implementing hash-based load-balancing query processing in a multiprocessor database system
JPH06314299A (ja) データベース管理方法
JP2006302307A (ja) 記憶装置管理方法
JPH06309284A (ja) 問合せ処理負荷分散方法
JP3806609B2 (ja) 並列データベースシステムおよび分散ファイルシステム
JP3060225B2 (ja) デ―タベ―ス管理方法およびシステム
JP3172793B1 (ja) データベース管理方法
JP3236999B2 (ja) データベース管理方法およびシステム
CN112000666B (zh) 一种面向列的数据库管理系统
JP3156199B2 (ja) データベース管理方法およびシステム
JP3599055B2 (ja) 記憶装置管理方法およびシステム
JP3060223B2 (ja) デ―タベ―ス管理方法およびシステム
JP3060222B2 (ja) デ―タベ―ス管理方法およびシステム
JP3060224B2 (ja) デ―タベ―ス管理方法およびシステム
JP3838248B2 (ja) データ格納方法およびデータ管理システム
JP4349463B2 (ja) 記憶装置管理方法
JP3538322B2 (ja) データベース管理システムおよび問合せの処理方法
JP3367510B2 (ja) データベース管理方法およびシステム
JP3438699B2 (ja) データベース管理方法およびシステム
JP3668243B2 (ja) データベース管理システム
JP2003223344A (ja) データベース管理方法
JP2748986B2 (ja) バッファ管理方式

Legal Events

Date Code Title Description
FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20071005

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20081005

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091005

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091005

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101005

Year of fee payment: 9

LAPS Cancellation because of no payment of annual fees