JP4933222B2

JP4933222B2 - インデックス処理方法及び計算機システム

Info

Publication number: JP4933222B2
Application number: JP2006309144A
Authority: JP
Inventors: 俊彦樫山; 格西澤
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2006-11-15
Filing date: 2006-11-15
Publication date: 2012-05-16
Anticipated expiration: 2026-11-15
Also published as: US20080114787A1; US7941413B2; JP2008123426A

Description

本発明は、リアルタイムストリームデータ等の挿入・削除が高頻度のデータ、特に、インデックスキー値が、ゆらぎを含む増加・減少傾向であるデータ、及びキー傾向が入れ替わるデータに対するインデックス構築方法に関する。

ストレージ装置に格納されたデータに対する処理を実行するデータベース管理システム（以下、ＤＢＭＳとする）に対して、時々刻々と到着するデータをリアルタイム処理するデータ処理システムに対する要求が高まっている。例えば、株式の売買を行うシステムでは、株価の変動にいかに迅速に反応できるかがシステムの最重要の課題の一つであり、従来のＤＢＭＳのように株式のデータを一旦記憶装置に格納してから、該格納データに関して検索を行うような方法では、株価変動のスピードに即応できず、ビジネスチャンスを逃してしまうことになりかねない。例えば、特許文献１では、記憶されているクエリが周期的に実行される機構を開示しているが、株価のようにデータが入ってきた瞬間にクエリを実行することが重要なリアルタイムデータ処理には適用が困難であった。

このような時々刻々と到着するデータをストリームデータと定義し、該ストリームデータのリアルタイム処理に好適なデータ処理システムとして、ストリームデータ処理システムが提案されている。例えば、非特許文献１には、ストリームデータ処理システムＳＴＲＥＡＭが開示されている。

ストリームデータ処理システムでは、従来のＤＢＭＳとは異なり、まずクエリ（問い合わせ）をシステムに登録し、データの到来と共に該クエリが継続的に実行される。前記ＳＴＲＥＡＭでは、ストリームデータを効率的に処理するために、ストリームデータの一部を切り取るスライディングウィンドウと呼ばれる概念を導入している。スライディングウィンドウ指定を含むクエリの記述言語の好適な例としては非特許文献１に開示されているＣＱＬ（ＣｏｎｔｉｎｕｏｕｓＱｕｅｒｙＬａｎｇｕａｇｅ）をあげることができる。ＣＱＬは、ＤＢＭＳで広く用いられているＳＱＬ（ＳｔｒｕｃｔｕｒｅｄＱｕｅｒｙＬａｎｇｕａｇｅ）のＦＲＯＭ句に、ストリーム名に続いて括弧を用いることにより、スライディングウィンドウを指定する拡張が施されている。ＳＱＬに関しては、非特許文献２に開示されるものが知られている。上記スライディングウィンドウを指定する代表的な方法としては、（１）切り取るデータ列の数を指定する方法、そして（２）切り取るデータ列の時間間隔を指定する方法の２種類をあげることができる。例えば、非特許文献１の第二節に示された“Ｒｏｗｓ５０Ｐｒｅｃｅｄｉｎｇ”は５０行分のデータを処理対象として切り取る（１）の好適な例であり、そして“Ｒａｎｇｅ１５ＭｉｎｕｔｅｓＰｒｅｃｅｄｉｎｇ”は１５分間分のデータを処理対象として切り取る（２）の好適な例である。スライディングウィンドウによって切り取られたストリームデータはメモリ上に保持され、クエリ処理に使用される。

処理を高速化するため、従来のＤＢＭＳでは、Ｂ木インデックスなどのインデックスを構築していた。Ｂ木インデックスは非特許文献３に開示されるものが知られている。B木インデックスに対し、キーの値が単調増加であるデータを挿入していく場合、キー数が半分となるようにノード分割が行われるため、インデックスの半分の領域が使われない問題がある。この問題を解決する手段として、キー挿入位置でアンバランスにノード分割を行うことで単調増加データに対し、効率的なインデックスを構築する方法が提案されている。キー挿入位置でノード分割する手法は特許文献２に開示されている。

ストリームデータ処理システムは、ファイナンシャルアプリケーション、交通情報システム、トレーサビリティシステム、センサモニタリングシステム、計算機システム管理に代表される、リアルタイム処理が必要とされる応用に対する適用が期待されている。
米国特許第５，４９５，６００号公報米国特許第５，６４４，７６３号公報Ｒ．Ｍｏｔｗａｎｉ，Ｊ．Ｗｉｄｏｍ，Ａ．Ａｒａｓｕ，Ｂ．Ｂａｂｃｏｃｋ，Ｓ．Ｂａｂｕ，Ｍ．Ｄａｔａｒ，Ｇ．Ｍａｎｋｕ，Ｃ．Ｏｌｓｔｏｎ，Ｊ．Ｒｏｓｅｎｓｔｅｉｎ，ａｎｄＲ．Ｖａｒｍａ著："ＱｕｅｒｙＰｒｏｃｅｓｓｉｎｇ，ＲｅｓｏｕｒｃｅＭａｎａｇｅｍｅｎｔ，ａｎｄＡｐｐｒｏｘｉｍａｔｉｏｎｉｎａＤａｔａＳｔｒｅａｍＭａｎａｇｅｍｅｎｔＳｙｓｔｅｍ"，ＩｎＰｒｏｃ．ｏｆｔｈｅ２００３Ｃｏｎｆ．ｏｎＩｎｎｏｖａｔｉｖｅＤａｔａＳｙｓｔｅｍｓＲｅｓｅａｒｃｈ（ＣＩＤＲ）、［online］、２００３年１月、［平成１８年１０月１２日検索］、インターネットURL＜http://infolab.usc.edu/csci599/Fall2002/paper/DS1_datastreammanagementsystem.pdf＞Ｃ．Ｊ．Ｄａｔｅ，ＨｕｇｈＤａｒｗｅｎ著："ＡＧｕｉｄｅｔｏＳＱＬＳｔａｎｄａｒｄ（４ｔｈＥｄｉｔｉｏｎ）"，米国、Ａｄｄｉｓｏｎ−ＷｅｓｌｅｙＰｒｏｆｅｓｓｉｏｎａｌ発行、１９９６年１１月８日発行，ＩＳＢＮ：０２０１９６４２６０Ｒ．Ｅｌｍａｓｒｉ，Ｓ．Ｂ．Ｎａｖａｔｈｅ著："ＦｕｎｄａｍｅｎｔａｌｓｏｆＤａｔａｂａｓｅＳｙｓｔｅｍｓ，３ｒｄｅｄｉｔｉｏｎ、米国、Ａｄｄｉｓｏｎ−ＷｅｓｌｅｙＰｒｏｆｅｓｓｉｏｎａｌ発行、１９９９年８月発行、ＩＳＢＮ：０８０５３１７５５４Ｔ．Ｊ．ＬｅｈｍａｎａｎｄＭ．Ｊ．Ｃａｒｅｙ，Ａｓｔｕｄｙｏｆｉｎｄｅｘｓｔｒｕｃｔｕｒｅｓｆｏｒｍａｉｎｍｅｍｏｒｙｄａｔａｂａｓｅｍａｎａｇｅｍｅｎｔｓｙｓｔｅｍｓ．ＩｎＰｒｏｃ．ｏｆｔｈｅＩｎｔ‘ｌＣｏｎｆ．ｏｎＶｅｒｙＬａｒｇｅＤａｔａｂａｓｅｓ，ｐａｇｅｓ２９４−３０３、［online］、１９８６年８月、［平成１８年１０月１２日検索］、インターネットURL＜http://www.sigmod.org/vldb/conf/1986/P294.PDF＞

ストリームデータ処理、若しくはデータベース処理を高速化するため、インデックスを構築する必要があるが、次々と挿入・削除されるデータに対し、ノード分割が多発すると性能上問題がある。場合によっては、インデックスを構築するメモリ量が不足し、インデックスの再構築が必要になり、リアルタイム処理ができなくなる、ストリームデータ処理が止まってしまうなどの問題が発生する。そのため、インデックスのノード分割回数を減少させたり、ノード分割の処理コストを低くするなど、前記インデックスのメンテナンスコストを低くする必要がある。従来、B木インデックスに対し、キーの挿入位置でアンバランスにノードをノード分割することで、単調増加データに対し、インデックス容量が小さなインデックスを構築する方法が開示されている。しかし、上記キー挿入位置でノード分割するインデックス処理方法には、次のような問題がある。

（１）センサモニタリングデータ、例えば、温度データは一定間隔の間、上がり続けるが、一度温度が下がった後にまた上がり続けるなど、全体としては増加傾向となるものの、単調増加とはならない。また、製品などのＩＤ情報に関して、１ずつ増加するようにＩＤを設定する場合も、ＩＤ情報を処理する場合に、１ずつ増加するとは限らず、ＩＤ情報の順番が入れ替わる場合がある。このような全体的には増加傾向、または減少傾向となっているが、ゆらぎを含むデータに対し、上記キー挿入位置でノード分割するインデックス処理方法を適用すると、ゆらぎを含むデータが到着した場合に、更なるノード分割を引き起こす場合があり、前記更なるノード分割が発生した場合に、インデックス容量も大きくなってしまうことが課題となっていた。

（２）センサモニタリングデータは、例えば、温度データは一定間隔の間、上がり続けるが、その後下がっていく周期的な変化をする場合があり、気温データは、夜から昼にかけて温度が上昇し、昼から夜にかけて温度が下降する。すなわち、データの傾向が時間により入れ替わる。このような傾向が入れ替わるデータに対し、上記キー挿入位置でノード分割するインデックス処理方法を適用すると、傾向が入れ替わった際にノード分割が多発する問題があり、インデックス容量も大きくなってしまうことが課題となっていた。

本発明は上記問題点に鑑みてなされたものであり、本発明の第１の目的は、キーの値が完全な単調増加、または完全な単調減少とならないゆらぎを含むデータに対し、インデックス容量が小さく、高速処理が可能なインデックスを提供することである。また、本発明の第２の目的は、増加傾向、減少傾向が入れ替わるデータに対し、インデックス容量が小さく、高速処理が可能なインデックスを提供することである。

本発明は、前記第１、及び第２の目的を達成するため、インデックスキーの傾向に基づいて、ノード分割時におけるキー配分割合を表すノードの分割割合を変更する。ノードの分割割合は、予め設定した値、または、演算により求めた値により決定する。キー傾向・分布は、（１）ユーザによって入力される時間とキー傾向の組合せで表現されるストリームデータの特性情報、及び（２）ストリームデータのモニタリングによって取得する監視情報により決定する。

また、上記の目的を達成するための別の手段として、（１）前記インデックス全体におけるノードの位置を表すノード位置を用いて、ノード分割割合を決定する手段、（２）キー傾向、及びキー挿入位置からノード分割割合を動的に変更する手段、（３）過去のノード分割割合を保持する分割履歴情報を用いてノード分割割合を決定する手段を提供する。

さらに、算出したキー傾向が実際のキー傾向と異なることを検知するため、前記ストリームデータのモニタリングによって取得するデータレート情報、前記インデックスのモニタリングによって取得する分割回数情報に基づいてノード分割が多発していることを検知する手段を提供する。

本発明を適用することにより、インデックス容量が小さく、高速処理が可能なインデックスが実現できる。これにより、高速で検索可能なストリームデータ処理またはデータベース処理を実現することができる。

以下、本発明の実施の形態について説明する。

図１は本発明の一実施形態が適用されたストリームデータ処理システム、及び関連するシステム構成を示すブロック図である。

図１において、ストリームデータ処理システム１００は、ＲＦＩＤリーダ１０４、またはセンサノード１０５、または計算機１０６上で実行されるアプリケーション１０７からリアルタイムに送信された情報をストリームデータ１０８として入力とし、ユーザ１０１、または計算機１０２上で実行されるアプリケーション１０３により入力されたコマンドに基づき、入力されたストリームデータ１０８を有意な情報に変換して、出力結果１８０を生成し、ユーザ１８１、または計算機１８２上で実行されるアプリケーション１８３へ提供するストリームデータ処理を実行する計算機（またはサーバ）である。ストリームデータは複数のストリームデータ１０８₁、１０８₂、・・・、１０８_lから構成される。

前記計算機１０２は、ネットワーク１０９を介してストリームデータ処理システム１００に接続されている。ネットワーク１０９は、イーサネット（登録商標）、光ファイバ、ＦＤＤＩ（ＦｉｂｅｒＤｉｓｔｒｉｂｕｔｅｄＤａｔａＩｎｔｅｒｆａｃｅ）等で接続されるローカルエリアネットワーク（ＬＡＮ）、若しくはＬＡＮよりも低速なインターネットを含んだワイドエリアネットワーク（ＷＡＮ）でも差し支えない。

ここで、前記ストリームデータ処理システム１００、前記計算機１０２、前記計算機１０６、前記計算機１８２は、パーソナルコンピュータ、ワークステーションなどの任意のコンピュータシステムで構成され、同一の計算機でも異なる計算機でも構わない。また、前記アプリケーション１０３、前記アプリケーション１０７、前記アプリケーション１８３は、同一のアプリケーションでも異なるアプリケーションでも構わない。また、前記ユーザ１０１、前記ユーザ１８１は同一のユーザでも異なるユーザでも構わない。

ここで、本実施形態で扱うストリームデータ１０８は、映像や音声の配信で用いられるストリームとは異なり、ひとつのストリームデータが有意な情報に対応するものである。また、ストリームデータ処理システム１００がＲＦＩＤリーダ１０４、またはセンサノード１０５、または計算機１０６上で実行されるアプリケーション１０７から前記ストリームデータ処理システム１００が受信するストリームデータ１０８は、連続的あるいは間欠的であり、ストリームデータ毎に異なる製品の情報や異なる要素が含まれる。

ストリームデータ処理システム１００は、コマンド入力部１１０、問合せ管理部１２０、ストリームデータ特性情報管理部１３０、ストリームデータ監視情報管理部１４０、インデックス管理部１５０、記憶装置１６０、問合せ実行部１７０から構成される。

コマンド入力部１１０は、前記ユーザ１０１、または前記計算機１０２上で実行されるアプリケーション１０３により入力されたコマンドを受け付ける。次に、問合せ管理部１２０は、前記コマンド入力部１１０で受け付けた前記ストリームデータを有意な情報に変換する処理内容を表す問合せを管理する。次に、ストリームデータ特性情報管理部１３０は、前記コマンド入力部１１０で受け付けたストリームデータの属性値の傾向や分布など、ストリームデータの属性値の特徴を表すストリームデータの特性情報を管理する。

次に、ストリームデータ監視情報管理部１４０は、前記ストリームデータ処理システム１００に入力されるストリームデータ１０８を監視し、ストリームデータ１０８の統計情報などのストリームデータに係る情報を表す監視情報を取得し、管理する。次に、インデックス管理部１５０は、記憶装置１６０におけるインデックス１６２のノード分割時におけるキー配分割合を表すノード分割割合などのインデックスに係る情報を表すインデックス情報を管理する。

次に、記憶装置１６０は、前記ストリームデータ１０８、及び前記ストリームデータ１０８に対するインデックスを保存している。ここで、記憶装置１６０は、メモリ、ディスク、テープ、フラッシュメモリなどのいかなる記憶媒体で構わない。また、記憶装置１６０は、複数の記憶媒体から構成される階層構造となっていてもよい。問合せ実行部１７０は、前記記憶装置１６０に保存されているストリームデータ１０８の情報を有意な情報に変換してから出力する。

ここで、ストリームデータ処理システム１００のハードウェア環境を図２に示す。ストリームデータ処理システム１００は、ひとつの計算機で実行され、演算処理を行うＣＰＵ１１と、ストリームデータ１０８やストリームデータ処理のプログラムを格納するメモリ１２と、データを格納するディスク装置１３と、ＣＰＵ１１とディスク装置１３やネットワーク１０９を接続するインターフェース１４を含んでいる。

ネットワーク１０９には、ストリームデータ処理システム１００に対してコマンドを入力する計算機１０２と、ストリームデータ処理システム１００が出力する出力結果１８０を利用する計算機１８２が接続される。

また、ネットワーク１０９には、ストリームデータ１０８を出力する計算機１０６と、センサノード１０５及びＲＦＩＤ（Radio Frequency Identification）リーダ１０４が接続される。計算機１０６は、例えば、製品番号などを出力し、センサノード１０５は環境の測定結果（例えば、温度）を出力し、ＲＦＩＤリーダ１０４は読み取ったRFIDタグの情報を出力する。これらの出力がストリームデータ１０８として、ストリームデータ処理システム１００へ入力される。

ここで、上記図１に示した記憶装置１６０は、メモリ１２の所定の領域とディスク装置１３の所定の領域から構成される。ストリームデータ１０８は、インデックスと共に主にメモリ１２上の記憶装置１６０に格納され、問い合わせに対して高速な検索を可能にする。時々刻々と変化するストリームデータ１０８には、検索対象となるデータをメモリ１２上の記憶装置１６０に格納しておき、検索の用途が済んだデータはディスク装置１３上の記憶装置１６０に格納することができる。例えば、ストリームデータ１０８がセンサノード１０５の測定値（温度など）の場合、ユーザ１８１が監視したい測定値は本日の値であり、昨日以前のものは高速に検索できなくても問題は生じない。このため、本日の測定値をメモリ１２上に格納し、昨日以前の測定値をアーカイブとしてディスク装置１３上に格納することができる。

図１において、本発明の概要を説明する。ストリームデータ処理システム１００は、ユーザ１０１、または計算機１０２上で実行されるアプリケーション１０３が入力した問合せに基づいて、入力されるストリームデータ１０８を有意な情報に変換する。ここで、有意な情報とは、例えば、センサノード１０５の測定値は、バイナリ値のままではユーザ１０１，１８１が理解できないので、所定の単位系を加えた数値に変換した情報である。

そして、ストリームデータの検索処理を高速化するため、前記ストリームデータ１０８に対しインデックス１６２を用意し、前記インデックス１６２を介して、問合せ実行部１７０は前記ストリームデータ１０８を読み出す。その際に、ユーザ１０１、または計算機１０２で実行されるアプリケーション１０３は、前記インデックス１６２のインデックスキーの値の傾向やインデックスキーの値の分布をストリームデータ特性情報管理部１３０に入力し、インデックスのノード分割割合をインデックス管理部１５０に入力する。さらに、前記インデックス１６２は、前記ストリームデータ１０８のインデックスキーの傾向に基づいて、前記インデックス１６２のノード分割割合を変更する。これにより、インデックスに必要な領域を最小限とし、かつ高速にストリームデータ１０８を処理することが可能となるのである。

以下では、前記ストリームデータ処理システム１００の構成を詳細に説明する。

コマンド入力部１１０は、ユーザ１０１、または計算機１０２上で実行されるアプリケーションから入力されるコマンドを受け付けるインターフェース（以下、Ｉ／Ｆ）を備える。前記コマンドが問合せに係るコマンドの場合、コマンド入力部１１０は問合せ管理部１２０にコマンド内容を出力する。また、ストリームデータ１０８の特性情報に係るコマンドの場合、コマンド入力部１１０は、ストリームデータ特性情報管理部１３０にコマンド内容を出力する。また、コマンド入力部１１０は、ストリームデータの監視情報に係るコマンドの場合、ストリームデータ監視情報管理部１４０にコマンド内容を出力し、インデックスに係るコマンドの場合、インデックス管理部１５０にコマンド内容を出力する。

問合せ管理部１２０は、問合せ設定部１２１、問合せ管理テーブル１２２から構成される。問合せ設定部１２１は、前記コマンド入力部１１０から入力された前記問合せを登録または変更するコマンドを表す問合せ登録・変更コマンドを受け付け、問合せ管理テーブル１２２を更新する。また、前記問合せコマンドに対応するストリームデータの処理内容を表す実行木１７４を生成・変更する。なお、問合せ設定部１２１は、生成した実行木１７４を問い合わせ実行部１７０に送信し、格納させる。問合せ管理テーブル１２２は、前記問合せ設定部１２１で設定された情報を後述するように保持するテーブルである。

前記ストリームデータ特性情報管理部１３０は、特性情報設定部１３１、特性情報管理テーブル１３２から構成される。

特性情報設定部１３１は、前記コマンド入力部１１０から入力された前記ストリームデータの特性情報を設定または変更するコマンドを表す特性情報設定コマンドを受け付け、特性情報管理テーブルを更新する。特性情報管理テーブル１３２は、前記特性情報設定部１３１で設定された情報を保持するテーブルである。

ストリームデータ監視情報管理部は、ストリームデータ監視部１４１、キー傾向予測部１４２、監視情報管理テーブル１４３から構成される。

ストリームデータ監視部１４１は、前記問合せ管理テーブル１２２を参照し、監視が必要なストリームデータ１０８を監視する。ストリームデータ監視部１４１は、監視の結果、前記監視情報を取得した場合、監視情報管理テーブル１４３を更新する。ここで、監視するストリームデータ１０８は、必要なものに限定せず、すべてのストリームデータの監視を行ってもよい。キー傾向予測部１４２は、前記監視情報管理テーブル１４３を参照し、前記ストリームデータ１０８の監視情報から、前記インデックスのキー傾向を予測し、監視情報管理テーブル１４３を更新する。監視情報管理テーブル１４３は、前記ストリームデータ監視部１４１において取得した前記監視情報、前記キー傾向予測部１４２で予測した前記キー傾向を保持するテーブルである。

インデックス管理部１５０は、インデックス管理テーブル１５１、インデックス設定部１５２、分割割合算出部１５３、インデックス監視情報管理テーブル１５４、インデックス監視部１５５、分割多発検知部１５６、分割履歴参照部１５７、読み出し順序制御部１５８から構成される。

インデックス設定部１５２は、前記コマンド入力部１１０から入力された前記ノード分割割合を設定または変更するコマンドを表すノード分割割合設定コマンドを受け付け、インデックス管理テーブル１５１を更新する。また、インデックス設定部１５２は、インデックス管理テーブル１５１を参照し、インデックス１６２のノード分割割合が変更となる場合、インデックス１６２に対し、分割割合変更命令を出力する。インデックス管理テーブル１５１は、前記インデックス設定部１５２で設定された前記インデックス情報を保持するテーブルである。

分割割合算出部１５３は、前記キー傾向、及び前記インデックス１６２におけるキーの挿入位置から前記ノード分割割合を後述するように算出する。そのため、前記キー傾向と前記ノード分割割合が1対1に対応せず、前記ノード分割割合が動的に決定される。

インデックス監視部１５５は、前記問合せ管理テーブル１２２、及び前記特性情報管理テーブル１３２を参照し、監視が必要な前記インデックス１６２を監視する。インデックス監視部１５５は、監視の結果、前記インデックス監視情報を取得した場合に、インデックス監視情報管理テーブル１５４を更新する。インデックス監視情報管理テーブル１５４は、前記インデックス監視部１５５で取得した前記インデックス監視情報を保持するテーブルであり、後述するように図１７のように構成される。なお、インデックス監視部１５５は所定の周期（例えば、５分）でインデックス１６２の監視を実行し、監視対象のインデックス１６２の情報を取得する。監視対象のインデックス１６２は、問合せ管理テーブル１２２に参照が設定されたデータ（ストリームデータ１０８）に対応するインデックス１６２や、特性情報管理テーブル１３２に設定されたカラム名カラム５０２のデータに対応するインデックス１６２が監視対象となる。

分割多発検知部１５６は、前記インデックス監視情報管理テーブル１５４を参照し、ノード分割が多発していないか判定する。ここで、ノード分割の多発とは、インデックス監視情報管理テーブル１５４のノード分割回数１００７が予め設定したしきい値を超えた場合に、分割多発検知部１５６がノード分割が多発したと判定する。そして、分割多発検知部１５６はノード分割が多発していると判定した場合、前記インデックス設定部１５２に、分割割合変更命令を出力する。インデックス設定部１５２は、分割割合変更命令を受けると、後述する図１８のように、記憶装置１６０のインデックスに対してキー傾向の再予測などの処理を実行する。

分割履歴参照部１５７は、前記インデックス監視情報管理テーブル１５４を参照し、時刻情報であるタイムスタンプ１００１と、前記ノード分割割合１００８とで表される分割履歴情報を用いて、分割多発検知部１５６がインデックス設定部１５２へ指令する前記ノード分割割合を決定する。

読み出し順序制御部１５８は、前記インデックス設定部１５２が、前記インデックス１６２の前記キーをページの各アドレスに割り当てる順序が通常か逆順かを表すフラグである読み込み順序フラグを備え、前記読み込み順序フラグに基づいて前記インデックス１６２の読み書き制御を行う。また、読み出し順序制御部１５８は、ノード分割が発生した場合に、前記キー傾向に基づいて前記読み込み順序フラグを設定する。なお、ページは、一時保存領域１６３に格納する一時保存データ１６４の集合である。

記憶装置１６０は、インデックス領域１６１、一時保存領域１６３から構成される。インデックス領域１６１は、インデックス１６２を格納する領域であり、インデックス１６２は、インデックス１６２₁、１６２₂、・・・、１６２_mから構成される。一時保存領域１６３は、一時保存データ１６４を格納する領域であり、一時保存データ１６４は、一時保存データ１６４₁、１６４₂、・・・、１６４_lから構成される。

ここで、前記一時保存データ１６４は、一時的に保存している前記ストリームデータ１０８を表す。また、前記問合せの実行途中結果、または前記問合せの実行結果（別の問合せで実行結果を用いる場合）も一時保存データ１６４として保存される。使用されなくなった一時保存データ１６４は、破棄されても、またはディスク装置１３等の外部記憶装置に保存されてもよい。

また、前記インデックス１６２は、前記一時保存データ１６４を高速に読み出すため用意される。前記インデックス１６２に対し、問い合わせ実行部１７０からインデックスキーで検索した場合に、インデックスキーと一致するデータ若しくはデータアドレスが提供される。インデックス処理方法の詳細は前述の非特許文献３に開示されているものが知られている。インデックスには、Ｂ木インデックス（Ｂ−ｔｒｅｅＩｎｄｅｘ）、Ｂ＋木インデックス（Ｂ＋−ｔｒｅｅＩｎｄｅｘ）、ハッシュインデックス（ＨａｓｈＩｎｄｅｘ）、Ｔ木インデックス（Ｔ−ｔｒｅｅＩｎｄｅｘ）などがある。上記のインデックスは、非特許文献４に開示されている。

本発明では、Ｂ木インデックス、Ｂ＋木インデックスなどの、インデックスキー挿入時にインデックスのノードにおいて格納可能なキー数上限を上回った場合にノード分割する多分木のインデックスを対象とする。なお、ノードに格納可能なキーの上限数は、予め設定した値である。

問合せ実行部１７０は、スケジューラ１７１、一時保存領域管理部１７２、実行木プール領域１７３から構成される。実行木プール領域１７３は実行木１７４から構成され、実行木１７４は、複数の実行木１７４₁、１７４₂、・・・、１７４_nから構成される。

実行木１７４は、ストリームデータ１０８の内容を表したもので、選択演算、射影演算、結合演算、集計演算等の処理モジュールが木構造になっている。実行木１７４は、前記問合せ設定部１２１により生成される。実行木プール領域１７３は、前記実行木１７４を格納する領域である。スケジューラ１７１は、前記実行木１７４の実行順序を制御する。一時保存領域管理部１７２は、記憶装置１６０に格納された前記一時保存データ１６４の生成、破棄の管理を行う。

ここで、前記一時保存領域１６３に格納される前記一時保存データ１６４は、タプル形式（レコード形式）、ＸＭＬ形式、ＣＳＶファイル等のいかなるデータ形式でもよい。以下では、タプル形式を用いる例を説明する。

第一の実施形態では、図１において、ストリームデータ監視情報管理部１４０（ストリームデータ監視部１４１、キー傾向予測部１４２、監視情報管理テーブル１４３）、及びインデックス管理部１５０中の分割割合算出部１５３、インデックス監視情報管理テーブル１５４、インデックス監視部１５５、分割多発検知部１５６、分割履歴参照部１５７、読み出し順序制御部１５８は用いない。

図３は、ストリームデータ１０８の好適なデータフォーマットの例を模式的に表した図である。図示の例では、センサノード１０５が出力したデータを示す。

ストリームデータ１０８はレコード形式であり、レコードを構成する温度センサＩＤカラム２０１、温度カラム２０２がセグメントに相当し、前記温度センサＩＤカラム２０１、及び前記温度カラム２０２の組み合わせをタプル２０３とする。前記ストリームデータ１０８が前記ストリームデータ処理システム１００に入力された場合、到着した時間を表すタイムスタンプが付加される。なお、ストリームデータソースにおいて、タイムスタンプを付加してもよい。

図４は、連続してストリームデータ処理システム１００へ入力されたストリームデータ１０８を例示した図であり、温度ストリームデータ（Ｓ１）１０８₁を表している。

温度ストリームデータ１０８₁において、表の１行が前記タプル２０３に対応し、各タプルの到着時間を表すタイムスタンプカラム２０４が付加されている。例えば、行２０５は、タイムスタンプカラム２０４の値が「１０：００」、温度センサＩＤカラム２０１の値が「１０１」、温度カラム２０２の値が「１８．０」であるタプルであることを表している。

ここで、本実施形態では、タイムスタンプを「１０：００」のような時間、及び分の形式で表しているが、「２００６／２／３９：００：００ＪＳＴ」のような日付、及び秒を含めた形式に代表される他の形式でもよい。以下の図においても、同様とする。

図５ａ〜図５ｃは、コマンド入力部１１０において、前記ストリームデータ処理システム１００に登録・設定する際の好適なコマンドの記述例である。

図５ａは、問合せ登録コマンドの記述例である。問合せ登録コマンド３０１は、前記ユーザ１０１、または前記クライアント計算機１０２上で実行される前記アプリケーション１０３から前記コマンド入力部１１０を通して、前記問合せ設定部１２１において登録される。問合せ登録コマンド３０１は、前記温度ストリーム（Ｓ１）１０８₁の過去１時間（［Ｒａｎｇｅ１ｈｏｕｒ］）において、温度センサごとに（ＧＲＯＵＰＢＹ温度センサＩＤ）最大値（Ｍａｘ（温度））、及び最小値（Ｍｉｎ（温度））を計算し、最大値と最小値の差が５よりも大きい（ＨＡＶＩＮＧＭａｘ（温度）−Ｍｉｎ（温度）＞５）ものに関して、温度センサＩＤ、最大値、最小値をストリーム化して（ＩＳＴＲＥＡＭ）、出力する処理を表す問合せであることを表している。

図５ｂは、ノード分割割合設定コマンドの記述例である。ノード分割割合設定コマンド３０２は、前記ユーザ１０１、または前記クライアント計算機１０２上で実行される前記アプリケーション１０３から前記コマンド入力部１１０を通して、前記インデックス設定部１５２において登録される。ノード分割割合設定コマンド３０２は、ストリーム名が「Ｓ１」、カラム名が「温度」であるストリームデータに対し、インデックス名が「インデックス１」であるインデックスを作成（変更）し、「−ｓｐｌｉｔｒａｔｉｏ」オプションでノード分割割合を設定している。具体的には、インデックスのキー値の増加傾向時にはノード分割割合を「５：２」に設定し（ｉｎｃｒｅａｓｅ５：２）、減少傾向時にはノード分割割合を「２：５」に設定し（ｄｅｃｒｅａｓｅ２：５）、ランダム傾向時にはノード分割割合を「１：１」に設定する（ｒａｎｄｏｍ１：１）処理であることを表している。

図５ｃは、ストリームデータ特性情報設定コマンドの記述例である。ストリームデータ特性情報設定コマンド３０３は、前記ユーザ１０１、または前記クライアント計算機１０２上で実行される前記アプリケーション１０３から前記コマンド入力部１１０を通して、特性情報設定部１３１において登録される。ストリームデータ特性情報設定コマンド３０３は、ストリーム名が「Ｓ１」であるストリームデータにおいて、カラム名が「温度」であるカラムに対し、増加傾向となるのが６：００から１３：００（ｉｎｃｒｅａｓｅ６：００＜＝ｔｉｍｅｓｔａｍｐ＜１３：００）、減少傾向となるのが０：００から３：００と１６：００から０：００（ｄｅｃｒｅａｓｅ０：００＜＝ｔｉｍｅｓｔａｍｐ＜３：００ＡＮＤ１６：００＜＝ｔｉｍｅｓｔａｍｐ＜０：００）、ランダム傾向となるのが３：００から６：００と１３：００から１６：００（ｒａｎｄｏｍ３：００＜＝ｔｉｍｅｓｔａｍｐ＜６：００ＡＮＤ１３：００＜＝ｔｉｍｅｓｔａｍｐ＜１６：００）であることを表している。

ここで、本実施形態では、コマンドをコマンドラインインターフェース（ＣＬＩ）形式で登録した例を表したが、これに限定されるものではない。例えば、グラフィックユーザーインターフェース（ＧＵＩ）を用いて上記と同様の意味の入力をしてもよい。

図６は、問合せ管理テーブル１２２の構成例を表した図である。

問合せ名カラム４０１、問合せカラム４０２には、それぞれ、前記コマンド入力部１１０において登録された問合せの名前、及び登録された問合せを格納する。

問合せ実行形式格納先カラム４０３には、問合せの実行形式の格納先のアドレス（ポインタ）を格納する。実行形式を予め作成しておくことにより、クエリの実行のたびにコンパイルを行うオーバーヘッドを削減できる。このアドレスは、例えばメモリ１２上の格納位置を指し示す。

登録者名カラム４０４、登録日時カラム４０５にはそれぞれ、問合せ登録時に取得した問合せの登録者名、問合せの登録日時が格納され、システムのアクセス管理、セキュリティ管理に使用される。

例えば、行４０６は、図５に示した問合せ登録コマンド３０１を登録した場合の登録問合せ管理テーブル１２２を表している。

行４０６は、問合せ名カラム４０１の値が「Ｑ１」、問合せカラム４０２の値が「ＳＥＬＥＣＴ温度センサＩＤ，Ｍｉｎ（温度），Ｍａｘ（温度）ＦＲＯＭＳ１［ＲＡＮＧＥ１ＨＯＵＲ］ＧＲＯＵＰＢＹ温度センサＩＤＨＡＶＩＮＧＭＡＸ（温度）− ＭＩＮ（温度）＞５」、問合せ実行形式格納先カラム４０３の値が「０ｘ７ＦＦＦＡＥＥ１」、登録者名カラム４０４の値が「樫山」、登録日時カラム４０５の値が「２００６／０８／０１１３：０７：２６ＪＳＴ」であることを表している。

ここで、問合せを入力するＩ／Ｆは、図５ａに示したコマンド形式、図６に示した表形式の他に、設定ファイルによる入力、ＸＭＬファイルによる入力など任意の形式でよい。以下のテーブルにおいても、同様とする。

図７は、特性情報管理テーブル１３２の構成例を表した図である。

ストリームデータ名カラム５０１には、特性情報を入力するストリームデータの名前を格納する。カラム名カラム５０２には、ストリームデータにおける前記特性情報を入力するカラムのカラム名を格納する。前記カラム名カラム５０２に前記インデックス１６２のキーを入力することにより、前記キー傾向を取得することができる。

タイムスタンプ範囲カラム５０３、傾向カラム５０４にはそれぞれ、時刻情報に関する範囲指定、及び前記時刻情報に対応する傾向を格納する。ここで、タイムスタンプ範囲カラム５０３には、値が入力されなくともよい。

例えば、行５０５は、「Ｓ１」というストリーム名を有するストリームデータにおいて、「温度」カラムは、「６：００から１３：００」に「増加傾向」となることを表している。図５ｃに示したストリームデータ特性情報設定コマンド３００を入力すると、行５０５、行５０６、行５０７が生成される。

ここで、傾向カラム５０４に入力される値としては、該挿入されるインデックスのキー系列が単調増加、若しくは単調増加ではないが、全体的に増加していることを表す「増加傾向」と、該挿入されるキー系列が単調減少、若しくは単調減少ではないが、全体的に減少していることを表す「減少傾向」と、該挿入されるキー系列に特徴がなく、ランダムな値であることを表す「ランダム傾向」と、該挿入されるキー系列が単調増加であることを表す「単調増加傾向」と、該挿入されるキー系列が単調減少であることを表す「単調減少傾向」と、該挿入されるキー系列が最大値若しくは最小値に向かって両側に広がっていくことを表す「発散傾向」と、該挿入されるキー系列がある値に向かって集まっていくことを表す「収束傾向」などが挙げられるが、上記以外の傾向でもよい。また、行５０８に示すように、複数の傾向が入力され、傾向が切り替わることを表してもよい。

また、特性を入力するストリームデータ名カラム５０１、及びカラム名カラム５０２は、前記問合せ管理テーブル１２２を参照し、取得してもよい。また、タイムスタンプ範囲カラム５０３に格納する情報はすべての情報が入力される必要はない。

図８は、インデックス管理テーブル１５１の構成例を表した図である。

インデックス設定部１５２は、インデックス管理テーブル１５１のインデックス名カラム７０１、ストリームデータ名カラム７０２、カラム名カラム７０３には、それぞれ、インデックスの名前７０１、ストリームデータの名前７０２、カラムの名前７０３を格納する。

キー傾向カラム７０４には、インデックスのキー傾向を格納する。ノード種別カラム７０５、分割割合カラム７０６には、それぞれ、ノード種別、及び対応するノード分割割合を格納する。

ここで、ストリームデータ処理システム１００ではインデックス管理テーブル１５１を基に、インデックス１６２に対して分割割合変更命令を出力する。また、ノード種別カラム７０５に格納する情報はすべての情報が入力される必要はない。

また、ランダム傾向に対する前記ノード分割割合は、システムで予め定めた既定値は任意の値でよい。例えば、１：１（半々に分割）でよい。

例えば、行７０７は、インデックス名が「インデックス１」、ストリームデータ名が「Ｓ１」、カラム名が「温度」であるインデックスに対し、「増加傾向」時には、ノード種別に関係なく、ノード分割割合を「５：２」にすることを表している。

また、行７０８は、「減少傾向」時には、ノード種別に関係なく、ノード分割割合を「２：５」にすることを表しており、行７０９は、「ランダム傾向」時には、ノード種別に関係なく、ノード分割割合を「１：１」（キー格納上限数が６の場合には、「３：４」）にすることを表している。

また、行７１０、若しくは行７１１に示すように、リーフノードと索引ノードとで、ノード分割割合を変更してもよい。

また、行７１２、若しくは行７１３に示すように、前記分割割合カラム７０６の値に、前記インデックスにキーが挿入されるリーフノードの位置を表すリーフノード位置に対応したノード分割割合を保持してもよい。例えば、行７１２は、リーフノード位置が「左」側の場合に、ノード分割割合を「２：５」にし、リーフノード位置が「中」側（真ん中付近）の場合に、ノード分割割合を「１：１」にし、リーフノード位置が「右」側の場合に、ノード分割割合を「５：２」にすることを表している。詳細は後述する（図２３に示すインデックス管理テーブル１５１を用いる）。

図９は、インデックス管理部１５０が前記インデックス１６２において、キー挿入時に実行するインデックス処理を表したフローチャートである。

キー挿入時のインデックス処理では、まず、非特許文献３に開示されているＢ木インデックスと同様に、キーが挿入されるリーフノード位置及びリーフノード内における挿入位置を特定し、キーを挿入する（Ｓ２００２）。次に、キーを挿入するノードが格納可能なキー格納上限数を上回り、ノード分割が発生するか否かを判定する（Ｓ２００３）。なお、キー格納上限数は予め定めた値である。

前記ステップＳ２００３でＮＯと判定された場合は、処理を終了する（Ｓ２０１１）。前記ステップＳ２００３でＹＥＳと判定された場合は、新規ノードを生成する（Ｓ２００４）。

次に、インデックス管理部１５０は特性情報管理テーブル１３２を参照し（Ｓ２００５）、現在のタイムスタンプに対応するキー傾向カラム５０４の値を取得する（Ｓ２００６）。

次に、インデックス管理テーブル１５１を参照し（Ｓ２００７）、前記取得したキー傾向に対応する分割割合カラム７０６の値を取得する（Ｓ２００８）。

次に、前記取得した分割割合に基づいて新規ノードにキーを移動し（Ｓ２００９）、上位ノードの参照を変更し（Ｓ２０１０）、処理を終了する（Ｓ２０１１）。

ここで、キーが前記ノード分割割合で整数値に配分できない場合に、ノード分割割合と最も近い割合でキー配分を行う。

また、キー削除時のインデックス処理では、非特許文献３に開示されているＢ木インデックスと同様に行える。また、ノードが空になるまで、キーを削除し続け、ノードが空になった段階で空きノード回収する方法でもよい。

図１０ａ〜図１０ｄは、インデックスのノード分割の例を表した図である。上記図９のフローチャートを参照しながら以下に説明する。

図１０ａから図１０ｄは、リーフノードのキー格納上限数が６、索引ノードのキー格納上限数が４であるインデックス１６２の例を表している。

図１０ａは、ランダム傾向時のインデックス１６２のノード分割の例を表した図である。キーの値が「１２」であるキーを挿入した場合、前記ステップＳ２００２が実行される。前記ステップＳ２００３では、キー格納数が１であり、キー格納上限数を上回らないため、ノード分割発生の判定はＮＯと判定され、処理を終了する。

次に、「１８、１５、２１、１３、１９」の順にキーを挿入すると上記と同様に処理され、インデックス８０１となる。

次に、キーの値が「１６」であるキーを挿入した場合、前記ステップＳ２００３において、キー格納数が７となり、キー格納上限数を上回るため、ノード分割発生の判定はＹＥＳと判定される。そこで、前記ステップＳ２００４で、新規ノードを生成する。前記ステップＳ２００５におけるランダム傾向の判定はＹＥＳが判定され、前記ステップＳ２００６で、ランダム傾向時のノード分割割合「１：１（半分に分けられないため３：４とする）」でノード分割する。前記ステップＳ２０１０で、新規ノードに４個のキー（「１６〜２１」）を移動し、前記ステップＳ２０１１で、上位ノードの参照を変更する。図１０ａでは、上位ノードが存在しないため、上位ノードを新たに生成している。上位ノード生成方法は非特許文献３に開示されているＢ木インデックスの処理方法と同様である。上記処理を行った結果のインデックスはインデックス８０２となり、処理を終了する。

インデックスのキーの値がランダムに変化する場合では、ノード分割時に値の小さいノードと値の大きいノードに格納するキーの数をほぼ等しく（１：１〜３：４）とすることで、次のキーの値が増大、減少しても分割したノードに格納することができる。これにより、キーの値がランダムに変化する場合に、キーを格納するノードの分割が頻発するのを防ぐことができる。

図１０ｂは、キーの値が増加傾向時のノード分割の例を表した図である。

「１１、１３、１４、１７、１５、１８」の順にキーを挿入した場合、インデックス８０３となる。次に、キーの値が「２２」であるキーをインデックス８０３に挿入した場合、前記ステップＳ２００３におけるノード分割発生の判定はＹＥＳと判定される。次に、前記ステップＳ２００７における増加傾向の判定はＹＥＳと判定され、前記ステップＳ２００８で、増加傾向時のノード分割割合「５：２」でノード分割する。ノード分割後の処理は図１０ａと同様である。上記処理を行ったインデックスはインデックス８０４となり、処理を終了する。

インデックスのキーの値が増加傾向で変化する場合では、ノード分割時に値の小さいノードへ格納するキーの数を、値の大きいノードよりも大きく（５：２等）とすることで、次のキーの値が増大しても分割したノードに格納することができる。これにより、キーの値が増加傾向で変化する場合に、キーを格納するノードの分割が頻発するのを防ぐことができる。

図１０ｃは、減少傾向時のノード分割の例を表した図である。

「２２、１８、１５、１７、１４、１３」の順にキーを挿入した場合、インデックス８０５となる。次に、キーの値が「１１」であるキーをインデックス８０４に挿入した場合、前記ステップＳ２００３におけるノード分割発生の判定はＹＥＳと判定される。次に、前記ステップＳ２００７における増加傾向の判定はＮＯと判定され、前記ステップＳ２００９で、減少傾向時のノード分割割合「２：５」でノード分割する。ノード分割後の処理は図１０ａと同様である。上記処理を行ったインデックスはインデックス８０６となり、処理を終了する。

インデックスのキーの値が減少傾向で変化する場合では、ノード分割時に値の小さいノードへ格納するキーの数を、値の大きいノードよりも少なく（２：５等）とすることで、次のキーの値が減少しても分割したノードに格納することができる。これにより、キーの値が減少傾向で変化する場合に、キーを格納するノードの分割が頻発するのを防ぐことができる。

図１０ｄは、前記特許文献２に開示されているキー挿入位置でノード分割する例を表した図である。

図１０ｂと同じ「１１、１３、１４、１７、１５、１８」の順にキーを挿入した場合、インデックス８０７となる。次に、キーの値が「２２」であるキーをインデックス８０７に挿入した場合に、挿入位置（左端）でノード分割をするため、キーは「１１、１３、１４、１７、１５、１８」と「２２」にノード分割され、インデックス８０８となる。ここで、ゆらぎを含むデータ、例えば、キーの値が「２１」であるキーを挿入した場合に、図中左側のリーフノードで再びノード分割が発生し、「１１、１３、１４、１７、１５、１８」と「２１」にノード分割され、インデックス８０９となる。インデックス８０９は、リーフノード数が３個となり、インデックス容量が増加してしまう。このように、従来例ではノード分割が頻発して、インデックスを格納するための記憶領域（インデックス領域１６１）が肥大することになる。

一方、図１０ｂに示した増加傾向時のインデックス８０４に対し、キーの値が「２１」であるキーを挿入した場合に、右側のリーフノードに入るために、ノード分割は発生せず、リーフノード数は２個のままとなるため、インデックス容量は増加しない。

ここで、図１０ａから図１０ｃではリーフノード分割の例を表したが、索引ノードの分割も同様にできる。

図１１は、問い合わせ実行部１７０の実行木１７４の一例を表した説明図である。

実行木１７４は、処理を行うオペレータ、及びオペレータ間をつなぐキュー１２１０から構成される。本説明図では、左端が入力で右端が出力となっている。入力データとして、ストリームデータ１０８を入力する。また、問合せの出力結果１８０をストリームデータ１０８として再入力することも可能である。

オペレータは、処理内容によって種類が異なる。ウィンドウオペレータ１２１１は、前記ストリームデータ１０８からデータ列の数を指定し、または、切り取るデータ列の時間間隔を指定してデータ列を切り取り、ストリームデータをタプル集合へと変換する処理を行う。射影オペレータ１２１２は、前記タプル２０３のカラムの一部のみを出力する処理を行う。選択オペレータ１２１３は、設定された条件に基づいてタプル２０３を出力するか否かを決定する処理を行う。結合オペレータ１２１４は、２入力以上のストリームデータ１０８をある条件のもとに結合する処理を行う。集計オペレータ１２１５は、合計、平均、最大、最小などの集計処理を行う。ストリーム化オペレータ１２１６は、タプル集合をストリームデータ１０８へと変換する処理を行う。

実行木１７４は、ストリームデータ１０８₁、及びストリームデータ１０８₂を入力とし、ストリームデータ１０８₁は、ウィンドウオペレータ１２１１で処理され、射影オペレータ１２１２に入力される。一方、ストリームデータ１０８₂は、ウィンドウオペレータ１２１１で処理され、選択オペレータ１２１３に入力される。射影オペレータ１２１２の出力、及び選択オペレータ１２１３の出力が結合オペレータ１２１４に入力され、集計オペレータ１２１５で処理され、最後に、ストリーム化オペレータ１２１６で処理され、出力結果１８０として出力する例を表している。

図１２は、問い合わせ実行部１７０が出力する出力結果１８０を例示した図であり、図４に示した温度ストリームデータ（Ｓ１）１０８₁に対して、図５ａに示した問合せ登録コマンド３０１を実行した場合の、出力結果を表している。

タイムスタンプカラム１３０１、温度センサＩＤカラム１３０２は、それぞれ、図４に示したタイムスタンプカラム２０４、温度センサＩＤカラム２０１に対応付けられる。また、Ｍｉｎ（温度）カラム１３０３、Ｍａｘ（温度）カラム１３０４は、それぞれ、ストリームデータ１０８のうちの温度の最小値、最大値が出力される。

例えば、行１３０５は、タイムスタンプ「１０：００」において、温度センサＩＤが「１０１」の温度センサが、最小値「１２．５」、最大値「１８．０」となったことを表している。

以上において、インデックス管理部１５０でインデックス１６２のノード分割割合を指定することにより、ノード分割が頻発するのを抑制できるので、本発明の第１の目的である、キーの値が完全な単調増加、または完全な単調減少とならないゆらぎを含むデータに対し、インデックス容量が小さく、高速処理が可能なインデックスを提供することが可能であることを示した。また、ノード分割割合を切り替えることにより、本発明の第２の目的である、増加傾向、減少傾向が入れ替わるデータに対し、インデックス容量が小さく、高速処理が可能なインデックスを提供することが可能であることを示した。

以上、本発明の第一の実施形態について説明した。

本発明は、上記に示した第一の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。以下では、第一の実施形態とは異なる実施形態により、同様、または更なる効果を得ることが可能である、若しくは第一の実施形態と組み合わせることにより更なる効果を得ることが可能であることを説明する。

なお、上記実施形態においてセンサノードの測定値から変換したユーザが理解可能な有意な情報は、センサノードが出力したバイナリ値を所定の単位系の数値に変換した情報としたが、これに限定されるものではない。例えば、センサノードの値の時系列の集計値、および複数のセンサノードの値の集計値を有意な情報としてもよい。あるいは、センサノードが1分間隔に温度情報を送信した場合に、ユーザは最近1時間の温度平均が知りたい(時系列の集計)場合では、直近の1時間の温度平均が有意な情報となる。また、複数のセンサノードの集計値の例では、同じ部屋にある複数のセンサノードの中で最も温度の高いものを有意な情報としてもよい。

＜第２実施形態＞
以下では、本発明の第二の実施形態について説明する。

前記第一の実施形態では、ユーザ１０１、または計算機１０２上で実行されるアプリケーション１０３が指定したストリームデータ１０８の特性情報により、キー傾向を与えたが、第二の実施形態では、ストリームデータ１０８の監視情報を用いることにより、キー傾向を予測することを特徴とする。キー傾向を予測する処理以外は、第一の実施形態と同様に処理を行える。

第二の実施形態では、図１において、ストリームデータ監視情報管理部１４０では、ストリームデータ監視部１４１がストリームデータ１０８の監視を行い、キー傾向予測部１４２が、監視情報管理テーブル１４３に保持されている取得した監視情報からキー傾向を予測する。

第二の実施形態では、図１において、インデックス管理部１５０中の分割割合算出部１５３、インデックス監視情報管理テーブル１５４、インデックス監視部１５５、分割多発検知部１５６、分割履歴参照部１５７、読み出し順序制御部１５８は用いない。

図１３は、ストリームデータ監視情報管理部１４０の監視情報管理テーブル１４３の構成例を表した図である。

タイムスタンプカラム６０１には、前記第１実施形態のストリームデータ監視部１４１において入力されたストリームデータ１０８の監視情報を取得した時刻情報を格納する。

ストリームデータ名カラム６０２、カラム名カラム６０３にはそれぞれ、前記第１実施形態に示した問合せ管理テーブル１２２を参照し、取得した監視対象のストリームデータ名カラム６０２、及び監視対象のカラム名６０３を格納する。キー傾向予測部１４２は、監視情報管理テーブル１４３の前記カラム名カラム６０３に前記インデックス１６２のキーを入力することにより、前記キー傾向を予測することができる。

属性値カラム６０４には、前記ストリームデータ監視部１４１において取得した監視情報のうち、前記カラム名カラム６０３に対応する属性値を格納する。属性値カラム６０４はすべての情報が入力される必要はなく、監視情報管理テーブル１４３に格納する情報は、属性値カラム６０４に情報が入力されている場合には、属性値カラム６０４に対応する監視情報を入力し、属性値カラム６０４に情報が入力されていない場合には、カラム名カラム６０３に対応する監視情報を入力する。

データレートカラム６０５には、前記ストリームデータ監視部１４１において取得した監視情報のうち、監視対象のストリームデータ１０８の到着レートを格納する。データレートを取得することにより、ストリームデータ処理システム１００に今後到着するストリームデータ１０８のデータ量を予測できる。

統計値カラム６０６には、前記ストリームデータ監視部１４１において取得した監視情報のうち、前回監視情報を取得した時点からの統計値を格納する。

現在の値カラム６０７には、前記ストリームデータ監視部１４１において取得した監視情報のうち、最新の値を格納する。

増加カウンタカラム６０８、減少カウンタカラム６０９には、それぞれ、前記ストリームデータ監視部１４１において取得した監視情報のうち、１個前のタプルと比較して増加したか否かをカウントし、増加した回数、減少した回数を格納する。増加カウンタカラム６０８、減少カウンタカラム６０９には、前回監視情報を取得した時点からのカウント回数を格納する。

傾向予測カラム６１０は、後述する傾向予測部１４２で予測したキー傾向を格納する。このキー傾向の予測値を用いて、インデックス１６２のノード分割割合を決定する。

例えば、行６１１は、タイムスタンプカラム６０１の値が「１０：００」であり、ストリームデータ名カラム６０２の値が「Ｓ１」であり、カラム名カラム６０３の値が「温度」であり、属性値カラム６０４の値が「温度センサＩＤ＝１０１」であり、データレートカラム６０５の値が「３０タプル／分」であり、統計値カラム６０６の値が「平均値＝１７．５℃」であり、現在の値カラム６０７の値が「１８．０」であり、増加カウンタカラム６０８の値が「５０」であり、減少カウンタカラム６０９の値が「４」であり、傾向予測カラム６１０の値が「増加傾向」であることを表している。

図中監視情報管理テーブル１４３の行６１２は、属性値カラム６０４の値が「温度センサＩＤ＝１０２」に対応する監視情報であることを表している。また、行６１３は、「１０：０５」にストリームデータ監視部１４１が取得した監視情報であることを示し、行６１４は、「１０：１０」に取得した監視情報であることを表している。

ここで、本第２実施形態では、監視情報を５分間隔で取得する例を表したが、これに限定されるものではない。また、ストリームデータ１０８ごとに監視情報取得間隔を変更してもよい。また、監視情報を監視情報管理テーブル１４３では新たなデータを追記しているが、不要となった行を監視情報管理テーブル１４３から削除してもよい。

また、データレートカラム６０５に格納するデータとして、タプル／分の例を表したが、これに限定されるものではない。統計値カラム６０６に格納するデータは、前回監視情報を取得した時点からの統計情報としたが、それ以前から取得している統計情報でも構わない。また、増加カウンタカラム６０８、減少カウンタカラム６０９に格納するデータは、前回監視情報を取得した時点からの回数としたが、それ以前から取得している回数でも構わない。また、統計値６０６として、中心値、及び平均値を示したが、分散などの他の統計情報でもよい。さらに、後述するストリームデータの特性情報の一部を、前記ストリームデータ１０８を監視することにより取得してもよい。

また、属性値カラム６０４、データレートカラム６０５、統計値カラム６０６、現在の値カラム６０７、増加カウンタカラム６０８、減少カウンタカラム６０９、傾向予測カラム６１０に格納する監視情報取得データはすべての情報が入力される必要はなく、監視項目はどのような方法で設定されてもよい。例えば、前記コマンド入力部１１０で設定する、設定ファイルに書き込んでおく、システムが既定値を定めておき、設定がなかった場合に、既定値を用いる、などで構わない。

図１４は、キー傾向予測部１４２で実行されるキー傾向の予測処理を表したフローチャートである。この処理は所定の周期で実行されるものである。

キー傾向予測処理では、まず、キー傾向予測部１４２が前記特性情報管理テーブル１３２を参照し（Ｓ２１０２）、現在のタイムスタンプにおける傾向が記述されているか否かを判定する（Ｓ２１０３）。具体的には、図７に示した特性情報管理テーブル１３２のタイムスタンプ範囲カラム５０３の値、傾向カラム５０４の値を参照し、該当するものがあるか否かを判定する。

前記ステップＳ２１０３でＹＥＳと判定された場合、前記特性情報管理テーブル１３２に記述されているキー傾向に設定し（Ｓ２１０４）、処理を終了する（Ｓ２１１２）。前記ステップＳ２１０３でＮＯと判定された場合、前記監視情報管理テーブル１４３を参照し（Ｓ２１０５）、増加カウンタ、減少カウンタの値を取得する（Ｓ２１０６）。具体的には、図１３に示した増加カウンタカラム６０８、減少カウンタ６０９の値を取得する。

次に、増加カウンタの値が減少カウンタの値よりも大きいか否か、具体的には、増加カウンタ、減少カウンタの比が予め設定された増加カウンタ閾値を超えているか否か、すなわち、「増加カウンタ／減少カウンタ＞増加カウンタ閾値」を満たすか否かを判定する（Ｓ２１０７）。

前記ステップＳ２１０７でＹＥＳと判定された場合、キー傾向を増加傾向に設定する（Ｓ２１０８）。前記ステップＳ２１０７でＮＯと判定された場合、減少カウンタの値が増加カウンタの値よりも大きいか否か、具体的には、減少カウンタ、増加カウンタの比が予め設定された減少カウンタ閾値を超えているか否か、すなわち、「減少カウンタ／増加カウンタ＞減少カウンタ閾値」を満たすか否かを判定する（Ｓ２１０９）。

前記ステップＳ２１０９でＹＥＳと判定された場合、キー傾向を減少傾向に設定し（Ｓ２１１１）、処理を終了する（Ｓ２１１２）。前記ステップＳ２１０９でＮＯと判定された場合、キー傾向をランダム傾向に設定し（Ｓ２１１０）、処理を終了する（Ｓ２１１２）。

ここで、図１４では、監視情報からキー傾向を予測するため、増加カウンタ、減少カウンタを用いたが、監視情報を用いた任意の方法で決定してよい。例えば、図１３に示した前記監視情報管理テーブル１４３における現在の値カラム６０７を用いて、１０：００、１０：０５、１０：１０における現在の値を取得し、増加し続けている場合、増加傾向に設定し、減少し続けている場合、減少傾向に設定し、それ以外の場合をランダム傾向に設定してもよい。処理の詳細は後述する（図２４に示すキー傾向予測処理のフローチャートを用いる）。

ここで、図１４では、特性情報管理テーブル１３２を参照したが、特性情報管理テーブル１３２を参照せず、監視情報のみでキー傾向を決定してもよい。すなわち、前記ステップＳ２１０３、及び前記ステップＳ２１０４は必ずしも必要でない。また、上記では、特性情報を優先してノード分割したが、監視情報から算出した傾向を優先してノード分割してもよい。または、特性情報、及び監視情報から算出した傾向を比較し、どちらも一致することを確認してもよい。

また、前記増加カウンタ閾値及び減少カウンタ閾値は、どのような方法で設定されてもよい。例えば、前記コマンド入力部１１０で設定する、設定ファイルに書き込んでおく、システムが既定値を定めておき、設定がなかった場合に、既定値を用いる、などで構わない。また、増加カウンタ閾値と減少カウンタの閾値は同じ値を用いてもよい。

以上、本発明の第二の実施形態について説明した。

＜第３実施形態＞
以下では、本発明の第三の実施形態について説明する。

前記第一、第二の実施形態では、ノード分割割合をユーザ、または計算機上で実行されるアプリケーションにより指定したが、第三の実施形態では、キーが挿入される位置を特定した後に、キー傾向からノード分割割合を算出し、ノード分割することを特徴とする。

すなわち、キー傾向とノード分割割合が1対1に対応せず、キーが挿入される位置によりノード分割割合が変更することを特徴とする。

ここで、前記特許文献２に開示されているインデックス処理方法では、キーが挿入される位置でノード分割を行うが、本発明の第三の実施形態では、キーが挿入される位置と異なる位置でノード分割される（キーが挿入される位置と同じになることもある）。

ノード分割割合を決定する処理以外は、前記第一、及び第二の実施形態と同様に処理を行える。キー傾向を決定する処理は、第一の実施形態（ユーザ１０１、または計算機１０２上で実行されるアプリケーション１０３が指定）、第二の実施形態（監視情報から予測）の何れでも構わない。

第三の実施形態では、図１において、インデックス管理部１５０の分割割合算出部１５３が、ストリームデータ特性情報管理部１３０の特性情報管理テーブル１３２、または監視情報管理テーブル１４３を参照し、キー傾向を取得し、インデックス１６２からキーの挿入位置を取得し、ノード分割割合を計算する。

第三の実施形態では、図１において、ストリームデータ特性情報管理部１３０（特性情報設定部１３１、特性情報管理テーブル１３２）、またはストリームデータ監視情報管理部（ストリームデータ監視部１４１、キー傾向予測部１４２、監視情報管理テーブル１４３）の少なくとも一方を用いるものとする。また、インデックス管理部１５０中のインデックス監視情報管理テーブル１５４、インデックス監視部１５５、分割多発検知部１５６、分割履歴参照部１５７、読み出し順序制御部１５８は用いない。

第三の実施形態では、挿入位置と傾向から分割割合算出部１５３がノード分割割合を動的に決定する。キー傾向または増加傾向の場合、挿入位置から右側のキーを半分ずつ分かれるようにノード分割する。すなわち、リーフノードのキー格納上限数をn_leaf、挿入位置をiとした場合、

の割合でノード分割する。一方、減少傾向の場合には、

の割合でノード分割する。

また、索引ノードの場合には、親ノードに１個のキーが移動することを考慮し、リーフノードと同様にノード分割する。すなわち、索引ノードのキー格納上限数をn_index、挿入位置をiとした場合、

の割合でノード分割する。一方、減少傾向の場合には、

の割合でノード分割する。

ここで、上記数１〜図４に示したノード分割割合算出式は、一例であって、上記以外のどのような算出式であってもよい。例えば、ノード分割元側に少しあきが多くなるようにノード分割割合を決定してもよい。この場合、マージンの割合をパラメータとして入力させる。

図１５は、分割割合算出処理のフローチャートを表している。分割割合算出処理は、図９に示した前記ステップＳ２００２、前記ステップＳ２００３を実行し、ノード分割が発生した場合の処理を表している。

分割割合算出処理では、まず、キー傾向（またはキー傾向予測値）がランダム傾向か否かを判定する（Ｓ２２０２）。この処理では、特性情報管理テーブル１３２の傾向５０４や監視情報管理テーブル１４３の傾向予測カラム６１０を参照することで判定を行う。

前記ステップＳ２２０２でＹＥＳと判定された場合、ノード分割割合をシステムが予め定めた既定値とし（Ｓ２２０３）、処理を終了する（Ｓ２２１１）。前記ステップＳ２２０２でＮＯと判定された場合、ノード分割するノードがリーフノードか索引ノードかを判定する（Ｓ２２０４）。

前記ステップＳ２２０４でリーフノードと判定された場合、キー傾向が増加傾向か減少傾向か判定する（Ｓ２２０５）。

前記ステップＳ２２０５で増加傾向と判定された場合、

の割合でノード分割し（Ｓ２２０７）、処理を終了する（Ｓ２２１１）。前記ステップＳ２２０５で減少傾向と判定された場合、

の割合でノード分割し（Ｓ２２０８）、処理を終了する（Ｓ２２１１）。

一方、前記ステップＳ２２０４で索引ノードと判定された場合、キー傾向が増加傾向か減少傾向か判定する（Ｓ２２０６）。

前記ステップＳ２２０６で増加傾向と判定された場合、

の割合でノード分割し（Ｓ２２０７）、処理を終了する（Ｓ２２１１）。前記ステップＳ２２０６で減少傾向と判定された場合、

ここで、システムで予め定めた既定値は任意の値でよい。例えば、１：１（半々に分割）でよい。

図１６ａ〜図１６ｄは、キー傾向、及びキーの挿入位置からノード分割割合を算出し、ノード分割する例と前記従来例及び第１，第２実施形態との比較を表した図である。

図１６ａは、本第３実施形態でキー傾向が減少傾向であり、キーが「２３、２１、１９、１７、１５、１３、１１、９、７、５、３、１」の順に挿入されたときのインデックスを表している。「１５」のキーが挿入された時点、及び「１７」のキーが挿入された時点でリーフノードのノード分割が起こり、インデックス９０１となる。つまり、ノード分割の回数と、ノード数の増大を抑制することができるので、増加傾向、減少傾向が入れ替わるデータに対し、インデックス容量が小さく、高速処理が可能なインデックスを提供することが可能となる。

図１６ｂは、前記特許文献２に開示されている挿入位置でノード分割するインデックス処理方法において、キーが「２、４、６、８」の順に挿入されたときのインデックス（リーフノードのみ）９０２を表している。インデックス９０２に示すように、「２」のキーが挿入された時点で１：４のノード分割が起こり、「４」のキーが挿入された時点で２：３のノード分割が起こり、「８」のキーが挿入された時点で４：１のノード分割が起こる。その結果、「１、３、５、７」の１リーフノードが、「１」、「２、３」、「４、５、６、７」、「８」の４リーフノードとなり、ノード数が多くなる。さらに、同様に、「１０、１２、１４、１６」の順にキーを挿入した場合、「９、１１、１３、１５」の１リーフノードが４リーフノードとなる。このように、前記従来例ではノード分割が頻発することになる。

図１６ｃは、本発明の第一、または第二の実施形態で示した傾向に対するノード分割割合をユーザ、または計算機１０２上で実行されるアプリケーション１０３が指定するインデックス処理方法において、減少傾向から増加傾向に切り替わり、キーが「２、４、６、８」の順に挿入されたときのインデックス（リーフノードのみ）を表している。図１６ｃに示す例では、増加傾向時のノード分割割合を４：１としている。インデックス９０３に示すように、「２」のキーが挿入された時点で４：１のノード分割が起こり、「４」のキーが挿入された時点で４：１のノード分割が起こる。その結果、「１、３、５、７」の１リーフノードが、「１、２、３、４」、「５、６」、「７、８」の３リーフノードとなり、図１６ｂに示した前記従来例のインデックスよりはノード分割回数が少なくなるものの、ノード数が多くなる。さらに、同様に、「１０、１２、１４、１６」の順にキーを挿入した場合、「９、１１、１３、１５」の１リーフノードが３リーフノードとなる。
図１６ｄは、本第３実施形態であるキー傾向、及びキーの挿入位置からノード分割割合を算出し、ノード分割するインデックス処理方法を適用した例を示す。キー傾向が減少傾向から増加傾向に切り替わり、キーが「２、４、６、８」の順に挿入されたときのインデックス（リーフノードのみ）を表している。インデックス９０４に示すように、「２」のキーが挿入された時点でノード分割が起こる。

図１５に示したフローチャートにおいて、ステップＳ２２０２ではキー傾向が増加傾向のため、ＮＯと判定され、ステップＳ２２０４ではリーフノードと判定され、ステップＳ２２０５では増加傾向と判定されるため、ステップＳ２２０７が実行される。

キー格納上限数n_leaf＝４、キー挿入位置ｉ＝２となるので、

でノード分割する。その結果、「１、３、５、７」の１リーフノードが、「１、２、３、４」、「５、６、７、８」の２リーフノードとなり、図１６ｂ、図１６ｃに示したインデックスよりも少ないノード数となる。さらに、同様に、「１０、１２、１４、１６」の順にキーを挿入した場合、「９、１１、１３、１５」の１リーフノードが２リーフノードとなる。

ここで、図１５に示したフローチャートに従い、減少傾向時のノード分割処理を行った場合、「１５」のキーが挿入された時点で、

のノード分割が起こる。同様に、「７」のキーが挿入された時点で１：４のノード分割が起こるため、インデックス９０１と同様となる。

このように、キーの挿入位置とキーの値の傾向に応じてノード分割割合を決定することで、揺らぎのあるインデックスのキーであってもノードの分割が頻発するのを抑制できる。特に、増加傾向の場合では、値の小さなノードにもキーを格納可能としておくことで、一時的にキーの値が減少してもノードの分割が頻発するのを抑制できる。

以上、本発明の第三の実施形態について説明した。

＜第４実施形態＞
以下では、本発明の第四の実施形態について説明する。

第一、第二の実施形態では、ノード分割割合をユーザ１０１、または計算機１０２上で実行されるアプリケーション１０３により指定し、第三の実施形態では、キーが挿入される位置を特定した後に、キー傾向からノード分割割合を算出した。しかしながら、何れの実施形態も指定したノード分割割合が正しいか判断する手段を備えていなかった。そこで、第四の実施形態では、インデックスを監視し、インデックスの監視情報（統計情報など）を取得することで、ノード分割が多発していることを検知し、ノード分割割合を変更する、あるいは、キー傾向を算出しなおす、等の処理を行うことを特徴とする。

ノード分割多発を検知する処理、及びノード分割多発時の処理を追加する以外は、第一から第三の実施形態と同様に処理を行える。

第四の実施形態では、図１において、インデックス監視部１５５が、インデックス１６２の監視を行い、分割多発検知部１５６が、インデックス監視情報管理テーブル１５４に保持されている取得した監視情報を基にノード分割が多発していることを検知する。また、ノード分割が多発している場合、分割多発検知部１５６が、インデックス設定部１５２に対し、ノード分割割合変更を指示したり、キー傾向予測部１４２にキー傾向の再予測を指示することができる。

第四の実施形態では、図１において、ストリームデータ特性情報管理部１３０（特性情報設定部１３１、特性情報管理テーブル１３２）、またはストリームデータ監視情報管理部（ストリームデータ監視部１４１、キー傾向予測部１４２、監視情報管理テーブル１４３）の何れかは必ずしも必要としない。また、インデックス管理部１５０中の分割履歴参照部１５７、読み出し順序制御部１５８は用いない。

図１７は、インデックス管理部１５０のインデックス監視情報管理テーブル１５４の構成例を表した図である。

タイムスタンプカラム１００１には、インデックス監視部１５５において記憶装置１６０に格納されたインデックス１６２の監視情報を取得した時刻情報を格納する。

インデックス名カラム１００２、ストリームデータ名カラム１００３、カラム名カラム１００４にはそれぞれ、図８に示したインデックス管理テーブル１５１を参照し、取得した監視対象のインデックス名、監視対象のストリームデータ名、監視対象のカラム名を格納する。

属性値カラム１００５には、前記インデックス監視部１５５において取得した監視情報のうち、前記カラム名カラム１００４に対応する属性値を格納する。属性値カラム１００５はすべての情報が入力される必要はなく、インデックス監視情報管理テーブル１５４の以下に格納する情報は、属性値カラム１００５に情報が入力されている場合には、属性値カラム１００５に対応する監視情報を入力し、属性値カラム１００５に情報が入力されていない場合には、カラム名カラム１００４に対応する監視情報を入力する。

充填率カラム１００６には、前記インデックス監視部１５５において取得した監視情報のうち、監視対象のインデックスの充填率を格納する。充填率とは、インデックス全体のキー格納数に対して、現在使用されているキーがどのくらいあるかを表す割合である。充填率が１００％の場合、すべてのキーが使用されている。

ノード分割回数カラム１００７には、前記インデックス監視部１５５において取得した監視情報のうち、監視対象のインデックスのノード分割回数を格納する。図１７では、前回の監視情報取得からのノード分割回数を格納しているが、ノード分割回数の累計を格納してもよい。

ノード分割割合カラム１００８には、前記インデックス監視部１５５において取得した監視情報のうち、監視対象のインデックスのノード分割割合を格納する。図１７では、監視情報を追記していくため、過去の分割履歴を取得することもできる。

例えば、行１００９は、タイムスタンプカラム１００１の値が「２００６／０８／０１１０：００：００ＪＳＴ」であり、インデックス名カラム１００２の値が「インデックス１」であり、ストリームデータ名カラム１００３の値が「Ｓ１」であり、カラム名カラム１００４の値が「温度」であり、属性値カラム１００５の値が「温度センサＩＤ＝１０１」であり、充填率カラム１００６の値が「８０％」であり、ノード分割回数カラム１００７の値が「６」であり、ノード分割割合カラム１００８の値が「３：１」であることを表している。

ここで、本第４実施形態では、監視情報を５分間隔で取得する例を表したが、これに限定されるものではない。また、ストリームデータごとに監視情報取得間隔を変更してもよい。また、監視情報をテーブルに追記しているが、不要となった行を削除してもよい。

また、タイムスタンプに格納するデータとして、「２００６／０８／０１１０：００：００ＪＳＴ」の形式としたが、これに限定されるものではなく、「１０：００」など任意の形式で構わない。

また、属性値カラム１００５、充填率カラム１００６、ノード分割回数カラム１００７、ノード分割割合カラム１００８に格納する監視情報データはすべての情報が入力される必要はなく、監視項目はどのような方法で設定されてもよい。例えば、前記コマンド入力部１１０で設定する、設定ファイルに書き込んでおく、システムが既定値を定めておき、設定がなかった場合に、既定値を用いる、などで構わない。

図１８は、分割多発検知部１５６で実行される分割多発検知及び分割多発時の分割割合決定処理のフローチャートを表した図である。

分割多発検知及び分割多発時の分割割合決定処理では、まず、分割多発検知部１５６は図１７に示したインデックス監視情報管理テーブル１５４を参照する（Ｓ２３０２）。次に、分割多発検知部１５６がインデックス監視情報管理テーブル１５４の充填率カラム１００６の値を取得し（Ｓ２３０３）、充填率が予め設定した充填率閾値を上回っているか否か、すなわち、「充填率＞充填率閾値」を満たしているか否かを判定する（Ｓ２３０４）。ここで、充填率閾値は、どのような方法で設定されてもよい。例えば、前記コマンド入力部１１０で設定する、あるいは設定ファイルに書き込んでおく、または、ストリームデータ処理システム１００で既定値を定めておき、設定がなかった場合に、既定値を用いる、などで構わない。

前記ステップＳ２３０４でＹＥＳと判定された場合、インデックス監視情報管理テーブル１５４からノード分割回数カラム１００７の値を取得する（Ｓ２３０５）。次に、監視情報管理テーブル１４３を参照し（Ｓ２３０６）、データレートカラム６０５の値を取得する（Ｓ２３０７）。次に、前記ステップＳ２３０７で取得したデータレートの値、及びインデックス１６２のキー格納上限数に基づいて予測分割回数を算出する（Ｓ２３０８）。算出式は、「データレート×時間／キー格納上限数」とすることができる。ここで、上記の式は一例であり、これに限定されるものではない。例えば、「データレート×時間×２／キー格納上限数」など定数倍した値を予測分割回数としてもよく、算出式は任意の式で構わない。

次に、前記ステップＳ２３０５で取得したノード分割回数と、前記ステップＳ２３０８で算出した予測分割回数とを比較し、ノード分割回数が大きく上回っているか否かを判定する、すなわち、「分割回数／予測分割回数＞予測分割回数閾値」を満たすか否かを判定する（Ｓ２３０９）。ここで、予測分割回数閾値は、どのような方法で設定されてもよい。例えば、前記コマンド入力部１１０で設定する、あるいは設定ファイルに書き込んでおく、またはシステムで既定値を定めておき、設定がなかった場合に、既定値を用いる、などで構わない。

前記ステップＳ２３０９でＮＯと判定された場合、ノード分割が多発していないと判断し、処理を終了する（Ｓ２３１５）。前記ステップＳ２３０９でＹＥＳと判定された場合、若しくは、前記ステップＳ２３０４でＮＯと判定された場合、ノード分割が多発していると判断し、ストリームデータ監視部１４１において、監視情報を再取得することにより監視情報管理テーブル１４３を更新する（Ｓ２３１０）。そして、キー傾向予測部１４２において、キー傾向を再度予測する（Ｓ２３１１）。次に、前記ステップＳ２３１０で再度予測したキー傾向と以前まで用いていたキー傾向が同じか否かを判定する（Ｓ２３１２）。

前記ステップＳ２３１１でＹＥＳと判定された場合、キー傾向の予測が誤っていると判断し、ランダム傾向に設定し（Ｓ２３１３）、処理を終了する（Ｓ２３１５）。前記ステップＳ２３１１でＮＯと判定された場合、再度予測したキー傾向に設定し（Ｓ２３１４）、処理を終了する（Ｓ２３１５）。

ここで、前記ステップＳ２３０３、Ｓ２３０４、または前記ステップＳ２３０５、Ｓ２３０６、Ｓ２３０７、Ｓ２３０８、Ｓ２３０９の処理は必ず必要ではなく、何れか一方でノード分割多発を検知しても構わない。

また、前記ステップＳ２３１０、Ｓ２３１１、Ｓ２３１２、Ｓ２３１３の処理は必ず必要ではなく、ノード分割多発時に常にランダム傾向に設定してもよい。または、ノード分割多発を検知するだけでも構わない。その際に、ノード分割が多発したことを、画面に表示したり、ログファイルに出力したりしてもよい。

図１７に示したインデックス監視情報管理テーブル１５４の例を用いて、具体的に説明する。ここで、充填率閾値を「７０％」、キー格納上限数を「１０」、予測分割回数閾値を「１．５」とする。

インデックス監視情報管理テーブル１５４の行１０１０を参照し（Ｓ２３０２）、充填率カラム１００６の値を取得すると、「７８％」となる（Ｓ２３０３）。充填率閾値「７０％」を上回っているため、ステップＳ２３０４では、ＮＯと判定される。次に、ノード分割回数カラム１００７の値を取得すると、「７」となる（Ｓ２３０５）。
次に、図１３に示した監視情報管理テーブル１４３の行６１３を参照し（Ｓ２３０６）、データレートカラム６０５の値を取得すると、「３０タプル／分」となる（Ｓ２３０７）。次に、「データレート×時間／キー格納上限数」の式に基づいて予測分割回数を算出すると、「３０×１（分）／６＝５」となる（Ｓ２３０８）。次に、「分割回数／予測分割回数＞予測分割回数閾値」の式に基づいて、ノード分割回数と予測分割回数を比較すると、「７／５＝１．４」となり、予測分割回数閾値「１．５」を上回らないため、ステップＳ２３０９では、ＮＯと判定され、処理を終了する（Ｓ２３１４）。

所定の監視間隔である５分が経過し、タイムスタンプが「２００６／０８／０１１０：１０：００ＪＳＴ」となると、上記処理と同様に、インデックス監視情報管理テーブル１５４の行１０１１が参照され、ノード分割回数は「１９８−１８０＝１８」となる。ステップＳ２３０９の判定では、「分割回数／予測分割回数＝１８／５＝３．６」となり、予測分割回数閾値「１．５」を上回るため、ＹＥＳと判定される。

そこで、キー傾向を再度算出したところ、増加傾向となったとすると（Ｓ２３１０）、ステップＳ２３１１では、ＮＯが判定され、増加傾向に設定され（Ｓ２３１３）、ノード分割割合カラム１００８の値を「３：１」から「１：３」に変更し、処理を終了する（Ｓ２３１４）。同時に、インデックス管理テーブル１５１も更新する。

以上のように、本第４実施形態では、インデックスを監視し、インデックスの監視情報を取得することで、ノード分割が多発していることを検知すると、ノード分割割合を変更、あるいは、キー傾向（またはキー傾向予測値）を再度算出する。これにより、キー傾向の判定結果や分割割合の判定結果に対して、実際のノード分割回数をフィードバックすることによって、キー傾向の判定結果の誤差や分割割合を補正することができる。これにより、ストリームデータ１０８の揺らぎが、ストリームデータ処理システム１００を設計する際の想定の範囲を超えた場合でも、ノード分割が頻発するのを抑制して、インデックス容量が肥大化するのを防ぐことができる。

以上、本発明の第四の実施形態について説明した。

＜第５実施形態＞
以下では、本発明の第五の実施形態について説明する。

前記第一、第二の実施形態では、ノード分割割合をユーザ１０１、または計算機１０２上で実行されるアプリケーション１０３により指定し、第三の実施形態では、キーが挿入される位置を特定した後に、キー傾向からノード分割割合を算出した。本第五の実施形態では、過去のノード分割履歴からノード分割割合を決定することを特徴とする。

ノード分割割合を決定する処理以外は、第一から第三の実施形態と同様に処理を行える。また、第四の実施形態に示したノード分割多発検知処理を組み合わせて実施してもよい。

第五の実施形態では、図１において、インデックス監視部１５５が、インデックス１６２の監視を行い、ノード分割の履歴をインデックス監視情報管理テーブル１５４に保持する。分割履歴参照部１５７が、インデックス監視情報管理テーブル１５４に保持されている前記インデックス監視部１５５が取得した分割履歴情報に基づいて、日付、時刻、曜日などの条件である時刻条件で、現在と同じ時刻条件に該当するノード分割履歴情報を検索し、ノード分割割合を決定する。また、外部記憶媒体に保持されている属性情報、例えば、天気、温度、イベント情報などを外部属性条件としてさらに絞り込んで検索してもよい。なお、外部記憶媒体は、例えばストリームデータ処理システム１００からアクセス可能なストレージ装置などで構成される。

第五の実施形態では、図１において、ストリームデータ特性情報管理部１３０（特性情報設定部１３１、特性情報管理テーブル１３２）、またはストリームデータ監視情報管理部（ストリームデータ監視部１４１、キー傾向予測部１４２、監視情報管理テーブル１４３）の何れか、または両方は必ずしも必要としない。また、インデックス管理部１５０中の分割割合算出部１５３、分割多発検知部１５６は必ずしも必要としない。インデックス管理部１５０中の読み出し順序制御部１５８は用いない。

図１９は、分割履歴参照部１５７が実行する分割割合履歴に基づく分割割合決定処理のフローチャートを表した図である。

分割割合履歴からの分割割合決定処理において、まず、分割履歴参照部１５７がインデックス監視情報管理テーブル１５４を参照する（Ｓ２４０２）。次に、分割履歴参照部１５７は前記インデックス監視情報管理テーブル１５４において、日付、時刻、曜日などの条件である時刻条件で、現在と同じ時刻条件に該当する行を検索する（Ｓ２４０３）。

次に、外部記憶媒体に保持されている属性情報があるか否か、また外部属性条件でさらに絞り込むか否かを判定する（Ｓ２４０４）。前記ステップＳ２４０４でＹＥＳと判定された場合、外部属性条件でさらに絞り込む（Ｓ２４０５）。

前記ステップＳ２４０４でＮＯと判定された場合、または前記ステップＳ２４０５が終了した場合、前記ステップＳ２４０３で検索した結果、または前記ステップＳ２４０５でさらに絞り込んだ結果、条件に該当する行があるか否かを判定する（Ｓ２４０６）。

前記ステップＳ２４０６でＹＥＳと判定された場合、最も出現頻度の多いノード分割割合をノード分割割合として設定し（Ｓ２４０７）、処理を終了する（Ｓ２４０９）。前記ステップＳ２４０６でＮＯと判定された場合、システムで予め定めた既定値でノード分割し（Ｓ２４０８）、処理を終了する（Ｓ２４０９）。

ここで、前記ステップＳ２４０７において、最も多いノード分割割合をノード分割割合として設定したが、これに限定されるものではなく、例えば、該当行の平均を取ってもよい。

また、システムで予め定めた既定値は任意の値でよい。例えば、１：１（半々に分割）でよい。

図１７に示したインデックス監視情報管理テーブル１５４を用いて具体的に説明する。

ここで、ある時刻「２００６／０８／０２１０：００：００ＪＳＴ」において、ノード分割割合を決定する場合の処理を説明する。また、外部属性条件は、「天気＝晴れ」の条件で絞込みを行い、外部記憶媒体に、行１００９の時刻情報「２００６／０８／０１１０：００：００ＪＳＴ」に対応する天気情報が、「天気＝晴れ」と保持されているものとする。

まず、図１７に示したインデックス監視情報管理テーブル１５４を参照し（Ｓ２４０２）、現在と同じ時刻条件、例えば、タイムスタンプカラム１００１の値が「１０：００：００」を含むノード分割割合履歴を検索する（Ｓ２４０３）。この検索の結果、行１００９が該当し、ノード分割割合カラム１００８の値は「３：１」となる。ステップＳ２４０４において、外部属性条件「天気＝晴れ」があるため、ＹＥＳと判定され、ステップＳ２６０５において絞り込みが行われる。ここでは、行１００９の天気情報は外部属性条件を満たすため、該当行は１行のままである。ステップＳ２４０６では、該当する行が１行あるため、ＹＥＳと判定され、ステップＳ２４０７では、該当行が１行のため、行１００９のノード分割割合である「３：１」が選択され、処理を終了する（Ｓ２４０９）。

以上のように、本第５実施形態によれば、過去の分割履歴から現在の時刻や現在の環境に最適なノード分割割合を設定することができ、時刻に関連してキー傾向が変化する温度などのストリームデータ１０８や、気象などの環境を条件としてキー傾向が変化するストリームデータ１０８など、揺らぎのあるストリームデータ１０８を検索するのに最適なインデックス１６２を提供できる。

以上、本発明の第五の実施形態について説明した。

＜第６実施形態＞
以下では、本発明の第六の実施形態について説明する。

前記第一から第五の実施形態では、ノードにキーを挿入する際に、小さい順（昇順）で格納していた。しかしながら、減少傾向時には、キーの挿入時に毎回データの移動が発生してしまうため、処理に要する負荷が増大してリアルタイム処理ができない場合やインデックス処理が遅延する場合がある。そこで、第六の実施形態では、インデックス１６２に読み込み順序フラグを備え、読み込み順序フラグにより、キーの格納順序を変更することを特徴とする。

キーの挿入・削除、及びノード分割処理以外は、第一から第五の実施形態と同様に処理を行える。

第六の実施形態では、図１において、読み出し順序制御部１５８が、インデックス１６２の読み込み順序フラグに基づいて読み込み順序を制御する。

第六の実施形態では、図１において、ストリームデータ特性情報管理部１３０（特性情報設定部１３１、特性情報管理テーブル１３２）、またはストリームデータ監視情報管理部（ストリームデータ監視部１４１、キー傾向予測部１４２、監視情報管理テーブル１４３）の何れかは必ずしも必要としない。また、インデックス管理部１５０中の分割割合算出部１５３、インデックス監視情報管理テーブル１５４、インデックス監視部１５５、分割多発検知部１５６は必ずしも必要としない。

本第６実施形態では、読み込み順序フラグの値が通常順（昇順）を表す「Ｆ」と、逆順（降順）を表す「Ｒ」とを用意し、「Ｆ」の場合、通常通りノードの先頭（図２１ａのインデックス１１０２で左側）からキーの値を読み込み、「Ｒ」の場合は、ノードの末尾（図２１ｃのインデックス１１１０で右側）からキーの値を読み込む逆順とする。ここで、読み込み順序フラグの値としての「Ｆ」と「Ｒ」は一例であり、これに限定されない。例えば、「０」と「１」でもよい。

図２０は、読み込み順序フラグに基づいたキー挿入処理のフローチャートを表した図である。本第６実施形態は、前記非特許文献３に開示されているＢ木インデックスとは、挿入位置を特定する処理も異なる。そのため、挿入位置を特定する処理から説明する。

読み込み順序フラグに基づいたキー挿入処理では、まず、読み込み順序フラグが「Ｆ」か「Ｒ」か否かを判定する（Ｓ２５０２）。

前記ステップＳ２５０２で「Ｆ」（通常順）と判定された場合、ノードの先頭からキーの比較を行い（Ｓ２５０３）、現在処理中のノードがリーフノードであるか否かを判定する（Ｓ２５０５）。前記ステップＳ２５０２で「Ｒ」（逆順）と判定された場合、ノードの末尾からキーの比較を行い（Ｓ２５０４）、現在処理中のノードがリーフノードであるか否かを判定する（Ｓ２５０５）。

前記ステップＳ２５０５でＮＯと判定された場合、該当する子ノードへジャンプし（Ｓ２５０６）、前記ステップＳ２５０２に戻る。そして、リーフノードとなるまで、前記ステップＳ２５０２から前記ステップＳ２５０５までを繰り返す。前記ステップＳ２５０５でＹＥＳと判定された場合、キー挿入位置を特定し、挿入する（Ｓ２５０７）。

次に、前記ステップＳ２５０７でキーを挿入することで、ノード分割が発生するか否かを判定する（Ｓ２５０８）。

前記ステップＳ２５０８でＮＯと判定された場合、処理を終了する（Ｓ２５１５）。前記ステップＳ２５０８でＹＥＳと判定された場合、新規ノードを生成し（Ｓ２５０９）、読み込み順序フラグを決定するため、現在のキー傾向が減少傾向であるか否かを判定する（Ｓ２５１０）。

前記ステップＳ２５１０でＮＯと判定された場合、リーフノードページの読み込み順序フラグを「Ｆ」（通常順）に設定する（Ｓ２５１１）。前記ステップＳ２５１０でＹＥＳと判定された場合、リーフノードページの読み込み順序フラグを「Ｒ」（逆順）に設定する（Ｓ２５１２）。

前記ステップＳ２５１１、または前記ステップＳ２５１２が終了した場合、新規ノードにキーを移動し、親ノードのポインタを更新する（Ｓ２５１３）。そして、親ノードにジャンプし（Ｓ２５１４）、前記ステップＳ２５０８に戻る。親ノードのノード分割がなくなるまで、前記ステップＳ２５０８から前記ステップＳ２５１４を繰り返し、処理を終了する（Ｓ２５１５）。

図２１ａ〜図２１ｃは、上記読み込み順序フラグを設定したインデックス処理の例を表した図である。

図２１ａは、ランダム傾向時に「０、１、２、３、４、５、６」の順にキーを挿入した場合のインデックスを表している。

キーを「０、１、２、３」の順に挿入した場合のインデックスはインデックス１１０２となる。読み込み順序フラグ１１０１は、ランダム傾向のため、「Ｆ」となっている。ここで、「４」のキーを挿入した場合を図２０に示したフローチャートを用いて具体的に説明する。

ステップＳ２５０２では、読み込み順序フラグが「Ｆ」となっているため、「Ｆ」と判定され、ノードの先頭からキーの比較を行う（Ｓ２５０３）。次に、現在処理するノードはリーフノードなので、ステップＳ２５０５ではＹＥＳが選択される。ステップＳ２５０７でキー挿入位置を特定すると、図中一番右に挿入される。

キー格納数が５であるため、ステップＳ２５０８では、ＹＥＳと判定され、新規ノードが生成される（Ｓ２５０９）。キー傾向はランダム傾向であるため、ステップＳ２５１０ではＮＯと判定され、新規ノードの読み込み順序フラグは「Ｆ」に設定される（Ｓ２５１１）。新規ノードに「２、３、４」のキーを移動し、親ノードのポインタを更新する（Ｓ２５１３）。この場合は、親ノードがないため、親ノードを生成する。親ノードの読み込み順序フラグは、ランダム傾向であるため、「Ｆ」の通常順が設定される。

ステップＳ２５０８に戻り、親ノードのノード分割がないため、ステップＳ２５０８ではＮＯと判定され、処理を終了する（Ｓ２５１４）。処理を終了したインデックスは、インデックス１１０３となる。

同様に、「５、６」のキーを挿入するとインデックス１１０４となる。

図２１ｂは、増加傾向時に「０、１、２、３、４、５、６」の順にキーを挿入した場合のインデックスを表している。読み込み順序フラグ１１０５は「Ｆ」が設定される。この場合、上記図２１ａと同様に、キーの読み込み順序は通常順となる。図２１ａと同様にインデックス処理を行うと、「０、１、２、３」のキーを挿入して、インデックス１１０６になり、「４、５、６」のキーを挿入すると、インデックス１１０７となる。

図２１ｃは、減少傾向時に「１１、１０、９、８、７、６、５、４、３」の順にキーを挿入した場合のインデックスを表している。読み込み順序フラグ１１０８は、減少傾向のため、「Ｒ」の逆順が設定される。

図２１ａと同様にインデックス処理を行うと、「１１、１０、９、８」のキーを挿入して、インデックス１１０９となる。さらに「７」のキーを挿入すると、ノードの格納数が上限であるのでノード分割を行って、新たなノードの先頭に「７」を挿入してインデックス１１１０となる。次に、「６、５、４、３」のキーを挿入すると逆順にキーを書き込んでいくため、インデックス１１１０には、「７」の位置を移動せずに「６，５，４」を挿入する。そして、「３」を挿入するとノード分割が発生し、新たなノードに「３」を挿入してインデックス１１１１となる。

ここで、読み込み順序フラグが「R」の場合、親ノード、すなわち参照ノードにおける子ノードへのポインタも逆順となる。このため、参照ノードのキーの値は、「８，４」の順序で書き込まれる。

また、リーフノード、及び索引ノードは、メモリやディスクなど記憶装置１６０に格納される場合、ページ単位に格納される。図２１に示したインデックスは説明図であり、キーはページの各アドレスに割り当てられる。この割り当て順序を定義したものが、読み込み順序フラグである。読み込み順序フラグを適用するインデックスでは、キーの値をノードに書き込む際には、値の「大小」を反転して書き込み、キーを読み出す際には、図示の格納位置の「左右」を反転して読み出すことになる。

以上のように、本第６実施形態によれば、キー傾向が減少傾向であればキーの読み込み順序を逆順とし、キー傾向が増加またはランダムであれば通常順とすることで、減少傾向の場合にはキーの値が大きい順に書き込むことで、キーを挿入するたびに、データの移動が発生するのを抑制でき、インデックス処理の負荷を低減して、高速な検索を実現できる。

以上、本発明の第六の実施形態について説明した。

＜第７実施形態＞
以下では、本発明の第七の実施形態について説明する。

前記第一から第六の実施形態では、ストリームデータ処理システムに対し、インデックス処理を適用していた。第七の実施形態では、データベースシステムに対し、インデックス処理を適用する例を示す。インデックス処理は、前記第一から第六実施形態のいずれか、あるいは各実施形態を組み合わせたものを適用することができる。

図２２は本発明の一実施形態が適用されたデータベースシステム、及び関連するシステム構成を示すブロック図である。

データベースシステム１２００は、入力された挿入データ１２０８を記憶装置１６０にテーブルデータ１２６４として格納し、コマンド入力部１１０が計算機１０２から問い合わせ文（ＳＱＬ文）を受け付けて、テーブルデータ１２６４の検索を行う点が前記第１実施形態と相違する。その他の構成は、前記第１実施形態と同様のものに同一の符号を付して重複説明を省略する。以下、前記第１実施形態の図１に示したストリームデータ処理システムと、本第６実施形態のデータベースシステム１２００の相違点を説明する。図２２において、ＲＦＩＤリーダ１０４、センサノード１０５、計算機１０６上で実行されるアプリケーション１０７のデータソースからデータベースシステム１２００へデータを入力する場合に、ストリームデータ処理システム１００のタプル（レコード）構造での入力ではなく、問合せ（ＳＱＬ文）での入力となり、コマンド入力部１２１０はＳＱＬの問い合わせを解析してデータベース処理を実行する。

前記第１実施形態のストリームデータ処理システム１００では、ユーザ１０１または計算機１０２からの問合せを登録し、登録された問合せを逐次実行するため、問合せ管理部１２０があったが、データベースシステム１２００では、問合せが来るたびに出力結果１８０を出力するため、問合せ情報を保持する必要がないため、前記第1実施形態のような問合せ管理部１２０は必要ない。一方、データベースシステム１２００では問合せから実行木を生成するモジュールとして、問合せ実行部１２７０中に実行木生成部１２２１を必要とする。

データ特性情報管理部１２３０は、前記第１実施形態のストリームデータ特性情報管理部１３０に代わって挿入データ１２０８の特性を管理する。なお、処理の内容は、前記第１実施形態のストリームデータ特性情報管理部１３０と同様である。挿入データ監視情報管理部１２４０は、前記第１実施形態のストリームデータ監視情報管理部１４０が監視する対象を挿入データ１２０８に変更したものであり、処理の内容は前記第１実施形態のストリームデータ監視情報管理部１４０と同様である。

記憶装置１２６０は、前記第１実施形態の記憶装置１６０に代わってデデータベースシステム１２００の外部でータを格納するものである。データベースシステム１２００の場合、記憶装置１２６０はＳＡＮストレージ装置やＮＡＳ等の外部記憶装置となる場合があり、図２２では、別のシステムとしている。同一計算機内に記憶装置１２６０を保持しても構わない。また、ストリームデータ処理システム１００とは異なり、データベースシステム１２００では、データ破棄コマンドがない限り、データを保持し続ける。また、データ構造もテーブル構造となるため、テーブル保存領域１２６３、及びテーブルデータ１２６４を必要とする。

問合せ実行部１２７０は、前記第１実施形態の問合せ実行部１７０の一時保存領域管理部１７２をテーブル管理部１２７２に置き換え、実行木生成部１２２１を新たに追加したものである。問合せ実行部１２７０は、記憶装置１２６０へのデータ格納や、記憶装置１２６０からのデータ取得を行い、問合せを実行する。

本第７実施形態では、上記のようなシステム構成において、インデックス１６２のノード分割割合を切り替える。ノード分割割合切り替え方法、及びキー傾向の設定方法、インデックスの読み出し順序は、第一から第六の実施形態に示した方法と同様に処理できる。

以上、本発明の第七の実施形態について説明した。

本発明は、上記に示した第一から第七の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。また、上記に示した第一から第七の実施形態を組み合わせた実施形態も可能である。

例えば、上記の第１の実施形態では、図８に示したインデックス管理テーブル１５１を用いて説明したが、図２３に示すインデックス管理テーブル１５１を用いて、キーが挿入されるリーフノード位置に基づいて、ノード分割割合を変更してもよい。本手法は、キーがグループ化されており、グループによって傾向が異なる場合、若しくはインデックスの木構造全体におけるリーフノード位置により傾向が異なる場合に、インデックス容量が小さく、高速処理が可能なインデックスを提供することができる。第一の実施形態に示した、前記発散傾向、若しくは収束傾向時のインデックス処理に用いることが可能である。

以下に、詳しく説明する。

図２３は、インデックス管理テーブル１５１の構成例を表した図である。

インデックス名カラム１３０１、ストリームデータ名カラム１３０２、カラム名カラム１３０３、キー傾向カラム１３０４は、それぞれ、前記第１実施形態の図８に示したインデックス管理テーブル１５１のインデックス名カラム７０１、ストリームデータ名カラム７０２、カラム名カラム７０３、キー傾向カラム７０４に対応する。

リーフノード位置カラム１３０５には、インデックスの木構造全体におけるリーフノードの位置（左から数えて何番目など）を格納する。

分割割合カラム１３０６には、前記リーフノード位置カラムに対応するノード分割割合を格納する。

例えば、行１３０７は、インデックス名が「インデックス１」、ストリームデータ名が「Ｓ１」、カラム名が「温度」であるインデックスに対し、「増加傾向」時において、リーフノード位置が「０＜＝位置＜１０」である場合に、「４：３」にノード分割することを表している。また、行１３０８は、リーフノード位置が「１０＜＝位置＜９０」である場合に、「５：２」にノード分割することを表し、行１３０９は、リーフノード位置が「９０＜＝位置＜１００」である場合に、「６：１」にノード分割することを表している。

ここで、インデックス管理テーブル１５１を基に、インデックス１６２に対して分割割合変更命令を出力する。また、リーフノード位置カラム１３０５に格納する情報はすべての情報が入力される必要はない。

インデックス処理を行う場合には、第一の実施形態において、図８に示したインデックス管理テーブル１５１の代わりに図２３に示したインデックス管理テーブル１５１を用いて、図９に示したキー挿入時のインデックス処理において、前記ステップＳ２００２において、リーフノード位置を特定し、前記ステップＳ２００８において、キーの傾向とリーフノード位置とに対応するノード分割割合を取得することで実現可能である。

また、上記の第２の実施形態では、図１４に示したキー傾向予測処理を行う例を説明したが、図２４に示すキー傾向予測処理のように、監視情報管理テーブル１４３において監視情報のうち、最新の値を格納する現在の値カラムを用いて、キー傾向を予測しても構わない。

以下に、詳しく説明する。

図２４は、キー傾向予測処理を表したフローチャートである。

ステップＳ２６０１、ステップＳ２６０２、ステップＳ２６０３、ステップＳ２６０４、ステップＳ２６１２は、それぞれ、前記第１実施形態の図１４に示した前記ステップＳ２１０１、前記ステップＳ２１０２、前記ステップＳ２１０３、前記ステップＳ２１０４、前記ステップＳ２１１２に対応する。

ステップＳ２６０５において、監視情報管理テーブル１４３を参照し、最新の監視情報から過去に遡り、一定間隔分の現在の値カラム６０７の値を取得する。

ここで、取得する現在の値カラム６０７の値は、任意の間隔、若しくは任意の個数で構わない。例えば、図１３に示した前記監視情報管理テーブル１４３における現在の値カラム６０７を用いて、１０：００、１０：０５、１０：１０における現在の値カラム６０７の値３個を取得してもよい。

次に、前記取得した現在の値が増加し続けているか否かを判定する（Ｓ２６０７）。ここで、増加し続けている判定は、任意の定義で構わない。例えば、すべての要素が増加しており、同じ値を許可しない定義としても、最初と最後を比較した場合に、増加しており、途中の要素は同じ値でも構わない定義としてもよい。

前記ステップＳ２６０７でＹＥＳと判定された場合、増加傾向に設定し（Ｓ２６０８）、処理を終了する（Ｓ２６１２）。前記ステップＳ２６０７でＮＯと判定された場合、前記取得した現在の値が減少し続けているか否かを判定する（Ｓ２６０９）。ここで、減少し続けている判定は、任意の定義で構わない。例えば、すべての要素が減少しており、同じ値を許可しない定義としても、最初と最後を比較した場合に、減少しており、途中の要素は同じ値でも構わない定義としてもよい。

前記ステップＳ２６０９でＹＥＳと判定された場合、減少傾向に設定し（Ｓ２６１１）、処理を終了する（Ｓ２６１２）。前記ステップＳ２６０９でＮＯと判定された場合、ランダム傾向に設定し（Ｓ２６１０）、処理を終了する。

また、上記の実施形態では、ストリームデータ処理システム、データベースシステムにおいてインデックス処理を行う例を説明したが、ストリームデータ処理システム、データベースシステム以外のシステムで、上記の実施形態で示したインデックス処理を行ってもよい。

また、上記の実施形態では、ストリームデータ処理システム１００、またはデータベースシステム１２００は、任意のコンピュータシステムとして説明したが、前記ストリームデータ処理システム１００、またはデータベースシステム１２００で行う処理の一部、若しくは全部をストレージ装置で行ってもよい。

また、上記の実施形態では、センサノード１０５が温度データをストリームデータ１０８としてストリームデータ処理システム１００に入力する例を説明したが、これに限定されるものではない。例えば、センサノード１０５に代わって多数のセンサノードを管理するセンサネットサーバが、センサノードの測定値をストリームデータ１０８と出力し、ストリームデータ処理システム１００でユーザ１８１が理解可能な有意な情報を含む出力結果１８０に変換し、計算機１８２へ提供するようにしてもよい。また、ストリームデータ処理システム１００に入力するデータは、ＲＦＩＤリーダで読み込んだタグの情報、ＲＦＩＤを一元管理するＲＦＩＤミドルウェアシステムである計算機１０６から入力されるデータでもよい。他にも、ＥＴＣシステムなどの交通情報、自動改札機やクレジットカードなどのＩＣカード情報、株価情報などの金融情報、製造工程管理情報などでもよい。

＜補足＞
なお、請求項５の発明に記載のインデックス処理方法において、
前記キー傾向は、該挿入されるキー系列が単調増加、若しくは単調増加ではないが、全体的に増加していることを表す増加傾向と、該挿入されるキー系列が単調減少、若しくは単調減少ではないが、全体的に減少していることを表す減少傾向と、該挿入されるキー系列に特徴がなく、ランダムな値であることを表すランダム傾向と、であり、
前記データ監視情報を取得する処理は、監視情報を取得した時点における該監視対象のデータの値を表す、現在の値情報を取得する処理をさらに含み、
前記キー傾向決定処理は、
一定間隔の前記監視情報における現在の値情報が増加し続けている場合、増加傾向に設定し、一定間隔の前記監視情報における現在の値情報が減少し続けている場合、減少傾向に設定し、上記何れでもない場合、ランダム傾向に設定することを特徴とするインデックス処理方法。

また、請求項５に記載のインデックス処理方法において、
前記キー傾向は、該挿入されるキー系列が単調増加、若しくは単調増加ではないが、全体的に増加していることを表す増加傾向と、該挿入されるキー系列が単調減少、若しくは単調減少ではないが、全体的に減少していることを表す減少傾向と、該挿入されるキー系列に特徴がなく、ランダムな値であることを表すランダム傾向と、であり、
前記データ監視情報を取得する処理は、
該監視対象のデータと前記監視対象の１個前のデータと比較し、増加したか否かを表す増加カウンタと、該監視対象のデータと前記監視対象の１個前のデータと比較し、減少したか否かを表す減少カウンタとを取得する処理をさらに含み、
前記キー傾向決定処理は、
増加カウンタの値と減少カウンタの値の比が予め設定した増加カウンタ閾値を上回った場合、増加傾向に設定し、減少カウンタの値と増加カウンタの値の比が予め設定した減少カウンタ閾値を上回った場合、減少傾向に設定し、何れの閾値も上回らなかった場合、ランダム傾向に設定することを特徴とするインデックス処理方法。

また、請求項１４の発明に記載のインデックス処理方法において、
前記インデックスのノード分割時におけるキー配分割合を表すノード分割割合を決定する処理をさらに含み、
前記ノード分割が多発していることを検知する処理において、ノード分割が多発していることを検知した場合に、
前記ノード分割割合を既定値に戻すことを特徴とするインデックス処理方法。

また、インデックスキー挿入時にインデックスのノードにおいてキー格納上限数を上回った場合にノード分割するインデックス処理方法において、
前記インデックスに前記キーをページの各アドレスに割り当てる順序が通常か逆順かを表すフラグである読み込み順序フラグを備えることを特徴とするインデックス処理方法。

上記のインデックス処理方法において、
前記インデックスにキーが挿入されたときの処理は、
前記インデックスのノードの前記読み込み順序フラグが通常か逆順かを判定する処理と、
前記読み込み順序フラグが通常の場合に、ノードの先頭からキーを大小比較する処理と、
前記読み込み順序フラグが逆順の場合に、ノードの末尾からキーを大小比較する処理と、
前記インデックスの該ノードがリーフノードであるか否かを判定する処理と、
前記ノードがリーフノードでない場合に、子ノードへジャンプし、上記処理をリーフノードに辿り着くまで繰り返す処理と、
前記ノードがリーフノードでない場合に、キーのノード内での位置を表すキー挿入位置を特定する処理と、
を含むことを特徴とするインデックス処理方法。

また、上記に記載のインデックス処理方法において、
前記インデックスに挿入されるキー系列の特徴を表すキー傾向を決定するキー傾向決定処理を含み、
前記インデックスにキーが挿入されたときの処理は、
前記ノードにノード分割が発生したか否かを判定する処理と、
新規ノードを生成する処理と、
前記キー傾向が該挿入されるキー系列が単調減少、若しくは単調減少ではないが、全体的に減少していることを表す減少傾向か否かを判定する処理と、
前記キー傾向が減少傾向の場合に、前記ノードの読み込み順序フラグを逆順に設定する処理と、
前記キー傾向が減少傾向でない場合に、前記ノードの読み込み順序フラグを通常に設定する処理と、
前記新規ノードにキー移動し、親ノードのポインタを更新する処理と、
親ノードへジャンプし、前記親ノードにおいてノード分割が発生するか否かを判定する処理と、
上記処理を親ノードがノード分割発生しなくなるまで行う処理と、
を含むことを特徴とするインデックス処理方法。

以上のように、本発明は時々刻々と変化するストリームデータのインデックス処理を少ないインデックス容量で高速に処理することができる。特に、リアルタイムで処理する必要があるストリームデータの量が膨大な量になるファイナンシャルアプリケーション、交通情報システム、トレーサビリティシステム、センサモニタリングシステム、計算機システム管理などに適用することができる。

本発明の第一実施形態を示しストリームデータ処理システム、及び関連するシステムの構成を示すブロック図である。本発明の計算機システムの一例を示すブロック図。ストリームデータ１０８の好適なデータフォーマットの例を模式的に表した図である。連続して入力されたストリームデータ１０８を例示した図であり、温度ストリームデータ（Ｓ１）１０８₁を表している。問合せをストリームデータ処理システム１００に登録する際の好適なコマンドの記述例を示す説明図である。ノード分割割合をストリームデータ処理システム１００に設定する際の好適なコマンドの記述例を示す説明図である。ストリームデータの特性情報をストリームデータ処理システム１００に設定する際の好適なコマンドの記述例を示す説明図である。問合せ管理テーブル１２２の構成例を表した図である。ストリーム特性管理テーブル１３２の構成例を表した図である。インデックス管理テーブル１５１の構成例を表した図である。キー挿入時のインデックス処理の処理手順を表したフローチャートである。ランダム傾向時のインデックスのノード分割の例を示す説明図である。増加傾向時のインデックスのノード分割の例を示す説明図である。減少傾向時のインデックスのノード分割の例を示す説明図である。従来例のインデックスのノード分割の例を示す説明図である。問合せを処理する実行木の好適な構成例を示す説明図である。出力結果１８０の例を表した説明図である。第２の実施形態を示し、監視情報管理テーブル１４３の構成例を表した図である。第２の実施形態を示し、キー傾向予測処理の処理手順を表したフローチャートである。第３の実施形態を示し、分割割合算出処理の処理手順を表したフローチャートである。第３の実施形態を示し、キー傾向、及びキーの挿入位置からノード分割割合を算出し、ノード分割する例の前提を示す説明図である。第３の実施形態を示し、挿入位置でノード分割するインデックス処理方法におけるインデックスの例を示す説明図である。第３の実施形態を示し、ノード分割割合を指定するインデックス処理方法におけるインデックスの例を示す説明図である。第３の実施形態を示し、キー傾向、及びキーの挿入位置からノード分割割合を算出し、ノード分割するインデックス処理方法におけるインデックスの例を示す説明図である。第４の実施形態を示し、インデックス監視情報管理テーブル１５４の構成例を表した図である。第４の実施形態を示し、分割多発検知及び分割多発時の分割割合決定処理の処理手順を表したフローチャートである。第５の実施形態を示し、分割割合履歴からの分割割合決定処理の処理手順を表したフローチャートである。第６の実施形態を示し、読み込み順序フラグに基づいたキー挿入処理の処理手順を表したフローチャートである。第６の実施形態を示し、読み込み順序フラグに基づいたキー挿入処理において、ランダム傾向時のインデックスの例を示す説明図である。第６の実施形態を示し、読み込み順序フラグに基づいたキー挿入処理において、増加傾向時のインデックスの例を示す説明図である。第６の実施形態を示し、読み込み順序フラグに基づいたキー挿入処理において、減少傾向時のインデックスの例を示す説明図である。第７の実施形態を示し、本発明の一実施形態が適用されたデータベースシステム、及び関連するシステムの構成を示すブロック図である。インデックス管理テーブルの他の構成例を示す図である。分割割合算出処理の他の処理手順を表したフローチャートである。

符号の説明

１００ストリームデータ処理システム
１０１ユーザ
１０２計算機
１０３アプリケーション
１０４ＲＦＩＤリーダ
１０５センサノード
１０６計算機
１０７アプリケーション
１０８ストリームデータ
１０９ネットワーク
１１０コマンド入力部
１２０問合せ管理部
１２１問合せ設定部
１２２問合せ管理テーブル
１３０ストリームデータ特性情報管理部
１３１特性情報設定部
１３２特性情報管理テーブル
１４０ストリームデータ監視情報管理部
１４１ストリームデータ監視部
１４２キー傾向予測部
１４３監視情報管理テーブル
１５０インデックス管理部
１５１インデックス管理テーブル
１５２インデックス設定部
１５３分割割合算出部
１５４インデックス監視情報管理テーブル
１５５インデックス監視部
１５６分割多発検知部
１５７分割履歴参照部
１５８読み出し順序制御部
１６０記憶装置
１６１インデックス領域
１６２インデックス
１６３一時保存領域
１６４一時保存データ
１７０問合せ実行部
１７１スケジューラ
１７２一時保存領域管理部
１７３実行木プール領域
１７４実行木
１８０出力結果

Claims

計算機に入力されたデータの項目を示すキーと、前記計算機は前記キーを格納するノードを備えて、前記計算機が、前記キーに関連付けられた前記データを検索する木構造のインデックスに前記キーを挿入するインデックス処理方法において、
前記計算機が、前記キーを挿入する前記ノードを特定する処理と、
前記計算機は、前記特定したノードに格納されているキーの数が、予め設定されたキー格納上限数を超えたか否かを判定する処理と、
前記計算機は、前記キーの数が前記キー格納上限数を超えたときには、前記特定したノードを第１のノードと第２のノードに分割する処理と、
を含み、
前記ノードを分割する処理は、
前記計算機は、前記特定したノードに格納されたキーを、第１のノードと第２のノードに振り分ける分割割合を変更する処理と、
を含み、
前記振り分ける分割割合を変更する処理は、
前記ノードに挿入されるキーの値の特徴を表すキー傾向を決定するキー傾向決定処理と、
前記キー傾向に基づいて、前記分割割合を決定するノード分割割合決定処理と、を含み、
前記キー傾向決定処理は、
時刻情報を取得する処理と、
前記時刻情報に対応する前記キー傾向を取得する処理と、
を含むことを特徴とするインデックス処理方法。
前記振り分ける割合を変更する処理は、
前記キー傾向を取得する処理と、
前記キー傾向に対応する分割割合を取得する処理と、
を含むことを特徴とする請求項１に記載のインデックス処理方法。
前記インデックスに挿入されるキーに対応するデータを監視してデータ監視情報を取得する処理をさらに含み、
前記キー傾向決定処理は、
前記データ監視情報に基づいて前記キー傾向の予測値を演算し、当該予測値をキー傾向として決定することを特徴とする請求項１に記載のインデックス処理方法。
前記データ監視情報は、前記挿入するキーに対応するデータの値の変化をキー系列として保持し、
前記キー傾向決定処理は、
前記キー系列が全体的に増加しているときにはキー傾向を増加傾向と決定し、前記キー系列が全体的に減少しているときにはキー傾向を減少傾向と決定し、前記キー系列が増加傾向と減少傾向の何れでもないときにはキー傾向をランダム傾向と決定することを特徴とする請求項３に記載のインデックス処理方法。
前記分割割合に基づいて、前記特定したノードに格納されたキーを、第１のノードと第２のノードに格納する処理をさらに含み、
前記ノード分割割合決定処理は、
前記キー傾向が増加傾向または減少傾向のときには、前記第１のノードに格納するキーの数と、第２のノードに格納するキーの数を異ならせる分割割合を設定し、当該分割割合は前記キー傾向が増加傾向のときには、前記第１のノードに格納するキーの数は前記キー傾向が減少傾向のときよりも大きくなる値であることを特徴とする請求項４に記載のインデックス処理方法。
前記ノード分割割合決定処理は、
前記キー傾向と、前記インデックスにキーが挿入されるノードの位置を表すノード位置と、前記キー傾向と前記ノード位置とに対応する分割割合を取得し、当該取得した分割割合を設定することを特徴とする請求項１に記載のインデックス処理方法。
前記ノード分割割合決定処理は、
前記キー傾向が増加傾向または減少傾向の場合には、前記キー傾向と、前記キー格納上限数と、新たに挿入されるキーのノード内での位置を表すキー挿入位置とに基づいて、前記割合を算出することを特徴とする請求項１に記載のインデックス処理方法。
前記インデックスを監視して当該インデックスの状態をインデックス監視情報として取得する処理をさらに含み、
前記インデックス監視情報は、時刻情報と、前記インデックスのノードに設定された分割割合とを含み、
前記ノード分割割合決定処理は、
前記インデックス監視情報の前記時刻情報に対応するインデックスの分割割合を設定することを特徴とする請求項１に記載のインデックス処理方法。
前記ノード分割割合決定処理は、
前記ノード分割割合情報を時刻情報に係る条件である時刻条件で絞り込む処理と、
外部記憶媒体に保持されている属性情報に係る条件である外部属性条件がある場合に、さらに絞り込む処理と、
該絞り込み結果がある場合に、最も頻度の高いノード分割割合に設定する処理と、
を含むことを特徴とする請求項８に記載のインデックス処理方法。
前記ノードを分割する処理は、
前記インデックスに挿入されるキーに対応するデータを監視してデータ監視情報を取得する処理と、
前記インデックスを監視して当該インデックスの状態をインデックス監視情報として取得する処理と、
前記データ監視情報と、前記インデックス監視情報とに基づいて前記インデックスでノードの分割回数を取得する処理と、
前記ノードの分割回数が所定のしきい値を超えたときにノードの分割が多発したことを判定する処理と、
を含むことを特徴とする請求項１に記載のインデックス処理方法。
前記ノードの分割が多発したことを判定する処理は、
前記データ監視情報に基づいて、所定の時間内の前記ノードの分割回数の予測値を演算する処理と、
前記インデックス監視情報から所定の時間内に前記インデックスで発生したノードの分割回数を取得する処理と、
前記発生したノードの分割回数と、前記分割回数の予測値の比が所定値を超えたときに、ノードの分割が多発したことを判定する処理と、
を含むことを特徴とする請求項１０に記載のインデックス処理方法。
前記ノードの分割が多発したと判定されたときに、前記データ監視情報を再度取得する処理をさらに含み、
前記キー傾向決定処理は、
前記再度取得したデータ監視情報に基づいて前記キー傾向の予測値を演算し、当該予測値をキー傾向として決定することを特徴とする請求項１０に記載のインデックス処理方法。
計算機へ入力されたデータの項目を示すキーと、前記キーを格納するノードを備えて、前記キーに関連付けられた前記データを検索する木構造のインデックスにキーを挿入するインデックス処理を計算機に実行させるプログラムにおいて、
前記キーを挿入する前記ノードを特定する手順と、
前記特定したノードに格納されているキーの数が、予め設定されたキー格納上限数を超えたか否かを判定する手順と、
前記キーの数が前記キー格納上限数を超えたときには、前記ノードを第１のノードと第２のノードに分割する手順と、を含み、
前記ノードを分割する手順は、
前記ノードに挿入されるキーの値の特徴を表すキー傾向を決定するキー傾向決定手順と、
前記特定したノードに格納されたキーを、第１のノードと第２のノードに振り分ける分割割合を前記キー傾向に基づいて決定する手順と、
を計算機に実行させ、
前記キー傾向決定手順は、
時刻情報を取得する手順と、
前記時刻情報に対応する前記キー傾向を取得する手順と、
を含むことを特徴とするプログラム。
プロセッサと記憶装置及びインターフェースを備えて、前記記憶装置に設定されて、前記インターフェースを介して入力されたデータを格納するデータ領域と、
前記記憶装置に設定されて、前記データの項目を示すキーと、前記キーを格納するノードを備えて、前記キーに関連付けられた前記データを検索する木構造のインデックスを格納するインデックス領域と、を有し、前記プロセッサが前記入力されたデータに対応するキーを前記インデックスに挿入する計算機システムにおいて、
前記キーを挿入する前記ノードを特定する挿入位置特定部と、
前記特定したノードに格納されているキーの数が、予め設定されたキー格納上限数を超えたか否かを判定するノード分割判定部と、
前記キーの数が前記キー格納上限数を超えたときには、前記ノードを第１のノードと第２のノードに分割するノード分割部と、を備え、
前記ノード分割部は、
前記ノードに挿入されるキーの値の特徴を表すキー傾向を決定するキー傾向決定部と、
前記特定したノードに格納されたキーを、第１のノードと第２のノードに振り分ける分割割合を前記キー傾向に基づいて決定する分割割合決定部と、
を備え、
前記分割割合決定部は、
時刻情報を取得し、
前記時刻情報に対応するキー傾向を取得し、
前記ノードに挿入されるキーの値の特徴を表すキー傾向を決定し、
前記キー傾向に基づいて、前記分割割合を決定することを特徴とする計算機システム。
前記データ領域に格納されるデータを監視してデータ監視情報を取得するデータ監視部をさらに有し、
前記キー傾向決定部は、
前記データ監視情報に基づいて前記キー傾向の予測値を演算し、当該予測値をキー傾向として決定することを特徴とする請求項１４に記載の計算機システム。
前記インデックス領域を監視してインデックスの状態をインデックス監視情報として取得するインデックス監視部をさらに有し、
前記データ監視情報と、前記インデックス監視情報とに基づいて前記インデックスでのノードの分割回数を取得する分割回数取得部と、
前記ノードの分割回数が所定のしきい値を超えたときにノードの分割が多発したことを判定する分割多発検知部と、
を備えたことを特徴とする請求項１４に記載の計算機システム。