JP6479186B2 - 計算機システム及びデータベース管理方法 - Google Patents

Description

本発明は、概して、データベース管理技術に関する。

一般に、データベース（ＤＢ）のデータ操作時（例えば更新時）には、データ操作のログを出力する必要がある。

高速にログを出力できることが望ましい。例えば、高レートで発生するデータ（例えば、制御システム系のセンサデータ）を高速に分析するためには、ＤＢのテーブルに高いスループットでデータを格納する必要がある。データをＤＢに格納する際には、検索に用いられるインデクスの更新も行われる。この場合、データログ（ＤＢテーブルに対するデータ操作のログ）とインデクスログ（インデクスに対するデータ操作のログ）がそれぞれ出力される。データログ及びインデクスログのいずれも高速に出力できることが望ましい。

特許文献１には、複数の小さなファイルをまとめて１つのファイルとしオフセット管理をする技術が開示されている。

US 8,825,652

一般に、ＤＢサーバのような計算機システムは、複数のプロセッサコア（以下、コア）を有し、各コアがスレッドを実行する。複数のコアが並列に複数のスレッドを実行できる。

処理の競合（例えばログ並列出力時の競合）を避けるために、並列処理を実行する計算機システムの少なくとも一部を論理的に分割することが考えられる。

そこで、ログ並列出力のために、図１に示すように、複数のログバッファが存在する環境を検討する。これにより、複数のスレッドが複数のログを並列に複数のログバッファに格納できる（スレッドに対して、ログバッファが割り当てられていてもよいし、ログバッファが割り当てられていなくてもよい）。なお、この環境では、下記の前提が採用されてよい。
（−）ログバッファ毎に１以上のログファイルが存在してよい。ログファイルは、ＤＢサーバの外部記憶デバイスに存在してもよいし、ＤＢサーバ内のメモリに存在してもよい。（−）複数のＤＢ領域及び複数のログ領域がある。複数のＤＢ領域は、複数のデータ領域及び複数のインデクス領域を含む。いずれの領域も論理領域である。データ領域内のデータは、ＤＢテーブルに書き込まれるデータであり、インデクス領域内のデータは、インデクスに書き込まれるデータであり、ログ領域内のログは、ログファイルに書き込まれるデータである。少なくともデータ領域及びインデクス領域の各々が、１以上のページの集合である。以下、データ領域及びインデクス領域は、いずれも１つのページであるとする。故に、以下、データ領域を「データページ」と言い、インデクス領域を「インデクスページ」と言う。また、以下、データページ及びインデクスページを「ＤＢページ」と総称することがある。ＤＢページは、ＤＢ領域の一例である。また、ログ領域はログファイルであるとする。
（−）ＤＢページの更新としては、論理的な更新と物理的な更新があってよい。論理的な更新とは、ＤＢページへのデータがバッファに書き込まれることでよい。物理的な更新とは、ページ書込みのことでよい。ページ書込みとは、バッファ内のデータ（特に、ＤＢページに実際に書き込まれていないデータであるダーティデータ）が実際にＤＢページに書き込まれることである。ページ書込みは、ページ単位で行われてよい。

図１に示すように、このような環境では、ログバッファからログファイルへのインデクスログの書込みの回数が多いと予測される。理由は、下記の通りである。
（−）１以上のデータページが更新されると、複数のスレッドにより１以上のインデクスページが更新される。ＤＢテーブルが更新されればインデクスの更新も必要になるからである。
（−）１つのインデクスページにつき複数のインデクスログが複数のログバッファに書き込まれることがある。なぜなら、複数のデータページの更新により更新されるインデクスページが共通していることがあるからである。
（−）インデクスページのページ書込みの前に、そのインデクスページに関わるインデクスログがログファイルに書き込まれる（ＷＡＬ（Write Ahead Logging））。なぜなら、コミット処理完了前に障害が発生した場合には、再起動後にログを用いたロールバックによりデータをページ書込み前の状態に復元できるようにするためである。

結果として、インデクスログ出力の並列度が低下し得る。なぜなら、図１に示すように、１つのインデクスページのページ書込みが行われる場合、そのインデクスページに関わる複数のインデクスログが複数のログファイルにスレッドにより書き込まれるが、インデクスログがログファイルに書き込まれている間は、そのログファイルが格納されているログバッファの排他（ロック）待ち（すなわち、そのログバッファへの新たな書込みが待たされること）が生じるからである。

また、ログバッファからログファイルへの書込みの頻度が高い場合、複数のログバッファの各々について、ログ（エントリ）が十分溜まる前にログがログバッファへ書き込まれることになる。このため、ログファイルへの書込みの回数が多い。

このような課題は、インデクスログに限らず、データログについてもあり得る。

バッファからのログの書込みの回数が多いという課題の解決に、複数の小さなファイルをまとめて１つのファイルとする特許文献１の技術を単純に利用することはできない。特許文献１の技術を利用できたとしても、その課題を解決することはできない。特許文献１には、バッファへのログの書き込みとバッファからのログの書き込みとのそれぞれについての開示が無い。

複数のスレッドを並列に実行する複数のプロセッサコアを有する計算機システムにおいて、ログバッファとして、１以上の専有ログバッファと１以上の共有ログバッファが用意される。計算機システムは、データベース（ＤＢ）に対応した複数のＤＢ領域のうち２以上のスレッドにより更新され得ないＤＢ領域を更新するスレッドについて、そのＤＢ領域の更新に関するログの書込み先のログバッファとして、いずれかの専有ログバッファを選択する。計算機システムは、複数のＤＢ領域のうち２以上のスレッドにより更新され得るＤＢ領域を更新するスレッドについて、そのＤＢ領域の更新に関するログの書込み先のログバッファとして、いずれかの共有ログバッファを選択する。各専有ログバッファは、１つのスレッドの１以上のログが存在し得るが２以上のスレッドの２以上のログが混在し得ないログバッファである。各共有ログバッファは、２以上のスレッドの２以上のログが混在し得るログバッファである。

ログバッファからログ領域（例えばログファイル）への書込みの回数を削減することができる。

比較例の説明図である。 実施形態の概要の説明図である。 インデクススプリット時の処理の概要の説明図である。 実施形態に係るシステム全体の構成例を示す。 データ更新の流れの説明図である。 バッファページ管理テーブルの構成例を示す。 インデクスの構成例を示す。 インデクススプリットの一例の説明図である。 ログ出力処理の流れの一例を示す。

以下、図面を参照しながら、一実施形態を説明する。

以下の説明では、データベース管理システム（以下、ＤＢＭＳ）へのクエリの発行元としては、ＤＢＭＳの内部のコンピュータプログラムであってもよいし、ＤＢＭＳの外部のコンピュータプログラム（例えば、クライアント計算機で実行されるコンピュータプログラム）であってよい。

また、以下の説明では、「×××管理テーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「×××管理テーブル」を「×××管理情報」と呼ぶことができる。また、以下の説明において、１つの管理テーブルは、２以上の管理テーブルに分割されてもよいし、２以上の管理テーブルの全部又は一部が１つの管理テーブルであってもよい。

また、以下の説明では、管理情報としてのテーブルが「管理テーブル」と呼ばれ、ＤＢテーブルが単に「テーブル」と呼ばれる。

また、以下の説明では、要素のＩＤ（識別情報）として、番号が使用されるが、それに代えて又は加えて他種のＩＤが使用されてもよい。

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号（又は参照符号における共通符号）を使用し、同種の要素を区別して説明する場合は、要素の番号（要素に割り振られた番号）（又は参照符号）を使用することがある。なお、以下の説明では、要素の番号の先頭は「０」である。

また、以下の説明では、Ｉ／Ｏ（Input/Output）要求は、ライト要求又はリード要求であり、アクセス要求と呼ばれてもよい。

また、以下の説明では、「ｂｂｂ部」を主語として説明を行う場合があるが、これら機能部は、プロセッサによって実行されることで定められた処理をメモリ及び通信ポート（ネットワークＩ／Ｆ）を用いながら行うため、プロセッサを主語とした説明としてもよい。プロセッサは、典型的には、マイクロプロセッサ（例えばＣＰＵ（Central Processing
Unit））を含んでおり、更に、専用ハードウェア（例えばＡＳＩＣ（Application Specific Integrated Circuit）又はＦＰＧＡ（Field-Programmable GateArray））を含んでもよい。また、これら機能部を主語として開示された処理は、計算機が行う処理としてもよい。また、これら機能部の一部または全ては、専用ハードウェアによって実現されてもよい。また、各種機能部は、プログラム配布サーバや、計算機が読み取り可能な記憶媒体によって各計算機にインストールされてもよい。また，各種機能部及びサーバは１つの計算機にインストールされ実行されても良いし，複数の計算機にインストールされ実行されても良い。プロセッサは、制御部の一例であり、処理の一部または全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサ（例えばＣＰＵ）と記憶部を含み、記憶部はさらに配布プログラムと配布対象であるプログラムとを記憶してよい。そして、プログラム配布サーバのプロセッサが配布プログラムを実行することで、プログラム配布サーバのプロセッサは配布対象のプログラムを他の計算機に配布してよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

また、以下の説明において、「スレッド」は、ＯＳスレッドであってもよいし疑似スレッドであってもよい。ＯＳスレッドは、ＯＳ（Operating System）によって管理されるスレッド（例えばカーネルとライブラリによって管理されるスレッド）であり、リアルスレッドと言うこともできる。一方、「擬似スレッド」は、ＤＢＭＳによって管理されるスレッドである。ＯＳスレッドが、ＤＢＭＳによって疑似的に細分化されることで、複数の疑似スレッドを含むことができる。

また、以下の説明において、「記憶部」は、メモリを含んだ１以上の記憶デバイスでよい。例えば、記憶部は、主記憶デバイス（典型的には揮発性のメモリ）及び補助記憶デバイス（典型的には不揮発性の記憶デバイス）のうちの少なくとも主記憶デバイスでよい。

また、以下の説明において、データベースは、テーブルとインデクスとを含む。「ＤＢページ」は、ＤＢ領域の一例である。「データページ」は、データ領域の一例である。「インデクスページ」は、インデクス領域の一例である。「ログファイル」は、ログ領域の一例である。いずれのページも論理領域の一例である。

図２は、実施形態の概要の説明図である。

ＤＢサーバのメモリに、複数（又は１つ）の専有ログバッファ（図では「ＰＬＢ」）と複数（又は１つ）の共有ログバッファ（図では「ＳＬＢ」）とが用意される。本実施形態では、スレッド毎に、専用ログバッファ及び共有ログバッファの両方が用意される。１つのスレッドに割り当てられる専用ログバッファ及び共有ログバッファのそれぞれの数は、１以上でよい。全てのスレッドについて、割り当てられる専有ログバッファの数が同じでなくてもよい。同様に、全てのスレッドについて、割り当てられる共有ログバッファの数も同じでなくてもよい。本実施形態では、１つのスレッド（例えばスレッド０１）に、１つの専有ログバッファ（例えばＰＬＢ０１）と１つの共有ログバッファ（例えばＳＬＢ０１）が割り当てられる。

各専有ログバッファは、その専有ログバッファが割り当てられている１つのスレッドの１以上のログが存在し得るが２以上のスレッドの２以上のログが混在し得ないログバッファである。一方、各共有ログバッファは、２以上のスレッドの２以上のログが混在し得るログバッファである。

ＤＢサーバは、複数のＤＢページのうち２以上のスレッドにより更新され得ないＤＢページを更新するスレッドについて、そのＤＢページの更新に関するログの書込み先のログバッファとして、いずれかの専有ログバッファを選択する。本実施形態では、ＤＢサーバは、そのスレッドに割り当てられている専有ログバッファを選択する。

一方、ＤＢサーバは、複数のＤＢページのうち２以上のスレッドにより更新され得るＤＢページを更新するスレッドについて、そのＤＢページの更新に関するログの書込み先のログバッファとして、いずれかの共有ログバッファを選択する。このため、ログバッファからログファイルへの書込みの回数を削減することができる。なお、２以上のスレッドの２以上のログが１つの共有ログバッファに集約されることになるため、共有ログバッファの競合（排他取得できないこと）が懸念される。しかし、仮に競合が生じても、ログバッファへの書込みのための競合であるため、書込みが待たされる時間は、ログバッファからログファイルへの書込み中にそのログバッファへの書込みが待たされる時間に比べて短い。つまり、影響は比較的小さい。

本実施形態では、ＤＢサーバは、２以上のスレッドにより更新され得るＤＢページを更新するスレッドについて、更新対象のＤＢページ（例えばインデクスページ）を基に一意に共有ログバッファを選択する。従って、２以上のスレッドの更新対象が同一のＤＢページであれば、その２以上のスレッドの２以上のログの集約先共有ログバッファも同一である。その共有ログバッファへ２以上のスレッドがログを書き込むことになる。

また、本実施形態では、複数のスレッドにそれぞれ複数のログファイルが割り当てられる。これにより、２以上のスレッドによる１つのログファイルに対する衝突を回避できる。なお、全てのスレッドについて、割り当てられるログファイルの数が同じでなくてもよい。本実施形態では、１つのスレッド（例えばスレッド０１）に、１つのログファイル（例えばログファイル０１）が割り当てられる。スレッドに割り当てられているログファイルに、そのスレッドに割り当てられている専有ログバッファ及び共有ログバッファ内のログが書き込まれる。

また、本実施形態では、複数のデータページの各々には、いずれかのスレッドが割り当てられている。つまり、１つのスレッドに、１以上のデータページが割り当てられている。各データページには、１つのスレッドが割り当てられている。スレッドは、そのスレッドに割り当てられているデータページを更新し得るが、そのスレッドに割り当てられていないデータページを更新しないようになっている。２以上のデータページが更新されると同一のインデクスページが更新されることがある。少なくとも１つのインデクスページが、２以上のデータページに共通であるからである。従って、本実施形態では、「２以上のスレッドにより更新され得ないＤＢページ」は、データページであり、「２以上のスレッドにより更新され得るＤＢページ」は、インデクスページである。従って、データページの更新ログは、専有ログバッファに書き込まれることになり、データページの更新ログのログバッファへの書込みにおいて、競合は生じない。なお、データページに代えて又は加えてインデクスページがスレッドに割り当てられることの意義は、データページがスレッドに割り当てられることに比べて低いと考えられる。なぜなら、少なくとも１つのインデクスページは、複数のデータページに共通であるからである。

また、本実施形態では、複数のスレッドの各々が、データページ及びインデクスページのいずれも更新し得るスレッドである。ＤＢサーバが、更新対象のＤＢページがデータページであるかインデクスページであるかを判断する。更新対象がデータページであれば、スレッドは、そのデータページの更新ログの書込み先として、そのスレッドに割り当てられている専有ログバッファを選択する。更新対象がインデクスページであれば、スレッドは、そのインデクスページの更新ログの書込み先として、そのインデスクページから一意に特定された共有ログバッファを選択する。このように、スレッドが、データページ及びインデクスページのいずれも更新し得るスレッドであっても、２以上のスレッドの２以上のログを共有ログバッファに集約できる。

また、本実施形態では、インデクスは、木構造のインデクス領域で構成されたＢ木構造のインデクスである。図３に示すように、インデクスページがスプリットされた場合（例えば、リーフインデクスページ（以下、リーフページ）に空きがなくなったため新たなリーフページが追加された場合）、スレッドは、全ての更新対象のリーフページに接続されたいずれかの上位インデクスページから一意に特定される共有ログバッファを選択する。その選択された共有ログバッファに、その上位インデクスページの下位における全ての更新対象リーフページにそれぞれ対応した複数のログが集約され、最終的に、その複数のログが全て同一のログファイルに書き込まれる。このため、リカバリの際に（例えばスプリットされたページを元のページに戻す際に）、ログファイル間でログの突合せを行う必要が無い。

以下、本実施形態を詳細に説明する。

図４は、実施形態に係るシステム全体の構成例を示す。

ＤＢサーバ４０１は、計算機システムの一例であって、例えば、パーソナルコンピュータ、ワークステーションまたはメインフレームであってよく、もしくは、これらの計算機において仮想化プログラムによって構成された仮想的な計算機であってもよい。ＤＢサーバ４０１は、ネットワークアダプタ４１３、メモリ４１２、ホストバスアダプタ４１４、及びそれらに接続されたプロセッサ４１１を有する。ネットワークアダプタ４１３及びホストバスアダプタ４１４は、インターフェースデバイスの一例である。ネットワークアダプタ４１３を介して、クライアント計算機（以下、クライアント）４０２との通信（典型的には通信ネットワークを介した通信）が行われる。ホストバスアダプタ４１４を介して、外部ストレージ装置４０３との通信が行われる。

プロセッサ４１１は、例えば、マイクロプロセッサであり、コンピュータプログラムを実行する。プロセッサ４１１により実行されるコンピュータプログラムは、例えば、ＯＳ（Operating System）及びＤＢＭＳ４８１である。メモリ４１２は、記憶部の一例であり、プロセッサ４１１によって実行されるプログラムと、プログラムが使用するデータを一時的に記憶する。プロセッサ４１１は、複数のコア４３１を有する。なお、複数のコア４３１は、シングルコアプロセッサが複数存在することで実現されてもよい。

ＤＢサーバ４０１では、ＤＢＭＳ４８１が、クライアント４０２のようなクエリ発行元から発行されたクエリを実行し、そのクエリの実行において、ＤＢ４７１からデータを読み出すために、若しくは、ＤＢ４７１にデータを書き込むために、ＤＢ４７１を格納する外部ストレージ装置４０２に対する入出力要求をＯＳに発行する。ＯＳは、その入出力要求を受け付け、外部ストレージ装置４０２へ入出力要求を発行する。クエリは、例えば、構造化問合せ言語（ＳＱＬ、Structured Query Language）によって記述される。

外部ストレージ装置４０２は、複数の記憶デバイスを含んだストレージ装置でもよいし、単一の記憶デバイスでもよい。外部ストレージ装置４０２は、ＤＢＭＳ４８１が管理するＤＢ４７１を記憶するが、ＤＢ４７１のデータに加えて、プログラムやログファイル４７２を記憶してもよい。外部ストレージ装置４０２は、ＤＢサーバ４０１から入出力要求を受け付け、その入出力要求に従いデータの読み書きを行い、その結果をＤＢサーバ４０１に返す。

ＤＢＭＳ４８１は、ＤＢ４７１を管理する。ＤＢ４７１は、１以上のテーブルと１以上のインデクスを含む。テーブルは、１以上のレコードの集合であり、レコードは１以上のカラムから構成される。インデクスは、テーブルの１以上のカラム等を対象として作成されるデータ構造であり、インデクスが対象とするカラム等を含む選択条件によるテーブルへのアクセスを高速化するためのものである。例えば、インデクスは、対象とするカラムの値の毎に、テーブルの中でその値を含むレコードを特定するための情報を保持するデータ構造である。データ構造としては、例えばＢ木が用いられる。レコードを特定するための情報としては、物理アドレスや論理的な行ＩＤ等が用いられることがある。

ＤＢＭＳ４８１は、クエリ実行部４４１、データ管理部４４３、インデクス管理部４４２、ＤＢバッファ管理部４４５、及びログ管理部４４４を含む。

クエリ実行部４４１は、クエリを受け付け、そのクエリを実行し、その実行結果をクエリ発行元に返す。クエリ実行部４４１は、複数のスレッド４２１を含み、複数のスレッド４２１の各々が、いずれかのコア４３１で実行される。例えば、スレッド０１〜０４がそれぞれコア０１〜０４によりそれぞれ実行される。各スレッド４２１が、データページに対するデータ操作もインデクスページに対するデータ操作もログファイルに対するデータ操作も行うことができる。しかし、データページに対するデータ操作を行うスレッドであるデータスレッドと、インデクスページに対するデータ操作を行うスレッドであるインデクススレッドと、ログファイルに対するデータ操作を行うスレッドであるログスレッドとが独立していてもよい。更に、データスレッド、インデクススレッド及びログスレッドの少なくとも１つについて、データ操作として更新を行うスレッドである更新スレッドと、データ操作として参照を行うスレッドである参照スレッドとが独立していてもよい。各スレッド４２１は、テーブルの更新に関し、バッファ管理部４４５が管理するＤＢバッファ４６２内のバッファページ４８１にデータ管理部４４３を介してアクセスしたり、ログ管理部４４４が管理するログバッファ４５３にデータ管理部４４３を介してアクセスしたりできる。また、各スレッド４２１は、インデクスの更新に関し、バッファ管理部４４５が管理するＤＢバッファ４６２内のバッファページ４８１にインデクス管理部４４２を介してアクセスしたり、ログ管理部４４４が管理するログバッファ４５３にインデクス管理部４４２を介してアクセスしたりできる。

ＤＢバッファ管理部４４５は、バッファページ管理テーブル４６１と、ＤＢ４７１のデータを一時的に格納するためのＤＢバッファ４６２とを管理する。ＤＢバッファ４６２は、メモリ４１２上に構成され、１以上のバッファページ４８１を含む。バッファページ４８１は、ＤＢバッファ４６２に存在するＤＢページである。ＤＢバッファ４６２が含むバッファページ４８１の数は、所定の数に制限されていることがある。ＤＢバッファ管理部４４５は、ＤＢ４７１のデータを、例えばＤＢページ単位でＤＢバッファ４６２に読み出し、ＤＢバッファ４６２に格納されているデータを、例えばＤＢページ単位でＤＢ４７１に書き込む。ＤＢバッファ管理部４４５は、クエリ実行部４４１からデータの読出し要求を受け付けた際、読出し要求対象のデータが既にＤＢバッファ４６２に格納されていれば、そのデータをクエリ実行部４４１に返す。一方、読出し要求対象のデータがＤＢバッファ４６２に格納されていなければ、ＤＢバッファ管理部４４５は、そのデータをＤＢ４７１から読み出し、読み出されたデータを、ＤＢバッファ４６２に格納して、そのデータをクエリ実行部４４１に返す。バッファページ管理テーブル４６１は、各バッファページ４８１に関する情報を保持する。

ログ管理部４４４は、ログバッファ選択部４５１を有し、複数のログバッファ４５３を管理する。本実施形態では、上述したように、スレッド４２１毎に、専有ログバッファ（ＰＬＢ）と、共有ログバッファ（ＳＬＢ）とが割り当てられている。ログバッファ選択部４５１は、書込み先のログバッファを選択する。

図１に示すＤＢＭＳ４８１の構成は一例に過ぎない。例えば、ある構成要素は複数の構成要素に分割されていてもよく、複数の構成要素が１つの構成要素に統合されていてもよい。

図５は、データ更新の流れの説明図である。

例えば、スレッド０１が、クライアント４０２からのクエリの実行において、いずれかのデータページ５１１（バッファページ４８１）にレコード５２１を追加する（Ｓ５０１）。これは、テーブル更新の一例である。スレッド０１が、そのテーブル更新のログを、専有ログバッファ０１に書き込む（Ｓ５０２）。なお、専有ログバッファ０１内のログは、スレッド０１に割り当てられているログファイル０１に書き込まれる。

スレッド０１が、Ｓ５０１のテーブル更新に伴い、インデクス５０１の該当リーフページ５１３を更新する（Ｓ５０３）。これは、インデクス更新の一例である。スレッド０１が、更新対象のリーフページ５１３から一意に特定された共有ログバッファ０２に、そのインデクス更新のログを書き込む（Ｓ５０４）。なお、共有ログバッファ０２内のログは、スレッド０２に割り当てられているログファイル０２に書き込まれる。

図６は、バッファページ管理テーブル４６１の構成例を示す。

バッファページ管理テーブル４６１は、バッファページ４８１毎に、バッファページ番号６０１、状態６０２、ＤＢページ番号６０３、データ種別６０４及び格納状態６０５という情報を保持する。

バッファページ番号６０１は、バッファページ４８１の番号である。

状態６０２は、バッファページ４８１の状態を示す。状態６０２として、“Clean”と“Dirty”がある。“Clean”は、バッファページが、外部ストレージ装置４０３内のＤＢページと一致していることを意味する。“Dirty”は、バッファページが、外部ストレージ装置４０３内のＤＢページと不一致であること（つまり、更新されたバッファページがＤＢページとして外部ストレージ装置４０３に書き込まれていないこと）を意味する。

ＤＢページ番号６０３は、バッファページ４８１に対応したＤＢページの番号である。データ種別６０４は、バッファページ４８１のページ種別を示す。例えば、“データページ”は、バッファページ４８１がデータページであることを意味する。

格納状態６０５は、ログバッファ４５３の格納状態を示す。“Ｙ”は、ログファイル４７２に未だ書き込まれていないログが存在することを意味する。ＤＢＭＳ４８１は、“Dirty”のバッファページ４８１をＤＢページとして書き込む際には、格納状態６０５が“Y”である全てのログバッファ４５３内のログをログファイル４７２に書き込んでから、その“Dirty”のバッファページ４８１をＤＢページとして書き込む。そのバッファページ４８１がＤＢページとして書き込まれた後、そのバッファページ４８１の状態６０２は“Dirty”から“Clean”に変更され、そのバッファページ４８１に対応した全ての格納状態６０５“Y”がそれぞれ“N”に変更される。

図７は、インデクス５０１の構成例を示す。

インデクス５０１は、Ｂ木インデクスであり、複数のインデクスページ５１３が木構造になっている。複数のインデクスページ５１３は、複数のリーフページと、１以上の上位ページとで構成される。１以上の上位ページは、少なくともルートページを含む。「リーフページ」は、子ページがいないページ、つまり最下位のページである。「ルートページ」は、親ノードがいないページ、つまり最上位のページである。ルートページ以外の上位ページは、中間ページ（内部ページと呼ばれてもよい）である。中間ページには、親ページと少なくとも１つの子ページとが存在する。

リーフページ間のリンクがある。つまり、各リーフページは、左側リーフページへのポインタ７０１と、右側リーフページへのポインタ７０２と、キー値７０３と、キー値７０３に対応したポインタ（データページ内のレコードへのポインタ）７０４とを含む。リーフページには、複数のキー値７０３が含まれており、キー値７０３毎に、ポインタ７０４が存在する。

図７によれば、リーフページ５１３Ｌは、空きが無いため（満杯であるため）、エントリ（キー値７０３及びポインタ７０４の組）を追加できない。このような状態で、リーフページ５１３Ｌに更にエントリとを追加したい場合には、インデクススプリットが行われる。

図８は、インデクススプリットの一例の説明図である。

インデクススプリットとは、リーフページを増やすことを意味し、例えば、少なくとも１つのリーフページを分割することを意味する。インデクススプリットは、例えば、空きの無いリーフページにエントリを追加しなければならない場合、クライアント４０２等からインデクススプリットの指示をＤＢＭＳ４８１が受けた場合等に実行されてよい。図８によれば、キー値“L”を含んだエントリの追加のためにインデクススプリットが行われる。具体的には、そのエントリの追加先は、キー値の並びによるとリーフページ５１３Ｌになるが、リーフページ５１３Ｌには空きがないために、インデクススプリットが行われる。インデクススプリットは、ＤＢＭＳ４８１（例えばインデクス管理部４４２）により行われる。

インデクス管理部４４２は、新規リーフページ５１３Ｎを生成する（Ｓ９０１）。

次に、インデクス管理部４４２は、新規リーフページ５１３Ｎに関連付けられるべき既存リーフページのポインタを、新規リーフページ５１３Ｎを指すように更新する（Ｓ９０２）。図８の例では、新規リーフページ５１３Ｎの左隣りのリーフページ５１３Ｌのポインタ（右側リーフページへのポインタ）と、新規リーフページ５１３Ｎの右隣りのリーフページ５１３Ｒのポインタ（左側リーフページへのポインタ）とが、それぞれ、新規リーフページ５１３Ｎを指すように更新される。

次に、インデクス管理部４４２は、リーフページ５１３Ｌの一部のエントリ（例えば、キー値“K”及び“M”をそれぞれ含んだ２つの右側エントリ）を、新規リーフページ５１３Ｎへ移動する（Ｓ８０３）。そして、インデクス管理部４４２は、新規リーフページ５１３Ｎに移動された２つのエントリ間に、キー値“L”を含んだエントリを挿入する（Ｓ８０４）。

最後に、インデクス管理部４４２は、リーフページ５１３Ｌ、５１３Ｎ及び５１３Ｌの共通の親ページ５１３Ｐに、新規リーフページ５１３Ｎへのエントリを追加する（Ｓ８０５）。

図８に例示したインデクススプリットによれば、更新対象インデクスページは、リーフページ５１３Ｌ、５１３Ｎ及び５１３Ｌと、親ページ５１３Ｐである。また、更新対象リーフページ５１３Ｌ、５１３Ｎ及び５１３Ｌの共通の上位ページ（先祖ページと呼ばれてもよい）として、親ページ５１３Ｐの他に、ルートページも該当する。本実施形態では、更新対象リーフページ５１３Ｌ、５１３Ｎ及び５１３Ｌの共通の上位ページのうち、最下位のページ（つまり親ページ５１３Ｐ）が、図３を参照して説明した上位ページ（すなわち、集約先共有ログバッファを選択するために使用されるインデクスページ）である。

図９は、ログ出力処理の流れの一例を示す。

ログバッファ選択部４５１は、スレッド（図９の説明において「対象スレッド」と言う）による更新対象のＤＢページがインデクスページか否かを判断する（Ｓ９０１）。

Ｓ９０１の判断結果が否定の場合（Ｓ９０１：Ｎｏ）、すなわち、更新対象ＤＢページがデータページの場合、ログバッファ選択部４５１は、対象スレッドに割り当てられている専有ログバッファを選択する（Ｓ９１１）。対象スレッドが、Ｓ９１１で選択された専有ログバッファの排他（ロック）を取得する（Ｓ９１２）。その後、対象スレッドは、更新ログを、Ｓ９１１で選択された専有ログバッファに書き込み（Ｓ９２７）、その専有ログバッファの排他を解放する（Ｓ９２８）なお、専有ログバッファについては、排他の取得及び解放は省略されてよい。

Ｓ９０１の判断結果が肯定の場合（Ｓ９０１：Ｙｅｓ）、すなわち、更新対象ＤＢページがインデクスページの場合、ログバッファ選択部４５１は、インデクススプリット中か否かを判断する（Ｓ９２１）。インデクススプリット中か否かは、例えば、インデクス管理部４４２に問い合わせることにより特定可能である。

Ｓ９２１の判断結果が否定の場合（Ｓ９２１：Ｎｏ）、ログバッファ選択部４５１は、集約先共有ログバッファの選択に使用するインデクスページとして、更新対象インデクスページであるリーフページを選択する（Ｓ９２２）。

一方、Ｓ９２１の判断結果が肯定の場合（Ｓ９２１：Ｙｅｓ）、ログバッファ選択部４５１は、集約先共有ログバッファの選択に使用するインデクスページとして、更新対象インデクスページのうちの最上位ページを選択する（Ｓ９２３）。Ｓ９２３では、全ての更新対象リーフページに共通のいずれの上位ページが選択されてもよいが、上述したように、更新対象インデクスページのうちの最上位ページが選択される。言い換えれば、全ての更新対象リーフページに共通の上位ページのうちの最下位の上位ページが選択される。これにより、集約先共有ログバッファとして選択される共有ログバッファが集中する確率を低減できる。

Ｓ９２２又はＳ９２３の後、ログバッファ選択部４５１は、１つの共有ログバッファを選択する（Ｓ９２４）。共有ログバッファは、ランダムに選択される等、種々の方法により選択されてよいが、ここでは、Ｓ９２２又はＳ９２３で選択されたインデクスページを基に選択される。具体的には、例えば、ログバッファ選択部４５１は、共有ログバッファ番号＝Hash(p) mod Nにより、共有ログバッファを一意に特定する。“p”は、Ｓ９２２又はＳ９２３で選択されたインデクスページ（対象のインデクスページ）の番号である。“N”は、共有ログバッファの数である。“Hash(x)”ハッシュ関数である。Ｓ９２２又はＳ９２３で選択されたインデクスページ（対象のインデクスページ）の番号から一意に共有ログバッファを選択できる方法は、“共有ログバッファ番号＝Hash(p) mod N”に限られない。

対象スレッドが、Ｓ９２４で選択された共有ログバッファの排他（ロック）を取得する（Ｓ９２５）。

排他取得に成功した場合（Ｓ９２６：Ｙｅｓ）、対象スレッドは、更新ログを、Ｓ９２４で選択された共有ログバッファに書き込み（Ｓ９２７）、その共有ログバッファの排他を解放する（Ｓ９２８）。

一方、排他取得に失敗した場合（Ｓ９２６：Ｎｏ）、ログバッファ選択部４５１は、対象スレッドに割り当てられている専有ログバッファを選択する（Ｓ９１１）。つまり、Ｓ９２４で選択された共有ログバッファが他スレッドとの間で競合した場合、更新ログは、共有ログバッファに集約されず、対象スレッドの専有ログバッファに格納される。これにより、ログバッファへの書き込みを待つことを回避できる。なお、排他取得に失敗した場合、Ｓ９１１の実行に代えて、排他取得できるまで待つことが行われてもよい。

以上、一実施形態を説明したが、本発明は、この実施形態に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、ＤＢ４７１の少なくとも一部が、ＤＢサーバ４０１内のメモリ４１２に存在してよい（例えばインメモリが採用されてもよい）。また、例えば、少なくとも１つのログファイル４７２が、ＤＢサーバ４０１内のメモリ４１２に存在してよい。

４０１…ＤＢサーバ

Claims (13)

1. データベースを管理する計算機システムであって、
   複数のスレッドを並列に実行する複数のプロセッサコアを有するプロセッサと、
   ２以上の専有ログバッファと２以上の共有ログバッファとを有する記憶部と
   を有し、
   前記プロセッサが、
   （Ａ）前記データベースに対応した複数のデータベース領域のうち２以上のスレッドにより更新され得ないデータベース領域を更新するスレッドについて、そのデータベース領域の更新に関するログの書込み先のログバッファとして、いずれかの専有ログバッファを選択し、
   （Ｂ）前記複数のデータベース領域のうち２以上のスレッドにより更新され得るデータベース領域を更新するスレッドについて、そのデータベース領域の更新に関するログの書込み先のログバッファとして、いずれかの共有ログバッファを選択し、
   各専有ログバッファは、１つのスレッドの１以上のログが存在し得るが２以上のスレッドの２以上のログが混在し得ないログバッファであり、
   各共有ログバッファは、２以上のスレッドの２以上のログが混在し得るログバッファである、
   計算機システム。
2. 複数の専有ログバッファの各々が、前記複数のスレッドのいずれかに割り当てられており、
   前記プロセッサが、（Ａ）において、そのスレッドに割り当てられている専有ログバッファを選択する、
   請求項１記載の計算機システム。
3. 複数の共有ログバッファの各々が、前記複数のスレッドのいずれかに割り当てられており、
   前記プロセッサが、（Ｂ）において、複数の共有ログバッファのうちのいずれかの共有ログバッファを選択する、
   請求項２記載の計算機システム。
4. 前記データベースは、テーブルとインデクスとを含み、
   前記複数のデータベース領域は、複数のデータ領域と、複数のインデクス領域とを含み、
   前記複数のデータ領域の各々は、テーブルのデータを含んだデータベース領域であり、
   前記複数のインデクス領域の各々は、インデクスのデータを含んだデータベース領域であり、
   ２以上のスレッドにより更新され得るデータベース領域は、インデクス領域である、
   請求項３記載の計算機システム。
5. （Ｂ）で選択された共有ログバッファは、更新対象のインデクス領域を基に選択された共有ログバッファである、
   請求項４記載の計算機システム。
6. 前記インデクスは、木構造のインデクス領域で構成されたＢ木構造のインデクスであり、
   前記インデクスについてスプリットが行われた場合、（Ｂ）で選択された共有ログバッファは、全ての更新対象のリーフインデクス領域に接続されたいずれかの上位インデクス領域を基に選択された共有ログバッファである、
   請求項５記載の計算機システム。
7. 前記いずれかの上位インデクス領域は、前記全ての更新対象インデクス領域のうちの最上位のインデクス領域である、
   請求項６記載の計算機システム。
8. （Ｂ）で選択された共有ログバッファは、対象のインデクス領域の番号と共有ログバッファの数とを用いて一意に特定された共有ログバッファである、
   請求項５記載の計算機システム。
9. 前記複数のスレッドにそれぞれ複数のログ領域も割り当てられており、
   前記複数のスレッドの各々が、そのスレッドに割り当てられている専有ログバッファ及び共有ログバッファ内のログを、そのスレッドに割り当てられているログ領域に書き込む、
   請求項４記載の計算機システム。
10. 前記複数のデータ領域の各々には、いずれかのスレッドが割り当てられており、
    少なくとも１つのデータ領域が割り当てられているスレッドは、そのスレッドに割り当てられている前記少なくとも１つのデータ領域を更新し得るが、そのスレッドに割り当てられていないデータ領域を更新しないようになっており、
    前記複数のインデクス領域の各々は、２以上のスレッドにより更新され得る、
    請求項４記載の計算機システム。
11. 前記複数のスレッドの各々が、データ領域及びインデクス領域のいずれも更新し得るスレッドであり、
    前記プロセッサが、
    更新対象のデータベース領域がインデクス領域であるか否かを判断し、
    前記判断の結果が否定の場合、（Ａ）の処理を実行し、
    前記判断の結果が肯定の場合、（Ｂ）の処理を実行する、
    請求項１０記載の計算機システム。
12. 前記プロセッサが、（Ｂ）において、前記選択された共有ログバッファのロックを取得してから、前記選択された共有ログバッファにログを書き込むようになっており、
    前記プロセッサが、（Ｂ）において、前記選択された共有ログバッファのロックを取得できない場合、そのスレッドに対応した専有ログバッファにログを書き込む、
    請求項１記載の計算機システム。
13. データベースを管理するデータベース管理方法であって、
    （Ａ）前記データベースに対応した複数のデータベース領域のうち２以上のスレッドにより更新され得ないデータベース領域を更新するスレッドについて、そのデータベース領域の更新に関するログの書込み先のログバッファとして、２以上の専有ログバッファのうちのいずれかの専有ログバッファを選択し、
    （Ｂ）前記複数のデータベース領域のうち２以上のスレッドにより更新され得るデータベース領域を更新するスレッドについて、そのデータベース領域の更新に関するログの書込み先のログバッファとして、２以上の共有ログバッファのうちのいずれかの共有ログバッファを選択し、
    各専有ログバッファは、１つのスレッドの１以上のログが存在し得るが２以上のスレッドの２以上のログが混在し得ないログバッファであり、
    各共有ログバッファは、２以上のスレッドの２以上のログが混在し得るログバッファである、
    データベース管理方法。

Images