JP4199888B2 - データベース管理方法 - Google Patents
データベース管理方法 Download PDFInfo
- Publication number
- JP4199888B2 JP4199888B2 JP32365799A JP32365799A JP4199888B2 JP 4199888 B2 JP4199888 B2 JP 4199888B2 JP 32365799 A JP32365799 A JP 32365799A JP 32365799 A JP32365799 A JP 32365799A JP 4199888 B2 JP4199888 B2 JP 4199888B2
- Authority
- JP
- Japan
- Prior art keywords
- database
- storage area
- data
- hash
- database storage
- 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 - Lifetime
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、時系列的に増加していくデータを新たに増設したデータベース格納領域にデータを再配置することによって、データベースの大規模化の運用を行うデータベース管理システムに関する。
【０００２】
【従来の技術】
一般的にデータベースを有するデータベースシステムでは、データベースに保有する情報は時々刻々変化している。その情報は時間経過と共に新たな情報が追加され、あらかじめ用意したデータベースを格納するためのデータベース格納領域の容量よりも大きくなる場合がある。
【０００３】
そのため、大規模なデータベースを扱う場合、あらかじめデータベースを複数のデータベース格納領域に分割して格納する方法が採用される。複数のデータベース格納領域に分割格納する分割手段として、キー・レンジ分割、ハッシュ分割、均等分割といった手段が用意される。各々の分割手段によって、分割したパーティションを指定したデータベース領域と１対１に対応させたり、複数のパーティションをあるデータベース領域に対応させたりという手法が採られる。時間経過と共に新たな情報が追加される場合、２つのデータベースの拡張方法が考えられる。一つは、分割手段としてキーレンジ分割が採用されている場合、新たなキーレンジを追加したり、あるキーレンジを分割するといった方法がある。これは、新たにデータベース領域を追加することなく操作することも可能である。もう一つは、分割手段は変更しないで新たにデータベース領域を追加または既存のデータベース領域を拡張する方法がある。これは、容量の増大に伴ってデータベース格納領域を増分させる方法である。これに対して、分割手段としてハッシュ分割を採用すると、分割に対するオーバヘッドが少なく、データの増加に対する柔軟性が高い。
【０００４】
ただし、あらかじめ用意したデータベース格納領域は時間と共に新たな情報が追加されるだけでなく、過去の古いデータを削除する場合もあり、必ずしも常にデータベース格納領域の容量よりも大きくなるわけではない。このような場合は、データベース再編成を行うことによって古いデータを削除することによって空きを作成し、新たに追加される情報を格納するために使用するようにすることで解決される。
【０００５】
しかし、過去のデータを延々と蓄積していくようなデータベースシステムでは、将来予測されるデータ量を想定し、あらかじめデータベース格納領域を用意しておくのは資源管理コストがかかるため、当面、予想されるデータ量まで格納できるデータベース領域を準備しておき、実際にデータ量の増加に伴って新たなデータベース格納領域が必要になった時点でデータベース格納領域を追加する運用を行う。
【０００６】
データベースに対するデータベース格納領域の追加は、データベースの定義変更を伴う。最も単純な方法としては、データベースの内容を一旦バックアップし、データベース格納領域の追加を行う定義変更処理を行った後、バックアップしたデータベースを再ローディングするという方法がある。ただし、この方法では大規模データベースの場合、バックアップを取得する時間及びバックアップ媒体等にかかるコストが非常に高く、再ローディングする処理も膨大な時間を要する。
【０００７】
第１の公知例として、米国特許４，４１２，２８５がある。本公知例では、表をハッシュ分割するが、あらかじめ複数のバケットに分割し、いくつかのバケットを仮想プロセッサに対応させて管理する技術が開示されている。
【０００８】
第２の公知例として、特開平６−１３９１１９号公報には、複数のプロセッサで構成される並列データベースシステム上に分割されたデータベースをアクセス頻度によってデータを再編成する技術が開示されている。
【０００９】
第３の公知例として、特開平６−３１４２９９号公報には、複数のプロセッサで構成される並列データベースシステム上に、階層的にデータベースを分割する技術が開示されている。
【００１０】
第４の公知例として、特開平７−１４１３９４号公報には、複数のプロセッサで構成される並列データベースシステム上に分割されたデータベースに対して、第５の公知例として、特開平９−２９３００６号公報には、ハッシュ関数を使用した分割方法を示し、データベース分割数が変更された場合にデータの再配置を必要とせず、データを新規追加した格納領域に格納しようとする技術が開示されている。ただし、本公知例ではデータの再配置は必要ないが、検索時には分割したすべての記憶装置を検索するようになっている。
【００１１】
【発明が解決しようとする課題】
従来技術における前者の方法の場合、データベースの大規模化についての問題が生じる。データベースの大規模化によって再配置が必要になるのは、データベース領域中の表に対するデータの追加が行われることによって、あらかじめ与えられたデータベース格納領域の空きがなくなる場合である。
【００１２】
上述したハッシュ分割を採用したデータベースの場合、ハッシング結果は分割数すなわち与えられたデータベース格納領域数に依存するため、新たにデータベース格納領域を追加する場合、それまで蓄積したデータをすべて新しい分割数の元でハッシングをやりなおし再格納しなければならない。これは、非常に膨大な時間と資源を浪費することになり、効率良くシステムを運用することができない。
【００１３】
また、再格納しないで既存の各データベース格納領域から、再配置処理として再ハッシュした結果によって他のデータベース格納領域にデータを移動させる場合、結局、各データベース格納領域中のすべてのデータを読み込まなければならず、再ハッシュしても同じデータベース格納領域内に残るデータがある場合でも無駄なデータの読み込みが生じてしまう。
【００１４】
本発明の第１の目的は、ハッシュ分割したデータベースに対してデータベース格納領域を追加する場合に、既存のデータベース格納領域から新たに追加したデータベース格納領域に対して最も少ないコストでデータを再配置することを可能とするデータベース格納管理方法を提供することにある。
【００１５】
【課題を解決するための手段】
前記目的を達成するために、本発明は、一つ又は複数の外部記憶装置から構成されるデータベース格納領域を管理し、前記データベース格納領域は物理的に固定長の複数のページから構成される複数のセグメントを管理するデータベース管理方法において、データベースの格納領域としてｍ個のデータベース格納領域が与えられた場合、データベースの一つ又は複数のデータ項目をパーティショニングキーとし、前記データベースを前記パーティショニングキーに対してハッシュ関数を適用し、ｎ（ｍ≦ｎ）個の論理的な単位であるバケットに分割し、当該与えられたデータベース格納領域数に応じて各バケットを管理するデータベース格納領域の対応を決定するハッシュマップ表と、分配されたバケットを各データベース格納領域内の格納単位であるセグメントとマッピングさせるためのセグメントハッシュマップ表によってデータベースを管理することを特徴とするデータベース管理方法を提供する。
【００１６】
【発明の実施の形態】
以下、本発明の一実施例を添付図面を用いて具体的に説明する。
【００１７】
図２は本実施形態のコンピュータシステムのハードウエア構成の一例を示す図である。コンピュータシステム１０は、ＣＰＵ１２、主記憶装置１４、磁気ディスク装置等の外部記憶装置２０及び多数の端末３０で構成される。主記憶装置１４上には、データベース管理システム４０が置かれ、複数の外部記憶装置２０を使用してデータベース管理システム４０が管理するデータベースを格納するデータベース領域５０ａ，５０ｂ，５０ｃ，５０ｄ、データベースの定義情報を管理するデータベース定義情報格納領域６０およびデータベースに対する更新操作に関する更新履歴情報を管理するデータベースログ格納領域７０が構成される。。さらに、データベース管理システム４０を実現するプログラムも外部記憶装置２０上に格納される。
【００１８】
図１は本発明におけるデータベースの管理形態を示す。図２で示したデータベース定義情報格納領域６０では、データベースシステムを構成するデータベース格納領域やデータベースの定義情報が格納される。データベース格納領域管理表６１は、データベースシステム内のデータベースを格納する領域として定義されたデータベース格納領域に関する情報を管理する。データベース格納領域構成ファイル管理表６２は、データベース格納領域定義時に指定された図２に示す外部記憶装置上に割り当てたファイルの構成に関する情報を管理する。データベース管理表６３は、特にリレーショナルデータベース管理システムのような場合に定義された表を管理する。データベース構成列管理表６４は、定義された表を構成する列に関する情報を管理する。データベース分割管理表６５は、表定義時にデータベースシステム内に定義されたデータベース格納領域を指定してデータを分割して格納した場合の表とデータベース格納領域の関連情報を持つ。ハッシュマップ表６６は、本発明で必要とするデータベース内に定義された表を複数のデータベース格納領域に分割して格納する場合に、その分割方法としてハッシュ分割方法が指定されると、指定されたデータベース格納領域数に対応してハッシュバケットに分割した場合の各ハッシュバケットをどのデータベース格納領域に格納するかを決定する対応表を持つ。
【００１９】
次に、データベース格納領域５０ａ，５０ｂ，５０ｃ，５０ｄの構成について説明する。ハッシュ分割された表について、データベース格納領域内での管理方法を示す。定義された表について、ハッシュバケットに分割する場合、ハッシュマップ表によってハッシュバケットの要素番号が決定されると、決定された要素番号のハッシュバケットのデータを格納する物理的に固定長の複数のページから構成されるセグメント５４にデータを格納した場合の先頭セグメント番号を管理するセグメントハッシュマップ表５１と、データベース格納領域内に確保されたすべてのセグメントの割当をビットマップとして管理するためのセグメントビットマップ表５２と、割り当てたセグメント５４内のページの割当をビットマップとして管理し、なおかつ、同じハッシュバケットの要素番号で複数のセグメントが割り当てられる場合にセグメント間のチェインを管理するページビットマップ表５３から構成される。
【００２０】
図３は、図２で示したデータベース定義情報格納領域６０に格納されたデータベース定義情報の一実施例として詳細に示したものである。データベース格納領域として、ＤＤＩＣＡＲＥＡ，ＤＢＡＲＥＡ１，ＤＢＡＲＥＡ２，ＤＢＡＲＥＡ３，ＤＢＡＲＥＡ４が定義されている場合にデータベース格納領域管理表６１及びデータベース格納領域構成ファイル管理表６２に格納された情報を示す。データベース格納領域管理表６１は、データベース領域名、種別、構成ファイル数、サーバ名、ページ長、セグメントサイズ及びセグメント数の列から構成される。また、データベース格納領域構成ファイル管理表は、データベース領域名、番号、及び構成ファイル名の列で構成される。当該データベースでは、ＤＤＩＣＡＲＥＡというデータベース格納領域が定義されると、その種別としてデータベース定義情報格納領域であることを示す’Ｄ’という情報で識別され、当該データベース格納領域を構成するファイル数である１、図１におけるデータベース格納領域で示したセグメント５４を構成するページのサイズであるページ長として４０９６バイト、当該セグメントを構成するページ数として５０ページ、さらに当該データベース格納領域に割り当てられるセグメント数５０が定義情報として格納される。同様に、ＤＢＡＲＥＡ１，ＤＢＡＲＥＡ２，ＤＢＡＲＥＡ３，ＤＢＡＲＥＡ４が定義されると、データベース格納領域の種別としてデータベース格納領域であることを識別する’Ｕ’、及び構成ファイル数、サーバ名、ページ長、セグメントサイズ、セグメント数の情報が各々格納される。これに対して、データベース格納領域構成ファイル管理表６２には、各データベース格納領域を構成するファイル名と複数のファイルで構成される場合には、その通番が情報として格納される。
【００２１】
次に当該データベースで「ＺＡＩＫＯ」表が定義された場合について、当該表の定義情報がデータベース管理表６３、データベース構成列管理表６４、及びデータベース分割管理表６５にどのように格納されるかについて説明する。「ＺＡＩＫＯ」表の定義文の一例を示す。
【００２２】
上記定義によって、「ＺＡＩＫＯ」表は４つの列ＳＣＯＤＥ，ＳＮＡＭＥ，ＣＯＬ，ＴＡＮＫＡ，ＺＳＵＲＹＯで構成され、ＳＣＯＤＥ列をパーティショニングキーとしてハッシュ分割し、ハッシュ分割したデータは、データベース格納領域ＤＢＡＲＥＡ１，ＤＢＡＲＥＡ２，ＤＢＡＲＥＡ３，ＤＢＡＲＥＡ４に分割して格納するよう指示されている。当該定義内容によって、データベース管理表６３には表名、所有者、構成列数、分割方法、指定したデータベース格納領域数を示す分割数、及びパーティショニングキー情報としてＳＣＯＤＥ列であることを示すためデータベース構成列管理表内の列番号が格納される。データベース構成列管理表６４には、「ＺＡＩＫＯ」表を構成する５つの列の定義情報として、列名、表名、所有者、表を構成する列の順番を示す列番号、データ型、データ長が格納される。さらに、データベース分割管理表６５には、「ＺＡＩＫＯ」表を４つのデータベース格納領域に分割して格納するため、表名、データベース格納領域の定義順を示す番号、及びデータベース格納領域名が格納される。
【００２３】
図４では、図２に示したハッシュマップ表６６を示す。本発明の実施例として当該データベースでは、データベースの表を複数のデータベース格納領域に分割する場合の最大データベース格納領域数を５１２とする。また、このとき、ハッシュ分割での最大ハッシュバケット数を１，０２４とする。ハッシュマップ表６６は、一つ一つの表のハッシュバケットの要素番号とデータベース格納領域との対応を示すようにする方法も考えられるが、データベース定義情報格納領域６０の容量増大を防止するため、２〜５１２分割までのすべてのデータベース格納領域指定数に応じ、ハッシュ関数によって求められたハッシュバケット要素番号と図３に示したデータベース分割管理表の「番号」列の値との対応表を持つようにしている。最も簡単な例として２分割の例を挙げる。２分割の場合、ハッシュマップ表の第１エントリを参照し、ハッシュバケット要素番号の０〜５１１までがデータベース格納領域の指定番号の０に格納することを示し、ハッシュバケット要素番号の５１２〜１０２３まではデータベース格納領域の指定番号の１に格納することを示す。それに対して、該当する表のデータベース分割管理表の番号０および１を参照してデータベース格納領域が決定される。次に、３分割の場合は、２分割状態のデータベースから１つのデータベース格納領域が追加された場合に追加されたデータベース格納領域に対して既存の２つの分割されたデータベース格納領域のハッシュバケットから３分の１ずつハッシュバケットを移動するようにさせたハッシュマップ表となる。したがって、ハッシュバケット要素番号０〜３４１までの３４２個のハッシュバケットがデータベース分割管理表の指定番号０のデータベース格納領域に格納することを示し、ハッシュバケット要素番号５１２〜８５３までの３４１個のハッシュバケットがデータベース分割管理表の指定番号１のデータベース格納領域に格納することを示し、ハッシュバケット要素番号３４２〜５１１及び８５４〜１０２３までの合計３４１個のハッシュバケットがデータベース分割管理表の指定番号２のデータベース格納領域に格納することを示す。３分の１に分ける場合、割り切れない場合にはデータベース分割管理表の指定番号の小さい方にハッシュバケットが多く残るように調整する。これによって、データの再配置が行われる場合に少しでも移動するデータ量を削減できる。さらに４分割の場合も同様に、３分割状態のデータベースから１つのデータベース格納領域が追加された場合に追加されたデータベース格納領域に対して既存の３つの分割されたデータベース格納領域のハッシュバケットから４分の１ずつハッシュバケットを移動するようにさせたハッシュマップ表となる。この場合、ハッシュバケット要素番号０〜２５５までの２５６個のハッシュバケットがデータベース分割管理表の指定番号０のデータベース格納領域に格納することを示し、ハッシュバケット要素番号５１２〜７６７までの２５６個のハッシュバケットがデータベース分割管理表の指定番号１のデータベース格納領域に格納することを示し、ハッシュバケット番号３４２〜４６９までの１２８個、ハッシュバケット要素番号８５４〜９８１までの１２８個の合計２５６個のハッシュバケットがデータベース分割管理表の指定番号２のデータベース格納領域に格納することを示し、ハッシュバケット要素番号２５６〜３４１までの８６個、ハッシュバケット要素番号４７０〜５１１までの４２個、ハッシュバケット要素番号７６８〜８５３までの８５個、ハッシュバケット要素番号９８２〜１０２３までの４３個の合計２５６個のハッシュバケットがデータベース分割管理表の指定番号３のデータベース格納領域に格納することを示す。このようにして、最大分割数である５１２分割までのハッシュバケットの対応表が保持されている。したがって、データベースの表定義時に決定したデータベース格納領域数によって参照するハッシュマップ表のエントリを決定すればよいことになる。
【００２４】
次に、図１におけるセグメントハッシュマップ表５１、セグメントビットマップ表５２、ページビットマップ表５３、およびセグメント５４に関して図５のデータベースの表へのデータ挿入処理の概略フローおよび図６を用いて詳細に示す。データベースの表に対してデータの挿入処理要求が行われる場合、「ＺＡＩＫＯ」表を例にとると以下のような要求がデータベース管理システムに対して発行される。
【００２５】
INSERT INTO ZAIKO VALUES('101','ブラウス','red',35000,62)
上記、要求が与えられた場合、まず、図２におけるデータベース定義情報格納領域６０からデータベース定義情報を取得する（ステップ４１０）。取得した情報の中から、「ＺＡＩＫＯ」表はパーティショニングキーＳＣＯＤＥ列でハッシュ分割することが判明する。したがって、ＳＣＯＤＥ列に指定された値’１０１’に対してハッシュ関数を施す（ステップ４１１）。ハッシュ関数を施した結果、図４におけるハッシュマップ表のハッシュバケット要素番号が決定される。ここでは、ハッシュバケット要素番号が２５６となったとする。そして、当該「ＺＡＩＫＯ」表はデータベース格納領域４つに分割することが与えられているので、図４におけるハッシュマップ表の分割数４のハッシュマップ表のハッシュバケット要素番号２５６のエントリを参照し、データベース分割管理表内の番号３がデータ格納するデータベース格納領域であることがわかる（ステップ４１２）。データベース分割管理表の「番号」列が３であるデータベース格納領域名を検索することによって、データベース格納領域名が’ＤＢＡＲＥＡ４’であることが確定する。データベース格納領域が決定したので、次にデータベース格納領域’ＤＢＡＲＥＡ４’内の格納するセグメントを決定するため、「ＺＡＩＫＯ」表のセグメントハッシュマップ表５１を参照する。セグメントハッシュマップ表５１を参照する場合、先ほど求めたハッシュバケット要素番号２５６を使ってセグメントハッシュマップ表内の配列番号２５６のエントリを参照する（ステップ４１３）。ここで、セグメントハッシュマップ表６６内の配列番号２５６には、図６で示すように当該ハッシュバケット要素番号を持つデータのセグメント数及びセグメント先頭ポインタとして先頭セグメント管理テーブルの番号が保持されている。ステップ４１４によって、このセグメント数が０又は先頭セグメント管理テーブルの番号が０かどうかを判定することによってセグメントが割り当てられているか否かをチェックする。もし、０の場合はまだセグメントが割り当てられていない、すなわち、当該ハッシュバケット要素番号に該当するデータが１件も格納されていないので、図１におけるセグメントビットマップ表を参照し、セグメントを確保する処理を行う（ステップ４１５）。図１におけるセグメントビットマップ表５２は、当該データベース格納領域内に確保できる全セグメント数分のビットマップで管理されており、空きビットをサーチすることによって見つかった空きセグメントを新規セグメントとして確保する。そして確保したセグメントのページ割当状況を管理するセグメント管理テーブルを図１におけるページビットマップ表５３から確保し、セグメントハッシュマップ表の配列番号２５６のエントリにセグメント数として１を設定し、セグメント先頭ポインタとして確保したセグメント番号を設定する。また、確保したセグメント管理テーブルには、次のセグメントがまだ割り当てられていないことを示すため、ＮＥＸＴポインタには０を設定する（ステップ４１６）。次に、確保したセグメントからデータを格納するページを決定する。新規に確保したセグメントの場合、セグメント管理テーブル中に含まれるページビットマップ領域はすべてのビットが空きページの状態となる。先頭ページを使用することを決定し、先頭ビットを使用状態に更新する。また、ステップ４１４によってすでに該当ハッシュバケットのセグメントが確保されている場合は、セグメント管理テーブルのチェインをたどり、最終セグメントのセグメント管理テーブルのページビットマップ領域を参照し、最終ページ番号をアクセスする。最終ページ番号のページを入力し、挿入するレコード（行）が格納できる空き領域が存在すれば当該ページを挿入ページとして決定する（ステップ４１７）。もし、空き領域が存在しなければ先ほどのセグメント管理テーブルから空きページを検索し、空きページがあれば当該ページを挿入ページとして決定する。さらに、当該セグメント中に空きページが存在しない場合は、セグメントビットマップ表を検索し、空きセグメントを確保するようにする。空きセグメントも存在しない場合は、ハッシュバケット要素番号に該当するすべてのセグメント管理テーブルのチェインを辿り、核セグメント管理テーブルから空きページをサーチすることによって挿入ページを決定する。それでも、空きページが存在しない場合は、当該データベース格納領域内に空き領域が存在しないことになり、挿入不可となる。こうして、正常に決定された挿入ページに行を格納することによって行の挿入処理が完了する（ステップ４１８）。行挿入に際しては、当然であるが図２におけるデータベースログ格納領域７０に対して挿入処理に関するログを取得しておく必要がある。
【００２６】
以上のように行を挿入する場合、ハッシュ関数によって定められたデータベース格納領域を決定し、さらにデータベース格納領域内でもハッシュバケット要素番号に該当するセグメントにデータを格納するため、他のパーティショニングキー値によって求められた異なるハッシュバケット要素番号のデータは明確に別セグメントに格納される。さらに、複数のユーザから行を挿入する要求が発生した場合、同じデータベース格納領域内であっても分割キー値が異なれば格納するセグメントも異なるので、同一セグメントへの挿入といった競合を大幅に抑止することも可能になる。
【００２７】
次に、データベースに対する問合せとして検索要求が発行された場合の検索処理の処理の流れを図７に示す。データベースの表に対してデータの検索処理要求が行われる場合、「ＺＡＩＫＯ」表を例にとると以下のような要求がデータベース管理システムに対して発行される。
【００２８】
SELECT SCODE,SNAME,COL,TANKA,ZSURYO FROM ZAIKO WHERE SNO='101'
上記要求が与えられた場合、まず、図２におけるデータベース定義情報格納領域６０からデータベース定義情報を取得する（ステップ４２０）。取得した情報の中から、「ＺＡＩＫＯ」表はパーティショニングキーＳＣＯＤＥ列でハッシュ分割していることが判明する。次に当該検索要求の探索条件中にパーティショニングキーであるＳＣＯＤＥ列に対する条件指定があるか否かをチェックする（ステップ４２１）。当該問い合わせの場合、ＳＮＯ列に対する条件が指定されているので、ハッシュ関数を適用することによってデータベース格納領域を決定する。ハッシュ関数を施した結果、図３におけるハッシュマップ表のハッシュバケット要素番号が決定される。ここでは、ハッシュバケット要素番号が２５６となったとする。そして、当該「ＺＡＩＫＯ」表はデータベース格納領域４つに分割することが与えられているので、図４におけるハッシュマップ表の分割数４のハッシュマップ表のハッシュバケット要素番号２５６のエントリを参照し、データベース分割管理表内の番号３がデータ格納するデータベース格納領域であることがわかる（ステップ４２３）。データベース分割管理表の「番号」列が３であるデータベース格納領域名を検索することによって、データベース格納領域名が’ＤＢＡＲＥＡ４’であることが確定する。データベース格納領域が決定したので、次にデータベース格納領域’ＤＢＡＲＥＡ４’内の当該ハッシュバケット要素番号に該当するセグメントを決定するため、「ＺＡＩＫＯ」表のセグメントハッシュマップ表５１を参照する。セグメントハッシュマップ表５１を参照する場合、先ほど求めたハッシュバケット要素番号２５６を使ってセグメントハッシュマップ表内の配列番号２５６のエントリを参照する（ステップ４２４）。セグメントハッシュマップ表の配列番号２５６のエントリ中に設定された先頭セグメント管理テーブル番号が存在する場合は、セグメント管理テーブルのチェインを辿りながら、全セグメントの割当ページを検索対象として探索条件を評価する（ステップ４２５）。もし、該当するエントリ中にセグメント番号が設定されていない場合は検索対象データがないということになり、検索結果は０件となる。また、ステップ４２１によってパーティショニングキーであるＳＮＯ列に対する条件指定がない場合は、すべてのデータベース格納領域が検索対象になる。すべてのデータベース格納領域が検索対象となった場合、各データベース格納領域内のセグメントハッシュマップ表に設定されたセグメント番号が０でないものを対象に各要素番号のセグメントチェインを辿りながら探索条件評価を行う（ステップ４２６ないし４２７）。
【００２９】
以上のようにデータベース検索の場合、パーティショニングキーに対する条件が指定されると、検索対象となるデータベース格納領域を絞り込むだけでなく、データベース格納領域内のセグメントを絞り込むことができるので、アクセスする必要のないセグメントを検索対象から除外することができる。
【００３０】
本発明によるデータベース分割格納方法を用い、データの再配置を行う場合の実施例を図８及び図９を用いて説明する。データベースシステム構成としては、図２に示した構成を用い、データベースの定義としては、図３で示した「ＺＡＩＫＯ」表を用いて、当該「ＺＡＩＫＯ」表に対して新規にデータベース格納領域「ＤＢＡＲＥＡ５」を追加する場合のデータベース再配置処理の流れを図８に示し、その場合のデータベースのデータの移動方法を図９に示す。データベース再配置処理は、図９に示したようにデータベース管理システム４０内の一つの処理プログラムであるデータベース再配置処理部４３０として動作する。まず、データベース再配置処理要求としてデータベース格納領域「ＤＢＡＲＥＡ５」の追加が要求されると、新規に追加したデータベース格納領域を含めた分割数でのハッシュマップ表を図４に示した各分割数毎のハッシュマップ対応表から求める（ステップ４３１）。ここでは、４分割されたデータベースに対してデータベース格納領域を一つ追加するので５分割の場合のハッシュマップ表を求めることになる。次に求めたハッシュマップ表から追加データベース格納領域が管理するハッシュバケット要素番号を抜き出したリストを作成する（ステップ４３２）。つまり、５分割の場合のハッシュマップ表の各配列の中の番号が４である配列番号をハッシュバケット要素番号として取り出せば良い。こうして追加したデータベース格納領域が管理すべきハッシュバケット要素番号が判明したので、現在の分割数である４分割のハッシュマップ表を参照し、先ほど取り出したハッシュバケット要素番号のハッシュバケットを現在管理しているデータベース格納領域の番号を取得する（ステップ４３３）。データベース格納領域の番号が判明すれば、図３におけるデータベース定義情報格納領域６０中のデータベース分割管理表６５からデータベース格納領域名を得ることができる。こうして得られた追加したデータベース格納領域への移動対象となるハッシュバケット要素番号と既存のデータベース格納領域との対応表を作成し、既存のデータベース格納領域毎に移動対象ハッシュバケット要素番号をソートするように対応表を作成しておくと処理を既存のデータベース格納領域毎に行えるようにすることができる。まず、データベース格納領域「ＤＢＡＲＥＡ１」から処理を開始する。図９を用いながら説明する。データベース格納領域「ＤＢＡＲＥＡ１」からは、ハッシュバケット要素番号０から２５５までの５分の１であるハッシュバケット要素番号２０４から２５５までが移動対象となり、図８における移動対象セグメント抽出処理（ステップ４３４）では、図９におけるデータベース格納領域「ＤＢＡＲＥＡ１」５０ａ中のセグメントハッシュマップ表５１ａを参照し、ハッシュバケット要素番号２０４から順番に２５５までのセグメント先頭番号を取出しながら、ページビットマップ表５３ａ中のセグメント管理テーブルのチェインを辿り、セグメント５４ａをセグメント入出力バッファ４２に読み込む。セグメント入出力バッファにはセグメント単位で読み込み処理を行うが、各セグメント管理テーブルのページビットマップ領域を参照することによって使用されていない、すなわち空きページについては読み込まないようにするか、移動先のデータベース格納領域の当該セグメントを割り当てた際にページビットマップ情報もコピーすればセグメント単位で読み込んでも問題ない。こうしてセグメント入出力バッファ４２に読み込んだセグメントを追加データベース格納領域「ＤＢＡＲＥＡ５」５０ｅに反映する処理を行う（ステップ４３５）。反映処理とは、次の手順で行われる。
【００３１】
（１）セグメント単位で処理を行うので追加データベース格納領域「ＤＢＡＲＥＡ５」５０ｅ中のセグメントビットマップ表から空きビットをサーチし、新規に１個のセグメントを確保する。
【００３２】
（２）新規に当該ハッシュバケット用のセグメントを確保した場合は、セグメントハッシュマップ表５３ａの先頭セグメント先頭ポインタを更新する。このとき、当該ハッシュバケット用セグメント数に１を加える。
【００３３】
（２）確保したセグメントを管理するセグメント管理テーブルをページビットマップ表５３ｅから確保する。確保したセグメント管理テーブル内のページビットマップは、移動前のページビットマップ内容をコピーすればよい。このとき、当該ハッシュバケット用のセグメントがすでに割り当てられている場合はセグメント管理テーブルの最後尾に当該テーブルをチェインさせる。
【００３４】
（３）確保したセグメントに対してセグメント入出力バッファ４２から書きこむ。
【００３５】
上記手順によって反映処理終了後、既存のデータベース格納領域「ＤＢＡＲＥＡ１」５０ａの移動完了したセグメントの削除処理を行う（ステップ４３６）。移動完了したセグメントの削除処理は、次の手順で行われる。
【００３６】
（１）セグメントハッシュマップ表５１ａの該当ハッシュバケット要素番号のセグメント先頭ポインタを参照し、ページビットマップ表５３ａのセグメント管理テーブルをＮＥＸＴポインタを辿りながら、セグメントビットマップ表５２ａ内の該当セグメントのビットを空きビットに更新する。
【００３７】
（２）該当ハッシュバケットのすべてのセグメントについてセグメントビットマップ表５２ａのビットを空きビットに更新したら、セグメントハッシュマップ表内の該当ハッシュバケット要素番号のセグメント数を０に更新する（ステップ４３７）。
【００３８】
以上の手順で各既存のデータベース格納領域内の移動対象となるハッシュバケットすべてを移動したかどうかをチェックし（ステップ４３８）、データベース格納領域「ＤＢＡＲＥＡ４」までステップ４３４から４３７までを行い、すべてのデータベース格納領域の処理が終了した場合、データベース定義情報格納領域６０内のデータベース定義情報を更新する（ステップ４３９）。更新する内容は、追加したデータベース格納領域の情報をデータベース領域管理表６１およびデータベース格納領域構成ファイル菅表に追加し、「ＺＡＩＫＯ」表に追加したデータベース格納領域の情報として、データベース管理表６３の分割数を５に更新し、データベース分割管理表６５には追加したデータベース格納領域「ＤＢＡＲＥＡ５」及び番号として４の情報を追加することである。
【００３９】
このようにデータベースの再配置処理では、各既存のデータベース格納領域から１レコードずつデータを読み込む必要がなく、セグメント単位で読み込み、追加したデータベース格納領域に書きこみを行えばよい。また、移動対象でないハッシュバケットは一切、読み込む必要がない。
【００４０】
次に、本発明によるデータの再配置に関する第２の実施例として並列データベースシステムにおけるデータの再配置処理を示す。
【００４１】
図１０は、並列データベースシステムのハードウエア構成の一例を示す図である。一つのコンピュータシステム１０は、図２と同様にＣＰＵ１２、主記憶装置１４、磁気ディスク装置等の外部記憶装置２０で構成される。当該並列データベースシステムでは。複数のコンピュータシステム及び複数台の端末３０がネットワークに接続されている。当該並列データベースシステムを構成するデータベース管理システム４０内に各処理構成単位が配置される。フロントエンドサーバ４１（以下ＦＥＳと呼ぶ）は、端末３０からの問合せを受信し、問合せの処理手順を生成するコンポーネントである。当該ＦＥＳには、トランザクション等に関するログを記録するためのデータベースログ格納領域７０を持つ。バックエンドサーバ４３ａ，４３ｂ，４３ｃ，４３ｄ（以下、ＢＥＳと呼ぶ）はＦＥＳからの処理手順を受信して、各々ＢＥＳ１，ＢＥＳ２，ＢＥＳ３，ＢＥＳ４が管理するデータベース格納領域５０ａ，５０ｂ，５０ｃ，５０ｄをアクセスすることによってＦＥＳにその処理結果を返す。このとき、各々のデータベース格納領域に対して行われたデータベースの変更に関するログやトランザクションに関するログが、データベースログ格納領域７０ａ，７０ｂ，７０ｃ，及び７０ｄに格納される。データディクショナリサーバ４２（以下、ＤＩＣと呼ぶ）は、データベースに関する定義情報を管理し、その定義情報はデータベース定義情報格納領域７０に格納され、データベース定義情報の変更に関するログやトランザクションに関するログが、データベースログ格納領域７０に格納される。ＦＥＳでは、要求された問合せでアクセスするデータベースの定義情報をＤＩＣから取得する。図１０でも示すように、一つのコンピュータシステム内にＢＥＳを複数配置することができる。これは、一つのコンピュータシステム内に複数のＢＥＳを配置することによって、並列処理能力を高めることができる。ここでは、各々のコンピュータシステムにそれぞれ２つのＢＥＳを配置する構成をとる。当該並列データベースシステムのハードウエア構成を利用し、先に挙げた「ＺＡＩＫＯ」表を定義した場合のデータベース定義情報格納領域７０の管理情報について図１１に示す。非並列データベースシステムの場合の実施例として示した図３のデータベース定義情報格納領域７０とは基本的な管理情報に違いはない。異なる点は、データベース領域管理表６１に含まれるサーバ名である。各データベース格納領域をどのサーバで管理しているかを管理するための情報が付加される。つまり、「ＺＡＩＫＯ」表は４つのデータベース格納領域ＤＢＡＲＥＡ１，ＤＢＡＲＥＡ２，ＤＢＡＲＥＡ３，ＤＢＡＲＥＡ４に分割され、ＤＢＡＲＥＡ１はＢＥＳ１、ＤＢＡＲＥＡ２はＢＥＳ２、ＤＢＡＲＥＡ３はＢＥＳ３、ＤＢＡＲＥＡ４はＢＥＳ４にてデータベース処理を行うようにＦＥＳが処理を振り分けるのである。
【００４２】
次に、当該並列データベースシステムに対して図１０に示すように新規にコンピュータシステムを追加し、データベースコンポーネントとしてＢＥＳ５ ４３ｅを追加し、さらに追加したＢＥＳ５にデータベース格納領域「ＤＢＡＲＥＡ５」を追加した場合に、戦術した「ＺＡＩＫＯ」表のデータの再配置がどう行われるかについて説明する。
【００４３】
最初に、ＢＥＳ５では再配置処理としてデータ受信処理を実行する。図１３にＢＥＳ５におけるデータ受信処理の概略処理フローを示す。ＢＥＳ５では、追加するデータベース格納領域ＤＢＡＲＥＡ５を含めた５分割時のハッシュマップ表をＤＩＣのデータベース定義情報格納領域から取り出す（ステップ４４１）。次に求めたハッシュマップ表から追加データベース格納領域が管理するハッシュバケット要素番号を抜き出したリストを作成する（ステップ４４２）。つまり、５分割の場合のハッシュマップ表の各配列の中の番号が４である配列番号をハッシュバケット要素番号として取り出せば良い。こうして追加したデータベース格納領域が管理すべきハッシュバケット要素番号が判明したので、現在の分割数である４分割のハッシュマップ表を参照し、先ほど取り出したハッシュバケット要素番号のハッシュバケットを現在管理しているデータベース格納領域の番号及びサーバ名をＤＩＣから取得する（ステップ４４３）。データベース格納領域の番号が判明すれば、図１１におけるデータベース定義情報格納領域６０中のデータベース分割管理表６５からデータベース格納領域名を得ることができる。また、各データベース格納領域を管理しているサーバ名はデータベース領域管理表より求めることができる。こうして得られた追加したデータベース格納領域への移動対象となるハッシュバケット要素番号と既存のデータベース格納領域との対応表を作成し、既存のデータベース格納領域毎に移動対象ハッシュバケット要素番号をソートするように対応表を作成しておくと処理を既存のデータベース格納領域毎に行えるようにすることができる。次に、ＢＥＳ５からデータベース格納領域ＤＢＡＲＥＡ１からＤＢＡＲＥＡ４までを管理しているＢＥＳ１からＢＥＳ４に対して、移動対象となるハッシュバケット要素番号とデータベース格納領域を入力情報とし移動対象セグメント抽出処理要求を送信する（ステップ４４４）。移動対象セグメント抽出処理要求の電文を受信した各ＢＥＳでのデータ抽出処理の処理の流れを図１３に示す。ＢＥＳ１からＢＥＳ４までが、当該電文を受信する（ステップ４６１）。各ＢＥＳでは、電文の内容を解析し、再配置におけるデータ抽出対象となったデータベース格納領域とハッシュバケット要素番号の組合せで抽出処理を開始する。例えば、ＢＥＳ１においてはデータベース格納領域ＤＢＡＲＥＡ１ ５０ａから処理を開始する。図１２を用いながら説明する。データベース格納領域「ＤＢＡＲＥＡ１」５０ａからは、ハッシュバケット要素番号０から２５５までの５分の１であるハッシュバケット要素番号２０４から２５５までが移動対象となり、図１２におけるデータベース格納領域「ＤＢＡＲＥＡ１」５０ａ中のセグメントハッシュマップ表５１ａを参照し、ハッシュバケット要素番号２０４から順番に２５５までのセグメント先頭番号を取出しながら、ページビットマップ表５３ａ中のセグメント管理テーブルのチェインを辿りながらセグメント５４ａをセグメント入力バッファ４５ａに読み込む（ステップ４６２）。そして、当該データベース格納領域からの移動対象セグメントすべてを読み込んだか否かをチェックし（ステップ４６３）、検索終了でない場合はデータ抽出処理要求を送信したＢＥＳ５に対して、セグメント入力バッファ４５ａからハッシュバケット要素番号とともに送信を行う（ステップ４６４）。ＢＥＳ１から送信されたデータは、ＢＥＳ５において各ＢＥＳからのデータ受信処理にて受信する（図１３のステップ４４５）。このとき、すべてのＢＥＳからのデータ送信が終了したか否かをチェックし（ステップ４４６）、データを受信した場合は、追加データベース格納領域「ＤＢＡＲＥＡ５」５０ｅへの移動対象セグメントの反映処理を行う。反映処理とは、次の手順で行われる。
【００４４】
（１）セグメント単位で処理を行うので追加データベース格納領域「ＤＢＡＲＥＡ５」５０ｅ中のセグメントビットマップ表５２ｅから空きビットをサーチし、新規に１個のセグメントを確保する。
【００４５】
（２）新規に当該ハッシュバケット用のセグメントを確保した場合は、セグメントハッシュマップ表５３ｅの先頭セグメント先頭ポインタを更新する。さらに、当該ハッシュバケット用セグメント数に１を加える。
【００４６】
（２）確保したセグメントを管理するセグメント管理テーブルをページビットマップ表５３ｅから確保する。確保したセグメント管理テーブル内のページビットマップは、移動前のページビットマップ内容をコピーすればよい。このとき、当該ハッシュバケット用のセグメントがすでに割り当てられている場合はセグメント管理テーブルの最後尾に当該テーブルをチェインさせる。
【００４７】
（３）確保したセグメントに対してセグメント出力バッファ４３ａから書きこむ。
【００４８】
本データ受信処理は、各ＢＥＳからデータを受信できるようにセグメント出力バッファ４６ａから４６ｄまでが用意される。１回のデータ受信処理が終了する毎に受信したセグメントの反映処理が完了したことを送信先に通知する（ステップ４４８）。これに対して、ＢＥＳ１では図１４のステップ４６５によりセグメント反映完了通知の受信処理によって、通知を受け取る。セグメント反映完了通知を受信すると、移動したセグメントの削除処理を行う（ステップ４６６）。移動完了したセグメントの削除処理は、次の手順で行われる。
【００４９】
（１）セグメントハッシュマップ表５１ａの該当ハッシュバケット要素番号のセグメント先頭ポインタを参照し、ページビットマップ表５３ａのセグメント管理テーブルをＮＥＸＴポインタを辿りながら、セグメントビットマップ表５２ａ内の該当セグメントのビットを空きビットに更新する。
【００５０】
（２）該当ハッシュバケットのすべてのセグメントについてセグメントビットマップ表５２ａのビットを空きビットに更新したら、セグメントハッシュマップ表内の該当ハッシュバケット要素番号のセグメント数を０に更新する（ステップ４６７）。
【００５１】
以上の手順でデータ抽出側のＢＥＳは、ステップ４６２から４６７までを繰返し、すべての移動対象セグメントの送信が完了した場合（ステップ４６３）、当該ＢＥＳからのデータ送信が終了したことをＢＥＳ５に通知する（ステップ４６８）。
【００５２】
一方、ＢＥＳ５においてもステップ４４５から４４８までを繰返し、ＢＥＳ１からＢＥＳ４までのすべてのＢＥＳからデータ送信完了通知を受け取ったら（ステップ４４６）、ＤＩＣのデータベース定義情報を更新する（ステップ４４９）。更新する内容は、追加したデータベース格納領域の情報をデータベース領域管理表６１およびデータベース格納領域構成ファイル菅表に追加し、「ＺＡＩＫＯ」表に追加したデータベース格納領域の情報として、データベース管理表６３の分割数を５に更新し、データベース分割管理表６５には追加したデータベース格納領域「ＤＢＡＲＥＡ５」及び番号として４の情報を追加することである。
【００５３】
以上のように並列データベースシステムにおいても、各ＢＥＳの各既存のデータベース格納領域から１レコードずつデータを読み込む必要がなく、セグメント単位で読み込み、追加したデータベース格納領域を管理するＢＥＳにセグメント単位で転送し、書き込み処理を行えばよい。また、移動対象でないハッシュバケットは一切、読み込む必要がない。
【００５４】
次に本発明に係るデータベースの分割方法の第２の実施例を図１５および図１６を用いて説明する。
【００５５】
図１５は、表の第１の分割方法としてキー・レンジ分割を行い、さらに各キー・レンジで分割されたパーティションをハッシュ分割している様子を示す。先述した「ＺＡＩＫＯ」表を例にとり、その分割方法を変更したものである。このときの、データベース定義情報格納領域内の管理情報を図１６に示す。図１１に示したデータベース定義情報格納領域の管理情報との相違点は、データベース管理表６３及びデータベース分割管理表６５である。「ＺＡＩＫＯ」表の表の定義として、「ＳＣＯＤＥ」列に対してキーレンジ分割する際の分割条件が与えられ、さらに「ＳＣＯＤＥ」列または別の列でもよいがハッシュ分割することが与えられたとする。データベース管理表６３には、分割方法としてキーレンジ分割であることを示す「ＲＡＮＧＥ」という値が保持され、第１のパーティショニングキーとして「ＳＣＯＤＥ」列であることを示すための列番号である１、第２のサブパーティショニングキーとして「ＳＣＯＤＥ」列であることを示すための列番号である１が保持される。そして、データベース分割管理表６５には、第１のパーティションに対応するデータベース格納領域の通番と第２のサブパーティションに対応するデータベース格納領域の通番が保持され、各々の分割条件が保持されることを示す。例えば、分割条件が「Ｃ１＞１００」の場合、データベース格納領域の通番は０で、そのパーティション内にデータベース格納領域として「ＤＢＡＲＥＡ１１」、「ＤＢＡＲＥＡ１２」、「ＤＢＡＲＥＡ１３」が指定され、さらにハッシュ関数によって各々サブ番号として０、１、２と割り当てられる。これは、単に第１の分割条件がハッシュ分割であった場合と同様に考えることができる。したがって、第１のパーティション内をあらかじめハッシュバケットに分割しておけば、各パーティションに対してデータベース格納領域を追加する場合、各パーティション内の分割数に対応させたハッシュマップ表を選択すればよいことになる。
【００５６】
以上、説明したように本実施例によれば、データベースのデータをあらかじめ固定された複数のハッシュバケットに分割し、かつ、データベース格納領域内で物理的に独立したセグメントにハッシュバケットを格納するので、新規に追加したデータベース格納領域に対するデータの再配置処理時に移動対象のハッシュバケットのデータのみを再配置対象とすることができる。
【００５７】
また、再配置処理によって移動したセグメントは開放されるので、他のハッシュバケットの格納セグメントとして再利用が可能となり、データベース格納領域の空きに無駄がない。
【００５８】
【発明の効果】
以上、説明したように本発明によれば、データベースのデータをあらかじめ固定された複数のハッシュバケットに分割し、かつ、データベース格納領域内で物理的に独立したセグメントにハッシュバケットを格納するので、新規に追加したデータベース格納領域に対するデータの再配置処理時に移動対象のハッシュバケットのデータのみを再配置対象とすることができる。
【図面の簡単な説明】
【図１】本発明の特長となるデータベース格納領域の構成を示す。
【図２】本発明を実施するためのデータベース管理システムの構成図を示す。
【図３】データベース定義情報を管理する表の情報を示す。
【図４】本発明の特徴となるハッシュマップ表を示す。
【図５】本実施例に係る表へのデータの挿入処理の概略フローを示す。
【図６】本実施例に係るセグメントマップ表とページビットマップ表との関連を示す。
【図７】本実施例に係る表の検索処理の概略処理フローを示す。
【図８】本発明によるデータベース再配置処理の概略処理フローを示す。
【図９】本発明によるデータベース再配置処理のデータの流れを示す。
【図１０】本発明を実施するための並列データベースシステムの構成図を示す。
【図１１】並列データベースシステムにおけるデータベース定義情報を管理する表の情報を示す。
【図１２】並列データベースシステムにおけるデータベース再配置処理のデータの流れを示す。
【図１３】本発明によるデータベース再配置のデータ受信処理の概略処理フローを示す。
【図１４】本発明によるデータベース再配置のデータ送信処理の概略処理フローを示す。
【図１５】本発明によるキーレンジ分割した場合の表の例を示す。
【図１６】キーレンジ分割した表のデータベース定義情報を管理する表の情報を示す。
【符号の説明】
１０：コンピュータシステム、１２：ＣＰＵ、１４：主記憶装置、２０：外部記憶装置、３０：端末、４０：データベース管理システム、５０：データベース格納領域、５１：セグメントハッシュマップ表、５２：セグメントビットマップ表、５３：ページビットマップ表、５４：セグメント、６１：データベース格納領域管理表、６２：データベース格納領域構成管理表、６３：データベース管理表、６４：データベース構成列管理表、６５：データベース分割管理表、６６：ハッシュマップ表、６０：データベース定義情報格納領域、７０：データベースログ格納領域。
【発明の属する技術分野】
本発明は、時系列的に増加していくデータを新たに増設したデータベース格納領域にデータを再配置することによって、データベースの大規模化の運用を行うデータベース管理システムに関する。
【０００２】
【従来の技術】
一般的にデータベースを有するデータベースシステムでは、データベースに保有する情報は時々刻々変化している。その情報は時間経過と共に新たな情報が追加され、あらかじめ用意したデータベースを格納するためのデータベース格納領域の容量よりも大きくなる場合がある。
【０００３】
そのため、大規模なデータベースを扱う場合、あらかじめデータベースを複数のデータベース格納領域に分割して格納する方法が採用される。複数のデータベース格納領域に分割格納する分割手段として、キー・レンジ分割、ハッシュ分割、均等分割といった手段が用意される。各々の分割手段によって、分割したパーティションを指定したデータベース領域と１対１に対応させたり、複数のパーティションをあるデータベース領域に対応させたりという手法が採られる。時間経過と共に新たな情報が追加される場合、２つのデータベースの拡張方法が考えられる。一つは、分割手段としてキーレンジ分割が採用されている場合、新たなキーレンジを追加したり、あるキーレンジを分割するといった方法がある。これは、新たにデータベース領域を追加することなく操作することも可能である。もう一つは、分割手段は変更しないで新たにデータベース領域を追加または既存のデータベース領域を拡張する方法がある。これは、容量の増大に伴ってデータベース格納領域を増分させる方法である。これに対して、分割手段としてハッシュ分割を採用すると、分割に対するオーバヘッドが少なく、データの増加に対する柔軟性が高い。
【０００４】
ただし、あらかじめ用意したデータベース格納領域は時間と共に新たな情報が追加されるだけでなく、過去の古いデータを削除する場合もあり、必ずしも常にデータベース格納領域の容量よりも大きくなるわけではない。このような場合は、データベース再編成を行うことによって古いデータを削除することによって空きを作成し、新たに追加される情報を格納するために使用するようにすることで解決される。
【０００５】
しかし、過去のデータを延々と蓄積していくようなデータベースシステムでは、将来予測されるデータ量を想定し、あらかじめデータベース格納領域を用意しておくのは資源管理コストがかかるため、当面、予想されるデータ量まで格納できるデータベース領域を準備しておき、実際にデータ量の増加に伴って新たなデータベース格納領域が必要になった時点でデータベース格納領域を追加する運用を行う。
【０００６】
データベースに対するデータベース格納領域の追加は、データベースの定義変更を伴う。最も単純な方法としては、データベースの内容を一旦バックアップし、データベース格納領域の追加を行う定義変更処理を行った後、バックアップしたデータベースを再ローディングするという方法がある。ただし、この方法では大規模データベースの場合、バックアップを取得する時間及びバックアップ媒体等にかかるコストが非常に高く、再ローディングする処理も膨大な時間を要する。
【０００７】
第１の公知例として、米国特許４，４１２，２８５がある。本公知例では、表をハッシュ分割するが、あらかじめ複数のバケットに分割し、いくつかのバケットを仮想プロセッサに対応させて管理する技術が開示されている。
【０００８】
第２の公知例として、特開平６−１３９１１９号公報には、複数のプロセッサで構成される並列データベースシステム上に分割されたデータベースをアクセス頻度によってデータを再編成する技術が開示されている。
【０００９】
第３の公知例として、特開平６−３１４２９９号公報には、複数のプロセッサで構成される並列データベースシステム上に、階層的にデータベースを分割する技術が開示されている。
【００１０】
第４の公知例として、特開平７−１４１３９４号公報には、複数のプロセッサで構成される並列データベースシステム上に分割されたデータベースに対して、第５の公知例として、特開平９−２９３００６号公報には、ハッシュ関数を使用した分割方法を示し、データベース分割数が変更された場合にデータの再配置を必要とせず、データを新規追加した格納領域に格納しようとする技術が開示されている。ただし、本公知例ではデータの再配置は必要ないが、検索時には分割したすべての記憶装置を検索するようになっている。
【００１１】
【発明が解決しようとする課題】
従来技術における前者の方法の場合、データベースの大規模化についての問題が生じる。データベースの大規模化によって再配置が必要になるのは、データベース領域中の表に対するデータの追加が行われることによって、あらかじめ与えられたデータベース格納領域の空きがなくなる場合である。
【００１２】
上述したハッシュ分割を採用したデータベースの場合、ハッシング結果は分割数すなわち与えられたデータベース格納領域数に依存するため、新たにデータベース格納領域を追加する場合、それまで蓄積したデータをすべて新しい分割数の元でハッシングをやりなおし再格納しなければならない。これは、非常に膨大な時間と資源を浪費することになり、効率良くシステムを運用することができない。
【００１３】
また、再格納しないで既存の各データベース格納領域から、再配置処理として再ハッシュした結果によって他のデータベース格納領域にデータを移動させる場合、結局、各データベース格納領域中のすべてのデータを読み込まなければならず、再ハッシュしても同じデータベース格納領域内に残るデータがある場合でも無駄なデータの読み込みが生じてしまう。
【００１４】
本発明の第１の目的は、ハッシュ分割したデータベースに対してデータベース格納領域を追加する場合に、既存のデータベース格納領域から新たに追加したデータベース格納領域に対して最も少ないコストでデータを再配置することを可能とするデータベース格納管理方法を提供することにある。
【００１５】
【課題を解決するための手段】
前記目的を達成するために、本発明は、一つ又は複数の外部記憶装置から構成されるデータベース格納領域を管理し、前記データベース格納領域は物理的に固定長の複数のページから構成される複数のセグメントを管理するデータベース管理方法において、データベースの格納領域としてｍ個のデータベース格納領域が与えられた場合、データベースの一つ又は複数のデータ項目をパーティショニングキーとし、前記データベースを前記パーティショニングキーに対してハッシュ関数を適用し、ｎ（ｍ≦ｎ）個の論理的な単位であるバケットに分割し、当該与えられたデータベース格納領域数に応じて各バケットを管理するデータベース格納領域の対応を決定するハッシュマップ表と、分配されたバケットを各データベース格納領域内の格納単位であるセグメントとマッピングさせるためのセグメントハッシュマップ表によってデータベースを管理することを特徴とするデータベース管理方法を提供する。
【００１６】
【発明の実施の形態】
以下、本発明の一実施例を添付図面を用いて具体的に説明する。
【００１７】
図２は本実施形態のコンピュータシステムのハードウエア構成の一例を示す図である。コンピュータシステム１０は、ＣＰＵ１２、主記憶装置１４、磁気ディスク装置等の外部記憶装置２０及び多数の端末３０で構成される。主記憶装置１４上には、データベース管理システム４０が置かれ、複数の外部記憶装置２０を使用してデータベース管理システム４０が管理するデータベースを格納するデータベース領域５０ａ，５０ｂ，５０ｃ，５０ｄ、データベースの定義情報を管理するデータベース定義情報格納領域６０およびデータベースに対する更新操作に関する更新履歴情報を管理するデータベースログ格納領域７０が構成される。。さらに、データベース管理システム４０を実現するプログラムも外部記憶装置２０上に格納される。
【００１８】
図１は本発明におけるデータベースの管理形態を示す。図２で示したデータベース定義情報格納領域６０では、データベースシステムを構成するデータベース格納領域やデータベースの定義情報が格納される。データベース格納領域管理表６１は、データベースシステム内のデータベースを格納する領域として定義されたデータベース格納領域に関する情報を管理する。データベース格納領域構成ファイル管理表６２は、データベース格納領域定義時に指定された図２に示す外部記憶装置上に割り当てたファイルの構成に関する情報を管理する。データベース管理表６３は、特にリレーショナルデータベース管理システムのような場合に定義された表を管理する。データベース構成列管理表６４は、定義された表を構成する列に関する情報を管理する。データベース分割管理表６５は、表定義時にデータベースシステム内に定義されたデータベース格納領域を指定してデータを分割して格納した場合の表とデータベース格納領域の関連情報を持つ。ハッシュマップ表６６は、本発明で必要とするデータベース内に定義された表を複数のデータベース格納領域に分割して格納する場合に、その分割方法としてハッシュ分割方法が指定されると、指定されたデータベース格納領域数に対応してハッシュバケットに分割した場合の各ハッシュバケットをどのデータベース格納領域に格納するかを決定する対応表を持つ。
【００１９】
次に、データベース格納領域５０ａ，５０ｂ，５０ｃ，５０ｄの構成について説明する。ハッシュ分割された表について、データベース格納領域内での管理方法を示す。定義された表について、ハッシュバケットに分割する場合、ハッシュマップ表によってハッシュバケットの要素番号が決定されると、決定された要素番号のハッシュバケットのデータを格納する物理的に固定長の複数のページから構成されるセグメント５４にデータを格納した場合の先頭セグメント番号を管理するセグメントハッシュマップ表５１と、データベース格納領域内に確保されたすべてのセグメントの割当をビットマップとして管理するためのセグメントビットマップ表５２と、割り当てたセグメント５４内のページの割当をビットマップとして管理し、なおかつ、同じハッシュバケットの要素番号で複数のセグメントが割り当てられる場合にセグメント間のチェインを管理するページビットマップ表５３から構成される。
【００２０】
図３は、図２で示したデータベース定義情報格納領域６０に格納されたデータベース定義情報の一実施例として詳細に示したものである。データベース格納領域として、ＤＤＩＣＡＲＥＡ，ＤＢＡＲＥＡ１，ＤＢＡＲＥＡ２，ＤＢＡＲＥＡ３，ＤＢＡＲＥＡ４が定義されている場合にデータベース格納領域管理表６１及びデータベース格納領域構成ファイル管理表６２に格納された情報を示す。データベース格納領域管理表６１は、データベース領域名、種別、構成ファイル数、サーバ名、ページ長、セグメントサイズ及びセグメント数の列から構成される。また、データベース格納領域構成ファイル管理表は、データベース領域名、番号、及び構成ファイル名の列で構成される。当該データベースでは、ＤＤＩＣＡＲＥＡというデータベース格納領域が定義されると、その種別としてデータベース定義情報格納領域であることを示す’Ｄ’という情報で識別され、当該データベース格納領域を構成するファイル数である１、図１におけるデータベース格納領域で示したセグメント５４を構成するページのサイズであるページ長として４０９６バイト、当該セグメントを構成するページ数として５０ページ、さらに当該データベース格納領域に割り当てられるセグメント数５０が定義情報として格納される。同様に、ＤＢＡＲＥＡ１，ＤＢＡＲＥＡ２，ＤＢＡＲＥＡ３，ＤＢＡＲＥＡ４が定義されると、データベース格納領域の種別としてデータベース格納領域であることを識別する’Ｕ’、及び構成ファイル数、サーバ名、ページ長、セグメントサイズ、セグメント数の情報が各々格納される。これに対して、データベース格納領域構成ファイル管理表６２には、各データベース格納領域を構成するファイル名と複数のファイルで構成される場合には、その通番が情報として格納される。
【００２１】
次に当該データベースで「ＺＡＩＫＯ」表が定義された場合について、当該表の定義情報がデータベース管理表６３、データベース構成列管理表６４、及びデータベース分割管理表６５にどのように格納されるかについて説明する。「ＺＡＩＫＯ」表の定義文の一例を示す。
【００２２】
【００２３】
図４では、図２に示したハッシュマップ表６６を示す。本発明の実施例として当該データベースでは、データベースの表を複数のデータベース格納領域に分割する場合の最大データベース格納領域数を５１２とする。また、このとき、ハッシュ分割での最大ハッシュバケット数を１，０２４とする。ハッシュマップ表６６は、一つ一つの表のハッシュバケットの要素番号とデータベース格納領域との対応を示すようにする方法も考えられるが、データベース定義情報格納領域６０の容量増大を防止するため、２〜５１２分割までのすべてのデータベース格納領域指定数に応じ、ハッシュ関数によって求められたハッシュバケット要素番号と図３に示したデータベース分割管理表の「番号」列の値との対応表を持つようにしている。最も簡単な例として２分割の例を挙げる。２分割の場合、ハッシュマップ表の第１エントリを参照し、ハッシュバケット要素番号の０〜５１１までがデータベース格納領域の指定番号の０に格納することを示し、ハッシュバケット要素番号の５１２〜１０２３まではデータベース格納領域の指定番号の１に格納することを示す。それに対して、該当する表のデータベース分割管理表の番号０および１を参照してデータベース格納領域が決定される。次に、３分割の場合は、２分割状態のデータベースから１つのデータベース格納領域が追加された場合に追加されたデータベース格納領域に対して既存の２つの分割されたデータベース格納領域のハッシュバケットから３分の１ずつハッシュバケットを移動するようにさせたハッシュマップ表となる。したがって、ハッシュバケット要素番号０〜３４１までの３４２個のハッシュバケットがデータベース分割管理表の指定番号０のデータベース格納領域に格納することを示し、ハッシュバケット要素番号５１２〜８５３までの３４１個のハッシュバケットがデータベース分割管理表の指定番号１のデータベース格納領域に格納することを示し、ハッシュバケット要素番号３４２〜５１１及び８５４〜１０２３までの合計３４１個のハッシュバケットがデータベース分割管理表の指定番号２のデータベース格納領域に格納することを示す。３分の１に分ける場合、割り切れない場合にはデータベース分割管理表の指定番号の小さい方にハッシュバケットが多く残るように調整する。これによって、データの再配置が行われる場合に少しでも移動するデータ量を削減できる。さらに４分割の場合も同様に、３分割状態のデータベースから１つのデータベース格納領域が追加された場合に追加されたデータベース格納領域に対して既存の３つの分割されたデータベース格納領域のハッシュバケットから４分の１ずつハッシュバケットを移動するようにさせたハッシュマップ表となる。この場合、ハッシュバケット要素番号０〜２５５までの２５６個のハッシュバケットがデータベース分割管理表の指定番号０のデータベース格納領域に格納することを示し、ハッシュバケット要素番号５１２〜７６７までの２５６個のハッシュバケットがデータベース分割管理表の指定番号１のデータベース格納領域に格納することを示し、ハッシュバケット番号３４２〜４６９までの１２８個、ハッシュバケット要素番号８５４〜９８１までの１２８個の合計２５６個のハッシュバケットがデータベース分割管理表の指定番号２のデータベース格納領域に格納することを示し、ハッシュバケット要素番号２５６〜３４１までの８６個、ハッシュバケット要素番号４７０〜５１１までの４２個、ハッシュバケット要素番号７６８〜８５３までの８５個、ハッシュバケット要素番号９８２〜１０２３までの４３個の合計２５６個のハッシュバケットがデータベース分割管理表の指定番号３のデータベース格納領域に格納することを示す。このようにして、最大分割数である５１２分割までのハッシュバケットの対応表が保持されている。したがって、データベースの表定義時に決定したデータベース格納領域数によって参照するハッシュマップ表のエントリを決定すればよいことになる。
【００２４】
次に、図１におけるセグメントハッシュマップ表５１、セグメントビットマップ表５２、ページビットマップ表５３、およびセグメント５４に関して図５のデータベースの表へのデータ挿入処理の概略フローおよび図６を用いて詳細に示す。データベースの表に対してデータの挿入処理要求が行われる場合、「ＺＡＩＫＯ」表を例にとると以下のような要求がデータベース管理システムに対して発行される。
【００２５】
INSERT INTO ZAIKO VALUES('101','ブラウス','red',35000,62)
上記、要求が与えられた場合、まず、図２におけるデータベース定義情報格納領域６０からデータベース定義情報を取得する（ステップ４１０）。取得した情報の中から、「ＺＡＩＫＯ」表はパーティショニングキーＳＣＯＤＥ列でハッシュ分割することが判明する。したがって、ＳＣＯＤＥ列に指定された値’１０１’に対してハッシュ関数を施す（ステップ４１１）。ハッシュ関数を施した結果、図４におけるハッシュマップ表のハッシュバケット要素番号が決定される。ここでは、ハッシュバケット要素番号が２５６となったとする。そして、当該「ＺＡＩＫＯ」表はデータベース格納領域４つに分割することが与えられているので、図４におけるハッシュマップ表の分割数４のハッシュマップ表のハッシュバケット要素番号２５６のエントリを参照し、データベース分割管理表内の番号３がデータ格納するデータベース格納領域であることがわかる（ステップ４１２）。データベース分割管理表の「番号」列が３であるデータベース格納領域名を検索することによって、データベース格納領域名が’ＤＢＡＲＥＡ４’であることが確定する。データベース格納領域が決定したので、次にデータベース格納領域’ＤＢＡＲＥＡ４’内の格納するセグメントを決定するため、「ＺＡＩＫＯ」表のセグメントハッシュマップ表５１を参照する。セグメントハッシュマップ表５１を参照する場合、先ほど求めたハッシュバケット要素番号２５６を使ってセグメントハッシュマップ表内の配列番号２５６のエントリを参照する（ステップ４１３）。ここで、セグメントハッシュマップ表６６内の配列番号２５６には、図６で示すように当該ハッシュバケット要素番号を持つデータのセグメント数及びセグメント先頭ポインタとして先頭セグメント管理テーブルの番号が保持されている。ステップ４１４によって、このセグメント数が０又は先頭セグメント管理テーブルの番号が０かどうかを判定することによってセグメントが割り当てられているか否かをチェックする。もし、０の場合はまだセグメントが割り当てられていない、すなわち、当該ハッシュバケット要素番号に該当するデータが１件も格納されていないので、図１におけるセグメントビットマップ表を参照し、セグメントを確保する処理を行う（ステップ４１５）。図１におけるセグメントビットマップ表５２は、当該データベース格納領域内に確保できる全セグメント数分のビットマップで管理されており、空きビットをサーチすることによって見つかった空きセグメントを新規セグメントとして確保する。そして確保したセグメントのページ割当状況を管理するセグメント管理テーブルを図１におけるページビットマップ表５３から確保し、セグメントハッシュマップ表の配列番号２５６のエントリにセグメント数として１を設定し、セグメント先頭ポインタとして確保したセグメント番号を設定する。また、確保したセグメント管理テーブルには、次のセグメントがまだ割り当てられていないことを示すため、ＮＥＸＴポインタには０を設定する（ステップ４１６）。次に、確保したセグメントからデータを格納するページを決定する。新規に確保したセグメントの場合、セグメント管理テーブル中に含まれるページビットマップ領域はすべてのビットが空きページの状態となる。先頭ページを使用することを決定し、先頭ビットを使用状態に更新する。また、ステップ４１４によってすでに該当ハッシュバケットのセグメントが確保されている場合は、セグメント管理テーブルのチェインをたどり、最終セグメントのセグメント管理テーブルのページビットマップ領域を参照し、最終ページ番号をアクセスする。最終ページ番号のページを入力し、挿入するレコード（行）が格納できる空き領域が存在すれば当該ページを挿入ページとして決定する（ステップ４１７）。もし、空き領域が存在しなければ先ほどのセグメント管理テーブルから空きページを検索し、空きページがあれば当該ページを挿入ページとして決定する。さらに、当該セグメント中に空きページが存在しない場合は、セグメントビットマップ表を検索し、空きセグメントを確保するようにする。空きセグメントも存在しない場合は、ハッシュバケット要素番号に該当するすべてのセグメント管理テーブルのチェインを辿り、核セグメント管理テーブルから空きページをサーチすることによって挿入ページを決定する。それでも、空きページが存在しない場合は、当該データベース格納領域内に空き領域が存在しないことになり、挿入不可となる。こうして、正常に決定された挿入ページに行を格納することによって行の挿入処理が完了する（ステップ４１８）。行挿入に際しては、当然であるが図２におけるデータベースログ格納領域７０に対して挿入処理に関するログを取得しておく必要がある。
【００２６】
以上のように行を挿入する場合、ハッシュ関数によって定められたデータベース格納領域を決定し、さらにデータベース格納領域内でもハッシュバケット要素番号に該当するセグメントにデータを格納するため、他のパーティショニングキー値によって求められた異なるハッシュバケット要素番号のデータは明確に別セグメントに格納される。さらに、複数のユーザから行を挿入する要求が発生した場合、同じデータベース格納領域内であっても分割キー値が異なれば格納するセグメントも異なるので、同一セグメントへの挿入といった競合を大幅に抑止することも可能になる。
【００２７】
次に、データベースに対する問合せとして検索要求が発行された場合の検索処理の処理の流れを図７に示す。データベースの表に対してデータの検索処理要求が行われる場合、「ＺＡＩＫＯ」表を例にとると以下のような要求がデータベース管理システムに対して発行される。
【００２８】
SELECT SCODE,SNAME,COL,TANKA,ZSURYO FROM ZAIKO WHERE SNO='101'
上記要求が与えられた場合、まず、図２におけるデータベース定義情報格納領域６０からデータベース定義情報を取得する（ステップ４２０）。取得した情報の中から、「ＺＡＩＫＯ」表はパーティショニングキーＳＣＯＤＥ列でハッシュ分割していることが判明する。次に当該検索要求の探索条件中にパーティショニングキーであるＳＣＯＤＥ列に対する条件指定があるか否かをチェックする（ステップ４２１）。当該問い合わせの場合、ＳＮＯ列に対する条件が指定されているので、ハッシュ関数を適用することによってデータベース格納領域を決定する。ハッシュ関数を施した結果、図３におけるハッシュマップ表のハッシュバケット要素番号が決定される。ここでは、ハッシュバケット要素番号が２５６となったとする。そして、当該「ＺＡＩＫＯ」表はデータベース格納領域４つに分割することが与えられているので、図４におけるハッシュマップ表の分割数４のハッシュマップ表のハッシュバケット要素番号２５６のエントリを参照し、データベース分割管理表内の番号３がデータ格納するデータベース格納領域であることがわかる（ステップ４２３）。データベース分割管理表の「番号」列が３であるデータベース格納領域名を検索することによって、データベース格納領域名が’ＤＢＡＲＥＡ４’であることが確定する。データベース格納領域が決定したので、次にデータベース格納領域’ＤＢＡＲＥＡ４’内の当該ハッシュバケット要素番号に該当するセグメントを決定するため、「ＺＡＩＫＯ」表のセグメントハッシュマップ表５１を参照する。セグメントハッシュマップ表５１を参照する場合、先ほど求めたハッシュバケット要素番号２５６を使ってセグメントハッシュマップ表内の配列番号２５６のエントリを参照する（ステップ４２４）。セグメントハッシュマップ表の配列番号２５６のエントリ中に設定された先頭セグメント管理テーブル番号が存在する場合は、セグメント管理テーブルのチェインを辿りながら、全セグメントの割当ページを検索対象として探索条件を評価する（ステップ４２５）。もし、該当するエントリ中にセグメント番号が設定されていない場合は検索対象データがないということになり、検索結果は０件となる。また、ステップ４２１によってパーティショニングキーであるＳＮＯ列に対する条件指定がない場合は、すべてのデータベース格納領域が検索対象になる。すべてのデータベース格納領域が検索対象となった場合、各データベース格納領域内のセグメントハッシュマップ表に設定されたセグメント番号が０でないものを対象に各要素番号のセグメントチェインを辿りながら探索条件評価を行う（ステップ４２６ないし４２７）。
【００２９】
以上のようにデータベース検索の場合、パーティショニングキーに対する条件が指定されると、検索対象となるデータベース格納領域を絞り込むだけでなく、データベース格納領域内のセグメントを絞り込むことができるので、アクセスする必要のないセグメントを検索対象から除外することができる。
【００３０】
本発明によるデータベース分割格納方法を用い、データの再配置を行う場合の実施例を図８及び図９を用いて説明する。データベースシステム構成としては、図２に示した構成を用い、データベースの定義としては、図３で示した「ＺＡＩＫＯ」表を用いて、当該「ＺＡＩＫＯ」表に対して新規にデータベース格納領域「ＤＢＡＲＥＡ５」を追加する場合のデータベース再配置処理の流れを図８に示し、その場合のデータベースのデータの移動方法を図９に示す。データベース再配置処理は、図９に示したようにデータベース管理システム４０内の一つの処理プログラムであるデータベース再配置処理部４３０として動作する。まず、データベース再配置処理要求としてデータベース格納領域「ＤＢＡＲＥＡ５」の追加が要求されると、新規に追加したデータベース格納領域を含めた分割数でのハッシュマップ表を図４に示した各分割数毎のハッシュマップ対応表から求める（ステップ４３１）。ここでは、４分割されたデータベースに対してデータベース格納領域を一つ追加するので５分割の場合のハッシュマップ表を求めることになる。次に求めたハッシュマップ表から追加データベース格納領域が管理するハッシュバケット要素番号を抜き出したリストを作成する（ステップ４３２）。つまり、５分割の場合のハッシュマップ表の各配列の中の番号が４である配列番号をハッシュバケット要素番号として取り出せば良い。こうして追加したデータベース格納領域が管理すべきハッシュバケット要素番号が判明したので、現在の分割数である４分割のハッシュマップ表を参照し、先ほど取り出したハッシュバケット要素番号のハッシュバケットを現在管理しているデータベース格納領域の番号を取得する（ステップ４３３）。データベース格納領域の番号が判明すれば、図３におけるデータベース定義情報格納領域６０中のデータベース分割管理表６５からデータベース格納領域名を得ることができる。こうして得られた追加したデータベース格納領域への移動対象となるハッシュバケット要素番号と既存のデータベース格納領域との対応表を作成し、既存のデータベース格納領域毎に移動対象ハッシュバケット要素番号をソートするように対応表を作成しておくと処理を既存のデータベース格納領域毎に行えるようにすることができる。まず、データベース格納領域「ＤＢＡＲＥＡ１」から処理を開始する。図９を用いながら説明する。データベース格納領域「ＤＢＡＲＥＡ１」からは、ハッシュバケット要素番号０から２５５までの５分の１であるハッシュバケット要素番号２０４から２５５までが移動対象となり、図８における移動対象セグメント抽出処理（ステップ４３４）では、図９におけるデータベース格納領域「ＤＢＡＲＥＡ１」５０ａ中のセグメントハッシュマップ表５１ａを参照し、ハッシュバケット要素番号２０４から順番に２５５までのセグメント先頭番号を取出しながら、ページビットマップ表５３ａ中のセグメント管理テーブルのチェインを辿り、セグメント５４ａをセグメント入出力バッファ４２に読み込む。セグメント入出力バッファにはセグメント単位で読み込み処理を行うが、各セグメント管理テーブルのページビットマップ領域を参照することによって使用されていない、すなわち空きページについては読み込まないようにするか、移動先のデータベース格納領域の当該セグメントを割り当てた際にページビットマップ情報もコピーすればセグメント単位で読み込んでも問題ない。こうしてセグメント入出力バッファ４２に読み込んだセグメントを追加データベース格納領域「ＤＢＡＲＥＡ５」５０ｅに反映する処理を行う（ステップ４３５）。反映処理とは、次の手順で行われる。
【００３１】
（１）セグメント単位で処理を行うので追加データベース格納領域「ＤＢＡＲＥＡ５」５０ｅ中のセグメントビットマップ表から空きビットをサーチし、新規に１個のセグメントを確保する。
【００３２】
（２）新規に当該ハッシュバケット用のセグメントを確保した場合は、セグメントハッシュマップ表５３ａの先頭セグメント先頭ポインタを更新する。このとき、当該ハッシュバケット用セグメント数に１を加える。
【００３３】
（２）確保したセグメントを管理するセグメント管理テーブルをページビットマップ表５３ｅから確保する。確保したセグメント管理テーブル内のページビットマップは、移動前のページビットマップ内容をコピーすればよい。このとき、当該ハッシュバケット用のセグメントがすでに割り当てられている場合はセグメント管理テーブルの最後尾に当該テーブルをチェインさせる。
【００３４】
（３）確保したセグメントに対してセグメント入出力バッファ４２から書きこむ。
【００３５】
上記手順によって反映処理終了後、既存のデータベース格納領域「ＤＢＡＲＥＡ１」５０ａの移動完了したセグメントの削除処理を行う（ステップ４３６）。移動完了したセグメントの削除処理は、次の手順で行われる。
【００３６】
（１）セグメントハッシュマップ表５１ａの該当ハッシュバケット要素番号のセグメント先頭ポインタを参照し、ページビットマップ表５３ａのセグメント管理テーブルをＮＥＸＴポインタを辿りながら、セグメントビットマップ表５２ａ内の該当セグメントのビットを空きビットに更新する。
【００３７】
（２）該当ハッシュバケットのすべてのセグメントについてセグメントビットマップ表５２ａのビットを空きビットに更新したら、セグメントハッシュマップ表内の該当ハッシュバケット要素番号のセグメント数を０に更新する（ステップ４３７）。
【００３８】
以上の手順で各既存のデータベース格納領域内の移動対象となるハッシュバケットすべてを移動したかどうかをチェックし（ステップ４３８）、データベース格納領域「ＤＢＡＲＥＡ４」までステップ４３４から４３７までを行い、すべてのデータベース格納領域の処理が終了した場合、データベース定義情報格納領域６０内のデータベース定義情報を更新する（ステップ４３９）。更新する内容は、追加したデータベース格納領域の情報をデータベース領域管理表６１およびデータベース格納領域構成ファイル菅表に追加し、「ＺＡＩＫＯ」表に追加したデータベース格納領域の情報として、データベース管理表６３の分割数を５に更新し、データベース分割管理表６５には追加したデータベース格納領域「ＤＢＡＲＥＡ５」及び番号として４の情報を追加することである。
【００３９】
このようにデータベースの再配置処理では、各既存のデータベース格納領域から１レコードずつデータを読み込む必要がなく、セグメント単位で読み込み、追加したデータベース格納領域に書きこみを行えばよい。また、移動対象でないハッシュバケットは一切、読み込む必要がない。
【００４０】
次に、本発明によるデータの再配置に関する第２の実施例として並列データベースシステムにおけるデータの再配置処理を示す。
【００４１】
図１０は、並列データベースシステムのハードウエア構成の一例を示す図である。一つのコンピュータシステム１０は、図２と同様にＣＰＵ１２、主記憶装置１４、磁気ディスク装置等の外部記憶装置２０で構成される。当該並列データベースシステムでは。複数のコンピュータシステム及び複数台の端末３０がネットワークに接続されている。当該並列データベースシステムを構成するデータベース管理システム４０内に各処理構成単位が配置される。フロントエンドサーバ４１（以下ＦＥＳと呼ぶ）は、端末３０からの問合せを受信し、問合せの処理手順を生成するコンポーネントである。当該ＦＥＳには、トランザクション等に関するログを記録するためのデータベースログ格納領域７０を持つ。バックエンドサーバ４３ａ，４３ｂ，４３ｃ，４３ｄ（以下、ＢＥＳと呼ぶ）はＦＥＳからの処理手順を受信して、各々ＢＥＳ１，ＢＥＳ２，ＢＥＳ３，ＢＥＳ４が管理するデータベース格納領域５０ａ，５０ｂ，５０ｃ，５０ｄをアクセスすることによってＦＥＳにその処理結果を返す。このとき、各々のデータベース格納領域に対して行われたデータベースの変更に関するログやトランザクションに関するログが、データベースログ格納領域７０ａ，７０ｂ，７０ｃ，及び７０ｄに格納される。データディクショナリサーバ４２（以下、ＤＩＣと呼ぶ）は、データベースに関する定義情報を管理し、その定義情報はデータベース定義情報格納領域７０に格納され、データベース定義情報の変更に関するログやトランザクションに関するログが、データベースログ格納領域７０に格納される。ＦＥＳでは、要求された問合せでアクセスするデータベースの定義情報をＤＩＣから取得する。図１０でも示すように、一つのコンピュータシステム内にＢＥＳを複数配置することができる。これは、一つのコンピュータシステム内に複数のＢＥＳを配置することによって、並列処理能力を高めることができる。ここでは、各々のコンピュータシステムにそれぞれ２つのＢＥＳを配置する構成をとる。当該並列データベースシステムのハードウエア構成を利用し、先に挙げた「ＺＡＩＫＯ」表を定義した場合のデータベース定義情報格納領域７０の管理情報について図１１に示す。非並列データベースシステムの場合の実施例として示した図３のデータベース定義情報格納領域７０とは基本的な管理情報に違いはない。異なる点は、データベース領域管理表６１に含まれるサーバ名である。各データベース格納領域をどのサーバで管理しているかを管理するための情報が付加される。つまり、「ＺＡＩＫＯ」表は４つのデータベース格納領域ＤＢＡＲＥＡ１，ＤＢＡＲＥＡ２，ＤＢＡＲＥＡ３，ＤＢＡＲＥＡ４に分割され、ＤＢＡＲＥＡ１はＢＥＳ１、ＤＢＡＲＥＡ２はＢＥＳ２、ＤＢＡＲＥＡ３はＢＥＳ３、ＤＢＡＲＥＡ４はＢＥＳ４にてデータベース処理を行うようにＦＥＳが処理を振り分けるのである。
【００４２】
次に、当該並列データベースシステムに対して図１０に示すように新規にコンピュータシステムを追加し、データベースコンポーネントとしてＢＥＳ５ ４３ｅを追加し、さらに追加したＢＥＳ５にデータベース格納領域「ＤＢＡＲＥＡ５」を追加した場合に、戦術した「ＺＡＩＫＯ」表のデータの再配置がどう行われるかについて説明する。
【００４３】
最初に、ＢＥＳ５では再配置処理としてデータ受信処理を実行する。図１３にＢＥＳ５におけるデータ受信処理の概略処理フローを示す。ＢＥＳ５では、追加するデータベース格納領域ＤＢＡＲＥＡ５を含めた５分割時のハッシュマップ表をＤＩＣのデータベース定義情報格納領域から取り出す（ステップ４４１）。次に求めたハッシュマップ表から追加データベース格納領域が管理するハッシュバケット要素番号を抜き出したリストを作成する（ステップ４４２）。つまり、５分割の場合のハッシュマップ表の各配列の中の番号が４である配列番号をハッシュバケット要素番号として取り出せば良い。こうして追加したデータベース格納領域が管理すべきハッシュバケット要素番号が判明したので、現在の分割数である４分割のハッシュマップ表を参照し、先ほど取り出したハッシュバケット要素番号のハッシュバケットを現在管理しているデータベース格納領域の番号及びサーバ名をＤＩＣから取得する（ステップ４４３）。データベース格納領域の番号が判明すれば、図１１におけるデータベース定義情報格納領域６０中のデータベース分割管理表６５からデータベース格納領域名を得ることができる。また、各データベース格納領域を管理しているサーバ名はデータベース領域管理表より求めることができる。こうして得られた追加したデータベース格納領域への移動対象となるハッシュバケット要素番号と既存のデータベース格納領域との対応表を作成し、既存のデータベース格納領域毎に移動対象ハッシュバケット要素番号をソートするように対応表を作成しておくと処理を既存のデータベース格納領域毎に行えるようにすることができる。次に、ＢＥＳ５からデータベース格納領域ＤＢＡＲＥＡ１からＤＢＡＲＥＡ４までを管理しているＢＥＳ１からＢＥＳ４に対して、移動対象となるハッシュバケット要素番号とデータベース格納領域を入力情報とし移動対象セグメント抽出処理要求を送信する（ステップ４４４）。移動対象セグメント抽出処理要求の電文を受信した各ＢＥＳでのデータ抽出処理の処理の流れを図１３に示す。ＢＥＳ１からＢＥＳ４までが、当該電文を受信する（ステップ４６１）。各ＢＥＳでは、電文の内容を解析し、再配置におけるデータ抽出対象となったデータベース格納領域とハッシュバケット要素番号の組合せで抽出処理を開始する。例えば、ＢＥＳ１においてはデータベース格納領域ＤＢＡＲＥＡ１ ５０ａから処理を開始する。図１２を用いながら説明する。データベース格納領域「ＤＢＡＲＥＡ１」５０ａからは、ハッシュバケット要素番号０から２５５までの５分の１であるハッシュバケット要素番号２０４から２５５までが移動対象となり、図１２におけるデータベース格納領域「ＤＢＡＲＥＡ１」５０ａ中のセグメントハッシュマップ表５１ａを参照し、ハッシュバケット要素番号２０４から順番に２５５までのセグメント先頭番号を取出しながら、ページビットマップ表５３ａ中のセグメント管理テーブルのチェインを辿りながらセグメント５４ａをセグメント入力バッファ４５ａに読み込む（ステップ４６２）。そして、当該データベース格納領域からの移動対象セグメントすべてを読み込んだか否かをチェックし（ステップ４６３）、検索終了でない場合はデータ抽出処理要求を送信したＢＥＳ５に対して、セグメント入力バッファ４５ａからハッシュバケット要素番号とともに送信を行う（ステップ４６４）。ＢＥＳ１から送信されたデータは、ＢＥＳ５において各ＢＥＳからのデータ受信処理にて受信する（図１３のステップ４４５）。このとき、すべてのＢＥＳからのデータ送信が終了したか否かをチェックし（ステップ４４６）、データを受信した場合は、追加データベース格納領域「ＤＢＡＲＥＡ５」５０ｅへの移動対象セグメントの反映処理を行う。反映処理とは、次の手順で行われる。
【００４４】
（１）セグメント単位で処理を行うので追加データベース格納領域「ＤＢＡＲＥＡ５」５０ｅ中のセグメントビットマップ表５２ｅから空きビットをサーチし、新規に１個のセグメントを確保する。
【００４５】
（２）新規に当該ハッシュバケット用のセグメントを確保した場合は、セグメントハッシュマップ表５３ｅの先頭セグメント先頭ポインタを更新する。さらに、当該ハッシュバケット用セグメント数に１を加える。
【００４６】
（２）確保したセグメントを管理するセグメント管理テーブルをページビットマップ表５３ｅから確保する。確保したセグメント管理テーブル内のページビットマップは、移動前のページビットマップ内容をコピーすればよい。このとき、当該ハッシュバケット用のセグメントがすでに割り当てられている場合はセグメント管理テーブルの最後尾に当該テーブルをチェインさせる。
【００４７】
（３）確保したセグメントに対してセグメント出力バッファ４３ａから書きこむ。
【００４８】
本データ受信処理は、各ＢＥＳからデータを受信できるようにセグメント出力バッファ４６ａから４６ｄまでが用意される。１回のデータ受信処理が終了する毎に受信したセグメントの反映処理が完了したことを送信先に通知する（ステップ４４８）。これに対して、ＢＥＳ１では図１４のステップ４６５によりセグメント反映完了通知の受信処理によって、通知を受け取る。セグメント反映完了通知を受信すると、移動したセグメントの削除処理を行う（ステップ４６６）。移動完了したセグメントの削除処理は、次の手順で行われる。
【００４９】
（１）セグメントハッシュマップ表５１ａの該当ハッシュバケット要素番号のセグメント先頭ポインタを参照し、ページビットマップ表５３ａのセグメント管理テーブルをＮＥＸＴポインタを辿りながら、セグメントビットマップ表５２ａ内の該当セグメントのビットを空きビットに更新する。
【００５０】
（２）該当ハッシュバケットのすべてのセグメントについてセグメントビットマップ表５２ａのビットを空きビットに更新したら、セグメントハッシュマップ表内の該当ハッシュバケット要素番号のセグメント数を０に更新する（ステップ４６７）。
【００５１】
以上の手順でデータ抽出側のＢＥＳは、ステップ４６２から４６７までを繰返し、すべての移動対象セグメントの送信が完了した場合（ステップ４６３）、当該ＢＥＳからのデータ送信が終了したことをＢＥＳ５に通知する（ステップ４６８）。
【００５２】
一方、ＢＥＳ５においてもステップ４４５から４４８までを繰返し、ＢＥＳ１からＢＥＳ４までのすべてのＢＥＳからデータ送信完了通知を受け取ったら（ステップ４４６）、ＤＩＣのデータベース定義情報を更新する（ステップ４４９）。更新する内容は、追加したデータベース格納領域の情報をデータベース領域管理表６１およびデータベース格納領域構成ファイル菅表に追加し、「ＺＡＩＫＯ」表に追加したデータベース格納領域の情報として、データベース管理表６３の分割数を５に更新し、データベース分割管理表６５には追加したデータベース格納領域「ＤＢＡＲＥＡ５」及び番号として４の情報を追加することである。
【００５３】
以上のように並列データベースシステムにおいても、各ＢＥＳの各既存のデータベース格納領域から１レコードずつデータを読み込む必要がなく、セグメント単位で読み込み、追加したデータベース格納領域を管理するＢＥＳにセグメント単位で転送し、書き込み処理を行えばよい。また、移動対象でないハッシュバケットは一切、読み込む必要がない。
【００５４】
次に本発明に係るデータベースの分割方法の第２の実施例を図１５および図１６を用いて説明する。
【００５５】
図１５は、表の第１の分割方法としてキー・レンジ分割を行い、さらに各キー・レンジで分割されたパーティションをハッシュ分割している様子を示す。先述した「ＺＡＩＫＯ」表を例にとり、その分割方法を変更したものである。このときの、データベース定義情報格納領域内の管理情報を図１６に示す。図１１に示したデータベース定義情報格納領域の管理情報との相違点は、データベース管理表６３及びデータベース分割管理表６５である。「ＺＡＩＫＯ」表の表の定義として、「ＳＣＯＤＥ」列に対してキーレンジ分割する際の分割条件が与えられ、さらに「ＳＣＯＤＥ」列または別の列でもよいがハッシュ分割することが与えられたとする。データベース管理表６３には、分割方法としてキーレンジ分割であることを示す「ＲＡＮＧＥ」という値が保持され、第１のパーティショニングキーとして「ＳＣＯＤＥ」列であることを示すための列番号である１、第２のサブパーティショニングキーとして「ＳＣＯＤＥ」列であることを示すための列番号である１が保持される。そして、データベース分割管理表６５には、第１のパーティションに対応するデータベース格納領域の通番と第２のサブパーティションに対応するデータベース格納領域の通番が保持され、各々の分割条件が保持されることを示す。例えば、分割条件が「Ｃ１＞１００」の場合、データベース格納領域の通番は０で、そのパーティション内にデータベース格納領域として「ＤＢＡＲＥＡ１１」、「ＤＢＡＲＥＡ１２」、「ＤＢＡＲＥＡ１３」が指定され、さらにハッシュ関数によって各々サブ番号として０、１、２と割り当てられる。これは、単に第１の分割条件がハッシュ分割であった場合と同様に考えることができる。したがって、第１のパーティション内をあらかじめハッシュバケットに分割しておけば、各パーティションに対してデータベース格納領域を追加する場合、各パーティション内の分割数に対応させたハッシュマップ表を選択すればよいことになる。
【００５６】
以上、説明したように本実施例によれば、データベースのデータをあらかじめ固定された複数のハッシュバケットに分割し、かつ、データベース格納領域内で物理的に独立したセグメントにハッシュバケットを格納するので、新規に追加したデータベース格納領域に対するデータの再配置処理時に移動対象のハッシュバケットのデータのみを再配置対象とすることができる。
【００５７】
また、再配置処理によって移動したセグメントは開放されるので、他のハッシュバケットの格納セグメントとして再利用が可能となり、データベース格納領域の空きに無駄がない。
【００５８】
【発明の効果】
以上、説明したように本発明によれば、データベースのデータをあらかじめ固定された複数のハッシュバケットに分割し、かつ、データベース格納領域内で物理的に独立したセグメントにハッシュバケットを格納するので、新規に追加したデータベース格納領域に対するデータの再配置処理時に移動対象のハッシュバケットのデータのみを再配置対象とすることができる。
【図面の簡単な説明】
【図１】本発明の特長となるデータベース格納領域の構成を示す。
【図２】本発明を実施するためのデータベース管理システムの構成図を示す。
【図３】データベース定義情報を管理する表の情報を示す。
【図４】本発明の特徴となるハッシュマップ表を示す。
【図５】本実施例に係る表へのデータの挿入処理の概略フローを示す。
【図６】本実施例に係るセグメントマップ表とページビットマップ表との関連を示す。
【図７】本実施例に係る表の検索処理の概略処理フローを示す。
【図８】本発明によるデータベース再配置処理の概略処理フローを示す。
【図９】本発明によるデータベース再配置処理のデータの流れを示す。
【図１０】本発明を実施するための並列データベースシステムの構成図を示す。
【図１１】並列データベースシステムにおけるデータベース定義情報を管理する表の情報を示す。
【図１２】並列データベースシステムにおけるデータベース再配置処理のデータの流れを示す。
【図１３】本発明によるデータベース再配置のデータ受信処理の概略処理フローを示す。
【図１４】本発明によるデータベース再配置のデータ送信処理の概略処理フローを示す。
【図１５】本発明によるキーレンジ分割した場合の表の例を示す。
【図１６】キーレンジ分割した表のデータベース定義情報を管理する表の情報を示す。
【符号の説明】
１０：コンピュータシステム、１２：ＣＰＵ、１４：主記憶装置、２０：外部記憶装置、３０：端末、４０：データベース管理システム、５０：データベース格納領域、５１：セグメントハッシュマップ表、５２：セグメントビットマップ表、５３：ページビットマップ表、５４：セグメント、６１：データベース格納領域管理表、６２：データベース格納領域構成管理表、６３：データベース管理表、６４：データベース構成列管理表、６５：データベース分割管理表、６６：ハッシュマップ表、６０：データベース定義情報格納領域、７０：データベースログ格納領域。
Claims (8)
- データを格納するための複数のデータ格納領域を含むデータベース格納領域を複数有し、該データ格納領域の位置情報を管理する管理テーブルを前記データベース格納領域毎に有するとともに、前記データの格納時もしくは検索時に利用するデータベース格納領域と前記データとを割り付けるデータ割り当て手段を有するデータベース管理装置におけるデータベース管理方法であって、
所定数の前記データベース格納領域と対応付けられたハッシュバケット要素番号をハッシュマップ表の各エントリに予め記憶し、前記データベース格納領域の分割数に対応した分割番号と前記データ格納領域の位置情報とを対応付けて前記管理テーブルに予め記憶し、
前記データを登録する場合に前記登録すべきデータについてハッシュ関数によりハッシュバケット要素番号を得て、前記ハッシュマップ表を参照して前記得たハッシュバケット要素番号に対応する前記ハッシュマップ表のエントリに記憶されている前記分割番号を得て、前記ハッシュバケット要素番号と対応付けられている前記データベース格納領域における前記分割番号に対応付けられた前記管理テーブルの位置情報を参照して前記登録すべきデータを格納すべき前記データ格納領域を特定し、当該データ格納領域に当該登録すべきデータを格納することを特徴とするデータベース管理方法。 - データを格納するための複数のデータ格納領域を含むデータベース格納領域を複数有し、該データ格納領域の位置情報を管理する管理テーブルを前記データベース格納領域毎に有するとともに、前記データの格納時もしくは検索時に利用するデータベース格納領域と前記データとを割り付けるデータ割り当て手段を有するデータベース管理装置におけるデータベース管理方法であって、
所定数の前記データベース格納領域と対応付けられたハッシュバケット要素番号をハッシュマップ表の各エントリに予め記憶し、前記データベース格納領域の分割数に対応した分割番号と前記データ格納領域の位置情報とを対応付けて前記管理テーブルに記憶し、
前記データを検索する場合に前記検索すべきデータについてハッシュ関数によりハッシュバケット要素番号を得て、前記ハッシュマップ表を参照して前記得たハッシュバケット要素番号に対応する前記ハッシュマップ表のエントリに記憶されている前記分割番号を得て、前記ハッシュバケット要素番号と対応付けられている前記データベース格納領域における前記分割番号に対応付けられた前記管理テーブルの位置情報を参照して前記検索すべき前記データ格納領域を特定し、当該データ格納領域について当該検索すべきデータを探索することを特徴とするデータベース管理方法。 - 前記データに含まれる第１の項目と第２の項目について、前記第１の項目に対して前記キーレンジ分割を適用し、前記第２の項目に対して前記ハッシュ関数を適用することを特徴とする請求項１または請求項２記載のデータベース管理方法。
- 前記データベース格納領域を一つ追加した場合、（所定数＋１）の前記データベース格納領域について、前記ハッシュ関数を利用して、追加以前の前記データベース格納領域の対応付けられている前記ハッシュマップ表のエントリから前記追加したデータベース格納領域に割り付けるべき前記エントリを特定し、
前記特定されたハッシュマップ表のエントリに格納された前記ハッシュバケット要素番号と該エントリに対応する前記分割番号とを得て、当該得た前記ハッシュバケット要素番号と当該得た分割番号に対応するデータベース格納領域とデータ格納領域を前記ハッシュマップ表の変更後の新しい前記分割番号に基づいて前記追加したデータベース格納領域に当該特定対象のデータ格納領域に格納されたデータを移動することを特徴とする請求項１または請求項２記載のデータベース管理方法。 - データを格納するための複数のデータ格納領域を含むデータベース格納領域を複数有し、該データ格納領域の位置情報を管理する管理テーブルを前記データベース格納領域毎に有するとともに、前記データの格納時もしくは検索時に利用するデータベース格納領域と前記データとを割り付けるデータ割り当て手段を有するデータベース管理装置であって、
所定数の前記データベース格納領域と対応付けられたハッシュバケット要素番号をハッシュマップ表の各エントリに予め記憶し、前記データベース格納領域の分割数に対応した分割番号と前記データ格納領域の位置情報とを対応付けて前記管理テーブルに記憶する手段と、
前記データを登録する場合に前記登録すべきデータについてハッシュ関数によりハッシュバケット要素番号を得て、前記ハッシュマップ表を参照して前記得たハッシュバケット要素番号に対応する前記ハッシュマップ表のエントリに記憶されている前記分割番号を得て、前記ハッシュバケット要素番号と対応付けられている前記データベース格納領域における前記分割番号に対応付けられた前記管理テーブルの位置情報を参照して前記登録すべきデータを格納すべき前記データ格納領域を特定し、当該データ格納領域に当該登録すべきデータを格納する手段とを備えたことを特徴とするデータベース管理装置。 - データを格納するための複数のデータ格納領域を含むデータベース格納領域を複数有し、該データ格納領域の位置情報を管理する管理テーブルを前記データベース格納領域毎に有するとともに、前記データの格納時もしくは検索時に利用するデータベース格納領域と前記データとを割り付けるデータ割り当て手段を有するデータベース管理装置であって、
所定数の前記データベース格納領域と対応付けられたハッシュバケット要素番号をハッシュマップ表の各エントリに予め記憶し、前記データベース格納領域の分割数に対応した分割番号と前記データ格納領域の位置情報とを対応付けて前記管理テーブルに記憶する手段と、
前記データを検索する場合に前記検索すべきデータについてハッシュ関数によりハッシュバケット要素番号を得て、前記ハッシュマップ表を参照して前記得たハッシュバケット要素番号に対応する前記ハッシュマップ表のエントリに記憶されている前記分割番号を得て、前記ハッシュバケット要素番号と予め対応付けられている前記データベース格納領域における前記分割番号に対応付けられた前記管理テーブルの位置情報を参照して前記検索すべき前記データ格納領域を特定し、当該データ格納領域について当該検索すべきデータを探索することを特徴とするデータベース管理装置。 - 前記データに含まれる第１の項目と第２の項目について、前記第１の項目に対してキーレンジ分割を適用し、前記第２の項目に対して前記ハッシュ関数を適用することを特徴とする請求項５または請求項６記載のデータベース管理装置。
- 前記データベース格納領域を一つ追加した場合、（所定数＋１）の前記データベース格納領域について、前記ハッシュ関数を利用して、追加以前の前記データベース格納領域の対応付けられている前記ハッシュマップ表のエントリから前記追加したデータベース格納領域に割り付けるべき前記エントリを特定する手段と、
前記特定されたハッシュマップ表のエントリに格納された前記ハッシュバケット要素番号と該エントリに対応する前記分割番号とを得て、当該得た前記ハッシュバケット要素番号と当該得た分割番号に対応するデータベース格納領域とデータ格納領域を前記ハッシュマップ表の変更後の新しい前記分割番号に基づいて前記追加したデータベース格納領域に当該特定対象のデータ格納領域に格納されたデータを移動する手段とを備えたことを特徴とする請求項５または請求項６記載のデータベース管理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP32365799A JP4199888B2 (ja) | 1999-11-15 | 1999-11-15 | データベース管理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP32365799A JP4199888B2 (ja) | 1999-11-15 | 1999-11-15 | データベース管理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001142752A JP2001142752A (ja) | 2001-05-25 |
| JP4199888B2 true JP4199888B2 (ja) | 2008-12-24 |
Family
ID=18157163
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP32365799A Expired - Lifetime JP4199888B2 (ja) | 1999-11-15 | 1999-11-15 | データベース管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4199888B2 (ja) |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006134191A (ja) | 2004-11-09 | 2006-05-25 | Hitachi Ltd | 文書検索方法およびそのシステム |
| JP2006293981A (ja) * | 2005-03-18 | 2006-10-26 | Hitachi Ltd | データベース格納方法、および、データベース格納システム |
| JP4581962B2 (ja) | 2005-10-27 | 2010-11-17 | 株式会社日立製作所 | 情報検索システムとインデクス管理方法およびプログラム |
| JP4813155B2 (ja) * | 2005-11-17 | 2011-11-09 | 三菱電機株式会社 | データ管理装置、データ管理装置のデータ管理方法およびデータ管理プログラム |
| JP5084310B2 (ja) | 2007-03-16 | 2012-11-28 | 日本電気株式会社 | 複数プロセッサに分散されたデータを再配置可能なデータベースサーバ、再配置方法、およびプログラム |
| JP5203733B2 (ja) * | 2008-02-01 | 2013-06-05 | 株式会社東芝 | コーディネータサーバ、データ割当方法及びプログラム |
| JP5408600B2 (ja) | 2008-05-28 | 2014-02-05 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 決定装置、データベース装置、プログラムおよび決定方法 |
| US8122225B2 (en) | 2008-08-12 | 2012-02-21 | International Business Machines Corporation | LUN masking/mapping in a SR-IOV enabled SAS adapter |
| JP4688111B2 (ja) * | 2008-11-28 | 2011-05-25 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 情報処理装置、データベース・システム、情報処理方法、およびプログラム |
| JP5023047B2 (ja) * | 2008-12-02 | 2012-09-12 | 株式会社日立製作所 | データベース管理方法、データベース管理プログラム、および、データベース受付装置 |
| US9684702B2 (en) | 2010-12-07 | 2017-06-20 | International Business Machines Corporation | Database redistribution utilizing virtual partitions |
| JP5733124B2 (ja) * | 2011-09-12 | 2015-06-10 | 富士通株式会社 | データ管理装置、データ管理システム、データ管理方法、及びプログラム |
| JP5759881B2 (ja) * | 2011-12-08 | 2015-08-05 | 株式会社日立ソリューションズ | 情報処理システム |
| JP6269140B2 (ja) | 2014-02-14 | 2018-01-31 | 富士通株式会社 | アクセス制御プログラム、アクセス制御方法、およびアクセス制御装置 |
| US10198589B2 (en) * | 2015-01-03 | 2019-02-05 | Mcafee, Llc | Secure distributed backup for personal device and cloud data |
| JP6657706B2 (ja) * | 2015-09-24 | 2020-03-04 | 日本電気株式会社 | データ管理装置、データ管理方法およびプログラム |
| WO2021133405A1 (en) * | 2019-12-27 | 2021-07-01 | Hitachi Vantara Llc | Dynamic adaptive partition splitting |
| CN113849496B (zh) * | 2020-06-28 | 2025-04-01 | 金篆信科有限责任公司 | 一种数据重分布的方法和装置 |
| CN115168364A (zh) * | 2022-07-31 | 2022-10-11 | 浙江移动信息系统集成有限公司 | 一种基于NVM的分区Clevel hash索引结构及数据处理方法 |
| CN115268816B (zh) * | 2022-08-17 | 2026-01-16 | 维沃移动通信有限公司 | 分屏控制方法、装置、电子设备和可读存储介质 |
| CN116303343A (zh) * | 2023-01-09 | 2023-06-23 | 天津南大通用数据技术股份有限公司 | 数据分片方法、装置、电子设备及存储介质 |
-
1999
- 1999-11-15 JP JP32365799A patent/JP4199888B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001142752A (ja) | 2001-05-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4199888B2 (ja) | データベース管理方法 | |
| JP4206586B2 (ja) | データベース管理方法および装置並びにデータベース管理プログラムを記録した記憶媒体 | |
| EP2264617B1 (en) | Method and apparatus for replicating a database | |
| US7558802B2 (en) | Information retrieving system | |
| US5274807A (en) | Method for reducing magnetic storage volume for computer disk image backup | |
| US5237681A (en) | Relational data base memory utilization analyzer | |
| CA2209549C (en) | Method and apparatus for loading data into a database in a multiprocessor environment | |
| US7213025B2 (en) | Partitioned database system | |
| US7673099B1 (en) | Affinity caching | |
| US7418544B2 (en) | Method and system for log structured relational database objects | |
| JP2005267600A5 (ja) | ||
| US8250075B2 (en) | System and method for generation of computer index files | |
| US20210209087A1 (en) | Reorganization of Databases by Sectioning | |
| US6606631B1 (en) | IMS on-line reorganization utility | |
| US12505082B2 (en) | Method of processing data in a database | |
| JP3666907B2 (ja) | データベース用ファイル格納管理システム | |
| US6957216B2 (en) | Method and apparatus for finding nearest logical record in a hash table | |
| US8818990B2 (en) | Method, apparatus and computer program for retrieving data | |
| CN118643025A (zh) | 文件迁移方法、装置、设备和存储介质 | |
| RU2621628C1 (ru) | Способ организации хранения связанных данных | |
| JP4825504B2 (ja) | データ登録・検索システムおよびデータ登録・検索方法 | |
| JP2010061604A (ja) | 整合性検証システム、検証方法およびプログラム | |
| Grossman et al. | Data Mining Using Light Weight Object Management in Clustered Computing Environments. | |
| JPH113260A (ja) | データベース管理方法 | |
| CN118069365A (zh) | 一种面向分布式图数据库的数据快速装载方法、系统、设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040929 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20060512 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20060512 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071113 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080115 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080701 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080829 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080924 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081006 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111010 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 4199888 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121010 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121010 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131010 Year of fee payment: 5 |
|
| EXPY | Cancellation because of completion of term |