JP2012234415A - インデックス管理方法、インデックス管理プログラムおよびインデックス管理装置 - Google Patents

Abstract

【課題】動的ツリー型インデックス方式によるインデックスの管理負荷を軽減することを課題とする。
【解決手段】多次元データ検索サーバは、空間を最小外接領域に分割して空間に存在するデータのインデックスをツリー構造で生成する。そして、多次元データ検索サーバは、ツリー構造を形成するノードごとに、当該ノードが検索された数を計数する。また、多次元データ検索サーバは、ノードごとに、当該ノードが管理するデータ又は当該ノードの子ノードが更新された数を計数する。その後、多次元データ検索サーバは、データの数または子ノードの数に基づいて特定したノードについて、計数した更新回数と検索回数とを用いて更新指数を算出し、算出した更新指数に基づいて、特定したノードの分割または統合処理の実行を抑止する。
【選択図】図７

Description

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

従来、空間内に存在する大量のデータから所望のデータを高速に検索するために、インデックスを用いたデータ管理が利用される。また、インデックスを用いた検索手法としては、範囲検索や近傍検索が一般的に利用される。範囲検索とは、所定の領域内に存在する全データを検索する手法であり、近傍検索とは、所定の点の近くにあるデータを距離や個数を指定して検索する手法である。

このようなインデックスを生成して管理する方式として、セル分割型インデックス方式が知られている。セル分割型インデックス方式は、空間をグリッド状の矩形領域に分割し、各領域に一意なＩＤを割り与えるとともに、各領域内のデータに別の一意なＩＤを付加して管理する。

この方式の場合、管理する領域が固定されるが、各領域内のデータ数が不均等となり、各領域のデータ密度に偏りが生じる。したがって、近傍検索を実施する場合には、データ数の少ない領域では高速な検索が実行できるものの、データ数の多い領域では検索に時間がかかり、全体としては検索効率が悪い。

近傍検索の検索効率を向上させる管理方式として、動的ツリー型インデックス方式が知られている。動的ツリー型インデックス方式は、多次元領域を分割領域の入れ子構造で管理するＲ−Ｔｒｅｅ（Ｒツリー）を利用した方式であり、近くに存在するデータ同士を動的にグループ化し、グループ同士をさらにグループ化して木構造で管理する。

この方式の場合、データ数が均等になるように領域が分割されるので、各領域の大きさは異なるが、各領域のデータ密度に生じる偏りは小さい。したがって、近傍検索を実施する場合にも、各領域でデータ検索を高速に実行できるので、セル分割型インデックス方式に比べて検索効率が向上する。また、動的ツリー型インデックス方式では、管理する領域を部分空間符号で圧縮することで、管理効率を上げる手法も知られている。

特開２０００−２００３４２号公報

しかしながら、従来の動的ツリー型インデックス方式では、頻繁に情報が更新される場合には、ノードの分割や統合が繰り返して実行されることになるので、インデックスの管理負荷が高いという問題がある。

例えば、１つの親ノードに子ノードが上限値である６つ関係付けられている状態、つまり、１つの矩形空間に６つの部分矩形領域が存在する状態で、１つの子ノード（部分矩形領域）を追加する場合を例にして説明する。上限値を越えてしまうため、この親ノードは分割しなければならない。一つの厳密な分割例を挙げると、子ノードを半分ずつに分割した上で新たな子ノードを追加する場合には、_６Ｃ_３＝２０通りのうち両矩形領域面積の和が最小となる分割を選択することになる。また、子ノードが１００の場合には、_１００Ｃ_５０＝１０^２９通りのうち矩形領域面積の和が最小となる分割を選択することになり、処理負荷が激増する。

より簡便な別の分割例としては、例えば空間の中心点でソートして最小と最大の領域の２領域を抽出して、それぞれを含んだ２グループを生成し、残りの領域を各グループの最小外接矩形（ＭＢＲ）の増分が最小になるように選んで入れる方法もある。この方法の場合、６個のソートと４×２＝８回の大小比較を行うことになる。つまり、「（ｌｏｇＮ＋２）×Ｎ」回の演算を実行することになり、演算量が大きなものになる。このように、いずれの方法であっても、インデックスの管理負荷が高い。

開示の技術は、上記に鑑みてなされたものであって、動的ツリー型インデックス方式によるインデックスの管理負荷を軽減することができるインデックス管理方法、インデックス管理プログラムおよびインデックス管理装置を提供することを目的とする。

本願の開示するインデックス管理方法、インデックス管理プログラムおよびインデックス管理装置は、一つの態様において、空間を最小外接領域に分割して前記空間に存在するデータのインデックスをツリー構造で生成する。そして、前記ツリー構造を形成するノードごとに、当該ノードが検索された数を計数し、前記ノードごとに、当該ノードが管理するデータ又は当該ノードの子ノードが更新された数を計数する。その後、前記データの数または子ノードの数に基づいて特定したノードについて、計数した更新回数と検索回数とを用いて更新指数を算出し、算出した更新指数に基づいて、前記特定したノードの分割または統合処理の実行を抑止する。

本願の開示するインデックス管理方法、インデックス管理プログラムおよびインデックス管理装置の一つの態様によれば、動的ツリー型インデックス方式によるインデックスの管理負荷を軽減することができるという効果を奏する。

図１は、実施例１に係るシステムの全体構成を示す図である。 図２は、Ｒツリーで管理するデータと矩形領域の例を示す図である。 図３は、Ｒツリーにノードを追加する例を示す図である。 図４は、Ｒツリーにデータを追加する例を示す図である。 図５は、Ｒツリーのノードを削除する例を示す図である。 図６は、Ｒツリーのデータを削除する例を示す図である。 図７は、実施例１に係る多次元データ検索サーバの構成を示すブロック図である。 図８は、インデックスＤＢに記憶される情報の例を示す図である。 図９は、インデックスＤＢに記憶されるルートノードの情報の例を示す図である。 図１０は、インデックスＤＢに記憶されるブランチノードの情報の例を示す図である。 図１１は、インデックスＤＢに記憶される葉ノードの情報の例を示す図である。 図１２は、更新／検索回数ＤＢに記憶される情報の例１を示す図である。 図１３は、更新／検索回数ＤＢに記憶される情報の例２を示す図である。 図１４は、データ検索リクエストの例を示す図である。 図１５は、データ検索リクエストの例を示す図である。 図１６は、データ検索応答の例を示す図である。 図１７は、実施例１に係る検索処理の流れを説明するフローチャートである。 図１８は、実施例１に係る追加処理の流れを説明するフローチャートである。 図１９は、実施例１に係る追加処理の流れを説明するフローチャートである。 図２０は、実施例１に係る削除処理の流れを説明するフローチャートである。 図２１は、実施例１に係る削除処理の流れを説明するフローチャートである。 図２２は、多次元データ検索サーバを用いたサービス例１を示す図である。 図２３は、多次元データ検索サーバを用いたサービス例２を示す図である。 図２４は、インデックス管理プログラムを実行するコンピュータのハードウェア構成例を示す図である。

以下に、本願の開示するインデックス管理方法、インデックス管理プログラムおよびインデックス管理装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

実施例１では、多次元データ検索サーバを含むシステムの全体構成、多次元データ検索サーバの機能ブロック図、処理の流れ、効果を説明する。

［全体構成］
図１は、実施例１に係るシステムの全体構成を示す図である。図１に示すように、このシステムは、多次元データ検索サーバ１０と複数の端末装置とが有線通信または無線通信で相互に通信可能に接続される。なお、図１に示した構成はあくまで例示であり、装置の台数やネットワーク構成、ネットワーク種別等を限定するものではない。

各端末装置は、所定間隔で位置情報を多次元データ検索サーバ１０に送信する装置であり、例えばパーソナルコンピュータ、サーバ、携帯端末、ＰＤＡ（Personal Digital Assistant）、スマートフォンなどの装置である。

一例を挙げると、端末装置は、温度や湿度などのセンサを有し、所定間隔でセンシングした値とともに、ＧＰＳ（Global Positioning System）受信機等で測定した座標などの位置情報を多次元データ検索サーバ１０に送信する。

多次元データ検索サーバ１０は、動的ツリー型インデックス方式を用いて、端末装置の位置情報のインデックスを生成して管理するサーバ装置である。例えば、多次元データ検索サーバ１０は、各端末装置から２次元の位置情報を受信して、受信した位置情報に基づいて、空間を最小外接矩形に分割して空間に存在する位置情報のインデックスをＲ−Ｔｒｅｅ（以下、Ｒツリーと表記する）で生成する。

ここで、多次元データ検索サーバ１０が生成するＲツリーと、生成したＲツリーの管理としてノードの追加や削除を実行する例を説明する。図２は、Ｒツリーで管理するデータと矩形領域の例を示す図である。なお、図２に示したノード数等はあくまで例示であり、図示したものに限定されるものではない。

図２に示すように、Ｒツリーは、Ｒ０からＲ１１で形成されるツリー構造であり、Ｒ０をルートノード、Ｒ５からＲ１１を最下段の葉ノード、ルートノードと葉ノードとの間に位置するＲ１からＲ４をブランチノードとする。

ルートノードＲ０は、子ノードであるＲ１、Ｒ２、Ｒ３、Ｒ４を含む最小外接矩形であり、ブランチノードＲ１は、Ｒ５、Ｒ６、Ｒ７、Ｒ８を含む最小外接矩形であり、Ｒ５からＲ８各々は、内部に持つ座標データ（位置情報）の最小外接矩形である。また、ノードＲ２からノードＲ４は、それぞれ子ノードであるＲ９からＲ１１を含む最小外接矩形である。なお、本実施例では、各ノードが子ノードを全て最小外接矩形で子ノードを管理する例で説明するが、最小外接矩形とは、例えば矩形や球など所定の形状の中で最小の領域の一例である。

つまり、図２の下図に示すように、葉ノードＲ５は、所定数の位置情報を全て含む最小の矩形領域である。ブランチノードＲ１は、子ノードであるＲ５、Ｒ６、Ｒ７、Ｒ８を全て含む最小の矩形領域である。ルートノードＲ０は、子ノードであるＲ１、Ｒ２、Ｒ３、Ｒ４、Ｒ５を全て含む最小の矩形領域である。なお、最小外接矩形の生成方法やＲツリーの生成方法は、一般的な公知の技術を用いることができるので、詳細な説明は省略する。

このようなＲツリーによってデータのインデックスを管理する多次元データ検索サーバ１０は、ノードの追加、データの追加、ノードの削除、データの削除などが発生した場合に、Ｒツリーを動的に変更する。

ここで、図３から図６を用いてＲツリーの動的変更について説明する。この例では、多次元データ検索サーバ１０は、ルートノードを「Ｒ０」、ブランチノードを「Ｒ１、Ｒ２、Ｒ３、Ｒ４」、葉ノードを「Ｒ５、Ｒ６、Ｒ７、Ｒ８、Ｒ９、Ｒ１０、Ｒ１１」とするインデックスを管理する。また、Ｒ０の子ノードがＲ１からＲ４であり、Ｒ１の子ノードがＲ５からＲ８であり、Ｒ２の子ノードがＲ９であり、Ｒ３の子ノードがＲ１０であり、Ｒ４の子ノードがＲ１１である。なお、ノードを分割または統合するアルゴリズム等は、一般的なＲツリーで使用されるものを使用できるので、詳細な説明は省略する。

図３は、Ｒツリーにノードを追加する例を示す図である。この例では、各ノードの子ノード数の上限値は４であるとする。図３では、多次元データ検索サーバ１０が、Ｒ１の子ノードに「ノードＲ１２」を追加する処理の一例について説明する。まず、多次元データ検索サーバ１０は、Ｒ１の子ノードとしてＲ１２を追加する。続いて、多次元データ検索サーバ１０は、Ｒ１の子ノードの数がＲ１２の追加によって管理できる上限値を超える場合、Ｒ１をＲ１ＡとＲ１Ｂとに分割する。そして、多次元データ検索サーバ１０は、Ｒ１をＲ１ＡとＲ１Ｂとに分割したことで、Ｒ０の子ノードの数が上限値を超えた場合、Ｒ０をＲ０ＡとＲ０Ｂとに分割し、新たなルートノードＲＲ０の子ノードとして管理する。

つまり、多次元データ検索サーバ１０は、新たなノードを子ノードとして追加した親ノードの分割や、当該親ノードが分割された各ノードを子ノードするノードの分割等を繰り返して実行する。このように、多次元データ検索サーバ１０は、ノードの追加に伴って、各ノードが管理するデータ数または各ノードの子ノード数が上限値を超えないように、ノードの分割を実行する。

図４は、Ｒツリーにデータを追加する例を示す図である。この例でも、各ノードの子ノード数の上限値は４であるとする。図４では、多次元データ検索サーバ１０が、葉ノードのＲ５にデータ「Ｄ１１」を追加する処理の一例について説明する。図示していないが、葉ノードＲ５からＲ１１まではいずれも上限値を越えない数のデータを保持している。まず、多次元データ検索サーバ１０は、Ｒ５が管理するデータにＤ１１を追加する。続いて、多次元データ検索サーバ１０は、Ｒ５が管理するデータの数がＤ１１の追加によって上限値を超える場合、Ｒ５をＲ５ＡとＲ５Ｂとに分割する。そして、多次元データ検索サーバ１０は、Ｒ５をＲ５ＡとＲ５Ｂとに分割したことで、Ｒ１の子ノードの数が上限値を超えた場合、Ｒ１をＲ１ＡとＲ１Ｂとに分割する。さらに、Ｒ１をＲ１ＡとＲ１Ｂとに分割したことで、Ｒ０の子ノードの数が上限値を超えた場合、Ｒ０をＲ０ＡとＲ０Ｂとに分割し、新たなルートノードＲＲ０の子ノードとして管理する。

つまり、多次元データ検索サーバ１０は、葉ノードに新たなデータを追加した場合も、図３と同様に、葉ノードからルートノードまでの各ノードについて、データ数や子ノード数が管理できる上限値を超えないか否かを判定する。そして、多次元データ検索サーバ１０は、上限値を超えるノードの分割等を繰り返して実行する。このように、多次元データ検索サーバ１０は、葉ノードへのデータの追加に伴って、各ノードが管理するデータ数または各ノードの子ノード数が上限値を超えないように、ノードの分割を実行する。

図５は、Ｒツリーのノードを削除する例を示す図である。この例では、各ノードの子ノード数の下限値は２であるとするために、図２から図４とは異なるツリーで説明する。具体的には、Ｒツリーは、Ｒ０からＲ１２で形成されるツリー構造であり、Ｒ０をルートノード、Ｒ５からＲ１２を最下段の葉ノード、ルートノードと葉ノードとの間に位置するＲ１からＲ４をブランチノードとする。また、Ｒ１からＲ４のブランチノードには、それぞれ葉ノードが２つずつぶら下がっている。図５では、多次元データ検索サーバ１０が、ブランチノードＲ３の子ノードである「Ｒ１０」を削除する処理の一例について説明する。まず、多次元データ検索サーバ１０は、Ｒ３の子ノードであるＲ１０を削除する。続いて、多次元データ検索サーバ１０は、Ｒ３の子ノードの数が下限値を下回ったので、Ｒ３とＲ４とを統合して新たなＲ４をＲ０の子ノードとする。そして、多次元データ検索サーバ１０は、新たなＲ４の子ノードが下限値より多く、Ｒ３が統合されてなくなることによってＲ０の子ノード数が下限値を下回ることもないので、処理を終了する。

つまり、多次元データ検索サーバ１０は、ノードを削除した場合も、図３と同様に、葉ノードからルートノードまでの各ノードについて、データ数や子ノード数が管理できる上限値や下限値を超えないか否かを判定する。そして、多次元データ検索サーバ１０は、上限値や下限値を超えるノードの分割または統合等を繰り返して実行する。このように、多次元データ検索サーバ１０は、ノードの追加に伴って、各ノードが管理するデータ数または各ノードの子ノード数が上限値や下限値を超えないように、ノードの分割または統合を実行する。

図６は、Ｒツリーのデータを削除する例を示す図である。図６では、多次元データ検索サーバ１０が、葉ノードＲ５が管理するデータ「Ｄ２１、Ｄ２２」のうち「Ｄ２１」を削除する処理の一例について説明する。Ｄ２１以外に図示しているデータはＤ２２のみであるが、葉ノードＲ５にはちょうど下限値に等しい数のデータを管理しており、Ｄ２１及びＤ２２以外のデータはＤ２２と同様に処理する物とする。まず、多次元データ検索サーバ１０は、ノードＲ５が管理するＤ２１を削除する。続いて、多次元データ検索サーバ１０は、Ｒ５の管理するデータ数が下限値を下回ったので、Ｒ５とＲ６とを統合して新たなＲ６をＲ１の子ノードとする。そして、多次元データ検索サーバ１０は、新たなＲ６のデータとして、元のＲ５のデータであるＤ２２を追加する。そして、多次元データ検索サーバ１０は、新たなＲ６のデータ数が下限値より多く、上限値を超えていないので、処理を終了する。なお、多次元データ検索サーバ１０は、新たなＲ６のデータ数が上限値を超えている場合には、新たなＲ６の分割を実行する。

つまり、多次元データ検索サーバ１０は、データを削除した場合も、図３と同様に、葉ノードからルートノードまでの各ノードについて、データ数や子ノード数が管理できる上限値や下限値を超えないか否かを判定する。そして、多次元データ検索サーバ１０は、上限値や下限値を超えるノードの分割または統合等を繰り返して実行する。このように、多次元データ検索サーバ１０は、データの追加に伴って、各ノードが管理するデータ数または各ノードの子ノード数が上限値や下限値を超えないように、ノードの分割または統合を実行する。

上述したように、多次元データ検索サーバ１０は、データの追加や削除、ノードの追加や削除に伴って、Ｒツリーの構成を変更してインデックスを管理する。このような多次元データ検索サーバ１０は、ツリー構造を形成するノードごとに、当該ノードが検索された数を計数する。また、多次元データ検索サーバ１０は、ノードごとに、当該ノードが管理するデータ又は当該ノードの子ノードが更新された数を計数する。そして、多次元データ検索サーバ１０は、データの数または子ノードの数に基づいて特定したノードについて、計数した更新回数と検索回数とを用いて更新指数を算出し、算出した更新指数に基づいて、特定したノードの分割または統合処理の実行を抑止する。

つまり、多次元データ検索サーバ１０は、更新回数の割合がノードについては、インデックス管理のボトルネックとなっていたノードの分割処理またはノード統合処理を抑止することで、インデックスの管理負荷を軽減することができる。すなわち、更新指数の高い領域については、負荷の高いインデックス更新処理を避けることで、検索処理性能を向上させることができる。

［多次元データ検索サーバの構成］
図７は、実施例１に係る多次元データ検索サーバの構成を示すブロック図である。図７に示すように、多次元データ検索サーバ１０は、通信インタフェース１１と、記憶部１２と、制御部１３とを有する。

通信インタフェース１１は、各端末装置との間で通信を確立して、各端末装置から位置情報やデータ検索要求等を受信したり、各端末装置にデータ検索応答を送信したりするインタフェースである。例えば、通信インタフェース１１は、ＬＡＮ（Local Area Network）やインターネットなどと接続するネットワークインタフェースカードや、無線アンテナを有する無線通信部などである。

記憶部１２は、制御部１３が実行するプログラム等を記憶するとともに、作業領域１２ａとインデックスＤＢ１２ｂと多次元データＤＢ１２ｃと更新／検索回数ＤＢ１２ｄとを有する半導体素子やハードディスクなどの記憶装置である。また、この記憶部１２は、葉ノードが管理できるデータの上限値および下限値、各ノードが子ノードとして管理できる子ノードの上限値および下限値を記憶する。例えば、記憶部１２は、データの上限値「４」、データの下限値「１」、ノードの上限値「４」、ノードの下限値「０」などと記憶する。

作業領域１２ａは、制御部１３または制御部１３が有する各処理部が各種処理を実行する際に使用する一時領域である。

インデックスＤＢ１２ｂは、空間内に存在する大量のデータから所望のデータを高速に検索するための索引情報である。例えば、インデックスＤＢ１２ｂは、端末装置の位置情報のインデックスをＲツリーで保持する。図８は、インデックスＤＢに記憶される情報の例を示す図である。図８に示すように、インデックスＤＢ１２ｂは、ノード種別としてルート、ブランチ、葉の三種のいずれかを示すデータで形成されるＲツリーを記憶する。ルートノードは、Ｒツリーに１つのみ存在する頂点データであり、検索を開始するノードとなる。また逆に、葉ノードはＲツリーの最底辺のノードであり、自らは子ノードを含まず、点・領域などの検索対象多次元データを１つ以上持つ。それ以外の木の中間に存在するノードはブランチノードであり、それぞれ子ノードを１つ以上持つ。

図８の場合、ルートノードがＲ０であり、Ｒ０の子ノードかつブランチノードがＲ１、Ｒ２、Ｒ３、Ｒ４である。ブランチノードＲ１の子ノードである葉ノードがＲ５、Ｒ６、Ｒ７、Ｒ８であり、ブランチノードＲ２の子ノードである葉ノードがＲ９である。ブランチノードＲ３の子ノードである葉ノードがＲ１０であり、ブランチノードＲ４の子ノードである葉ノードがＲ１１である。

インデックスＤＢ１２ｂは、Ｒツリーの実体としてルート、ブランチ、葉の各ノードの情報を記憶する。図９は、インデックスＤＢに記憶されるルートノードの情報の例を示す図である。図９に示すように、インデックスＤＢ１２ｂは、ルートノードＲ０の情報として、「ノード種別、矩形情報、子ノードリスト」を記憶する。ここで記憶される「ノード種別」は、ノードがルート、ブランチ、葉のいずれであるかを示す情報であり、「矩形情報」は、子ノードの担当領域をすべて含む最小外接矩形の情報であり、「子ノードリスト」は、当該ノードの子ノードへのリンクポインタのリストである。

図９の場合、ルートノードＲ０は、ｘ、ｙの２次元データを管理し、「ｘ１＝３５．５０、ｙ１＝１３９．００」が担当領域の最小点であり、「ｘ２＝３５．９０、ｙ２＝１３９．５０」が担当領域の最大点であることを示す。すなわち、Ｒ０が担当する領域は、両点を頂点として各次元軸に直交した４直線で作られる領域である。また、Ｒ０は、子ノード「Ｒ１、Ｒ２、Ｒ３、Ｒ４」へのポインタのリストを記憶する。

図１０は、インデックスＤＢに記憶されるブランチノードの情報の例を示す図である。図１０に示すように、インデックスＤＢ１２ｂは、ブランチノードの情報として、「ノード種別、矩形情報、子ノードリスト」を記憶する。ここで記憶される「ノード種別」、「矩形情報」、「子ノードリスト」は、図９と同様なので詳細な説明は省略する。インデックスＤＢ１２ｂは、Ｒ１、Ｒ２、Ｒ３、Ｒ４について、図１０の情報を記憶する。

図１０の場合、ブランチノードＲ１は、ｘ、ｙの２次元データを管理し、「ｘ１＝３５．５０、ｙ１＝１３９．２０」が担当領域の最小点であり、「ｘ２＝３５．７０、ｙ２＝１３９．３０」が担当領域の最大点であることを示す。すなわち、ブランチノードＲ１が担当する領域は、両点を頂点として各次元軸に直交した４直線で作られる領域である。また、Ｒ１は、子ノード「Ｒ５、Ｒ６、Ｒ７、Ｒ８」へのポインタのリストを記憶する。

図１１は、インデックスＤＢに記憶される葉ノードの情報の例を示す図である。図１１に示すように、インデックスＤＢ１２ｂは、葉ノードの情報として、「ノード種別、矩形情報、データリスト」を記憶する。ここで記憶される「ノード種別」、「矩形情報」は、図９と同様なので詳細な説明は省略する。「データリスト」は、管理する多次元データである。インデックスＤＢ１２ｂは、Ｒ５、Ｒ６、Ｒ７、Ｒ８について、図１１の情報を記憶する。

図１１の場合、葉ノードＲ５は、ｘ、ｙの２次元データを管理し、「ｘ１＝３５．５０、ｙ１＝１３９．２５」が担当領域の最小点であり、「ｘ２＝３５．６５、ｙ２＝１３９．３０」が担当領域の最大点であることを示す。すなわち、葉ノードＲ５が担当する領域は、両点を頂点として各次元軸に直交した４直線で作られる領域である。また、Ｒ５は、データ「Ｄ１、Ｄ２、Ｄ３、Ｄ４」へのポインタのリストを記憶する。各データの実体は、多次元データＤＢ１２ｃに格納されている。

図７に戻り、多次元データＤＢ１２ｃは、例えば２次元の位置情報などデータそのものを記憶する。具体的には、多次元データＤＢ１２ｃは、各葉ノードが保持するデータＤの値そのものを記憶する。なお、データは、横（ｘ）軸と縦（ｙ）軸とから形成される２次元情報に限定されるものではなく、横（ｘ）軸と縦（ｙ）軸と時間（ｔ）軸などの３次元情報であってもよく、３次元以上の多次元情報であってもよい。

更新／検索回数ＤＢ１２ｄは、インデックスＤＢ１２ｂに記憶されるインデックスツリーの各ノードごとに、ノードが検索された回数、および、ノードが管理するデータ又は当該ノードの子ノードが更新された回数を記憶する。なお、ここで記憶される情報は、後述するデータ検索部１４やデータ更新部１５等によって更新される。

図１２は、更新／検索回数ＤＢに記憶される情報の例１を示す図である。図１２に示すように、更新／検索回数ＤＢ１２ｄは、「更新／変更回数計測開始時間」と「ノードＩＤ、検索回数、更新回数」を記憶する。ここで記憶される「更新／変更回数計測開始時間」は、計数が開始された時間であり、「ノードＩＤ」は、ノードを識別する識別子である。「検索回数」は、データ検索部１４によって検索された回数であり、「更新回数」は、データ更新部１５によって追加や削除などの更新がされた回数である。

2010/11/15 18:00:00.000に処理が開始され、ノードＩＤ＝００００１のノードは、現時点で１４５回検索され、３４９回更新されたことを示す。同様に、ノードＩＤ＝０００１５のノードは、現時点で４９３回検索され、３３１回更新されたことを示す。なお、図１２の場合、サーバの停止等によって、検索および更新回数をリセットしたりする。

図１３は、更新／検索回数ＤＢに記憶される情報の例２を示す図である。図１３に示すように、更新／検索回数ＤＢ１２ｄは、「最古更新／変更回数計測開始時間」と「ノードＩＤ、検索回数、更新回数」を記憶する。図１２と異なる点は、各ノードごとに、例えば１時間など一定時間毎の検索および更新回数を記憶する点であり、一定期間を経過する度に各回数の値を一つずつ左方向にずらしても良い。

図１３の場合、ノードＩＤ＝００００１の最新の情報として、現時点から１時間前までに「検索回数＝１４５、更新回数＝３４９」が計数されたことを示す。さらに１時間前まで、すなわち１時間前から２時間前までに「検索回数＝１３９、更新回数＝３２４」が計数されたことを示す。そして、最古の情報、すなわち４時間前から５時間前までに「検索回数＝４５、更新回数＝１６９」が計数されたことを示す。

この場合、検索および更新指数の計算方法は、最も左の回数欄の計測開始時間と現在時刻の差で、各ノードＩＤの検索又は更新回数の全欄を足した値を割ることで、検索頻度及び更新指数を計算することができる。

データ検索部１４は、ネットワーク経由で受信した検索リクエストに応じて、インデックスツリーを検索して応答する処理部である。図１４は、データ検索リクエストの例を示す図である。図１４に示すように、データ検索部１４は、「多次元データ、検索範囲」として「３５．４１３４、１３９．６２５２、１００ｍ」などを受信する。この「多次元データ」は、検索対象の位置情報であり、例えば緯度や経度の情報である。「検索範囲」は、指定された多次元データから検索対象の範囲を示す情報である。つまり、図１４の場合、データ検索部１４は、インデックスＤＢ１２ｂを参照し、「３５．４１３４、１３９．６２５２」から１００ｍに位置するデータを近傍検索して応答する。

また、別の例としては、図１５は、データ検索リクエストの例を示す図である。図１５に示すように、データ検索部１４は、「多次元データ、検索データ数」として「３５．４１３４、１３９．６２５２、１０個」などを受信する。この「多次元データ」は、図１４と同様であり、「検索データ数」は、指定された多次元データから近い位置に存在するデータを１０個選択することを示す。つまり、図１５の場合、データ検索部１４は、インデックスＤＢ１２ｂを参照し、「３５．４１３４、１３９．６２５２」の近くに存在する１０個のデータを近傍検索して応答する。

また、図１６は、データ検索応答の例を示す図である。図１６に示すように、データ検索部１４は、データの近傍検索結果として、ノードを特定する「ＩＤ」を応答する。つまり、図１６の場合、データ検索部１４は、データ検索リクエストにしたがってインデックスツリーを検索し、検索したノードのＩＤが「００００１、０００３４、００００９７、・・・」であることを、リクエスト元に応答する。この実施例ではデータのＩＤを応答する例を示したが、ＩＤではなくデータの内容にして応答しても良い。その場合は、データ検索部１４は、検索されたＩＤに対応するデータを多次元データＤＢ１２ｃから取得し、取得したデータそのものを応答することもできる。

図７に戻り、データ更新部１５は、インデックスＤＢ１２ｂに記憶されるインデックスツリーに対して、ノードの追加、ノードの削除、データの追加、データの削除を実行して、インデックスツリーを更新する処理部である。なお、ノードの追加、ノードの削除、データの追加、データの削除、さらにこれらに伴ってノードを分割または統合する処理については、図２から図６を用いて説明したので、ここでは詳細な説明は省略する。

また、データ更新部１５は、データを追加または削除した場合には、インデックスＤＢ１２ｂに記憶される葉ノードのデータリストを更新する。また、データ更新部１５は、インデックスツリーに変更があった場合には、その変更にあわせてインデックスＤＢ１２ｂを更新する。また、データ更新部１５は、ノードを追加した場合には、「検索回数＝０、更新回数＝０」とする新たなレコードを更新／検索回数ＤＢ１２ｄに作成する。データ更新部１５は、ノードを削除した場合には、当該ノードに対応するレコードを更新／検索回数ＤＢ１２ｄから削除する。

ノード制御部１６は、ノードの分割または統合を実施するか否かを判定する処理部であり、分割統合判定部１６ａと、更新指数算出部１６ｂと、分割統合制御部１６ｃとを有する。

分割統合判定部１６ａは、データ更新部１５やデータ検索部１４による処理が実行され、各ノードが管理するデータ数または子ノード数が、記憶部１２に記憶される上限値または下限値を満たすか否かを判定する処理部である。つまり、分割統合判定部１６ａは、データ更新部１５やデータ検索部１４の処理によって、ノードを分割する処理またはノードを統合する処理が発生したか否かを判定する。

例えば、分割統合判定部１６ａは、インデックスＤＢ１２ｂを参照し、データリストとして記憶するデータ数が上限値より多い葉ノードを分割対象として更新指数算出部１６ｂに通知する。同様に、分割統合判定部１６ａは、インデックスＤＢ１２ｂを参照し、子ノードのポインタ数が上限値より多いブランチノードまたはルートノードを、分割対象として更新指数算出部１６ｂに通知する。このとき、分割統合判定部１６ａは、ノードＩＤを更新指数算出部１６ｂに通知する。

また、分割統合判定部１６ａは、インデックスＤＢ１２ｂを参照し、データリストとして記憶するデータ数が下限値より多い葉ノードを統合対象として更新指数算出部１６ｂに通知する。同様に、分割統合判定部１６ａは、インデックスＤＢ１２ｂを参照し、子ノードのポインタ数が下限値より多いブランチノードまたはルートノードを、統合対象として更新指数算出部１６ｂに通知する。このとき、分割統合判定部１６ａは、ノードＩＤを更新指数算出部１６ｂに通知する。

更新指数算出部１６ｂは、分割統合判定部１６ａから通知されたノードについて更新／検索回数ＤＢ１２ｄを参照し、更新回数と検索回数とを用いて更新指数を算出する。例えば、更新指数算出部１６ｂは、分割統合判定部１６ａからノードＩＤ＝００００１を受信した場合、図１２の「ノードＩＤ」を参照して「検索回数＝１４５、更新回数＝３４９」を取得する。そして、更新指数算出部１６ｂは、「更新回数（３４９）／検索回数（１４５）＝２．４０・・・」を更新指数として算出して分割統合制御部１６ｃに通知する。

また、別の例としては、更新指数算出部１６ｂは、分割統合判定部１６ａからノードＩＤ＝０００１５を受信した場合、図１３の「ノードＩＤ」のうち最新のデータを参照して「検索回数＝４９３、更新回数＝３３１」を取得する。そして、更新指数算出部１６ｂは、「更新回数（３３１）／検索回数（４９３）＝０．６７１・・・」を更新指数として算出して分割統合制御部１６ｃに通知する。

分割統合制御部１６ｃは、更新指数算出部１６ｂの算出結果に基づいて、ノードの分割または統合を実行するか否かを判定する処理部である。例えば、分割統合制御部１６ｃは、更新指数算出部１６ｂが算出した更新指数が２以上であれば、更新指数が高いと判定し、当該ノードの更新を抑止すると判定する。そして、分割統合制御部１６ｃは、データ更新部１５に対して、当該ノードの分割または統合処理を抑止する指示を出力する。

また、分割統合制御部１６ｃは、更新指数算出部１６ｂが算出した更新指数が２未満であれば、更新指数が低いと判定し、当該ノードの更新を実行すると判定する。そして、分割統合制御部１６ｃは、データ更新部１５に対して、当該ノードの分割または統合処理を実行する指示を出力する。

なお、データ更新部１５は、ノードを分割した場合、当該ノードの更新／検索回数については、分割後のそれぞれのノードが分割前のノードの回数を引き継ぐように制御してもよく、分割前の回数を半分ずつ引き継ぐようにしてもよい。また、データ更新部１５は、分割後のそれぞれのノードについては、回数を０とすることもできる。つまり、ノード分割後については、ユーザやシステムの仕様によって任意に設定できる。

［処理の流れ］
次に、図１７から図２１を用いて、多次元データ検索サーバ１０が実行する検索処理、追加処理、削除処理について説明する。

（検索処理）
図１７は、実施例１に係る検索処理の流れを説明するフローチャートである。図１７に示すように、検索リクエストを受信したデータ検索部１４は、まず、ルートノードを選択し（Ｓ１０１）、選択したノードが葉ノードか否かをインデックスツリーやインデックスＤＢ１２ｂから判定する（Ｓ１０２）。

そして、データ検索部１４は、選択したノードが葉ノードでないと判定した場合（Ｓ１０２否定）、選択ノードの子ノードに検索対象の座標を含むノードがあるか否かを、インデックスＤＢ１２ｂを参照して判定する（Ｓ１０３）。

その後、データ検索部１４は、選択ノードの子ノードに検索対象の座標を含むノードがないと判定した場合（Ｓ１０３否定）、全ての選択候補ノードの検索を終了したか否かを、インデックスツリーやインデックスＤＢ１２ｂから判定する（Ｓ１０４）。

データ検索部１４は、検索未実施の選択候補ノードが存在すると判定した場合（Ｓ１０４否定）、選択候補ノードの内の１つのノードを選択し、検索回数をインクリメントする（Ｓ１０５）。その後、データ検索部１４は、Ｓ１０２以降の処理を繰り返す。

また、Ｓ１０２において、データ検索部１４は、選択したノードが葉ノードであると判定した場合（Ｓ１０２肯定）、選択した葉ノードにある多次元データのうち、検索座標を含むデータを検索結果に追加し（Ｓ１０６）、Ｓ１０４以降の処理を実行する。例えば、データ検索部１４は、選択した葉ノードが有する多次元データのＩＤまたはポインタを用いて多次元データＤＢ１２ｃを検索し、検索座標を含むデータを検索結果に追加する。

また、Ｓ１０３において、データ検索部１４は、選択ノードの子ノードに検索対象の座標を含むノードがあると判定した場合（Ｓ１０３肯定）、検索座標を含む子ノードを選択候補ノードに加えて（Ｓ１０７）、Ｓ１０４以降の処理を実行する。なお、選択候補ノードのリスト等は、作業領域１２ａで管理される。

また、Ｓ１０４において、データ検索部１４は、検索未実施の選択候補ノードが存在しないと判定した場合（Ｓ１０４肯定）、選択済みの座標データを検索結果として応答し（Ｓ１０８）、処理を終了する。

（追加処理）
図１８と図１９は、実施例１に係る追加処理の流れを説明するフローチャートである。図１８に示すように、データやノードの追加を指示されたデータ更新部１５は、ルートノードを選択し（Ｓ２０１）、インデックスＤＢ１２ｂ等を参照して、選択した選択ノードが葉ノードか否かを判定する（Ｓ２０２）。

データ更新部１５は、選択ノードが葉ノードではないと判定した場合（Ｓ２０２否定）、選択ノードの子ノードに、追加データの領域を包含するデータがあるか否かを、インデックスＤＢ１２ｂ等を参照して判定する（Ｓ２０３）。

そして、データ更新部１５は、追加データの領域を包含するデータがないと判定した場合（Ｓ２０３否定）、追加対象の多次元データを含めるために必要な拡大量が最小になる子ノードを選択ノードとして（Ｓ２０４）、Ｓ２０２以降の処理を実行する。

また、Ｓ２０３において、データ更新部１５は、追加データの領域を包含するデータがあると判定した場合（Ｓ２０３肯定）、追加対象の多次元データを包含する子ノードのうち矩形面積が最小のものを選択ノードとする（Ｓ２０５）。その後、データ更新部１５は、Ｓ２０２以降の処理を実行する。

一方、Ｓ２０２において、データ更新部１５は、選択ノードが葉ノードであると判定した場合（Ｓ２０２肯定）、図１９に示すように、選択した葉ノードに追加対象の多次元データを追加するとともに当該葉ノードの更新回数をインクリメントする（Ｓ２０６）。

続いて、分割統合判定部１６ａは、記憶部１２やインデックスＤＢ１２ｂを参照し、選択した葉ノードの持つ多次元データ数が上限値を超えるか否かを判定し（Ｓ２０７）、超えない場合（Ｓ２０７否定）には、処理を終了する。

さらに、分割統合判定部１６ａが、選択した葉ノードの持つ多次元データ数が上限値を超えると判定した場合（Ｓ２０７肯定）、多次元データ検索サーバ１０はＳ２０８を実行する。すなわち、更新指数算出部１６ｂは、選択ノードの更新回数と検索回数とに基づいて更新指数を算出し、分割統合制御部１６ｃは、算出された更新指数が所定値よりも大きい場合（Ｓ２０８否定）には、当該選択ノードの分割を抑止して処理を終了する。一方、分割統合制御部１６ｃは、算出された更新指数が所定値よりも小さい場合（Ｓ２０８肯定）には、データ更新部１５に当該選択ノードの分割を許可する。

分割が許可されたデータ更新部１５は、分割結果の矩形の大きさの和が最小となるようにノードを２分割し、親ノードに追加する（Ｓ２０９）。このとき、データ更新部１５は、インデックスＤＢ１２ｂのインデックスツリーを更新する。

続いて、データ更新部１５は、更新／検索回数ＤＢ１２ｄに分割した新ノードのデータ用の行を追加し（Ｓ２１０）、元ノードの更新および変更回数を半分にして、分割した新ノードの更新および変更回数にも元ノードと同じ半分にした値を更新／検索回数ＤＢ１２ｄに登録する（Ｓ２１１）。

その後、分割統合判定部１６ａは、分割中のノードのデータ数が全て上限値以下でない場合（Ｓ２１２否定）、上限を超えている分割中ノードを１つ選択して（Ｓ２１３）、Ｓ２０９以降の処理を実行する。

一方、分割統合判定部１６ａは、分割中のノードのデータ数が全て上限値以下である場合（Ｓ２１２肯定）、追加する親ノードの持つ子ノード数が上限値を超えるか否かを判定する（Ｓ２１４）。そして、分割統合判定部１６ａは、追加する親ノードの持つ子ノード数が上限値を超えないと判定した場合（Ｓ２１４否定）、処理を終了し、追加する親ノードの持つ子ノード数が上限値を超えると判定した場合（Ｓ２１４肯定）、Ｓ２１５を実行する。

すなわち、Ｓ２０８と同様、分割統合制御部１６ｃは、更新指数算出部１６ｂが算出した更新指数が所定値よりも大きい場合（Ｓ２１５否定）には、当該選択ノードの分割を抑止して処理を終了する。一方、分割統合制御部１６ｃは、算出された更新指数が所定値よりも小さい場合（Ｓ２１５肯定）には、データ更新部１５に当該選択ノードの分割を許可する。

続いて、データ更新部１５は、インデックスＤＢ１２ｂや多次元データＤＢ１２ｃを参照し、追加する親ノードがルートノードである場合に（Ｓ２１６肯定）、現ルートノードを分割し、その上に新ルートノードを作成して（Ｓ２１７）、処理を終了する。一方、データ更新部１５は、追加する親ノードがルートノードでない場合に（Ｓ２１６否定）、親ノードを分割対象として（Ｓ２１８）、Ｓ２０９以降の処理を繰り返す。

（削除処理）
図２０と図２１は、実施例１に係る削除処理の流れを説明するフローチャートである。図２０に示すように、データ更新部１５は、データ検索部１４が図１７に示した処理によって特定した削除対象データを葉ノードから削除する（Ｓ３０１、Ｓ３０２）。なお、データ更新部１５は、多次元データに自身が含まれる葉ノードの情報を記録し、削除時にはデータＩＤなどから削除対象のデータを多次元データＤＢ１２ｃから取得して、葉ノードを辿っても良い。この場合、データ更新部１５は、葉ノードの分割・統合時にデータに記録する葉ノードを書き直すことになる。

このとき、データ更新部１５は、インデックスＤＢ１２ｂや多次元データＤＢ１２ｃから、削除対象データを削除する。続いて、データ更新部１５は、データを削除した葉ノードの更新回数をインクリメントする（Ｓ３０３）。

そして、分割統合判定部１６ａは、データが削除された葉ノードが保持するデータ数が下限値未満か否かを、記憶部１２やインデックスＤＢ１２ｂを参照して判定する（Ｓ３０４）。分割統合判定部１６ａは、データ数が下限値未満でないと判定した場合（Ｓ３０４否定）、処理を終了し、分割統合判定部１６ａによってデータ数が下限値未満であると判定された場合（Ｓ３０４肯定）、Ｓ３０５が実行される。

すなわち、更新指数算出部１６ｂは、選択ノードの更新回数と検索回数とに基づいて更新指数を算出し、分割統合制御部１６ｃは、算出された更新指数が所定値よりも大きい場合（Ｓ３０５否定）には、当該選択ノードの統合を抑止して処理を終了する。一方、分割統合制御部１６ｃは、算出された更新指数が所定値よりも小さい場合（Ｓ３０５肯定）には、データ更新部１５に当該選択ノードの統合を許可する。

続いて、データ更新部１５は、対象ノードの兄弟ノードについて、対象ノードの矩形領域を追加したときの領域増加が最小となる兄弟ノードを選択して統合する（Ｓ３０６）。そして、データ更新部１５は、統合前のノードの更新および検索回数各々を、統合先のノードの更新および検索回数各々に追加する（Ｓ３０７）。

その後、データ更新部１５は、統合して削除したノードのエントリを更新／検索回数ＤＢ１２ｄから削除した後（Ｓ３０８）、当該ノードの親ノードの更新回数をインクリメントする（Ｓ３０９）。

そして、分割統合判定部１６ａによって統合ノードの子ノード数またはデータ数が上限値を超えると判定された場合（Ｓ３１０肯定）、データ更新部１５は、分割結果の矩形の大きさの和が最小となるように、統合ノードを再分割する（Ｓ３１１）。

続いて、データ更新部１５は、分割して増加したノードを親ノードに追加し（Ｓ３１２）、更新／検索回数ＤＢ１２ｄに、分割ノード用の行を追加する（Ｓ３１３）。そして、データ更新部１５は、元ノードの更新および検索回数を半分にし、分割ノードの更新および検索回数も同じ回数にした情報を更新／検索回数ＤＢ１２ｄに記録して処理を終了する（Ｓ３１４）。

図２１に示すように、分割統合判定部１６ａは、統合ノードの子ノード数またはデータ数が上限値を超えないと判定された場合（Ｓ３１０否定）、親ノードがルートノードであるか否かを判定する（Ｓ３１５）。そして、分割統合判定部１６ａは、親ノードがルートノードでない場合（Ｓ３１５否定）、親ノードの子ノード数が下限値未満か否かを判定する（Ｓ３１６）。

親ノードの子ノード数が下限値未満と判定された場合（Ｓ３１６肯定）、Ｓ３１７が実行される。すなわち、更新指数算出部１６ｂは、選択ノードの更新回数と検索回数とに基づいて更新指数を算出し、分割統合制御部１６ｃは、算出された更新指数が所定値よりも大きい場合（Ｓ３１７否定）には、当該選択ノードの統合を抑止して処理を終了する。一方、分割統合制御部１６ｃは、算出された更新指数が所定値よりも小さい場合（Ｓ３１７肯定）には、データ更新部１５に当該選択ノードの統合を許可する。データ更新部１５は、親ノードを統合対象として（Ｓ３１８）、Ｓ３０６以降の処理を実行する。

また、Ｓ３１６において、親ノードの子ノード数が下限値以上と判定された場合（Ｓ３１６否定）、データ更新部１５は、処理を終了する。

また、Ｓ３１５において、親ノードがルートノードである場合（Ｓ３１５肯定）、データ更新部１５は、ルートノードの子ノード数が１つにならない場合（Ｓ３１９否定）、処理を終了する。

一方、データ更新部１５は、ルートノードの子ノード数が１つになる場合（Ｓ３１９肯定）、現ルートノードを削除し、統合結果のノードを新規ルートノードとする（Ｓ３２０）。その後、データ更新部１５は、前ルートノードのエントリを更新／検索回数ＤＢ１２ｄから削除して処理を終了する（Ｓ３２１）。

［実施例１による効果］
実施例１によれば、更新指数の高い領域については、負荷の高いインデックス更新処理、すなわちノードの分割処理を抑止することで、多次元データ検索サーバ１０の処理負荷を軽減する。この結果、多次元データ検索サーバ１０は、分割処理を抑止したツリーについては、その部分だけ更新に時間がかかる場合もあるが、ツリー全体としては検索処理性能を向上させることができる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。

（閾値例）
例えば、上記実施例では、分割または統合を実行するまたは抑止する判定に用いる子ノード数の上限値および下限値は、サーバ管理者によって予め定められた所定の値であったが、更新／検索回数の比の関数とすることもできる。例えば、更新／検索回数＝Ｒとして、上限値Ｌｍａｘを「Ｌｍａｘ＝２×Ｒ＋５」とすることもできる。同様に、更新／検索回数＝Ｒとして、上限値Ｌｍａｘを「Ｌｍｉｎ＝５−２×Ｒ」とすることもできる。つまり、「更新指数＝更新回数／検索回数＝Ｒ＝２」の場合、上限値（Ｌｍａｘ）は９となり、下限値（Ｌｍｉｎ）は１となる。

したがって、多次元データ検索サーバは、インデックスツリーのあるノードについて分割対象か否かを判定する場合には、まず、上限値Ｌｍａｘを算出する。続いて、多次元データ検索サーバは、ノードが管理するデータ又は当該ノードの子ノードの数が算出した上限値Ｌｍａｘよりも多い場合には、分割対象のノードとして特定し、特定したノードについて分割処理または統合処理の実行を判断することができる。また、多次元データ検索サーバは、特定したノードについて、更新指数を算出して分割を実行または抑止することもできる。

同様に、多次元データ検索サーバは、インデックスツリーのあるノードについて統合対象か否かを判定する場合には、まず、下限値Ｌｍｉｎを算出する。続いて、多次元データ検索サーバは、ノードが管理するデータ又は当該ノードの子ノードの数が算出した下限値Ｌｍｉｎよりも少ない場合には、統合対象のノードとして特定する。その後、多次元データ検索サーバは、特定したノードについて、更新指数を算出して統合を実行または抑止することもできる。

別の手法としては、多次元データ検索サーバは、インデックスツリーのあるノードについて分割または統合対象か否かを判定する場合には、まず、上限値Ｌｍａｘと下限値Ｌｍｉｎを算出する。そして、多次元データ検索サーバは、ノードが管理するデータ又は当該ノードの子ノードの数が上限値から下限値の範囲内である場合には、分割または統合を抑止する。一方、多次元データ検索サーバは、ノードが管理するデータ又は当該ノードの子ノードの数が上限値から下限値の範囲内にない場合には、分割または統合を実行するようにすることもできる。つまり、多次元データ検索サーバは、上限値Ｌｍａｘと下限値Ｌｍｉｎを、分割または統合を抑止する判断材料とすることもできる。

なお、この例では、上限値Ｌｍａｘを計算する関数を頻度比Ｒの一次関数としたが、高次関数や指数関数などを用いることもできる。同様に、下限値ＬｍｉｎについてもＲの高次関数や指数関数とすることもできる。この時、頻度比Ｒが増えるにしたがって上限値は単調増加するよう、また下限値が単調減少するように定める。

また、分割するかしないかの判断に用いられる更新指数の上限値と、統合するかしないかの判断に用いられる上限値は、同じ値であっても良いし、統合処理と分割処理の負荷を考慮して異なる値としても良い。この場合、より負荷の高い処理に対応する上限値の方を、なるべく処理を控えるべきであるので、上限値の値を小さくすることが好ましい。

また、上記実施例では、更新回数／検索回数を更新指数として算出する例について説明したが、これに限定されるものではない。例えば、上述した例と同様、指数関数などの公知の関数を用いることもできる。また、更新頻度が多いノードか否かを判定する任意にお関数等を用いることもできる。

（サービス例１）
上述した多次元データ検索サーバを用いたサービス形態の例について説明する。図２２は、多次元データ検索サーバを用いたサービス例１を示す図である。図２２は、事故情報共有サービスである。一例としては、事故警告サービスの利用者が月額３００円などの利用料を払って、車両の位置情報を送り、周辺に事故があった際に警告情報を受け取ることができる。

具体的には、車両位置収集サーバが各車両から位置情報を収集して多次元データ検索サーバに送信する。多次元データ検索サーバは、各車両の位置情報のインデックスツリーを生成する。事故警告サービスサーバは、周辺検索（事故座標、半径１００ｍ）などの要求を多次元データ検索サーバに送信する。多次元データ検索サーバは、事故があった座標から半径１００ｍ内に存在する車両の情報を事故警告サービスサーバに送信する。事故警告サービスサーバは、多次元データ検索サーバから通知された各車両に対して運転注意を警告する。このようにすることで、車両の安全運転を促進するサービスを提供することができる。

（サービス例２）
上述した多次元データ検索サーバを用いたサービス形態の例について説明する。図２３は、多次元データ検索サーバを用いたサービス例２を示す図である。図２３は、業務端末管理サービスである。一例を挙げると、業務端末を管理する主体が、サーバを用意して業務管理端末の位置情報を管理する。そして、業務端末は、周囲の業務端末を検索して不足機能の補助依頼やオペレータへのヘルプ通知を送信する。

具体的には、端末位置収集サーバが各端末から位置情報を収集して多次元データ検索サーバに送信する。多次元データ検索サーバは、各端末の位置情報のインデックスツリーを生成する。業務端末は、多次元データ検索サーバに対して、自端末の周辺検索（端末座標、半径１００ｍ）を送信する。多次元データ検索サーバは、受信した端末座標から半径１００ｍに位置する端末を特定して、業務端末に応答する。業務端末は、受信した端末に対して不足機能の補助依頼やオペレータへのヘルプ通知を送信する。

（データ例）
上記実施例では、データと２次元データの例を説明したが、これに限定されるものではなく、例えばさらに高さや時間軸を入れた３次元データであってもよい。すなわち、開示する多次元データ検索サーバで管理できるデータの次元は、２次元に限定されるものではない。

（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

（プログラム）
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。

図２４は、インデックス管理プログラムを実行するコンピュータのハードウェア構成例を示す図である。図２４に示すように、コンピュータ１００は、バス１０１に、ＣＰＵ１０２、入力装置１０３、出力装置１０４、通信インタフェース１０５、記録媒体読み取り装置１０６、ＨＤＤ（Hard Disk Drive）１０７、ＲＡＭ（Random Access Memory）１０８が接続される。

入力装置１０３は、マウスやキーボードであり、出力装置１０４は、ディスプレイなどであり、通信インタフェース１０５は、ＮＩＣ（Network Interface Card）などのインタフェースである。ＨＤＤ１０７は、インデックス管理プログラム１０７ａととともに、図７等に示した各テーブル等に記憶される情報を記憶する。記録媒体の例としてＨＤＤ１０７を例に挙げたが、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ等の他のコンピュータが読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、記憶媒体を遠隔地に配置し、コンピュータが、その記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのコンピュータ自身の記録媒体に格納して用いてもよい。

ＣＰＵ１０２は、インデックス管理プログラム１０７ａを読み出してＲＡＭ１０８に展開することで、図７等で説明した各機能を実行するインデックス管理プロセス１０８ａを動作させる。すなわち、インデックス管理プロセス１０８ａは、図７に記載したデータ検索部１４、データ更新部１５、ノード制御部１６の各処理部と同様の機能を実行する。このようにコンピュータ１００は、プログラムを読み出して実行することでインデックス管理方法を実行する情報処理装置として動作する。

例えば、コンピュータ１００は、記録媒体読み取り装置１０６によって記録媒体からインデックス管理プログラムを読み出し、読み出されたインデックス管理プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、コンピュータ１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

１０ 多次元データ検索サーバ
１１ 通信インタフェース
１２ 記憶部
１２ａ 作業領域
１２ｂ インデックスＤＢ
１２ｃ 多次元データＤＢ
１２ｄ 更新／検索回数ＤＢ
１３ 制御部
１４ データ検索部
１５ データ更新部
１６ ノード制御部
１６ａ 分割統合判定部
１６ｂ 更新指数算出部
１６ｃ 分割統合制御部

Claims (6)

1. コンピュータが、
   空間を最小外接領域に分割して前記空間に存在するデータのインデックスをツリー構造で生成し、
   前記ツリー構造を形成するノードごとに、当該ノードが検索された数を計数し、
   前記ノードごとに、当該ノードが管理するデータ又は当該ノードの子ノードが更新された数を計数し、
   前記データの数または子ノードの数に基づいて特定したノードについて、計数した更新回数と検索回数とを用いて更新指数を算出し、
   算出した更新指数に基づいて、前記特定したノードの分割または統合処理の実行を抑止する
   ことを実行するインデックス管理方法。
2. 前記更新指数を算出する処理は、
   前記計数した更新回数を前記計数した検索回数で除算した値を更新指数として算出し、
   前記ノードの分割を実行または抑止する処理は、前記算出した更新指数が所定値より大きい場合には、前記特定したノードの分割または統合を抑止し、前記算出した更新指数が所定値より小さい場合には、前記特定したノードの分割または統合を実行することを特徴とする請求項１に記載のインデックス管理方法。
3. 前記更新指数を算出する処理は、前記データの数または子ノードの数が、前記計数した更新回数と検索回数との比を用いる所定関数で算出した上限値よりも多いノード、または、前記計数した更新回数と検索回数との比を用いる所定関数で算出した下限値よりも少ないノードについて、ノードの分割または統合処理を実行または抑止することを特徴とする請求項１または２に記載のインデックス管理方法。
4. コンピュータが、
   空間を最小外接領域に分割して前記空間に存在するデータのインデックスをツリー構造で生成し、
   前記ツリー構造を形成するノードごとに、当該ノードが検索された数を計数し、
   前記ノードごとに、当該ノードが管理するデータ又は当該ノードの子ノードが更新された数を計数し、
   前記データの数または子ノードの数が、前記計数した更新回数と検索回数との比を用いる所定関数で算出した値を満たさない場合に、前記特定したノードの分割または統合処理の実行を抑止する
   ことを実行するインデックス管理方法。
5. コンピュータが、
   空間を最小外接領域に分割して前記空間に存在するデータのインデックスをツリー構造で生成し、
   前記ツリー構造を形成するノードごとに、当該ノードが検索された数を計数し、
   前記ノードごとに、当該ノードが管理するデータ又は当該ノードの子ノードが更新された数を計数し、
   前記データの数または子ノードの数に基づいて特定したノードについて、計数した更新回数と検索回数とを用いて更新指数を算出し、
   算出した更新指数に基づいて、前記特定したノードの分割または統合処理の実行を抑止する
   ことを実行させるインデックス管理プログラム。
6. 空間を最小外接領域に分割して前記空間に存在するデータのインデックスをツリー構造で生成する生成部と、
   前記ツリー構造を形成するノードごとに、当該ノードが検索された数を計数する第１計数部と、
   前記ノードごとに、当該ノードが管理するデータ又は当該ノードの子ノードが更新された数を計数する第２計数部と、
   前記データの数または子ノードの数に基づいて特定されたノードについて、前記第２計数部によって計数された更新回数と前記第１計数部によって計数された検索回数とを用いて更新指数を算出する算出部と、
   前記算出部によって算出された更新指数に基づいて、前記特定されたノードの分割または統合処理の実行を抑止する実行制御部と
   を有することを特徴とするインデックス管理装置。

Images