JP2018005300A - データベース管理装置、データベース管理方法、およびデータベース管理プログラム - Google Patents

Abstract

【課題】複数の分散化されたデータベース管理装置において、無効レコードに関連する処理負荷を抑制することができるデータベース管理装置、データベース管理方法、およびデータベース管理プログラムを提供することである。【解決手段】実施形態のデータベース管理装置は、複数のデータベース管理装置と、前記複数のデータベース管理装置により共有される記憶装置と、を備え、前記複数のデータベース管理装置のそれぞれは、データ管理部と、削除部とを持つ。データ管理部は、クライアントから登録要求のあったデータを前記記憶装置に書き込む。削除部は、前記データ管理部により前記記憶装置に書き込まれたデータの有効期限を認識可能な第１情報に基づいて、前記記憶装置に記憶されたデータのうち、有効期限を徒過したデータを削除する。【選択図】図１

Description

本発明の実施形態は、データベース管理装置、データベース管理方法、およびデータベース管理プログラムに関する。

データベース管理システム（DataBase Management System，DBMS）では、データベースにレコードを登録する場合に、そのレコードを利用できる有効期限を設定し、有効期限を徒過したレコード（無効レコード）を所定のタイミングで削除する場合がある。無効レコードを削除する手法としては、例えば定期的にテーブル内の全レコードをスキャンし、有効期限を徒過したレコードを削除する手法（ガベージコレクション／オフライン削除）や、アクセス要求のあったレコードにアクセスして、そのレコードの有効期限が徒過していた場合に、レコードの削除を行う手法（インライン削除）がある。しかしながら、従来の技術では、複数の分散化されたシステムにおいて、無効レコードへのアクセス数が増大したり、無効レコードを削除する処理負荷が増大する場合があった。

特開２００５−１４９３４８号公報

本発明が解決しようとする課題は、複数の分散化されたデータベース管理装置において、無効レコードに関連する処理負荷を抑制することができるデータベース管理装置、データベース管理方法、およびデータベース管理プログラムを提供することである。

実施形態のデータベース管理装置は、複数のデータベース管理装置と、前記複数のデータベース管理装置により共有される記憶装置と、を備え、前記複数のデータベース管理装置のそれぞれは、データ管理部と、削除部とを持つ。データ管理部は、クライアントから登録要求のあったデータを前記記憶装置に書き込む。削除部は、前記データ管理部により前記記憶装置に書き込まれたデータの有効期限を認識可能な第１情報に基づいて、前記記憶装置に記憶されたデータのうち、有効期限を徒過したデータを削除する。

本実施形態のデータベース管理装置１００を備えるデータベース管理システム１の機能構成例を示す図。 データベース管理装置１００における登録動作を説明するための図。 データベース管理装置１００におけるデータ登録処理の一例を示すフローチャート。 有効期限付きレコードリスト１４０Ａの一例を示す図。 データベース管理装置１００におけるレコードアクセス時の動作を説明するための図。 データベース管理装置１００におけるレコードアクセス処理の一例を示すフローチャート。 無効レコードエントリ処理の一例を示すフローチャート。 優先削除レコードリスト１４０Ｂの一例を示す図。 データベース管理装置１００における優先削除動作の一例を説明するための図。 データベース管理装置１００における優先削除処理の一例を示すフローチャート。 データベース管理装置１００における定周期削除動作の一例を示す図。 データベース管理装置１００における定周期削除処理の一例を示すフローチャート。 第２の実施例における優先削除レコードリスト１４０Ｂの一例を示す図。 第４の実施例における優先削除レコードリスト１４０Ｂの一例を示す図。 第５の実施例における優先削除レコードリスト１４０Ｂの一例を示す図。 無効レコード削除に関する処理結果の一例を示す図。

以下、実施形態のデータベース管理装置、データベース管理方法、およびデータベース管理プログラムを、図面を参照して説明する。

図１は、本実施形態のデータベース管理装置１００を備えるデータベース管理システム１の機能構成例を示す図である。図１に示すデータベース管理システム１は、複数のデータベース管理装置１００と、複数のデータベース管理装置により共有される１又は複数の記憶装置２００と、データベース管理装置１００に指示を送信し、対応する回答を取得するクライアント３００とを備える。図１の例では、データベース管理システム１として、２つのデータベース管理装置１００−１、１００−２と、２つの記憶装置２００−１、２００−２と、２つのクライアント３００−１、３００−２とを備えるが、これに限定されるものではない。

ここで、データベース管理装置１００−１、１００−２のそれぞれは、同様の構成を有しているため、いずれのデータベース管理装置であるか区別しないときは、いずれのデータベース管理装置であるかを示すハイフン以降の符号を省略し、「データベース管理装置１００」と称して説明する。また同様に、記憶装置２００−１、２００−２、クライアント３００−１、３００−２についても、必要に応じてそれぞれ「記憶装置２００」、「クライアント３００」と称する。なお、データベース管理装置１００、記憶装置２００、およびクライアント３００のそれぞれは、インターネットやＬＡＮ（Local Area Network）等を含む通信ネットワークにより、データの送受信が可能な状態で接続されている。

データベース管理装置１００は、ユーザが使用するクライアント３００からの設定情報の入力や、処理を実行するための指示の入力を受け付け、受け付けた内容に基づいて、記憶装置２００に対するＩ／Ｏ命令を発行する。

データベース管理装置１００は、レコード管理部（データ管理部）１１０と、無効レコード削除部（削除部）１２０と、通信部１３０と、記憶部１４０とを備える。レコード管理部１１０は、レコード登録部１１２と、期限徒過判定部１１４とを備える。無効レコード削除部１２０は、コスト計算部（評価部）１２２と、削除実行部１２４とを備える。これらの構成要素のうち記憶部１４０を除くものの一部または全部は、例えば、コンピュータにおけるＣＰＵ（Central Processing Unit）等のプロセッサが、記憶部１４０等のプログラムメモリに格納されたプログラム（ソフトウェア）を実行することで実現される。また、これらの機能部のうち一部または全部は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）等のハードウェアによって実現されてもよいし、ソフトウェアとハードウェアとの協働により実現されてもよい。また、記憶部１４０は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ等により実現される。

レコード管理部１１０は、クライアント３００から登録要求のあったレコードを記憶装置２００に書き込む。ここで、レコードとは、例えばクライアント３００が書き込みや読み出しを指定する１単位のデータである。レコードは、例えば、各レコードを識別する識別情報と、それに関連付けられたデータとで構成される。

レコード管理部１１０のレコード登録部１１２は、クライアント３００から登録要求のあったデータに対して各データを識別するＩＤ（キー）を付与したレコードを記憶装置２００に書きこむ。このとき、レコード登録部１１２は、登録するレコードＩＤごとにＴＴＬ値（Time To Live）を設定する。ＴＴＬ値は、レコード（データ）の有効期限を認識可能な情報（第１情報の一例）である。ＴＴＬ値は、例えば、そのレコードがいつまで有効であるかを示す時刻情報である。ＴＴＬ値は、クライアント３００から指定してもよく、データベース管理装置１００において設定されてもよい。レコード登録部１１２は、登録したレコードのレコードＩＤとＴＴＬ値とを無効レコード削除部１２０に出力する。

期限徒過判定部１１４は、記憶装置２００に書き込まれたレコードに対して、ＴＴＬ値を参照し、基準時刻（例えば、現在時刻）がＴＴＬ値で設定された時刻を徒過しているか否かを判定する。期限徒過判定部１１４は、例えば、現在時刻がＴＴＬ値を徒過していた場合、そのレコードが無効レコードであると判定し、その旨を無効レコードとなったレコードの識別情報であるレコードＩＤとともに無効レコード削除部１２０に出力する。

なお、このような仕組みに代えて、レコードの書き込み時刻および有効期間の情報が保持され、期限徒過判定部１１４が、書き込み時刻からの期間が有効期間を超えたときに、そのレコードを無効レコードと判定する仕組みを採用してもよい。また、期限徒過判定部１１４は、レコードの書き込み時点で、有効期間に対応する値をカウントダウンさせるタイマを備え、カウントダウンにより有効期間に対応する値が０になった場合に、そのレコードが無効レコードであると判定してもよい。

期限徒過判定部１１４は、無効レコードとなったレコードのレコードＩＤと、ＴＴＬ値が示す時刻と現在時刻との差分値により求められる徒過後の経過時間とを無効レコード削除部１２０に出力してもよい。上述した徒過後の経過時間は、記憶装置２００により記憶されたレコードの保持コストを評価するための情報（第２情報の一例）である。ここで、保持コストとは、そのレコード（データ）を記憶装置２００に保持させておくことで生じるコスト（処理負荷、処理時間）に関する情報である。以下、保持コストを、単に「コスト」と称する。

無効レコード削除部１２０は、レコード管理部１１０により有効期限が設定されたレコードに関する情報（例えば、レコードＩＤ、ＴＴＬ値等）を取得し、これらのレコードをリスト化して管理する。また、無効レコード削除部１２０は、管理された各レコードのうち、無効レコードをコストに基づく所定の順序で記憶装置２００から削除する。

例えば、無効レコード削除部１２０のコスト計算部１２２は、少なくとも、上述したＴＴＬ値、その他の第２情報に基づいて、レコードごとにコスト値を計算し、計算結果からコストを評価する。第２情報は、例えば、徒過後の経過時間、無効レコードに対するアクセス回数（無効アクセス回数）、レコードのサイズ、レコードが所属する領域（ブロック）の空き領域（残りレコード数）、レコードの登録先の記憶装置（レコードが所属する記憶装置）２００の種類、および、レコードが所属する記憶装置の劣化度合等のうち、少なくとも１つを含む。

例えば、コスト計算部１２２は、例えば、徒過後の経過時間が長くなるほどコスト値が高くなるようにコストを計算する。無効レコードに対するアクセス回数が多いほどコスト値が高くなるようにコストを計算する。また、コスト計算部１２２は、レコードのサイズが大きいほどコスト値が高くなるようにコストを計算してもよい。また、コスト計算部１２２は、レコードが登録された所定領域（ブロック）における空き領域が多いほど、コスト値が高くなるようにコストを計算してもよい。また、コスト計算部１２２は、レコードの登録先の記憶装置の種類に基づいて決定される係数が高い記憶装置２００に登録されるレコードほど、コスト値が高くなるようにコストを計算してもよい。

削除実行部１２４は、コスト計算部１２２により計算されたコスト値に基づいて優先度（例えば、優先順位）を設定し、設定された優先度に基づいて無効レコードを削除する。例えば、削除実行部１２４は、優先度の高い順に無効レコードを削除する。

通信部１３０は、他のデータベース管理装置１００、記憶装置２００、およびクライアント３００のうち、少なくとも１つと通信ネットワークを介してデータの送受信を行う通信インターフェースである。通信ネットワークは、ＷＡＮ（Wide Area Network）やＬＡＮ（Local Area Network）、インターネット等を含む。

記憶部１４０は、データベース管理装置１００における各種設定情報や、データベース管理に関する各種処理の実行経過または実行結果等により得られる情報、ログ情報、エラー情報等を記憶する。

記憶装置２００は、例えば複数のデータベース管理装置１００により共有されるストレージ装置である。記憶装置２００は、例えば、ハードディスク（ディスク装置）、フラッシュメモリ、ＲＡＭ、および制御回路等を備える。記憶装置２００は、キャッシュ領域２１０と、データ記憶領域２２０とを備える。キャッシュ領域２１０は、データ記憶領域２２０に対するキャッシュ領域として使用される。キャッシュ領域２１０は、例えば、ＲＡＭ上に設定される。データ記憶領域２２０は、レコードを不揮発に保持する。

クライアント３００は、データベース管理装置１００にデータの読み書き、削除等を行わせるためのコマンドを出力する。クライアント３００は、例えばＰＣ（Personal Computer）やタブレット端末、携帯電話等の情報処理装置である。クライアント３００は、データベース管理装置１００のユーザによって使用される情報処理装置であってもよく、さらに別の装置から受信したコマンド等に基づいて、データベース管理装置１００に各種コマンドを送信する装置であってもよい。また、クライアント３００は、内部において情報処理した結果に基づいて、各種コマンドを生成してデータベース管理装置１００に送信する装置であってもよい。

例えば、クライアント３００は、データベース管理装置１００に対して、所定の処理を実行させるために、データの書き込みを指示するライトコマンド、データの読み出しを指示するリードコマンド、データの削除を指示する削除コマンド等を送信する。以下、リードコマンドによって、あるレコードの読み出しが要求されることを、「アクセス要求」と称する。また、クライアント３００は、データベース管理装置１００から指示した内容に対する処理結果を取得する。

図１に示すデータベース管理システム１において、記憶装置２００およびクライアント３００の一方または双方は、データベース管理装置１００と統合されてもよい。また、図１の例では、データベース管理装置１００を使用する装置として１つのクライアント３００が示されているが、複数のクライアント３００が１つのデータベース管理装置１００を使用してもよい。

次に、データベース管理装置１００におけるデータベース管理の各種動作について、図を用いて説明する。図２は、データベース管理装置１００における登録動作を説明するための図である。図２の例では、クライアント３００からのライトコマンド（上書きでないもの）に基づき、対象のデータが含まれるレコードを生成し、生成したレコードを記憶装置２００に登録する例を示している。また、図３は、データベース管理装置１００におけるデータ登録処理の一例を示すフローチャートである。

図３の例において、データベース管理装置１００は、クライアント３００からレコードの登録要求を受け付ける（ステップＳ１００、図２に示す（１））。次に、レコード登録部１１２は、対象レコードを記憶装置２００のキャッシュ領域２１０に登録する（ステップＳ１０２、図２に示す（２））。なお、ステップＳ１０２の処理では、レコードに対し、必要に応じてＴＴＬ値を設定する。設定されるＴＴＬ値は、レコードの所定のデータ項目に記憶され、データに関連付けられて登録される。

次に、レコード登録部１１２は、登録が成功したか否かを判定する（ステップＳ１０４）。登録に成功した場合、レコード登録部１１２は、登録したレコードにＴＴＬが設定されているか否かを判定する（ステップＳ１０６）。ＴＴＬ値が設定されている場合、レコード登録部１１２は、登録したレコードに割り当てたレコードＩＤと、ＴＴＬ値とを無効レコード削除部１２０に通知する（ステップＳ１０８、図２に示す（３））。通知を受けた無効レコード削除部１２０は、記憶部１４０に記憶された有効期限付きレコードリスト（有効期限付きリスト）１４０Ａに、通知されたレコードＩＤを持つエントリ（登録データ）を作成する（ステップＳ１１０）。

なお、ステップＳ１０８の処理では、登録したレコードに割り当てるレコードＩＤを、ハッシュを用いて生成してもよい。ハッシュ値を用いることで、例えば文字列検索のように個々のデータが大きい場合、データ全体を比較しながら検索するよりも比較にかかるコストを節約でき、高速に検索することができる。

ステップＳ１０６の処理において、ＴＴＬ値が設定されていない場合、またはステップＳ１０８の処理後、レコード管理部１１０は、レコードの登録が成功したことを示す情報をクライアント３００に出力する（ステップＳ１１２、図２に示す（４））。また、上述したステップＳ１０４の処理において、登録が成功しなかった場合、レコード管理部１１０は、登録が失敗した原因に対応するエラー情報をクライアント３００に出力する（ステップＳ１１４、図２に示す（４））。登録が失敗した原因としては、例えば記憶装置２００の空き容量不足や排他制御中による書き込みエラー等があるが、これに限定されるものではない。

ここで、上述した有効期限付きレコードリスト１４０Ａについて図を用いて説明する。図４は、有効期限付きレコードリスト１４０Ａの一例を示す図である。図４に示す有効期限付きレコードリスト１４０Ａの項目（エントリ構成）としては、例えば「レコードＩＤ」、「ＴＴＬ値」等がある。レコードＩＤは、レコードを識別するための識別情報であり、ＩＤの内容は、図４の例に示すように文字や数値を用いることができるが、これに限定されるものではない。ＴＴＬ値は、例えば時刻型の値である。ＴＴＬ値は、例えば「2016/6/14 10：00」等のように、登録した時点より先の時刻が設定されるが、これに限定されるものではなく、上述した有効期間（例えば、２４時間）等の情報であってもよい。例えば、期限徒過判定部１１４は、現在時刻がＴＴＬ値の時刻を超えた場合に、対象のレコードを無効レコードと判定する。

なお、レコード管理部１１０は、クライアント３００からアクセス要求されたレコードが記憶装置２００に存在するとともに、そのレコードが有効期限を徒過していない場合、そのレコードをクライアント３００に出力する。ここで、「記憶装置２００に存在する」とは、キャッシュ領域２１０とデータ記憶領域２２０との双方に存在する場合と、キャッシュ領域２１０のみ、データ記憶領域２２０のみに存在する場合とがある。

また、アクセス要求されたレコードが記憶装置２００に存在しない場合には、すでに削除されたレコードであるため、レコード管理部１１０は、その旨をクライアント３００に通知する。

次に、クライアント３００からのレコードアクセス要求に基づくレコードアクセス（読み出し）時の動作について、図を用いて説明する。図５は、データベース管理装置１００におけるレコードアクセス時の動作を説明するための図である。また、図６は、データベース管理装置１００におけるレコードアクセス処理の一例を示すフローチャートである。

図６の例において、データベース管理装置１００は、クライアント３００からのレコードアクセスコマンド（リードコマンド）を受け付ける（ステップＳ２００、図５に示す（１））。次に、レコード管理部１１０は、記憶装置２００から受け付けたコマンドに対するレコードを取得する処理を行う（ステップＳ２０２、図５に示す（２））。

次に、レコード管理部１１０は、記憶装置２００からレコードを取得できたか否かを判定する（ステップＳ２０４、図５に示す（３））。レコードを取得できた場合、レコード管理部１１０の期限徒過判定部１１４は、レコードに対応するＴＴＬ値を取得し（ステップＳ２０６）、現在時刻がＴＴＬ値を超えているか否かを判定する（ステップＳ２０８）。

現在時刻がＴＴＬ値を超えている場合、そのレコードは、有効期限を徒過しているため、期限徒過判定部１１４は、レコードＩＤを含む情報を、無効レコード削除部１２０に通知する（ステップＳ２１０、図５に（４））。無効レコード削除部１２０は、無効レコードエントリ処理を行う（ステップＳ２１２、図５に示す（５）、（６））。なお、無効レコードエントリ処理については、後述する。

次に、レコード管理部１１０は、対象のレコードが存在しない旨のエラー情報をクライアント３００に出力する（ステップＳ２１６、図５に示す（７））。また、ステップＳ２０８の処理において、現在時刻がＴＴＬ値以下である場合、そのレコードは有効期限内であるため、取得したレコードを、クライアント３００に出力する（ステップＳ２１８、図５に示す（７））。また、ステップＳ２０４の処理において、レコードの取得に成功しなかった場合、失敗した原因に基づくエラー情報をクライアント３００に出力する（ステップＳ２２０、図５に示す（７））。

図７は、無効レコードエントリ処理の一例を示すフローチャートである。図７の例において、無効レコード削除部１２０は、レコード管理部１１０からアクセスのあった無効レコードのレコードＩＤを取得し（ステップＳ３００）、取得したレコードＩＤが、記憶部１４０に記憶された優先削除レコードリスト（優先削除リスト）１４０Ｂに存在するか否かを判定する（ステップＳ３０２）。レコードＩＤが優先削除レコードリスト１４０Ｂに存在する場合、コスト計算部１２２は、レコードＩＤの該当エントリのコストを計算する（ステップＳ３０４）。このタイミングでコスト値を計算することで、無効レコードへのアクセス回数に対応した最新のコスト値を取得することができる。

次に、無効レコード削除部１２０は、優先削除レコードリスト１４０Ｂの各レコードをコスト順（例えば、降順）に並び替える（ステップＳ３０６）。これにより、優先削除レコードリスト１４０Ｂの各レコードは、例えば優先度順（降順）に整列される。

また、取得したレコードＩＤを持つエントリが優先削除レコードリスト１４０Ｂに存在しない場合、有効期限付きレコードリスト１４０Ａから、取得したレコードＩＤを持つエントリを削除し（ステップＳ３０８、図５に示す（５））、優先削除レコードリスト１４０Ｂに該当れレコードＩＤを持つエントリを作成する（ステップＳ３１０、図５に示す（６））。ステップＳ３０８およびステップＳ３１０の処理により、無効レコードのレコードＩＤ等の情報を有効期限付きレコードリスト１４０Ａから優先削除レコードリスト１４０Ｂに移動させることができる。

ここで、上述した優先削除レコードリスト１４０Ｂの一例について、図を用いて説明する。図８は、優先削除レコードリスト１４０Ｂの一例を示す図である。優先削除レコードリスト１４０Ｂの項目（エントリ構成）としては、例えば「レコードＩＤ」、「無効アクセス回数」、「ＴＴＬ値」、「コスト値」等がある。レコードＩＤおよびＴＴＬ値は、いずれも有効期限付きレコードリスト１４０Ａから取得される情報である。また、無効アクセス回数は、有効期限を徒過した後（現在時刻がＴＴＬ値を超えた後）に、クライアント３００等から、そのレコードにアクセスのあった回数である。

例えば、無効レコード削除部１２０は、期限徒過判定部１１４から無効アクセスのあったレコードＩＤの通知があった場合に、そのレコードＩＤに基づいて優先削除レコードリスト１４０Ｂを参照し、抽出されたレコードの無効アクセス回数の値に１を増加する。また、無効レコード削除部１２０は、そのレコードＩＤが優先削除レコードリスト１４０Ｂに存在しなかった場合、有効期限付きレコードリスト１４０Ａから該当レコードを抽出し、優先削除レコードリスト１４０Ｂにエントリする。この場合、無効アクセス回数には、１が設定される。コスト計算部１２２は、このように更新された優先削除レコードリスト１４０Ｂを用いて、優先削除レコードリスト１４０Ｂにエントリされたレコードごとに、所定の計算手法でコスト値を計算し、計算結果を優先削除レコードリスト１４０Ｂの「コスト値」に格納する。これにより、最新の情報でコスト値を計算することができる。なお、コスト計算部１２２におけるコスト値の計算手法の具体例については、後述する。

なお、上述した有効期限付きレコードリスト１４０Ａと、優先削除レコードリスト１４０Ｂとは、別リストとして示しているが、一体に構成されていてもよい。また、上述した有効期限付きレコードリスト１４０Ａおよび優先削除レコードリスト１４０Ｂは、上述したデータ構造を規定するものではない。例えば、上述した各リストの実現のために、例えば配列、キュー、ヒープ、二分木等を用いたデータ構造でもよい。

次に、優先削除実行時の動作例について、図を用いて説明する。図９は、データベース管理装置１００における優先削除動作の一例を説明するための図である。また、図１０は、データベース管理装置１００における優先削除処理の一例を示すフローチャートである。なお、優先削除処理は、例えば、所定の周期、無効レコードへのアクセス回数が所定数以上となった場合、データベース管理装置１００のユーザ（管理者）が指示したタイミングで実行される。

図１０の例において、無効レコード削除部１２０は、優先削除レコードリスト１４０Ｂにエントリがあるか否かを判定する（ステップＳ４００）。優先削除レコードリスト１４０Ｂにエントリがある場合、削除実行部１２４は、優先削除レコードリスト１４０Ｂの先頭のレコードＩＤを取得する（ステップＳ４０２、図９に示す（１））。ここで、先頭のレコードＩＤとは、上述したステップＳ３０６の処理で、優先削除レコードリスト１４０Ｂの各レコードＩＤをコスト値に基づき降順に並び替えている場合、各レコードＩＤのうち、最も優先度の高いレコードＩＤである。次に、削除実行部１２４は、レコードＩＤに対応するレコードを記憶装置２００のキャッシュ領域２１０から抽出し、抽出されたレコードを削除し（ステップＳ４０４、図９に示す（２））、優先削除レコードリスト１４０Ｂのエントリを削除する（ステップＳ４０６、図９に示す（３））。なお、レコードを削除する場合に、削除実行部１２４は、キャッシュ領域２１０に存在するレコードＩＤに対応するレコードを削除してもよく、データ記憶領域２２０に記憶されたレコードＩＤに対応するレコードを削除してもよい。

次に、削除実行部１２４は、最大削除数に達したか否かを判定する（ステップＳ４０８）。最大削除数とは、１回のレコード削除処理において、削除が可能な無効レコードの最大数である。最大削除数を設定しておくことで、無効レコードの削除処理に要する時間または負荷を管理することができる。最大削除数に達していない場合、削除実行部１２４は、ステップＳ４００の処理に戻る。また、最大削除数に達した場合、または、優先削除レコードリスト１４０Ｂにエントリがない場合、本フローチャートを終了する。

次に、データベース管理装置１００における定周期削除動作について、図を用いて説明する。図１１は、データベース管理装置１００における定周期削除動作の一例を示す図である。また、図１２は、データベース管理装置１００における定周期削除処理の一例を示すフローチャートである。定周期削除処理は、例えば上述した優先削除処理において削除しきれなかった無効レコードを削除するための処理であり、例えば優先削除処理が実行される周期やタイミングよりも長い周期で定期的に実行される。

図１２の例において、無効レコード削除部１２０は、優先削除レコードリスト１４０Ｂにエントリがあるか否かを判定する（ステップＳ５００）。優先削除レコードリスト１４０Ｂにエントリがある場合、削除実行部１２４は、優先削除レコードリスト１４０Ｂの先頭のエントリを取得する（ステップＳ５０２）。

また、優先削除レコードリスト１４０Ｂにエントリがない場合、無効レコード削除部１２０は、有効期限付きレコードリスト１４０Ａにエントリがあるか否かを判定する（ステップＳ５０４）。有効期限付きレコードリスト１４０Ａにエントリがある場合、削除実行部１２４は、有効期限付きレコードリスト１４０Ａの中で、ＴＴＬ値が最小のエントリを取得する（ステップＳ５０６）。

次に、削除実行部１２４は、エントリ内のレコードのＴＴＬ値と、現在時刻とを比較し、エントリ内のレコードがすでに無効か否かを判定する（ステップＳ５０８）。なお、ステップＳ５０８の処理では、例えば現在時刻がＴＴＬ値を超えている場合に、そのレコードが無効であると判定することができる。エントリ内のレコードがすでに無効である場合、またステップＳ５０２の処理後、取得したレコードＩＤに対応するレコードを削除し（ステップＳ５１０）、優先削除レコードリスト１４０Ｂのエントリを削除する（ステップＳ５１２）。

次に、無効レコード削除部１２０は、最大削除数に達したか否かを判定する（ステップＳ５１４）。最大削除数に達している場合、無効レコード削除部１２０は、有効期限付きレコードリスト１４０Ａにある削除されていないレコードＩＤ等を優先削除レコードリスト１４０Ｂに移動（エントリ）し（ステップＳ５１６）、本フローチャートの処理を終了する。なお、削除されていないレコードＩＤ等がすでに優先削除レコードリスト１４０Ｂにある場合には、ステップＳ５１６の処理を行わなくてもよい。

また、エントリ内のレコードが無効でない場合、または、最大削除数に達していない場合、無効レコード削除部１２０は、全てのエントリに対して削除判定を行ったか否かを判定する（ステップＳ５１８）。全てのエントリに対して削除判定を行った場合、本フローチャートの処理を終了する。また、全てのエントリに対して削除判定を行っていない場合、ステップＳ５００の処理に戻り、他のエントリに対する処理を行う。

次に、コスト計算部１２２におけるコスト計算の具体例について説明する。
（第１の実施例）
コスト計算の第１の実施例では、評価の対象となる無効レコードの無効アクセス回数と、ＴＴＬ値からの経過時間とに基づいて、コスト値を計算する。第１の実施例では、上述した図８に示す優先削除レコードリスト１４０Ｂを用いる。

例えば、第１の実施例として、１００件の有効レコード、１００００件の無効レコードがある状況からスタートし、データベース管理装置１００は、毎秒１００件の無効レコードを削除する処理を想定する。また、クライアント３００は、１０秒後、最近の１０００件のレコードを２回スキャンする。なお、２回のスキャンの間は１０秒間の間隔を空けるものとする。

また、計算の便宜上、１０秒間で有効レコードの有効期限は切れないものとする。また、１件のレコードアクセスは２００μｓとし、１件のレコード存在確認には１００μｓ、１件のレコード削除には１ｍｓの時間がかかるものとする。

上述の条件において、コスト計算部１２２は、例えば「コスト値＝レコードの無効アクセス回数×１００−（現在時刻−レコードのＴＴＬ値）」としてコスト値を計算する。例えば、無効アクセスが１回あった場合、１０秒前に有効期限切れになったレコードのコスト値は、１×１００−１０＝９０となる。なお、コスト値には、経過時間について負の相関、無効アクセス回数について正の相関を持たせてもよい。また、第１の実施例では、コスト値が大きいほど、削除する優先度が高くなるが、これに限定されるものではなく、例えばコスト値が小さいほど、優先度が高くなるようなコストの評価を行ってもよい。

また、無効アクセスが発生した最近有効期限切れになったレコードは、またアクセスされる可能性が高いため、できる限り即座に削除することが好ましい。したがって、第１の実施例では、同じ無効アクセス回数のレコードがあった場合に、経過時間が少ないものほど優先度が高くなる計算式となっている。また、第１の実施例では、無効アクセス回数がコスト値を大きく引き上げるように計算式を定めている。なお、無効アクセスが０回の場合、対象レコードは、有効期限付きレコードリスト１４０Ａから優先削除レコードリスト１４０Ｂに移動されないため、コスト値が設定されない。

上述したように、第１の実施例によれば、削除実行部１２４は、優先削除レコードリスト１４０Ｂにある無効アクセス回数の多い無効レコードを優先して削除しておくことで無効レコードへのアクセスや削除処理等の処理負荷を抑制することができる。なお、第１の実施例のコスト計算に基づく優先削除処理において、１回に削除可能なレコードの数（最大削除数）を超え、削除されない無効レコードが残った場合でも、上述した定周期削除処理により、残りのレコードを削除することができる。

（第２の実施例）
次に、コスト計算部１２２におけるコスト計算手法の第２の実施例について説明する。第２の実施例において、コスト計算部１２２は、評価の対象となる無効レコードの容量（レコードサイズ）に基づいて、コスト計算を行う。レコードサイズは、例えば無効レコードアクセス時にレコード管理部１１０により通知される。第２の実施例によれば、レコードサイズの大きい無効レコードを先に削除することで、効率的に記憶装置２００の空き容量を増やすことができる。

第２の実施例において、コスト計算部１２２は、例えば「コスト値＝レコードの大きさ(ＫＢ単位)−(現在時刻−レコードのＴＴＬ値)／２」としてコスト値を計算する。また、上述したコスト値の計算結果から、コスト値が大きいレコードほど、削除する優先度が高くなる。この計算式によれば、例えば１０秒前に有効期限切れになった１０ＫＢの大きさのレコードのコスト値が５、１０秒前に有効期限切れになった１００ＫＢの大きさのレコードのコスト値が９５、および１００秒前に有効期限切れになった１００ＫＢの大きさのレコードのコスト値が５０と計算できる。

また、第２の実施例においてコスト値等を計算する場合には、「無効アクセス回数」は、優先削除レコードリスト１４０Ｂに格納しなくてもよい。ここで、図１３は、第２の実施例における優先削除レコードリスト１４０Ｂの一例を示す図である。図１３に示すように、第２の実施例における優先削除レコードリスト１４０Ｂの項目（エントリ構成）としては、例えば「レコードＩＤ」、「ＴＴＬ値」、「コスト値」等がある。レコードＩＤは、削除する無効レコードのＩＤである。ＴＴＬ値は、有効期限の判定のために用いられる。コスト値は、ＴＴＬ値およびレコードサイズから計算したコストである。なお、第２の実施例において、優先削除レコードリスト１４０Ｂにレコードサイズを格納してもよく、またレコードサイズが固定値である場合には省略してもよい。

上述したように、第２の実施例によれば、削除実行部１２４は、新しく有効期限切れになったものを優先して削除するとともに、その中でもレコードサイズが大きい無効レコードを優先的に削除することができる。なお、レコードサイズの小さいレコードは、優先度が低くなるため、優先削除レコードリスト１４０Ｂ内に残る可能性があるが、上述した定周期削除処理で削除される。

（第３の実施例）
次に、コスト計算部１２２におけるコスト計算手法の第３の実施例について説明する。第３の実施例では、評価の対象となるレコードの所属する所定領域（例えば、ブロック）の空き容量（例えば、残りレコード数等の使用容量でもよい）等を用いてコスト値を計算する。例えば、記憶装置２００におけるデータベースは、Ｉ／Ｏ効率を高めるために、複数のレコードをまとめてブロック単位で管理していることが多い場合がある。また、同じブロックには同じようなＴＴＬ値を有するレコードが集まりやすい場合がある。したがって、第３の実施例では、レコードが所属するブロックの情報を基準にコスト値を計算することで、例えばブロック内のレコードが全て無効レコードになった場合に、そのレコードを優先的に削除して、そのブロックを早期に空にすることができ、そのブロックを再利用することができる。

第３の実施例において、コスト計算部１２２は、例えば「コスト値＝レコードが所属するブロックにおける残りのレコード数」としてコスト値を計算する。所属するブロックの残りのレコード数は、例えば無効レコードアクセス時にレコード管理部１１０により通知される。また、レコードを削除する優先度とコスト値との関係は、「優先度＝１／コスト値」となる。つまり、コスト値が大きくなるほど、優先度は低くなる。例えば、ある有効期限切れになったレコードが所属するブロックに、他に１０レコードがある場合、コスト値＝１０となり、優先度は、０．１となる。

ここで、第３の実施例における優先削除レコードリスト１４０Ｂのエントリ構成は、上述した図１３と同じ構成を用いることができる。なお、第３の実施例の場合、「レコードＩＤ」および「ＴＴＬ値」は、上述した第２の実施例と同様であるが、「コスト値」には、所属ブロックの残りレコード数から計算したコストが格納される。

上述したように、第３の実施例によれば、残りレコード数が少ないブロックに所属する無効レコードが優先的に削除される。したがって、従来手法よりブロックが空になるのが早くなるため、ブロック単位での再利用を効率的に行うことができる。

（第４の実施例）
次に、コスト計算部１２２におけるコスト計算手法の第４の実施例について説明する。第４の実施例では、評価の対象となるレコードが所属する記憶装置２００の種類に応じてコストを設定する。例えば、データベース管理装置１００が、記憶装置２００に記憶されるレコードを複数のストレージに分割して保持している場合、より高速な記憶装置２００をなるべく空けておきたい場合がある。そのため、第４の実施例では、例えばＨＤＤとＳＳＤ（Solid State Drive）とを備える記憶装置２００において、ＳＳＤに記憶されたレコードが、ＨＤＤに記憶されたレコードよりも優先して削除されるようにする。この場合、コスト計算部１２２は、例えば「コスト値＝レコードの大きさ（ＫＢ）×ストレージ係数」としてコストを計算する。ここで、ストレージ係数とは、レコードが記憶された記憶装置（ストレージ）２００の種類に基づいて設定される値であり、例えばＨＤＤである場合にストレージ係数を１とし、ＳＳＤであるの場合にストレージ係数を１０とする。無効レコードが記憶された記憶装置２００の種類は、その無効レコードがアクセスされた時に、レコード管理部１１０により通知される。例えば、１００ＫＢのレコードがＨＤＤにある場合、コスト値＝１００×１＝１００となり、１００ＫＢのレコードがＳＳＤにある場合、コスト値＝１００×１０＝１０００となる。第４の実施例の場合、コスト値が大きいほど、優先度は高くなる。

ここで、図１４は、第４の実施例における優先削除レコードリスト１４０Ｂの一例を示す図である。図１４に示すように、第４の実施例における優先削除レコードリスト１４０Ｂの項目（エントリ構成）としては、「レコードＩＤ」および「コスト値」等がある。レコードＩＤは、削除するレコードのＩＤである。ＴＴＬ値は、有効期限の判定のために用いられる。コスト値は、レコードの大きさおよびストレージ係数から計算したコストである。第４の実施例において、優先削除レコードリスト１４０Ｂのエントリ構成は、無効レコードの所属ストレージが変わることは想定しにくい。そのため、コスト計算部１２２は、コスト計算を一度行えばよい。

上述したように、第４の実施例によれば、より高速なストレージにある無効レコードを優先的に削除することができる。これにより、高速ストレージの領域を早期に再利用することができる。

（第５の実施例）
次に、コスト計算部１２２におけるコスト計算手法の第５の実施例について説明する。第５の実施例では、例えば記憶装置２００に記憶される各レコードが複数のＳＳＤ等に分割して保持されている場合に、劣化しているＳＳＤに対する無効レコードの削除処理を減らして、なるべく上書き処理を行うようにする。無効レコードは、上述した削除処理により記憶領域から削除するだけでなく、そのレコードを他のレコードで上書きすることで削除してもよい。

第５の実施例において、コスト計算部１２２は、例えば「コスト値=レコードの所属するストレージの劣化係数（劣化度合）」としてコスト値を計算する。また、レコードを削除する優先度とコスト値との関係は、逆相関の関係となる。つまり、第５の実施例では、コスト値が大きいほど、優先度は低くなる。

なお、上述した劣化係数は、例えばS.M.A.R.T.（Self-Monitoring, Analysis and Reporting Technology）情報より取得することができる。S.M.A.R.T.情報とは、記憶装置２００の内部で管理することができるモニタリング情報等である。S.M.A.R.T.情報は、データベース管理装置１００で管理されていてもよく、記憶装置２００で管理されていてもよい。S.M.A.R.T.情報としては、例えば、使用済み予備ブロック数、不良ブロック数、および消去失敗回数等がある。これらの情報が得られた場合、コスト計算部１２２は、例えば「劣化係数＝使用済み予備ブロック数＋不良ブロック数＋消去失敗回数」として劣化係数を計算する。なお、計算手法については、これに限定されるものではない。例えば、第５の実施例において、使用済み予備ブロック数を１０とし、不良ブロック数を１００とし、消去失敗回数を０とした場合のＳＳＤに所属するレコードのコスト値は１１０となる。したがって、優先度は、−１１０となる。

ここで、図１５は、第５の実施例における優先削除レコードリスト１４０Ｂの一例を示す図である。図１５に示すように、第５の実施例における優先削除レコードリスト１４０Ｂの項目（エントリ構成）としては、「レコードＩＤ」、「所属ストレージ」、「最終コスト更新時間」、「コスト値」等がある。レコードＩＤは、削除する無効レコードのＩＤである。所属ストレージは、所属する記憶装置（ストレージ）２００のＩＤである。最終コスト更新時間は、最後にコスト値を更新した時刻である。この時刻は、S.M.A.R.T.情報の新しさを示すものである。また、コスト値は、ストレージの劣化係数から計算したコストである。

また、第５の実施例において、優先削除レコードリスト１４０Ｂのエントリ構成において、コスト値はS.M.A.R.T.情報を取得するごとに更新される可能性がある。そのため、コスト計算部１２２は、S.M.A.R.T.情報を取得した後に、無効レコードのアクセスがあった場合に、コスト値を再計算する。

上述したように、第５の実施例によれば、劣化したＳＳＤの有効期限切れレコードの削除を抑制することができる。なお、コスト計算部１２２におけるコスト計算は、上述した第１〜第５の各実施例の一部または全部を組み合わせてもよい。

次に、記憶装置２００内の無効レコードの削除に関する処理結果の一例について、図を用いて説明する。図１６は、無効レコード削除に関する処理結果の一例を示す図である。図１６の例では、横軸に無効レコード削除のための記憶装置２００のスキャン回数を示し、縦軸に上記スキャンの所要時間を示す。また、図１６の例では、従来手法と本実施形態とにおける処理結果を比較している。従来手法としては、ガベージコレクションを用いてレコードを削除する手法（ガベージコレクション方式）と、インライン削除においてレコードを削除する手法（インライン削除方式）を用いる。ガベージコレクション方式は、定期的（例えば、１日に１回）の周期で記憶装置２００内の全レコードをスキャンし、ＴＴＬ値が現在時刻を超えているレコードを削除する。また、インライン削除方式は、レコードアクセス時にそのレコードを削除する。

また、図１６の例では、便宜的に、１件のレコードアクセスを２００μｓとし、１件のレコード存在確認時間を１００μｓとし、１件のレコード削除時間１ｍｓとする。また、クライアント３００から送信されるレコードを記憶装置２００内のテーブルで管理するものとする。また、テーブルには、毎秒１００件のレコードを、ＴＴＬ値を１日として登録するものとする。また、テーブルには、常に８６４万件の有効レコードがある状態とする。

図１６に示す例では、（Ａ）がガベージコレクション方式による処理結果を示し、（Ｂ）がインライン削除方式による処理結果を示し、（Ｃ）が本実施形態における処理結果を示している。図１６に示すように、本実施形態は、従来手法と比較して、スキャンの所要時間を短縮することができ、無効レコードの削除処理における処理負荷を抑制することができる。

以上説明した少なくとも一つの実施形態によれば、複数のデータベース管理装置１００と、複数のデータベース管理装置１００により共有される記憶装置２００とを備え、複数のデータベース管理装置１００のそれぞれは、クライアントから登録要求のあったデータを記憶装置２００に書き込むデータ管理部（レコード管理部１１０）と、データ管理部により、記憶装置２００に書き込まれたデータに関連付けられる情報に基づいて、記憶装置２００に記憶されたデータのうち、有効期限を徒過したデータを削除する削除部（無効レコード削除部１２０）と、を持つことにより、複数の分散化されたデータベース管理装置において、無効レコードに関連する処理負荷を抑制することができる。

具体的には、少なくとも一つの実施形態によれば、例えば多数のクライアント３００がデータベース管理装置１００を用いて記憶装置２００へデータの書き込みを行い、そのデータの分析を行うためのアクセス（読み出し）を行う場合であっても、無効レコードへのアクセスを低く抑えることができるため、無効レコードによるスループットやレイテンシの低下を抑制することができる。また、無効レコードを優先的に削除するため、記憶装置２００内の全てのデータをスキャンする時間を減らすことができ、処理時間の短縮および処理の効率化を図ることができる。

なお、上述したデータベース管理システム１は、複数の分散化されたデータベース管理装置１００を備えているが、単体のデータベース管理装置１００で構成されていたとしても、上述した各種処理と同様の処理を行うことができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１…データベース管理システム、１００…データベース管理装置、１１０…レコード管理部（データ管理部）、１１２…レコード登録部、１１４…期限徒過判定部、１２０…無効レコード削除部（削除部）、１２２…コスト計算部（評価部）、１２４…削除実行部、１３０…通信部、１４０…記憶部、２００…記憶装置、３００…クライアント

例えば、コスト計算部１２２は、例えば、徒過後の経過時間が長くなるほどコスト値が高くなるようにコストを計算する。無効レコードに対するアクセス回数が多いほどコスト値が高くなるようにコストを計算する。また、コスト計算部１２２は、レコードのサイズが大きいほどコスト値が高くなるようにコストを計算してもよい。また、コスト計算部１２２は、レコードが登録された所定領域（ブロック）における空き領域が多いほど、コスト値が低くなるようにコストを計算してもよい。また、コスト計算部１２２は、レコードの登録先の記憶装置の種類に基づいて決定される係数が高い記憶装置２００に登録されるレコードほど、コスト値が高くなるようにコストを計算してもよい。

Claims (11)

1. 複数のデータベース管理装置と、
   前記複数のデータベース管理装置により共有される記憶装置と、を備え、
   前記複数のデータベース管理装置のそれぞれは、
   クライアントから登録要求のあったデータを前記記憶装置に書き込むデータ管理部と、
   前記データ管理部により前記記憶装置に書き込まれたデータの有効期限を認識可能な第１情報に基づいて、前記記憶装置に記憶されたデータのうち、有効期限を徒過したデータを削除する削除部と、
   を備えるデータベース管理装置。
2. 前記削除部は、
   前記記憶装置により記憶されたデータの保持コストを評価するための第２情報に基づいて、前記データごとに保持コストを評価する評価部と、
   前記評価部により前記保持コストが高いと評価されたデータを優先して、前記記憶装置から削除する削除実行部とを備える、
   請求項１に記載のデータベース管理装置。
3. 前記第２情報は、前記データの有効期限を徒過した後のアクセス回数を含み、
   前記評価部は、前記アクセス回数が多いほど、前記保持コストを高くする、
   請求項２に記載のデータベース管理装置。
4. 前記第２情報は、前記データのサイズを含み、
   前記評価部は、前記データのサイズが大きいほど、前記保持コストを高くする、
   請求項２または３に記載のデータベース管理装置。
5. 前記第２情報は、前記保持コストの評価の対象となるデータが格納された所定領域における空き領域を含み、
   前記評価部は、前記空き領域が多いほど、前記保持コストを低くする、
   請求項２から４のうち、いずれか１項に記載のデータベース管理装置。
6. 前記第２情報は、前記データの登録先の記憶装置の種類に基づいて決定される係数を含み、
   前記評価部は、前記係数が高い記憶装置に登録されるデータほど、前記保持コストを高くする、
   前記請求項２から５のうち、いずれか１項に記載のデータベース管理装置。
7. 前記第２情報は、前記データの登録先の記憶装置ごとに決定される劣化度合を含み、
   前記評価部は、前記劣化度合が高い記憶装置に登録されるデータほど、前記保持コストを低くする、
   前記請求項２から６のうち、いずれか１項に記載のデータベース管理装置。
8. 前記削除部は、前記評価部により得られる保持コストに対応した優先度順に、削除するデータが整列された優先削除リストを生成し、生成した優先削除リストに基づいて、前記データを削除する、
   請求項２から７のうち、いずれか１項に記載のデータベース管理装置。
9. 前記データ管理部は、前記記憶装置にデータを記憶する場合に、有効期限が設定されたデータを有効期限付きリストに登録し、
   前記評価部は、前記有効期限付きリストに登録されたデータごとに前記保持コストを評価し、評価したデータを評価結果とともに、前記優先削除リストに移動する、
   請求項８に記載のデータベース管理装置。
10. 複数のデータベース管理装置と、前記複数のデータベース管理装置により共有される記憶装置と、を備えたデータベース管理システムにおける前記複数のデータベース管理装置のそれぞれのコンピュータが、
    クライアントから登録要求のあったデータを前記記憶装置に書き込み、
    前記記憶装置に書き込まれたデータの有効期限を認識可能な第１情報に基づいて、前記記憶装置に記憶されたデータのうち、有効期限を徒過したデータを削除する、
    データベース管理方法。
11. 複数のデータベース管理装置と、前記複数のデータベース管理装置により共有される記憶装置と、を備えたデータベース管理システムにおける前記複数のデータベース管理装置のそれぞれのコンピュータに、
    クライアントから登録要求のあったデータを前記記憶装置に書き込ませ、
    前記記憶装置に書き込まれたデータの有効期限を認識可能な第１情報に基づいて、前記記憶装置に記憶されたデータのうち、有効期限を徒過したデータを削除させる、
    データベース管理プログラム。

Images