JP2001282599A - データ管理方法および装置並びにデータ管理プログラムを格納した記録媒体 - Google Patents
データ管理方法および装置並びにデータ管理プログラムを格納した記録媒体Info
- Publication number
- JP2001282599A JP2001282599A JP2000101211A JP2000101211A JP2001282599A JP 2001282599 A JP2001282599 A JP 2001282599A JP 2000101211 A JP2000101211 A JP 2000101211A JP 2000101211 A JP2000101211 A JP 2000101211A JP 2001282599 A JP2001282599 A JP 2001282599A
- Authority
- JP
- Japan
- Prior art keywords
- data
- key
- pointer
- data structure
- log record
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】
【課題】複数アクセスが可能な環境下において、同一キ
ーに対するインデクスアクセスを効率的に行うデータ管
理方法を提供することにある。 【解決手段】あるキーに関連するデータポインタを追加
もしくは削除する際に、そのキーに関連する複数のデー
タポインタを格納する前記データ構造に対し、そのデー
タポインタを追加もしくは削除するための情報を含む第
１のログレコードを取得し、リーフノードに格納された
そのキーを含むインデクスエントリを更新するステップ
と、さらに、前記データ構造へのそのデータポインタの
追加もしくは削除が行われたことを示す情報を含む第２
のログレコードを取得し、前記データ構造に、そのデー
タポインタを追加もしくは削除するステップを有するも
のである。
ーに対するインデクスアクセスを効率的に行うデータ管
理方法を提供することにある。 【解決手段】あるキーに関連するデータポインタを追加
もしくは削除する際に、そのキーに関連する複数のデー
タポインタを格納する前記データ構造に対し、そのデー
タポインタを追加もしくは削除するための情報を含む第
１のログレコードを取得し、リーフノードに格納された
そのキーを含むインデクスエントリを更新するステップ
と、さらに、前記データ構造へのそのデータポインタの
追加もしくは削除が行われたことを示す情報を含む第２
のログレコードを取得し、前記データ構造に、そのデー
タポインタを追加もしくは削除するステップを有するも
のである。
Description
【０００１】
【発明の属する技術分野】本発明はデータ管理技術に関
し，あるインデクスのキーに対して複数のデータを管理
する場合に適用して有効な技術に関するものである。
し，あるインデクスのキーに対して複数のデータを管理
する場合に適用して有効な技術に関するものである。
【０００２】
【従来の技術】近年インタネットを利用した業務システ
ムの急速な普及に伴い、システムを支えるデータベース
管理システム(DBMS)の適用分野も拡大している。さらに
それに伴いDBMSの扱うデータ量も年々増加している。そ
のシステム中には、ワークフローにおける「業務推移状
態」など、値域の狭いデータに対してDBMSの最も代表的
な高速検索手段であるB木インデクスを利用するような
アプリケーションも多く、Ｂ木インデクスの安定した性
能の提供が重要となっている。
ムの急速な普及に伴い、システムを支えるデータベース
管理システム(DBMS)の適用分野も拡大している。さらに
それに伴いDBMSの扱うデータ量も年々増加している。そ
のシステム中には、ワークフローにおける「業務推移状
態」など、値域の狭いデータに対してDBMSの最も代表的
な高速検索手段であるB木インデクスを利用するような
アプリケーションも多く、Ｂ木インデクスの安定した性
能の提供が重要となっている。
【０００３】Ｂ木インデクスに関しては、例えば、文献
(Jim Gray and Andreas Reuter, Transaction Processi
ng: Concepts and Techniques, Morgan Kaufmann Publi
shers, 1993)に、基本的はデータ構造、複数処理からの
同時アクセス方法、および回復に関する基本方式につい
て開示している。
(Jim Gray and Andreas Reuter, Transaction Processi
ng: Concepts and Techniques, Morgan Kaufmann Publi
shers, 1993)に、基本的はデータ構造、複数処理からの
同時アクセス方法、および回復に関する基本方式につい
て開示している。
【０００４】実システムとしての高速なＢ木インデクス
を実現するためには、次の課題を解消する必要がある。
を実現するためには、次の課題を解消する必要がある。
【０００５】（ｉ）複数処理による同時実行性の向上 レコードを含むデータベーステーブルに対して複数のト
ランザクションが同時にアクセスしてくる場合、問題が
起こる。具体的には、あるトランザクションが１つのレ
コードを更新しようとしたとき、同時に他のトランザク
ションが同一レコードにアクセスしようとするとき、競
合状況が発生する。競合問題の解決法の１つとして、レ
コードまたはＢ木インデクスのある部分（Ｂ木インデク
ス全体、ノード、インデクスエントリ、キー値など）に
対するロッキング方式（排他的アクセス方式）がある。
ロッキング方式は、データにアクセスする前に強制的に
トランザクションにロックを取得させ。このとき他のト
ランザクションによってロックがかけられている場合、
そのロックが衝突するために、必要なロックを取得でき
ないことがある。ロッキング方式は自トランザクション
の更新結果や参照結果を確実に保証してくれるが、ロッ
クを取得中は他のトランザクションのアクセスをロック
解除まで待たすので、システムの多重度(同時実行性)を
高めスループットを上げるためには、１つのトランザク
ションが同時に取得するロックの数やロックによる影響
範囲（粒度）を最小限に抑えることが重要である。
ランザクションが同時にアクセスしてくる場合、問題が
起こる。具体的には、あるトランザクションが１つのレ
コードを更新しようとしたとき、同時に他のトランザク
ションが同一レコードにアクセスしようとするとき、競
合状況が発生する。競合問題の解決法の１つとして、レ
コードまたはＢ木インデクスのある部分（Ｂ木インデク
ス全体、ノード、インデクスエントリ、キー値など）に
対するロッキング方式（排他的アクセス方式）がある。
ロッキング方式は、データにアクセスする前に強制的に
トランザクションにロックを取得させ。このとき他のト
ランザクションによってロックがかけられている場合、
そのロックが衝突するために、必要なロックを取得でき
ないことがある。ロッキング方式は自トランザクション
の更新結果や参照結果を確実に保証してくれるが、ロッ
クを取得中は他のトランザクションのアクセスをロック
解除まで待たすので、システムの多重度(同時実行性)を
高めスループットを上げるためには、１つのトランザク
ションが同時に取得するロックの数やロックによる影響
範囲（粒度）を最小限に抑えることが重要である。
【０００６】（ii）回復処理制御 実システムにおいては、トランザクションの中断、シス
テムダウン、媒体障害など種々の障害に関して、トラン
ザクションの原子性(Atomicity)を保証し、かつＢ木イ
ンデクス内のデータの整合性を保証する必要がある。そ
のためのログレコード取得方式およびログレコードを使
用した回復処理制御が重要となる。ログレコードに取得
方式には、インデクスを構成するノードの更新前・更新
後の物理イメージをログレコードの情報をして取得する
物理ログ方式などがある。物理イメージを用いた回復で
は、更新を行ったトランザクションの完了まで、他トラ
ンザクションはそのページへのアクセスが制限されるこ
とになる。すわち、回復処理制御は排他制御と密接に関
係し、同時実行性にも影響を与える。
テムダウン、媒体障害など種々の障害に関して、トラン
ザクションの原子性(Atomicity)を保証し、かつＢ木イ
ンデクス内のデータの整合性を保証する必要がある。そ
のためのログレコード取得方式およびログレコードを使
用した回復処理制御が重要となる。ログレコードに取得
方式には、インデクスを構成するノードの更新前・更新
後の物理イメージをログレコードの情報をして取得する
物理ログ方式などがある。物理イメージを用いた回復で
は、更新を行ったトランザクションの完了まで、他トラ
ンザクションはそのページへのアクセスが制限されるこ
とになる。すわち、回復処理制御は排他制御と密接に関
係し、同時実行性にも影響を与える。
【０００７】図１１に、従来の代表的なＢ木インデクス
の構造を示す。
の構造を示す。
【０００８】Ｂ木インデクスは、１つのルートノードを
頂点に、ルートノードから多数のレベルにわたりノード
が枝分かれしている。枝分かれしたノードの内末端のノ
ードをしばしばリーフノードと呼ぶ。またルートノード
を含むリーフノード以外のノードをしばしば上位ノード
と呼ぶ。各ノード内は以下に示す情報から構成される複
数のインデクスエントリを持つ。リーフノード内のイン
デクスエントリは、データベース中のレコード(テーブ
ルデータ)を示すポインタと、そのレコード(テーブルデ
ータ)の特徴の１つを表すキー値から構成される。また
上位ノード内のインデクスエントリは、次の下位レベル
にあるノード（子ノード）を示すポインタと、その子ノ
ードから枝分かれして最終的にリーフノードで管理され
ているキー値の範囲を示す１キー値から構成される。上
位インデクスエントリ内のキー値は、Ｂ木インデクスへ
のアクセス・プログラムがルートノードから目的とする
レコードへのポインタを含むインデクスエントリが格納
管理されているリーフノードへと辿っていく際の道しる
べ（判定要素）の役割を担う。通常Ｂ木インデクスの１
ノードは、データベース上では、アクセス単位であるペ
ージによって実現される。
頂点に、ルートノードから多数のレベルにわたりノード
が枝分かれしている。枝分かれしたノードの内末端のノ
ードをしばしばリーフノードと呼ぶ。またルートノード
を含むリーフノード以外のノードをしばしば上位ノード
と呼ぶ。各ノード内は以下に示す情報から構成される複
数のインデクスエントリを持つ。リーフノード内のイン
デクスエントリは、データベース中のレコード(テーブ
ルデータ)を示すポインタと、そのレコード(テーブルデ
ータ)の特徴の１つを表すキー値から構成される。また
上位ノード内のインデクスエントリは、次の下位レベル
にあるノード（子ノード）を示すポインタと、その子ノ
ードから枝分かれして最終的にリーフノードで管理され
ているキー値の範囲を示す１キー値から構成される。上
位インデクスエントリ内のキー値は、Ｂ木インデクスへ
のアクセス・プログラムがルートノードから目的とする
レコードへのポインタを含むインデクスエントリが格納
管理されているリーフノードへと辿っていく際の道しる
べ（判定要素）の役割を担う。通常Ｂ木インデクスの１
ノードは、データベース上では、アクセス単位であるペ
ージによって実現される。
【０００９】
【発明が解決しようとする課題】Ｂ木インデクスに対す
る排他制御方式の一つにインデクスの排他資源の粒度を
「キー」とするキー値排他方式もしくはキーレンジ排他
方式がある。これらインデクスのキーに対する排他制御
を用いた場合、同一キーを持つデータ(行)に対する検索
・更新処理はインデクスキー排他によりシリアライズさ
れ、同時実行性が低下する。現在急速な普及をみせてい
るWEB環境下におけるトランザクションは、従来のＯＬ
ＴＰのトランザクションの長さに較べ長く、キーに対す
る排他制御方式では高スループットのサービスの提供は
困難である。
る排他制御方式の一つにインデクスの排他資源の粒度を
「キー」とするキー値排他方式もしくはキーレンジ排他
方式がある。これらインデクスのキーに対する排他制御
を用いた場合、同一キーを持つデータ(行)に対する検索
・更新処理はインデクスキー排他によりシリアライズさ
れ、同時実行性が低下する。現在急速な普及をみせてい
るWEB環境下におけるトランザクションは、従来のＯＬ
ＴＰのトランザクションの長さに較べ長く、キーに対す
る排他制御方式では高スループットのサービスの提供は
困難である。
【００１０】また、図１１に示すように多数の同一キー
有するＢ木インデクスに関して、以下のような問題もあ
る。図１１のＢ木インデクスでは、あるキーに関連する
テーブルデータ情報を１つのリーフエントリ１６で管理
している。リーフエントリ１６は、キー１４、そのキー
値に関連するテーブルデータ情報１８(データレコード
識別子)、そのキー値に関連するテーブルデータに関す
る情報１８の個数１７（超複数）を有する。テーブルデ
ータ情報１８は重複数分リスト形式にて昇順に配置され
ている。このような格納方式では、あるキーに対する重
複数が多くなると、リーフエントリ自体の長さがリーフ
ノード１２に収まりきれなくなる。結果的に、１つのキ
ーに対するテーブルデータ情報を複数のリーフエントリ
として、複数のノードに分けて格納しなければならな
い。図１１の例では、キー「２８」のエントリがリーフ
ノードＮ４、Ｎ５、Ｎ６と３つのノードに分かれて格納
されている。この構造では、範囲検索に対応するための
リーフリーフノードの水平方向のポインタを用いたスキ
ャンにおいて、キー「２８」のエントリがネックとな
る。またさらに、ルートノード１０および上位ノード１
３に格納されている上位エントリ１３に含まれるキー１
４は、「２８」に加えテーブルデータ情報でキーとしな
ければならず、ルートノード１０および上位ノード１３
の数を増大する要因となっている。結果的に、重複キー
は、重複キーそのものに対するアクセス処理だけでな
く、Ｂ木インデクス全体のアクセス性能の低下および格
納効率の低下の要因となっている。
有するＢ木インデクスに関して、以下のような問題もあ
る。図１１のＢ木インデクスでは、あるキーに関連する
テーブルデータ情報を１つのリーフエントリ１６で管理
している。リーフエントリ１６は、キー１４、そのキー
値に関連するテーブルデータ情報１８(データレコード
識別子)、そのキー値に関連するテーブルデータに関す
る情報１８の個数１７（超複数）を有する。テーブルデ
ータ情報１８は重複数分リスト形式にて昇順に配置され
ている。このような格納方式では、あるキーに対する重
複数が多くなると、リーフエントリ自体の長さがリーフ
ノード１２に収まりきれなくなる。結果的に、１つのキ
ーに対するテーブルデータ情報を複数のリーフエントリ
として、複数のノードに分けて格納しなければならな
い。図１１の例では、キー「２８」のエントリがリーフ
ノードＮ４、Ｎ５、Ｎ６と３つのノードに分かれて格納
されている。この構造では、範囲検索に対応するための
リーフリーフノードの水平方向のポインタを用いたスキ
ャンにおいて、キー「２８」のエントリがネックとな
る。またさらに、ルートノード１０および上位ノード１
３に格納されている上位エントリ１３に含まれるキー１
４は、「２８」に加えテーブルデータ情報でキーとしな
ければならず、ルートノード１０および上位ノード１３
の数を増大する要因となっている。結果的に、重複キー
は、重複キーそのものに対するアクセス処理だけでな
く、Ｂ木インデクス全体のアクセス性能の低下および格
納効率の低下の要因となっている。
【００１１】GrayはＢ木構造外へのデータ構造にてテー
ブルデータ情報を管理する方法を開示しているが、それ
に対する同時実行制御および回復制御方法に関しては開
示されていない。また、物理ログによる回復処理方式に
ついて開示しているが、先に示したような同一ページに
対する同時実行を実現することができない。このような
問題は、同一キーに対するインデクスアクセスを行う場
合、一般的に発生する。
ブルデータ情報を管理する方法を開示しているが、それ
に対する同時実行制御および回復制御方法に関しては開
示されていない。また、物理ログによる回復処理方式に
ついて開示しているが、先に示したような同一ページに
対する同時実行を実現することができない。このような
問題は、同一キーに対するインデクスアクセスを行う場
合、一般的に発生する。
【００１２】本発明の目的は上記問題を改善し、複数の
アクセスが行われる環境下において、同一キーに対する
インデクスアクセスを好適に行うことが可能な技術を提
供することにある。
アクセスが行われる環境下において、同一キーに対する
インデクスアクセスを好適に行うことが可能な技術を提
供することにある。
【００１３】
【課題を解決するための手段】前記課題を以下の手段に
より改善する。
より改善する。
【００１４】複数ユーザから同時にアクセスされる環境
下で、多数の同一キーを持つＢ木インデクスを管理する
方法において、ある一つのキーに関する複数のデータポ
インタを格納するデータ構造であり、そのキーを含むイ
ンデクスエントリが格納されるリーフノードとは異なる
データ構造であり、そのデータ構造はそのキーを含むイ
ンデクスエントリからポイントされ、複数処理による同
時アクセスが可能であるデータ構造を有し、あるキーに
関連するデータポインタを追加もしくは削除する際に、
そのキーに関連する複数のデータポインタを格納する前
記データ構造に対し、そのデータポインタを追加もしく
は削除するための情報を含む第１のログレコードを取得
し、リーフノードに格納されたそのキーを含むインデク
スエントリを更新し、前記データ構造へのそのデータポ
インタの追加もしくは削除が行われたことを示す情報を
含む第２のログレコードを取得し、前記データ構造に、
そのデータポインタを追加もしくは削除することにより
上記課題を改善する。
下で、多数の同一キーを持つＢ木インデクスを管理する
方法において、ある一つのキーに関する複数のデータポ
インタを格納するデータ構造であり、そのキーを含むイ
ンデクスエントリが格納されるリーフノードとは異なる
データ構造であり、そのデータ構造はそのキーを含むイ
ンデクスエントリからポイントされ、複数処理による同
時アクセスが可能であるデータ構造を有し、あるキーに
関連するデータポインタを追加もしくは削除する際に、
そのキーに関連する複数のデータポインタを格納する前
記データ構造に対し、そのデータポインタを追加もしく
は削除するための情報を含む第１のログレコードを取得
し、リーフノードに格納されたそのキーを含むインデク
スエントリを更新し、前記データ構造へのそのデータポ
インタの追加もしくは削除が行われたことを示す情報を
含む第２のログレコードを取得し、前記データ構造に、
そのデータポインタを追加もしくは削除することにより
上記課題を改善する。
【００１５】
【発明の実施の形態】複数ユーザからの同時アクセス環
境下において、同一キーに対するインデクスアクセスを
効率的に行うことが可能な一実施形態のデータベース処
理システムについて説明する。
境下において、同一キーに対するインデクスアクセスを
効率的に行うことが可能な一実施形態のデータベース処
理システムについて説明する。
【００１６】まず、本発明の概念を図１を用いて簡単に
説明する。
説明する。
【００１７】本実施形態のデータベース管理システムに
おけるＢ木インデクス１は、図１に示すようにキーを用
いて効率的にテーブルデータに関連する情報を取得する
ためのＢ木構造１０１と、キーごとにそのキーに関連付
けられた多数のテーブルデータ情報を管理するデータ構
造１０２(以降「重複キーデータ構造」と呼ぶ)から構成
される。
おけるＢ木インデクス１は、図１に示すようにキーを用
いて効率的にテーブルデータに関連する情報を取得する
ためのＢ木構造１０１と、キーごとにそのキーに関連付
けられた多数のテーブルデータ情報を管理するデータ構
造１０２(以降「重複キーデータ構造」と呼ぶ)から構成
される。
【００１８】Ｂ木構造１０１は、ルートノード１０、中
間ノード１１、リーフノード１２により構成され、１つ
のルートノードを頂点に、ルートノードから多数のレベ
ルにわたりノードが枝分かれしている構造をもつ。ルー
トノード１０および中間ノード１１には、キー１４とそ
のキー値に関連する下位レベルへのノードを示すポイン
タ１３とを有する上位エントリ１３が格納される。それ
ぞれのノード内において、上位エントリ１３およびリー
フエントリ１６は、そのインデクスエントリ１３、１６
が有するキー値の順に格納管理されている。本実施例で
は、図の左から右方向へキー値が昇順に格納されてい
る。それぞれのノード内において、それらソートされた
インデクスエントリをバイナリサーチすることにより、
効率的かつ安定して必要なインデクスエントリにアクセ
スすることができる。一つの上位インデクスエントリが
ポイントする子ノードには、その上位インデクスエント
リ内キー値よりも小さいキー値を持つインデクスエント
リが格納されている。
間ノード１１、リーフノード１２により構成され、１つ
のルートノードを頂点に、ルートノードから多数のレベ
ルにわたりノードが枝分かれしている構造をもつ。ルー
トノード１０および中間ノード１１には、キー１４とそ
のキー値に関連する下位レベルへのノードを示すポイン
タ１３とを有する上位エントリ１３が格納される。それ
ぞれのノード内において、上位エントリ１３およびリー
フエントリ１６は、そのインデクスエントリ１３、１６
が有するキー値の順に格納管理されている。本実施例で
は、図の左から右方向へキー値が昇順に格納されてい
る。それぞれのノード内において、それらソートされた
インデクスエントリをバイナリサーチすることにより、
効率的かつ安定して必要なインデクスエントリにアクセ
スすることができる。一つの上位インデクスエントリが
ポイントする子ノードには、その上位インデクスエント
リ内キー値よりも小さいキー値を持つインデクスエント
リが格納されている。
【００１９】キー１４に関連するテーブルデータが多数
の場合のリーフエントリ２０は、キー１４、そのキー値
に関連するテーブルデータに関する情報の個数１７、及
び、テーブルデータに関する情報を格納する重複キーデ
ータ構造１０２へのポインタ１９を有する。図１の例で
は、キー値「２８」に対して、関連するテーブルデータ
情報数すなわち重複数が「35,678」であることを示して
いる。それら35,678個の情報は、ポインタ１９「Nx1」
にて指される重複データ構造１０２に格納管理されてい
る。
の場合のリーフエントリ２０は、キー１４、そのキー値
に関連するテーブルデータに関する情報の個数１７、及
び、テーブルデータに関する情報を格納する重複キーデ
ータ構造１０２へのポインタ１９を有する。図１の例で
は、キー値「２８」に対して、関連するテーブルデータ
情報数すなわち重複数が「35,678」であることを示して
いる。それら35,678個の情報は、ポインタ１９「Nx1」
にて指される重複データ構造１０２に格納管理されてい
る。
【００２０】一方、キー値「２８」以外のインデクスエ
ントリのように図１の例では、重複数すなわちテーブル
データに関する情報数があまり多くない場合、重複キー
データ構造１０２を持たないリーフエントリ１６として
格納される。リーフエントリ１６は、キー１４、そのキ
ー値に関連するテーブルデータに関する情報１８(デー
タレコード識別子)、そのキー値に関連するテーブルデ
ータに関する情報１８の個数１７を有する。データレコ
ードの追加もしくは更新によって、そのキーに関連する
テーブルデータ情報の重複数がある敷居値を超えた際
に、上記重複キーデータ構造１０２をポイントするリー
フエントリ２０に移行する。
ントリのように図１の例では、重複数すなわちテーブル
データに関する情報数があまり多くない場合、重複キー
データ構造１０２を持たないリーフエントリ１６として
格納される。リーフエントリ１６は、キー１４、そのキ
ー値に関連するテーブルデータに関する情報１８(デー
タレコード識別子)、そのキー値に関連するテーブルデ
ータに関する情報１８の個数１７を有する。データレコ
ードの追加もしくは更新によって、そのキーに関連する
テーブルデータ情報の重複数がある敷居値を超えた際
に、上記重複キーデータ構造１０２をポイントするリー
フエントリ２０に移行する。
【００２１】また、多数のテーブルデータに関連する情
報を格納管理する重複キーデータ構造１０２は以下の特
徴を持つ。
報を格納管理する重複キーデータ構造１０２は以下の特
徴を持つ。
【００２２】(1)アクセスの際に排他を取得することな
く、複数処理による同時アクセスが可能である。
く、複数処理による同時アクセスが可能である。
【００２３】(2)通常処理のアクセスを制限することな
く取り消し処理が可能である。
く取り消し処理が可能である。
【００２４】ここで、矢印１０３はデータレコードの更
新に伴うＢ木インデクス１に対するキー値「２８」、テ
ーブルデータ関連情報「Ｐ１８」の追加更新処理の様子
を示している。まず、この追加更新処理は、キー値「２
８」を用いてＢ木構造１０１のルートノード１０（Ｎ
１）からサーチを開始し、中間ノード１１（Ｎ２）を経
由し、更新対象のキー値「２８」を有するリーフエント
リ２０が格納されているリーフノード１２（Ｎ５）に辿
り着く。そして、リーフエントリ２０を確定し、第１の
ログレコード４１を取得し、エントリ内の重複数１７を
インクリメントする。第１のログレコード４１には、重
複キーデータ構造１０２に対する更新処理を続行するた
めに必要な情報が含まれている。さらに、エントリ内の
重複キーデータ構造１０２へのポインタ１９（Ｎｘ１）
を取得し、重複キーデータ構造１０２へのアクセスを行
う。そして、第２のログレコード４２を取得し、重複キ
ーデータ構造１０２に対し、テーブルデータ関連情報
「Ｐ１８」を追加する。第２のログレコード４２には、
重複キーデータ構造１０２に対しテーブルデータ関連情
報１８の追加が完了したことを示す情報が含まれてい
る。
新に伴うＢ木インデクス１に対するキー値「２８」、テ
ーブルデータ関連情報「Ｐ１８」の追加更新処理の様子
を示している。まず、この追加更新処理は、キー値「２
８」を用いてＢ木構造１０１のルートノード１０（Ｎ
１）からサーチを開始し、中間ノード１１（Ｎ２）を経
由し、更新対象のキー値「２８」を有するリーフエント
リ２０が格納されているリーフノード１２（Ｎ５）に辿
り着く。そして、リーフエントリ２０を確定し、第１の
ログレコード４１を取得し、エントリ内の重複数１７を
インクリメントする。第１のログレコード４１には、重
複キーデータ構造１０２に対する更新処理を続行するた
めに必要な情報が含まれている。さらに、エントリ内の
重複キーデータ構造１０２へのポインタ１９（Ｎｘ１）
を取得し、重複キーデータ構造１０２へのアクセスを行
う。そして、第２のログレコード４２を取得し、重複キ
ーデータ構造１０２に対し、テーブルデータ関連情報
「Ｐ１８」を追加する。第２のログレコード４２には、
重複キーデータ構造１０２に対しテーブルデータ関連情
報１８の追加が完了したことを示す情報が含まれてい
る。
【００２５】図１の例を用いてテーブルデータ関連情報
の追加に関し説明したが、テーブルデータ関連情報の削
除に関しても同様である。リーフエントリ２０をアクセ
スし、第１のログレコード４１を取得し、エントリ内の
重複数１７をデクリメントする。そして、重複キーデー
タ構造１０２をアクセスし、第２のログレコードを取得
した後に、重複キーデータ構造１０２からテーブルデー
タ関連情報１８の削除を行う。
の追加に関し説明したが、テーブルデータ関連情報の削
除に関しても同様である。リーフエントリ２０をアクセ
スし、第１のログレコード４１を取得し、エントリ内の
重複数１７をデクリメントする。そして、重複キーデー
タ構造１０２をアクセスし、第２のログレコードを取得
した後に、重複キーデータ構造１０２からテーブルデー
タ関連情報１８の削除を行う。
【００２６】以上のように、リーフエントリの更新から
重複キーデータ構造への変更順序が一定であり、インデ
クス１を構成するデータリソースへの排他制御を必要と
しないことから、複数処理の同時実行が可能である。ま
た、一連の変更処理結果に対し取り消し要因が発生した
場合、もしくはリーフエントリに対する更新直後に処理
の中断要因が発生した場合でも、前述の第１のログレコ
ード４１および第２のログレコード４２を使用すること
により、同時実行性を失うことなしに取り消し処理を実
施することが可能である。
重複キーデータ構造への変更順序が一定であり、インデ
クス１を構成するデータリソースへの排他制御を必要と
しないことから、複数処理の同時実行が可能である。ま
た、一連の変更処理結果に対し取り消し要因が発生した
場合、もしくはリーフエントリに対する更新直後に処理
の中断要因が発生した場合でも、前述の第１のログレコ
ード４１および第２のログレコード４２を使用すること
により、同時実行性を失うことなしに取り消し処理を実
施することが可能である。
【００２７】具体的には、取り消し処理時、第１のログ
レコード４１と第２のログレコードがペアで取得されて
いる場合、一連の変更処理は完了していると判断し、図
１の例では、キー値「２８」、テーブルデータ関連情報
「Ｐ１８」の削除処理を行う。取り消し処理時、第１の
ログレコード４１しか取得されていない場合は、リーフ
エントリ２０に対する変更処理しか行われていないの
で、第１のログレコードに含まれる情報を用いて重複キ
ーデータ構造２０１に対するテーブルデータ関連情報
「Ｐ１８」の追加処理を行った後、改めてキー値「２
８」、テーブルデータ関連情報「Ｐ１８」の削除処理を
行う。取り消し処理においてもＢ木インデクス１に対す
る変更の順序は常に片方向であるため、他処理との同時
実行性を損なうことはない。以上のように、取り消し処
理を交えても高い同時実行性を提供することが可能であ
る。
レコード４１と第２のログレコードがペアで取得されて
いる場合、一連の変更処理は完了していると判断し、図
１の例では、キー値「２８」、テーブルデータ関連情報
「Ｐ１８」の削除処理を行う。取り消し処理時、第１の
ログレコード４１しか取得されていない場合は、リーフ
エントリ２０に対する変更処理しか行われていないの
で、第１のログレコードに含まれる情報を用いて重複キ
ーデータ構造２０１に対するテーブルデータ関連情報
「Ｐ１８」の追加処理を行った後、改めてキー値「２
８」、テーブルデータ関連情報「Ｐ１８」の削除処理を
行う。取り消し処理においてもＢ木インデクス１に対す
る変更の順序は常に片方向であるため、他処理との同時
実行性を損なうことはない。以上のように、取り消し処
理を交えても高い同時実行性を提供することが可能であ
る。
【００２８】さらに、本重複キーデータ構造２０１をリ
ーフエントリ２０からポイントし、リーフノード１２の
外に格納管理することから、リーフエントリ２０が格納
されているリーフノード１２内には、すべてのテーブル
データ関連情報１８をリーフエントリ１６の有する方式
に較べ、より多くの他のキーを有するリーフエントリの
格納が可能となる。そしてリーフエントリを格納するリ
ーフノード１２の必要数を抑え、最終的に上位ノード１
１の必要数も抑え、Ｂ木インデクス全体の格納容量削減
にもなる。多くのテーブルデータ情報を持たないキーに
対するアクセスに関しても、Ｂ木構造の容量が抑えられ
るため、Ｂ木構造を辿るすべての検索処理および変更処
理に対し安定した性能を提供することが可能である。
ーフエントリ２０からポイントし、リーフノード１２の
外に格納管理することから、リーフエントリ２０が格納
されているリーフノード１２内には、すべてのテーブル
データ関連情報１８をリーフエントリ１６の有する方式
に較べ、より多くの他のキーを有するリーフエントリの
格納が可能となる。そしてリーフエントリを格納するリ
ーフノード１２の必要数を抑え、最終的に上位ノード１
１の必要数も抑え、Ｂ木インデクス全体の格納容量削減
にもなる。多くのテーブルデータ情報を持たないキーに
対するアクセスに関しても、Ｂ木構造の容量が抑えられ
るため、Ｂ木構造を辿るすべての検索処理および変更処
理に対し安定した性能を提供することが可能である。
【００２９】次に図２に本実施形態のデータベース管理
システムの概略構成を示す。ユーザが作成したアプリケ
ーションプログラム６と、問い合わせやリソース管理な
どのデータベースシステム全体の管理を行うデータベー
ス管理システム２がある。上記のデータベース管理シス
テム２は、論理処理部２１、物理処理部２２、システム
制御２３と、データベースアクセス対象となるデータを
永続的にあるいは一時的に格納するデータベース３、そ
してシステムログ４を有する。また、上記データベース
管理システム２はネットワークなどを介して他のシステ
ムと接続されている。
システムの概略構成を示す。ユーザが作成したアプリケ
ーションプログラム６と、問い合わせやリソース管理な
どのデータベースシステム全体の管理を行うデータベー
ス管理システム２がある。上記のデータベース管理シス
テム２は、論理処理部２１、物理処理部２２、システム
制御２３と、データベースアクセス対象となるデータを
永続的にあるいは一時的に格納するデータベース３、そ
してシステムログ４を有する。また、上記データベース
管理システム２はネットワークなどを介して他のシステ
ムと接続されている。
【００３０】上記論理処理部２１は、問合せの構文解析
・意味解析を行う問合せ解析２１１と、適切な処理手順
を生成する最適化処理２１２と、処理手順に対応したコ
ードの生成を行うコード生成２１３を具備している。ま
た、上記生成されたコードに基づき、コードを解釈しデ
ータベース処理実行の指示を物理処理部２２に対して行
うコード解釈実行２１４を具備している。
・意味解析を行う問合せ解析２１１と、適切な処理手順
を生成する最適化処理２１２と、処理手順に対応したコ
ードの生成を行うコード生成２１３を具備している。ま
た、上記生成されたコードに基づき、コードを解釈しデ
ータベース処理実行の指示を物理処理部２２に対して行
うコード解釈実行２１４を具備している。
【００３１】上記物理処理部２２は、データベース３に
格納されているテーブルデータ５に対し、データの格
納、削除、更新、検索処理をデータベースバッファ２４
を介して行うテーブルデータ管理部２２１を具備する。
また、データベース３に格納されているインデクス１を
管理するＢ木インデクス管理部２５を具備している。イ
ンデクス１は、キーを用いて効率的に関連情報にアクセ
スするためのＢ木構造と、キーごとにそのキーに関連付
けられた多数のテーブルデータ情報を管理する重複キー
データ構造から成る。
格納されているテーブルデータ５に対し、データの格
納、削除、更新、検索処理をデータベースバッファ２４
を介して行うテーブルデータ管理部２２１を具備する。
また、データベース３に格納されているインデクス１を
管理するＢ木インデクス管理部２５を具備している。イ
ンデクス１は、キーを用いて効率的に関連情報にアクセ
スするためのＢ木構造と、キーごとにそのキーに関連付
けられた多数のテーブルデータ情報を管理する重複キー
データ構造から成る。
【００３２】Ｂ木インデクス管理部２５は、テーブルデ
ータ５の更新に伴い、それに関連するＢ木インデクス１
に対し、Ｂ木構造に対する変更を行うＢ木構造アクセス
処理２６の機能、および重複データデータ構造に対する
変更を行う重複キーデータ構造アクセス処理２７の機能
を有する。また、インデクス１をアクセスすることによ
り、検索条件であるキーから関連するテーブルデータを
高速に検索するための機能をＢ木構造アクセス処理２６
と重複キーデータ構造アクセス処理２７内に有する。
ータ５の更新に伴い、それに関連するＢ木インデクス１
に対し、Ｂ木構造に対する変更を行うＢ木構造アクセス
処理２６の機能、および重複データデータ構造に対する
変更を行う重複キーデータ構造アクセス処理２７の機能
を有する。また、インデクス１をアクセスすることによ
り、検索条件であるキーから関連するテーブルデータを
高速に検索するための機能をＢ木構造アクセス処理２６
と重複キーデータ構造アクセス処理２７内に有する。
【００３３】上記物理処理部２２は、また、システムで
共用するリソースの排他制御２２３を具備している。本
実施例では、データに対する整合性は、テーブルデータ
５に対する排他制御(排他リソース：テーブルデータ格
納ページID,テーブルデータIDなど)のみで実現し、Ｂ木
インデクス１のリソース(インデクスID,インデクスペー
ジID,キー値など)に対する排他制御は行わない。
共用するリソースの排他制御２２３を具備している。本
実施例では、データに対する整合性は、テーブルデータ
５に対する排他制御(排他リソース：テーブルデータ格
納ページID,テーブルデータIDなど)のみで実現し、Ｂ木
インデクス１のリソース(インデクスID,インデクスペー
ジID,キー値など)に対する排他制御は行わない。
【００３４】システムログ４は、データベース３へのデ
ータ挿入、更新、削除などの更新履歴情報を蓄積する。
その蓄積される情報には、Ｂ木インデクス１に対する変
更に関する履歴情報も含まれる。そして、トランザクシ
ョンの取り消しやシステムダウンなどの種々の状況にお
いて、Ｂ木インデクス１のデータ整合性を回復するため
に使用される。
ータ挿入、更新、削除などの更新履歴情報を蓄積する。
その蓄積される情報には、Ｂ木インデクス１に対する変
更に関する履歴情報も含まれる。そして、トランザクシ
ョンの取り消しやシステムダウンなどの種々の状況にお
いて、Ｂ木インデクス１のデータ整合性を回復するため
に使用される。
【００３５】上記システム制御２３は、ユーザからの問
い合わせ入力、問い合わせ結果の返却、コマンド受付に
よるデータベース保守などを行う。また、前述のシステ
ムログ４の管理を行い、上記物理処理部２２と連携し、
データベース３変更の際に履歴情報であるログレコード
の取得２６を行う。そして、システム制御２３は、読み
込んだログレコードがＢ木インデクスに対する変更処理
に関する場合に、物理処理部２２のＢ木インデクス管理
部２５にそのログレコードを渡し、取り消し処理を依頼
する。依頼されたＢ木インデクス管理部２５は、ログレ
コード内の情報を基に変更取り消し処理を行う。
い合わせ入力、問い合わせ結果の返却、コマンド受付に
よるデータベース保守などを行う。また、前述のシステ
ムログ４の管理を行い、上記物理処理部２２と連携し、
データベース３変更の際に履歴情報であるログレコード
の取得２６を行う。そして、システム制御２３は、読み
込んだログレコードがＢ木インデクスに対する変更処理
に関する場合に、物理処理部２２のＢ木インデクス管理
部２５にそのログレコードを渡し、取り消し処理を依頼
する。依頼されたＢ木インデクス管理部２５は、ログレ
コード内の情報を基に変更取り消し処理を行う。
【００３６】ユーザは、アプリケーションプログラム６
を介し、データベース管理システム２を用いて、データ
ベース３内のテーブルデータ５を構成するデータレコー
ドを探索、アクセスし、変更することができる。データ
ベース管理システム２はデータレコードへの効率のよい
アクセスを実現するために、Ｂ木インデクス１を利用す
る。
を介し、データベース管理システム２を用いて、データ
ベース３内のテーブルデータ５を構成するデータレコー
ドを探索、アクセスし、変更することができる。データ
ベース管理システム２はデータレコードへの効率のよい
アクセスを実現するために、Ｂ木インデクス１を利用す
る。
【００３７】データベース３内のＢ木インデクス１ある
いはテーブルデータ５は、アクセス単位であるページ単
位に、データベースバッファ２４に読み込んでくる(GET
してくる)ことによりアクセスが可能になる。バッファ
上のページを参照（検索）した後、バッファをRELEASE
することにより使用していたバッファに対する利用終了
を宣言し、他処理からのそのバッファの利用を許可す
る。また、バッファ上のページに対して更新を行った
後、バッファをPUTすることにより当該バッファ上のペ
ージがデータベースに反映することを宣言し、使用して
いたバッファの他処理からの利用を許可する。そのバッ
ファ上のページはすぐにはデータベースに反映されず、
ある契機にデータベースに反映される。バッファにGET
したページに他のトランザクションが不当にアクセスし
ないようにバッファに対してラッチをかける。ラッチは
一種のロックであるが通常のロックよりもはるかに取得
期間が短く、獲得と解除を安価に行うことができる。本
実施例では、インデクスノードを参照する際に共用ラッ
チを、更新する際に排他ラッチをかける。排他ラッチに
関する処理はシリアライズされ、共用ラッチ間ではバッ
ファに対する同時参照を可能にする。そして、バッファ
解放の際に獲得中ラッチを解除し、排他ラッチを獲得し
ようとしている他の処理のアクセスを許可する。
いはテーブルデータ５は、アクセス単位であるページ単
位に、データベースバッファ２４に読み込んでくる(GET
してくる)ことによりアクセスが可能になる。バッファ
上のページを参照（検索）した後、バッファをRELEASE
することにより使用していたバッファに対する利用終了
を宣言し、他処理からのそのバッファの利用を許可す
る。また、バッファ上のページに対して更新を行った
後、バッファをPUTすることにより当該バッファ上のペ
ージがデータベースに反映することを宣言し、使用して
いたバッファの他処理からの利用を許可する。そのバッ
ファ上のページはすぐにはデータベースに反映されず、
ある契機にデータベースに反映される。バッファにGET
したページに他のトランザクションが不当にアクセスし
ないようにバッファに対してラッチをかける。ラッチは
一種のロックであるが通常のロックよりもはるかに取得
期間が短く、獲得と解除を安価に行うことができる。本
実施例では、インデクスノードを参照する際に共用ラッ
チを、更新する際に排他ラッチをかける。排他ラッチに
関する処理はシリアライズされ、共用ラッチ間ではバッ
ファに対する同時参照を可能にする。そして、バッファ
解放の際に獲得中ラッチを解除し、排他ラッチを獲得し
ようとしている他の処理のアクセスを許可する。
【００３８】図３は本実施形態のコンピュータシステム
のハードウエア構成の一例を示す図である。コンピュー
タシステム３０００は、ＣＰＵ３００２、主記憶装置３
００１、磁気ディスク装置等の外部記憶装置３００３及
び多数の端末３００４で構成される。主記憶装置３００
１上には、図２を用いて先に説明したデータベース管理
システム２が置かれ、外部記憶装置３００３上にはデー
タベース管理システム３が管理するテーブルデータ５と
インデクス１を含むデータベース３が格納される。ま
た、システムログ４も外部記憶装置３００３上に格納さ
れる。さらに、データベース管理システム２を実現する
プログラム３１００も外部記憶装置３００３上に格納さ
れる。
のハードウエア構成の一例を示す図である。コンピュー
タシステム３０００は、ＣＰＵ３００２、主記憶装置３
００１、磁気ディスク装置等の外部記憶装置３００３及
び多数の端末３００４で構成される。主記憶装置３００
１上には、図２を用いて先に説明したデータベース管理
システム２が置かれ、外部記憶装置３００３上にはデー
タベース管理システム３が管理するテーブルデータ５と
インデクス１を含むデータベース３が格納される。ま
た、システムログ４も外部記憶装置３００３上に格納さ
れる。さらに、データベース管理システム２を実現する
プログラム３１００も外部記憶装置３００３上に格納さ
れる。
【００３９】図８は本実施形態のインデクスのログレコ
ードの一例を示す図である。
ードの一例を示す図である。
【００４０】図８の４１に示す様に、図１にて説明した
リーフエントリ変更時に取得される第１のログレコード
４１は、その変更処理が属するトランザクションの情報
などを含むログレコードヘッダ４１０、変更を示す操作
コード４１１、キー４１２、変更対象であるテーブルデ
ータ情報４１３、そして変更されたリーフエントリが指
す重複キーデータ構造へのポインタ４１４により構成さ
れる。操作コード４１１には、追加処理や削除処理を示
すコードが設定される。図８の例ではその設定コードは
追加処理を示す「INSERT」である。ログレコードヘッダ
４１０には変更対象のＢ木インデクスのインデクスIDや
そのインデクスが格納されるエリア情報も含まれる。キ
ー４１２に設定される値は変更対象であるリーフエント
リ２０内のキー１４の値と同値である。図８の例ではそ
の値は「２８」である。
リーフエントリ変更時に取得される第１のログレコード
４１は、その変更処理が属するトランザクションの情報
などを含むログレコードヘッダ４１０、変更を示す操作
コード４１１、キー４１２、変更対象であるテーブルデ
ータ情報４１３、そして変更されたリーフエントリが指
す重複キーデータ構造へのポインタ４１４により構成さ
れる。操作コード４１１には、追加処理や削除処理を示
すコードが設定される。図８の例ではその設定コードは
追加処理を示す「INSERT」である。ログレコードヘッダ
４１０には変更対象のＢ木インデクスのインデクスIDや
そのインデクスが格納されるエリア情報も含まれる。キ
ー４１２に設定される値は変更対象であるリーフエント
リ２０内のキー１４の値と同値である。図８の例ではそ
の値は「２８」である。
【００４１】重複キーデータ構造へのポインタ４１４
は、リーフエントリ変更は終了したが重複キーデータ構
造変更が完了していない状況にて変更結果取り消し要因
が発生した場合に、重複キーデータ構造に対する変更処
理を続行するための情報である。
は、リーフエントリ変更は終了したが重複キーデータ構
造変更が完了していない状況にて変更結果取り消し要因
が発生した場合に、重複キーデータ構造に対する変更処
理を続行するための情報である。
【００４２】また図８の４２に示す様に、図１にて説明
したリーフエントリ変更時に取得される第２のログレコ
ードは、その変更処理が属するトランザクションの情報
などを含むログレコードヘッダ４２０、変更を示す操作
コード４２１、そして変更対象であるテーブルデータ情
報４２２により構成される。４１１と同様に操作コード
４２１には、追加処理や削除処理を示すコードが設定さ
れる。図８の例ではその設定コードは追加処理を示す
「INSERT」である。また、テーブルデータ情報４２２に
は、第１のログレコード４１の４１３と同じ値が設定さ
れることになる。第２のログレコード４２は、先に図１
を用いて説明したように、重複キーデータ構造に対する
変更処理が終了しているかを示すマーカの役割を担う。
したリーフエントリ変更時に取得される第２のログレコ
ードは、その変更処理が属するトランザクションの情報
などを含むログレコードヘッダ４２０、変更を示す操作
コード４２１、そして変更対象であるテーブルデータ情
報４２２により構成される。４１１と同様に操作コード
４２１には、追加処理や削除処理を示すコードが設定さ
れる。図８の例ではその設定コードは追加処理を示す
「INSERT」である。また、テーブルデータ情報４２２に
は、第１のログレコード４１の４１３と同じ値が設定さ
れることになる。第２のログレコード４２は、先に図１
を用いて説明したように、重複キーデータ構造に対する
変更処理が終了しているかを示すマーカの役割を担う。
【００４３】図４は本実施形態のＢ木インデクス管理部
２５の処理手順を示すフローチャートである。図４では
Ｂ木インデクスに対するテーブルデータ情報追加の場合
のＢ木構造アクセス処理２６の処理内容を表している。
２５の処理手順を示すフローチャートである。図４では
Ｂ木インデクスに対するテーブルデータ情報追加の場合
のＢ木構造アクセス処理２６の処理内容を表している。
【００４４】まず、ステップ４０１において、キーを用
いて、Ｂ木構造をルートノードから上位ノードへと辿
り、リーフノードを確定後、そのリーフノードをデータ
ベースバッファに読み込みバッファ固定(GET)を行う。
次にステップ４０２において、リーフノード内に格納さ
れているリーフエントリをサーチし、変更対象であるリ
ーフエントリの確定を行う。そして、ステップ４０３に
おいてそのリーフエントリのキーに関連するテーブルデ
ータ情報数(重複数)をインクリメントする。ここで、ス
テップ４０４にて、リーフエントリ内に含まれる重複キ
ーデータ構造を指すポインタを取得する。さらに、図８
を用いて説明した第１のログレコードを作成し（ステッ
プ４０５）、作成した第１のログレコードを取得する
（ステップ４０６）。最後にリーフノードをデータベー
スに書き出すように予約し、バッファ固定を解除(PUT)
する（ステップ４０７）。以上でリーフエントリ変更処
理を終了し（ステップ４０８）、引き続き重複キーデー
タ構造に対する変更処理に進む。
いて、Ｂ木構造をルートノードから上位ノードへと辿
り、リーフノードを確定後、そのリーフノードをデータ
ベースバッファに読み込みバッファ固定(GET)を行う。
次にステップ４０２において、リーフノード内に格納さ
れているリーフエントリをサーチし、変更対象であるリ
ーフエントリの確定を行う。そして、ステップ４０３に
おいてそのリーフエントリのキーに関連するテーブルデ
ータ情報数(重複数)をインクリメントする。ここで、ス
テップ４０４にて、リーフエントリ内に含まれる重複キ
ーデータ構造を指すポインタを取得する。さらに、図８
を用いて説明した第１のログレコードを作成し（ステッ
プ４０５）、作成した第１のログレコードを取得する
（ステップ４０６）。最後にリーフノードをデータベー
スに書き出すように予約し、バッファ固定を解除(PUT)
する（ステップ４０７）。以上でリーフエントリ変更処
理を終了し（ステップ４０８）、引き続き重複キーデー
タ構造に対する変更処理に進む。
【００４５】本フローチャートでは、リーフエントリ変
更（４０４）、ログレコード取得（４０５）の順に処理
が行われているが、実際のデータベースへのリーフノー
ドに対する変更結果の反映は、ＷＡＬ(Write-ahead lo
g)プロトコルに従ってログレコードのシステムログへの
書き出しが実施された後に行われる。
更（４０４）、ログレコード取得（４０５）の順に処理
が行われているが、実際のデータベースへのリーフノー
ドに対する変更結果の反映は、ＷＡＬ(Write-ahead lo
g)プロトコルに従ってログレコードのシステムログへの
書き出しが実施された後に行われる。
【００４６】図５は本実施形態のＢ木インデクス管理部
２５の処理手順を示すフローチャートである。図５では
Ｂ木インデクスに対するテーブルデータ情報追加の場合
の重複キーデータ構造アクセス処理２７の処理内容を表
している。
２５の処理手順を示すフローチャートである。図５では
Ｂ木インデクスに対するテーブルデータ情報追加の場合
の重複キーデータ構造アクセス処理２７の処理内容を表
している。
【００４７】重複キーデータ構造に対する変更処理は、
図４のフローチャートで説明したリーフエントリに対す
る変更処理に引き続き行われる。
図４のフローチャートで説明したリーフエントリに対す
る変更処理に引き続き行われる。
【００４８】まず、ステップ５０１において、先に図４
のステップ４０４にて取得したポインタを用いて重複キ
ーデータ構造へアクセスし、ステップ５０２において、
テーブルデータ情報を追加する位置をサーチする。そし
て、図８を用いて説明した第２のログレコードを作成し
（ステップ５０３）、作成した第２のログレコードを取
得する（ステップ５０４）。ここで、重複キーデータ構
造に追加領域があるかを判定する（ステップ５０５）。
追加領域が無い場合、ステップ５０６に進み、新規領域
の割り当てを行い、新規領域追加に伴う重複キーデータ
構造の変更を行う(ステップ５０７)。具体的には重複キ
ーデータ構造が複数のページから構成される場合は、新
規ページ割り当てが行われる。その後ステップ５０８へ
進む。また、ステップ５０５の判定結果が領域有りの場
合、ステップ５０８へ進み、重複キーデータ構造へテー
ブルデータ情報を追加し、重複キーデータ構造に対する
変更処理を終了する（ステップ５０９）。
のステップ４０４にて取得したポインタを用いて重複キ
ーデータ構造へアクセスし、ステップ５０２において、
テーブルデータ情報を追加する位置をサーチする。そし
て、図８を用いて説明した第２のログレコードを作成し
（ステップ５０３）、作成した第２のログレコードを取
得する（ステップ５０４）。ここで、重複キーデータ構
造に追加領域があるかを判定する（ステップ５０５）。
追加領域が無い場合、ステップ５０６に進み、新規領域
の割り当てを行い、新規領域追加に伴う重複キーデータ
構造の変更を行う(ステップ５０７)。具体的には重複キ
ーデータ構造が複数のページから構成される場合は、新
規ページ割り当てが行われる。その後ステップ５０８へ
進む。また、ステップ５０５の判定結果が領域有りの場
合、ステップ５０８へ進み、重複キーデータ構造へテー
ブルデータ情報を追加し、重複キーデータ構造に対する
変更処理を終了する（ステップ５０９）。
【００４９】図６は本実施形態のＢ木インデクス管理部
２５の処理手順を示すフローチャートである。図６では
Ｂ木インデクスに対するテーブルデータ情報削除の場合
のＢ木構造アクセス処理２６の処理内容を表している。
２５の処理手順を示すフローチャートである。図６では
Ｂ木インデクスに対するテーブルデータ情報削除の場合
のＢ木構造アクセス処理２６の処理内容を表している。
【００５０】まず、ステップ６０１において、キーを用
いて、Ｂ木構造をルートノードから上位ノードへと辿
り、リーフノードを確定後、そのリーフノードをデータ
ベースバッファに読み込みバッファ固定(GET)を行う。
次にステップ６０２において、リーフノード内に格納さ
れているリーフエントリをサーチし、変更対象であるリ
ーフエントリの確定を行う。ここで、ステップ６０３に
おいて、リーフエントリ内に含まれる重複キーデータ構
造を指すポインタを取得する。そして、ステップ６０４
において、そのリーフエントリのキーに関連するテーブ
ルデータ情報数(重複数)が、１かどうかを判定する。重
複数が１の場合、ステップ６０５に進みリーフエントリ
の削除を行い、ステップ６０７に進む。ステップ６０４
の判定結果が重複数が１より大きい場合、ステップ６０
６に進み、そのリーフエントリのキーに関連するテーブ
ルデータ情報数(重複数)をデクリメントする。
いて、Ｂ木構造をルートノードから上位ノードへと辿
り、リーフノードを確定後、そのリーフノードをデータ
ベースバッファに読み込みバッファ固定(GET)を行う。
次にステップ６０２において、リーフノード内に格納さ
れているリーフエントリをサーチし、変更対象であるリ
ーフエントリの確定を行う。ここで、ステップ６０３に
おいて、リーフエントリ内に含まれる重複キーデータ構
造を指すポインタを取得する。そして、ステップ６０４
において、そのリーフエントリのキーに関連するテーブ
ルデータ情報数(重複数)が、１かどうかを判定する。重
複数が１の場合、ステップ６０５に進みリーフエントリ
の削除を行い、ステップ６０７に進む。ステップ６０４
の判定結果が重複数が１より大きい場合、ステップ６０
６に進み、そのリーフエントリのキーに関連するテーブ
ルデータ情報数(重複数)をデクリメントする。
【００５１】さらに、図８を用いて説明した第１のログ
レコードを作成し（ステップ６０７）、作成した第１の
ログレコードを取得する（ステップ６０８）。最後にリ
ーフノードをデータベースに書き出すように予約し、バ
ッファ固定を解除(PUT)する（ステップ６０９）。以上
でリーフエントリ変更処理を終了し（ステップ６１
０）、引き続き重複キーデータ構造に対する変更処理に
進む。
レコードを作成し（ステップ６０７）、作成した第１の
ログレコードを取得する（ステップ６０８）。最後にリ
ーフノードをデータベースに書き出すように予約し、バ
ッファ固定を解除(PUT)する（ステップ６０９）。以上
でリーフエントリ変更処理を終了し（ステップ６１
０）、引き続き重複キーデータ構造に対する変更処理に
進む。
【００５２】図７は本実施形態のＢ木インデクス管理部
２５の処理手順を示すフローチャートである。図７では
Ｂ木インデクスに対するテーブルデータ情報削除の場合
の重複キーデータ構造アクセス処理２７の処理内容を表
している。
２５の処理手順を示すフローチャートである。図７では
Ｂ木インデクスに対するテーブルデータ情報削除の場合
の重複キーデータ構造アクセス処理２７の処理内容を表
している。
【００５３】重複キーデータ構造に対する変更処理は、
図６のフローチャートで説明したリーフエントリに対す
る変更処理に引き続き行われる。
図６のフローチャートで説明したリーフエントリに対す
る変更処理に引き続き行われる。
【００５４】まず、ステップ７０１において、先に図４
のステップ６０３にて取得したポインタを用いて重複キ
ーデータ構造へアクセスし、ステップ７０２において、
削除対象テーブルデータ情報の存在位置をサーチする。
そして、図８を用いて説明した第２のログレコードを作
成し（ステップ７０３）、作成した第２のログレコード
を取得する（ステップ７０４）。
のステップ６０３にて取得したポインタを用いて重複キ
ーデータ構造へアクセスし、ステップ７０２において、
削除対象テーブルデータ情報の存在位置をサーチする。
そして、図８を用いて説明した第２のログレコードを作
成し（ステップ７０３）、作成した第２のログレコード
を取得する（ステップ７０４）。
【００５５】次に、ステップ７０５において、重複キー
データ構造からのテーブルデータ情報削除を行う。ここ
で、テーブルデータ情報の削除によって、回収可能な重
複キーデータ構造を構成する領域が発生したかを判定す
る（ステップ７０６）。判定の結果、回収可能領域が発
生した場合、ステップ７０７へ進み領域の回収を行い、
領域回収に伴う重複キーデータ構造の変更を行う(ステ
ップ７０８)。具体的には重複キーデータ構造が複数の
ページから構成される場合は、ページの回収が行われ
る。回収されたページは他の処理における新規ページ割
り当てにより再利用されることとなる。ステップ７０８
後ステップ７０９にて重複キーデータ構造に対する変更
処理を終了する。また、ステップ７０６における判定結
果が、回収可能領域発生なしの場合、そのままステップ
７０９にて重複キーデータ構造に対する変更処理を終了
する。
データ構造からのテーブルデータ情報削除を行う。ここ
で、テーブルデータ情報の削除によって、回収可能な重
複キーデータ構造を構成する領域が発生したかを判定す
る（ステップ７０６）。判定の結果、回収可能領域が発
生した場合、ステップ７０７へ進み領域の回収を行い、
領域回収に伴う重複キーデータ構造の変更を行う(ステ
ップ７０８)。具体的には重複キーデータ構造が複数の
ページから構成される場合は、ページの回収が行われ
る。回収されたページは他の処理における新規ページ割
り当てにより再利用されることとなる。ステップ７０８
後ステップ７０９にて重複キーデータ構造に対する変更
処理を終了する。また、ステップ７０６における判定結
果が、回収可能領域発生なしの場合、そのままステップ
７０９にて重複キーデータ構造に対する変更処理を終了
する。
【００５６】図９は本実施形態のインデクス管理部のイ
ンデクス更新結果取り消し処理の処理手順を示すフロー
チャートである。
ンデクス更新結果取り消し処理の処理手順を示すフロー
チャートである。
【００５７】まず、ステップ９０１において、システム
制御からＢ木インデクス変更に関するログレコードを受
け取る。ステップ９０２において、処理すべきログレコ
ードが存在するかを判定する。処理すべきログレコード
が存在しない場合、ステップ９１３にてインデクス更新
結果取り消し処理を終了する。処理すべきログレコード
が存在する、すなわち受け取りログレコードが存在する
場合、ステップ９０３へ進みログレコードの種別を判定
する。ここでまずログレコードが第２のログレコードか
どうかを判定する（ステップ９０３）。第２のログレコ
ードである場合、ステップ９０４へ進み第２のログレコ
ードを保持する。そして、ステップ９０１へ戻り次のロ
グレコードの処理を行う。ここで次のログレコードは、
第１のログレコードのはずである。ステップ９０３の判
定において、第１のログレコードではない場合、さらに
ステップ９０５にて、ログレコードが第１のログレコー
ドかどうかを判定する。第１のログレコードでない場
合、ステップ９０６にてその他のログレコードに対応す
る更新結果取り消し処理を行い、ステップ９０１へ戻
り、次のログレコードの処理を行う。第１のログレコー
ドである場合、以下の処理を行う。まず第２のログレコ
ードが保持されているかを判定し（ステップ９０７）、
保持されている場合には、リーフエントリおよび重複キ
ーデータ構造に対する一連の変更処理が完了していると
判断し、保持されている第２のログレコードを廃棄し
（ステップ９０８）、ステップ９１０へ進む。第２のロ
グレコードが保持されていない場合、リーフエントリの
変更処理は終わっているが対となる重複キーデータ構造
に対する変更処理が完了していないと判断し、ステップ
９０９にて重複キーデータ構造の対する更新処理を続行
する。その後ステップ９１０へ進む。ステップ９１０で
は、処理中のログレコードが通常処理にて取得されたも
のであるかどうかを判定する。通常処理にて取得された
ログレコードである場合、関連する変更結果を取り消す
必要がある。ステップ９１１にてその取り消し処理を行
う。また、通常処理時取得ではない、すなわち取り消し
処理時における取得の場合、取り消し処理はステップ９
０９を含めすでに完了していると判断し、一連のＢ木イ
ンデクス更新結果の取り消し処理を終了し、ステップ９
０１へ戻り、次のログレコードの処理を行う。
制御からＢ木インデクス変更に関するログレコードを受
け取る。ステップ９０２において、処理すべきログレコ
ードが存在するかを判定する。処理すべきログレコード
が存在しない場合、ステップ９１３にてインデクス更新
結果取り消し処理を終了する。処理すべきログレコード
が存在する、すなわち受け取りログレコードが存在する
場合、ステップ９０３へ進みログレコードの種別を判定
する。ここでまずログレコードが第２のログレコードか
どうかを判定する（ステップ９０３）。第２のログレコ
ードである場合、ステップ９０４へ進み第２のログレコ
ードを保持する。そして、ステップ９０１へ戻り次のロ
グレコードの処理を行う。ここで次のログレコードは、
第１のログレコードのはずである。ステップ９０３の判
定において、第１のログレコードではない場合、さらに
ステップ９０５にて、ログレコードが第１のログレコー
ドかどうかを判定する。第１のログレコードでない場
合、ステップ９０６にてその他のログレコードに対応す
る更新結果取り消し処理を行い、ステップ９０１へ戻
り、次のログレコードの処理を行う。第１のログレコー
ドである場合、以下の処理を行う。まず第２のログレコ
ードが保持されているかを判定し（ステップ９０７）、
保持されている場合には、リーフエントリおよび重複キ
ーデータ構造に対する一連の変更処理が完了していると
判断し、保持されている第２のログレコードを廃棄し
（ステップ９０８）、ステップ９１０へ進む。第２のロ
グレコードが保持されていない場合、リーフエントリの
変更処理は終わっているが対となる重複キーデータ構造
に対する変更処理が完了していないと判断し、ステップ
９０９にて重複キーデータ構造の対する更新処理を続行
する。その後ステップ９１０へ進む。ステップ９１０で
は、処理中のログレコードが通常処理にて取得されたも
のであるかどうかを判定する。通常処理にて取得された
ログレコードである場合、関連する変更結果を取り消す
必要がある。ステップ９１１にてその取り消し処理を行
う。また、通常処理時取得ではない、すなわち取り消し
処理時における取得の場合、取り消し処理はステップ９
０９を含めすでに完了していると判断し、一連のＢ木イ
ンデクス更新結果の取り消し処理を終了し、ステップ９
０１へ戻り、次のログレコードの処理を行う。
【００５８】図１０は本実施形態の重複キーデータ構造
１０２の構成の一例を示す図である。
１０２の構成の一例を示す図である。
【００５９】図１０の例では、重複キーデータ構造１０
２は、実際にテーブルデータ情報を格納するページ１０
０２と、そのページ１００２を指すポインタを有する管
理エントリ１００３を格納するページ１００１より構成
される。
２は、実際にテーブルデータ情報を格納するページ１０
０２と、そのページ１００２を指すポインタを有する管
理エントリ１００３を格納するページ１００１より構成
される。
【００６０】ページ１００１に格納される管理エントリ
１００３は、ページ１００２を指すポインタ１００５、
およびそのページ１００２内に格納されるテーブルデー
タ情報の最大値１００４を有する。ページ１００１内の
管理エントリ１００３は、テーブルデータ情報の最大値
１００４の順にソートされている。
１００３は、ページ１００２を指すポインタ１００５、
およびそのページ１００２内に格納されるテーブルデー
タ情報の最大値１００４を有する。ページ１００１内の
管理エントリ１００３は、テーブルデータ情報の最大値
１００４の順にソートされている。
【００６１】また図１０に示すように、各ページ１００
１は、そのページ１００１内に格納される管理エントリ
１００３内の最大情報１００４よりも大きな最大情報を
持つ管理エントリが格納されるページ１００１へのポイ
ンタを有する。リーフエントリ２０からは、最も小さい
テーブルデータ情報を格納するページ１００２をポイン
トする管理エントリが格納されてるページ１００１がポ
イントされる。
１は、そのページ１００１内に格納される管理エントリ
１００３内の最大情報１００４よりも大きな最大情報を
持つ管理エントリが格納されるページ１００１へのポイ
ンタを有する。リーフエントリ２０からは、最も小さい
テーブルデータ情報を格納するページ１００２をポイン
トする管理エントリが格納されてるページ１００１がポ
イントされる。
【００６２】以上のデータ構造により、図５および図７
にて説明した重複キーデータ構造内のサーチを効率的に
行うことが可能である。
にて説明した重複キーデータ構造内のサーチを効率的に
行うことが可能である。
【００６３】また、ページ１００１もしくはページ１０
０２の新規割り当て・回収は、データベースバッファへ
のＧＥＴ・ＰＵＴにより容易に実現可能である。新規割
り当て・回収の際の第２のログレコードは、図８の例で
示した構成情報の他にページ１００１もしくはページ１
００２のページ識別子を付け加えることにより、取り消
し処理における変更続行処理が容易に可能である。
０２の新規割り当て・回収は、データベースバッファへ
のＧＥＴ・ＰＵＴにより容易に実現可能である。新規割
り当て・回収の際の第２のログレコードは、図８の例で
示した構成情報の他にページ１００１もしくはページ１
００２のページ識別子を付け加えることにより、取り消
し処理における変更続行処理が容易に可能である。
【００６４】以上示したフローチャートの処理は、図３
で例として示したコンピュータシステムにおけるプログ
ラムとして実行される。しかし、そのプログラムは図３
の例の様にコンピュータシステムに物理的に直接接続さ
れる外部記憶装置に格納されるものと限定はしない。ハ
ードディスク装置、フロッピー（登録商標）ディスク装
置等のコンピュータで読み書きできる記憶媒体に格納す
ることができる。また、ネットワークを介して図３のコ
ンピュータシステムとは別のコンピュータシステムに接
続される外部記憶装置に格納することもできる。
で例として示したコンピュータシステムにおけるプログ
ラムとして実行される。しかし、そのプログラムは図３
の例の様にコンピュータシステムに物理的に直接接続さ
れる外部記憶装置に格納されるものと限定はしない。ハ
ードディスク装置、フロッピー（登録商標）ディスク装
置等のコンピュータで読み書きできる記憶媒体に格納す
ることができる。また、ネットワークを介して図３のコ
ンピュータシステムとは別のコンピュータシステムに接
続される外部記憶装置に格納することもできる。
【００６５】このようにすることにより、同一キーを持
つテーブルデータ情報が、アクセスの際に排他を取得す
ることなく複数処理による同時アクセスが可能であり、
且つ通常処理のアクセスを制限することなく取り消し処
理が可能である重複キーデータ構造で管理されるため、
同一キーに対して同時にアクセスする複数の処理に対
し、取り消し処理をも交えた高い同時実行性を提供する
ことが可能である。
つテーブルデータ情報が、アクセスの際に排他を取得す
ることなく複数処理による同時アクセスが可能であり、
且つ通常処理のアクセスを制限することなく取り消し処
理が可能である重複キーデータ構造で管理されるため、
同一キーに対して同時にアクセスする複数の処理に対
し、取り消し処理をも交えた高い同時実行性を提供する
ことが可能である。
【００６６】その重複キーデータ構造はリーフエントリ
からポイントされ、リーフノードの外に格納管理される
ことから、重複キーを有するリーフエントリが格納され
ているリーフノード内により多くの他のキーを有するリ
ーフエントリの格納が可能となる。その結果、Ｂ木イン
デクスの格納容量が抑えられ、安定したアクセス性能を
提供することが可能になる。
からポイントされ、リーフノードの外に格納管理される
ことから、重複キーを有するリーフエントリが格納され
ているリーフノード内により多くの他のキーを有するリ
ーフエントリの格納が可能となる。その結果、Ｂ木イン
デクスの格納容量が抑えられ、安定したアクセス性能を
提供することが可能になる。
【００６７】以上のように、多数の重複キーを有する場
合でも同時実行性に優れ、格納効率のよいＢ木インデク
スを用いたデータ管理方法を提供することができる。
合でも同時実行性に優れ、格納効率のよいＢ木インデク
スを用いたデータ管理方法を提供することができる。
【００６８】本Ｂ木インデクスを用いたデータ管理方法
は、ワークフローにおける「業務推移状態」など、値域
の狭いデータに対してＢ木インデクスを利用するような
アプリケーションに対して非常に有効である。そのアプ
リケーションが利用するＢ木インデクスでは、値域が狭
いため一つのキーに関連するデータ重複数が膨大であ
り、さらに「業務推移状態」などの変化によってＢ木イ
ンデクスに関して頻繁に更新が発生するためである。
は、ワークフローにおける「業務推移状態」など、値域
の狭いデータに対してＢ木インデクスを利用するような
アプリケーションに対して非常に有効である。そのアプ
リケーションが利用するＢ木インデクスでは、値域が狭
いため一つのキーに関連するデータ重複数が膨大であ
り、さらに「業務推移状態」などの変化によってＢ木イ
ンデクスに関して頻繁に更新が発生するためである。
【００６９】以上、Ｂ木について説明してきたが、本発
明は、複数のアクセスが行われる環境下において、同一
キーに対するインデクスアクセスが発生する場合に同様
に適用可能であり、同一キーに対するインデクスアクセ
スを好適に行うことが可能なデータ管理方法および装置
を提供することが可能である。
明は、複数のアクセスが行われる環境下において、同一
キーに対するインデクスアクセスが発生する場合に同様
に適用可能であり、同一キーに対するインデクスアクセ
スを好適に行うことが可能なデータ管理方法および装置
を提供することが可能である。
【００７０】
【発明の効果】本発明によれば、複数のアクセスが行わ
れる環境下において、同一キーに対するインデクスアク
セスを好適に行うことが可能なデータ管理方法および装
置を提供することができる。
れる環境下において、同一キーに対するインデクスアク
セスを好適に行うことが可能なデータ管理方法および装
置を提供することができる。
【図１】本発明の概念図である。
【図２】本実施形態のＢ木インデクスを有するデータベ
ース処理システムの機能ブロックを示す図である。
ース処理システムの機能ブロックを示す図である。
【図３】本実施形態のコンピュータシステムのハードウ
エア構成の一例を示す図である。
エア構成の一例を示す図である。
【図４】本実施形態のＢ木インデクス管理部２５のイン
デクス更新処理の処理手順を示すフローチャートであ
る。
デクス更新処理の処理手順を示すフローチャートであ
る。
【図５】本実施形態のＢ木インデクス管理部２５のイン
デクス更新処理の処理手順を示すフローチャートであ
る。
デクス更新処理の処理手順を示すフローチャートであ
る。
【図６】本実施形態のＢ木インデクス管理部２５のイン
デクス更新処理の処理手順を示すフローチャートであ
る。
デクス更新処理の処理手順を示すフローチャートであ
る。
【図７】本実施形態のＢ木インデクス管理部２５のイン
デクス更新処理の処理手順を示すフローチャートであ
る。
デクス更新処理の処理手順を示すフローチャートであ
る。
【図８】本実施形態のＢ木インデクスのログレコードの
一例を示す図である。
一例を示す図である。
【図９】本実施形態のＢ木インデクス管理部のインデク
ス更新結果取消し処理(回復処理手順)の処理手順を示す
フローチャートである。
ス更新結果取消し処理(回復処理手順)の処理手順を示す
フローチャートである。
【図１０】本実施形態の重複キーデータ構造の構成の一
例を示す図である。
例を示す図である。
【図１１】従来の多くの重複キーを有するＢ木インデク
スの構成を示す図である。
スの構成を示す図である。
１…Ｂ木インデクス、２…データベース管理システム、
３…データベース、４…システムログ、５…テーブルデ
ータ、６…アプリケーションプログラム、２１…論理処
理部、２２…物理処理部、２３…システム制御、２５…
Ｂ木インデクス管理部、２６…Ｂ木構造アクセス処理、
２７…重複キーデータ構造アクセス処理、１０１…Ｂ木
構造、１０２…重複キーデータ構造、４１…第１ログレ
コード、４２…第２ログレコード。
３…データベース、４…システムログ、５…テーブルデ
ータ、６…アプリケーションプログラム、２１…論理処
理部、２２…物理処理部、２３…システム制御、２５…
Ｂ木インデクス管理部、２６…Ｂ木構造アクセス処理、
２７…重複キーデータ構造アクセス処理、１０１…Ｂ木
構造、１０２…重複キーデータ構造、４１…第１ログレ
コード、４２…第２ログレコード。
Claims (7)
- 【請求項１】一つのキーが、該キーを含むデータに関す
る識別情報をデータポインタとして管理し、キー値に基
づいて上記キーに関連するデータポインタを見つけるた
めにＢ木インデクスを用いたデータ管理方法において、 上記一つのキーに関する複数のデータポインタを格納す
るデータ構造であり、そのキーを含むインデクスエント
リが格納されるリーフノードとは異なるデータ構造であ
り、そのデータ構造はそのキーを含むインデクスエント
リからポイントされ、複数処理による同時アクセスが可
能であるデータ構造を有し、 あるキーに関連するデータポインタを追加もしくは削除
する際に、 そのキーに関連する複数のデータポインタを格納する前
記データ構造に対し、そのデータポインタを追加もしく
は削除するための情報を含む第１のログレコードを取得
するステップと、 リーフノードに格納されたそのキーを含むインデクスエ
ントリを更新するステップと、 前記データ構造へのそのデータポインタの追加もしくは
削除が行われたことを示す情報を含む第２のログレコー
ドを取得するステップと、 前記データ構造に、そのデータポインタを追加もしくは
削除するステップとを有し、 上記データポインタの追加もしくは削除を伴う処理結果
を取り消す際に、 前記データ構造へのそのデータポインタの追加もしくは
削除が完了したかどうかを、前記第２のログレコード内
の情報を用いて判定するステップと、 上記判定の結果前記データ構造へのそのポインタの追加
もしくは削除が完了していない場合、第１のログレコー
ド内の情報を用いて、前記データ構造にそのデータポイ
ンタを追加もしくは削除するステップとを有することを
特徴とするデータ管理方法。 - 【請求項２】請求項１において、 第１のログレコードは、そのデータポインタを追加もし
くは削除するための情報として、そのデータポインタ、
およびそのデータポインタが格納されているもしくは格
納されるべきデータ構造へのポインタを含むことを特徴
とするデータ管理方法。 - 【請求項３】請求項１において、 リーフノードに格納されたそのキーを含むインデクスエ
ントリを更新するステップは、データポインタの追加の
際には、インデクスエントリに含まれるそのキーに関連
するデータポインタの数を増やし、データポインタの削
除の際には、削除の結果そのキーに関連するデータポイ
ンタが存在しなくなる場合にはそのインデクスエントリ
を削除もしくは削除状態とし、そのキーに関連する他の
データポインタが存在する場合にはデータポインタの数
を減らす処理を含むことを特徴とするデータ管理方法。 - 【請求項４】請求項１において、 ある一つのキーに関する複数のデータポインタを格納す
るデータ構造に対するアクセスは、そのキー、リーフノ
ード、あるいは当該データ構造を構成するいかなる資源
に対する排他を取得することなし行われることを有する
ことを特徴とするデータ管理方法。 - 【請求項５】請求項１記載のＢ木インデクス管理方法に
おいて、 前記データ構造は複数のノードにより構成され、そのキ
ーに関連する複数のデータポインタを格納する前記デー
タ構造へのデータポインタの追加もしくは削除は、新規
ノードの割り当てもしくは既存ノードの回収を伴うこと
を有することを特徴とするデータ管理方法。 - 【請求項６】一つのキーが、該キーを含むデータに関す
る識別情報をデータポインタとして管理し、キー値に基
づいて上記キーに関連するデータポインタを見つけるた
めにＢ木インデクスを用いたデータ管理装置において、 上記一つのキーに関する複数のデータポインタを格納す
るデータ構造であり、そのキーを含むインデクスエント
リが格納されるリーフノードとは異なるデータ構造であ
り、そのデータ構造はそのキーを含むインデクスエント
リからポイントされ、複数処理による同時アクセスが可
能であるデータ構造を有する記憶手段と、 あるキーに関連するデータポインタを追加もしくは削除
する際に、そのキーに関連する複数のデータポインタを
格納する前記データ構造に対し、そのデータポインタを
追加もしくは削除するための情報を含む第１のログレコ
ードを取得する手段と、 リーフノードに格納されたそのキーを含むインデクスエ
ントリを更新する手段と、 前記データ構造へのそのデータポインタの追加もしくは
削除が行われたことを示す情報を含む第２のログレコー
ドを取得する手段と、 前記データ構造に、そのデータポインタを追加もしくは
削除する手段と、 上記データポインタの追加もしくは削除を伴う処理結果
を取り消す際に、前記データ構造へのそのデータポイン
タの追加もしくは削除が完了したかどうかを、前記第２
のログレコード内の情報を用いて判定する手段と、 上記判定の結果前記データ構造へのそのポインタの追加
もしくは削除が完了していない場合、第１のログレコー
ド内の情報を用いて、前記データ構造にそのデータポイ
ンタを追加もしくは削除する手段とを有することを特徴
とするデータ管理装置。 - 【請求項７】一つのキーが、該キーを含むデータに関す
る識別情報をデータポインタとして管理し、キー値に基
づいて上記キーに関連するデータポインタを見つけるた
めにＢ木インデクスを用いたデータ管理プログラムを記
録した計算機読み取り可能な記録媒体において、 上記一つのキーに関する複数のデータポインタを格納す
るデータ構造であり、そのキーを含むインデクスエント
リが格納されるリーフノードとは異なるデータ構造であ
り、そのデータ構造はそのキーを含むインデクスエント
リからポイントされ、複数処理による同時アクセスが可
能であるデータ構造を有し、 あるキーに関連するデータポインタを追加もしくは削除
する際に、 そのキーに関連する複数のデータポインタを格納する前
記データ構造に対し、そのデータポインタを追加もしく
は削除するための情報を含む第１のログレコードを取得
するステップと、 リーフノードに格納されたそのキーを含むインデクスエ
ントリを更新するステップと、 前記データ構造へのそのデータポインタの追加もしくは
削除が行われたことを示す情報を含む第２のログレコー
ドを取得するステップと、 前記データ構造に、そのデータポインタを追加もしくは
削除するステップとを有し、 上記データポインタの追加もしくは削除を伴う処理結果
を取り消す際に、 前記データ構造へのそのデータポインタの追加もしくは
削除が完了したかどうかを、前記第２のログレコード内
の情報を用いて判定するステップと、 上記判定の結果前記データ構造へのそのポインタの追加
もしくは削除が完了していない場合、第１のログレコー
ド内の情報を用いて、前記データ構造にそのデータポイ
ンタを追加もしくは削除するステップとを有することを
特徴とするデータ管理プログラムを記録した計算機読み
取り可能な記録媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000101211A JP4126843B2 (ja) | 2000-03-31 | 2000-03-31 | データ管理方法および装置並びにデータ管理プログラムを格納した記録媒体 |
| US09/651,102 US6571250B1 (en) | 2000-03-31 | 2000-08-30 | Method and system for processing queries in a data processing system using index |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000101211A JP4126843B2 (ja) | 2000-03-31 | 2000-03-31 | データ管理方法および装置並びにデータ管理プログラムを格納した記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001282599A true JP2001282599A (ja) | 2001-10-12 |
| JP4126843B2 JP4126843B2 (ja) | 2008-07-30 |
Family
ID=18615297
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000101211A Expired - Fee Related JP4126843B2 (ja) | 2000-03-31 | 2000-03-31 | データ管理方法および装置並びにデータ管理プログラムを格納した記録媒体 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6571250B1 (ja) |
| JP (1) | JP4126843B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007249724A (ja) * | 2006-03-17 | 2007-09-27 | Nippon Telegr & Teleph Corp <Ntt> | ＸＰａｔｈ式処理装置、ＸＰａｔｈ式処理方法、および、ＸＰａｔｈ式処理プログラム |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8972380B2 (en) * | 2003-09-29 | 2015-03-03 | International Business Machines Corporaton | System and method for monitoring events against continual range queries |
| US7835953B2 (en) * | 2003-09-29 | 2010-11-16 | International Business Machines Corporation | Method and structure for monitoring moving objects |
| US7536376B2 (en) * | 2003-10-03 | 2009-05-19 | International Business Machines Corporation | Task oriented log retrieval utilizing a self-learning search tool |
| US20050102255A1 (en) * | 2003-11-06 | 2005-05-12 | Bultman David C. | Computer-implemented system and method for handling stored data |
| US20090119577A1 (en) * | 2005-07-20 | 2009-05-07 | Obigo Ab | Method and Arrangement in a Display System |
| US7941451B1 (en) * | 2006-08-18 | 2011-05-10 | Unisys Corporation | Dynamic preconditioning of a B+ tree |
| CN101523391A (zh) * | 2006-10-06 | 2009-09-02 | 日本电气株式会社 | 信息检索系统和信息检索方法及程序 |
| US7853480B2 (en) * | 2007-05-21 | 2010-12-14 | Amazon Technologies, Inc. | System and method for providing export services to merchants |
| US8171003B2 (en) * | 2007-06-06 | 2012-05-01 | Kunio Kamimura | Method and apparatus for changing reference of database |
| CN111782661A (zh) * | 2020-07-21 | 2020-10-16 | 杭州海康威视数字技术股份有限公司 | 一种数据存储方法、数据查询方法和装置 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6175835B1 (en) * | 1996-07-26 | 2001-01-16 | Ori Software Development, Ltd. | Layered index with a basic unbalanced partitioned index that allows a balanced structure of blocks |
-
2000
- 2000-03-31 JP JP2000101211A patent/JP4126843B2/ja not_active Expired - Fee Related
- 2000-08-30 US US09/651,102 patent/US6571250B1/en not_active Expired - Fee Related
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007249724A (ja) * | 2006-03-17 | 2007-09-27 | Nippon Telegr & Teleph Corp <Ntt> | ＸＰａｔｈ式処理装置、ＸＰａｔｈ式処理方法、および、ＸＰａｔｈ式処理プログラム |
| JP4523561B2 (ja) * | 2006-03-17 | 2010-08-11 | 日本電信電話株式会社 | ＸＰａｔｈ式処理装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4126843B2 (ja) | 2008-07-30 |
| US6571250B1 (en) | 2003-05-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5758356A (en) | High concurrency and recoverable B-tree index management method and system | |
| US6792432B1 (en) | Database system with methods providing high-concurrency access in B-Tree structures | |
| US5430869A (en) | System and method for restructuring a B-Tree | |
| CN107077495B (zh) | 数据库管理系统中的高性能事务 | |
| JP4603546B2 (ja) | 効率的なバージョン制御を有するデータベース管理システム | |
| EP0303231B1 (en) | Method and device for enabling concurrent access of indexed sequential data files | |
| US5276872A (en) | Concurrency and recovery for index trees with nodal updates using multiple atomic actions by which the trees integrity is preserved during undesired system interruptions | |
| RU2413984C2 (ru) | Системы и способы манипулирования данными в системе хранения данных | |
| US6772155B1 (en) | Looking data in a database system | |
| US7418544B2 (en) | Method and system for log structured relational database objects | |
| US6606626B1 (en) | Database system with lock manager enhancement for improving concurrency | |
| EP0336035B1 (en) | Tree structure database system | |
| US5287496A (en) | Dynamic, finite versioning for concurrent transaction and query processing | |
| US7376674B2 (en) | Storage of multiple pre-modification short duration copies of database information in short term memory | |
| US8326839B2 (en) | Efficient file access in a large repository using a two-level cache | |
| AU2002303900B2 (en) | Consistent read in a distributed database environment | |
| US20060020634A1 (en) | Method, system and program for recording changes made to a database | |
| Lomet et al. | Access method concurrency with recovery | |
| US20070118547A1 (en) | Efficient index versioning in multi-version databases | |
| JP4340226B2 (ja) | データ項目の使用可能バージョンの提供 | |
| US8825700B2 (en) | Paging hierarchical data | |
| US9922086B1 (en) | Consistent query of local indexes | |
| EP2378420A1 (en) | Ownership reassignment in a shared-nothing database system | |
| CN111143389A (zh) | 事务执行方法、装置、计算机设备及存储介质 | |
| JPH04337850A (ja) | データベース・トランザクション及び照会処理システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040824 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060417 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080115 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080314 |
|
| 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: 20080422 |
|
| 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: 20080505 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130523 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130523 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |