特許 6021111 フロー集約装置及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6021111

(24)【登録日】2016年10月14日

(45)【発行日】2016年11月2日

(54)【発明の名称】フロー集約装置及び方法

(51)【国際特許分類】

   G06F 17/30 20060101AFI20161020BHJP

   G06F 12/00 20060101ALI20161020BHJP

【ＦＩ】

   G06F17/30 414A

   G06F12/00 513D

   G06F12/00 520A

【請求項の数】6

【全頁数】15

(21)【出願番号】特願2013-211333(P2013-211333)

(22)【出願日】2013年10月8日

(65)【公開番号】特開2015-75896(P2015-75896A)

(43)【公開日】2015年4月20日

【審査請求日】2015年11月25日

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(73)【特許権者】

【識別番号】504176911

【氏名又は名称】国立大学法人大阪大学

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100124844

【弁理士】

【氏名又は名称】石原 隆治

(72)【発明者】

【氏名】高橋 洋介

(72)【発明者】

【氏名】石橋 圭介

(72)【発明者】

【氏名】塩本 公平

(72)【発明者】

【氏名】大下 裕一

(72)【発明者】

【氏名】村田 正幸

【審査官】 田中 秀樹

(56)【参考文献】

【文献】 特開平０９−２６５４７９（ＪＰ，Ａ）

【文献】 特開２００１−２１６３０７（ＪＰ，Ａ）

【文献】 特開２００１−０２２７６６（ＪＰ，Ａ）

【文献】 特開２００１−１６８９１０（ＪＰ，Ａ）

【文献】 特開２０１０−０６８２７９（ＪＰ，Ａ）

【文献】 米国特許第０６２９８３４０（ＵＳ，Ｂ１）

【文献】 米国特許第０６１８２０６０（ＵＳ，Ｂ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １７／３０

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

高次元かつ大規模なフローデータを対象として、多次元データを組み合わせた集約フローを検索するためのデータベースを構築するフロー集約装置であって、
読み込まれた多次元データの多次元属性を格納する多次元属性テーブルと、
前記多次元データに対するインデックス番号を格納するデータインデックステーブルと、
前記多次元データのフロー情報を格納するデータテーブルと、
前記検索するためのデータベースを構築するデータベース構築手段と、
を有し、
前記データベース構築手段は、
前記多次元属性テーブル内の次元毎に一意なメンバを次元ごとに次元メンバテーブルに格納する手段と、
前記次元メンバテーブルの前記メンバに対してインデックス番号を付与し、次元をまたがるメンバに対しては一意なインデックス番号を付与し、多次元メンバ情報を一元化し、メンバインデックス変換テーブルに格納する手段と、
前記多次元属性テーブルの属性をメンバインデックスに変換し、前記メンバインデックス変換テーブルを参照して、メンバに対するメンバインデックスを取得し、前記データテーブルのデータインデックスと取得した該メンバインデックスからメンバインデックス・データインデックス変換テーブルを作成する手段と、
前記メンバインデックス・データインデックス変換テーブルの前記メンバインデックスをウェーブレット木のルート列内インデックスに変換し、ウェーブレット木インデックス変換テーブルを作成する手段と、
前記メンバインデックス・データインデックス変換テーブルから前記メンバインデックスと前記データインデックスを取得し、該データインデックスから単一のデータ列に変換し、該データ列からウェーブレット木を作成し、該メンバインデックスと該データインデックス及び該ウェーブレット木の組み合わせからなる検索用ウェーブレット木ＤＢを作成する手段と、
を有することを特徴とするフロー集約装置。

【請求項2】

前記データベース構築手段は、
前記次元メンバテーブルを作成する際に、次元が、送信元ポート(SrcPort)、宛先ポート(DstPort)、プロトコル(Proto)については、昇順に前記次元メンバテーブルに格納する手段と、
送信元アドレス(SrcIP)、宛先アドレス(DstIP)については、Patricia木を利用してIPアドレスの昇順に前記次元メンバテーブルに格納する手段と、
を含む
請求項１記載のフロー集約装置。

【請求項3】

次元名とメンバ情報からなるユーザクエリが入力されると、該ユーザクエリを解析し、データベースにアクセスするためのデータベースアクセスクエリを生成するクエリ解析手段と、
前記データベースアクセスクエリを前記ウェーブレット木インデックス変換テーブルを参照して、ウェーブウレット木ルート列内のインデックスの組に変換し、前記検索用ウェーブレット木ＤＢを参照し、共通部分集合を求める処理を行うデータベースアクセス手段と、
を更に有する請求項１または２記載のフロー集約装置。

【請求項4】

高次元かつ大規模なフローデータを対象として、多次元データを組み合わせた集約フローを検索するためのデータベースを構築するフロー集約方法であって、
読み込まれた多次元データの多次元属性を格納する多次元属性テーブルと、
前記多次元データに対するインデックス番号を格納するデータインデックステーブルと、
前記多次元データのフロー情報を格納するデータテーブルと、
前記検索するためのデータベースを構築するデータベース構築手段と、
を有する装置において、
前記データベース構築手段が、
前記多次元属性テーブル内の次元毎に一意なメンバを次元ごとに次元メンバテーブルに格納するステップと、
前記次元メンバテーブルの前記メンバに対してインデックス番号を付与し、次元をまたがるメンバに対しては一意なインデックス番号を付与し、多次元メンバ情報を一元化し、メンバインデックス変換テーブルに格納するステップと、
前記多次元属性テーブルの属性をメンバインデックスに変換し、前記メンバインデックス変換テーブルを参照して、メンバに対するメンバインデックスを取得し、前記データテーブルのデータインデックスと取得した該メンバインデックスからメンバインデックス・データインデックス変換テーブルを作成するステップと、
前記メンバインデックス・データインデックス変換テーブルの前記メンバインデックスをウェーブレット木のルート列内インデックスに変換し、ウェーブレット木インデックス変換テーブルを作成するステップと、
前記メンバインデックス・データインデックス変換テーブルから前記メンバインデックスと前記データインデックスを取得し、該データインデックスから単一のデータ列に変換し、該データ列からウェーブレット木を作成し、該メンバインデックスと該データインデックス及び該ウェーブレット木の組み合わせからなる検索用ウェーブレット木ＤＢを作成するステップと、
を行うことを特徴とするフロー集約方法。

【請求項5】

前記次元メンバテーブルを作成する際に、
次元が、送信元ポート(SrcPort)、宛先ポート(DstPort)、プロトコル(Proto)については、昇順に前記次元メンバテーブルに格納するステップと、
送信元アドレス(SrcIP)、宛先アドレス(DstIP)については、Patricia木を利用してIPアドレスの昇順に前記次元メンバテーブルに格納するステップと、
を含む
請求項４記載のフロー集約方法。

【請求項6】

クエリ解析手段とデータベースアクセス手段を更に有する装置において、
前記クエリ解析手段が、次元名とメンバ情報からなるユーザクエリが入力されると、該ユーザクエリを解析し、データベースにアクセスするためのデータベースアクセスクエリを生成ステップと、
前記データベースアクセス手段が、前記データベースアクセスクエリを前記ウェーブレット木インデックス変換テーブルを参照して、ウェーブウレット木ルート列内のインデックスの組に変換し、前記検索用ウェーブレット木ＤＢを参照し、共通部分集合を求める処理を行うステップと、
を更に行う請求項４または５記載のフロー集約方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、フロー集約装置及び方法に係り、特に、フローデータ分析装置及びフロー集約装置において、フローデータの分析結果に基づくフロー集約を効率化するためのフロー集約装置及び方法に関する。

【背景技術】

【0002】

ネットワーク上のトラヒックを監視することは、ネットワーク資源の適切な設計や、異常なトラヒックの検出・制御を実現する上で欠かせない技術である。このためには細粒度でのトラヒック監視技術が必要となる。

【0003】

NetFlow技術では、フローの属性情報として、送信元アドレス(SrcIP)、宛先アドレス(DstIP)、送信元ポート(SrcPort)、宛先ポート(DstPort)、プロトコル(Proto)の５-tupleに加えて、送信元AS(Autonomous System)番号、宛先AS番号、転送に用いられるルータインタフェースの入出力番号、ToS(Type of Service)値、TCP(Transmission Control Protocol)_flag値等のフロー属性情報が含まれている。

【0004】

また、転送されるトラヒック量は日々増大しており、観測されるNetFlowデータのフロー数も爆発的に増加している。このため、従来手法でのNetFlowデータへの自在なアクセスが困難となりつつある。

【0005】

多次元フローデータを保持するためのデータ構造として、FlowID(5-toupleのフロー情報）をキーとして保持する１次元ハッシュテーブルや、Tupleごとにハッシュテーブルを作成し、ハッシュテーブルのキーをLinked Listを用いて繋げたデータ構造を有する多次元ハッシュテーブルがある（例えば、非特許文献１）。

【0006】

しかしながら、１次元ハッシュテーブルは、５-tuple情報をそのまま保持するため、Tupleを自在に組み合わせての問合せができない。また、多次元ハッシュテーブルは、特定のtupleをワイルドカード指定して集約フローを探索する際に、探索時間が大きいという問題がある。

【0007】

また、多次元論理データ空間ビットマップによる多次元データベースがある（例えば特許文献１参照）。これは、次元の特定の組み合わせにおいて、データが多次元論理データ空間内の座標を示すビットマップを作成しておくものである。

【0008】

多次元フローデータベースにおいて、特定次元の組み合わせを指定したフロー検索（スライス検索）を実施することで、異常トラヒック等の特徴的なフローを抽出することができる。例えば、ワーム感染の疑いのあるホストの送信元IPアドレスとワーム感染拡大に利用される宛先ポート番号の組を指定して多次元データベース内を検索することで、ワーム感染拡大に伴って発信されるフローと、その感染先ホストのIPアドレス情報を得ることができる。

【先行技術文献】

【特許文献】

【0009】

【特許文献1】特開平０９−２６５４７９号公報

【非特許文献】

【0010】

【非特許文献1】Yan Hu, Dah-Ming Chiu, John C. S. Lui, "Entropy Based Adaptive Flow Aggregation", IEEE/ACM TRANSACTIONS ON NETWORKING, VOL., 17. NO. 3, (2009) , pp. 698 - 711.

【発明の概要】

【発明が解決しようとする課題】

【0011】

上記の多次元データベースでは、高速にアクセスできるが、ビットマップ保持に必要な記憶容量が次元メンバ数、次元数、データ数に応じて増大するため、多次元大規模データにおいては、データベースに必要となるメモリ量が膨大となる。また、アクセス可能な次元の組み合わせパターンが限定されており、任意の次元の組み合わせでのアクセスが困難である。On-the-fly方式で問合せがある度に上記データベースを任意の組み合わせで構築する場合には、データベース構築時間及びデータベースに必要となるメモリ量が膨大となり、アクセスにかかるオーバヘッドが大きい。

【0012】

分析対象となる異常トラヒックの特徴が予めわかっている場合で、かつ、一定以下の次元数・規模のデータであれば、特許文献１のように多次元論理データ空間ビットマップを作成することで高速なアクセスが可能である。しかし、分析対象となる異常トラヒックの特徴が未知である場合には、多次元データベースに対して任意の次元組み合わせでの複数パターンのスライス検索を実施しつつ、異常トラヒックの特徴を探る等の作業が必要となる。従来技術では、多次元データベースに対する、自在な次元組み合わせのスライス検索が困難である。

【0013】

上記のように、１次元ハッシュテーブル、多次元ハッシュテーブルでは、フロー属性情報を自在に組み合わせた集約フローへのアクセスが困難である。また、多次元フローデータベースの多次元論理データ空間ビットマップでは、短時間でのアクセスが可能となる一方で、多次元の全ての組み合わせを考えると組み合わせ数が爆発するため、データベースに必要となる空間が膨大となり実施できない。

【0014】

本発明は、上記の点に鑑みなされたもので、大規模多次元データの任意の次元組み合わせの検索機能（スライス機能）を高速化可能なフロー集約装置及び方法を提供することを目的とする。

【課題を解決するための手段】

【0015】

一態様によれば、高次元かつ大規模なフローデータを対象として、多次元データを組み合わせた集約フローを検索するためのデータベースを構築するフロー集約装置であって、
読み込まれた多次元データの多次元属性を格納する多次元属性テーブルと、
前記多次元データに対するインデックス番号を格納するデータインデックステーブルと、
前記多次元データのフロー情報を格納するデータテーブルと、
前記検索するためのデータベースを構築するデータベース構築手段と、
を有し、
前記データベース構築手段は、
前記多次元属性テーブル内の次元毎に一意なメンバを次元ごとに次元メンバテーブルに格納する手段と、
前記次元メンバテーブルの前記メンバに対してインデックス番号を付与し、次元をまたがるメンバに対しては一意なインデックス番号を付与し、多次元メンバ情報を一元化し、メンバインデックス変換テーブルに格納する手段と、
前記多次元属性テーブルの属性をメンバインデックスに変換し、前記メンバインデックス変換テーブルを参照して、メンバに対するメンバインデックスを取得し、前記データテーブルのデータインデックスと取得した該メンバインデックスからメンバインデックス・データインデックス変換テーブルを作成する手段と、
前記メンバインデックス・データインデックス変換テーブルの前記メンバインデックスをウェーブレット木のルート列内インデックスに変換し、ウェーブレット木インデックス変換テーブルを作成する手段と、
前記メンバインデックス・データインデックス変換テーブルから前記メンバインデックスと前記データインデックスを取得し、該データインデックスから単一のデータ列に変換し、該データ列からウェーブレット木を作成し、該メンバインデックスと該データインデックス及び該ウェーブレット木の組み合わせからなる検索用ウェーブレット木ＤＢを作成する手段と、を有するフロー集約装置が提供される。

【発明の効果】

【0016】

一態様によれば、大規模高次元フローデータを現実的なメモリ空間量で管理することができ、さらに、目的のフローを検索する際には、フロー数に対数比例する時間計算量での高速な探索が可能となる。

【図面の簡単な説明】

【0017】

【図1】本発明の一実施の形態における多次元データベース構成装置の構成例である。

【図2】本発明の一実施の形態におけるデータインデックステーブル、多次元属性テーブル、データテーブルの例である。

【図3】本発明の一実施の形態における次元メンバテーブルの例である。

【図4】本発明の一実施の形態におけるメンバインデックス・データインデックス変換テーブルの例である。

【図5】本発明の一実施の形態におけるメンバインデックス変換テーブルの例である。

【図6】本発明の一実施の形態における検索用ウェーブレット木への変換方法を示す図である。

【図7】本発明の一実施の形態におけるウェーブレット木の例である。

【図8】本発明の一実施の形態におけるウェーブレット木インデックス変換テーブルの例である。

【図9】本発明の一実施の形態におけるデータベースアクセス部の処理のフローチャート（その１）である。

【図10】本発明の一実施の形態におけるウェーブレット木を用いた共通部分集合演算の例である。

【図11】本発明の一実施の形態におけるデータベースアクセス部の処理のフローチャート（その２）である。

【図12】本発明の一実施の形態におけるデータベースアクセス部の処理のフローチャート（その３）である。

【図13】本発明の一実施の形態におけるPatricia木ＤＢの例である。

【発明を実施するための形態】

【0018】

以下、図面と共に本発明の実施の形態を説明する。

【0019】

本発明は、高次元かつ大規模なフローデータを対象として、自在な組み合わせの集約フローに対して高速なアクセスを可能にするフロー集約装置（多次元データベース構成装置）を提供するものである。

【0020】

図１は、本発明の一実施の形態における多次元データベース構成装置の構成例である。

【0021】

同図に示す多次元データベース構成装置１００は、NetFlowデータ読み込み部１１０、テーブル作成部１２０、ＤＢ構築部１３０、ユーザクエリ解析部１４０、データベースアクセス部１５０、データ出力部１６０、中間ＤＢ１７０、ＤＢ１８０、データテーブル１０１、多次元属性テーブル１０２、データインデックステーブル１０３を有する。

【0022】

中間ＤＢ１７０は、メモリ上に設定され、次元メンバテーブル１７１と、メンバインデックス・データインデックス変換テーブル１７２を有する。ＤＢ１８０が構築されると当該中間ＤＢ１７０のメモリは解放される。

【0023】

ＤＢ１８０は、検索用ウェーブレット木ＤＢ１８１、ウェーブレット木インデックス変換テーブル１８２、メンバインデックス変換テーブル１８３、Patricia木ＤＢ１８４を有する。

【0024】

多次元データ読み込み部１１０は、フローデータ等の多次元データを読み込み、テーブル作成部１２０、ＤＢ構築部１３０に渡す。本例では、５次元のIPフロー情報の時系列トラヒック情報を読み込むものとする。

【0025】

テーブル作成部１２０は、読み込まれた多次元データを、図２に示すように、メモリ上のテーブル１０１，１０２，１０３に格納する。データインデックステーブル１０１は、読み込まれた各５次元情報に対して付与されたインデックス番号を保持する。多次元属性テーブル１０２は、各インデックス番号に対応するSrcIP、DstIP、SrcPort、DstPort、Protoを格納する。データテーブル１０３は、インデックス番号に対応するフローの情報（トラヒック量、パケット数等）を時系列に従って保持する。データテーブル１０３はフローごとに行が分かれており、多次元属性テーブル１０２は、データテーブル１０３の各行のポインタを返すため、当該多次元属性テーブル１０２を介してポインタを取得することで、データテーブル１０３内の該当するフローの情報を得ることができる。

【0026】

ＤＢ構築部１３０は、以下のように中間ＤＢ１７０、ＤＢ１８０を構築する。

【0027】

まず、ＤＢ構築部１３０は、多次元データを読み込む際に、図３に示すように次元ごとに、読み込みデータに出現した一意なメンバを次元メンバテーブル１７１に格納する。但し、SrcPort、DstPort、Protoについては昇順にメンバを格納する。SrcIP、DstIPについては、構築済みのPatricia木ＤＢ１８４を利用してIPアドレスの昇順にメンバを格納する。

【0028】

ＤＢ構築部１３０は、メンバインデックス・データインデックス変換テーブル１７２を生成する。

【0029】

メンバインデックス・データインデックス変換テーブル１７２は、図４に示すように、次元メンバテーブル１７１のメンバインデックスとデータテーブル１０３から得られたデータインデックスから構成される。

【0030】

ＤＢ構築部１３０は、以下の手順でメンバインデックス・データインデックス変換テーブル１７２を生成する。

【0031】

（１）多次元属性テーブル１０２と図５に示すメンバインデックス変換テーブル１８３を用いて、多次元属性テーブル１０２の属性をメンバインデックスに変換する。例えば、図２の多次元テーブル１０２の１行目の
"SrcIP:10.0.01，DstIP:20.0.0.1，SrcPort:10，DstPort:20，Proto:6"
については、図５のメンバインデックス変換テーブル１８３を用いて
"SrcIP:0，DstIP:1000，SrcPort:2000，DstPort:3000，Proto:4000"
となる（これを仮に、多次元属性テーブル-2とする）。

【0032】

（２）データインデックステーブル１０１内の適当なData Indexから上記の多次元属性テーブル-2内の特定の行を得ることができる。例えば、Data Index１にアクセスすると、上記の
"SrcIP:0，DstIP:1000，SrcPort:2000，DstPort:3000，Proto:4000"
が得られ、下記のように、メンバインデックス・データインデックス変換テーブル１７２を作成する。

【0033】

メンバインデックス：0に対して、Data Index 1であるので、0→１；
メンバインデックス：1000に対して、Data Index 1であるので、1000→１；
メンバインデックス：2000に対して、Data Index 1であるので、2000→１；
メンバインデックス：3000に対して、Data Index 1であるので、3000→１；
メンバインデックス：4000に対して、Data Index 1であるので、4000→１；
上記の処理を全てのData Indexにアクセスして繰り返すことでメンバインデックス・データインデックス変換テーブル１７２を作成する。

【0034】

Patricia木ＤＢ１８４は、SrcIP、DstIP次元に関して、多次元データを読み込む際に、読み込みデータに出現したメンバを用いて構築されたPatricia木を保持する。パトリシア木ＤＢ１８４は、後述する図１３に示すように、SrcIP、DstIPそれぞれについて構成され、読み込まれる多次元データに存在する全てのSrcIPアドレス、DstIPアドレスが格納されている。

【0035】

メンバインデックス変換テーブル１８３は、メンバ情報に対応するメンバインデックスを保持する。ＤＢ構築部１３０は、次元メンバテーブル１７１を参照してメンバに対してインデックス番号を付与する。同時に、図５に示すように、メンバ情報からインデックス番号に変換するテーブルを作成する。この際、次元をまたがるメンバに対して一意なインデックス番号を付与することで、多次元メンバ情報の一次元化を行う（ウェーブレット木を１次元リストで構築しなければならないため）。

【0036】

検索用ウェーブレット木ＤＢ１８１は、メンバインデックス・データインデックス変換テーブル１７２のメンバインデックス(図４のMember index)とデータインデックス（図４のData Index）を用いて、多次元データの一次元マッピングを行い、ウェーブレット木インデックス変換テーブル１８２を参照して、図６に示すようにマルチインデックス構造（ウェーブレット木）へと変換することにより生成される。

【0037】

具体的には、メンバインデックス・データインデックス変換テーブル１７２を先頭から順に参照して、Data Index(図４)を単一のデータ列に変換する。図４の例では、1,3,2,4,6,5,…,1,2,3,5,4,6…となる。当該データ列からウェーブレット木を作成する。なお、データ列からウェーブレット列の生成については既存技術（例えば、非特許文献２：http://www.slideshare.net/pfi/ss-15916040）を用いることが可能である。図７にウェーブレット木の例を示す。ウェーブレット木は、完全二分木であり、各節点にはビット列が付随する。葉は各値に対応し、内部節点は子孫の葉の範囲に対応する。

【0038】

このウェーブレット木を用いることで、共通のメンバインデックスを含むデータインデックスの部分集合を得られる。このために例えば、Rank辞書という省メモリで構築可能な簡潔辞書を構築しておき、高速に（データ数に対して対数比例する時間計算量O(log n,但し、nはフロー数)で）共通部分集合を求めることが可能である（例えば、非特許文献３：T. Gagie, G. Navarro, S.J. Puglisi, New algorithms on wavelet trees and applications to information retrieval, Theoretical Computer Science 426-427 (2012) pp. 25-41.参照）。Rank辞書は索引構造を持ち、ビット列B[0…n]に対し、以下の操作を備えた辞書を完備辞書（FID）と呼ぶ。

【0039】

・rankb(B,pos):B[0…pos]中のｂの出現回数を返す；
・selectb(B,ind):(ind+1)番目のｂの出現位置を返す；
例えば、図７の例では、rank1(6)=2であるとき、B[0,6）中に"１"は２回出現することを返し、select0(4)=8であるとき、(4+1)番目の"０"は８で出現することを返す。

【0040】

ウェーブレット木インデックス変換テーブル１８２は、データ検索時に使用され、検索対象データがウェーブレット木のどの位置に存在するかを示すテーブルである。メンバインデックス変換テーブル１８３のメンバインデックス(Member index)をウェーブレット木のルート列内インデックスに変換するテーブルであり、メンバインデックス変換テーブル１８３の作成と同時に作成される。ＤＢ構築部１３０は、メンバインデックス・データインデックス変換テーブル１７２から当該ウェーブレット木インデックス変換テーブル１８２を作成する。具体的には、図６の例では、メンバインデックス"０"は、データ列において０〜１番目に存在し、メンバインデックス"３"は、データ列において４〜６番目に存在するという情報を、図８に示すように、メンバインデックスごとのウェーブレット開始インデックス（Wavelet_start_Index）と終了インデックス(Wavelet_last_Index)を設定する。

【0041】

クエリ解析部１４０は、入力された各次元名とそのメンバ情報からなるユーザクエリを解析し、データベース１８０にアクセスするためのデータベースアクセスクエリを生成する。

【0042】

データベースアクセス部１５０は、データベースアクセスクエリを以下の手順でデータインデックスへと変換する。

【0043】

（１）データベースアクセスクエリをウェーブレット木インデックス変換テーブル１８２を参照して、ウェーブレット木ルート列内インデックスの組へと変換する。

【0044】

（２）検索用ウェーブレット木ＤＢ１８１に対して、共通部分集合を求める処理を実施する。

【0045】

本例では、５次元データであるので、最大５つの共通部分集合を求める関数を準備する。具体的には、非特許文献３の３章（3. New algorithms）に記載されている、２つの共通部分集合を得るためのアルゴリズムを用いる。当該非特許文献３の３．３節（3.3 Range intersection）において、３つ以上の共通部分集合を得るための関数拡張が可能である旨が記載されている。

【0046】

以下にデータベースアクセス部１５０の具体的な動作を説明する。

【0047】

まず、ユーザクエリXとして、SrcIP，DstIP，SrcPort，DstPort，Protoの全てが指定されている場合について説明する。

【0048】

図９は、本発明の一実施の形態におけるデータベースアクセス部の処理のフローチャート（その１）である。

【0049】

本例では、ユーザクエリXとして、
"SrcIP=10.0.0.1，DstIP=20.0.0.5，SrcPort=10，DstPort=20，Proto=6"
が入力されると（ステップ１０１）、当該ユーザクエリXでメンバインデックステーブル変換テーブル１８３（図５）を参照し、ユーザクエリXに対応するメンバインデックスX
"0，1001，2000，3000，4001"
を取得する（ステップ１０２）。

【0050】

次に、上記のメンバインデックスXに基づいて、ウェーブレット木インデックス変換テーブル１８２（図８）を参照し、メンバインデックスXに対するウェーブレット木インデックスX
"［0,1］，[40,46]，[60,72]，[89,94]，[130,132])"
を取得する（ステップ１０３）。

【0051】

上記で取得したウェーブレット木インデックスXに対して、非特許文献３の技術を適用して共通部分集合演算を行い、データインデックス（1）を取得し、データ出力部１６０に出力する（ステップ１０４）。

【0052】

ステップ１０４のウェーブレット木を用いた共通部分集合演算は、図１０の『0721436725047263』について共通部分集合を求める場合、二つの集合［（214）と（250）］の共通部分集合をウェーブレット木で求めるものとする。Rank0操作で左の節に移動（実線）し、Rank１操作で右の節に移動（破線）できる。Rank操作は集合の始点と終点でそれぞれ実施される（集合の長さに無関係）。Rank操作は定数時間とする。２つの集合が同じ値のポインタをさす場合、それが共通部分集合の値となる。

【0053】

次に、ユーザクエリYとして、DstIP，Protoのみが指定されている場合について説明する。

【0054】

図１１は、本発明の一実施の形態におけるデータベースアクセス部の処理のフローチャート（その２）である。

【0055】

本例では、ユーザクエリYとして、
"SrcIP=*，DstIP=20.0.0.1，SrcPort=*，DstPort=*，Proto=6"
が入力されると（ステップ２０１）、当該ユーザクエリYでメンバインデックステーブル変換テーブル１８３（図５）を参照し、ユーザクエリYに対応するメンバインデックスY
"1000，4000"
を取得する（ステップ２０２）。

【0056】

次に、上記のメンバインデックスYに基づいて、ウェーブレット木インデックス変換テーブル１８２（図８）を参照し、メンバインデックスYに対するウェーブレット木インデックスY
" [30,40]，[120,130])"
を取得する（ステップ２０３）。

【0057】

上記で取得したウェーブレット木インデックスYに対して、非特許文献３の技術を適用して共通部分集合演算を行い、データインデックス（1，2，5）を取得し、データ出力部１６０に出力する（ステップ２０４）。共通部分集合演算は、上記と同様である。

【0058】

次に、ユーザクエリZとして、SrcIPとDstIPのみが指定されている場合について説明する。

【0059】

図１２は、本発明の一実施の形態におけるデータベースアクセス部の処理のフローチャート（その３）である。

【0060】

本例では、ユーザクエリZとして、
"SrcIP=*，DstIP=10.0.0.4/30， DstIP=20.0.0.1"
が入力されると（ステップ３０１）、当該ユーザクエリZにSrcIPについて、DstIP[10.0.0.4/30]の範囲でメンバインデックス変換テーブル１８３に含まれるアドレスが10.0.0.1〜10.0.0.6であるため[10.0.0.1，10.0.0.6]とし、図１３に示すようなPatricia木ＤＢ１８４を参照する。（ステップ３０２）。

【0061】

ユーザクエリZのSrcIP=[10.0.0.1]とSrcIP= [10.0.0.6]に基づいてメンバインデックス変換テーブル１８３を参照し、メンバインデックス[0，3]を取得し、DstIP=20.0.0.1に基づいてメンンバインデックス"1000"を取得する。ここで、SrcIP_firstのメンバインデックスの先頭と末尾の組をクエリとする（ステップ３０３）。

【0062】

ステップ３０３で得られたユーザクエリZ(［0,3］，1000)に基づいて、ウェーブレット木インデックス変換テーブル１８２（図８）を参照し、ウェーブレット木インデックスZ（[0,6]，[40,46]）を取得する（ステップ３０４）。図８のウェーブレット木インデックス変換テーブル１８２の例では、１つ目の集合内の先頭であるメンバインデックス"０"のWevelet_start_Indexは"0"であり、集合内の末尾であるメンバインデックス"３"のWavelet_last_Indexは"6"である。

【0063】

上記で取得したウェーブレット木インデックスZに対して、非特許文献３の技術を適用して共通部分集合演算を行い、データインデックス（1，2，3，5）を取得し、データ出力部１６０に出力する（ステップ３０５）。共通部分集合演算は、上記と同様である。

【0064】

上記のように、本発明では、マルチインデックス構造とすることにより、任意のtupleの組み合わせに対して均一時間でのアクセスが可能となる。また、ウェーブレット木構造を組み合わせることで、アクセス時間の時間計算量をO(n)からO(log n)へ削減することが可能となる。

【0065】

上記の実施の形態に示した多次元データベース構成装置の各構成要素の動作をプログラムとして構築し、多次元データベース構成装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。

【0066】

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

【符号の説明】

【0067】

１００ 多次元データベース構成装置
１０１ データインデックステーブル
１０２ 多次元属性テーブル
１０３ データテーブル
１１０ 多次元データ読み込み部
１２０ テーブル作成部
１３０ ＤＢ構築部
１４０ ユーザクエリ解析部
１５０ データベースアクセス部
１６０ データ出力部
１７０ 中間ＤＢ
１７１ 次元メンバテーブル
１７２ メンバインデックス・データインデックス変換テーブル
１８０ ＤＢ
１８１ 検索用ウェーブレット木ＤＢ
１８２ ウェーブレット木インデックス変換テーブル
１８３ メンバインデックス変換テーブル
１８４ Patricia木

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】