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

Description

本発明は、インデックスを有するデータベースのデータベース管理方法、プログラム、および情報処理装置に関する。

コンピュータシステムで取り扱うデータの多くは、データベース（ＤＢ）で管理される。ＤＢに格納されるデータ量の増加に伴い、データの検索に要する時間も長期化する。例えば、全データを走査して検索条件に合致するデータを抽出する場合、Ｏ記法でＯ（Ｎ）の計算時間がかかる（Ｎは、データ数であり１以上の整数）。そこで、ＤＢの検索の効率化のために、例えばＤＢに格納されたデータの索引データ（インデックス）が作成される。インデックスを作っておくことで、計算時間をＯ（ｌｏｇＮ）程度にすることができる。

インデックスには、例えばＤＢ内の各データのキーとなる値（インデックス値）と、そのデータの位置情報とが対応付けて登録される。インデックスを有するＤＢを検索する場合、検索キーに対応するインデックス値が、インデックスから検索される。そして該当するキーに対応付けられたデータの位置情報に基づいて、そのデータが取得され、検索結果として出力される。

このようなインデックスを有するＤＢでは、ＤＢ内のデータを更新した場合、インデックスを更新することで、検索時に、更新後のデータを迅速に見つけ出すことが可能となる。そこで、インデックスの生成及び削除を自動的に行うことができるインデックスの自動更新装置が考えられている。この装置は、検索すべきデータについての各属性に対するアクセス毎に、該当する属性のアクセス頻度情報を更新し、このアクセス頻度情報に基づいてインデックスの内容を更新すべきか否かを評価すると共に、該評価結果に基づいてインデックスの内容を更新する。

特開平６−２１５０３７号公報

インデックスは、高速な検索が可能となるように、例えば木構造に構造化されている。そのため、インデックスの更新処理では、インデックス値の追加、変更、削除に加え、インデックスのデータ構造の再構築が行われる。このようなインデックスのデータ構造の再構築を、ＤＢのデータ更新のたびに行っていると、システム全体の処理負荷が過大となってしまう。そこで、例えば、レコード更新時にはインデックスを更新せず、次回の検索時にインデックスの更新処理を行なうことが考えられる。このようにすれば、インデックス更新が頻繁に発生することを抑止でき、システム全体の処理の効率化が図れる。

しかし、検索時にインデックスの更新を行う場合、検索要求に対する応答時間が、インデックス未更新のレコードの量に左右され、検索時の応答時間にばらつきが生じてしまう。例えば、普段より大量のデータ更新が行われた後に入力された検索要求については、それ以外の検索要求と比べて、検索要求に対する応答時間が極端に遅くなる。

１つの側面では、本発明は、検索要求に対する応答時間のばらつきを抑止したデータベース管理方法、プログラム、および情報処理装置を提供することを目的とする。

１つの案では、情報処理装置が、インデックスを有するデータベースのデータが更新された場合、所定の確率で前記インデックスの更新処理が実行されるように、前記インデックスの更新処理を実行するか否かを決定し、前記インデックスの更新処理を実行すると決定した場合、インデックス更新要求を出力する、データベース管理方法が提供される。

１態様によれば、検索要求に対する応答時間のばらつきが抑止される。
本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。

第１の実施の形態に係る装置の機能構成の一例を示す図である。 第１の実施の形態におけるデータ更新処理手順の一例を示すフローチャートである。 第１の実施の形態におけるデータ検索処理手順の一例を示すフローチャートである。 第１の実施の形態におけるインデックス未反映の更新履歴数の推移の一例を示す図である。 第２の実施の形態のシステム構成例を示す図である。 第２の実施の形態に用いるＷｅｂサーバのハードウェアの一構成例を示す図である。 第２の実施の形態に係る各サーバの機能を示すブロック図である。 データ保管部のデータ構造の一例を示す図である。 インデックス保管部のデータ構造の一例を示す図である。 データ更新履歴保管部のデータ構造の一例を示す図である。 データ更新処理手順の一例を示すシーケンス図である。 データ検索時の処理の手順を示すシーケンス図である。 インデックスへ未反映の更新履歴数の推移の一例を示す図である。 第３の実施の形態のシステム構成例を示す図である。 第３の実施の形態に係る各サーバの機能を示すブロック図である。 更新確率定義記憶部のデータ構造の一例を示す図である。 第３の実施の形態におけるデータ更新処理の手順の一例を示すシーケンス図である。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず第１の実施の形態について説明する。第１の実施の形態は、インデックスを有するデータベースのデータが更新された場合に、所定の確率でインデックスの更新処理が実行されるようにしたものである。

例えばインデックス更新方法として、いわば働き者（Eager）と呼ぶことができる第１の方法と、いわば怠け者（Lazy）と呼ぶことができる第２の方法が考えられる。
第１の方法は、データ更新（追加・更新・削除）が行われたときに、インデックスの更新を行う方法である。この方法では、検索処理の応答時間は安定する一方で、データ更新に時間がかかる。しかもデータベースに大量のデータが短時間に登録されると、システム全体の性能が劣化してしまう。

第２の方法は、データ更新時にはインデックスを更新せず、データ検索要求が入力された場合に、データ検索に先立ってインデックスを更新する。この方法では、データ更新を効率よく実行できる一方で、データ検索時の性能にばらつきが生じる。特に、大量のデータ更新が行われた直後のデータ検索に非常に時間がかかる。

第１の実施の形態では、データ検索要求が入力された場合にインデックスを更新すると共に、データ更新時に所定の確率（例えば１／数十〜１／数百の確率）でインデックスを更新する。これにより、データ更新を効率よく実行しながら、データ検索時の性能のばらつきを抑止可能となる。

すなわち第１の実施の形態ではデータ更新時に常にインデックスを更新するわけではないため、第１の方法のようにデータ更新の度にインデックス更新を実行する場合に比べ処理効率が向上する。また第１の実施の形態では、データ更新時にも所定の確率でインデックスを更新するため、短時間で大量のデータ更新があっても、第２の方法よりもデータ検索時の性能のばらつきが抑止される。例えば第２の方法では、１００万件のデータ更新後の検索には１００万件分のインデックス値の更新が必要になりサービス停止を含む重大な影響が出てしまう。他方、第１の実施の形態では、データ更新時に数十から数百回に一度インデックスの更新処理が実行されるため、検索時のインデックス更新は数十から数百件程度で済み、サービス停止などの悪影響の発生が抑止される。

図１は、第１の実施の形態に係る装置の機能構成の一例を示す図である。データベース（ＤＢ）１ａを有する情報処理装置１には端末装置２が接続されている。情報処理装置１は、端末装置２から指示に応じて、ＤＢ１ａのデータの更新やデータの検索を行う。

情報処理装置１は、データベース（ＤＢ）１ａ、更新履歴記憶手段１ｂ、データ更新手段１ｃ、決定手段１ｄ、出力手段１ｅ、インデックス更新手段１ｆ、および検索手段１ｇを有する。

ＤＢ１ａは、複数のデータ１ｈとインデックス１ｉとを有する。インデックス１ｉには、複数のデータ１ｈそれぞれから抽出したキー情報（インデックス値）が、そのキー情報の抽出元となったデータの識別情報（例えばデータへのポインタ）に対応付けて登録されている。

更新履歴記憶手段１ｂは、前回のインデックス１ｉの更新処理の後に行われたデータ更新の更新履歴を記憶する。更新履歴には、例えば更新されたデータの識別情報と更新内容（追加・削除）との組が設定される。

データ更新手段１ｃは、ＤＢ１ａに格納されたデータを更新する。例えばデータ更新手段１ｃは、ＤＢ１ａへの新たなデータの追加、データの削除、データの変更を行う。データ更新手段１ｃは、例えばデータを更新した場合、更新したデータの識別情報と更新内容との組を、更新履歴として更新履歴記憶手段１ｂに格納する。

決定手段１ｄは、インデックス１ｉを有するＤＢ１ａのデータが更新された場合、所定の確率でインデックス１ｉの更新処理が実行されるように、インデックス１ｉの更新処理を実行するか否かを決定する。例えば決定手段１ｄは、インデックス１ｉの前回の更新処理の後にＤＢ１ａのデータが更新された回数をカウントし、カウントした回数が、所定の確率に応じた所定の値（閾値）に達した場合、インデックス１ｉの更新処理を実行すると決定する。また決定手段１ｄは、乱数を生成し、乱数の値が、所定の確率に応じた所定の範囲内であれば、インデックスの更新処理を実行すると決定するようにしてもよい。

出力手段１ｅは、インデックス１ｉの更新処理を実行すると決定した場合、インデックス更新手段１ｆに対してインデックス更新要求を出力する。
インデックス更新手段１ｆは、インデックス更新要求に応じて、インデックス１ｉを更新する。例えばインデックス更新手段１ｆは、インデックス１ｉの前回の更新処理の後に実行されたＤＢ１ａのデータの更新処理を示す更新履歴を、更新履歴記憶手段１ｂから取得する。そしてインデックス更新手段１ｆは、取得した更新履歴に基づいて、インデックス１ｉを更新する。例えばインデックス更新手段１ｆは、データの追加を示す更新履歴に応じて、インデックス１ｉに、追加されたデータのインデックス値を追加する。またインデックス更新手段１ｆは、データの削除を示す更新履歴に応じて、インデックス１ｉから削除されたデータのインデックス値を削除する。その後、インデックス更新手段１ｆは、例えば、インデックス１ｉ内のインデックス値のソートや、データ構造の再作成を行う。

検索手段１ｇは、端末装置２からのデータ検索指示に応じて、ＤＢ１ａからデータを検索する。なお検索手段１ｇは、データ検索の実行に先立って、インデックス更新手段１ｆに対してインデックス更新要求を出力する。そして検索手段１ｇは、インデックス更新手段１ｆによってインデックスが最新の状態に更新された後、ＤＢ１ａの検索を行う。例えば検索手段１ｇは、データ検索要求で示される検索キーに適合するインデックス値を、インデックス１ｉから検索する。次に検索手段１ｇは、該当するインデックス値に対応付けられたデータの識別情報に基づいて、その識別情報で示されるデータをＤＢ１ａから抽出する。そして検索手段１ｇは、抽出したデータを、検索結果として端末装置２に送信する。

なお、データ更新手段１ｃ、決定手段１ｄ、出力手段１ｅ、インデックス更新手段１ｆ、および検索手段１ｇは、情報処理装置１が有するＣＰＵ（Central Processing Unit）により実現することができる。また、ＤＢ１ａと更新履歴記憶手段１ｂとは、情報処理装置１が有するＲＡＭ（Random Access Memory）やハードディスクドライブ（ＨＤＤ:Hard Disk Drive）などにより実現することができる。

また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
次に、情報処理装置１におけるデータ更新処理とデータ検索処理とについて、図２，図３を参照して説明する。なお以下の例では、インデックス更新後のデータ更新回数を示すカウンタを用いて、インデックス更新処理を実行するか否かを判断するものとする。

図２は、第１の実施の形態におけるデータ更新処理手順の一例を示すフローチャートである。以下、図２に示す処理をステップ番号に沿って説明する。
［ステップＳ１１］データ更新手段１ｃは、端末装置２からのデータ更新指示を受け付ける。

［ステップＳ１２］データ更新手段１ｃは、データ更新指示に応じて、ＤＢ１ａ内のデータを更新する。
［ステップＳ１３］データ更新手段１ｃは、更新履歴記憶手段１ｂにデータの更新履歴を格納する。その後、データ更新手段１ｃは、決定手段１ｄに、データ更新を行ったことを通知する。

［ステップＳ１４］決定手段１ｄは、データ更新の回数を示すカウンタに１を加算する。なお、カウンタの初期値は０である。
［ステップＳ１５］決定手段１ｄは、カウンタの値が閾値に達したか否かを判断する。なお閾値は、インデックス１ｉの更新処理を実行する確率に応じて予め定義されている。例えば、データが更新された際に１／１００の確率でインデックスを更新する場合、閾値として１００が設定される。決定手段１ｄは、カウンタの値が閾値に達した場合、インデックスの更新処理を実行するものと決定し、処理をステップＳ１６に進める。また決定手段１ｄは、カウンタの値が閾値に達していなければ、処理を終了する。

［ステップＳ１６］出力手段１ｅは、インデックス更新手段１ｆに対してインデックス更新要求を出力する。するとインデックス更新手段１ｆは、更新履歴記憶手段１ｂに蓄積されている更新履歴に基づいて、インデックス１ｉを更新する。

［ステップＳ１７］インデックス更新手段１ｆは、更新履歴記憶手段１ｂ内の更新履歴をクリアする。
［ステップＳ１８］インデックス更新手段１ｆは、決定手段１ｄにインデックスを更新したことを通知する。すると決定手段１ｄは、カウンタに０を代入する。その後、処理が終了する。

図３は、第１の実施の形態におけるデータ検索処理手順の一例を示すフローチャートである。以下、図３に示す処理をステップ番号に沿って説明する。
［ステップＳ２１］検索手段１ｇは、端末装置２からのデータ検索指示を受け付ける。

［ステップＳ２２］検索手段１ｇは、更新履歴記憶手段１ｂにデータの更新履歴があるか否かを判断する。検索手段１ｇは、更新履歴がある場合、処理をステップＳ２３に進める。また検索手段１ｇは、更新履歴がない場合、処理をステップＳ２６に進める。

［ステップＳ２３］検索手段１ｇは、インデックス更新手段１ｆに対してインデックス更新要求を出力する。するとインデックス更新手段１ｆは、更新履歴記憶手段１ｂに蓄積されている更新履歴に基づいて、インデックス１ｉを更新する。

［ステップＳ２４］インデックス更新手段１ｆは、更新履歴記憶手段１ｂ内の更新履歴をクリアする。
［ステップＳ２５］インデックス更新手段１ｆは、決定手段１ｄと検索手段１ｇとに、インデックスを更新したことを通知する。すると決定手段１ｄは、カウンタに０を代入する。

［ステップＳ２６］検索手段１ｇは、インデックスが更新されたことを確認後、ＤＢ１ａに対して、データ検索指示に応じたデータ検索を行う。
［ステップＳ２７］検索手段１ｇは、検索結果を端末装置２に応答する。

このようにして、データ更新時において所定の確率でインデックスが更新されると共に、データ検索時にインデックスが更新される。
図４は、第１の実施の形態におけるインデックス未反映の更新履歴数の推移の一例を示す図である。図４では、横軸に時間、縦軸にインデックスへ未反映の更新履歴数を示している。図４の例では、データ更新時にインデックス更新処理を行う確率は０．０１（１％）であるものとする。この場合、決定手段１ｄには、閾値として「１００」が設定される。

インデックスへ未反映の更新履歴数は、決定手段１ｄで、インデックス１ｉの更新処理を実行すると決定されたときと、データ検索指示を受信したときとに０になる。それ以外の期間は、インデックスへ未反映の更新履歴数は、データ更新指示を受信するごとに１ずつ増加する。

図４の例では、カウンタの値が１００となったときに、インデックス更新要求が出力され、インデックスが更新されている。これにより、インデックスへ未反映の更新履歴数は、最大でも１００となる。これは、前回にデータ検索指示から今回のデータ検索指示までの間に、例えば数万件のデータ更新が行われたとしても、データ検索時においてインデックスに反映させる更新履歴数が最大でも１００であることを意味する。

このように、データ更新の際に確率的にインデックスの更新処理を実行するので、検索要求を受ける時点で、未更新のインデックス値が大量に残存することが抑止される。そのため、インデックス値の大量更新に起因して、検索要求に対する応答時間の長期化する事態の発生が抑止される。すなわち、検索要求に対する応答時間のばらつきが抑止される。

なお図１の例では、情報処理装置１内にＤＢ１ａが設けられているが、ＤＢ１ａは、情報処理装置１に対してネットワークで接続された他の装置に設けられていてもよい。その場合、更新履歴記憶手段１ｂ、データ更新手段１ｃ、インデックス更新手段１ｆ、または検索手段１ｇの機能の一部または全部を、ＤＢ１ａが設けられた他の装置内に設けることもできる。

〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、複数のＷｅｂサーバから、ＤＢサーバ内のＤＢを利用するシステムにおいて、複数のＷｅｂサーバからの指示により、ＤＢのインデックスの適切な更新を行うものである。

複数のＷｅｂサーバがインデックスの更新を指示するシステムでは、第１の実施の形態のように、データの更新回数をカウンタで計数するには、個々のＷｅｂサーバが、他のＷｅｂサーバからＤＢ内のデータの更新を何回行ったのかを把握する必要が生じる。それにはＷｅｂサーバ間で情報をリアルタイムに共有する機能が必要となり、処理が複雑化すると共に処理負荷も増大する。そこで、第２の実施の形態では、インデックスの更新処理を実行するか否かを、各Ｗｅｂサーバが乱数を用いて確率的に決定する。これにより、Ｗｅｂサーバが他のＷｅｂサーバからのデータ更新回数を把握せずに、適切な頻度で、ＤＢサーバに対してインデックス更新要求を出すことができる。その結果、複数のＷｅｂサーバを用いた並列処理の処理効率が向上し、大規模システムにおける処理効率が向上する。

図５は、第２の実施の形態のシステム構成例を示す図である。複数のＷｅｂサーバ１００，１００ａ，１００ｂ，・・・は、スイッチ装置３４を介してＤＢサーバ２００に接続されている。ＤＢサーバ２００は、インデックスでレコードが管理されたＤＢを有している。

またＷｅｂサーバ１００，１００ａ，１００ｂ，・・・は、スイッチ装置３３を介してロードバランサ３２に接続されている。ロードバランサ３２には、ネットワーク３１を介して複数の端末装置２１，２２，２３，・・・が接続されている。端末装置２１，２２，２３，・・・は、ＤＢサーバ２００内のＤＢを利用するユーザが使用するコンピュータである。ロードバランサ３２は、端末装置２１，２２，２３，・・・からの要求を、複数のＷｅｂサーバ１００，１００ａ，１００ｂ，・・・のうちの１台に振り分ける。その際、ロードバランサ３２は、例えばＷｅｂサーバ１００，１００ａ，１００ｂ，・・・それぞれの負荷が均等になるように、要求の振り分け先を決定する。

Ｗｅｂサーバ１００，１００ａ，１００ｂ，・・・は、端末装置２１，２２，２３，・・・からの要求に応じて処理を実行する。例えばＷｅｂサーバ１００，１００ａ，１００ｂ，・・・は、ＤＢサーバ２００で管理されているデータの操作要求を受信した場合、ＤＢサーバ２００に対してＤＢのレコードの更新、または検索などの指示を行う。

第２の実施の形態では、Ｗｅｂサーバ１００，１００ａ，１００ｂ，・・・は、ＤＢサーバ２００のレコードの更新を行う場合、インデックスの更新の要否を決定する。インデックスの更新処理を実行するか否かの決定は、乱数による確率的な判断によって行われる。例えばＷｅｂサーバ１００，１００ａ，１００ｂ，・・・は、インデックスの更新処理を実行するか否かの決定のために、乱数を使った「くじ引き」機構を用意する。この「くじ引き」機構では、特定の確率（例えば１％または５％）で当たりが出て、その他の場合ははずれとなる。そしてＷｅｂサーバ１００，１００ａ，１００ｂ，・・・は、更新時に「くじ引き」を行い、当たりがでたら、ＤＢサーバ２００にインデックス更新要求を送信する。一方、ＤＢサーバ２００は、インデックス更新要求またはデータ検索要求を受信したときにインデックスを更新する。

図６は、第２の実施の形態に用いるＷｅｂサーバのハードウェアの一構成例を示す図である。Ｗｅｂサーバ１００は、ＣＰＵ１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０９を介してＲＡＭ１０２と複数の周辺機器が接続されている。なおＷｅｂサーバ１００が有するＣＰＵ数は１つに限定されず、複数であってもよい。Ｗｅｂサーバ１００が複数のＣＰＵを有する場合、複数のＣＰＵが連係動作し、装置全体を制御する。

ＲＡＭ１０２は、Ｗｅｂサーバ１００の主記憶装置として使用される。ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。

バス１０９に接続されている周辺機器としては、ＨＤＤ１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８ａ，１０８ｂがある。

ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、Ｗｅｂサーバ１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、フラッシュメモリなどの半導体記憶装置を使用することもできる。

グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。モニタ１１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号をＣＰＵ１０１に送信する。なお、マウス１３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク１４に記録されたデータの読み取りを行う。光ディスク１４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク１４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、Ｗｅｂサーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置１５やメモリリーダライタ１６を接続することができる。メモリ装置１５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ１６は、メモリカード１７へのデータの書き込み、またはメモリカード１７からのデータの読み出しを行う装置である。メモリカード１７は、カード型の記録媒体である。

ネットワークインタフェース１０８ａは、スイッチ装置３３に接続されている。ネットワークインタフェース１０８ａは、スイッチ装置３３を介して、ロードバランサ３２との間でデータの送受信を行う。

ネットワークインタフェース１０８ｂは、スイッチ装置３４に接続されている。ネットワークインタフェース１０８ｂは、スイッチ装置３４を介して、ＤＢサーバ２００との間でデータの送受信を行う。

以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。なお図６には、Ｗｅｂサーバ１００のハードウェア構成例を示したが、他のＷｅｂサーバ１００ａ，１００ｂ，・・・、ＤＢサーバ２００、ロードバランサ３２、および端末装置２１，２２，２３，・・・も同様のハードウェアで実現することができる。また、第１の実施の形態に示した情報処理装置１も、図６に示したＷｅｂサーバ１００と同様のハードウェアにより実現することができる。

Ｗｅｂサーバ１００は、コンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。Ｗｅｂサーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、Ｗｅｂサーバ１００に実行させるプログラムをＨＤＤ１０３に格納しておくことができる。ＣＰＵ１０１は、ＨＤＤ１０３内のプログラムの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。またＷｅｂサーバ１００に実行させるプログラムを、光ディスク１４、メモリ装置１５、メモリカード１７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばＣＰＵ１０１からの制御により、ＨＤＤ１０３にインストールされた後、実行可能となる。またＣＰＵ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。なおプログラムを記録する記録媒体には、一時的な伝搬信号自体は含まれない。

プログラムを流通させる場合には、例えば、そのプログラムが記録された光ディスク１４、メモリ装置１５、メモリカード１７などの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、他のサーバコンピュータからＷｅｂサーバ１００にそのプログラムを転送することもできる。Ｗｅｂサーバ１００は、ネットワークを介してプログラムを取得する場合、例えば取得したプログラムをＨＤＤ１０３に格納する。そしてＷｅｂサーバ１００のＣＰＵ１０１がＨＤＤ１０３内のプログラムを実行する。またＷｅｂサーバ１００のＣＰＵ１０１は、サーバコンピュータからプログラムの一部が転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

次に、第２の実施の形態におけるインデックス更新に関連する各サーバの機能について説明する。
図７は、第２の実施の形態に係る各サーバの機能を示すブロック図である。Ｗｅｂサーバ１００は、データ操作受付部１１０とインデックス更新決定部１２０とを有する。

データ操作受付部１１０は、端末装置２１，２２，２３，・・・からのＤＢサーバ２００内のＤＢに対するデータ操作指示を受け付ける。データ操作指示には、データ更新指示やデータ検索指示などがある。データ更新指示には、データの追加要求、削除要求、変更要求がある。データ操作受付部１１０は、データ更新指示を受け付けた場合、ＤＢサーバ２００に対してデータ更新要求を送信すると共に、インデックス更新決定部１２０にデータ更新通知を送信する。またデータ操作受付部１１０は、データ検索指示を受け付けた場合、ＤＢサーバ２００に対して、検索キーを含む検索要求を送信する。

インデックス更新決定部１２０は、データ操作受付部１１０からのデータ更新通知を受け取ると、インデックス更新処理の実行の要否を判断する。第２の実施の形態では、インデックス更新決定部１２０は、所定の確率で更新処理を実行すると決定する。例えばインデックス更新決定部１２０は、乱数を生成する。そしてインデックス更新決定部１２０は、乱数として生成可能な全数値のうちの、所定の割合の数値に属する乱数が生成された場合、インデックス更新処理を実行すると決定する。インデックス更新処理を実行する確率が例えば０．０１（１％）であれば、インデックス更新決定部１２０は、０〜９９の範囲内で乱数を生成する。生成される乱数は一様乱数であり、「０〜９９」の各数値が生成される確率は同じである。

そしてインデックス更新決定部１２０は、０〜９９の範囲内の特定の数値（例えば「０」）が生成された場合、インデックス更新処理を実行すると決定する。またインデックス更新決定部１２０は、特定の数値以外の数値（例えば「１〜９９」）が生成された場合、インデックス更新処理を実行しないと決定する。

インデックス更新決定部１２０は、インデックスを更新すると決定した場合、ＤＢサーバ２００に対して、インデックス更新要求を送信する。
なお図７には、代表的にＷｅｂサーバ１００の機能を示しているが、他のＷｅｂサーバ１００ａ，１００ｂ，・・・も同様の機能を有している。

ＤＢサーバ２００は、データ保管部２１０、インデックス保管部２２０、データ更新履歴保管部２３０、アクセス管理部２４０、およびインデックス操作部２５０を有する。
データ保管部２１０は、管理対象のデータを記憶する。例えばＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部がデータ保管部２１０として使用される。

インデックス保管部２２０は、データ保管部２１０に格納されたデータのインデックスを記憶する。例えばＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部がインデックス保管部２２０として使用される。

データ更新履歴保管部２３０は、データの更新履歴を記憶する。例えばＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部が、データ更新履歴保管部２３０として使用される。なお、データ更新履歴保管部２３０内のデータの更新履歴は、データ変更内容がインデックスに反映されたときにクリアされる。

アクセス管理部２４０は、Ｗｅｂサーバ１００，１００ａ，１００ｂ，・・・から送られたデータ更新要求または検索要求に応じて処理を実行する。例えばアクセス管理部２４０は、データ更新要求を受信した場合、データ保管部２１０に格納されているデータの更新操作を行う。アクセス管理部２４０は、データ更新要求で、データの追加が指示されている場合、新たなデータＩＤを生成し、生成したデータＩＤを付与したデータをデータ保管部２１０に格納する。またアクセス管理部２４０は、データ更新要求で、データの削除が指示されている場合、データ保管部２１０から該当するデータを削除する。さらにアクセス管理部２４０は、データ更新要求で、データの値の変更が指示されている場合、データ保管部２１０内の該当データの値を変更する。

アクセス管理部２４０は、データ更新要求に応じたデータ保管部２１０に対する処理が完了すると、データ更新要求の送信元のＷｅｂサーバに、処理結果を応答する。またアクセス管理部２４０は、データ更新要求に応じて実行した処理内容を、データ更新履歴保管部２３０に格納する。

さらにアクセス管理部２４０は、検索要求を受信した場合、データ保管部２１０に格納されているデータの検索を行う。例えばアクセス管理部２４０は、検索要求を受信した場合、データ更新履歴保管部２３０に、インデックスに未反映の更新履歴が格納されているか否かを判断する。未反映の更新履歴がある場合、アクセス管理部２４０は、インデックス操作部２５０に対して、インデックス更新要求を送信する。そして、アクセス管理部２４０は、インデックス操作部２５０からインデックス更新の完了応答を受け取ると、インデックス保管部２２０に格納されたインデックスを用いて、データ検索を実行する。例えばアクセス管理部２４０は、検索要求に含まれる検索キーに対応するデータのデータＩＤを、インデックスを用いて特定する。次に、アクセス管理部２４０は、特定したデータＩＤに対応するデータを、データ保管部２１０から抽出する。そしてアクセス管理部２４０は、抽出したデータを、検索要求の送信元のＷｅｂサーバに対して送信する。

インデックス操作部２５０は、インデックス保管部２２０に格納されているインデックスを管理する。例えばインデックス操作部２５０は、アクセス管理部２４０またはＷｅｂサーバからインデックス更新要求を受信した場合、インデックスを更新する。インデックスを更新する場合、インデックス操作部２５０は、データ更新履歴保管部２３０からデータの更新履歴を取得する。次にインデックス操作部２５０は、データの更新履歴に応じて、インデックスを更新する。例えばインデックス操作部２５０は、データ追加の更新履歴があった場合、追加されたデータをデータ保管部２１０から抽出し、そのデータのインデックス値を、インデックス上の適切な場所に挿入する。またインデックス操作部２５０は、データ削除の更新履歴があった場合、削除されたデータに対応するインデックス値を無効とする。インデックス操作部２５０は、インデックスの更新が完了すると、インデックス更新要求の送信元に対して、インデックス更新完了を通知する。

なお、図７に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図７に示したデータ保管部２１０とインデックス保管部２２０とを合わせた機能は、図１に示した第１の実施の形態のＤＢ１ａの一例である。図７に示したデータ更新履歴保管部２３０は、図１に示した第１の実施の形態の更新履歴記憶手段１ｂの一例である。図７に示したインデックス更新決定部１２０は、図１に示した第１の実施の形態の決定手段１ｄと出力手段１ｅとを包含する機能の一例である。図７に示したデータ操作受付部１１０とアクセス管理部２４０とが連携して実現する機能は、図１に示した第１の実施の形態のデータ更新手段１ｃと検索手段１ｇとを合わせた機能の一例である。図７に示したインデックス操作部２５０は、図１に示した第１の実施の形態のインデックス更新手段１ｆの一例である。

次に、ＤＢサーバ２００の各記憶部のデータ構造について説明する。
図８は、データ保管部のデータ構造の一例を示す図である。データ保管部２１０には、データＩＤに対応付けて、データが格納されている。データＩＤとデータとの組が、１つのレコードを構成する。データには、インデックス値となる文字列が含まれる。例えば、データの先頭に、データの項目名が設定されており、その項目名がインデックス値として用いられる。なお、データが削除されたレコードは、データＩＤのみが残され、データの領域は空となっている。

次に、インデックス保管部２２０のデータ構造について説明する。
図９は、インデックス保管部のデータ構造の一例を示す図である。図９には、Ｂ−Ｔｒｅｅで構造化されたインデックスの例を示している。Ｂ−Ｔｒｅｅは、多分岐の平衡木である。

インデックス２２１は、木構造であり、木構造には複数のノード４１，４２，４３，４４，４５，・・・が含まれる。ノード４１は、根のノードである。またノード４４，４５は、葉のノードである。

葉のノード以外の各ノードから枝が出ており、枝の先に下位のノードが接続されている。ノードに設けられる枝の数には最大値が決められている。また、ノードは、枝の数より１だけ少ない数のキーを有する。例えば図９の例では、各ノードに、最大で３つの枝が生成できるものとする。

根のノード４１は、キー「baby」、「drama」を有している。そしてノード４１には、３つの枝５１〜５３が設けられている。枝５１はノード４２に接続されている。ノード４２以下の構造には、アルファベット順でキー「baby」より前のインデックス値が保持される。枝５２はノード４３に接続されている。ノード４３以下の構造には、アルファベット順でキー「baby」以降、「drama」より前のインデックス値が保持される。枝５３は、図示していないノードに接続されている。枝５３の接続先のノード以下の構造には、アルファベット順でキー「drama」以降のインデックス値が保持される。

ノード４２は、キー「abbot」、「abhor」を有している。そしてノード４２には、３つの枝５４〜５６が接続されている。枝５４は、葉のノード４４に接続されている。ノード４４には、アルファベット順でキー「abbot」より前のインデックス値が保持される。枝５５は、葉のノード４５に接続されている。ノード４５には、アルファベット順でキー「abbot」以降、「abhor」より前のインデックス値が保持される。枝５６は、図示していない葉のノードに接続されている。枝５６の接続先のノードには、アルファベット順でキー「abhor」以降、「drama」より前のインデックス値が保持される。

ノード４３は、キー「bring」、「create」を有している。そしてノード４３には、３つの枝５７〜５９が接続されている。各枝には、図示していない葉のノードが接続されている。

葉のノード４４，４５，・・・には、インデックス値に対応付けて、データＩＤと無効フラグとの設定領域が設けられている。インデックス値は、例えばアルファベット順にソートされている。データＩＤの設定領域には、インデックス値に対応するデータに付与されている識別子（データＩＤ）が設定される。無効フラグの設定領域は、対応するデータが削除されたインデックス値に対して、そのインデックス値が無効であることを示すフラグ（無効フラグ）が設定される。

このようなデータ構造のインデックス２２１に対してインデックス値を追加する場合、インデックス値のソートが行われる。また、インデックス２２１を用いたデータ検索の効率化を図るため、木構造が再構築される。例えば、ノードにおいて、そのノードの複数の枝それぞれの接続先のノード以降で保持されるインデックス値の数が均等となるように、木構造が再構築される。このように、インデックス２２１の更新時には、最適化のためのインデックス値のソートや、木構造の再構築が行われる。そのため、インデックス２２１の更新頻度が高すぎると、ＤＢサーバ２００の処理負荷が過大となり、データ検索処理などの処理遅延の原因となってしまう。例えば、データ更新処理ごとにインデックス２２１を更新した場合、処理負荷が過大となるおそれがある。そこで、第２の実施の形態では、データ更新の際には、確率的にインデックス更新処理の実行の有無が判断される。

なお、データが削除するデータ更新が行われた場合、そのデータに対応するデータＩＤの無効フラグ領域に、無効フラグが設定される。
次に、データ更新履歴保管部２３０のデータ構造について説明する。

図１０は、データ更新履歴保管部のデータ構造の一例を示す図である。データ更新履歴保管部２３０には、更新履歴管理テーブル２３１が格納されている。更新履歴管理テーブル２３１には、データＩＤと変更区分との欄が設けられている。

データＩＤの欄には、変更されたデータのうち、変更結果がインデックスに反映されていないデータのデータＩＤが設定される。変更区分の欄には、変更されたデータのデータＩＤに対応付けて、変更区分が設定される。変更区分には、変更内容を示す情報として、「追加」または「削除」が設定される。なおデータが変更された場合、データの追加とデータの削除の組で、データの変更内容が表される。データＩＤと変更区分との組が、更新履歴の１つのレコードを構成する。

インデックス更新処理は、更新履歴管理テーブル２３１に登録されているレコードごとに行われる。例えば、変更区分「追加」のレコードに応じて、追加されたデータのインデックス値が、インデックス２２１上の適切な場所に挿入される。また変更区分「削除」のレコードに応じて、削除されたデータのインデックス値が設定されているインデックス２２１内の葉のノードに対し、削除されたデータのデータＩＤの位置に無効マークが設定される。

次に、データ更新処理の手順について説明する。
図１１は、データ更新処理手順の一例を示すシーケンス図である。以下、図１１に示す処理をステップ番号に沿って説明する。

［ステップＳ１０１］Ｗｅｂサーバ１００のデータ操作受付部１１０は、端末装置からのデータ更新指示を受け付ける。
［ステップＳ１０２］データ操作受付部１１０は、データ更新指示に応じたデータ更新要求をＤＢサーバ２００に送信する。

［ステップＳ１０３］ＤＢサーバ２００のアクセス管理部２４０は、データ更新要求に応じて、データ保管部２１０内のデータを更新する。
［ステップＳ１０４］アクセス管理部２４０は、データ更新履歴保管部２３０に更新履歴を追記する。例えば新たなデータが追加された場合、アクセス管理部２４０は、追加されたデータのデータＩＤと変更区分「追加」とを有するレコードを、更新履歴管理テーブル２３１に追加登録する。またデータが削除された場合、アクセス管理部２４０は、削除されたデータのデータＩＤと変更区分「削除」とを有するレコードを、更新履歴管理テーブル２３１に追加登録する。さらにデータが変更された場合、アクセス管理部２４０は、変更されたデータのデータＩＤと変更区分「追加」とを有するレコード、および変更されたデータのデータＩＤと変更区分「削除」とを有するレコードを、更新履歴管理テーブル２３１に追加登録する。

［ステップＳ１０５］アクセス管理部２４０は、データ更新の処理結果を、Ｗｅｂサーバ１００に応答する。
［ステップＳ１０６］データ操作受付部１１０は、インデックス更新決定部１２０に対して、データ更新通知を送信する。するとインデックス更新決定部１２０は、インデックスの更新処理をＤＢサーバ２００に実行させるか否かを、確率的に決定する。例えばインデックス更新決定部１２０は、乱数を生成し、その乱数の値に応じてインデックス更新処理の実行の要否を決定する。

［ステップＳ１０７］データ操作受付部１１０は、インデックス更新処理を実行させると決定した場合、処理をステップＳ１０８に進める。またデータ操作受付部１１０は、インデックス更新処理を実行させないと決定した場合、処理を終了する。

［ステップＳ１０８］データ操作受付部１１０は、インデックス更新処理を実行させると決定した場合、ＤＢサーバ２００に対してインデックス更新要求を送信する。
［ステップＳ１０９］ＤＢサーバ２００のインデックス操作部２５０は、インデックス保管部２２０に格納されているインデックス２２１を更新する。例えばインデックス操作部２５０は、データ更新履歴保管部２３０からデータの更新履歴を１つずつ抽出する。次にインデックス操作部２５０は、抽出した更新履歴に応じて、インデックス２２１を更新する。例えば抽出した更新履歴の変更区分が「追加」であれば、インデックス操作部２５０は、その更新履歴のデータＩＤに対応するデータを、データ保管部２１０から取得する。次にインデックス操作部２５０は、取得したデータからインデックス値を抽出する。さらにインデックス操作部２５０は、インデックス２２１における、抽出したインデックス値に応じた位置に、そのインデックス値と、取得したデータのデータＩＤとの組を追加する。また抽出した更新履歴の変更区分が「削除」であれば、インデックス操作部２５０は、インデックス２２１における、抽出したインデックス値に対応する無効フラグ領域に、無効フラグを設定する。

インデックス操作部２５０は、すべての更新履歴について、インデックス２２１への反映が完了すると、インデックス２２１のデータ構造の再構築を行う。
［ステップＳ１１０］インデックス操作部２５０は、インデックス２２１の更新が完了すると、データ更新履歴保管部２３０内の更新履歴をすべて削除（クリア）する。

このようにして、データの更新時には、乱数を用い、確率的にインデックスの更新処理の実行の有無が決定される。その結果、連続して大量のデータ更新が発生した場合、データ更新の間の適当な間隔で、インデックスの更新処理が実行される。その結果、インデックス２２１へ未反映の履歴情報の量が過大になることが抑止される。

次に、データ検索時の処理について説明する。
図１２は、データ検索時の処理の手順を示すシーケンス図である。以下、図１２に示す処理をステップ番号に沿って説明する。

［ステップＳ１２１］Ｗｅｂサーバ１００のデータ操作受付部１１０は、端末装置からのデータ検索指示を受け付ける。
［ステップＳ１２２］データ操作受付部１１０は、検索要求をＤＢサーバ２００に送信する。

［ステップＳ１２３］ＤＢサーバ２００のアクセス管理部２４０は、データ更新履歴保管部２３０を参照し、インデックス２２１へ未反映の更新履歴があるか否かを判断する。更新履歴があれば、アクセス管理部２４０は処理をステップＳ１２４に進める。また更新履歴がなければ、アクセス管理部２４０は処理をステップＳ１２６に進める。

［ステップＳ１２４］インデックス２２１へ未反映の更新履歴がある場合、アクセス管理部２４０は、インデックス操作部２５０に対してインデックス更新要求を送信する。インデックス操作部２５０は、インデックス更新要求に応じてインデックス２２１を更新する。インデックス更新処理の詳細は、ステップＳ１０９で説明した通りである。

［ステップＳ１２５］インデックス操作部２５０は、インデックス２２１の更新が完了すると、データ更新履歴保管部２３０内の更新履歴をすべて削除（クリア）する。そしてインデックス操作部２５０は、インデックス更新の完了応答をアクセス管理部２４０に送信する。

［ステップＳ１２６］アクセス管理部２４０は、インデックス更新処理の完了応答を受信すると、データ検索を実行する。例えばアクセス管理部２４０は、検索要求に含まれている検索キーに該当するインデックス値を、インデックス保管部２２０内のインデックス２２１から検索する。該当するインデックス値が見つかった場合、アクセス管理部２４０は、そのインデックス値に対応付けられたデータＩＤを取得する。次にアクセス管理部２４０は、取得したデータＩＤに対応するデータを、データ保管部２１０から取得する。

［ステップＳ１２７］アクセス管理部２４０は、データ検索で取得したデータを含む検索結果応答を、Ｗｅｂサーバ１００に送信する。
［ステップＳ１２８］Ｗｅｂサーバ１００は、データ検索指示の送信元の端末装置に、検索結果を送信する。

このようにして、データ検索が行われる。そしてデータ検索時に、インデックス２２１へ未反映の履歴情報があれば、その履歴情報を反映するようにインデックス２２１が更新される。なお、図１１で示したように、データ更新時のみ間欠的にインデックス２２１が更新されているため、データ検索時に、インデックス２２１へ未反映の履歴情報が過大に残存していることは抑止されている。そのため、データ検索時にインデックスの更新処理が発生したとしても、更新処理が挟まることによるデータ検索の応答時間が、極端に長期化する事態は抑止される。

図１３は、インデックスへ未反映の更新履歴数の推移の一例を示す図である。図１３では、横軸に時間、縦軸にインデックスへ未反映の更新履歴数を示している。図１３の例では、データ更新時にインデックス更新処理を行う確率は０．０１（１％）であるものする。

インデックスへ未反映の更新履歴数は、ＤＢサーバ２００における、インデックス更新要求受信時と検索要求受信時とに０になる。それ以外の期間は、ＤＢサーバ２００がデータ更新要求を受信するごとに、１ずつ増加する。

図１３の例では、インデックス更新要求が、データ更新時に０．０１の確率で入力されている。これにより、インデックスへ未反映の更新履歴数は、最大でも１００を少し超える程度に収まっている。これは、前回に検索要求から今回の検索要求の間に、例えば数万件のデータ更新が行われたとしても、検索要求時においてインデックスに反映させる更新履歴数が最大でも１００を少し超える程度に収まることを意味する。このことから、検索要求に対する応答時間が、極端に長期化する事態の発生が抑止されていることが分かる。

しかも第２の実施の形態では、各Ｗｅｂサーバ１００，１００ａ，１００ｂ，・・・において、インデックスの更新処理の実行の要否を、確率的に決定している。そのため各Ｗｅｂサーバ１００，１００ａ，１００ｂ，・・・は、他のＷｅｂサーバからのどの程度のデータ更新要求が出されているかの情報を用いずに、インデックス更新要求を送信できる。これにより、インデックス更新要求を出力するためのＷｅｂサーバ１００，１００ａ，１００ｂ，・・・での処理が極めて単純となり、インデックス更新要求を出力することによる処理負荷の増加が最小限に抑えられる。

〔第３の実施の形態〕
次に第３の実施の形態について説明する。第３の実施の形態は、端末装置との間の通信速度に応じて、インデックスの更新処理の実行確率（更新確率）を変動させるものである。

図１４は、第３の実施の形態のシステム構成例を示す図である。図１４において、第２の実施の形態と同じ要素には、図５に示した第２の実施の形態の対応する要素と同じ符号を付し、説明を省略する。第３の実施の形態では、端末装置６１，６２，６３，・・・が、無線によってネットワーク３１に接続されている。端末装置６１，６２，６３，・・・は、例えば移動体通信端末装置である。

Ｗｅｂサーバ３００，３００ａ，３００ｂ，・・・は、端末装置６１，６２，６３，・・・からの要求に応じて処理を実行する。例えばＷｅｂサーバ３００，３００ａ，３００ｂ，・・・は、ＤＢサーバ２００で管理されているデータの操作要求を受信した場合、ＤＢサーバ２００に対してＤＢのレコードの更新、または検索などの指示を行う。

第３の実施の形態では、Ｗｅｂサーバ３００，３００ａ，３００ｂ，・・・は、ＤＢサーバ２００のレコードの更新を行う場合、データ更新要求の送信元の端末装置との間の通信速度に応じて、インデックスの更新確率を決定する。そしてＷｅｂサーバ３００，３００ａ，３００ｂ，・・・は、乱数による確率的な判断によって、インデックスの更新の要否を決定する。

Ｗｅｂサーバ３００，３００ａ，３００ｂ，・・・のハードウェア構成は、図６に示した第２の実施の形態のＷｅｂサーバ１００のハードウェア構成と同様である。
図１５は、第３の実施の形態に係る各サーバの機能を示すブロック図である。第３の実施の形態では、Ｗｅｂサーバ３００，３００ａ，３００ｂ，・・・の機能が第２の実施の形態と異なる。ＤＢサーバ２００の機能は第２の実施の形態と同様である。

Ｗｅｂサーバ３００は、データ操作受付部３１０、インデックス更新決定部３２０、および更新確率定義記憶部３３０を有する。このうちデータ操作受付部３１０は、第２の実施の形態におけるデータ操作受付部１１０（図７参照）と同じ機能を有している。また第３の実施の形態では、第２の実施の形態の構成に対して更新確率定義記憶部３３０が追加されている。

更新確率定義記憶部３３０は、端末装置との間の通信回線の速度に応じた、インデックスの更新処理の実行確率を定義する情報を記憶する。例えばＲＡＭやＨＤＤの記憶領域の一部が、更新確率定義記憶部３３０として使用される。

インデックス更新決定部３２０は、第２の実施の形態におけるインデックス更新決定部１２０（図７参照）が有する機能に加え、更新確率の判定機能を有する。更新確率判定機能により、インデックス更新決定部３２０は、データ操作受付部３１０からのデータ更新通知を受け取ると、更新確率定義記憶部３３０を参照し、データ更新要求の送信元の端末装置との間の通信速度に応じた更新確率を判断する。そしてインデックス更新決定部３２０は、判断した更新確率に従って、インデックス更新処理の実行の要否を判断する。

次に、更新確率定義記憶部３３０のデータ構造について説明する。
図１６は、更新確率定義記憶部のデータ構造の一例を示す図である。更新確率定義記憶部３３０には、回線種別テーブル３３１と更新確率テーブル３３２とが格納されている。

回線種別テーブル３３１には、要求元ＩＰアドレスと回線種別との欄が設けられている。要求元ＩＰアドレスの欄には、データ更新指示の送信元の端末装置のＩＰアドレスが設定される。要求元ＩＰアドレスの欄には、ＩＰアドレスの一部をワイルドカード「＊」で表すことができる。このワイルドカードは、任意の数値を意味する。回線種別の欄には、要求元ＩＰアドレスの欄に設定されたＩＰアドレスの端末装置との間の通信回線の種別が設定される。

回線種別テーブル３３１を参照することで、データ更新指示の送信元の端末装置のＩＰアドレスに基づいて、その端末装置との間の回線種別が判別できる。
更新確率テーブル３３２には、回線種別と確率との欄が設けられている。回線種別の欄には、要求元ＩＰアドレスの欄に設定されたＩＰアドレスの端末装置との間の通信回線の種別が設定される。確率の欄には、対応する回線種別の通信回線経由でデータ更新指示を受信した場合の、インデックスの更新処理の実行確率が設定される。例えば、通信速度が速い回線ほど、高い確率が設定される。

更新確率テーブル３３２を参照することで、回線種別ごとの更新確率が判別できる。
次に、第３の実施の形態におけるデータ更新処理について説明する。
図１７は、第３の実施の形態におけるデータ更新処理の手順の一例を示すシーケンス図である。図１７に示す処理のうちステップＳ２０１〜Ｓ２０５，Ｓ２０７〜Ｓ２１１の処理は、それぞれ図１１に示す第２の実施の形態のステップＳ１０１〜Ｓ１１０の処理と同じである。そこで第２の実施の形態と異なるステップＳ２０６の処理について説明する。

［ステップＳ２０６］インデックス更新決定部３２０は、ＤＢサーバ２００からデータ更新の結果応答を受信すると、要求元ＩＰアドレスに基づき、更新確率を決定する。例えばインデックス更新決定部３２０は、データ更新指示の通信に用いられたパケットから、要求元ＩＰアドレスを抽出する。次にインデックス更新決定部３２０は、抽出した要求元ＩＰアドレスを検索キーとして、回線種別テーブル３３１の要求元ＩＰアドレスを検索する。該当する要求元ＩＰアドレスがあれば、インデックス更新決定部３２０は、その要求元ＩＰアドレスに対応する回線種別を、回線種別テーブル３３１から抽出する。次にインデックス更新決定部３２０は、抽出した回線種別を検索キーとして、更新確率テーブル３３２の回線種別の欄を検索する。インデックス更新決定部３２０は、該当する回線種別に対応する確率を、更新確率テーブル３３２から抽出する。そしてインデックス更新決定部３２０は、抽出した確率を、今回の処理で適用する更新確率に決定する。

以後、ステップＳ２０７では、決定された更新確率に基づいて、インデックス更新処理の実行の要否が判断される。
このようにして、端末装置が接続された回線の速度に応じてインデックスの更新確率を変えることができる。例えば回線の速度が高いほどインデックスの更新確率を高くすることで、ユーザが使用する回線速度が早いほど、データ検索時の応答時間を短くすることができる。

すなわち、ユーザが端末装置を利用し、高速回線を介してデータ更新指示が入力された場合、インデックス更新処理の実行頻度が高くなる。すると、データ更新履歴保管部２３０に蓄積される更新履歴の数も抑制される。その後、そのユーザがデータ検索指示を入力すると、更新履歴の数が抑制されているため、インデックスの更新が短時間で完了し、データ検索の応答時間も短くて済む。これにより、高速回線を使用していながら、データ検索時の応答時間が長期化してしまい、ユーザの要求するサービスの品質が満たせない事態を抑止できる。

一方、ユーザが端末装置を利用し、低速回線を介してデータ更新指示が入力された場合、インデックス更新処理の実行頻度が低くなる。すると、データ更新履歴保管部２３０に蓄積される更新履歴の数は増大するが、インデックス更新処理の実行に伴う処理負荷は軽減される。その後、そのユーザがデータ検索指示を入力すると、更新履歴の数が多く、高速回線の場合よりもデータ検索の応答時間も長くなる場合もあり得る。ただし、低速回線を使用しているユーザは、もともと通信速度が遅いため、高速回線よりも応答が遅れることを想定しており、若干応答時間が長くなったとしても、気にならないものと思われる。

このように、回線の通信速度に応じた更新確率を適用するようにすると、例えば、データ検索時のインデックス更新に起因する応答時間の増加量を、通信の応答時間の許容誤差の範囲内に抑えることができる。これにより、ユーザに対して、データ検索処理の遅延を感じさせずに、できるだけインデックス更新処理の頻度を抑止し、ＤＢサーバ２００の処理効率を向上させることができる。

〔その他の実施の形態〕
第２の実施の形態では、Ｂ−Ｔｒｅｅのインデックスを用いているが、インデックスのデータ構造は、他の構造であってもよい。例えばインデックスは、Ｂ＋Ｔｒｅｅのデータ構造であってもよい。

また第２・第３の実施の形態では、ＤＢサーバ２００が、外部からのインデックス更新要求に応じてインデックスの更新処理を実行する機能を有しているが、ＤＢサーバがそのような機能を有していない場合もある。その場合には、例えばＷｅｂサーバのインデックス更新決定部１２０，３２０からＤＢサーバに、インデックス更新要求に代えて、何らかのデータ検索を指示するデータ検索要求を送信することもできる。ＤＢサーバでは、データ検索要求に応じてインデックス更新処理が実行される。これにより、インデックス更新要求に応じた処理の実行機能を有していないＤＢサーバを用いたシステムであっても、検索要求に対する応答時間のばらつきの抑止が可能となる。

また、第２・第３の実施の形態では、ＷｅｂサーバとＤＢサーバとが連携して処理を実行しているが、ＷｅｂサーバとＤＢサーバとの機能を１つの情報処理装置（コンピュータ）で実現することもできる。例えば、ＤＢサーバ２００が、Ｗｅｂサーバ１００またはＷｅｂサーバ３００の機能を有することもできる。

また、第２・第３の実施の形態では、乱数を生成することで、インデックスの更新処理を実行する確率が所定の値になるようにしているが、乱数の生成以外の手法で、インデックスの更新処理を実行する確率を制御することもできる。例えば、第１の実施の形態で示したように、データの更新回数に基づいてインデックスの更新処理を実行するか否かを判断することで、実行確率を所定の値にすることもできる。また、前回のインデックスの更新時刻からの経過時間を用いることもできる。その場合、Ｗｅｂサーバでは、例えば、インデックスの更新処理を実行する確率が「０．０１」であれば、経過時間を１００で除算する。そしてＷｅｂサーバは、除算により割り切れた場合（余りが「０」の場合）に、インデックスの更新処理を実行するものと決定する。

なお上記の実施の形態では、ＣＰＵ１０１がプログラムを実行することによって実現するものとしたが、プログラムで記述された処理の一部を、電子回路に置き換えることが可能である。例えば、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応するすべての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。

１ 情報処理装置
１ａ ＤＢ
１ｂ 更新履歴記憶手段
１ｃ データ更新手段
１ｄ 決定手段
１ｅ 出力手段
１ｆ インデックス更新手段
１ｇ 検索手段
２ 端末装置

Claims (6)

1. 情報処理装置が、
   複数のデータと該複数のデータのインデックスとを記憶する記憶部内のデータが更新された場合、乱数を生成し、該乱数の値が所定の確率に応じた所定の範囲内であれば、前記インデックスの更新処理を実行すると決定し、
   前記インデックスの更新処理を実行すると決定した場合、前記記憶部内の前記インデックスの更新を指示するインデックス更新要求を出力する、
   データベース管理方法。
2. 前記情報処理装置が、
   前記情報処理装置にネットワークを介して接続された端末装置からのデータ更新指示に基づいて前記記憶部内のデータが更新されたときに、前記端末装置と前記情報処理装置との間の通信速度に応じて、前記所定の確率を決定する、
   請求項１記載のデータベース管理方法。
3. 前記所定の確率の決定では、前記記憶部内のデータ更新指示を出力した前記端末装置と前記情報処理装置との間の通信速度が速いほど高い値を、前記所定の確率とする、
   請求項２記載のデータベース管理方法。
4. 前記情報処理装置、または前記情報処理装置にネットワークを介して接続された他の情報処理装置が、
   前記インデックス更新要求に応じて、前記インデックスの前回の更新処理の後に実行された前記記憶部内のデータの更新処理を示す履歴情報に基づいて、前記インデックスを更新する、
   請求項１乃至３のいずれかに記載のデータベース管理方法。
5. 情報処理装置に、
   複数のデータと該複数のデータのインデックスとを記憶する記憶部内のデータが更新された場合、乱数を生成し、該乱数の値が所定の確率に応じた所定の範囲内であれば、前記インデックスの更新処理を実行すると決定し、
   前記インデックスの更新処理を実行すると決定した場合、前記記憶部内の前記インデックスの更新を指示するインデックス更新要求を出力する、
   処理を実行させるプログラム。
6. インデックスを有するデータベースのデータが更新された場合、乱数を生成し、該乱数の値が所定の確率に応じた所定の範囲内であれば、前記インデックスの更新処理を実行すると決定する決定手段と、
   前記インデックスの更新処理を実行すると決定した場合、前記インデックスの更新を指示するインデックス更新要求を出力する出力手段と、
   を有する情報処理装置。
   

Images