以下、本発明の実施の形態について説明する。
図1は本発明の一実施形態が適用されたストリームデータ処理システム、及び関連するシステム構成を示すブロック図である。
図1において、ストリームデータ処理システム100は、RFIDリーダ104、またはセンサノード105、または計算機106上で実行されるアプリケーション107からリアルタイムに送信された情報をストリームデータ108として入力とし、ユーザ101、または計算機102上で実行されるアプリケーション103により入力されたコマンドに基づき、入力されたストリームデータ108を有意な情報に変換して、出力結果180を生成し、ユーザ181、または計算機182上で実行されるアプリケーション183へ提供するストリームデータ処理を実行する計算機(またはサーバ)である。ストリームデータは複数のストリームデータ1081、1082、・・・、108lから構成される。
前記計算機102は、ネットワーク109を介してストリームデータ処理システム100に接続されている。ネットワーク109は、イーサネット(登録商標)、光ファイバ、FDDI(Fiber Distributed Data Interface)等で接続されるローカルエリアネットワーク(LAN)、若しくはLANよりも低速なインターネットを含んだワイドエリアネットワーク(WAN)でも差し支えない。
ここで、前記ストリームデータ処理システム100、前記計算機102、前記計算機106、前記計算機182は、パーソナルコンピュータ、ワークステーションなどの任意のコンピュータシステムで構成され、同一の計算機でも異なる計算機でも構わない。また、前記アプリケーション103、前記アプリケーション107、前記アプリケーション183は、同一のアプリケーションでも異なるアプリケーションでも構わない。また、前記ユーザ101、前記ユーザ181は同一のユーザでも異なるユーザでも構わない。
ここで、本実施形態で扱うストリームデータ108は、映像や音声の配信で用いられるストリームとは異なり、ひとつのストリームデータが有意な情報に対応するものである。また、ストリームデータ処理システム100がRFIDリーダ104、またはセンサノード105、または計算機106上で実行されるアプリケーション107から前記ストリームデータ処理システム100が受信するストリームデータ108は、連続的あるいは間欠的であり、ストリームデータ毎に異なる製品の情報や異なる要素が含まれる。
ストリームデータ処理システム100は、コマンド入力部110、問合せ管理部120、ストリームデータ特性情報管理部130、ストリームデータ監視情報管理部140、インデックス管理部150、記憶装置160、問合せ実行部170から構成される。
コマンド入力部110は、前記ユーザ101、または前記計算機102上で実行されるアプリケーション103により入力されたコマンドを受け付ける。次に、問合せ管理部120は、前記コマンド入力部110で受け付けた前記ストリームデータを有意な情報に変換する処理内容を表す問合せを管理する。次に、ストリームデータ特性情報管理部130は、前記コマンド入力部110で受け付けたストリームデータの属性値の傾向や分布など、ストリームデータの属性値の特徴を表すストリームデータの特性情報を管理する。
次に、ストリームデータ監視情報管理部140は、前記ストリームデータ処理システム100に入力されるストリームデータ108を監視し、ストリームデータ108の統計情報などのストリームデータに係る情報を表す監視情報を取得し、管理する。次に、インデックス管理部150は、記憶装置160におけるインデックス162のノード分割時におけるキー配分割合を表すノード分割割合などのインデックスに係る情報を表すインデックス情報を管理する。
次に、記憶装置160は、前記ストリームデータ108、及び前記ストリームデータ108に対するインデックスを保存している。ここで、記憶装置160は、メモリ、ディスク、テープ、フラッシュメモリなどのいかなる記憶媒体で構わない。また、記憶装置160は、複数の記憶媒体から構成される階層構造となっていてもよい。問合せ実行部170は、前記記憶装置160に保存されているストリームデータ108の情報を有意な情報に変換してから出力する。
ここで、ストリームデータ処理システム100のハードウェア環境を図2に示す。ストリームデータ処理システム100は、ひとつの計算機で実行され、演算処理を行うCPU11と、ストリームデータ108やストリームデータ処理のプログラムを格納するメモリ12と、データを格納するディスク装置13と、CPU11とディスク装置13やネットワーク109を接続するインターフェース14を含んでいる。
ネットワーク109には、ストリームデータ処理システム100に対してコマンドを入力する計算機102と、ストリームデータ処理システム100が出力する出力結果180を利用する計算機182が接続される。
また、ネットワーク109には、ストリームデータ108を出力する計算機106と、センサノード105及びRFID(Radio Frequency Identification)リーダ104が接続される。計算機106は、例えば、製品番号などを出力し、センサノード105は環境の測定結果(例えば、温度)を出力し、RFIDリーダ104は読み取ったRFIDタグの情報を出力する。これらの出力がストリームデータ108として、ストリームデータ処理システム100へ入力される。
ここで、上記図1に示した記憶装置160は、メモリ12の所定の領域とディスク装置13の所定の領域から構成される。ストリームデータ108は、インデックスと共に主にメモリ12上の記憶装置160に格納され、問い合わせに対して高速な検索を可能にする。時々刻々と変化するストリームデータ108には、検索対象となるデータをメモリ12上の記憶装置160に格納しておき、検索の用途が済んだデータはディスク装置13上の記憶装置160に格納することができる。例えば、ストリームデータ108がセンサノード105の測定値(温度など)の場合、ユーザ181が監視したい測定値は本日の値であり、昨日以前のものは高速に検索できなくても問題は生じない。このため、本日の測定値をメモリ12上に格納し、昨日以前の測定値をアーカイブとしてディスク装置13上に格納することができる。
図1において、本発明の概要を説明する。ストリームデータ処理システム100は、ユーザ101、または計算機102上で実行されるアプリケーション103が入力した問合せに基づいて、入力されるストリームデータ108を有意な情報に変換する。ここで、有意な情報とは、例えば、センサノード105の測定値は、バイナリ値のままではユーザ101,181が理解できないので、所定の単位系を加えた数値に変換した情報である。
そして、ストリームデータの検索処理を高速化するため、前記ストリームデータ108に対しインデックス162を用意し、前記インデックス162を介して、問合せ実行部170は前記ストリームデータ108を読み出す。その際に、ユーザ101、または計算機102で実行されるアプリケーション103は、前記インデックス162のインデックスキーの値の傾向やインデックスキーの値の分布をストリームデータ特性情報管理部130に入力し、インデックスのノード分割割合をインデックス管理部150に入力する。さらに、前記インデックス162は、前記ストリームデータ108のインデックスキーの傾向に基づいて、前記インデックス162のノード分割割合を変更する。これにより、インデックスに必要な領域を最小限とし、かつ高速にストリームデータ108を処理することが可能となるのである。
以下では、前記ストリームデータ処理システム100の構成を詳細に説明する。
コマンド入力部110は、ユーザ101、または計算機102上で実行されるアプリケーションから入力されるコマンドを受け付けるインターフェース(以下、I/F)を備える。前記コマンドが問合せに係るコマンドの場合、コマンド入力部110は問合せ管理部120にコマンド内容を出力する。また、ストリームデータ108の特性情報に係るコマンドの場合、コマンド入力部110は、ストリームデータ特性情報管理部130にコマンド内容を出力する。また、コマンド入力部110は、ストリームデータの監視情報に係るコマンドの場合、ストリームデータ監視情報管理部140にコマンド内容を出力し、インデックスに係るコマンドの場合、インデックス管理部150にコマンド内容を出力する。
問合せ管理部120は、問合せ設定部121、問合せ管理テーブル122から構成される。問合せ設定部121は、前記コマンド入力部110から入力された前記問合せを登録または変更するコマンドを表す問合せ登録・変更コマンドを受け付け、問合せ管理テーブル122を更新する。また、前記問合せコマンドに対応するストリームデータの処理内容を表す実行木174を生成・変更する。なお、問合せ設定部121は、生成した実行木174を問い合わせ実行部170に送信し、格納させる。問合せ管理テーブル122は、前記問合せ設定部121で設定された情報を後述するように保持するテーブルである。
前記ストリームデータ特性情報管理部130は、特性情報設定部131、特性情報管理テーブル132から構成される。
特性情報設定部131は、前記コマンド入力部110から入力された前記ストリームデータの特性情報を設定または変更するコマンドを表す特性情報設定コマンドを受け付け、特性情報管理テーブルを更新する。特性情報管理テーブル132は、前記特性情報設定部131で設定された情報を保持するテーブルである。
ストリームデータ監視情報管理部は、ストリームデータ監視部141、キー傾向予測部142、監視情報管理テーブル143から構成される。
ストリームデータ監視部141は、前記問合せ管理テーブル122を参照し、監視が必要なストリームデータ108を監視する。ストリームデータ監視部141は、監視の結果、前記監視情報を取得した場合、監視情報管理テーブル143を更新する。ここで、監視するストリームデータ108は、必要なものに限定せず、すべてのストリームデータの監視を行ってもよい。キー傾向予測部142は、前記監視情報管理テーブル143を参照し、前記ストリームデータ108の監視情報から、前記インデックスのキー傾向を予測し、監視情報管理テーブル143を更新する。監視情報管理テーブル143は、前記ストリームデータ監視部141において取得した前記監視情報、前記キー傾向予測部142で予測した前記キー傾向を保持するテーブルである。
インデックス管理部150は、インデックス管理テーブル151、インデックス設定部152、分割割合算出部153、インデックス監視情報管理テーブル154、インデックス監視部155、分割多発検知部156、分割履歴参照部157、読み出し順序制御部158から構成される。
インデックス設定部152は、前記コマンド入力部110から入力された前記ノード分割割合を設定または変更するコマンドを表すノード分割割合設定コマンドを受け付け、インデックス管理テーブル151を更新する。また、インデックス設定部152は、インデックス管理テーブル151を参照し、インデックス162のノード分割割合が変更となる場合、インデックス162に対し、分割割合変更命令を出力する。インデックス管理テーブル151は、前記インデックス設定部152で設定された前記インデックス情報を保持するテーブルである。
分割割合算出部153は、前記キー傾向、及び前記インデックス162におけるキーの挿入位置から前記ノード分割割合を後述するように算出する。そのため、前記キー傾向と前記ノード分割割合が1対1に対応せず、前記ノード分割割合が動的に決定される。
インデックス監視部155は、前記問合せ管理テーブル122、及び前記特性情報管理テーブル132を参照し、監視が必要な前記インデックス162を監視する。インデックス監視部155は、監視の結果、前記インデックス監視情報を取得した場合に、インデックス監視情報管理テーブル154を更新する。インデックス監視情報管理テーブル154は、前記インデックス監視部155で取得した前記インデックス監視情報を保持するテーブルであり、後述するように図17のように構成される。なお、インデックス監視部155は所定の周期(例えば、5分)でインデックス162の監視を実行し、監視対象のインデックス162の情報を取得する。監視対象のインデックス162は、問合せ管理テーブル122に参照が設定されたデータ(ストリームデータ108)に対応するインデックス162や、特性情報管理テーブル132に設定されたカラム名カラム502のデータに対応するインデックス162が監視対象となる。
分割多発検知部156は、前記インデックス監視情報管理テーブル154を参照し、ノード分割が多発していないか判定する。ここで、ノード分割の多発とは、インデックス監視情報管理テーブル154のノード分割回数1007が予め設定したしきい値を超えた場合に、分割多発検知部156がノード分割が多発したと判定する。そして、分割多発検知部156はノード分割が多発していると判定した場合、前記インデックス設定部152に、分割割合変更命令を出力する。インデックス設定部152は、分割割合変更命令を受けると、後述する図18のように、記憶装置160のインデックスに対してキー傾向の再予測などの処理を実行する。
分割履歴参照部157は、前記インデックス監視情報管理テーブル154を参照し、時刻情報であるタイムスタンプ1001と、前記ノード分割割合1008とで表される分割履歴情報を用いて、分割多発検知部156がインデックス設定部152へ指令する前記ノード分割割合を決定する。
読み出し順序制御部158は、前記インデックス設定部152が、前記インデックス162の前記キーをページの各アドレスに割り当てる順序が通常か逆順かを表すフラグである読み込み順序フラグを備え、前記読み込み順序フラグに基づいて前記インデックス162の読み書き制御を行う。また、読み出し順序制御部158は、ノード分割が発生した場合に、前記キー傾向に基づいて前記読み込み順序フラグを設定する。なお、ページは、一時保存領域163に格納する一時保存データ164の集合である。
記憶装置160は、インデックス領域161、一時保存領域163から構成される。インデックス領域161は、インデックス162を格納する領域であり、インデックス162は、インデックス1621、1622、・・・、162mから構成される。一時保存領域163は、一時保存データ164を格納する領域であり、一時保存データ164は、一時保存データ1641、1642、・・・、164lから構成される。
ここで、前記一時保存データ164は、一時的に保存している前記ストリームデータ108を表す。また、前記問合せの実行途中結果、または前記問合せの実行結果(別の問合せで実行結果を用いる場合)も一時保存データ164として保存される。使用されなくなった一時保存データ164は、破棄されても、またはディスク装置13等の外部記憶装置に保存されてもよい。
また、前記インデックス162は、前記一時保存データ164を高速に読み出すため用意される。前記インデックス162に対し、問い合わせ実行部170からインデックスキーで検索した場合に、インデックスキーと一致するデータ若しくはデータアドレスが提供される。インデックス処理方法の詳細は前述の非特許文献3に開示されているものが知られている。インデックスには、B木インデックス(B−tree Index)、B+木インデックス(B+−tree Index)、ハッシュインデックス(Hash Index)、T木インデックス(T−tree Index)などがある。上記のインデックスは、非特許文献4に開示されている。
本発明では、B木インデックス、B+木インデックスなどの、インデックスキー挿入時にインデックスのノードにおいて格納可能なキー数上限を上回った場合にノード分割する多分木のインデックスを対象とする。なお、ノードに格納可能なキーの上限数は、予め設定した値である。
問合せ実行部170は、スケジューラ171、一時保存領域管理部172、実行木プール領域173から構成される。実行木プール領域173は実行木174から構成され、実行木174は、複数の実行木1741、1742、・・・、174nから構成される。
実行木174は、ストリームデータ108の内容を表したもので、選択演算、射影演算、結合演算、集計演算等の処理モジュールが木構造になっている。実行木174は、前記問合せ設定部121により生成される。実行木プール領域173は、前記実行木174を格納する領域である。スケジューラ171は、前記実行木174の実行順序を制御する。一時保存領域管理部172は、記憶装置160に格納された前記一時保存データ164の生成、破棄の管理を行う。
ここで、前記一時保存領域163に格納される前記一時保存データ164は、タプル形式(レコード形式)、XML形式、CSVファイル等のいかなるデータ形式でもよい。以下では、タプル形式を用いる例を説明する。
第一の実施形態では、図1において、ストリームデータ監視情報管理部140(ストリームデータ監視部141、キー傾向予測部142、監視情報管理テーブル143)、及びインデックス管理部150中の分割割合算出部153、インデックス監視情報管理テーブル154、インデックス監視部155、分割多発検知部156、分割履歴参照部157、読み出し順序制御部158は用いない。
図3は、ストリームデータ108の好適なデータフォーマットの例を模式的に表した図である。図示の例では、センサノード105が出力したデータを示す。
ストリームデータ108はレコード形式であり、レコードを構成する温度センサIDカラム201、温度カラム202がセグメントに相当し、前記温度センサIDカラム201、及び前記温度カラム202の組み合わせをタプル203とする。前記ストリームデータ108が前記ストリームデータ処理システム100に入力された場合、到着した時間を表すタイムスタンプが付加される。なお、ストリームデータソースにおいて、タイムスタンプを付加してもよい。
図4は、連続してストリームデータ処理システム100へ入力されたストリームデータ108を例示した図であり、温度ストリームデータ(S1)1081を表している。
温度ストリームデータ1081において、表の1行が前記タプル203に対応し、各タプルの到着時間を表すタイムスタンプカラム204が付加されている。例えば、行205は、タイムスタンプカラム204の値が「10:00」、温度センサIDカラム201の値が「101」、温度カラム202の値が「18.0」であるタプルであることを表している。
ここで、本実施形態では、タイムスタンプを「10:00」のような時間、及び分の形式で表しているが、「2006/2/3 9:00:00 JST」のような日付、及び秒を含めた形式に代表される他の形式でもよい。以下の図においても、同様とする。
図5a〜図5cは、コマンド入力部110において、前記ストリームデータ処理システム100に登録・設定する際の好適なコマンドの記述例である。
図5aは、問合せ登録コマンドの記述例である。問合せ登録コマンド301は、前記ユーザ101、または前記クライアント計算機102上で実行される前記アプリケーション103から前記コマンド入力部110を通して、前記問合せ設定部121において登録される。問合せ登録コマンド301は、前記温度ストリーム(S1)1081の過去1時間([Range 1 hour])において、温度センサごとに(GROUP BY 温度センサID)最大値(Max(温度))、及び最小値(Min(温度))を計算し、最大値と最小値の差が5よりも大きい(HAVING Max(温度)−Min(温度)>5)ものに関して、温度センサID、最大値、最小値をストリーム化して(ISTREAM)、出力する処理を表す問合せであることを表している。
図5bは、ノード分割割合設定コマンドの記述例である。ノード分割割合設定コマンド302は、前記ユーザ101、または前記クライアント計算機102上で実行される前記アプリケーション103から前記コマンド入力部110を通して、前記インデックス設定部152において登録される。ノード分割割合設定コマンド302は、ストリーム名が「S1」、カラム名が「温度」であるストリームデータに対し、インデックス名が「インデックス1」であるインデックスを作成(変更)し、「−splitratio」オプションでノード分割割合を設定している。具体的には、インデックスのキー値の増加傾向時にはノード分割割合を「5:2」に設定し(increase 5:2)、減少傾向時にはノード分割割合を「2:5」に設定し(decrease 2:5)、ランダム傾向時にはノード分割割合を「1:1」に設定する(random 1:1)処理であることを表している。
図5cは、ストリームデータ特性情報設定コマンドの記述例である。ストリームデータ特性情報設定コマンド303は、前記ユーザ101、または前記クライアント計算機102上で実行される前記アプリケーション103から前記コマンド入力部110を通して、特性情報設定部131において登録される。ストリームデータ特性情報設定コマンド303は、ストリーム名が「S1」であるストリームデータにおいて、カラム名が「温度」であるカラムに対し、増加傾向となるのが6:00から13:00(increase 6:00<=timestamp<13:00)、減少傾向となるのが0:00から3:00と16:00から0:00(decrease 0:00<=timestamp<3:00 AND 16:00<=timestamp<0:00)、ランダム傾向となるのが3:00から6:00と13:00から16:00(random 3:00<=timestamp<6:00 AND 13:00<=timestamp<16:00)であることを表している。
ここで、本実施形態では、コマンドをコマンドラインインターフェース(CLI)形式で登録した例を表したが、これに限定されるものではない。例えば、グラフィックユーザーインターフェース(GUI)を用いて上記と同様の意味の入力をしてもよい。
図6は、問合せ管理テーブル122の構成例を表した図である。
問合せ名カラム401、問合せカラム402には、それぞれ、前記コマンド入力部110において登録された問合せの名前、及び登録された問合せを格納する。
問合せ実行形式格納先カラム403には、問合せの実行形式の格納先のアドレス(ポインタ)を格納する。実行形式を予め作成しておくことにより、クエリの実行のたびにコンパイルを行うオーバーヘッドを削減できる。このアドレスは、例えばメモリ12上の格納位置を指し示す。
登録者名カラム404、登録日時カラム405にはそれぞれ、問合せ登録時に取得した問合せの登録者名、問合せの登録日時が格納され、システムのアクセス管理、セキュリティ管理に使用される。
例えば、行406は、図5に示した問合せ登録コマンド301を登録した場合の登録問合せ管理テーブル122を表している。
行406は、問合せ名カラム401の値が「Q1」、問合せカラム402の値が「SELECT 温度センサID,Min(温度),Max(温度) FROM S1[RANGE 1 HOUR] GROUP BY 温度センサID HAVING MAX(温度)− MIN(温度)>5」、問合せ実行形式格納先カラム403の値が「0x7FFFAEE1」、登録者名カラム404の値が「樫山」、登録日時カラム405の値が「2006/08/01 13:07:26 JST」であることを表している。
ここで、問合せを入力するI/Fは、図5aに示したコマンド形式、図6に示した表形式の他に、設定ファイルによる入力、XMLファイルによる入力など任意の形式でよい。以下のテーブルにおいても、同様とする。
図7は、特性情報管理テーブル132の構成例を表した図である。
ストリームデータ名カラム501には、特性情報を入力するストリームデータの名前を格納する。カラム名カラム502には、ストリームデータにおける前記特性情報を入力するカラムのカラム名を格納する。前記カラム名カラム502に前記インデックス162のキーを入力することにより、前記キー傾向を取得することができる。
タイムスタンプ範囲カラム503、傾向カラム504にはそれぞれ、時刻情報に関する範囲指定、及び前記時刻情報に対応する傾向を格納する。ここで、タイムスタンプ範囲カラム503には、値が入力されなくともよい。
例えば、行505は、「S1」というストリーム名を有するストリームデータにおいて、「温度」カラムは、「6:00から13:00」に「増加傾向」となることを表している。図5cに示したストリームデータ特性情報設定コマンド300を入力すると、行505、行506、行507が生成される。
ここで、傾向カラム504に入力される値としては、該挿入されるインデックスのキー系列が単調増加、若しくは単調増加ではないが、全体的に増加していることを表す「増加傾向」と、該挿入されるキー系列が単調減少、若しくは単調減少ではないが、全体的に減少していることを表す「減少傾向」と、該挿入されるキー系列に特徴がなく、ランダムな値であることを表す「ランダム傾向」と、該挿入されるキー系列が単調増加であることを表す「単調増加傾向」と、該挿入されるキー系列が単調減少であることを表す「単調減少傾向」と、該挿入されるキー系列が最大値若しくは最小値に向かって両側に広がっていくことを表す「発散傾向」と、該挿入されるキー系列がある値に向かって集まっていくことを表す「収束傾向」などが挙げられるが、上記以外の傾向でもよい。また、行508に示すように、複数の傾向が入力され、傾向が切り替わることを表してもよい。
また、特性を入力するストリームデータ名カラム501、及びカラム名カラム502は、前記問合せ管理テーブル122を参照し、取得してもよい。また、タイムスタンプ範囲カラム503に格納する情報はすべての情報が入力される必要はない。
図8は、インデックス管理テーブル151の構成例を表した図である。
インデックス設定部152は、インデックス管理テーブル151のインデックス名カラム701、ストリームデータ名カラム702、カラム名カラム703には、それぞれ、インデックスの名前701、ストリームデータの名前702、カラムの名前703を格納する。
キー傾向カラム704には、インデックスのキー傾向を格納する。ノード種別カラム705、分割割合カラム706には、それぞれ、ノード種別、及び対応するノード分割割合を格納する。
ここで、ストリームデータ処理システム100ではインデックス管理テーブル151を基に、インデックス162に対して分割割合変更命令を出力する。また、ノード種別カラム705に格納する情報はすべての情報が入力される必要はない。
また、ランダム傾向に対する前記ノード分割割合は、システムで予め定めた既定値は任意の値でよい。例えば、1:1(半々に分割)でよい。
例えば、行707は、インデックス名が「インデックス1」、ストリームデータ名が「S1」、カラム名が「温度」であるインデックスに対し、「増加傾向」時には、ノード種別に関係なく、ノード分割割合を「5:2」にすることを表している。
また、行708は、「減少傾向」時には、ノード種別に関係なく、ノード分割割合を「2:5」にすることを表しており、行709は、「ランダム傾向」時には、ノード種別に関係なく、ノード分割割合を「1:1」(キー格納上限数が6の場合には、「3:4」)にすることを表している。
また、行710、若しくは行711に示すように、リーフノードと索引ノードとで、ノード分割割合を変更してもよい。
また、行712、若しくは行713に示すように、前記分割割合カラム706の値に、前記インデックスにキーが挿入されるリーフノードの位置を表すリーフノード位置に対応したノード分割割合を保持してもよい。例えば、行712は、リーフノード位置が「左」側の場合に、ノード分割割合を「2:5」にし、リーフノード位置が「中」側(真ん中付近)の場合に、ノード分割割合を「1:1」にし、リーフノード位置が「右」側の場合に、ノード分割割合を「5:2」にすることを表している。詳細は後述する(図23に示すインデックス管理テーブル151を用いる)。
図9は、インデックス管理部150が前記インデックス162において、キー挿入時に実行するインデックス処理を表したフローチャートである。
キー挿入時のインデックス処理では、まず、非特許文献3に開示されているB木インデックスと同様に、キーが挿入されるリーフノード位置及びリーフノード内における挿入位置を特定し、キーを挿入する(S2002)。次に、キーを挿入するノードが格納可能なキー格納上限数を上回り、ノード分割が発生するか否かを判定する(S2003)。なお、キー格納上限数は予め定めた値である。
前記ステップS2003でNOと判定された場合は、処理を終了する(S2011)。前記ステップS2003でYESと判定された場合は、新規ノードを生成する(S2004)。
次に、インデックス管理部150は特性情報管理テーブル132を参照し(S2005)、現在のタイムスタンプに対応するキー傾向カラム504の値を取得する(S2006)。
次に、インデックス管理テーブル151を参照し(S2007)、前記取得したキー傾向に対応する分割割合カラム706の値を取得する(S2008)。
次に、前記取得した分割割合に基づいて新規ノードにキーを移動し(S2009)、上位ノードの参照を変更し(S2010)、処理を終了する(S2011)。
ここで、キーが前記ノード分割割合で整数値に配分できない場合に、ノード分割割合と最も近い割合でキー配分を行う。
また、キー削除時のインデックス処理では、非特許文献3に開示されているB木インデックスと同様に行える。また、ノードが空になるまで、キーを削除し続け、ノードが空になった段階で空きノード回収する方法でもよい。
図10a〜図10dは、インデックスのノード分割の例を表した図である。上記図9のフローチャートを参照しながら以下に説明する。
図10aから図10dは、リーフノードのキー格納上限数が6、索引ノードのキー格納上限数が4であるインデックス162の例を表している。
図10aは、ランダム傾向時のインデックス162のノード分割の例を表した図である。キーの値が「12」であるキーを挿入した場合、前記ステップS2002が実行される。前記ステップS2003では、キー格納数が1であり、キー格納上限数を上回らないため、ノード分割発生の判定はNOと判定され、処理を終了する。
次に、「18、15、21、13、19」の順にキーを挿入すると上記と同様に処理され、インデックス801となる。
次に、キーの値が「16」であるキーを挿入した場合、前記ステップS2003において、キー格納数が7となり、キー格納上限数を上回るため、ノード分割発生の判定はYESと判定される。そこで、前記ステップS2004で、新規ノードを生成する。前記ステップS2005におけるランダム傾向の判定はYESが判定され、前記ステップS2006で、ランダム傾向時のノード分割割合「1:1(半分に分けられないため3:4とする)」でノード分割する。前記ステップS2010で、新規ノードに4個のキー(「16〜21」)を移動し、前記ステップS2011で、上位ノードの参照を変更する。図10aでは、上位ノードが存在しないため、上位ノードを新たに生成している。上位ノード生成方法は非特許文献3に開示されているB木インデックスの処理方法と同様である。上記処理を行った結果のインデックスはインデックス802となり、処理を終了する。
インデックスのキーの値がランダムに変化する場合では、ノード分割時に値の小さいノードと値の大きいノードに格納するキーの数をほぼ等しく(1:1〜3:4)とすることで、次のキーの値が増大、減少しても分割したノードに格納することができる。これにより、キーの値がランダムに変化する場合に、キーを格納するノードの分割が頻発するのを防ぐことができる。
図10bは、キーの値が増加傾向時のノード分割の例を表した図である。
「11、13、14、17、15、18」の順にキーを挿入した場合、インデックス803となる。次に、キーの値が「22」であるキーをインデックス803に挿入した場合、前記ステップS2003におけるノード分割発生の判定はYESと判定される。次に、前記ステップS2007における増加傾向の判定はYESと判定され、前記ステップS2008で、増加傾向時のノード分割割合「5:2」でノード分割する。ノード分割後の処理は図10aと同様である。上記処理を行ったインデックスはインデックス804となり、処理を終了する。
インデックスのキーの値が増加傾向で変化する場合では、ノード分割時に値の小さいノードへ格納するキーの数を、値の大きいノードよりも大きく(5:2等)とすることで、次のキーの値が増大しても分割したノードに格納することができる。これにより、キーの値が増加傾向で変化する場合に、キーを格納するノードの分割が頻発するのを防ぐことができる。
図10cは、減少傾向時のノード分割の例を表した図である。
「22、18、15、17、14、13」の順にキーを挿入した場合、インデックス805となる。次に、キーの値が「11」であるキーをインデックス804に挿入した場合、前記ステップS2003におけるノード分割発生の判定はYESと判定される。次に、前記ステップS2007における増加傾向の判定はNOと判定され、前記ステップS2009で、減少傾向時のノード分割割合「2:5」でノード分割する。ノード分割後の処理は図10aと同様である。上記処理を行ったインデックスはインデックス806となり、処理を終了する。
インデックスのキーの値が減少傾向で変化する場合では、ノード分割時に値の小さいノードへ格納するキーの数を、値の大きいノードよりも少なく(2:5等)とすることで、次のキーの値が減少しても分割したノードに格納することができる。これにより、キーの値が減少傾向で変化する場合に、キーを格納するノードの分割が頻発するのを防ぐことができる。
図10dは、前記特許文献2に開示されているキー挿入位置でノード分割する例を表した図である。
図10bと同じ「11、13、14、17、15、18」の順にキーを挿入した場合、インデックス807となる。次に、キーの値が「22」であるキーをインデックス807に挿入した場合に、挿入位置(左端)でノード分割をするため、キーは「11、13、14、17、15、18」と「22」にノード分割され、インデックス808となる。ここで、ゆらぎを含むデータ、例えば、キーの値が「21」であるキーを挿入した場合に、図中左側のリーフノードで再びノード分割が発生し、「11、13、14、17、15、18」と「21」にノード分割され、インデックス809となる。インデックス809は、リーフノード数が3個となり、インデックス容量が増加してしまう。このように、従来例ではノード分割が頻発して、インデックスを格納するための記憶領域(インデックス領域161)が肥大することになる。
一方、図10bに示した増加傾向時のインデックス804に対し、キーの値が「21」であるキーを挿入した場合に、右側のリーフノードに入るために、ノード分割は発生せず、リーフノード数は2個のままとなるため、インデックス容量は増加しない。
ここで、図10aから図10cではリーフノード分割の例を表したが、索引ノードの分割も同様にできる。
図11は、問い合わせ実行部170の実行木174の一例を表した説明図である。
実行木174は、処理を行うオペレータ、及びオペレータ間をつなぐキュー1210から構成される。本説明図では、左端が入力で右端が出力となっている。入力データとして、ストリームデータ108を入力する。また、問合せの出力結果180をストリームデータ108として再入力することも可能である。
オペレータは、処理内容によって種類が異なる。ウィンドウオペレータ1211は、前記ストリームデータ108からデータ列の数を指定し、または、切り取るデータ列の時間間隔を指定してデータ列を切り取り、ストリームデータをタプル集合へと変換する処理を行う。射影オペレータ1212は、前記タプル203のカラムの一部のみを出力する処理を行う。選択オペレータ1213は、設定された条件に基づいてタプル203を出力するか否かを決定する処理を行う。結合オペレータ1214は、2入力以上のストリームデータ108をある条件のもとに結合する処理を行う。集計オペレータ1215は、合計、平均、最大、最小などの集計処理を行う。ストリーム化オペレータ1216は、タプル集合をストリームデータ108へと変換する処理を行う。
実行木174は、ストリームデータ1081、及びストリームデータ1082を入力とし、ストリームデータ1081は、ウィンドウオペレータ1211で処理され、射影オペレータ1212に入力される。一方、ストリームデータ1082は、ウィンドウオペレータ1211で処理され、選択オペレータ1213に入力される。射影オペレータ1212の出力、及び選択オペレータ1213の出力が結合オペレータ1214に入力され、集計オペレータ1215で処理され、最後に、ストリーム化オペレータ1216で処理され、出力結果180として出力する例を表している。
図12は、問い合わせ実行部170が出力する出力結果180を例示した図であり、図4に示した温度ストリームデータ(S1)1081に対して、図5aに示した問合せ登録コマンド301を実行した場合の、出力結果を表している。
タイムスタンプカラム1301、温度センサIDカラム1302は、それぞれ、図4に示したタイムスタンプカラム204、温度センサIDカラム201に対応付けられる。また、Min(温度)カラム1303、Max(温度)カラム1304は、それぞれ、ストリームデータ108のうちの温度の最小値、最大値が出力される。
例えば、行1305は、タイムスタンプ「10:00」において、温度センサIDが「101」の温度センサが、最小値「12.5」、最大値「18.0」となったことを表している。
以上において、インデックス管理部150でインデックス162のノード分割割合を指定することにより、ノード分割が頻発するのを抑制できるので、本発明の第1の目的である、キーの値が完全な単調増加、または完全な単調減少とならないゆらぎを含むデータに対し、インデックス容量が小さく、高速処理が可能なインデックスを提供することが可能であることを示した。また、ノード分割割合を切り替えることにより、本発明の第2の目的である、増加傾向、減少傾向が入れ替わるデータに対し、インデックス容量が小さく、高速処理が可能なインデックスを提供することが可能であることを示した。
以上、本発明の第一の実施形態について説明した。
本発明は、上記に示した第一の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。以下では、第一の実施形態とは異なる実施形態により、同様、または更なる効果を得ることが可能である、若しくは第一の実施形態と組み合わせることにより更なる効果を得ることが可能であることを説明する。
なお、上記実施形態においてセンサノードの測定値から変換したユーザが理解可能な有意な情報は、センサノードが出力したバイナリ値を所定の単位系の数値に変換した情報としたが、これに限定されるものではない。例えば、センサノードの値の時系列の集計値、および複数のセンサノードの値の集計値を有意な情報としてもよい。あるいは、センサノードが1分間隔に温度情報を送信した場合に、ユーザは最近1時間の温度平均が知りたい(時系列の集計)場合では、直近の1時間の温度平均が有意な情報となる。また、複数のセンサノードの集計値の例では、同じ部屋にある複数のセンサノードの中で最も温度の高いものを有意な情報としてもよい。
<第2実施形態>
以下では、本発明の第二の実施形態について説明する。
前記第一の実施形態では、ユーザ101、または計算機102上で実行されるアプリケーション103が指定したストリームデータ108の特性情報により、キー傾向を与えたが、第二の実施形態では、ストリームデータ108の監視情報を用いることにより、キー傾向を予測することを特徴とする。キー傾向を予測する処理以外は、第一の実施形態と同様に処理を行える。
第二の実施形態では、図1において、ストリームデータ監視情報管理部140では、ストリームデータ監視部141がストリームデータ108の監視を行い、キー傾向予測部142が、監視情報管理テーブル143に保持されている取得した監視情報からキー傾向を予測する。
第二の実施形態では、図1において、インデックス管理部150中の分割割合算出部153、インデックス監視情報管理テーブル154、インデックス監視部155、分割多発検知部156、分割履歴参照部157、読み出し順序制御部158は用いない。
図13は、ストリームデータ監視情報管理部140の監視情報管理テーブル143の構成例を表した図である。
タイムスタンプカラム601には、前記第1実施形態のストリームデータ監視部141において入力されたストリームデータ108の監視情報を取得した時刻情報を格納する。
ストリームデータ名カラム602、カラム名カラム603にはそれぞれ、前記第1実施形態に示した問合せ管理テーブル122を参照し、取得した監視対象のストリームデータ名カラム602、及び監視対象のカラム名603を格納する。キー傾向予測部142は、監視情報管理テーブル143の前記カラム名カラム603に前記インデックス162のキーを入力することにより、前記キー傾向を予測することができる。
属性値カラム604には、前記ストリームデータ監視部141において取得した監視情報のうち、前記カラム名カラム603に対応する属性値を格納する。属性値カラム604はすべての情報が入力される必要はなく、監視情報管理テーブル143に格納する情報は、属性値カラム604に情報が入力されている場合には、属性値カラム604に対応する監視情報を入力し、属性値カラム604に情報が入力されていない場合には、カラム名カラム603に対応する監視情報を入力する。
データレートカラム605には、前記ストリームデータ監視部141において取得した監視情報のうち、監視対象のストリームデータ108の到着レートを格納する。データレートを取得することにより、ストリームデータ処理システム100に今後到着するストリームデータ108のデータ量を予測できる。
統計値カラム606には、前記ストリームデータ監視部141において取得した監視情報のうち、前回監視情報を取得した時点からの統計値を格納する。
現在の値カラム607には、前記ストリームデータ監視部141において取得した監視情報のうち、最新の値を格納する。
増加カウンタカラム608、減少カウンタカラム609には、それぞれ、前記ストリームデータ監視部141において取得した監視情報のうち、1個前のタプルと比較して増加したか否かをカウントし、増加した回数、減少した回数を格納する。増加カウンタカラム608、減少カウンタカラム609には、前回監視情報を取得した時点からのカウント回数を格納する。
傾向予測カラム610は、後述する傾向予測部142で予測したキー傾向を格納する。このキー傾向の予測値を用いて、インデックス162のノード分割割合を決定する。
例えば、行611は、タイムスタンプカラム601の値が「10:00」であり、ストリームデータ名カラム602の値が「S1」であり、カラム名カラム603の値が「温度」であり、属性値カラム604の値が「温度センサID=101」であり、データレートカラム605の値が「30タプル/分」であり、統計値カラム606の値が「平均値=17.5℃」であり、現在の値カラム607の値が「18.0」であり、増加カウンタカラム608の値が「50」であり、減少カウンタカラム609の値が「4」であり、傾向予測カラム610の値が「増加傾向」であることを表している。
図中監視情報管理テーブル143の行612は、属性値カラム604の値が「温度センサID=102」に対応する監視情報であることを表している。また、行613は、「10:05」にストリームデータ監視部141が取得した監視情報であることを示し、行614は、「10:10」に取得した監視情報であることを表している。
ここで、本第2実施形態では、監視情報を5分間隔で取得する例を表したが、これに限定されるものではない。また、ストリームデータ108ごとに監視情報取得間隔を変更してもよい。 また、監視情報を監視情報管理テーブル143では新たなデータを追記しているが、不要となった行を監視情報管理テーブル143から削除してもよい。
また、データレートカラム605に格納するデータとして、タプル/分の例を表したが、これに限定されるものではない。統計値カラム606に格納するデータは、前回監視情報を取得した時点からの統計情報としたが、それ以前から取得している統計情報でも構わない。また、増加カウンタカラム608、減少カウンタカラム609に格納するデータは、前回監視情報を取得した時点からの回数としたが、それ以前から取得している回数でも構わない。また、統計値606として、中心値、及び平均値を示したが、分散などの他の統計情報でもよい。さらに、後述するストリームデータの特性情報の一部を、前記ストリームデータ108を監視することにより取得してもよい。
また、属性値カラム604、データレートカラム605、統計値カラム606、現在の値カラム607、増加カウンタカラム608、減少カウンタカラム609、傾向予測カラム610に格納する監視情報取得データはすべての情報が入力される必要はなく、監視項目はどのような方法で設定されてもよい。例えば、前記コマンド入力部110で設定する、設定ファイルに書き込んでおく、システムが既定値を定めておき、設定がなかった場合に、既定値を用いる、などで構わない。
図14は、キー傾向予測部142で実行されるキー傾向の予測処理を表したフローチャートである。この処理は所定の周期で実行されるものである。
キー傾向予測処理では、まず、キー傾向予測部142が前記特性情報管理テーブル132を参照し(S2102)、現在のタイムスタンプにおける傾向が記述されているか否かを判定する(S2103)。具体的には、図7に示した特性情報管理テーブル132のタイムスタンプ範囲カラム503の値、傾向カラム504の値を参照し、該当するものがあるか否かを判定する。
前記ステップS2103でYESと判定された場合、前記特性情報管理テーブル132に記述されているキー傾向に設定し(S2104)、処理を終了する(S2112)。前記ステップS2103でNOと判定された場合、前記監視情報管理テーブル143を参照し(S2105)、増加カウンタ、減少カウンタの値を取得する(S2106)。具体的には、図13に示した増加カウンタカラム608、減少カウンタ609の値を取得する。
次に、増加カウンタの値が減少カウンタの値よりも大きいか否か、具体的には、増加カウンタ、減少カウンタの比が予め設定された増加カウンタ閾値を超えているか否か、すなわち、「増加カウンタ/減少カウンタ>増加カウンタ閾値」を満たすか否かを判定する(S2107)。
前記ステップS2107でYESと判定された場合、キー傾向を増加傾向に設定する(S2108)。前記ステップS2107でNOと判定された場合、減少カウンタの値が増加カウンタの値よりも大きいか否か、具体的には、減少カウンタ、増加カウンタの比が予め設定された減少カウンタ閾値を超えているか否か、すなわち、「減少カウンタ/増加カウンタ>減少カウンタ閾値」を満たすか否かを判定する(S2109)。
前記ステップS2109でYESと判定された場合、キー傾向を減少傾向に設定し(S2111)、処理を終了する(S2112)。前記ステップS2109でNOと判定された場合、キー傾向をランダム傾向に設定し(S2110)、処理を終了する(S2112)。
ここで、図14では、監視情報からキー傾向を予測するため、増加カウンタ、減少カウンタを用いたが、監視情報を用いた任意の方法で決定してよい。例えば、図13に示した前記監視情報管理テーブル143における現在の値カラム607を用いて、10:00、10:05、10:10における現在の値を取得し、増加し続けている場合、増加傾向に設定し、減少し続けている場合、減少傾向に設定し、それ以外の場合をランダム傾向に設定してもよい。処理の詳細は後述する(図24に示すキー傾向予測処理のフローチャートを用いる)。
ここで、図14では、特性情報管理テーブル132を参照したが、特性情報管理テーブル132を参照せず、監視情報のみでキー傾向を決定してもよい。すなわち、前記ステップS2103、及び前記ステップS2104は必ずしも必要でない。また、上記では、特性情報を優先してノード分割したが、監視情報から算出した傾向を優先してノード分割してもよい。または、特性情報、及び監視情報から算出した傾向を比較し、どちらも一致することを確認してもよい。
また、前記増加カウンタ閾値及び減少カウンタ閾値は、どのような方法で設定されてもよい。例えば、前記コマンド入力部110で設定する、設定ファイルに書き込んでおく、システムが既定値を定めておき、設定がなかった場合に、既定値を用いる、などで構わない。また、増加カウンタ閾値と減少カウンタの閾値は同じ値を用いてもよい。
以上、本発明の第二の実施形態について説明した。
<第3実施形態>
以下では、本発明の第三の実施形態について説明する。
前記第一、第二の実施形態では、ノード分割割合をユーザ、または計算機上で実行されるアプリケーションにより指定したが、第三の実施形態では、キーが挿入される位置を特定した後に、キー傾向からノード分割割合を算出し、ノード分割することを特徴とする。
すなわち、キー傾向とノード分割割合が1対1に対応せず、キーが挿入される位置によりノード分割割合が変更することを特徴とする。
ここで、前記特許文献2に開示されているインデックス処理方法では、キーが挿入される位置でノード分割を行うが、本発明の第三の実施形態では、キーが挿入される位置と異なる位置でノード分割される(キーが挿入される位置と同じになることもある)。
ノード分割割合を決定する処理以外は、前記第一、及び第二の実施形態と同様に処理を行える。キー傾向を決定する処理は、第一の実施形態(ユーザ101、または計算機102上で実行されるアプリケーション103が指定)、第二の実施形態(監視情報から予測)の何れでも構わない。
第三の実施形態では、図1において、インデックス管理部150の分割割合算出部153が、ストリームデータ特性情報管理部130の特性情報管理テーブル132、または監視情報管理テーブル143を参照し、キー傾向を取得し、インデックス162からキーの挿入位置を取得し、ノード分割割合を計算する。
第三の実施形態では、図1において、ストリームデータ特性情報管理部130(特性情報設定部131、特性情報管理テーブル132)、またはストリームデータ監視情報管理部(ストリームデータ監視部141、キー傾向予測部142、監視情報管理テーブル143)の少なくとも一方を用いるものとする。また、インデックス管理部150中のインデックス監視情報管理テーブル154、インデックス監視部155、分割多発検知部156、分割履歴参照部157、読み出し順序制御部158は用いない。
第三の実施形態では、挿入位置と傾向から分割割合算出部153がノード分割割合を動的に決定する。キー傾向または増加傾向の場合、挿入位置から右側のキーを半分ずつ分かれるようにノード分割する。すなわち、リーフノードのキー格納上限数をnleaf、挿入位置をiとした場合、
の割合でノード分割する。一方、減少傾向の場合には、
の割合でノード分割する。
また、索引ノードの場合には、親ノードに1個のキーが移動することを考慮し、リーフノードと同様にノード分割する。すなわち、索引ノードのキー格納上限数をnindex、挿入位置をiとした場合、
の割合でノード分割する。一方、減少傾向の場合には、
の割合でノード分割する。
ここで、上記数1〜図4に示したノード分割割合算出式は、一例であって、上記以外のどのような算出式であってもよい。例えば、ノード分割元側に少しあきが多くなるようにノード分割割合を決定してもよい。この場合、マージンの割合をパラメータとして入力させる。
図15は、分割割合算出処理のフローチャートを表している。分割割合算出処理は、図9に示した前記ステップS2002、前記ステップS2003を実行し、ノード分割が発生した場合の処理を表している。
分割割合算出処理では、まず、キー傾向(またはキー傾向予測値)がランダム傾向か否かを判定する(S2202)。この処理では、特性情報管理テーブル132の傾向504や監視情報管理テーブル143の傾向予測カラム610を参照することで判定を行う。
前記ステップS2202でYESと判定された場合、ノード分割割合をシステムが予め定めた既定値とし(S2203)、処理を終了する(S2211)。前記ステップS2202でNOと判定された場合、ノード分割するノードがリーフノードか索引ノードかを判定する(S2204)。
前記ステップS2204でリーフノードと判定された場合、キー傾向が増加傾向か減少傾向か判定する(S2205)。
前記ステップS2205で増加傾向と判定された場合、
の割合でノード分割し(S2207)、処理を終了する(S2211)。前記ステップS2205で減少傾向と判定された場合、
の割合でノード分割し(S2208)、処理を終了する(S2211)。
一方、前記ステップS2204で索引ノードと判定された場合、キー傾向が増加傾向か減少傾向か判定する(S2206)。
前記ステップS2206で増加傾向と判定された場合、
の割合でノード分割し(S2207)、処理を終了する(S2211)。前記ステップS2206で減少傾向と判定された場合、
の割合でノード分割し(S2208)、処理を終了する(S2211)。
ここで、システムで予め定めた既定値は任意の値でよい。例えば、1:1(半々に分割)でよい。
図16a〜図16dは、キー傾向、及びキーの挿入位置からノード分割割合を算出し、ノード分割する例と前記従来例及び第1,第2実施形態との比較を表した図である。
図16aは、本第3実施形態でキー傾向が減少傾向であり、キーが「23、21、19、17、15、13、11、9、7、5、3、1」の順に挿入されたときのインデックスを表している。「15」のキーが挿入された時点、及び「17」のキーが挿入された時点でリーフノードのノード分割が起こり、インデックス901となる。つまり、ノード分割の回数と、ノード数の増大を抑制することができるので、増加傾向、減少傾向が入れ替わるデータに対し、インデックス容量が小さく、高速処理が可能なインデックスを提供することが可能となる。
図16bは、前記特許文献2に開示されている挿入位置でノード分割するインデックス処理方法において、キーが「2、4、6、8」の順に挿入されたときのインデックス(リーフノードのみ)902を表している。インデックス902に示すように、「2」のキーが挿入された時点で1:4のノード分割が起こり、「4」のキーが挿入された時点で2:3のノード分割が起こり、「8」のキーが挿入された時点で4:1のノード分割が起こる。その結果、「1、3、5、7」の1リーフノードが、「1」、「2、3」、「4、5、6、7」、「8」の4リーフノードとなり、ノード数が多くなる。さらに、同様に、「10、12、14、16」の順にキーを挿入した場合、「9、11、13、15」の1リーフノードが4リーフノードとなる。このように、前記従来例ではノード分割が頻発することになる。
図16cは、本発明の第一、または第二の実施形態で示した傾向に対するノード分割割合をユーザ、または計算機102上で実行されるアプリケーション103が指定するインデックス処理方法において、減少傾向から増加傾向に切り替わり、キーが「2、4、6、8」の順に挿入されたときのインデックス(リーフノードのみ)を表している。図16cに示す例では、増加傾向時のノード分割割合を4:1としている。インデックス903に示すように、「2」のキーが挿入された時点で4:1のノード分割が起こり、「4」のキーが挿入された時点で4:1のノード分割が起こる。その結果、「1、3、5、7」の1リーフノードが、「1、2、3、4」、「5、6」、「7、8」の3リーフノードとなり、図16bに示した前記従来例のインデックスよりはノード分割回数が少なくなるものの、ノード数が多くなる。さらに、同様に、「10、12、14、16」の順にキーを挿入した場合、「9、11、13、15」の1リーフノードが3リーフノードとなる。
図16dは、本第3実施形態であるキー傾向、及びキーの挿入位置からノード分割割合を算出し、ノード分割するインデックス処理方法を適用した例を示す。キー傾向が減少傾向から増加傾向に切り替わり、キーが「2、4、6、8」の順に挿入されたときのインデックス(リーフノードのみ)を表している。インデックス904に示すように、「2」のキーが挿入された時点でノード分割が起こる。
図15に示したフローチャートにおいて、ステップS2202ではキー傾向が増加傾向のため、NOと判定され、ステップS2204ではリーフノードと判定され、ステップS2205では増加傾向と判定されるため、ステップS2207が実行される。
キー格納上限数nleaf=4、キー挿入位置i=2となるので、
でノード分割する。その結果、「1、3、5、7」の1リーフノードが、「1、2、3、4」、「5、6、7、8」の2リーフノードとなり、図16b、図16cに示したインデックスよりも少ないノード数となる。さらに、同様に、「10、12、14、16」の順にキーを挿入した場合、「9、11、13、15」の1リーフノードが2リーフノードとなる。
ここで、図15に示したフローチャートに従い、減少傾向時のノード分割処理を行った場合、「15」のキーが挿入された時点で、
のノード分割が起こる。同様に、「7」のキーが挿入された時点で1:4のノード分割が起こるため、インデックス901と同様となる。
このように、キーの挿入位置とキーの値の傾向に応じてノード分割割合を決定することで、揺らぎのあるインデックスのキーであってもノードの分割が頻発するのを抑制できる。特に、増加傾向の場合では、値の小さなノードにもキーを格納可能としておくことで、一時的にキーの値が減少してもノードの分割が頻発するのを抑制できる。
以上、本発明の第三の実施形態について説明した。
<第4実施形態>
以下では、本発明の第四の実施形態について説明する。
第一、第二の実施形態では、ノード分割割合をユーザ101、または計算機102上で実行されるアプリケーション103により指定し、第三の実施形態では、キーが挿入される位置を特定した後に、キー傾向からノード分割割合を算出した。しかしながら、何れの実施形態も指定したノード分割割合が正しいか判断する手段を備えていなかった。そこで、第四の実施形態では、インデックスを監視し、インデックスの監視情報(統計情報など)を取得することで、ノード分割が多発していることを検知し、ノード分割割合を変更する、あるいは、キー傾向を算出しなおす、等の処理を行うことを特徴とする。
ノード分割多発を検知する処理、及びノード分割多発時の処理を追加する以外は、第一から第三の実施形態と同様に処理を行える。
第四の実施形態では、図1において、インデックス監視部155が、インデックス162の監視を行い、分割多発検知部156が、インデックス監視情報管理テーブル154に保持されている取得した監視情報を基にノード分割が多発していることを検知する。また、ノード分割が多発している場合、分割多発検知部156が、インデックス設定部152に対し、ノード分割割合変更を指示したり、キー傾向予測部142にキー傾向の再予測を指示することができる。
第四の実施形態では、図1において、ストリームデータ特性情報管理部130(特性情報設定部131、特性情報管理テーブル132)、またはストリームデータ監視情報管理部(ストリームデータ監視部141、キー傾向予測部142、監視情報管理テーブル143)の何れかは必ずしも必要としない。また、インデックス管理部150中の分割履歴参照部157、読み出し順序制御部158は用いない。
図17は、インデックス管理部150のインデックス監視情報管理テーブル154の構成例を表した図である。
タイムスタンプカラム1001には、インデックス監視部155において記憶装置160に格納されたインデックス162の監視情報を取得した時刻情報を格納する。
インデックス名カラム1002、ストリームデータ名カラム1003、カラム名カラム1004にはそれぞれ、図8に示したインデックス管理テーブル151を参照し、取得した監視対象のインデックス名、監視対象のストリームデータ名、監視対象のカラム名を格納する。
属性値カラム1005には、前記インデックス監視部155において取得した監視情報のうち、前記カラム名カラム1004に対応する属性値を格納する。属性値カラム1005はすべての情報が入力される必要はなく、インデックス監視情報管理テーブル154の以下に格納する情報は、属性値カラム1005に情報が入力されている場合には、属性値カラム1005に対応する監視情報を入力し、属性値カラム1005に情報が入力されていない場合には、カラム名カラム1004に対応する監視情報を入力する。
充填率カラム1006には、前記インデックス監視部155において取得した監視情報のうち、監視対象のインデックスの充填率を格納する。充填率とは、インデックス全体のキー格納数に対して、現在使用されているキーがどのくらいあるかを表す割合である。充填率が100%の場合、すべてのキーが使用されている。
ノード分割回数カラム1007には、前記インデックス監視部155において取得した監視情報のうち、監視対象のインデックスのノード分割回数を格納する。図17では、前回の監視情報取得からのノード分割回数を格納しているが、ノード分割回数の累計を格納してもよい。
ノード分割割合カラム1008には、前記インデックス監視部155において取得した監視情報のうち、監視対象のインデックスのノード分割割合を格納する。図17では、監視情報を追記していくため、過去の分割履歴を取得することもできる。
例えば、行1009は、タイムスタンプカラム1001の値が「2006/08/01 10:00:00 JST」であり、インデックス名カラム1002の値が「インデックス1」であり、ストリームデータ名カラム1003の値が「S1」であり、カラム名カラム1004の値が「温度」であり、属性値カラム1005の値が「温度センサID=101」であり、充填率カラム1006の値が「80%」であり、ノード分割回数カラム1007の値が「6」であり、ノード分割割合カラム1008の値が「3:1」であることを表している。
ここで、本第4実施形態では、監視情報を5分間隔で取得する例を表したが、これに限定されるものではない。また、ストリームデータごとに監視情報取得間隔を変更してもよい。 また、監視情報をテーブルに追記しているが、不要となった行を削除してもよい。
また、タイムスタンプに格納するデータとして、「2006/08/01 10:00:00 JST」の形式としたが、これに限定されるものではなく、「10:00」など任意の形式で構わない。
また、属性値カラム1005、充填率カラム1006、ノード分割回数カラム1007、ノード分割割合カラム1008に格納する監視情報データはすべての情報が入力される必要はなく、監視項目はどのような方法で設定されてもよい。例えば、前記コマンド入力部110で設定する、設定ファイルに書き込んでおく、システムが既定値を定めておき、設定がなかった場合に、既定値を用いる、などで構わない。
図18は、分割多発検知部156で実行される分割多発検知及び分割多発時の分割割合決定処理のフローチャートを表した図である。
分割多発検知及び分割多発時の分割割合決定処理では、まず、分割多発検知部156は図17に示したインデックス監視情報管理テーブル154を参照する(S2302)。次に、分割多発検知部156がインデックス監視情報管理テーブル154の充填率カラム1006の値を取得し(S2303)、充填率が予め設定した充填率閾値を上回っているか否か、すなわち、「充填率>充填率閾値」を満たしているか否かを判定する(S2304)。ここで、充填率閾値は、どのような方法で設定されてもよい。例えば、前記コマンド入力部110で設定する、あるいは設定ファイルに書き込んでおく、または、ストリームデータ処理システム100で既定値を定めておき、設定がなかった場合に、既定値を用いる、などで構わない。
前記ステップS2304でYESと判定された場合、インデックス監視情報管理テーブル154からノード分割回数カラム1007の値を取得する(S2305)。次に、監視情報管理テーブル143を参照し(S2306)、データレートカラム605の値を取得する(S2307)。次に、前記ステップS2307で取得したデータレートの値、及びインデックス162のキー格納上限数に基づいて予測分割回数を算出する(S2308)。算出式は、「データレート×時間/キー格納上限数」とすることができる。ここで、上記の式は一例であり、これに限定されるものではない。例えば、「データレート×時間×2/キー格納上限数」など定数倍した値を予測分割回数としてもよく、算出式は任意の式で構わない。
次に、前記ステップS2305で取得したノード分割回数と、前記ステップS2308で算出した予測分割回数とを比較し、ノード分割回数が大きく上回っているか否かを判定する、すなわち、「分割回数/予測分割回数>予測分割回数閾値」を満たすか否かを判定する(S2309)。ここで、予測分割回数閾値は、どのような方法で設定されてもよい。例えば、前記コマンド入力部110で設定する、あるいは設定ファイルに書き込んでおく、またはシステムで既定値を定めておき、設定がなかった場合に、既定値を用いる、などで構わない。
前記ステップS2309でNOと判定された場合、ノード分割が多発していないと判断し、処理を終了する(S2315)。前記ステップS2309でYESと判定された場合、若しくは、前記ステップS2304でNOと判定された場合、ノード分割が多発していると判断し、ストリームデータ監視部141において、監視情報を再取得することにより監視情報管理テーブル143を更新する(S2310)。そして、キー傾向予測部142において、キー傾向を再度予測する(S2311)。次に、前記ステップS2310で再度予測したキー傾向と以前まで用いていたキー傾向が同じか否かを判定する(S2312)。
前記ステップS2311でYESと判定された場合、キー傾向の予測が誤っていると判断し、ランダム傾向に設定し(S2313)、処理を終了する(S2315)。前記ステップS2311でNOと判定された場合、再度予測したキー傾向に設定し(S2314)、処理を終了する(S2315)。
ここで、前記ステップS2303、S2304、または前記ステップS2305、S2306、S2307、S2308、S2309の処理は必ず必要ではなく、何れか一方でノード分割多発を検知しても構わない。
また、前記ステップS2310、S2311、S2312、S2313の処理は必ず必要ではなく、ノード分割多発時に常にランダム傾向に設定してもよい。または、ノード分割多発を検知するだけでも構わない。その際に、ノード分割が多発したことを、画面に表示したり、ログファイルに出力したりしてもよい。
図17に示したインデックス監視情報管理テーブル154の例を用いて、具体的に説明する。ここで、充填率閾値を「70%」、キー格納上限数を「10」、予測分割回数閾値を「1.5」とする。
インデックス監視情報管理テーブル154の行1010を参照し(S2302)、充填率カラム1006の値を取得すると、「78%」となる(S2303)。充填率閾値「70%」を上回っているため、ステップS2304では、NOと判定される。次に、ノード分割回数カラム1007の値を取得すると、「7」となる(S2305)。
次に、図13に示した監視情報管理テーブル143の行613を参照し(S2306)、データレートカラム605の値を取得すると、「30タプル/分」となる(S2307)。次に、「データレート×時間/キー格納上限数」の式に基づいて予測分割回数を算出すると、「30×1(分)/6=5」となる(S2308)。次に、「分割回数/予測分割回数>予測分割回数閾値」の式に基づいて、ノード分割回数と予測分割回数を比較すると、「7/5=1.4」となり、予測分割回数閾値「1.5」を上回らないため、ステップS2309では、NOと判定され、処理を終了する(S2314)。
所定の監視間隔である5分が経過し、タイムスタンプが「2006/08/01 10:10:00 JST」となると、上記処理と同様に、インデックス監視情報管理テーブル154の行1011が参照され、ノード分割回数は「198−180=18」となる。ステップS2309の判定では、「分割回数/予測分割回数=18/5=3.6」となり、予測分割回数閾値「1.5」を上回るため、YESと判定される。
そこで、キー傾向を再度算出したところ、増加傾向となったとすると(S2310)、ステップS2311では、NOが判定され、増加傾向に設定され(S2313)、ノード分割割合カラム1008の値を「3:1」から「1:3」に変更し、処理を終了する(S2314)。同時に、インデックス管理テーブル151も更新する。
以上のように、本第4実施形態では、インデックスを監視し、インデックスの監視情報を取得することで、ノード分割が多発していることを検知すると、ノード分割割合を変更、あるいは、キー傾向(またはキー傾向予測値)を再度算出する。これにより、キー傾向の判定結果や分割割合の判定結果に対して、実際のノード分割回数をフィードバックすることによって、キー傾向の判定結果の誤差や分割割合を補正することができる。これにより、ストリームデータ108の揺らぎが、ストリームデータ処理システム100を設計する際の想定の範囲を超えた場合でも、ノード分割が頻発するのを抑制して、インデックス容量が肥大化するのを防ぐことができる。
以上、本発明の第四の実施形態について説明した。
<第5実施形態>
以下では、本発明の第五の実施形態について説明する。
前記第一、第二の実施形態では、ノード分割割合をユーザ101、または計算機102上で実行されるアプリケーション103により指定し、第三の実施形態では、キーが挿入される位置を特定した後に、キー傾向からノード分割割合を算出した。本第五の実施形態では、過去のノード分割履歴からノード分割割合を決定することを特徴とする。
ノード分割割合を決定する処理以外は、第一から第三の実施形態と同様に処理を行える。また、第四の実施形態に示したノード分割多発検知処理を組み合わせて実施してもよい。
第五の実施形態では、図1において、インデックス監視部155が、インデックス162の監視を行い、ノード分割の履歴をインデックス監視情報管理テーブル154に保持する。分割履歴参照部157が、インデックス監視情報管理テーブル154に保持されている前記インデックス監視部155が取得した分割履歴情報に基づいて、日付、時刻、曜日などの条件である時刻条件で、現在と同じ時刻条件に該当するノード分割履歴情報を検索し、ノード分割割合を決定する。また、外部記憶媒体に保持されている属性情報、例えば、天気、温度、イベント情報などを外部属性条件としてさらに絞り込んで検索してもよい。なお、外部記憶媒体は、例えばストリームデータ処理システム100からアクセス可能なストレージ装置などで構成される。
第五の実施形態では、図1において、ストリームデータ特性情報管理部130(特性情報設定部131、特性情報管理テーブル132)、またはストリームデータ監視情報管理部(ストリームデータ監視部141、キー傾向予測部142、監視情報管理テーブル143)の何れか、または両方は必ずしも必要としない。また、インデックス管理部150中の分割割合算出部153、分割多発検知部156は必ずしも必要としない。インデックス管理部150中の読み出し順序制御部158は用いない。
図19は、分割履歴参照部157が実行する分割割合履歴に基づく分割割合決定処理のフローチャートを表した図である。
分割割合履歴からの分割割合決定処理において、まず、分割履歴参照部157がインデックス監視情報管理テーブル154を参照する(S2402)。次に、分割履歴参照部157は前記インデックス監視情報管理テーブル154において、日付、時刻、曜日などの条件である時刻条件で、現在と同じ時刻条件に該当する行を検索する(S2403)。
次に、外部記憶媒体に保持されている属性情報があるか否か、また外部属性条件でさらに絞り込むか否かを判定する(S2404)。前記ステップS2404でYESと判定された場合、外部属性条件でさらに絞り込む(S2405)。
前記ステップS2404でNOと判定された場合、または前記ステップS2405が終了した場合、前記ステップS2403で検索した結果、または前記ステップS2405でさらに絞り込んだ結果、条件に該当する行があるか否かを判定する(S2406)。
前記ステップS2406でYESと判定された場合、最も出現頻度の多いノード分割割合をノード分割割合として設定し(S2407)、処理を終了する(S2409)。前記ステップS2406でNOと判定された場合、システムで予め定めた既定値でノード分割し(S2408)、処理を終了する(S2409)。
ここで、前記ステップS2407において、最も多いノード分割割合をノード分割割合として設定したが、これに限定されるものではなく、例えば、該当行の平均を取ってもよい。
また、システムで予め定めた既定値は任意の値でよい。例えば、1:1(半々に分割)でよい。
図17に示したインデックス監視情報管理テーブル154を用いて具体的に説明する。
ここで、ある時刻「2006/08/02 10:00:00 JST」において、ノード分割割合を決定する場合の処理を説明する。また、外部属性条件は、「天気=晴れ」の条件で絞込みを行い、外部記憶媒体に、行1009の時刻情報「2006/08/01 10:00:00 JST」に対応する天気情報が、「天気=晴れ」と保持されているものとする。
まず、図17に示したインデックス監視情報管理テーブル154を参照し(S2402)、現在と同じ時刻条件、例えば、タイムスタンプカラム1001の値が「10:00:00」を含むノード分割割合履歴を検索する(S2403)。この検索の結果、行1009が該当し、ノード分割割合カラム1008の値は「3:1」となる。ステップS2404において、外部属性条件「天気=晴れ」があるため、YESと判定され、ステップS2605において絞り込みが行われる。ここでは、行1009の天気情報は外部属性条件を満たすため、該当行は1行のままである。ステップS2406では、該当する行が1行あるため、YESと判定され、ステップS2407では、該当行が1行のため、行1009のノード分割割合である「3:1」が選択され、処理を終了する(S2409)。
以上のように、本第5実施形態によれば、過去の分割履歴から現在の時刻や現在の環境に最適なノード分割割合を設定することができ、時刻に関連してキー傾向が変化する温度などのストリームデータ108や、気象などの環境を条件としてキー傾向が変化するストリームデータ108など、揺らぎのあるストリームデータ108を検索するのに最適なインデックス162を提供できる。
以上、本発明の第五の実施形態について説明した。
<第6実施形態>
以下では、本発明の第六の実施形態について説明する。
前記第一から第五の実施形態では、ノードにキーを挿入する際に、小さい順(昇順)で格納していた。しかしながら、減少傾向時には、キーの挿入時に毎回データの移動が発生してしまうため、処理に要する負荷が増大してリアルタイム処理ができない場合やインデックス処理が遅延する場合がある。そこで、第六の実施形態では、インデックス162に読み込み順序フラグを備え、読み込み順序フラグにより、キーの格納順序を変更することを特徴とする。
キーの挿入・削除、及びノード分割処理以外は、第一から第五の実施形態と同様に処理を行える。
第六の実施形態では、図1において、読み出し順序制御部158が、インデックス162の読み込み順序フラグに基づいて読み込み順序を制御する。
第六の実施形態では、図1において、ストリームデータ特性情報管理部130(特性情報設定部131、特性情報管理テーブル132)、またはストリームデータ監視情報管理部(ストリームデータ監視部141、キー傾向予測部142、監視情報管理テーブル143)の何れかは必ずしも必要としない。また、インデックス管理部150中の分割割合算出部153、インデックス監視情報管理テーブル154、インデックス監視部155、分割多発検知部156は必ずしも必要としない。
本第6実施形態では、読み込み順序フラグの値が通常順(昇順)を表す「F」と、逆順(降順)を表す「R」とを用意し、「F」の場合、通常通りノードの先頭(図21aのインデックス1102で左側)からキーの値を読み込み、「R」の場合は、ノードの末尾(図21cのインデックス1110で右側)からキーの値を読み込む逆順とする。ここで、読み込み順序フラグの値としての「F」と「R」は一例であり、これに限定されない。例えば、「0」と「1」でもよい。
図20は、読み込み順序フラグに基づいたキー挿入処理のフローチャートを表した図である。本第6実施形態は、前記非特許文献3に開示されているB木インデックスとは、挿入位置を特定する処理も異なる。そのため、挿入位置を特定する処理から説明する。
読み込み順序フラグに基づいたキー挿入処理では、まず、読み込み順序フラグが「F」か「R」か否かを判定する(S2502)。
前記ステップS2502で「F」(通常順)と判定された場合、ノードの先頭からキーの比較を行い(S2503)、現在処理中のノードがリーフノードであるか否かを判定する(S2505)。前記ステップS2502で「R」(逆順)と判定された場合、ノードの末尾からキーの比較を行い(S2504)、現在処理中のノードがリーフノードであるか否かを判定する(S2505)。
前記ステップS2505でNOと判定された場合、該当する子ノードへジャンプし(S2506)、前記ステップS2502に戻る。そして、リーフノードとなるまで、前記ステップS2502から前記ステップS2505までを繰り返す。前記ステップS2505でYESと判定された場合、キー挿入位置を特定し、挿入する(S2507)。
次に、前記ステップS2507でキーを挿入することで、ノード分割が発生するか否かを判定する(S2508)。
前記ステップS2508でNOと判定された場合、処理を終了する(S2515)。前記ステップS2508でYESと判定された場合、新規ノードを生成し(S2509)、読み込み順序フラグを決定するため、現在のキー傾向が減少傾向であるか否かを判定する(S2510)。
前記ステップS2510でNOと判定された場合、リーフノードページの読み込み順序フラグを「F」(通常順)に設定する(S2511)。前記ステップS2510でYESと判定された場合、リーフノードページの読み込み順序フラグを「R」(逆順)に設定する(S2512)。
前記ステップS2511、または前記ステップS2512が終了した場合、新規ノードにキーを移動し、親ノードのポインタを更新する(S2513)。そして、親ノードにジャンプし(S2514)、前記ステップS2508に戻る。親ノードのノード分割がなくなるまで、前記ステップS2508から前記ステップS2514を繰り返し、処理を終了する(S2515)。
図21a〜図21cは、上記読み込み順序フラグを設定したインデックス処理の例を表した図である。
図21aは、ランダム傾向時に「0、1、2、3、4、5、6」の順にキーを挿入した場合のインデックスを表している。
キーを「0、1、2、3」の順に挿入した場合のインデックスはインデックス1102となる。読み込み順序フラグ1101は、ランダム傾向のため、「F」となっている。ここで、「4」のキーを挿入した場合を図20に示したフローチャートを用いて具体的に説明する。
ステップS2502では、読み込み順序フラグが「F」となっているため、「F」と判定され、ノードの先頭からキーの比較を行う(S2503)。次に、現在処理するノードはリーフノードなので、ステップS2505ではYESが選択される。ステップS2507でキー挿入位置を特定すると、図中一番右に挿入される。
キー格納数が5であるため、ステップS2508では、YESと判定され、新規ノードが生成される(S2509)。キー傾向はランダム傾向であるため、ステップS2510ではNOと判定され、新規ノードの読み込み順序フラグは「F」に設定される(S2511)。新規ノードに「2、3、4」のキーを移動し、親ノードのポインタを更新する(S2513)。この場合は、親ノードがないため、親ノードを生成する。親ノードの読み込み順序フラグは、ランダム傾向であるため、「F」の通常順が設定される。
ステップS2508に戻り、親ノードのノード分割がないため、ステップS2508ではNOと判定され、処理を終了する(S2514)。処理を終了したインデックスは、インデックス1103となる。
同様に、「5、6」のキーを挿入するとインデックス1104となる。
図21bは、増加傾向時に「0、1、2、3、4、5、6」の順にキーを挿入した場合のインデックスを表している。読み込み順序フラグ1105は「F」が設定される。この場合、上記図21aと同様に、キーの読み込み順序は通常順となる。図21aと同様にインデックス処理を行うと、「0、1、2、3」のキーを挿入して、インデックス1106になり、「4、5、6」のキーを挿入すると、インデックス1107となる。
図21cは、減少傾向時に「11、10、9、8、7、6、5、4、3」の順にキーを挿入した場合のインデックスを表している。読み込み順序フラグ1108は、減少傾向のため、「R」の逆順が設定される。
図21aと同様にインデックス処理を行うと、「11、10、9、8」のキーを挿入して、インデックス1109となる。さらに「7」のキーを挿入すると、ノードの格納数が上限であるのでノード分割を行って、新たなノードの先頭に「7」を挿入してインデックス1110となる。次に、「6、5、4、3」のキーを挿入すると逆順にキーを書き込んでいくため、インデックス1110には、「7」の位置を移動せずに「6,5,4」を挿入する。そして、「3」を挿入するとノード分割が発生し、新たなノードに「3」を挿入してインデックス1111となる。
ここで、読み込み順序フラグが「R」の場合、親ノード、すなわち参照ノードにおける子ノードへのポインタも逆順となる。このため、参照ノードのキーの値は、「8,4」の順序で書き込まれる。
また、リーフノード、及び索引ノードは、メモリやディスクなど記憶装置160に格納される場合、ページ単位に格納される。図21に示したインデックスは説明図であり、キーはページの各アドレスに割り当てられる。この割り当て順序を定義したものが、読み込み順序フラグである。読み込み順序フラグを適用するインデックスでは、キーの値をノードに書き込む際には、値の「大小」を反転して書き込み、キーを読み出す際には、図示の格納位置の「左右」を反転して読み出すことになる。
以上のように、本第6実施形態によれば、キー傾向が減少傾向であればキーの読み込み順序を逆順とし、キー傾向が増加またはランダムであれば通常順とすることで、減少傾向の場合にはキーの値が大きい順に書き込むことで、キーを挿入するたびに、データの移動が発生するのを抑制でき、インデックス処理の負荷を低減して、高速な検索を実現できる。
以上、本発明の第六の実施形態について説明した。
<第7実施形態>
以下では、本発明の第七の実施形態について説明する。
前記第一から第六の実施形態では、ストリームデータ処理システムに対し、インデックス処理を適用していた。第七の実施形態では、データベースシステムに対し、インデックス処理を適用する例を示す。インデックス処理は、前記第一から第六実施形態のいずれか、あるいは各実施形態を組み合わせたものを適用することができる。
図22は本発明の一実施形態が適用されたデータベースシステム、及び関連するシステム構成を示すブロック図である。
データベースシステム1200は、入力された挿入データ1208を記憶装置160にテーブルデータ1264として格納し、コマンド入力部110が計算機102から問い合わせ文(SQL文)を受け付けて、テーブルデータ1264の検索を行う点が前記第1実施形態と相違する。その他の構成は、前記第1実施形態と同様のものに同一の符号を付して重複説明を省略する。以下、前記第1実施形態の図1に示したストリームデータ処理システムと、本第6実施形態のデータベースシステム1200の相違点を説明する。
図22において、RFIDリーダ104、センサノード105、計算機106上で実行されるアプリケーション107のデータソースからデータベースシステム1200へデータを入力する場合に、ストリームデータ処理システム100のタプル(レコード)構造での入力ではなく、問合せ(SQL文)での入力となり、コマンド入力部1210はSQLの問い合わせを解析してデータベース処理を実行する。
前記第1実施形態のストリームデータ処理システム100では、ユーザ101または計算機102からの問合せを登録し、登録された問合せを逐次実行するため、問合せ管理部120があったが、データベースシステム1200では、問合せが来るたびに出力結果180を出力するため、問合せ情報を保持する必要がないため、前記第1実施形態のような問合せ管理部120は必要ない。一方、データベースシステム1200では問合せから実行木を生成するモジュールとして、問合せ実行部1270中に実行木生成部1221を必要とする。
データ特性情報管理部1230は、前記第1実施形態のストリームデータ特性情報管理部130に代わって挿入データ1208の特性を管理する。なお、処理の内容は、前記第1実施形態のストリームデータ特性情報管理部130と同様である。挿入データ監視情報管理部1240は、前記第1実施形態のストリームデータ監視情報管理部140が監視する対象を挿入データ1208に変更したものであり、処理の内容は前記第1実施形態のストリームデータ監視情報管理部140と同様である。
記憶装置1260は、前記第1実施形態の記憶装置160に代わってデータベースシステム1200の外部データを格納するものである。データベースシステム1200の場合、記憶装置1260はSANストレージ装置やNAS等の外部記憶装置となる場合があり、図22では、別のシステムとしている。同一計算機内に記憶装置1260を保持しても構わない。また、ストリームデータ処理システム100とは異なり、データベースシステム1200では、データ破棄コマンドがない限り、データを保持し続ける。また、データ構造もテーブル構造となるため、テーブル保存領域1263、及びテーブルデータ1264を必要とする。
問合せ実行部1270は、前記第1実施形態の問合せ実行部170の一時保存領域管理部172をテーブル管理部1272に置き換え、実行木生成部1221を新たに追加したものである。問合せ実行部1270は、記憶装置1260へのデータ格納や、記憶装置1260からのデータ取得を行い、問合せを実行する。
本第7実施形態では、上記のようなシステム構成において、インデックス162のノード分割割合を切り替える。ノード分割割合切り替え方法、及びキー傾向の設定方法、インデックスの読み出し順序は、第一から第六の実施形態に示した方法と同様に処理できる。
以上、本発明の第七の実施形態について説明した。
本発明は、上記に示した第一から第七の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。また、上記に示した第一から第七の実施形態を組み合わせた実施形態も可能である。
例えば、上記の第1の実施形態では、図8に示したインデックス管理テーブル151を用いて説明したが、図23に示すインデックス管理テーブル151を用いて、キーが挿入されるリーフノード位置に基づいて、ノード分割割合を変更してもよい。本手法は、キーがグループ化されており、グループによって傾向が異なる場合、若しくはインデックスの木構造全体におけるリーフノード位置により傾向が異なる場合に、インデックス容量が小さく、高速処理が可能なインデックスを提供することができる。第一の実施形態に示した、前記発散傾向、若しくは収束傾向時のインデックス処理に用いることが可能である。
以下に、詳しく説明する。
図23は、インデックス管理テーブル151の構成例を表した図である。
インデックス名カラム1301、ストリームデータ名カラム1302、カラム名カラム1303、キー傾向カラム1304は、それぞれ、前記第1実施形態の図8に示したインデックス管理テーブル151のインデックス名カラム701、ストリームデータ名カラム702、カラム名カラム703、キー傾向カラム704に対応する。
リーフノード位置カラム1305には、インデックスの木構造全体におけるリーフノードの位置(左から数えて何番目など)を格納する。
分割割合カラム1306には、前記リーフノード位置カラムに対応するノード分割割合を格納する。
例えば、行1307は、インデックス名が「インデックス1」、ストリームデータ名が「S1」、カラム名が「温度」であるインデックスに対し、「増加傾向」時において、リーフノード位置が「0<=位置<10」である場合に、「4:3」にノード分割することを表している。また、行1308は、リーフノード位置が「10<=位置<90」である場合に、「5:2」にノード分割することを表し、行1309は、リーフノード位置が「90<=位置<100」である場合に、「6:1」にノード分割することを表している。
ここで、インデックス管理テーブル151を基に、インデックス162に対して分割割合変更命令を出力する。また、リーフノード位置カラム1305に格納する情報はすべての情報が入力される必要はない。
インデックス処理を行う場合には、第一の実施形態において、図8に示したインデックス管理テーブル151の代わりに図23に示したインデックス管理テーブル151を用いて、図9に示したキー挿入時のインデックス処理において、前記ステップS2002において、リーフノード位置を特定し、前記ステップS2008において、キーの傾向とリーフノード位置とに対応するノード分割割合を取得することで実現可能である。
また、上記の第2の実施形態では、図14に示したキー傾向予測処理を行う例を説明したが、図24に示すキー傾向予測処理のように、監視情報管理テーブル143において監視情報のうち、最新の値を格納する現在の値カラムを用いて、キー傾向を予測しても構わない。
以下に、詳しく説明する。
図24は、キー傾向予測処理を表したフローチャートである。
ステップS2601、ステップS2602、ステップS2603、ステップS2604、ステップS2612は、それぞれ、前記第1実施形態の図14に示した前記ステップS2101、前記ステップS2102、前記ステップS2103、前記ステップS2104、前記ステップS2112に対応する。
ステップS2605において、監視情報管理テーブル143を参照し、最新の監視情報から過去に遡り、一定間隔分の現在の値カラム607の値を取得する。
ここで、取得する現在の値カラム607の値は、任意の間隔、若しくは任意の個数で構わない。例えば、図13に示した前記監視情報管理テーブル143における現在の値カラム607を用いて、10:00、10:05、10:10における現在の値カラム607の値3個を取得してもよい。
次に、前記取得した現在の値が増加し続けているか否かを判定する(S2607)。ここで、増加し続けている判定は、任意の定義で構わない。例えば、すべての要素が増加しており、同じ値を許可しない定義としても、最初と最後を比較した場合に、増加しており、途中の要素は同じ値でも構わない定義としてもよい。
前記ステップS2607でYESと判定された場合、増加傾向に設定し(S2608)、処理を終了する(S2612)。前記ステップS2607でNOと判定された場合、前記取得した現在の値が減少し続けているか否かを判定する(S2609)。ここで、減少し続けている判定は、任意の定義で構わない。例えば、すべての要素が減少しており、同じ値を許可しない定義としても、最初と最後を比較した場合に、減少しており、途中の要素は同じ値でも構わない定義としてもよい。
前記ステップS2609でYESと判定された場合、減少傾向に設定し(S2611)、処理を終了する(S2612)。前記ステップS2609でNOと判定された場合、ランダム傾向に設定し(S2610)、処理を終了する。
また、上記の実施形態では、ストリームデータ処理システム、データベースシステムにおいてインデックス処理を行う例を説明したが、ストリームデータ処理システム、データベースシステム以外のシステムで、上記の実施形態で示したインデックス処理を行ってもよい。
また、上記の実施形態では、ストリームデータ処理システム100、またはデータベースシステム1200は、任意のコンピュータシステムとして説明したが、前記ストリームデータ処理システム100、またはデータベースシステム1200で行う処理の一部、若しくは全部をストレージ装置で行ってもよい。
また、上記の実施形態では、センサノード105が温度データをストリームデータ108としてストリームデータ処理システム100に入力する例を説明したが、これに限定されるものではない。例えば、センサノード105に代わって多数のセンサノードを管理するセンサネットサーバが、センサノードの測定値をストリームデータ108と出力し、ストリームデータ処理システム100でユーザ181が理解可能な有意な情報を含む出力結果180に変換し、計算機182へ提供するようにしてもよい。また、ストリームデータ処理システム100に入力するデータは、RFIDリーダで読み込んだタグの情報、RFIDを一元管理するRFIDミドルウェアシステムである計算機106から入力されるデータでもよい。他にも、ETCシステムなどの交通情報、自動改札機やクレジットカードなどのICカード情報、株価情報などの金融情報、製造工程管理情報などでもよい。
<補足>
なお、請求項5の発明に記載のインデックス処理方法において、
前記キー傾向は、該挿入されるキー系列が単調増加、若しくは単調増加ではないが、全体的に増加していることを表す増加傾向と、該挿入されるキー系列が単調減少、若しくは単調減少ではないが、全体的に減少していることを表す減少傾向と、該挿入されるキー系列に特徴がなく、ランダムな値であることを表すランダム傾向と、であり、
前記データ監視情報を取得する処理は、監視情報を取得した時点における該監視対象のデータの値を表す、現在の値情報を取得する処理をさらに含み、
前記キー傾向決定処理は、
一定間隔の前記監視情報における現在の値情報が増加し続けている場合、増加傾向に設定し、一定間隔の前記監視情報における現在の値情報が減少し続けている場合、減少傾向に設定し、上記何れでもない場合、ランダム傾向に設定することを特徴とするインデックス処理方法。
また、請求項5に記載のインデックス処理方法において、
前記キー傾向は、該挿入されるキー系列が単調増加、若しくは単調増加ではないが、全体的に増加していることを表す増加傾向と、該挿入されるキー系列が単調減少、若しくは単調減少ではないが、全体的に減少していることを表す減少傾向と、該挿入されるキー系列に特徴がなく、ランダムな値であることを表すランダム傾向と、であり、
前記データ監視情報を取得する処理は、
該監視対象のデータと前記監視対象の1個前のデータと比較し、増加したか否かを表す増加カウンタと、該監視対象のデータと前記監視対象の1個前のデータと比較し、減少したか否かを表す減少カウンタとを取得する処理をさらに含み、
前記キー傾向決定処理は、
増加カウンタの値と減少カウンタの値の比が予め設定した増加カウンタ閾値を上回った場合、増加傾向に設定し、減少カウンタの値と増加カウンタの値の比が予め設定した減少カウンタ閾値を上回った場合、減少傾向に設定し、何れの閾値も上回らなかった場合、ランダム傾向に設定することを特徴とするインデックス処理方法。また、請求項14の発明に記載のインデックス処理方法において、
前記インデックスのノード分割時におけるキー配分割合を表すノード分割割合を決定する処理をさらに含み、
前記ノード分割が多発していることを検知する処理において、ノード分割が多発していることを検知した場合に、
前記ノード分割割合を既定値に戻すことを特徴とするインデックス処理方法。
また、インデックスキー挿入時にインデックスのノードにおいてキー格納上限数を上回った場合にノード分割するインデックス処理方法において、
前記インデックスに前記キーをページの各アドレスに割り当てる順序が通常か逆順かを表すフラグである読み込み順序フラグを備えることを特徴とするインデックス処理方法。
上記のインデックス処理方法において、
前記インデックスにキーが挿入されたときの処理は、
前記インデックスのノードの前記読み込み順序フラグが通常か逆順かを判定する処理と、
前記読み込み順序フラグが通常の場合に、ノードの先頭からキーを大小比較する処理と、
前記読み込み順序フラグが逆順の場合に、ノードの末尾からキーを大小比較する処理と、
前記インデックスの該ノードがリーフノードであるか否かを判定する処理と、
前記ノードがリーフノードでない場合に、子ノードへジャンプし、上記処理をリーフノードに辿り着くまで繰り返す処理と、
前記ノードがリーフノードでない場合に、キーのノード内での位置を表すキー挿入位置を特定する処理と、
を含むことを特徴とするインデックス処理方法。
また、上記に記載のインデックス処理方法において、
前記インデックスに挿入されるキー系列の特徴を表すキー傾向を決定するキー傾向決定処理を含み、
前記インデックスにキーが挿入されたときの処理は、
前記ノードにノード分割が発生したか否かを判定する処理と、
新規ノードを生成する処理と、
前記キー傾向が該挿入されるキー系列が単調減少、若しくは単調減少ではないが、全体的に減少していることを表す減少傾向か否かを判定する処理と、
前記キー傾向が減少傾向の場合に、前記ノードの読み込み順序フラグを逆順に設定する処理と、
前記キー傾向が減少傾向でない場合に、前記ノードの読み込み順序フラグを通常に設定する処理と、
前記新規ノードにキー移動し、親ノードのポインタを更新する処理と、
親ノードへジャンプし、前記親ノードにおいてノード分割が発生するか否かを判定する処理と、
上記処理を親ノードがノード分割発生しなくなるまで行う処理と、
を含むことを特徴とするインデックス処理方法。