JP6205463B2 - 検索装置、検索方法、プログラム、及び記録媒体 - Google Patents

Description

本発明は、木構造で表現される検索対象データを探索することにより、所望のデータを取得する検索技術に関連するものである。

ルータ等の装置においては、受信したパケットの宛先アドレスに基づいて経路表を検索して、パケットの転送先を決定する処理が行われる。当該処理では、最長一致探索が行われるが、そのために、従来、パトリシアトライ（Ｔｒｉｅ）、ラディックス木（基数木）等が用いられていた。従来は２分木のものが主流であり、性能は高くても数Ｍｌｐｓ（Ｍｅｇａ Ｌｏｏｋｕｐ ｐｅｒ ｓｅｃｏｎｄ）であった。多進木（Ｎ−ａｒｙ／Ｍｕｌｔｉｗａｙ）のものも考案されていたが、実用面では主流ではなかった。これらの性能が望ましいものではないため、数百Ｍｌｐｓを実現するＴＣＡＭというハードウェアが事実上の標準となっている。ＴＣＡＭでは経済性、集積度・規模性、消費電力・発熱に難点がある。

ＴＣＡＭの問題点を打破するため、市販品のデバイスとソフトウェアを組み合わせて経路検索する技術が近年現れてきている。ＰａｃｋｅｔＳｈａｄｅｒ、ＧＰＵ Ｃｌｉｃｋ、ＧＡＭＴ等はＧＰＵを利用して高い経路検索性能を実現するが、ＧＰＵを利用するためＴＣＡＭと同様に熱問題などを抱える。なお、先行技術文献として特許文献１がある。

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

上記のようにＴＣＡＭやＧＰＵ等の特定のデバイスを利用すると発熱等の問題があるため、特定のデバイスを利用して経路検索を高速化することは好ましくない。

特定のハードウェアの利用を前提とすることなく、汎用のハードウェア（例：市販のＣＰＵ等）でソフトウェアにより経路検索を高速化する技術（例：ＤＸＲ、ＳＡＩＬ）も提案されているが、当該技術には、経路表内の経路数が大規模になった際や、アドレス長が長くなった際に性能が低下してしまうという問題点がある。

汎用のハードウェアを用いる検索処理において、検索対象データのデータ規模が大規模になったり、キーデータ長が長くなった場合に検索性能が低下する問題は経路検索に限らず生じる問題である。

本発明は上記の点に鑑みてなされたものであり、汎用のハードウェアを用いる場合でも、木構造で表現される検索対象データを高速に検索することを可能とする技術を提供することを目的とする。

本発明の実施の形態によれば、検索対象データを格納した記憶手段と、
キーデータに基づき前記検索対象データに対する検索処理を行う演算手段と、を備える検索装置であって、
前記記憶手段に格納される前記検索対象データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
前記検索対象データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトル、遷移先の１つの内部ノードの格納位置を示す第１のベース情報、及び、遷移先の１つのリーフノードの格納位置を示す第２のベース情報を含み、
前記演算手段は、
キーデータから所定ビット長のチャンクを取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該チャンクの値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、判定された遷移先が内部ノードである場合に、前記第１のベース情報を用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第２のベース情報を用いて当該遷移先のリーフノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する、検索装置であり、
前記検索対象データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納され、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、
前記演算手段は、
前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記ビットベクトルにおける内部ノードを示すビットの値である０又は１の個数を数え、当該個数と前記第１のベース情報とを用いて当該遷移先の内部ノードにアクセスし、
遷移先がリーフノードである場合に、前記ビットベクトルにおけるリーフノードを示すビットの値である１又は０の個数を数え、当該個数と前記第２のベース情報とを用いて当該遷移先のリーフノードにアクセスする
ことを特徴とする検索装置が提供される。

また、本発明の実施の形態によれば、検索対象データを格納した記憶手段と、キーデータに基づき前記検索対象データに対する検索処理を行う演算手段とを備える検索装置が実行する検索方法であって、
前記記憶手段に格納される前記検索対象データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
前記検索対象データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトル、遷移先の１つの内部ノードの格納位置を示す第１のベース情報、及び、遷移先の１つのリーフノードの格納位置を示す第２のベース情報を含み、
前記検索方法は、
キーデータから所定ビット長のチャンクを取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該チャンクの値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、判定された遷移先が内部ノードである場合に、前記第１のベース情報を用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第２のベース情報を用いて当該遷移先のリーフノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する演算ステップを有し、
前記検索対象データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納され、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、
前記演算ステップにおいて、前記検索装置は、
前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記ビットベクトルにおける内部ノードを示すビットの値である０又は１の個数を数え、当該個数と前記第１のベース情報とを用いて当該遷移先の内部ノードにアクセスし、
遷移先がリーフノードである場合に、前記ビットベクトルにおけるリーフノードを示すビットの値である１又は０の個数を数え、当該個数と前記第２のベース情報とを用いて当該遷移先のリーフノードにアクセスする
ことを特徴とする検索方法が提供される。

本発明の実施の形態によれば、汎用のハードウェアを用いる場合でも、木構造で表現される検索対象データを高速に検索することが可能となる。

マルチウェイ基数探索方法を説明するための図である。 本発明の実施の形態に係る検索装置１０の構成図である。 本発明の実施の形態に係る検索装置２０を示す図である。 記憶部１２に格納される検索対象データの例を示す図である。 本実施の形態における検索対象データの構造及び検索処理の概要を説明するための図である。 内部ノードとリーフノードのより具体的な例を示す図である。 検索処理の手順を説明するためのフローチャートである。 ダイレクトポインティングを説明するための図である。 リーフノードのデータの圧縮例を説明するための図である。 圧縮例におけるデータ構造の例を説明するための図である。 リーフノードのデータの圧縮例を説明するための図である。 圧縮例におけるデータ構造の例を説明するための図である。 内部ノードのデータの圧縮例を説明するための図である。 ｌｅａｆ ｍａｓｋを適用する場合における内部ノードのデータ構造を示す図である。 ｌｅａｆ ｍａｓｋを使用する場合において、リーフの値を取得する処理のフローチャートである。 ｌｅａｆ ｍａｓｋに関するデータ作成方法を説明するための図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

（探索方法について）
本実施の形態では、本発明の検索技術の適用先の例として、ルータにおいて、受信したパケットの宛先アドレスをキーとして、ルーティングテーブル（より具体的にはフォワーディングテーブル）を最長一致で検索することにより、当該パケットの転送先とするネクストホップの情報を取得する処理を想定している。ただし、本発明の適用先はこれに限らず、本発明は最長一致に限らず、完全一致等の様々な種類の検索に適用できる。以下では、検索（探索）の対象とするデータを検索対象データと呼ぶ。また、宛先アドレス等の検索のキーとなるデータをキーデータと呼ぶ。

本実施の形態では、検索対象データを検索する手法として、多進木で表現されるマルチウェイ基数探索法を用いているので、まず、マルチウェイ基数探索法の概要を図１を参照して説明する。

マルチウェイ基数探索法では、キーデータを先頭から所定数の複数ビット（以下、チャンクと呼ぶ）ずつに分け、当該複数ビット毎に木の遷移を行う。図１は、２ビットずつチャンクとする例である。各チャンクは４種類の値（図１では、ａ、ｂ、ｃ、ｄと表す）を取り得るから、木における各ノードは４方向に分岐する。分岐先は内部ノード（図１で丸で示すノード）もしくはリーフノード（図１で四角で示すノード）である。

キーデータにおける最初のチャンクから一段目のノードで探索を開始し、該当する値の子ノードに分岐し、キーを次のチャンクに進めることで、順次探索を行い、リーフノードに到達したら探索終了となる。

図１の例で、例えば、キーデータがｄｘｘｘｘ（ｘは任意の値）である場合、５で示すリーフノードに到達する。また、キーデータがｂｂｘｘである場合、６で示すリーフノードに到達する。リーフノードには、例えば、ネクストホップを示す情報（例：アドレス、ＩＦ情報等）が格納され、リーフノードに到達した場合、キーデータに対応するネクストホップの情報を取得できる。

上記の例は、チャンク長を２ビットとする例であるが、例えば、６４ビットＣＰＵアーキテクチャを用いる場合、ビット幅を同一にして演算を効率的にするために、チャンク長を６ビットとして、各ノードで６４分岐する木のデータ構造を使用することができる。

上記のようなマルチウェイ基数探索法においては、一般に、各ノードは、子ノードをポイントするためのポインタ（子ノードを格納するアドレス等）を分岐数分持つが、各ポインタは、例えば６４ビットで子ノードを指定するため、全体の木のデータ量が非常に大きくなるという問題がある。そのため、このようにポインタを用いる構成では、木のデータを汎用ＣＰＵのキャッシュに格納し切れず、ＣＰＵの外にあるメモリに格納せざるを得ないため、検索速度が低下するという問題がある。

一方、本実施の形態に係る技術では、上記の技術に比べて、各内部ノードのデータ量を大幅に削減できるとともに、同じデータを持つノードを圧縮することもできるため、全体の木のデータ量を小さくすることができ、汎用ＣＰＵのキャッシュに木のデータを格納して処理を行うことが可能となる。従って、汎用ＣＰＵ等の汎用のハードウェアを用いる場合でも、高速な検索処理が可能となる。以下、本実施の形態に係る技術をより詳細に説明する。

（装置構成例）
まず、本実施の形態に係る検索処理を実行する検索装置の構成例を説明する。図２は、本実施の形態に係る検索装置１０の構成例を示す図である。

図２に示すように、検索装置１０は、演算部１１、記憶部１２、入力部１３、出力部１４を備える。演算部１１は、後述する方法でキーデータを用いた検索対象データに対する検索処理を実行する機能部である。記憶部１２は、検索対象データを格納する機能部である。入力部１３は、キーデータを入力する機能部である。出力部１４は検索結果を出力する機能部である。

例えば、検索装置１０は、汎用コンピュータであり、演算部１１と記憶部１２がＣＰＵを構成する。この場合、記憶部１２は、ＣＰＵ内のキャッシュに相当する。また、記憶部１２の一部がＣＰＵ外のメモリであってもよい。当該ＣＰＵは、本実施の形態に係る処理のロジックを持つプログラムに従って動作する。当該プログラムは記憶部１２に格納される。また、当該プログラムは記憶部１２以外のメモリ等の記憶部に格納されてもよい。

当該プログラムは、可搬メモリ等の記録媒体に格納して、当該可搬メモリから汎用コンピュータにロードすることで、当該コンピュータを検索装置１０として使用することができる。

また、演算部１１と記憶部１２を、本実施の形態に係る処理のロジックをハードウェア回路として組み込んだ装置として構成することもできる。

図３に、本実施の形態に係る検索装置の他の例である検索装置２０を示す。検索装置２０は、例えばルータとして機能する装置である。図３に示すように、検索装置２０は、パケット処理部２１、宛先決定部２２、及び複数のインターフェース（ＩＦ）を有する。パケット処理部２１は、ＩＦを介してパケットを受信し、宛先決定部２２により決定された宛先（ネクストホップ）に対応するＩＦからパケットを出力する。図３には、パケットをＩＦ−Ａから受信し、ＩＦ−Ｂから出力する例が示されている。

宛先決定部２２は、ルーティングテーブル（フォワーディングテーブル）を格納する記憶部を備え、パケット処理部２１からパケットの宛先アドレスをキーデータとして受け取り、当該キーデータに基づきフォワーディングテーブルを検索することにより当該パケットのネクストホップを決定し、当該ネクストホップの情報をパケット処理部２１に出力する。宛先決定部２２として、例えば、図２に示した検索装置１０を用いることができる。

以下、検索装置１０により実行される検索処理を詳細に説明する。以下、基本的な処理を行う方式を実施例１として説明し、実施例１に対してノードの圧縮を可能とした機能を加えた例を実施例２〜４として説明する。

（実施例１）
図４に、検索装置１０の記憶部１２に格納される検索対象データの例を示す。図４は、実施例１〜４に共通である。前述したように、本実施の形態では、マルチウェイ基数探索法をベースとした検索処理を行うことから、検索対象データは、木における各内部ノードのデータを保持するｎｏｄｅ ａｒｒａｙ（ノード配列）と、木における各リーフノードのデータであるｌｅａｆ ａｒｒａｙ（リーフ配列）を有する。配列として格納される各ノードのデータには、各配列のＩｎｄｅｘを指定することでアクセスできる。

ｌｅａｆ ａｒｒａｙとｎｏｄｅ ａｒｒａｙからなる検索対象データは、例えば可搬メモリ等の記録媒体に格納して、当該可搬メモリから検索装置１０にロードすることで、検索装置１０を検索対象データに対する検索装置１０として使用することができる。また、検索対象データを、あるコンピュータからネットワークを経由して検索装置１０にロードすることもできる。

図５を参照して、実施例１における内部ノードのデータ構造について説明する。図５は、チャンクのビット長が２の場合、つまり、木の各ノードから４方向に分岐する場合の例であるが、チャンクのビット長が何ビットであっても同様の構造である。

図５に示すように、内部ノードは、ｖｅｃｔｏｒ、ｂａｓｅ０、ｂａｓｅ１を有する。ｖｅｃｔｏｒは、当該内部ノードからの分岐数のビットからなるビットベクトルである。キーデータのチャンクが２ビットの場合、００、０１、１０、１１の４種類の値を取り得る。ｖｅｃｔｏｒの各ビットは、右端から順に、上記４種類の各値に対応している。なお、「右端から」とするのは一例であり、「左端から」であってもよい。例えば、ｌｉｔｔｌｅ ｅｎｄｉａｎのＣＰＵを用いる場合に右端から数え、ｂｉｇ ｅｎｄｉａｎのＣＰＵを用いる場合に左端から数える。

図５の例では、例えば、ｖｅｃｔｏｒの右端（０番目）のビットがチャンク００に対応し、１番目のビットがチャンク０１に対応し、２番目のビットがチャンク１０に対応し、３番目のビットがチャンク１１に対応する。ｖｅｃｔｏｒの各ビットは、当該内部ノードからの遷移先（子ノード）が、内部ノードであるか、リーフノードであるかを示す。本実施の形態では、１が内部ノードを示し、０がリーフノードを示すが、これは例であり、１がリーフノードを示し、０が内部ノードを示すように構成してもよい。

例えば、図５に示す内部データに対応するチャンクが００、０１、１０、１１のうちの０１であった場合、演算部１１は、ｖｅｃｔｏｒの０番目から数えて１番目のビット（１）を参照することで、次のノードは内部ノードであることを把握する。また、例えば、チャンクが００、０１、１０、１１のうちの００であった場合、演算部１１は、ｖｅｃｔｏｒの０番目のビット（０）を参照することで、次のノードはリーフノードであることを把握する。

上記のように演算部１１は、ｖｅｃｔｏｒにより遷移先のノードが内部ノードであるかリーフノードであるかを把握できるが、このままでは、内部ノード／リーフノードのデータを取得するために、ｎｏｄｅ ａｒｒａｙ／ｌｅａｆ ａｒｒａｙにおけるどのＩｎｄｅｘの要素にアクセスすればよいかわからない。そこで、本実施の形態では、内部ノードはｂａｓｅ０、ｂａｓｅ１を保持する。

ｂａｓｅ１は、ｎｏｄｅ ａｒｒａｙにおける、当該内部ノードのｖｅｃｔｏｒのビット１に対応する子の内部ノードの格納開始Ｉｎｄｅｘを保持する。ｂａｓｅ０は、ｌｅａｆ ａｒｒａｙにおける、当該内部ノードのｖｅｃｔｏｒのビット０に対応する子のリーフノードの格納開始Ｉｎｄｅｘを保持する。

本実施の形態では、ｎｏｄｅ ａｒｒａｙにおいては、各内部ノードについて、当該内部ノードの子となる内部ノードのデータがＩｎｄｅｘの順番で格納されている。例えば、ある内部ノードについて、子の内部ノードが３つある場合、当該子の内部ノードの３つのデータは、ｎｏｄｅ ａｒｒａｙにおいて、Ｉｎｄｅｘが連続する３つのデータとして格納される。この３つのデータのうちＩｎｄｅｘが先頭（最小）となるデータのＩｎｄｅｘがｂａｓｅ１である。

また、ｌｅａｆ ａｒｒａｙにおいて、各内部ノードについて、当該内部ノードの子となるリーフノードのデータがＩｎｄｅｘの順番で格納されている。例えば、ある内部ノードについて、子のリーフノードが３つある場合、当該子のリーフノードの３つのデータは、ｌｅａｆ ａｒｒａｙにおいて、Ｉｎｄｅｘが連続する３つのデータとして格納される。この３つのデータのうちＩｎｄｅｘが先頭（最小）となるデータのＩｎｄｅｘがｂａｓｅ０である。なお、本実施の形態で使用するＩｎｄｅｘは、格納場所を指す指標であり、これを「アドレス」と言い換えてもよい。

上記のようにしてｎｏｄｅ ａｒｒａｙ／ｌｅａｆ ａｒｒａｙにデータが格納されていることから、演算部１１は、次のようにして、ｂａｓｅ０／ｂａｓｅ１を用いて子の内部ノード／リーフノードのデータにアクセスする。

ｖｅｃｔｏｒのあるビット位置（０番目から数えてｖ番目とする）の子の内部ノードへのアクセスに関し、演算部１１は、ｖｅｃｔｏｒの０番目からｖ番目までのビット位置の１の個数を算出（カウント）する。つまり、ｖｅｃｔｏｒの右端から（ｖ＋１）ビットの中の１の個数を算出する。この個数をｂｃ（ｂｉｔ ｃｏｕｎｔ）とすると、演算部１１は、ｎｏｄｅ ａｒｒａｙにおいて、ｂｃにｂａｓｅ１を加えた値から１を引いた値（ｂｃ＋ｂａｓｅ１−１）のＩｎｄｅｘにアクセスすることで該当内部ノードのデータを取得できる。

ｖｅｃｔｏｒのあるビット位置（０番目から数えてｖ番目とする）の子のリーフノードへのアクセスに関し、演算部１１は、ｖｅｃｔｏｒの０番目からｖ番目までのビット位置の０の個数を算出（カウント）する。つまり、ｖｅｃｔｏｒの右端から（ｖ＋１）ビットの中の０の個数を算出する。この個数をｂｃ（ｂｉｔ ｃｏｕｎｔ）とすると、演算部１１は、ｌｅａｆ ａｒｒａｙにおいて、ｂｃにｂａｓｅ０を加えた値から１を引いた値（ｂｃ＋ｂａｓｅ０−１）のＩｎｄｅｘにアクセスすることで該当リーフノードのデータを取得できる。

図５には、上記の方法で、子の内部ノード（Ｉｎｄｅｘ：２４９８）、及びリーフノード（Ｉｎｄｅｘ：３１２７〜３１２９）にアクセスすることが示されている。

一般にＣＰＵにはビットの数を高速に算出するｐｏｐｃｎｔという機能が備えられており、本実施の形態では、この機能を有効に活用でき、高速に探索を行うことができる。なお、ｐｏｐｃｎｔを使用することは例であり、ｐｏｐｃｎｔを使用しないこととしてもよい。

図５は、チャンク長が２ビット、つまり、ｖｅｃｔｏｒが４ビットである例を示しているが、これは例であり、チャンク長／ｖｅｃｔｏｒは他の長さであってもよい。図６に、チャンク長が６ビット、つまり、ｖｅｃｔｏｒが６４（２^６）ビットである場合の例を示す。図６には、既に説明したとおりに、内部ノードがｖｅｃｔｏｒ、ｂａｓｅ０／ｂａｓｅ１を有し、ビットカウント及びｂａｓｅ０／ｂａｓｅ１により、子の内部ノード／リーフノードにアクセスできることが示されている。

本実施の形態では、内部ノードは、ビットベクトルと２つのｂａｓｅを持てばよく、分岐毎にポインタを有する方式に比べて、各ノードのデータ量を大幅に削減でき、結果として、検索対象データのデータ量を削減できる。

図７を参照して、演算部１１が実行する検索処理の処理手順を説明する。この処理の前提として、演算部１１にはキーデータが入力され、また、記憶部１２には、上述した構造を持つ検索対象データ（ｎｏｄｅ ａｒｒａｙ／ｌｅａｆ ａｒｒａｙ）が格納されているものとする。また、図７は、リーフノードに到達することで検索処理が終了する例を示している。

演算部１１は、ｎｏｄｅ ａｒｒａｙにおける最初の内部ノードからｖｅｃｔｏｒを取得し（ステップ１０１）、また、キーデータから最初のチャンクを取得する（ステップ１０２）。

演算部１１は、チャンクに該当するｖｅｃｔｏｒの位置のビットを読み、当該ビットが１であるかどうか判定する（ステップ１０３）。当該ビットが１である場合、前述したように、ビットカウントｂｃを算出し、（ｂｃ＋ｂａｓｅ１−１）のＩｎｄｅｘに格納されている内部ノードにアクセスして、当該内部ノードのｖｅｃｔｏｒを取得する（ステップ１０４）。

演算部１１は、キーデータから次のチャンクを取得し（ステップ１０５）、再びステップ１０３の判定を実行する。

ステップ１０３の判定の結果、チャンクに該当するｖｅｃｔｏｒの位置のビットが０である場合（ステップ１０３のＮｏ）、ステップ１０６に進む。ステップ１０６において、演算部１１は、前述したように、ビットカウントｂｃを算出し、（ｂｃ＋ｂａｓｅ０−１）のＩｎｄｅｘに格納されているリーフノードにアクセスして、当該リーフノードの値を取得する。

なお、例えば、フォワーディングテーブルにおいては、リーフとなるプレフィックス長が特定の範囲（例：／１１〜／２４）に集中する傾向があるため、最初のほうのノードの探索を省略して、ダイレクトに目的のエントリに到達させることが可能である。これをダイレクトポインティングと呼ぶ。図８を参照して例を説明する。

図８の左側は、ダイレクトポインティングを行わない例であり、この例では、６ビットずつのチャンクで探索を行っている。図８の右側は、最初に１２ビットのチャンクで探索を行うダイレクトポインティングの例を示している。図８の右側の場合でも、当該チャンクでリーフノードに到達できない場合、以降、実施例１での上記の方法と同様にして、例えば６ビットずつのチャンクで探索を行う。ダイレクトポインティングは、他の実施例にも適用可能である。

（実施例２）
次に、実施例２として、実施例１で説明した方式に対して、リーフデータを圧縮できる方式を説明する。例えば、実施例１の方式をフォワーディングテーブルの検索に適用する際に、重複する値（ネクストホップ）を持つリーフノードが多く発生することが考えられる。実施例２は、実施例１の方式をベースとし、リーフノードを圧縮して保持できるようにしている。以下では、主に実施例１と異なる部分について説明する。

図９は、実施例２における内部ノードを示す図である。図９に示すように、実施例２においては、実施例１で説明したｖｅｃｔｏｒ、ｂａｓｅ０、ｂａｓｅ１に加えて、ｌｅａｆｖｅｃが追加される。ｌｅａｆｖｅｃはｖｅｃｔｏｒのビット長と同じビット長である。

また、ｌｅａｆ ａｒｒａｙにおける各内部ノードの子になるリーフノード（つまり、各段のリーフノード）に関して、同じ値を持つ連続するリーフノードは、連続が開始する最初のリーフノードのみが保持される。図９の例では、Ｉｎｄｅｘが３１２７、３１２８、３１２９のリーフノードに関して、値は全部同じで７であり、この場合、Ｉｎｄｅｘが３１２７のリーフノードのみが保持される。このような圧縮の結果、複数のリーフノードがある場合でも、同じ値を持つ複数のリーフノードを含まず、それぞれ異なる値となる。

ｌｅａｆｖｅｃの要素は０又は１のビットであり、右端から、圧縮前のリーフノードの連続が開始する位置に対応するビットに１が立てられている。例えば、図９の例では、最初のリーフノードから連続が始まるので、当該最初のリーフノードに対応する最初（０番目）のビットに１が立てられている。また、連続が終わり別の値のリーフノードが始まる場合（リーフノードが変化する場合）、その位置に１が立てられる。リーフノードが変化する場合とは、最初のリーフノードを含む。ここでの「連続」とは１個の場合を含む。つまり、リーフノードのデータが全て異なる場合、リーフノードに対応するｌｅａｆｖｅｃのビット位置には全て１が立てられる。ｌｅａｆｖｅｃの使用方法は以下のとおりである。

演算部１１が、チャンクに対応するｖｅｃｔｏｒのビット（０番目から数えてｖ番目のビットとする）が０であることを検出すると、子がリーフノードであることを把握する。演算部１１は、ｌｅａｆｖｅｃにおける右端の０番目から数えてｖ番目までのビット（ｖ＋１個のビット）における１のビットの個数を算出する。当該個数をｂｃとすると、ｖｅｃｔｏｒの場合と同様に、演算部１１は、（ｂｃ＋ｂａｓｅ０−１）のＩｎｄｅｘのリーフノードにアクセスする。

図１０に、実施例２における内部ノードとリーフノードのデータ例を示す。図１０の例において、演算部１１は、チャンクに基づき、（ａ）で示す内部ノードにおけるｖｅｃｔｏｒの０番目から数えた１番目のビットが１であることを検知し、それに対応する（ｃ）の内部ノードにアクセスすることが示されている。また、例えば、（ａ）の内部ノードにおいて、チャンクが０番目から数えた２番目（０）に対応する場合に、演算部１１は、ｌｅａｆｖｅｃにおける２番目までの３ビットにおける１の個数を算出し、ｂａｓｅ０を用いて、当該個数に対応するリーフノード（Ｌ（０））にアクセスする。

リーフノードの圧縮は、上記のようにｌｅａｆｖｅｃを用いる以外の方法で実現してもよい。以下、リーフノードの圧縮に係る他の方法を実施例３として説明する。ただし、実施例３の方法は、ｌｅａｆｖｅｃを用いる方法と実質的に同じである。

（実施例３）
図１１は、実施例３における内部ノードを示す図である。図１１に示すように、実施例３においては、実施例１で説明したｖｅｃｔｏｒ、ｂａｓｅ０、ｂａｓｅ１に加えて、ｍａｓｋが追加される。ｍａｓｋはｖｅｃｔｏｒのビット長と同じビット長である。

また、ｌｅａｆ ａｒｒａｙにおける各内部ノードの子になるリーフノード（つまり、各段のリーフノード）に関して、同じ値を持つ連続するリーフノードは、連続が開始する最初のリーフノードのみが保持される。図１１の例では、Ｉｎｄｅｘが３１２７、３１２８、３１２９のリーフノードに関して、値は全部同じで７であり、この場合、Ｉｎｄｅｘが３１２７のリーフノードのみが保持される。このような圧縮の結果、複数のリーフノードがある場合でも、同じ値を持つ連続する複数のリーフノードを含まない。

ｍａｓｋの要素は０又は１のビットであり、右端から、圧縮前のリーフノードの連続が開始する位置に対応するビットに０が立てられ、当該開始位置から同じ値の連続するリーフノードの位置に１（マスク）が立てられる。また、連続が終わり別の値のリーフノードが始まる場合（リーフノードが変化する場合）、その位置に０が立てられる。リーフノードが変化する場合とは、最初のリーフノードを含む。

なお、内部ノードに該当する位置は、１を立ててもよいし、０でもよいが、本例では０としている。図１１の例では、３つのリーフノードが連続するから、最初のリーフノードに該当するビット位置に０が立てられ、以降のリーフノードに該当するビット位置にはマスクである１が立てられる。ｍａｓｋの使用方法は以下のとおりである。

演算部１１が、チャンクに対応するｖｅｃｔｏｒのビット（０番目から数えてｖ番目のビットとする）が０であることを検出すると、子がリーフノードであることを把握する。実施例３では、演算部１１は、ｖｅｃｔｏｒとｍａｓｋのＯＲ演算を行って、ＯＲ演算を行った後のｖｅｃｔｏｒにおける右端の０番目から数えてｖ番目までのビット（ｖ＋１個のビット）における０のビットの個数を算出する。当該個数をｂｃとすると、演算部１１は、（ｂｃ＋ｂａｓｅ０−１）のＩｎｄｅｘのリーフノードにアクセスする。

図１２に、実施例３における内部ノードとリーフノードのデータ例を示す。図１１の例において、演算部１１は、チャンクに基づき、（ａ）で示す内部ノードにおけるｖｅｃｔｏｒの０番目から数えた１番目のビットが１であることを検知し、それに対応する（ｃ）の内部ノードにアクセスすることが示されている。また、例えば、（ａ）の内部ノードにおいて、チャンクが０番目から数えた２番目（０）に対応する場合に、演算部１１は、ｍａｓｋ後のｖｅｃｔｏｒにおける２番目までの３ビットにおける０の個数を算出し、ｂａｓｅ０を用いて、当該個数に対応するリーフノード（Ｌ（０））にアクセスする。

ｍａｓｋは内部ノードの圧縮にも適用できる。ｍａｓｋを内部ノードの圧縮に適用する例を図１３を参照して説明する。図１３は、図６と同様に、チャンク長が６ビット、つまり、ｖｅｃｔｏｒが６４（２^６）ビットである場合の例を示している。この例でも、実施例１で説明したｖｅｃｔｏｒ、ｂａｓｅ０、ｂａｓｅ１に加えて、ｍａｓｋが追加される。ｍａｓｋはｖｅｃｔｏｒのビット長と同じビット長である。

また、各段の内部ノードに関して、同じ値を持つ連続する内部ノードは、連続が開始する最初の内部ノードのみが保持される。図１３の例では、（ａ）に示すように、同一のサブツリーを持つ内部ノードが３つある。この場合、（ｂ）に示すように、３つのうちの最初の内部ノードのみが保持される。このような圧縮の結果、複数の内部ノードがある場合でも、同じ値を持つ連続する複数の内部ノードを含まない。

ｍａｓｋの要素は０又は１のビットであり、右端から、圧縮前の内部ノードの連続が開始する位置に対応するビットに１が立てられ、当該開始位置から同じ値の連続する内部ノードの位置に０（マスク）が立てられる。また、連続が終わり別の値の内部ノードが始まる場合（内部ノードが変化する場合）、その位置に１が立てられる。

図１３の例では、３つの内部ノードが連続するから、最初の内部ノードに該当するビット位置に１が立てられ、以降の内部ノードに該当するビット位置にはマスクである０が立てられる。つまり、図１３（ｂ）に示すように、ｖｅｃｔｏｒの最初の１に対応するｍａｓｋのビットは１であり、次の１とその次の１に対応するｍａｓｋのビットは０である。ｍａｓｋの使用方法は以下のとおりである。

演算部１１が、チャンクに対応するｖｅｃｔｏｒのビット（０番目から数えてｖ番目のビットとする）が１であることを検出すると、子が内部ノードであることを把握する。演算部１１は、ｖｅｃｔｏｒとｍａｓｋのＡＮＤ演算を行って、ＡＮＤ演算を行った後のｖｅｃｔｏｒにおける右端の０番目から数えてｖ番目までのビット（ｖ＋１個のビット）における１のビットの個数を算出する。当該個数をｂｃとすると、演算部１１は、（ｂｃ＋ｂａｓｅ１−１）のＩｎｄｅｘの内部ノードにアクセスする。

（実施例４）
次に、実施例４について説明する。実施例４は、実施例２、３よりも更にリーフノードを圧縮できる方式である。実施例４における内部データの構造を図１４に示す。図１４に示すように、実施例４の内部データは、既に説明したｖｅｃｔｏｒ、ｌｅａｆｖｅｃ、ｂａｓｅ０、ｂａｓｅ１に加えて、「Ａ」で示すように、ｌｅａｆ ｍａｓｋとｍａｓｋｅｄ ｌｅａｆが追加されたものである。記憶部１２にはｎｏｄｅ ａｒｒａｙとｌｅａｆ ａｒｒａｙが格納されている。

ｌｅａｆ ｍａｓｋはｖｅｃｔｏｒと同じビット長の０／１のビットからなるデータである。ｍａｓｋｅｄ ｌｅａｆは、あるリーフノードのデータである。以下、ｌｅａｆ ｍａｓｋとｍａｓｋｅｄ ｌｅａｆを用いる場合の演算部１１の動作を説明する。

図１５のフローチャートを参照して、実施例４における検索装置１０の演算部１１の動作例を説明する。図１５は、実施例１、２とは異なる処理の部分を特に説明するためのものである。

ステップ２０１において、演算部１１は、現在のチャンクのｖｅｃｔｏｒにおける該当ビット（０番目から数えてｖ番目のビットとする）が０であることを検出することで、リーフノードに遷移することを検出する。

ステップ２０２では、演算部１１は、ｌｅａｆ ｍａｓｋにおいて０番目から数えてｖ番目のビットが１であるかどうかを判定する。これが１である場合（ステップ２０２のＹｅｓ）、ｍａｓｋｅｄ ｌｅａｆの値をリーフデータの値として取得する（ステップ２０３）。

ステップ２０２において、ｖ番目のビットが１でない場合（ステップ２０２のＮｏ）、演算部１１は、実施例２と同様にして、ｌｅａｆｖｅｃの０番目からｖ番目までの１の個数（ｂｃ）を算出し、（ｂｃ＋ｂａｓｅ０−１）のＩｎｄｅｘのリーフノードにアクセスして値を取得する（ステップ２０４）。

次に、図１６を参照して、実施例４におけるｌｅａｆ ｍａｓｋに関連するデータの作成方法を説明する。以下で説明するデータの作成は、検索装置１０が行ってもよいし、他の装置（コンピュータ）が行ってもよい。以下では、データの作成を行う装置を作成装置と呼ぶ。作成装置は、検索装置１０又は他の装置である。作成装置が他の装置である場合、データ作成後に、作成データを検索装置１０の記憶部１２に格納する。

まず、作成装置は、圧縮なしでｌｅａｆ ａｒｒａｙを計算する。これにより、例えば４分木であれば、親の内部ノード毎に、例えば図５のＬで示すように、Ｉｎｄｅｘが連続するリーフノードのデータが作成される。

また、６４分木であれば、親の内部ノード毎に、ｌｅａｆ ａｒｒａｙの項目数は最大で６４になる。また、例えば１６分木の例において、リーフ情報が３種類のＡ、Ｂ、Ｃであるとすると、リーフ情報が、図１６（ａ）に示すとおり、例えばＡＢＡＡ ＢＢＢＡ ＢＣＢＢ ＣＣＣＣのようにｌｅａｆ ａｒｒａｙ内に並ぶ。

次に、作成装置は、マスクされるリーフ情報を選ぶ。本例では、Ｂをマスクして省略することにする。一般には、連続する断片が現れる回数が最も多いものをマスクするのが有効であることから、作成装置は、連続する断片が現れる回数が最も多いＢをマスクすると決定する。なお、「連続する断片」は、ＡＢＡにおけるＢのように１つの場合を含む。マスクされたリーフの情報Ｂは、ｍａｓｋｅｄ ｌｅａｆに格納する。

次に、作成装置は、マスクされるリーフ情報が現れるスロットを、ｌｅａｆ ｍａｓｋ に保存する。マスクされるリーフ情報が現れるスロットとは、ｖｅｃｔｏｒにおける当該リーフに対応するビット位置に相当する。例えば、ｖｅｃｔｏｒが００１０である場合に、左端を１番目として数えて２番目のビット０に対応するリーフをマスクする場合、ｌｅａｆ ｍａｓｋに、０１００が保存される。

また、作成装置は、ｌｅａｆ ａｒｒａｙにおいて、マスクされるリーフ情報のスロットを、直前の値と同じにする。これにより、図１６（ａ）に示すリーフ情報から、図１６（ｂ）に示すように、「ｌｅａｆ ｍａｓｋ：０１００ １１１０ １０１１ ００００」が得られ、「ｌｅａｆ ａｒｒａｙ： ＡＡＡＡ ＡＡＡＡ ＡＣＣＣ ＣＣＣＣ」が得られる。なお、本例は、ｂｉｇ ｅｎｄｉａｎであるため、左端から数える。図１６（ｂ）において、下線部分がマスクされた部分であり、数える方向での直前の値（左の値）と同じ値になっている。

次に、リーフマスク無しの場合と同じように、連続する部分を圧縮する。これにより、図１６（ｃ）に示すように、「ｌｅａｆｖｅｃ：１０００ ００００ ０１００ ００００」となり、「ｌｅａｆ ａｒｒａｙ：ＡＣ」となる。

上記の処理の結果、図１６（ｄ）に示すように、「ｌｅａｆ ｍａｓｋ： ０１００ １１１０ １０１１ ００００」、「ｍａｓｋｅｄ ｌｅａｆ：Ｂ」、「ｌｅａｆ ｖｅｃｔｏｒ：１０００ ００００ ０１００ ００００」、「ｌｅａｆ ａｒｒａｙ：ＡＣ」が得られる。

なお、参考までに、リーフマスク無しで圧縮した場合のｌｅａｆ ａｒｒａｙは「ＡＢＡＢＡＢＣＢＣ」となり、実施例４により高い圧縮効果が得られることがわかる。

実施例４では、マスク１つ（例：６４ｂｉｔ）とリーフ１つが追加されるが、不連続であったいくつかのリーフを省略することができ、ｌｅａｆ ａｒｒａｙのさらなる圧縮が実現できる。これは、ｌｅａｆ ａｒｒａｙがあるネクストホップ値によって多く分断されている（縞状態になっている）場合や、リーフ１つの大きさ（ｌｅａｆ ａｒｒａｙの１エントリのサイズ）が１６バイトなど大きかった場合に特に有効となる。

なお、実施例２、３、４は、リーフノードを圧縮する例を示しているが、同じデータを持つ内部ノードに関しても、リーフノードの場合と同じようにして、圧縮することが可能である。また、リーフノードの圧縮と内部ノードの圧縮の両方を行うこととしてもよい。

（実施の形態の効果）
以上、説明したように、本実施の形態では、木のデータ量を大幅に削減できることから、例えば汎用ＣＰＵのキャッシュ（例：Ｌ１、Ｌ２、Ｌ３キャッシュ）に検索対象データを格納して検索処理を実施でき、高速な検索処理を実現できる。特に、例として検索対象データが経路表である場合には、経路表内の経路数が大規模になった際に性能が低下してしまう問題点が解決される。また、処理が高速化されるため、アドレス長が長くなった際に性能が低下してしまう問題点も解決することが可能となる。

また、木の各レベルで、ビット単位で部分木の有無を表現するため、メモリ効率が良い。特に、例として６４分木を用いる場合、６４ビットずつ部分木の有無（子配列）を表現するため、６４−ｂｉｔ ＣＰＵでの処理効率が良いという特徴を持つ。

また、ｖｅｃｔｏｒ等において、１であるビットを数え、配列の中の該当する子に１ステップで飛べるため、高速処理を実現でき、メモリ効率も良い。また、１であるビットを数えるために、ｐｏｐｃｎｔ ＣＰＵ ｉｎｓｔｒｕｃｔｉｏｎ を使用でき、高速処理を実現できる。また、汎用的な多進木（Ｍｕｌｔｉｗａｙ ｔｒｉｅ）をベースにしているため、拡張性・柔軟性が高く、経路表検索に限らず、様々な検索に適用できる。

更に、実施例２〜４で説明したリーフ情報の圧縮を行うことで検索対象データの量を小さくでき、更なる高速化を実現できる。

一例として、本実施の形態に係る技術を用いることで、ｐｏｐｃｎｔ ＣＰＵ ｉｎｓｔｒｕｃｔｉｏｎを持つ汎用ＣＰＵを利用して、５０万のＩＰｖ４フルルート経路を保持する経路表について、シングルコアで２４０Ｍｌｐｓ程度、４コアで９１０Ｍｌｐｓ程度を実現することができる。ＴＣＡＭを利用せず、汎用ＣＰＵでＴＣＡＭと同等から数倍の性能を発揮することができる。

（実施の形態のまとめ）
以上、説明したように、本実施の形態により、検索対象データを格納した記憶手段と、キーデータに基づき前記検索対象データに対する検索処理を行う演算手段と、を備える検索装置であって、前記記憶手段に格納される前記検索対象データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、前記検索対象データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、前記演算手段は、キーデータから所定ビット長のチャンクを取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該チャンクの値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行することを特徴とする検索装置が提供される。

前記検索対象データにおける各内部ノードは、遷移先の１つの内部ノードの格納位置を示す第１のベース情報、及び、遷移先の１つのリーフノードの格納位置を示す第２のベース情報を含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第１のベース情報を用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第２のベース情報を用いて当該遷移先のリーフノードにアクセスするように構成してもよい。

前記検索対象データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納され、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第１のベース情報と、前記ビットベクトルにおける内部ノードを示すビットの数とを用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第２のベース情報と、前記ビットベクトルにおけるリーフノードを示すビットの数とを用いて当該遷移先のリーフノードにアクセスすることとしてもよい。

前記検索対象データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、前記検索対象データにおける各内部ノードは、圧縮前のリーフノードの値が変化した格納位置を示すビットを有するリーフベクトルを含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第２のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスすることとしてもよい。

前記演算手段は、前記ビットベクトルと前記リーフベクトルのうちの前記ビットベクトルを先に調べ、当該ビットベクトルのビットの値に基づき前記リーフベクトルを使用することとしてもよい。

前記検索対象データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、前記検索対象データにおける各内部ノードは、圧縮前のリーフノードの値が変化した格納位置を示すビットを有するマスクベクトルを含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第２のベース情報と、前記マスクベクトルでマスクした前記ビットベクトルにおけるリーフノードを示すビットの数とを用いて当該遷移先のリーフノードにアクセスするようにしてもよい。

前記検索対象データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納されており、同じ値を持つ内部ノードは圧縮され、複数の内部ノードは、同じ値を持つ複数の内部ノードを含まず、前記検索対象データにおける各内部ノードは、圧縮前の内部ノードの値が変化した格納位置を示すビットを有するマスクベクトルを含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第１のベース情報と、前記マスクベクトルでマスクした前記ビットベクトルにおける内部ノードを示すビットの数とを用いて当該遷移先の内部ノードにアクセスすることとしてもよい。

前記検索対象データの各内部ノードについて、遷移先となるリーフノードにおける所定の値がマスクされ、当該マスクされた値が別の値に変更された後に、同じ値を持つリーフノードが圧縮されたことにより、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、前記リーフノード配列において、格納位置が連続して格納されており、前記検索対象データにおける各内部ノードは、前記マスクされた所定の値と、当該所定の値を持つリーフベクトルの圧縮前の位置を示すビットを有するリーフマスクと、圧縮前のリーフノードの値が変化した格納位置を示すビットからなるリーフベクトルとを含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記ビットベクトルにおける当該ビットの位置と同じ位置に、前記リーフマスクにビットが立っているか否かを判定し、立っている場合に、前記所定の値を当該遷移先のリーフノードの値として取得し、立っていない場合に、前記第２のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスすることとしてもよい。

前記演算手段は、当該演算手段により構成されるＣＰＵのｐｏｐｃｎｔ命令を用いて前記ビットの数を算出することとしてもよい。

また、前記演算手段と前記記憶手段は、６４ビットＣＰＵ上で構成することとしてもよい。また、前記チャンクは、６ビット長であり、前記ビットベクトルは、６４ビット長であることとしてもよい。

また、前記演算手段と前記記憶手段は、６４ビットＣＰＵ上で構成し、前記チャンクは、６ビット長であり、前記ビットベクトルは、６４ビット長であり、前記演算手段は、前記６４ビットＣＰＵのｐｏｐｃｎｔ命令を用いて前記ビットの数を算出し、前記遷移先のノードへのアクセスを、ベース情報からの、当該ビットの数に基づくオフセットを用いて行うこととしてもよい。

また、前記演算手段は、前記キーデータから前記所定ビット長よりも長いビット長のチャンクを取得し、当該チャンクを用いて探索を行うことにより、ダイレクトにリーフノードに到達するようにしてもよい。

また、本実施の形態により、コンピュータを、前記検索装置における各手段として機能させるためのプログラムを提供することもできる。また、本実施の形態により、前記検索対象データを格納したコンピュータ読み取り可能な記録媒体を提供することもできる。

また、本実施の形態に係る検索方法を、キーデータに基づき検索対象データに対する検索処理を行う検索方法であって、前記検索対象データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、前記検索対象データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、前記検索方法は、キーデータから所定ビット長のチャンクを取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該チャンクの値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行するステップを有する検索方法として構成してもよい。

以下、本明細書に開示される構成を例示的に列挙する。
（第１項）
検索対象データを格納した記憶手段と、
キーデータに基づき前記検索対象データに対する検索処理を行う演算手段と、を備える検索装置であって、
前記記憶手段に格納される前記検索対象データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
前記検索対象データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトル、遷移先の１つの内部ノードの格納位置を示す第１のベース情報、及び、遷移先の１つのリーフノードの格納位置を示す第２のベース情報を含み、
前記演算手段は、
キーデータから所定ビット長のチャンクを取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該チャンクの値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、判定された遷移先が内部ノードである場合に、前記第１のベース情報を用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第２のベース情報を用いて当該遷移先のリーフノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する
ことを特徴とする検索装置。
（第２項）
前記検索対象データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納され、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、
前記演算手段は、
前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第１のベース情報と、前記ビットベクトルにおける内部ノードを示すビットの数とを用いて当該遷移先の内部ノードにアクセスし、
遷移先がリーフノードである場合に、前記第２のベース情報と、前記ビットベクトルにおけるリーフノードを示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
ことを特徴とする第１項に記載の検索装置。
（第３項）
前記検索対象データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、
前記検索対象データにおける各内部ノードは、圧縮前のリーフノードの値が変化した格納位置を示すビットを有するリーフベクトルを含み、
前記演算手段は、
前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第２のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
ことを特徴とする第１項に記載の検索装置。
（第４項）
前記演算手段は、前記ビットベクトルと前記リーフベクトルのうちの前記ビットベクトルを先に調べ、当該ビットベクトルのビットの値に基づき前記リーフベクトルを使用する
ことを特徴とする第３項に記載の検索装置。
（第５項）
前記検索対象データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、
前記検索対象データにおける各内部ノードは、圧縮前のリーフノードの値が変化した格納位置を示すビットを有するマスクベクトルを含み、
前記演算手段は、
前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第２のベース情報と、前記マスクベクトルでマスクした前記ビットベクトルにおけるリーフノードを示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
ことを特徴とする第１項に記載の検索装置。
（第６項）
前記検索対象データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納されており、同じ値を持つ内部ノードは圧縮され、複数の内部ノードは、同じ値を持つ複数の内部ノードを含まず、
前記検索対象データにおける各内部ノードは、圧縮前の内部ノードの値が変化した格納位置を示すビットを有するマスクベクトルを含み、
前記演算手段は、
前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第１のベース情報と、前記マスクベクトルでマスクした前記ビットベクトルにおける内部ノードを示すビットの数とを用いて当該遷移先の内部ノードにアクセスする
ことを特徴とする第１項に記載の検索装置。
（第７項）
前記検索対象データの各内部ノードについて、遷移先となるリーフノードにおける所定の値がマスクされ、当該マスクされた値が別の値に変更された後に、同じ値を持つリーフノードが圧縮されたことにより、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、前記リーフノード配列において、格納位置が連続して格納されており、
前記検索対象データにおける各内部ノードは、前記マスクされた所定の値と、当該所定の値を持つリーフベクトルの圧縮前の位置を示すビットを有するリーフマスクと、圧縮前のリーフノードの値が変化した格納位置を示すビットからなるリーフベクトルとを含み、
前記演算手段は、
前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記ビットベクトルにおける当該ビットの位置と同じ位置に、前記リーフマスクにビットが立っているか否かを判定し、立っている場合に、前記所定の値を当該遷移先のリーフノードの値として取得し、立っていない場合に、前記第２のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
ことを特徴とする第１項に記載の検索装置。
（第８項）
前記演算手段は、当該演算手段により構成されるＣＰＵのｐｏｐｃｎｔ命令を用いて前記ビットの数を算出する
ことを特徴とする第２項ないし第７項のうちいずれか１項に記載の検索装置。
（第９項）
前記演算手段と前記記憶手段は、６４ビットＣＰＵ上で構成する
ことを特徴とする第１項ないし第８項のうちいずれか１項に記載の検索装置。
（第１０項）
前記チャンクは、６ビット長であり、前記ビットベクトルは、６４ビット長である
ことを特徴とする第１項ないし第９項のうちいずれか１項に記載の検索装置。
（第１１項）
前記演算手段と前記記憶手段は、６４ビットＣＰＵ上で構成し、前記チャンクは、６ビット長であり、前記ビットベクトルは、６４ビット長であり、
前記演算手段は、前記６４ビットＣＰＵのｐｏｐｃｎｔ命令を用いて前記ビットの数を算出し、前記遷移先のノードへのアクセスを、ベース情報からの、当該ビットの数に基づくオフセットを用いて行う
ことを特徴とする第２項ないし第７項のうちいずれか１項に記載の検索装置。
（第１２項）
前記演算手段は、前記キーデータから前記所定ビット長よりも長いビット長のチャンクを取得し、当該チャンクを用いて探索を行うことにより、ダイレクトにリーフノードに到達する
ことを特徴とする第１項ないし第１１項のうちいずれか１項に記載の検索装置。
（第１３項）
コンピュータを、第１項ないし第１２項のうちいずれか１項に記載の前記検索装置における各手段として機能させるためのプログラム。
（第１４項）
第１項ないし第１２項のうちいずれか１項に記載の前記検索対象データを格納したコンピュータ読み取り可能な記録媒体。
（第１５項）
検索対象データを格納した記憶手段と、キーデータに基づき前記検索対象データに対する検索処理を行う演算手段とを備える検索装置が実行する検索方法であって、
前記記憶手段に格納される前記検索対象データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
前記検索対象データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトル、遷移先の１つの内部ノードの格納位置を示す第１のベース情報、及び、遷移先の１つのリーフノードの格納位置を示す第２のベース情報を含み、
前記検索方法は、
キーデータから所定ビット長のチャンクを取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該チャンクの値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、判定された遷移先が内部ノードである場合に、前記第１のベース情報を用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第２のベース情報を用いて当該遷移先のリーフノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行するステップを有する
ことを特徴とする検索方法。

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

１０、２０ 検索装置
１１ 演算部
１２ 記憶部
１３ 入力部
１４ 出力部
２１ パケット処理部
２２ 宛先決定部

Claims (13)

1. 検索対象データを格納した記憶手段と、
   キーデータに基づき前記検索対象データに対する検索処理を行う演算手段と、を備える検索装置であって、
   前記記憶手段に格納される前記検索対象データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
   前記検索対象データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトル、遷移先の１つの内部ノードの格納位置を示す第１のベース情報、及び、遷移先の１つのリーフノードの格納位置を示す第２のベース情報を含み、
   前記演算手段は、
   キーデータから所定ビット長のチャンクを取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該チャンクの値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、判定された遷移先が内部ノードである場合に、前記第１のベース情報を用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第２のベース情報を用いて当該遷移先のリーフノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する、検索装置であり、
   前記検索対象データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納され、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、
   前記演算手段は、
   前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記ビットベクトルにおける内部ノードを示すビットの値である０又は１の個数を数え、当該個数と前記第１のベース情報とを用いて当該遷移先の内部ノードにアクセスし、
   遷移先がリーフノードである場合に、前記ビットベクトルにおけるリーフノードを示すビットの値である１又は０の個数を数え、当該個数と前記第２のベース情報とを用いて当該遷移先のリーフノードにアクセスする
   ことを特徴とする検索装置。
2. 検索対象データを格納した記憶手段と、
   キーデータに基づき前記検索対象データに対する検索処理を行う演算手段と、を備える検索装置であって、
   前記記憶手段に格納される前記検索対象データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
   前記検索対象データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトル、遷移先の１つの内部ノードの格納位置を示す第１のベース情報、及び、遷移先の１つのリーフノードの格納位置を示す第２のベース情報を含み、
   前記演算手段は、
   キーデータから所定ビット長のチャンクを取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該チャンクの値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、判定された遷移先が内部ノードである場合に、前記第１のベース情報を用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第２のベース情報を用いて当該遷移先のリーフノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する、検索装置であり、
   前記検索対象データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、
   前記検索対象データにおける各内部ノードは、圧縮前の所定のリーフノードの格納位置を示すビットを有するリーフベクトルを含み、
   前記演算手段は、
   前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第２のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
   ことを特徴とする検索装置。
3. 前記演算手段は、
   前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記ビットベクトルにおける内部ノードを示すビットの値である０又は１の個数を数え、当該個数と前記第１のベース情報とを用いて当該遷移先の内部ノードにアクセスし、
   遷移先がリーフノードである場合に、前記リーフベクトルにおける前記格納位置を示すビットの値である１又は０の個数を数え、当該個数と前記第２のベース情報とを用いて当該遷移先のリーフノードにアクセスする
   ことを特徴とする請求項２に記載の検索装置。
4. 前記演算手段は、前記ビットベクトルと前記リーフベクトルのうちの前記ビットベクトルを先に調べ、当該ビットベクトルのビットの値に基づき前記リーフベクトルを使用する
   ことを特徴とする請求項２に記載の検索装置。
5. 前記演算手段は、当該演算手段により構成されるＣＰＵのｐｏｐｃｎｔ命令を用いて前記ビットの数を算出する
   ことを特徴とする請求項１ないし４のうちいずれか１項に記載の検索装置。
6. 前記演算手段と前記記憶手段は、６４ビットＣＰＵ上で構成する
   ことを特徴とする請求項１ないし５のうちいずれか１項に記載の検索装置。
7. 前記チャンクは、６ビット長であり、前記ビットベクトルは、６４ビット長である
   ことを特徴とする請求項１ないし６のうちいずれか１項に記載の検索装置。
8. 前記演算手段と前記記憶手段は、６４ビットＣＰＵ上で構成し、前記チャンクは、６ビット長であり、前記ビットベクトルは、６４ビット長であり、
   前記演算手段は、前記６４ビットＣＰＵのｐｏｐｃｎｔ命令を用いて前記ビットの数を算出し、前記遷移先のノードへのアクセスを、ベース情報からの、当該ビットの数に基づくオフセットを用いて行う
   ことを特徴とする請求項１ないし４のうちいずれか１項に記載の検索装置。
9. 前記演算手段は、前記キーデータから前記所定ビット長よりも長いビット長のチャンクを取得し、当該チャンクを用いて探索を行うことにより、ダイレクトにリーフノードに到達する
   ことを特徴とする請求項１ないし８のうちいずれか１項に記載の検索装置。
10. コンピュータを、請求項１ないし９のうちいずれか１項に記載の前記検索装置における各手段として機能させるためのプログラム。
11. 請求項１ないし９のうちいずれか１項に記載の前記検索対象データを格納したコンピュータ読み取り可能な記録媒体。
12. 検索対象データを格納した記憶手段と、キーデータに基づき前記検索対象データに対する検索処理を行う演算手段とを備える検索装置が実行する検索方法であって、
    前記記憶手段に格納される前記検索対象データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
    前記検索対象データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトル、遷移先の１つの内部ノードの格納位置を示す第１のベース情報、及び、遷移先の１つのリーフノードの格納位置を示す第２のベース情報を含み、
    前記検索方法は、
    キーデータから所定ビット長のチャンクを取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該チャンクの値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、判定された遷移先が内部ノードである場合に、前記第１のベース情報を用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第２のベース情報を用いて当該遷移先のリーフノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する演算ステップを有し、
    前記検索対象データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納され、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、
    前記演算ステップにおいて、前記検索装置は、
    前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記ビットベクトルにおける内部ノードを示すビットの値である０又は１の個数を数え、当該個数と前記第１のベース情報とを用いて当該遷移先の内部ノードにアクセスし、
    遷移先がリーフノードである場合に、前記ビットベクトルにおけるリーフノードを示すビットの値である１又は０の個数を数え、当該個数と前記第２のベース情報とを用いて当該遷移先のリーフノードにアクセスする
    ことを特徴とする検索方法。
13. 検索対象データを格納した記憶手段と、キーデータに基づき前記検索対象データに対する検索処理を行う演算手段とを備える検索装置が実行する検索方法であって、
    前記記憶手段に格納される前記検索対象データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
    前記検索対象データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトル、遷移先の１つの内部ノードの格納位置を示す第１のベース情報、及び、遷移先の１つのリーフノードの格納位置を示す第２のベース情報を含み、
    前記検索方法は、
    キーデータから所定ビット長のチャンクを取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該チャンクの値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、判定された遷移先が内部ノードである場合に、前記第１のベース情報を用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第２のベース情報を用いて当該遷移先のリーフノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する演算ステップを有し、
    前記検索対象データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、
    前記検索対象データにおける各内部ノードは、圧縮前の所定のリーフノードの格納位置を示すビットを有するリーフベクトルを含み、
    前記演算ステップにおいて、前記検索装置は、
    前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第２のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
    ことを特徴とする検索方法。
    
    
    
    

Images