JP2017167654A - データ管理装置及びデータベースの管理方法 - Google Patents

Abstract

【課題】インデックスの追加処理とインデックスメンテナンスによる負荷の増大を抑制する。【解決手段】プロセッサとメモリとを有する計算機でデータベースの表データを管理するデータベースの管理方法であって、前記計算機が、リングバッファで構成された前記表データにデータを追加し、前記データを追加した前記リングバッファの位置を保持する最終書き込み位置を更新し、前記リングバッファを循環した回数を保持する第１の循環回数を更新し、前記データを検索するインデックス要素を格納したインデックスで、前記追加したデータに対応する前記インデックス要素を特定し、前記特定したインデックス要素に対応して、前記データを追加した前記表データの位置を示す位置情報と、前記位置情報に対応するデータを追加したときの前記リングバッファの循環回数を保持する第２の循環回数とを含むデータブロックを追加する。【選択図】図２

Description

本発明は、記憶装置にデータを保持するリレーショナルデータベースのインデックス技術に関するものである。

産業機器などにセンサーを取り付けて得られる稼働データや、情報システムの運用データは、ログデータとして蓄積され、障害発生時の原因調査や、情報セキュリティの監視などに活用されている。このようなデータを管理する場合、稼働ログまたは運用ログデータの容量が肥大化しないよう配慮し、有効なデータだけを格納して、不要となったデータは順次破棄する必要がある。特に、二次記憶装置の容量に制限のある傾向が高い組み込み機器では、このような設計が必須となっている。

このような一定件数のデータだけを管理するデータ管理システムにおいては、リングバッファ、または、循環参照と呼ばれるデータ構造が使われる。本技術に関連する公知技術文献として、特許文献１が知られている。

また、データ管理システムとして広く普及しているリレーショナルデータベースシステムでは、任意の値や文字列など、ユーザが定めた条件でデータを検索する機能を有し、その検索を高速化する技術としてインデックスが存在する。インデックス技術の代表的な例としてＢ−Ｔｒｅｅインデックスが知られている。

図１３は、Ｂ−Ｔｒｅｅインデックスにリングバッファを採用したデータ構造の一例である。図示の例は、表データ１４００のＶＡＬＵＥ１４０３列の情報に対してＢ−Ｔｒｅｅインデックス１５００が構成されている状態を示す。表データ１４００は、各レコードに対して二次記憶装置上の物理的な格納位置を示す格納位置ＩＤ１４０１と、格納された日時を格納するＴＩＭＥ１４０２と、所定の値を格納するＶＡＬＵＥ１４０３と、データ本体を格納するＤＡＴＡ１４０４からひとつのレコードが構成される。

インデックス１５００は、ルートブロック１５０１、リーフブロック１５０２、レコードＩＤブロック１５０３のデータで構成される。ルートブロック１５０１には、検索条件として指定された値に対応するリーフブロック１５０２の位置を算出するためのデータが記録される。リーフブロック１５０２には、検索対象の値に対するレコードＩＤブロック１５０３の格納位置を算出するためのデータが記録され、レコードＩＤブロック１５０３には、対象の値を格納している表データ１４００のレコードの格納位置ＩＤ１４０１が記録される。

たとえば、検索条件に数値「２」が指定されている場合、ルートブロック１５０１内の情報から数値「２」の値を示すリーフブロック１５１０の格納位置が算出され、さらに、レコードＩＤブロック１５１１の格納位置が算出される。レコードＩＤブロック１５１１に記録された格納位置ＩＤ１４０１をもとに表データ１４００の該当のレコードを順次取り出すことによって、インデックスを利用した検索が実現される。

リレーショナルデータベースに対して、リングバッファと同様の概念を取り入れることで、データ管理の最適化を実現した技術文献として、特許文献２が知られている。

特開２０１３-２０６１４７号公報 特開平０８-２５５０１７号公報

図１２は、リングバッファを取り入れたデータベースのデータ更新例として、表データ１４００の最大格納数を５としたリングバッファにおけるデータ追加の例を示したものである。なお、表データ１４００とインデックス１５００は図１３と同様の構成である。

始めに、データの登録処理として、格納時間が最も長い時間となっているデータ１４１０が、新規データ１４１１によって置き換えられる。新規データ１４１１の書き換えに伴い、インデックス１５００の処理として、更新前のインデックス情報が削除され、追加された新規データ１４１１のインデックス情報が追加される。

図１２の例では、始めに、格納位置ＩＤが「２」であるデータ１４１０を指すインデックスのレコードＩＤブロック１５１１内の構成要素「２」が削除され、データ１４１０が新規データ１４１１で上書きされる。

次に、新規データ１４１１に対するインデックス１５００のレコードＩＤブロック１５１２に構成要素「２」が追加される。また、レコードＩＤブロック１５１２が不要になった場合、リーフブロック１５０２の構成要素の削除が行われる場合がある。

すなわち、新しいデータを追加し、リングバッファによって最古のデータが上書きされるたびに、登録するデータのためのレコードＩＤブロック１５１２の更新と、古いデータのためのレコードＩＤブロック１５１１の更新の二つの処理が発生するということになる。これら二つのレコードＩＤブロック１５１１と１５１２は、二次記憶装置上の離れた位置に格納されているため、二次記憶装置上の二箇所への更新が必要となる。

さらに、データの追加と削除を繰り返していくと、二次記録装置の断片化などが発生することが懸念される。これを防ぐため、インデックス１５００のメンテナンスと呼ばれる高負荷のデータの詰め替え処理が定期的に行われる。メンテナンスのタイミングは、利用者が定期的に実行するものや、一定の間隔で新規データ登録時にデータ管理システムが実施する場合がある。

組み込み機器や小規模なデータ管理システムでは、システム全体の運用計画に合わせたタイミングでメンテナンスを実施することが難しいため、後者の方針を採用しているシステムがある。そのため、意図しないタイミングでインデックスのメンテナンス処理が発生してしまう場合があり、データ管理システムの導入の妨げとなっている。上記特許文献２においても、データ管理の最適化方法に関しての記述は存在するが、インデックスのメンテナンスに関する性能を改善するための仕組みは存在しない。

本発明の目的は、インデックス処理に伴うレコードＩＤブロックの更新によるＩ／Ｏ回数とインデックスメンテナンスによる負荷の増大という、ボトルネックを解消することが可能なインデックスを有するデータ管理システムを提供することにある。

本発明は、プロセッサとメモリとを有するデータ管理装置であって、データを格納する表データと、前記データを検索するインデックス要素を格納するインデックスと、前記表データとインデックスを管理するデータベース管理部と、を有し、前記表データは、前記データを格納するリングバッファと、前記データを書き込んだ前記リングバッファの位置を保持する最終書き込み位置と、前記リングバッファを循環した回数を保持する第１の循環回数と、を有し、前記インデックスは、検索対象の値に対応して設定された前記インデックス要素と、前記インデックス要素に対応して、前記表データの位置を示す位置情報と、前記位置情報に対応するデータを書き込んだときの前記リングバッファの循環回数を保持する第２の循環回数とを含むデータブロックと、を有し、前記データベース管理部は、前記表データへデータを追加する際には、前記最終書き込み位置に前記データを書き込んでから、前記最終書き込み位置と前記第１の循環回数を更新する表データ登録部と、前記書き込んだデータに対応する前記インデックス要素で、当該インデックス要素に対応する前記データブロックを前記インデックスに追加するインデックス登録部と、を有する。

したがって、本発明によれば、インデックスのメンテナンスの契機を、新規データ登録時に処理対象のインデックス要素と同じ値を有する別データのインデックス要素に対して行うことでＩ／Ｏ回数を最小限にし、メンテナンス負荷を平滑化することができるため、ログデータ等を管理するデータベースにおける性能確保が可能となる。これにより、従来のリレーショナルデータベースでは適用が困難だった、容量が限られた組み込み機器の二次記憶装置における産業機器の稼働データの蓄積や、情報システムのログデータなどの運用などといった分野に活用することが可能となる。

本発明の実施例を示し、データ管理装置の一例を示すブロック図である。 本発明の実施例を示し、二次記憶装置のデータベースに格納される表データおよびインデックスの構成図である。 本発明の実施例を示し、新規データをデータベースに挿入する際に、データベース管理システムで行われる処理の一例を示すフローチャートである。 本発明の実施例を示し、新規データをデータベースに挿入する際の、表データに対する操作の一例を示す図である。 本発明の実施例を示し、新規データをデータベースに挿入する際にデータベース管理システムで行われる処理の一例を示すフローチャートである。 本発明の実施例を示し、データベース管理システムが、新規データをデータベースに挿入する際のインデックス操作中に行うメンテナンス処理のフローチャートである。 本発明の実施例を示し、レコードＩＤブロックのメンテナンス処理において、現在位置より表データの格納位置が前方の情報がメンテナンスされる例を示す図である。 本発明の実施例を示し、レコードＩＤブロックのメンテナンス処理において、現在位置より表データの格納位置が後方の情報がメンテナンスされる例を示す図である。 本発明の実施例を示し、データ管理装置で行われる検索処理の一例を示すフローチャートである。 本発明の実施例を示し、データ管理装置でデータの検索を行う例を示す説明図である。 本発明の実施例を示し、ハッシュインデックスを採用したインデックスの構成図である。 リングバッファを取り入れたデータベースのデータ更新例として、表データの最大格納数を５としたリングバッファにおいて、データ追加時の例を示した説明図である。 Ｂ−Ｔｒｅｅインデックスにリングバッファを取り入れたデータベースにおいてデータの更新を行う例を示す説明図である。

以下、本発明の実施形態を添付図面に基づいて説明する。

以下、本発明を実施する場合の一形態を、図面を参照して具体的に説明する。

図１は、本発明の実施例を示し、データ管理装置１の一例を示すブロック図である。データ管理装置１は、演算を行うプロセッサ１００と、データやプログラムを保持するメモリ１０２と、外部からのデータの検索や登録などの操作命令であるＳＱＬ文を受け付ける入力装置１０４と、ＳＱＬ文の構文解析を行う構文解析部１０７と、データ検索要求に対してデータの検索を実現するデータ検索部１０８と、検索結果を出力する出力装置１０５と、データ更新要求に対してデータの更新を実現するデータ更新部１０９と、データやプログラムを格納する二次記憶装置１０３で構成された計算機である。

二次記憶装置１０３には、表データ２０１とインデックス３０１から構成されるデータベース１１１が配置され、メモリ１０２に設定したＤＢキャッシュ１１０を介してデータの読み込みと書き出しが行われる。

メモリ１０２には、データベース１１１を管理するデータベース管理システム１０１がロードされて、プロセッサ１００によって実行される。データベース管理システム１０１は、構文解析部１０７と、データ検索部１０８と、データ更新部１０９と、表データ登録部１０９１と、インデックス登録部１０９２と、ＤＢキャッシュ１１０を含む。

データ管理装置１は、図示しないネットワークを介して接続されたクライアント計算機から、データベース１１１の検索要求や登録要求を受け付けて、データベース管理システム１０１で処理した結果をクライアント計算機に応答する。

本実施例において、入力装置１０４に入力されたＳＱＬ文は、構文解析部１０７でＳＱＬ文の構文解析が行われる。ＳＱＬ文が検索要求である場合は、データ検索部１０８にて、データベース１１１から該当のデータを検索し、出力装置１０５に検索結果が出力される。登録要求である場合は、データ更新部１０９の表データ登録部１０９１で表２０１の情報が登録され、さらに、インデックス登録部１０９２でインデックス３０１の情報が更新される。

構文解析部１０７と、データ検索部１０８と、データ更新部１０９等のデータベース管理システム１０１の各機能部はプログラムとしてメモリ１０２にロードされる。

プロセッサ１００は、各機能部のプログラムに従って処理することによって、所定の機能を提供する機能部として稼働する。例えば、プロセッサ１００は、データ検索部プログラムに従って処理することでデータ検索部１０８として機能する。他のプログラムについても同様である。さらに、プロセッサ１００は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

データベース管理システム１０１の各機能を実現するプログラム、テーブル等の情報は、二次記憶装置１０３や不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

図２は、二次記憶装置１０３上のデータベース１１１に格納される表データ２０１およびインデックス３０１の構成図である。図示の例は、表データ２０１に、最大格納数（レコード数）＝５のリングバッファを採用し、インデックス３０１にはＢ−Ｔｒｅｅインデックスを採用したデータ構造である。

表データ２０１は、データを格納する管理対象データ部２０２と、リングバッファの状態を管理する属性管理情報２０３から構成される。

表データ２０１の管理対象データ部２０２は、二次記憶装置１０３上の物理的な格納位置を示す格納位置ＩＤ２０２１と、管理対象のデータの書き込み日時を格納するＴＩＭＥ２０２２と、所定の値を格納するＶＡＬＵＥ２０２３と、データ本体を格納するＤＡＴＡ２０２４からひとつのレコードが構成される。なお、ＶＡＬＵＥ２０２３は、ログデータなどを構成する所定の情報を格納することができる。

属性管理情報２０３は、現在の最新データの格納位置を示すＣｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性（最終書き込み位置）２０３２と、データ登録時に管理対象データ部２０２においてデータ格納位置がリングバッファを循環した回数を示すＣｕｒｒｅｎｔ Ｌａｐ属性（循環回数）２０３１を含む。

インデックス３０１は、ルートブロック３０５と、リーフブロック３０６と、レコードＩＤブロック（データブロック）３０７で構成される。ルートブロック３０５には、検索条件として指定された値に対応するリーフブロック３０６の位置を算出するためのデータが格納される。リーフブロック３０６には、検索対象の値に対するレコードＩＤブロック３０７の格納位置を算出するためのデータが格納される。なお、ルートブロック３０５からリーフブロック３０６の総称をインデックス要素とする。

リーフブロック３０６の値に対応して、表データ２０１上の位置と、リングバッファの循環回数がレコードＩＤブロック３０７として設定される。レコードＩＤブロック３０７の各構成要素には、格納位置ＩＤ３０７１とインデックス構築時のＣｕｒｒｅｎｔ Ｌａｐ属性２０３１の値（循環回数）が記録されるＬａｐ情報３０７２が格納される。本実施例は、管理対象データ部２０２で管理するデータの最大格納件数を５とした場合の例である。

以下、上述のように構成されたデータ管理装置１で行われる処理の一例を説明する。

図３は、新規データをデータベース１１１へ登録する際に、表データ登録部１０９１で行われる表データ登録処理の一例を示すフローチャートである。

表データ登録部１０９１は、まず、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の値に１を加算し（ステップＳ１）、管理対象データ部２０２で管理するデータの最大格納件数と比較する（ステップＳ２）。

Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の値が最大格納件数（５）より大きい場合は、表データ２０１の末尾を示すことになるので、表データ登録部１０９１は、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２に「１」を設定し、Ｃｕｒｒｅｎｔ Ｌａｐ属性２０３１に１を加算する（ステップＳ３）。

続いて、表データ登録部１０９１は、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２が指し示す管理対象データ部２０２の格納位置にデータが存在するか否かを判定し（ステップＳ４）、データが存在しない場合はデータを新規登録する（ステップＳ６）。一方、表データ登録部１０９１は、データが存在する場合、新規データで古いデータを上書きする（ステップＳ５）。

上記処理によって、表データ登録部１０９１は、リングバッファで構成された表データ２０１にデータを追加し、属性管理情報２０３で、リングバッファの書き込み位置と周回数を管理する。

図４は、データベース管理システム１０１が、新規データをデータベース１１１に挿入する際に、表データ２０１に対する操作を示すデータ構成図である。データベース管理システム１０１が、新規データ４０１を登録する場合、初めに、前記ステップＳ１により現在のＣｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３１の値が「４」から「５」に更新され、前記ステップＳ２によってＣｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の値と表格納最大件数（５）が比較される。

データベース管理システム１０１は、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の値が、最大格納件数を超えていないため、表格納位置ＩＤ２０２１＝「５」のデータが上書きされる。次の新規データ４０２が登録される場合では、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の値＝「５」が、前記ステップＳ１で「１」が加算されて「６」となる。

Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の値が表格納最大件数５を超えるため、前記ステップＳ３により データベース管理システム１０１は、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２に「１」を設定し、Ｃｕｒｒｅｎｔ Ｌａｐ属性２０３１に「１」を加算した値「４」を設定し、格納位置ＩＤ２０２１＝１のデータが上書きされる。

図５は、新規データをデータベース１１１に挿入する際に、インデックス登録部１０９２で行われる処理の一例を示すフローチャートである。

インデックス登録部１０９２では、新規データが表データ２０１に登録されると、インデックス３０１に値を設定する。インデックス登録部１０９２は、インデックスとして利用する表データ２０１の値（例えば、ＶＡＬＵＥ２０２３）を元に、Ｂ−Ｔｒｅｅで構成されたルートブロック３０５とリーフブロック２０６の探索を行う。

インデックス登録部１０９２は探索の結果、該当するレコードＩＤブロック３０７の格納位置の算出を行い（ステップＳ１１）、該当のレコードＩＤブロック３０７をＤＢキャッシュ１１０に読み込む（ステップＳ１２）。

次に、インデックス登録部１０９２は、ＤＢキャッシュ１１０上のレコードＩＤブロック３０７のメンテナンスを行う（ステップＳ１３）。レコードＩＤブロックのメンテナンスは、後述するように当該レコードＩＤブロック３０７の内容を、書き込みが行われた表データ２０１の内容に一致させる。

インデックス登録部１０９２は、メンテナンスが完了すると、レコードＩＤブロック３０７の末尾に追加した表データ２０１の格納位置ＩＤ２０２１とＣｕｒｒｅｎｔ Ｌａｐ属性２０３１の値を格納する（ステップＳ１４）。最後に、インデックス登録部１０９２は、ＤＢキャッシュ１１０上のレコードＩＤブロック３０７をインデックス３０１に書き込む（ステップＳ１５）。

上記処理によって、インデックス登録部１０９２は、表データ２０１に追加されたレコードのインデックスに用いる値（ＶＡＬＵＥ２０２３）に対応するリーフブロック３０６を探索し、該当するリーフブロック３０６のレコードＩＤブロック３０７に格納位置ＩＤ２０２１とＣｕｒｒｅｎｔ Ｌａｐ属性２０３１を追加する。

そして、インデックス登録部１０９２は、該当するレコードＩＤブロック３０７についてメンテナンスを実施して、レコードＩＤブロック３０７の内容を表データ２０１と整合させてから新たな構成要素（データブロック）を追加する。

したがって、インデックス３０１のメンテナンスの契機を、新規データの登録時に処理対象のレコードＩＤブロック３０７の構成要素（データブロック）と同じ値を有する別データの構成要素に対して行うことで、二次記憶装置１０３へのＩ／Ｏ回数を最小限にすることが可能となる。また、レコードＩＤブロック３０７の構成要素のメンテナンスによって不要な構成要素を削除してから新たな構成要素を加えることで、メンテナンスで処理する構成要素の数を削減して処理負荷の低減を図ることができる。

すなわち、表データ２０１への書き込み毎に、対象となるレコードＩＤブロック３０７についてメンテナンスを実施するので、メンテナンスの負荷を平滑化することができるため、ログデータなどのデータベース管理システムにおける性能確保が可能となる。これにより、前記従来例のように、インデックス３０１の全体に対するメンテナンス処理は不要となって、従来のリレーショナルデータベースでは適用が困難だった、容量が限られた組み込み機器の二次記憶装置１０３における産業機器の稼働データの蓄積や、情報システムのログデータなどの運用などといった分野に活用することが可能となる。

なお、上記ではレコードＩＤブロック３０７のメンテナンスを行った（ステップＳ１３）後に、構成要素の追加（ステップＳ１４）を行う例を示したが、レコードＩＤブロック３０７に構成要素を追加してからメンテナンスを行ってもよい。

図６は、前記ステップＳ１３で行われるインデックス追加処理時のメンテナンス処理の一例を示すフローチャートである。

インデックス登録部１０９２は、図５のステップＳ１２で読み込んだＤＢキャッシュ１１０上のレコードＩＤブロック３０７に格納された構成要素のすべてについて（ステップＳ２１）、格納位置ＩＤ３０７１とＣｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の比較を行う（ステップＳ２２）。

インデックス登録部１０９２は、格納位置ＩＤ３０７１の値がＣｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２以下の場合、ステップＳ２３に進んでＬａｐ情報３０７２とＣｕｒｒｅｎｔ Ｌａｐ属性２０３１の値を比較し、Ｌａｐ情報３０７２がＣｕｒｒｅｎｔ Ｌａｐ属性２０３１より小さい場合、ＤＢキャッシュ１１０から対象の構成要素を削除する（ステップＳ２５）。

一方、インデックス登録部１０９２は、前記ステップＳ２２の比較において、格納位置ＩＤ３０７１の値がＣｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２より大きい場合は、Ｌａｐ情報３０７２に「１」を加算した値とＣｕｒｒｅｎｔ Ｌａｐ属性２０３１を比較し（ステップＳ２４）する。インデックス登録部１０９２は、Ｌａｐ情報３０７２に「１」を加算した値がＣｕｒｒｅｎｔ Ｌａｐ属性２０３１未満の場合、ＤＢキャッシュ１１０から対象の構成要素を削除する（ステップＳ２５）。

最後に、インデックス登録部１０９２は、ＤＢキャッシュ１１０上のレコードＩＤブロック３０７の詰め直しを行う（ステップＳ２６）。この詰め直しでは、レコードＩＤブロック３０７の不要な領域の消去などが行われる。

以上の処理によって、インデックス３０１で更新されるレコードＩＤブロック３０７は、不要な構成要素が削除された後に、不要な領域の消去などが行われて、ブロック内でフラグメントのないデータとしてメンテナンスが行われる。本実施例では、インデックス３０１の追加時に、追加対処のレコードＩＤブロック３０７についてメンテナンスを行うことで、メンテナンスを行う際のデータ管理装置１の負荷を抑制することができる。

これにより、インデックス３０１のレコードＩＤブロック３０７に新たな構成要素が追加される度にメンテナンスが行われ、一回のメンテナンスに要する計算機資源を低減できる。そして、レコードＩＤブロック３０７への構成要素の追加の度に、該当のレコードＩＤブロック３０７のメンテナンスを行っておくことで、多大な計算機資源を必要とするインデックス３０１全体のメンテナンスを不要にすることができる。

また、インデックス３０１のメンテナンスでは、レコードＩＤブロック３０７の構成要素のＬａｐ情報３０７２とＣｕｒｒｅｎｔ Ｌａｐ属性２０３１から不要となった構成要素を削除することができる。これにより、インデックス登録部１０９２は、実際の表データ２０１を参照することなく不要な構成要素を判定することができるので、処理負荷の低減を図ることができる。

図７は、インデックスのメンテナンス処理における、レコードＩＤブロック３０７のメンテナンスで、現在位置より表データ２０１の格納位置が前方の情報がメンテナンスされる例を示すものである。なお、表データ２０１の格納位置が前方とは、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２よりも値が小さい格納位置ＩＤ２０２１を指す。

表データ登録部１０９１により、新規データ４０１が表データ２０１に登録されて格納位置ＩＤ＝「４」のデータが上書きされたあと、インデックス登録部１０９２では、新規データ４０１のＶＡＬＵＥ２０２３の値である「２」を元に、対象のレコードＩＤブロック３０７の格納位置が算出され（ステップＳ１１）、ＤＢキャッシュ１１０上に読み込まれる（ステップＳ１２）。

次に、インデックス３０１のメンテナンス処理（ステップＳ１３）において、インデックス登録部１０９２では前記ステップＳ２２の判定がレコードＩＤブロック３０７の構成要素５０１に対して行われる。

構成要素５０１の格納位置ＩＤ３０７１の値は「１」であり、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の値が「４」であることから、次に前記図６のステップＳ２３の比較が行われる。そして、構成要素５０１のＬａｐ情報３０７２の値が「２」であり、Ｃｕｒｒｅｎｔ Ｌａｐ属性２０３１の値が「３」であることから、構成要素５０１の情報はＤＢキャッシュ１１０上のレコードＩＤブロック３０７から削除される（ステップＳ２５）。

インデックス登録部１０９２は、上述のようにレコードＩＤブロック３０７のインデックスのメンテナンスが完了した後、ＤＢキャッシュ１１０上のレコードＩＤブロック３０７の末尾に新規データの構成要素５０２を追加し（ステップＳ１４）、当該レコードＩＤブロック３０７がインデックス３０１に書き込まれる。

図８は、インデックスのメンテナンス処理における、レコードＩＤブロック３０７のメンテナンスで、現在位置より表データ２０１の格納位置が後方の情報がメンテナンスされる例を示すものである。なお、表データ２０１の格納位置が後方とは、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２よりも値が大きい格納位置ＩＤ２０２１を指す。

表データ登録部１０９１により、新規データ４０３が表データ２０１に登録されて格納位置ＩＤ＝「４」のデータが上書きされたあと、インデックス登録部１０９２では、新規データ４０２のＶＡＬＵＥ２０２３の値である「８」を元に、対象のレコードＩＤブロック３０７の格納位置が算出され、ＤＢキャッシュ１１０上に読み込まれる（ステップＳ１２）。

前記図６のステップＳ２３の比較において、構成要素５０３が適用され、構成要素５０３の格納位置ＩＤ３０７１の値は「５」であり、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の値が「４」であることから、次に前記ステップＳ２４の比較が行われる。構成要素５０３のＬａｐ情報３０７２の値が「１」であり、Ｃｕｒｒｅｎｔ Ｌａｐ属性２０３１の値が「３」であることから、構成要素５０３の情報はＤＢキャッシュ１１０上のレコードＩＤブロックから削除される（ステップＳ２５）。

このように、不要になったインデックス３０１のメンテナンスが、新規登録時のインデックスのメンテナンスに関する二次記憶装置１０３からの読み込みと書き込みのタイミングで同時に行われる構成となっている。

以上の処理及び構成によって、表データ２０１へデータを追加すると、インデックス３０１のレコードＩＤブロック３０７にも構成要素が追加される。インデックス登録部１０９２は、構成要素の追加に先立って当該レコードＩＤブロック３０７のメンテナンスを行って、不要な構成要素の削除を実施する。これにより、表データ２０１へデータが追加される度にインデックス３０１の部分的なメンテナンスが自動で行われることになる。したがって、データベース管理システム１０１では、インデックス３０１の構成要素のメンテナンスを明示的に実行しなくてもよい。

また、本実施例では、対象の表データ２０１に対してインデックスが一つ定義された例を示したが、複数のインデックスを定義した場合でも、インデックス登録部１０９２で行われるインデックス登録処理が、それぞれのインデックスに対して行われることは言うまでもない。

また、リレーショナルデータベースにおいては、ジャーナル情報の管理ならびにトランザクション制御によりＤＢキャッシュ１１０と二次記憶装置１０３の間の読み込みや書き込みのタイミングが制御されているが、本実施例におけるデータ構造が同様に適用できることは言うまでもない。

図９は、データ検索部１０８において、データの検索を行う処理の一例を示すフローチャートである。この処理は、データベース管理システム１０１が検索要求を受け付けたときに実行される。

データ検索部１０８では、受け付けた検索条件の値を元に、インデックス３０１のルートブロック３０５とリーフブロック３０６の探索を行い、該当するレコードＩＤブロック３０７の格納位置の算出を行う（ステップＳ３１）。

次に、データ検索部１０８は、対象のレコードＩＤブロック３０７の各構成要素について（ステップＳ３２）、格納位置ＩＤ３０７１とＣｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の比較を行い（ステップＳ３３）、格納位置ＩＤ３０７１がＣｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２以下の場合は、Ｌａｐ情報３０７２とＣｕｒｒｅｎｔ Ｌａｐ属性２０３１の値の比較を行う（ステップＳ３４）。

データ検索部１０８は、Ｌａｐ情報３０７２がＣｕｒｒｅｎｔ Ｌａｐ属性２０３１の値以上である場合、検索結果として有効と判断し、結果リスト用のＤＢキャッシュ１１０に格納位置ＩＤ３０７１の値を登録する（ステップＳ３６）。一方、データ検索部１０８は、Ｌａｐ情報３０７２がＣｕｒｒｅｎｔ Ｌａｐ属性２０３１の値より小さい場合、次の構成要素に対する処理を行う（Ｓ３７）。

前記ステップＳ３３の判定において、格納位置ＩＤ３０７１がＣｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の値より大きい場合、データ検索部１０８は、Ｌａｐ情報３０７２に「１」を加算した値とＣｕｒｒｅｎｔ Ｌａｐ属性２０３１の値の比較を行う（ステップＳ３５）。Ｌａｐ情報３０７２に「１」を加算した値がＣｕｒｒｅｎｔ Ｌａｐ属性２０３１の値以上である場合、データ検索部１０８は、検索結果として有効と判断し、結果リスト用のＤＢキャッシュ１１０に格納位置ＩＤ３０７１の値を登録する（ステップＳ３６）。

最後に、データ検索部１０８は、前記ステップＳ３６でＤＢキャッシュ１１０上に登録された検索対象の格納位置ＩＤのすべてについて、表データ２０１の対象位置の情報を取得し、出力装置１０５へ検索結果の出力を行う（ステップＳ３８）。

上記処理によって、検索要求を受け付けたデータベース管理システム１０１は、インデックス３０１に基づいて表データ２０１を検索し、検索結果を出力装置１０５に出力する。

図１０は、本実施例において、データの検索を行う例を示した説明図である。検索条件として、値「２」が指定された場合、データ検索部１０８では、前記図９のステップＳ３１により、リーフブロック３０６で「２」のレコードＩＤブロック３０７が算出される。図示の例では、ＶＡＬＵＥ２０２３＝２に対応するレコードＩＤブロック３０７は、構成要素５０１、５０２を含んでいる。

次に構成要素５０１は、前記図９のステップＳ３３により比較される。構成要素５０１の格納位置ＩＤ３０７１の値は、「１」であり、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の値が「４」であることから、真と判定され前記ステップＳ３４による比較が行われる。

次に、ステップＳ３４では、構成要素５０１のＬａｐ情報３０７２の値が「２」であり、Ｃｕｒｒｅｎｔ Ｌａｐ属性２０３１の値が「３」であることから、偽と判定され構成要素５０１は検索結果から除外される。

次にデータ検索部１０８は次の構成要素５０２を取得して、前記ステップＳ３３による比較が行われる。構成要素５０２の格納位置ＩＤ３０７１の値は、「４」であり、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の値が「４」であることから、真と判定され前記ステップＳ３４による比較が行われる。

ステップＳ３４では、構成要素５０２のＬａｐ情報３０７２の値が「３」であり、Ｃｕｒｒｅｎｔ Ｌａｐ属性２０３１の値が「３」であることから、真と判定されて構成要素５０２の格納位置ＩＤ３０７１が検索結果に登録される。

最後にデータ検索部１０８では、前記ステップＳ３７により、表データ２０１から検索結果が取得され出力装置１０５に出力される。

また、検索条件として、値「８」が指定された場合は、データ検索部１０８では、前記ステップＳ３１により、レコードＩＤブロック３０７が算出される。図示の例では、ＶＡＬＵＥ２０２３＝８に対応するレコードＩＤブロック３０７は、構成要素５１１、５１２を含む。

次にデータ検索部１０８では、構成要素５１１が前記ステップＳ３３により比較される。構成要素５１１の格納位置ＩＤ３０７１の値は、「１」であり、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の値が４であることから、真と判定され前記ステップＳ３４による比較が行われる。

ステップＳ３４では、構成要素５１１のＬａｐ情報３０７２の値が「１」であり、Ｃｕｒｒｅｎｔ Ｌａｐ属性２０３１の値が３であることから、偽と判定されて当該構成要素５１１は検索結果から除外される。

データ検索部１０８では、次の構成要素５１２に対して、前記ステップＳ３３による比較が行われる。構成要素５１２の格納位置ＩＤ３０７１の値は、「５」であり、Ｃｕｒｒｅｎｔ Ｐｏｓｉｔｉｏｎ属性２０３２の値が「４」であることから、偽と判定され前記ステップＳ３５による比較が行われる。ステップＳ３４では、構成要素５１２のＬａｐ情報３０７２の値が１であり、Ｃｕｒｒｅｎｔ Ｌａｐ属性２０３１の値が３であることから、偽と判定され構成要素５１２の格納位置ＩＤが検索結果から除外される。

最後に前記ステップＳ３７では、該当の格納位置ＩＤ３０７１が検索結果用のＤＢキャッシュ１１０に登録されていないため、検索結果が０件として出力装置１０５に出力される。このように、インデックス３０１のレコードＩＤブロック３０７内に古い構成要素が残っていた場合でも、データ検索部１０８がＬａｐ情報３０７２に基づいて当該古い構成要素を読み飛ばすことで、ひとつのレコードＩＤブロック３０７に古い構成要素が残存していても検索結果から排除することができる。

また、図５、図６に示した通り、本発明では登録した表データ２０１に対応するインデックス３０１のレコードＩＤブロック３０７と同一ブロックに格納される構成要素が、表データ２０１への書き込み毎にメンテナンスされる仕組みとなっている。

しかし、インデックス３０１に利用される値は、本実施例で示したある一定範囲の数値データだけではなく、日時情報や文字列情報なども格納されるため、対象のリーフブロック３０６が再利用されない場合がある。この場合、本発明のインデックス３０１の効果が発揮されず、不要なデータが残ったままとなる場合がある。このようなデータを管理する場合では、インデックシングにハッシュインデックスを利用することで、対処することができる。

図１１は、ハッシュインデックスのデータ構造の一例であり、表データ２０１のＶＡＬＵＥ２０２３の情報に対してハッシュ値のインデックス３０１Ａが構成されている状態を示す。各表データ２０１には、各レコードに対して二次記憶装置１０３上の物理的な格納位置を示す格納位置ＩＤ２０２１が付与されて記憶される。図１１の例では、表データ２０１は図２と同様であり、図２に示したＢ−Ｔｒｅｅのインデックス３０１に代わって、ハッシュインデックス３０１Ａを採用したものである。

インデックス３０１Ａはハッシュ関数３３０と、リーフブロック３０６と、レコードＩＤブロック３０７のデータブロックで構成される。ハッシュ関数３３０では、インデックス対象値を入力としてハッシュ値が出力される。

本実施例ではインデックス対象値としてＶＡＬＵＥ２０２３の値を用いる例を示す。また、本実施例では、ハッシュ関数３３０が、インデックス対象値を１０で除した余りを結果として算出する例を示す。したがって、インデックス要素のリーフブロック３０６は、０〜９の整数となる。

各リーフブロック３０６は、対応するハッシュ値の順に格納されており、ハッシュ値によって、該当するリーフブロック３０６が特定される。そして、レコードＩＤブロック３０７には、リーフブロック３０６に対応する構成要素３０７４〜３０７６が含まれる。

レコードＩＤブロック３０７の構成要素３０７４〜３０７６は、対象の値を格納している表データ２０１のレコードの格納位置ＩＤ３０７１と、インデックス対象値としてのＶＡＬＵＥ３０７３と、表データ２０１に追加したときの循環回数を示すＬａｐ情報３０７２が、インデックス対象値順でソートされ、記録される。なお、レコードＩＤブロック３０７は、図２と同様に複数の構成要素（データブロック）を含むことができる。

たとえば、検索条件に数値「２２」が指定されており、ハッシュ関数３３０が１０の剰余で求めるものである場合、ハッシュ関数３３０によってハッシュ値が数値「２」と算出され、数値「２」の値を示すリーフブロック３０６の格納位置が算出され、さらに、レコードＩＤブロック３０７の構成要素３０７４が算出される。

算出されたレコードＩＤブロック３０７の構成要素３０７４に対して、データ検索部１０８は検索条件をキーにした二分木探索などを行い、該当ハッシュ値と等しい部分集合を取得し、記録された格納位置ＩＤをもとに、表データ２０１の該当のレコードを順次取り出すことによって、ハッシュインデックスを利用した検索が実現される。

ハッシュインデックスを利用すると、異なる複数のインデックス対象値に対して同一のハッシュ値が得られる場合がある。これをシノニムと呼ぶ。たとえば、ＶＡＬＵＥ２０２３の値が「２２」のときに得られるハッシュ値と、ＶＡＬＵＥ２０２３の値が「２」のときに得られるハッシュ値は同一の「２」となるためシノニムである。

そして、シノニムとなったレコードＩＤブロック３０７では、複数のデータが格納されるが、Ｌａｐ情報３０７２の値によって、検索結果として利用するか否かを判定することができる。このため、本実施例のハッシュインデックスでは、レコードＩＤブロック３０７でシノニムを許容して複数のデータを格納することができる。

例えば、ハッシュ値＝２のレコードＩＤブロック３０７の構成要素３０７４には、インデックス対象値が２、１２、２２、・・・となる表データ２０１のレコードの情報（ＶＡＬＵＥ３０７３）が登録される。

そのため、たとえば、新規データとして「２２」の値を持つデータが表データ２０１に登録された場合、前記インデックスのメンテナンス処理（ステップＳ１３）において、シノニムである「２」、「１２」の構成要素もメンテナンス対象として処理されることが期待できる。

また、ハッシュインデックスを採用したことにより、インデックス３０１Ａを利用した検索を行う際のレコードＩＤブロック３０７の構成要素の有効判定に、レコードＩＤブロック３０７に格納されたインデックス対象値の実値（ＶＡＬＵＥ３０７３）による判定が行われることは言うまでもない。

＜まとめ＞
本実施例のデータベース管理システム１０１のインデックス登録部１０９２は、表データ２０１にレコードが追加されると、追加されたレコードのインデクス対象値（ＶＡＬＵＥ２０２３）に対応するリーフブロック３０６のレコードＩＤブロック３０７をメンテナンスしてから、当該レコードＩＤブロック３０７に新たな格納位置ＩＤ２０２１とＣｕｒｒｅｎｔ Ｌａｐ属性２０３１を追加する。

インデックス３０１のメンテナンスは、表データ２０１を追加する度に、データを追加したレコードＩＤブロック３０７の単位で行うことができ、二次記憶装置１０３へのＩ／Ｏ回数を最小限にすることが可能となる。これにより、インデックス３０１のメンテナンスにかかる負荷を平滑化することができるため、データベース１１１でログデータを管理する場合などで性能確保が可能となる。これにより、従来のリレーショナルデータベースでは適用が困難だった、容量が限られた組み込み機器の二次記憶装置における産業機器の稼働データの蓄積や、情報システムのログデータなどの運用などといった分野に活用することが可能となる。

すなわち、インデックス３０１の追加とメンテナンスは、インデックス登録部１０９２がＤＢキャッシュ１１０に読み込んだレコードＩＤブロック３０７について行うため、前記従来例のように、二次記憶装置１０３上の二箇所への更新が不要になることでＩ／Ｏ回数を低減できる。

また、インデックス３０１のレコードＩＤブロック３０７内に古い構成要素が残っていた場合でも、データ検索部１０８がＬａｐ情報３０７２に基づいて当該古い構成要素を読み飛ばすことで、ひとつのレコードＩＤブロック３０７に古い構成要素が残存していても検索結果から排除することができる。すなわち、Ｌａｐ情報３０７２をレコードＩＤブロック３０７の構成要素の有効または無効を判定する基準として利用することができる。

また、インデックス３０１Ａにハッシュインデックスを取り入れることで、時間情報や文字列情報などの格納データの重複が発生しないデータに対するインデックスの管理においても、メンテナンスにかかる負荷を平滑化することができる。

また、上記実施例では、データベース１１１を二次記憶装置１０３に格納する例を示したが、これに限定されるものではなく、データベース１１１をメモリ１０２等の主記憶へ格納するインメモリデータベースに本発明を適用することができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。

また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１ データ管理装置
１０２ メモリ
１０３ 二次記憶装置
１００ プロセッサ
１０４ 入力装置
１０５ 出力装置
１０７ 構文解析部
１０８ データ検索部１０８
１０９ データ更新部１０９
１１０ ＤＢキャッシュ
１１１ データベース
２０１ 表データ
２０３ 属性管理情報
３０１ インデックス
１０９１ 表データ登録部
１０９２ インデックス登録部

Claims (12)

1. プロセッサとメモリとを有するデータ管理装置であって、
   データを格納する表データと、
   前記データを検索するインデックス要素を格納するインデックスと、
   前記表データとインデックスを管理するデータベース管理部と、を有し、
   前記表データは、
   前記データを格納するリングバッファと、
   前記データを追加した前記リングバッファの位置を保持する最終書き込み位置と、
   前記リングバッファを循環した回数を保持する第１の循環回数と、を有し、
   前記インデックスは、
   検索対象の値に対応して設定された前記インデックス要素と、
   前記インデックス要素に対応して、前記表データの位置を示す位置情報と、前記位置情報に対応するデータを追加したときの前記リングバッファの循環回数を保持する第２の循環回数とを含むデータブロックと、を有し、
   前記データベース管理部は、
   前記表データへデータを追加する際には、前記最終書き込み位置に前記データを追加してから、前記最終書き込み位置と前記第１の循環回数を更新する表データ登録部と、
   前記追加したデータに対応する前記インデックス要素で、当該インデックス要素に対応する前記データブロックを前記インデックスに追加するインデックス登録部と、
   を有することを特徴とするデータ管理装置。
2. 請求項１に記載のデータ管理装置であって、
   前記インデックス登録部は、
   前記データブロックを追加する際に、前記データブロックのうち不要なデータブロックを前記第２の循環回数に基づいて特定し、当該特定されたデータブロックを削除することを特徴とするデータ管理装置。
3. 請求項２に記載のデータ管理装置であって、
   前記インデックス登録部は、
   前記第１の循環回数と、前記第２の循環回数とを比較して、前記第１の循環回数と前記第２の循環回数が所定の関係であれば当該データブロックを不要なデータブロックと判定することを特徴とするデータ管理装置。
4. 請求項２に記載のデータ管理装置であって、
   前記インデックス登録部は、
   前記データブロックを追加する前に、前記不要なデータブロックを削除することを特徴とするデータ管理装置。
5. 請求項１に記載のデータ管理装置であって、
   前記インデックス要素は、
   前記データから所定のハッシュ関数で算出したハッシュ値を含み、同一のハッシュ値に複数のデータブロックを対応付けることを特徴とするデータ管理装置。
6. 請求項１に記載のデータ管理装置であって、
   前記データベース管理部は、
   検索条件を受け付けて、当該検索条件に合致する前記インデックス要素を特定し、当該特定したインデックス要素に対応するデータブロックのうち不要なデータブロックを前記第２の循環回数に基づいて特定し、当該特定されたデータブロックを排除して前記検索条件に合致するデータブロックを検索する検索部を、さらに有することを特徴とするデータ管理装置。
7. プロセッサとメモリとを有する計算機でデータベースの表データを管理するデータベースの管理方法であって、
   前記計算機が、リングバッファで構成された前記表データにデータを追加する第１のステップと、
   前記計算機が、前記データを追加した前記リングバッファの位置を保持する最終書き込み位置を更新し、前記リングバッファを循環した回数を保持する第１の循環回数を更新する第２のステップと、
   前記計算機が、前記データを検索するインデックス要素を格納したインデックスで、前記追加したデータに対応する前記インデックス要素を特定する第３のステップと、
   前記計算機が、前記特定したインデックス要素に対応して、前記データを追加した前記表データの位置を示す位置情報と、前記位置情報に対応するデータを追加したときの前記リングバッファの循環回数を保持する第２の循環回数とを含むデータブロックを追加する第４のステップと、
   を含むことを特徴とするデータベースの管理方法。
8. 請求項７に記載のデータベースの管理方法であって、
   前記第４のステップは、
   前記データブロックを追加する際に、前記データブロックのうち不要なデータブロックを前記第２の循環回数に基づいて特定し、当該特定されたデータブロックを削除することを特徴とするデータベースの管理方法。
9. 請求項８に記載のデータベースの管理方法であって、
   前記第４のステップは、
   前記第１の循環回数と、前記第２の循環回数とを比較して、前記第１の循環回数と前記第２の循環回数が所定の関係であれば当該データブロックを不要なデータブロックと判定することを特徴とするデータベースの管理方法。
10. 請求項８に記載のデータベースの管理方法であって、
    前記第４のステップは、
    前記データブロックを追加する前に、前記不要なデータブロックを削除することを特徴とするデータベースの管理方法。
11. 請求項７に記載のデータベースの管理方法であって、
    前記インデックス要素は、
    前記データから所定のハッシュ関数で算出したハッシュ値を含み、同一のハッシュ値に複数のデータブロックを対応付けることを特徴とするデータベースの管理方法。
12. 請求項７に記載のデータベースの管理方法であって、
    検索条件を受け付けて、当該検索条件に合致する前記インデックス要素を特定し、当該特定したインデックス要素に対応するデータブロックのうち不要なデータブロックを前記第２の循環回数に基づいて特定し、当該特定されたデータブロックを排除して前記検索条件に合致するデータブロックを検索する第５のステップを、さらに含むことを特徴とするデータベースの管理方法。

Images