JP2017167917A - データベース管理装置 - Google Patents

Abstract

【課題】クエリの処理効率の観点に基づいてインデックスの生成可否を決定することは困難であること。【解決手段】データベース管理装置は、データおよびインデックスをカラム単位で格納するデータベースに接続され、クライアントからのクエリを受け付けてデータベースに対するクエリ実行結果をクライアントに返却する。データベース管理装置は、処理時間計測部と生成可否決定部を有する。処理時間計測部は、インデックスを利用する場合のクエリの処理時間である第１の処理時間とインデックスを利用しない場合のクエリの処理時間である第２の処理時間とを計測する。生成可否決定部は、インデックスが削除された後に計測された第２の処理時間とインデックスが削除される前に計測された第１の処理時間とに基づいて、インデックスが削除された後、インデックスを生成するか否かを決定する。【選択図】図１

Description

本発明は、データベース管理装置、インデックス生成制御方法、およびプログラムに関する。

今般、ビッグデータ時代の到来から、大量のデータを利用した分析や予測を行う技術が求められている。従来、データベースは、行単位（レコード単位）で処理を行うリレーショナルデータベースが主流だったが、昨今は項目毎（列毎）の集計・並び替えを高速に処理できるカラムストア型データベースが注目を集めている。カラムストア型データベースのデータ保持の方法、即ちデータ構造の一つに、ＦＡＳＴ（Ｆｉｌｔｅｒ ＡＲＲＡＹ ＳＴｒｕｃｔｕｒｅ）構造がある（例えば特許文献１参照）。

図１は、１つの表形式データ（図１上部）をＦＡＳＴ構造データ（図１下部）に変換する様子を表している。ＦＡＳＴ構造は、表形式のデータを、列毎に、ユニークで昇順にソートされたデータ群である値リストと、列にどのデータが入っているかを示す値番号（ＰＶ）との２つの成分に分解して表現する。また、図１には示されていないが、行番号（レコード番号）を表す順序集合を備えることがある。

ＦＡＳＴ構造のカラムストア型データベースで、或る値の検索を要求するクエリを処理する場合、以下のような手順になる。

まず、値リストから検索したい値のリスト番号を取得する。例えば、顧客ＩＤ１０２のデータ（レコード）の検索を要求するクエリの場合、図２に示すように、顧客ＩＤの列に対応する値リストから１０２の値リスト番号を取得する。このとき、値リストは昇順ソートされているため、値リストから該当する値を見つけるためにバイナリサーチを使用することができる。今の例では、値リストの番号として、２を取得する。

次に、図２に示すように、顧客ＩＤの列に対応する値番号の先頭から最後尾までの値番号と、上記取得した値リストの番号２とを順番に比較し、一致する値番号のリスト番号を全て取得する。今の例では、リスト番号２、５を取得する。この取得したリスト番号２、５がクエリ処理結果となる。顧客ＩＤ、商品名のデータも一緒に検索したい場合は、顧客ＩＤ、商品名の値番号が２、５の値を取得する流れになる。

このようにＦＡＳＴ構造のカラムストア型データベースは、データをカラム単位かつソート状態で保持しているため、行単位（レコード単位）で処理を行うリレーショナルデータベースに比較して、項目毎（列毎）の検索を高速に処理することができる。しかし、上述したように、取得したい値の値リストに格納されている番号と値番号リストとの比較が、値番号のサイズ分だけ繰り返す必要がある。そこで、その繰り返しを避けるため、カラム単位でインデックスを生成する方法がある。

図５は、インデックスを有するＦＡＳＴ構造の例を示す。図５の各項目（日付、顧客ＩＤ、商品名）の値リストの横に記載されているのが、当該項目のインデックスである。インデックスを有するＦＡＳＴ構造のカラムストア型データベースで、或る値の検索を要求するクエリを処理する場合、以下のような手順になる。

まず、値リストから検索したい値のリスト番号を取得する。例えば、顧客ＩＤが１０２のデータ（レコード）を検索する場合、顧客ＩＤの列に対応する値リストから１０２の値リスト番号を検索する。このとき、値リストは昇順ソートされているため、値リストから該当する値を見つけるためにバイナリサーチを使用することができる。今の例では、値リストの２番目が検索される。

次に、上記検索した値リストの２番目に関連付けられているインデックスに記載されているリスト番号を全て取得する。今の例では、リスト番号２、５を取得する。この取得したリスト番号２、５がクエリ処理結果となる。

このようにインデックスを有するＦＡＳＴ構造では、インデックスを利用することにより、クエリを効率良く処理することができ、一般的には、インデックスを利用しない場合に比較してクエリ処理時間を短縮することができる。

しかし、先述の通り、値リストは昇順ソートされた状態でデータを持っている必要があるため、値リストのデータが更新されてソート状態が崩れると、値リストを再び昇順ソートして作り直す必要が生じる。そして、値リストを作り直すと、元の値リストに関連付けられたインデックスは利用できなくなってしまう。そのため、利用できなくなってしまったインデックスを再び利用できるようにするために、インデックスを保守する仕組みが必要になる。

インデックスを保守する仕組みを有するデータベース管理装置の一例が特許文献２に記載されている。特許文献２に記載される技術では、蓄積されたカラム情報と、外部から利用者により入力された判定式に基づいて、インデックスの保守を自動的に行う。具体的には、データベース管理装置に対して要求されたカラム毎の情報として、表番号、カラム番号、インデックスの有無、検索要求回数、更新要求回数、更新件数をカラム情報テーブルに蓄積する。また、判定式として、「検索要求回数−（更新要求回数×更新件数）×１００」を入力する。そして、蓄積した情報を判定式に代入し、判定式の計算結果が正の場合、インデックス要、負の場合、インデックス不要と判定し、判定結果に基づいて、インデックスの生成、削除を行う。

特開２０１５−１７９３５３号公報 特願昭６３−２０１７１６号公報 特開２０１５−１７９３５３号公報

特許文献２に記載される技術によれば、カラム毎の利用状況に応じて、インデックスの生成可否を決定することができる。しかしながら、検索要求回数、更新要求回数、更新件数は、クエリの処理効率とは無関係であるため、クエリの処理効率の観点に基づいてインデックスの生成可否を決定するのは困難であった。

本発明の目的は、上述した課題、すなわち、クエリの処理効率の観点に基づいてインデックスの生成可否を決定することは困難である、という課題を解決するデータベース管理装置を提供することにある。

本発明の一実施形態に係るデータベース管理装置は、
データおよびインデックスをカラム単位で格納するデータベースに接続され、クライアントからのクエリを受け付けて前記データベースに対するクエリ実行結果を前記クライアントに返却するデータベース管理装置であって、
前記インデックスを利用する場合の前記クエリの処理時間である第１の処理時間と前記インデックスを利用しない場合の前記クエリの処理時間である第２の処理時間とを計測する処理時間計測部と、
前記インデックスが削除された後に計測された前記第２の処理時間と前記インデックスが削除される前に計測された前記第１の処理時間とに基づいて、前記インデックスが削除された後、前記インデックスを生成するか否かを決定する生成可否決定部と、
を有する。
また、本発明の他の実施形態に係るインデックス生成制御方法は、
データおよびインデックスをカラム単位で格納するデータベースに接続され、クライアントからのクエリを受け付けて前記データベースに対するクエリ実行結果を前記クライアントに返却するデータベース管理装置が実行するインデックス生成制御方法であって、
前記インデックスを利用する場合の前記クエリの処理時間である第１の処理時間と前記インデックスを利用しない場合の前記クエリの処理時間である第２の処理時間とを計測し、
前記インデックスが削除された後に計測された前記第２の処理時間と前記インデックスが削除される前に計測された前記第１の処理時間とに基づいて、前記インデックスが削除された後、前記インデックスを生成するか否かを決定する。
また、本発明の他の実施形態に係るプログラムは、
データおよびインデックスをカラム単位で格納するデータベースに接続され、クライアントからのクエリを受け付けて前記データベースに対するクエリ実行結果を前記クライアントに返却するコンピュータを、
前記インデックスを利用する場合の前記クエリの処理時間である第１の処理時間と前記インデックスを利用しない場合の前記クエリの処理時間である第２の処理時間とを計測する処理時間計測部と、
前記インデックスが削除された後に計測された前記第２の処理時間と前記インデックスが削除される前に計測された前記第１の処理時間とに基づいて、前記インデックスが削除された後、前記インデックスを生成するか否かを決定する生成可否決定部と、
して機能させる。

本発明は上述した構成を有するため、クエリの処理効率の観点に基づいてインデックスの生成可否を決定することができる。

表形式データとＦＡＳＴ構造データの例を示す図である。 顧客ＩＤに係る値リストと値番号リストに対して検索処理を行う手順の説明図である。 インデックス生成可否の決定を含むインデックス生成処理のフローチャートである。 本発明の第１の実施形態に係るデータベース管理装置のブロック図である。 インデックスを有するＦＡＳＴ構造データの例を示す図である。 本発明の第１の実施形態に係るデータベース管理装置の動作の一例を示すフローチャートである。 インデックス生成可否を判定する式で使用する参照処理平均時間の計測方法を説明するためのパラメータ等を示す図である。 本発明の第２の実施形態に係るデータベース管理装置のブロック図である。 本発明の第２の実施形態に係るデータベース管理装置の動作の一例を示すフローチャートである。 本発明の第３の実施形態に係るデータベース管理装置のブロック図である。 インデックスを一部削除する例を示す図である。 本発明の第３の実施形態に係るデータベース管理装置の動作の一例を示すフローチャートである。 本発明の第４の実施形態に係るデータベース管理装置のブロック図である。

次に本発明の実施の形態について図面を参照して詳細に説明する。
［第１の実施形態］
図４は本発明の第１の実施形態に係るデータベース管理装置１００のブロック図である。図４を参照すると、データベース管理装置１００は、ＬＡＮ等のネットワークを介してクライアント装置１０１に接続されている。またデータベース管理装置１００は、クライアント装置１０１や図示しないアプリケーションプログラムからのクエリを処理する処理実行部１１０と、インデックスの生成可否を決定し、必要に応じてインデックスを生成するインデックス生成部１２０と、ＦＡＳＴ構造のデータベースを管理するデータ管理部１３０とを有する。

データ管理部１３０は、データベース１４０とアクセス数カウント処理部１５０とを有する。データベース１４０は、ＦＡＳＴ構造でデータを保持する機能を有する。データベース１４０が保持するデータ数、データ型（数値型データ、文字型データなどの実データ）に制限はない。データベース１４０は、値リスト１４１と値番号リスト１４２の組を、項目数の数だけ有する。値リスト１４１は、実データが格納されているリストであり、値リスト番号管理部１４３と実の値格納部１４４とインデックス格納部１４５とを有する。値番号リスト１４２は、項目の値を値リストの番号で示したリストであり、値番号リスト管理部１４６と値番号処理部１４７とを有する。図５の例えば顧客ＩＤの項目との関係では、値リスト番号管理部１４３と実の値格納部１４４は、値リストの番号「１、２、３」と値リスト「１０１、１０２、１０３」に相当し、インデックス格納部１４５は、値リストに関連付けられたインデックスに相当し、値番号リスト管理部１４６と値番号処理部１４７は、値番号リストの番号「１〜７」と値番号「１、２、１、１、２、３、１」に相当する。アクセス数カウント処理部１５０は、項目毎のアクセス数を計測する機能を有する。

処理実行部１１０は、クライアント装置１０１からのクエリを受け付け、データベース１４０に対するクエリ実行結果をクライアントに返却する機能を有する参照・更新処理部１１１を有する。

インデックス生成部１２０は、インデックス削除部１２１と処理実行時間計測部１２２とインデックス生成時間計測部１２３とインデックス生成判断計算部１２４とを有する。インデックス削除部１２１は、インデックス格納部１４５に格納されているインデックスを削除する機能を有する。処理実行時間計測部１２２は、クエリ処理に要する実行時間を計測する機能を有する。インデックス生成時間計測部１２３は、インデックス格納部１４５にインデックスを生成するのに要する実行時間を計測する機能を有する。インデックス生成判断計算部１２４は、インデックスの生成可否を決定し、必要に応じてインデックスを生成する機能を有する。

上述した参照・更新処理部１１１、インデックス削除部１２１、処理実行時間計測部１２２、インデックス生成時間計測部１２３、インデックス生成判断計算部１２４、アクセス数カウント処理部１５０といった機能手段は、例えば、コンピュータとプログラムとで実現することができる。プログラムは、コンピュータ読み取り可能な記録媒体に記録されて提供され、コンピュータの立ち上げ時にコンピュータに読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上に参照・更新処理部１１１、インデックス削除部１２１、処理実行時間計測部１２２、インデックス生成時間計測部１２３、インデックス生成判断計算部１２４、アクセス数カウント処理部１５０といった機能手段を実現する。後述する他の実施形態における機能手段についても同様にコンピュータとプログラムとで実現することができる。

図６はデータベース管理装置１００が実行する処理の一例を示すフローチャートである。図６には、クライアント装置１０１から受け付けたクエリの処理のうち１つの項目（列）に対する処理が示されている。また、受け付けたクエリの解析は別フローで行っているものとして、図６では省略している。また、図６のステップＳ１０３に記載されるインデックス存在フラグは、該当項目がインデックスを持っているか否かを示すフラグであり、更新処理実行フラグは、更新処理を行ったか否かを示すフラグである。また、ステップＳ１０６に記載される閾値ｎは、インデックスを生成する判断を行うためのアクセス数の閾値である。この閾値ｎは、システムによって最適な値を事前に設定しておくことが望ましいが、正の整数であれば問題ない。また、閾値ｎは項目毎に設定することが望ましい。しかし、以下では、説明を簡単にするために、全項目で共通の閾値ｎを使用するものとする。また、各項目のアクセス数の初期値は０とする。

図６を参照すると、データベース管理装置１００の参照・更新処理部１１１は、クライアント装置１０１から受信したクエリが参照クエリか、更新クエリかを判断する（Ｓ１０１）。参照・更新処理部１１１は、更新クエリならば、更新クエリに従ってデータベース１４０に対する更新処理を実行する（Ｓ１０２）。次に、参照・更新処理部１１１は、ステップＳ１０３の処理を行う。参照・更新処理部１１１は、ステップＳ１０３においては、以下の処理を行う。

まず、参照・更新処理部１１１は、更新処理によってソート状態が崩れた値リストを再生成し、それにあわせて値番号リストを再生成する。また、参照・更新処理部１１１は、更新処理を行った項目がインデックスを持っていれば、インデックス削除部１２１によりインデックスを破棄する。また、参照・更新処理部１１１は、インデックスを破棄した場合、当該項目に対応するインデックス存在フラグの値を、インデックスが存在しない旨を示す値０（ｆａｌｓｅ）とする。なお、インデックスが存在する旨を示す値は１（ｔｒｕｅ）である。また参照・更新処理部１１１は、当該項目に対応する更新処理実行フラグの値を、更新処理を実行した旨を示す値１（ｔｒｕｅ）とする。なお、更新処理を実行していない旨を示す値は０（ｆａｌｓｅ）とする。ここで、フラグの値を１（ｔｒｕｅ）にすることを、フラグをたてるとも呼ぶ。

参照・更新処理部１１１は、ステップＳ１０３の処理後、次の処理を確認しに行く（１項目の処理は終了する）。

他方、参照・更新処理部１１１は、クライアント装置１０１から受信したクエリが参照クエリならば、まず更新処理後の最初のアクセスか否か調べる（Ｓ１０４）。これは、更新処理実行フラグが１か否かを確認することで行う。更新処理実行フラグが１であれば更新処理後の最初のアクセスのため、ステップＳ１０９へ進む。このとき、更新処理実行フラグの値を０にしておく。そして、ステップＳ１０９の処理を実行後にステップＳ１０８へ進む。また、更新処理実行フラグが０であれば、すなわち更新処理後の最初のアクセスではない場合、参照・更新処理部１１１は、当該項目にインデックスが生成されているか否かを確認する（Ｓ１０５）。これは、インデックス存在フラグが１か否かを確認することで行う。インデックスが存在していれば、参照・更新処理部１１１は、ステップＳ１０８へ進む。また、インデックスが存在していないならば、参照・更新処理部１１１は、当該項目のアクセス数が最初に設定した閾値ｎ以下であるか否か判断する（Ｓ１０６）。閾値ｎより項目のアクセス数が大きい場合、ステップＳ１０９へ進む。そして、ステップＳ１０９の処理の実行後にステップＳ１０８へ進む。また、アクセス数が閾値ｎ以下の場合、アクセス数カウント処理部１５０により当該項目のアクセス数を１だけ加算し（Ｓ１０７）、ステップＳ１０８へ進む。

ステップＳ１０８では、参照・更新処理部１１１は、参照クエリに係る参照処理を実行する。このとき、参照・更新処理部１１１は、処理する項目にインデックスが存在していれば、当該インデックスを利用して参照処理を実行し、処理実行時間計測部１２２はそのときの参照処理に要した時間を計測する。他方、参照・更新処理部１１１は、処理する項目にインデックスが存在していなければ、インデックスを利用しない方法で参照処理を実行し、処理実行時間計測部１２２はそのときの参照処理に要した時間を計測する。ステップＳ１０８の実行後、次の処理を確認しに行く（１項目の処理は終了する）。

図３はステップＳ１０９の詳細なフローチャートである。以下、図３を参照して、ステップＳ１０９の詳細を説明する。

まず、インデックス生成部１２０のインデックス生成判断計算部１２４は、インデックス生成の可否を以下の判定式に基づいて決定する（Ｓ１１１）。
ｔ１＿ａｖｇ×ｎ≧ｔ２＿ａｖｇ×ｎ＋ａ …（１）

判定式１において、ｔ１＿ａｖｇは、インデックスが存在しない時の当該項目の処理時間の平均、即ちステップＳ１０８でインデックスを利用しないで当該項目に係る参照処理を行ったときの処理時間の平均を示す。ｔ２＿ａｖｇは、インデックスが存在する時の当該項目の処理時間の平均、即ちステップＳ１０８でインデックスを利用して当該項目に係る参照処理を行ったときの処理時間の平均を示す。ｔ１＿ａｖｇとｔ２＿ａｖｇの初期値は０である。また、ａは、当該項目のインデックスを生成するのに要した時間である。ａの初期値は０である。

インデックス生成判断計算部１２４は、判定式１により、インデックスが存在するときと存在しないときの処理時間を閾値ｎ回実行した時の時間で比較する。そして、インデックス生成判断計算部１２４は、ｔ１＿ａｖｇ×ｎがｔ２＿ａｖｇ×ｎ＋ａ以上であれば、インデックスを生成すると決定し、それ以外は生成しないと決定する。判定式１の全ての変数の初期値は０のため、インデックス生成判断計算部１２４は、初回は必ずインデックスを生成すると決定する。

インデックス生成判断計算部１２４は、インデックスを生成すると決定すると、値番号リストの値からインデックスを生成する（Ｓ１１３）。また、インデックス生成時間計測部１２３は、インデックス生成判断計算部１２４によるインデックスの生成開始から生成終了までの時間を計測する（Ｓ１１２、Ｓ１１４）。この計測時間は、インデックス生成時間ａとして使用される。

インデックス生成判断計算部１２４は、インデックスの生成では、値番号リストを１番目から確認し、値リストに値番号を紐付けていく。例えば、図５の顧客ＩＤでは、値番号リスト１番目は１のため値リストの１番目の値に紐付いたインデックスに１を追加する。２番目は２のため、値リストの２番目の値に紐付いたインデックスに２を追加する。これを繰り返し、最終的に図５のようになる。このインデックスは、わかり易くするためシーケンス上で示しているが、Ｂツリーインデックスでもハッシュインデックスでも構わない。

インデックス生成判断計算部１２４は、最後までインデックスを生成し終えたら、当該項目がインデックスを持っていることを示すためにインデックス存在フラグの値を１にする（Ｓ１１５）。

次に、判定式１で使用するｔ１＿ａｖｇ、ｔ２＿ａｖｇの計測方法について説明する。

図７に示すように、インデックスが存在しないとき、即ちインデックスフラグがｆａｌｓｅのとき、直前α―１回の参照処理平均時間の平均値がｔ１＿ａｖｇであり、α回目の参照時間がｔ＿ｃであるとする。このとき、最後のα回目の処理を含めた平均時間は、次式で計算する
新参照処理平均時間ｔ１＿ａｖｇ＝（ｔ１＿ａｖｇ×（α−１）＋ｔ＿ｃ）／α
…（２）

同様に、図７に示すように、インデックスが存在するとき、即ちインデックスフラグがｔｒｕｅのとき、直前β−１回の参照処理平均時間の平均値がｔ２＿ａｖｇであり、β回目の参照時間がｔ＿ｃであるとする。このとき、最後のβ回目の処理を含めた平均時間は、次式で計算する
新参照処理平均時間ｔ２＿ａｖｇ＝（ｔ２＿ａｖｇ×（β−１）＋ｔ＿ｃ）／β
…（３）

先述したように、アクセス回数αが閾値ｎを超えた場合、図６のステップＳ１０９、即ち図３のフローに入る。図３のステップＳ１１１の判定式１におけるｔ１＿ａｖｇ、ｔ２＿ａｖｇは、上記式２、３を用いて計算された値を使用する。ｔ１＿ａｖｇがｎ回の総和の値ではなく平均値を持つ理由は、ステップＳ１０９に入るタイミングが閾値ｎを超えた時点と更新処理直後の２パターンあるためである。ｔ１＿ａｖｇを保持し、必要時にｎ倍して計算することで、ステップＳ１０９のフローに入るタイミングが閾値ｎを越えた時以外にも対応できる。

また、上記判定式１は以下のように変形できる。
（ｔ１＿ａｖｇ−ｔ２＿ａｖｇ）×ｎ≧ａ …（１’）
このため、言い換えるとインデックス生成判断計算部１２４は、インデックスの生成時間が、インデックスがない時の１回の処理時間とインデックスが存在するときの１回の処理時間の差分の閾値倍より速い場合、インデックスを生成するように決定する、とも言える。したがって、上記判定式１は、インデックスによる効果が大きい項目はインデックスが自動生成され、効果が少ない項目は生成されない判定方法であると言える。

このように本実施形態によれば、クエリの処理効率の観点に基づいてインデックスの生成可否を決定することができる。

また、ＦＡＳＴ構造でデータを保持している場合、インデックス生成時間に時間がかかる。本実施形態では、インデックス生成に時間がかかるデータやシステムの場合、インデックスを生成しないため、インデックス生成によるタイムロスを最小限にできる。また、更新が入ったときインデックスが自動破棄されるため、古いデータを参照してしまう危険性を防ぐことができる。また、管理者が常時監視する必要がないため、人の目による確認による誤認識やチェック漏れを回避でき、さらに、人件費を削減可能である。

［第２の実施形態］
図８は本発明の第２の実施形態に係るデータベース管理装置２００のブロック図である。図８を参照すると、データベース管理装置２００は、図４に示したデータベース管理装置１００と比較して、インデックス生成部１２０がインデックスサイズ計測部１２５を備えていることと、インデックス生成判断計算部１２４の機能が図４に示すインデックス生成判断計算部１２４と異なっている点で、相違する。

インデックスサイズ計測部１２５は、インデックス格納部１４５に作成される項目（列）毎の最大インデックスサイズを計測し、保持する機能を有する。ここで、最大インデックスサイズは、インデックスの行の長さの最大値のことである。例えば、図５の顧客ＩＤにおけるインデックスの１行目には４個の値番号リストの番号「１、３、４、７」があり、２行目には２個の値番号リストの番号「２、５」があり、３行目には１個の値番号リストの番号「６」がある。従って、顧客ＩＤの最大インデックスサイズは４である。

インデックス生成判断計算部１２４は、最大インデックスサイズに基づいて、インデックスを生成するか否かを決定し、必要に応じてインデックスを生成する機能を有する。

次に本実施形態の動作を、第１の実施形態との相違点を中心に説明する。

データベース管理装置２００の動作は、データベース管理装置１００の動作と比較して、図６のステップＳ１０９の動作が相違する。図９は、データベース管理装置２００が図６のステップＳ１０９において実行する処理の詳細を示すフローチャートである。

まず、インデックス生成部１２０のインデックス生成判断計算部１２４は、当該項目の最大インデックスサイズに基づいて、当該項目のインデックスを生成するか否かを決定する（Ｓ２１０）。例えば、インデックス生成判断計算部１２４は、以下の判定式４に従って、インデックスの生成可否を決定する。
ＶｎｏＳｉｚｅ／２≧ｉｎｄｘｍａｘ …（４）

判定式４において、ｉｎｄｘｍａｘはインデックスサイズ計測部１２５が保持している当該項目の最大インデックスサイズである。また、ＶｎｏＳｉｚｅは、当該項目の値番号リストのサイズである。例えば、図５の顧客ＩＤの値番号リストのサイズは７である。上記判定式４は、最大インデックスサイズが値番号リストのサイズの半分以上であれば、インデックスを生成することを表している。最大インデックスサイズに基づいてインデックス生成の可否を決定する理由は、最大インデックスサイズがより大きなインデックスほど、インデックスを利用する効果が大きいため、削除後に速やかにインデックスを再生成することが望ましいためである。

インデックス生成判断計算部１２４は、判定式４に基づいてインデックスを生成すると決定した場合、ステップＳ２１２へ進み、インデックスを生成しないと決定した場合、ステップＳ２１１へ進む。ステップＳ２１１は、図３のステップＳ１１１と同じであり、インデックス生成判断計算部１２４は、先述の判定式１に基づいてインデックス生成の可否を決定する。そして、判定式１に基づいてインデックスを生成すると決定した場合、ステップＳ２１２へ進み、インデックスを生成しないと決定した場合、図９の処理を終える。

図９のステップＳ２１２、Ｓ２１４、Ｓ２１５は、図３のステップＳ１１２、Ｓ１１４、Ｓ１１５と同じである。図９のステップＳ２１３では、以下のようにして、サイズを計測しながら値番号リストの値からインデックスを生成する。

まず、インデックス生成判断計算部１２４は、当該項目の値番号リストの次の値を取得できる、すなわち最後の値ではないならば（Ｓ２２１でｙｅｓ）、値番号リストの値を取得し、該当する値番号に紐付いたインデックスに追加する（Ｓ２２２）。次に、インデックスサイズ計測部１２５は、初期値が０のインデックスサイズに１を加算する（Ｓ２２３）。次に、インデックスサイズ計測部１２５は、加算後のインデックスサイズと保持している最大インデックスサイズとを比較する（Ｓ２２４）。そして、インデックスサイズ計測部１２５は、保持している最大インデックスサイズより加算後のインデックスサイズが大きければ、保持している最大インデックスサイズを加算後のインデックスサイズに更新し（Ｓ２２５）、ステップＳ２２１の処理へ戻る。一方、インデックスサイズ計測部１２５は、保持している最大インデックスサイズより加算後のインデックスサイズが大きくなければ、ステップＳ２２５をスキップし、ステップＳ２２１の処理へ戻る。ステップＳ２２１において、当該項目の値番号リストの次の値を取得できない、すなわち最後の値まで処理し終えていれば（Ｓ２２１でｎｏ）、図９の処理を終了する。

このように本実施形態によれば、最大インデックスサイズに基づいて、インデックスの生成可否を決定する。そのため、最大インデックスサイズが大きなインデックスが更新処理に伴って削除されると、速やかに当該インデックスを生成でき、その結果、クエリの効率的な処理が可能になる。

［第３の実施形態］
図１０は本発明の第３の実施形態に係るデータベース管理装置３００のブロック図である。図１０を参照すると、データベース管理装置３００は、図４に示したデータベース管理装置１００と比較して、インデックス生成部１２０がインデックス削除部１２１の代わりにインデックス一部削除部１２６を備えている点で、相違する。

インデックス一部削除部１２６は、更新処理が行われた項目に係る最小の値番号リスト１４２の番号を参照・更新処理部１１１から取得して保持する機能と、その保持した番号に基づいてインデックス格納部１４５上と当該項目のインデックスの一部を削除する機能とを有する。

次に本実施形態の動作を、第１の実施形態との相違点を中心に説明する。

図１２はデータベース管理装置３００が実行する処理の一例を示すフローチャートである。図１２に示すステップのうち、ステップＳ３０１〜Ｓ３０２、Ｓ３０６〜Ｓ３１１は、図６に示すステップＳ１０１〜Ｓ１０２、Ｓ１０４〜Ｓ１０９と同じである。

図１２を参照すると、データベース管理装置３００の参照・更新処理部１１１は、クライアント装置１０１から受信したクエリが更新クエリならば、更新クエリに従ってデータベース１４０に対する更新処理を実行する（Ｓ３０２）。次に、インデックス一部削除部１２６は、更新処理が行われた項目に係る最小の値番号リスト１４２の番号を参照・更新処理部１１１から取得して保持する（Ｓ３０３）。次に、インデックス一部削除部１２６は、当該項目のインデックスの一部を削除する（Ｓ３０４）。ここで、インデックスの一部削除は、物理的にインデックスの一部を削除してもよいし、論理的にインデックスの一部を削除してもよい。論理的にインデックスを削除する方法として、通常の処理では絶対に使わない特定の値（例えば−１）で、削除部分のインデックスを書き換える方法がある。

図１１は、インデックスの一部を論理的に削除する方法の説明図である。参照・更新処理部１１１が図１１（Ａ）に示すように、顧客ＩＤに係る値番号リストの４番目を１から２に更新したとする（Ｓ３０２）。この更新によって、顧客ＩＤのインデックスは一部が不正なものとなる。そこで、インデックス一部削除部１２６は、更新処理が行われた項目に係る最小の値番号リスト１４２の番号「４」を取得し（Ｓ３０３）、値リストに紐付いたインデックスの各行を先頭から順に調べ、上記最小の値番号リストの番号「４」以上の値を発見すると、その発見した値を「−１」に書き換える（Ｓ３０４）。これにより、図１１（Ａ）に示すインデックスの丸い印を付けた箇所が、図１１（Ｂ）に示すように「−１」に更新される。この「−１」は、それ以降のインデックスは削除されていることを示している。その後、インデックス一部削除部１２６は、図６のステップＳ１０３における場合と同様に、該当項目のアクセス数を初期化し、インデックス存在フラグをｆａｌｓｅにし、更新処理事項フラグを１にセットする（Ｓ３０５）。そして、図１２の処理を終える。

参照・更新処理部１１１は、インデックスの利用時、−１が出現するまではインデックスを利用し、−１が出現した後は、インデックスを利用せずに処理を進める。例えば、参照・更新処理部１１１は、図１１（Ｂ）において、顧客ＩＤが「１０２」であるレコードを検索する場合、値リストの「１０２」に紐付いたインデックスから「２」を取得し、その直後に「−１」が存在するので、インデックスをそれ以上は利用しない。代わりに、参照・更新処理部１１１は、最小の値番号リストの番号「４」から、値番号リストをシーケンシャルに検索し、「５」を取得する。

このように本実施形態によれば、更新処理に伴うインデックスの削除を一部分に限定することにより、インデックスの一部を利用可能にするため、参照処理時の値番号リストに対するシーケンシャル処理領域を減らすことができる。その結果、インデックスが再生成されるまでの参照処理時間を短縮することができる。

以上は、更新処理時に既に値リストに存在する値に値番号リストを更新する例を示したが、インデックスの一部削除を適用できる形態は上述した例に限定されず、値リストや値番号リストが更新時に再生成しないで済む方法や構造を採用している場合にも適用可能である。例えば、本発明に関連する技術として、表形式データを列ごとの成分に分解した値リストおよび値番号リストに変換する際に、値リストを構成する各データの間に空き領域を形成して、当該値リストおよび値番号リストに変換し、そして、値リストを構成する各データ間に他のデータを挿入する際に、当該各データ間に形成された空き領域に当該他のデータを挿入する技術が知られている（例えば特許文献３参照）。この関連技術によれば、値リストの更新が値リストの空き領域にデータを挿入するものであれば、値リストおよび値番号リストの作り変えは不要であり、インデックスの一部削除を適用可能である。

［第４の実施形態］
図１３を参照すると、本発明の第４の実施形態に係るデータベース管理装置４００は、データおよびインデックスをカラム単位で格納するデータベース４１０に接続され、クライアント４２０からのクエリを受け付けてデータベース４１０に対するクエリ実行結果をクライアント４２０に返却する装置である。データベース管理装置４００は、処理時間計測部４３０と生成可否決定部４４０とを有する。

処理時間計測部４３０は、インデックスを利用する場合のクエリの処理時間である第１の処理時間と、インデックスを利用しない場合のクエリの処理時間である第２の処理時間とを計測する機能を有する。

生成可否決定部４４０は、インデックスが削除された後に計測された第２の処理時間とインデックスが削除される前に計測された第１の処理時間とに基づいて、インデックスが削除された後、インデックスを生成するか否かを決定する機能を有する。

このように構成されたデータベース管理装置４００は、以下のように動作する。即ち、データベース管理装置４００は、まず、処理時間計測部４３０により、インデックスを利用する場合のクエリの処理時間である第１の処理時間と、インデックスを利用しない場合のクエリの処理時間である第２の処理時間とを計測する。次に、データベース管理装置４００は、生成可否決定部４４０により、インデックスが削除された後に計測された第２の処理時間とインデックスが削除される前に計測された第１の処理時間とに基づいて、インデックスが削除された後、インデックスを生成するか否かを決定する。

このように本実施形態によれば、クエリの処理効率の観点に基づいてインデックスの生成可否を決定することができる。

その理由は、データベース管理装置４００は、インデックスが削除された後に計測された第２の処理時間とインデックスが削除される前に計測された第１の処理時間とに基づいて、インデックスが削除された後、インデックスを生成するか否かを決定するためである。

以上、本発明を幾つかの実施形態を挙げて説明したが、本発明は以上の実施形態にのみ限定されず、本発明の範囲内において各種の付加変更が可能である。

データおよびインデックスをカラム単位で格納するＦＡＳＴ構造などのデータベースに接続され、クライアントからのクエリを受け付けてデータベースに対するクエリ実行結果をクライアントに返却するデータベース管理装置に利用できる。

１００…データベース管理装置
１０１…クライアント装置
１１０…処理実行部
１１１…参照・更新処理部
１２０…インデックス生成部
１２１…インデックス削除部
１２２…処理実行時間計測部
１２３…インデックス生成時間計測部
１２４…インデックス生成判断計算部
１２５…インデックスサイズ計測部
１２６…インデックス一部削除部
１３０…データ管理部
１４０…データベース
１４１…値リスト
１４２…値番号リスト
１４３…値リスト番号管理部
１４４…実の値格納部
１４５…インデックス格納部
１４６…値番号リスト管理部
１４７…値番号処理部
１５０…アクセス数カウント処理部
２００…データベース管理装置
３００…データベース管理装置
４００…データベース管理装置
４１０…データベース
４２０…クライアント
４３０…処理時間計測部
４４０…生成可否決定部

Claims (10)

1. データおよびインデックスをカラム単位で格納するデータベースに接続され、クライアントからのクエリを受け付けて前記データベースに対するクエリ実行結果を前記クライアントに返却するデータベース管理装置であって、
   前記インデックスを利用する場合の前記クエリの処理時間である第１の処理時間と前記インデックスを利用しない場合の前記クエリの処理時間である第２の処理時間とを計測する処理時間計測部と、
   前記インデックスが削除された後に計測された前記第２の処理時間と前記インデックスが削除される前に計測された前記第１の処理時間とに基づいて、前記インデックスが削除された後、前記インデックスを生成するか否かを決定する生成可否決定部と、
   を有するデータベース管理装置。
2. 前記インデックスの生成に要するインデックス生成時間を計測する生成時間計測部を有し、
   前記生成可否決定部は、前記第１の処理時間と前記第２の処理時間と前記インデックス生成時間とに基づいて、前記生成の可否を決定するように構成されている、
   請求項１に記載のデータベース管理装置。
3. 前記生成可否決定部は、前記インデックスが削除された後に計測された前記第２の処理時間の平均値をｔ１＿ａｖｇ、前記インデックスが削除される前に計測された前記第１の処理時間の平均値をｔ２＿ａｖｇ、前記インデックス生成時間をａ、予め設定された閾値をｎとするとき、ｔ１＿ａｖｇ×ｎ≧ｔ２＿ａｖｇ×ｎ＋ａが成立するか否かによって、前記インデックスを生成するか否かを決定するように構成されている、
   請求項２に記載のデータベース管理装置。
4. 前記クエリの処理中における前記データへの参照アクセス回数を計測するアクセス数計測部を有し、
   前記生成可否決定部は、前記インデックスの削除後に前記参照アクセス回数が予め定められた回数を超えた場合、前記データへの参照アクセスが行われる毎に、前記決定を行うように構成されている、
   請求項１乃至３の何れかに記載のデータベース管理装置。
5. 前記インデックスの行の長さの最大値を最大インデックスサイズとして計測するサイズ計測部を有し、
   前記生成可否決定部は、前記最大インデックスサイズに基づいて、前記インデックスが削除された後、前記インデックスを生成するか否かを決定するように構成されている、
   請求項１乃至４の何れかに記載のデータベース管理装置。
6. 前記インデックスの削除は、前記インデックスの全てを利用できない状態とすることである、
   請求項１乃至５の何れかに記載のデータベース管理装置。
7. 前記インデックスの削除は、前記インデックスの一部を利用できない状態とすることである、
   請求項１乃至５の何れかに記載のデータベース管理装置。
8. 前記データベースは、各カラムに関連する項目値を含むレコードの配列として表される表形式データに対応するデータ構造であって、前記カラムごとに、前記項目値を一意に特定する項目値番号に対応して当該カラムにおける項目値がソート状態で格納されている値リストと、前記レコードの順番に前記項目値番号を指定する情報が格納されている値番号配列とを含むデータ構造を有する、
   請求項１乃至７の何れかに記載のデータベース管理装置。
9. データおよびインデックスをカラム単位で格納するデータベースに接続され、クライアントからのクエリを受け付けて前記データベースに対するクエリ実行結果を前記クライアントに返却するデータベース管理装置が実行するインデックス生成制御方法であって、
   前記インデックスを利用する場合の前記クエリの処理時間である第１の処理時間と前記インデックスを利用しない場合の前記クエリの処理時間である第２の処理時間とを計測し、
   前記インデックスが削除された後に計測された前記第２の処理時間と前記インデックスが削除される前に計測された前記第１の処理時間とに基づいて、前記インデックスが削除された後、前記インデックスを生成するか否かを決定する、
   インデックス生成制御方法。
10. データおよびインデックスをカラム単位で格納するデータベースに接続され、クライアントからのクエリを受け付けて前記データベースに対するクエリ実行結果を前記クライアントに返却するコンピュータを、
    前記インデックスを利用する場合の前記クエリの処理時間である第１の処理時間と前記インデックスを利用しない場合の前記クエリの処理時間である第２の処理時間とを計測する処理時間計測部と、
    前記インデックスが削除された後に計測された前記第２の処理時間と前記インデックスが削除される前に計測された前記第１の処理時間とに基づいて、前記インデックスが削除された後、前記インデックスを生成するか否かを決定する生成可否決定部と、
    して機能させるためのプログラム。

Images