JP2020004132A - 検索装置、検索方法、プログラム、及び記録媒体 - Google Patents
検索装置、検索方法、プログラム、及び記録媒体 Download PDFInfo
- Publication number
- JP2020004132A JP2020004132A JP2018123685A JP2018123685A JP2020004132A JP 2020004132 A JP2020004132 A JP 2020004132A JP 2018123685 A JP2018123685 A JP 2018123685A JP 2018123685 A JP2018123685 A JP 2018123685A JP 2020004132 A JP2020004132 A JP 2020004132A
- Authority
- JP
- Japan
- Prior art keywords
- node
- leaf
- bit
- transition destination
- internal node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】木構造で表現される辞書データを高速に検索する。【解決手段】辞書データを格納した記憶手段と、入力文字列に基づき前記辞書データに対する検索処理を行う演算手段と、を備える検索装置において、前記記憶手段に格納される前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、前記演算手段は、入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する。【選択図】図5
Description
本発明は、辞書データを入力文字列に基づいて検索することにより、単語の意味等を取得する検索技術に関連するものである。
一般に辞書データは、単語とその意味を格納したテーブルの形式で実現される。このようなテーブル形式の辞書データからある単語(入力文字列)を検索する場合、入力文字列と膨大な数の単語(例:100万語)との文字列マッチングを行わなければならず、処理が遅くなる。
そこで、辞書データをB木、トライ、Patricia木などの木構造を用いてインデックス化することで、高速に検索を行う技術が従来から存在する。
しかし、従来技術では、木のデータ量が非常に大きくなるため、検索速度が低下する等の問題があった。
本発明は上記の点に鑑みてなされたものであり、木構造で表現される辞書データを高速に検索することを可能とする技術を提供することを目的とする。
本発明の実施の形態によれば、辞書データを格納した記憶手段と、
入力文字列に基づき前記辞書データに対する検索処理を行う演算手段と、を備える検索装置であって、
前記記憶手段に格納される前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、
前記演算手段は、
入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する
ことを特徴とする検索装置が提供される。
入力文字列に基づき前記辞書データに対する検索処理を行う演算手段と、を備える検索装置であって、
前記記憶手段に格納される前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、
前記演算手段は、
入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する
ことを特徴とする検索装置が提供される。
本発明の実施の形態によれば、木構造で表現される検索対象データを高速に検索することが可能となる。
以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。
(探索方法について)
本実施の形態では、検索装置に入力した文字列をキーとして辞書データを検索することにより、当該文字列の意味等を出力する処理を想定している。以下では、検索(探索)の対象とする辞書データを検索対象データと呼ぶ。また、検索のキーとなるデータ(入力文字列)をキーデータと呼ぶ。
本実施の形態では、検索装置に入力した文字列をキーとして辞書データを検索することにより、当該文字列の意味等を出力する処理を想定している。以下では、検索(探索)の対象とする辞書データを検索対象データと呼ぶ。また、検索のキーとなるデータ(入力文字列)をキーデータと呼ぶ。
本実施の形態では、検索対象データを検索する手法として、多進木で表現されるマルチウェイ基数探索法を用いているので、まず、マルチウェイ基数探索法の概要を図1を参照して説明する。
マルチウェイ基数探索法では、キーデータを先頭から所定数の複数ビット(以下、チャンクと呼ぶ)ずつに分け、当該複数ビット毎に木の遷移を行う。図1は、2ビットずつチャンクとする例である。これは、例えば1文字を8ビットで表わす場合において、2ビット毎に分岐を行う例に相当する。なお、非マルチウェイ探索では1ビットずつ分岐を行うが、マルチウェイ探索では、このように複数ビット毎に分岐を行うことが可能である。
各チャンクは4種類の値(図1に示すように00、01、10、11の4種類の値)を取り得るから、木における各ノードは4方向に分岐する。分岐先は内部ノード(図1で丸で示すノード)もしくはリーフノード(図1で四角で示すノード)である。
キーデータにおける最初のチャンクから一段目のノードで探索を開始し、該当する値の子ノードに分岐し、キーを次のチャンクに進めることで、順次探索を行い、リーフノードに到達したら探索終了となる。
図1の例で、例えば、キーデータが11である場合、5で示すリーフノードに到達する。また、キーデータが0101である場合、6で示すリーフノードに到達する。リーフノードには、例えば、文字列の意味を示す情報が格納され、リーフノードに到達した場合、キーデータに対応する意味の情報を取得できる。なお、「意味」は検索結果の一例である。
上記の例は、チャンク長を2ビットとする例であるが、例えば、64ビットCPUアーキテクチャを用いる場合、ビット幅を同一にして演算を効率的にするために、チャンク長を6ビットとして、各ノードで64分岐する木のデータ構造を使用することができる。また、チャンク長を8ビットとして各ノードで256分岐する木のデータ構造を使用することもできる。
上記のようなマルチウェイ基数探索法においては、一般に、各ノードは、子ノードをポイントするためのポインタ(子ノードを格納するアドレス等)を分岐数分持つ。各ポインタが、例えば64ビットあるいは256ビットで子ノードを指定すると、全体の木のデータ量が非常に大きくなるという問題がある。そのため、このようにポインタを用いる構成では、木のデータを汎用CPUのキャッシュ等に格納し切れず、CPUの外にあるメモリあるいはハードディスクに格納せざるを得ないため、検索速度が低下するという問題がある。
一方、本実施の形態に係る技術では、上記の技術に比べて、各内部ノードのデータ量を大幅に削減できるとともに、同じデータを持つノードを圧縮することもできるため、全体の木のデータ量を小さくすることができ、汎用CPUのキャッシュに木のデータを格納して処理を行うことが可能となり、高速な検索処理が可能となる。以下、本実施の形態に係る技術をより詳細に説明する。
(装置構成例)
まず、本実施の形態に係る検索処理を実行する検索装置の構成例を説明する。図2は、本実施の形態に係る検索装置10の構成例を示す図である。
まず、本実施の形態に係る検索処理を実行する検索装置の構成例を説明する。図2は、本実施の形態に係る検索装置10の構成例を示す図である。
図2に示すように、検索装置10は、演算部11、記憶部12、入力部13、出力部14を備える。演算部11は、後述する方法でキーデータ(入力文字列)を用いた検索対象データ(辞書データ)に対する検索処理を実行する機能部である。記憶部12は、検索対象データを格納する機能部である。入力部13は、キーデータを入力する機能部である。出力部14は検索結果を出力する機能部である。
例えば、検索装置10は、汎用コンピュータであり、演算部11と記憶部12がCPUを構成する。また、記憶部12は、CPU内のキャッシュでもよいし、CPU外のメモリであってもよいし、ハードディスク等の記憶装置であってもよい。当該CPUは、本実施の形態に係る処理のロジックを持つプログラムに従って動作する。当該プログラムは記憶部12に格納される。また、当該プログラムは記憶部12以外の記憶装置に格納されてもよい。
当該プログラムは、可搬メモリ等の記録媒体に格納して、当該可搬メモリから汎用コンピュータにロードすることで、当該コンピュータを検索装置10として使用することができる。
また、演算部11と記憶部12を、本実施の形態に係る処理のロジックをハードウェア回路として組み込んだ装置として構成することもできる。
以下、検索装置10により実行される検索処理を詳細に説明する。以下、基本的な処理を行う方式を実施例1として説明し、実施例1に対してノードの圧縮を可能とした機能を加えた例を実施例2〜4として説明する。
(実施例1)
図3は、本実施の形態における検索対象となる辞書の構成例を示す図である。図3に示すように、辞書は、単語とその意味(単語の説明)からなる。なお、単語に対応付けられる情報は任意であり、"意味"は一例である。例えば、意味に代えて、あるいは、意味に加えて、単語に対応する他の言語の単語、単語に対応する漢字、単語に対応する品詞、あるいは単語に対応するURLなどが、単語に対応付けられる情報であってもよい。
図3は、本実施の形態における検索対象となる辞書の構成例を示す図である。図3に示すように、辞書は、単語とその意味(単語の説明)からなる。なお、単語に対応付けられる情報は任意であり、"意味"は一例である。例えば、意味に代えて、あるいは、意味に加えて、単語に対応する他の言語の単語、単語に対応する漢字、単語に対応する品詞、あるいは単語に対応するURLなどが、単語に対応付けられる情報であってもよい。
本実施の形態では、辞書をインデックス化して、検索対象データ(辞書データ)とし、検索装置10の記憶部12に格納する。
図4に、検索装置10の記憶部12に格納される検索対象データの例を示す。図4は、実施例1〜4に共通である。前述したように、本実施の形態では、マルチウェイ基数探索法をベースとした検索処理を行うことから、検索対象データは、木における各内部ノードのデータを保持するnode array(ノード配列)と、木における各リーフノードのデータであるleaf array(リーフ配列)を有する。配列として格納される各ノードのデータには、各配列のIndexを指定することでアクセスできる。
leaf arrayとnode arrayからなる検索対象データ(辞書データ)は、例えば可搬メモリ等の記録媒体に格納して、当該可搬メモリから検索装置10にロードすることで、検索装置10を検索対象データに対する検索装置10として使用することができる。また、検索対象データを、あるコンピュータからネットワークを経由して検索装置10にロードすることもできる。
図5を参照して、実施例1における内部ノードのデータ構造について説明する。図5は、チャンクのビット長が2の場合、つまり、木の各ノードから4方向に分岐する場合の例であるが、チャンクのビット長が何ビットであっても同様の構造である。なお、例えば1文字が8ビットで表わされる場合において、入力文字列から切り出される2ビットのチャンクは文字そのものではないが、文字を構成する情報であることから、チャンクを文字情報と呼ぶことができる。
図5に示すように、内部ノードは、vector、base0、base1を有する。vectorは、当該内部ノードからの分岐数のビットからなるビットベクトルである。キーデータのチャンクが2ビットの場合、00、01、10、11の4種類の値を取り得る。vectorの各ビットは、右端から順に、上記4種類の各値に対応している。なお、「右端から」とするのは一例であり、「左端から」であってもよい。例えば、little endianのCPUを用いる場合に右端から数え、big endianのCPUを用いる場合に左端から数える。
図5の例では、例えば、vectorの右端(0番目)のビットがチャンク00に対応し、1番目のビットがチャンク01に対応し、2番目のビットがチャンク10に対応し、3番目のビットがチャンク11に対応する。vectorの各ビットは、当該内部ノードからの遷移先(子ノード)が、内部ノードであるか、リーフノードであるかを示す。本実施の形態では、1が内部ノードを示し、0がリーフノードを示すが、これは例であり、1がリーフノードを示し、0が内部ノードを示すように構成してもよい。
例えば、図5に示す内部データに対応するチャンクが00、01、10、11のうちの01であった場合、演算部11は、vectorの0番目から数えて1番目のビット(1)を参照することで、次のノードは内部ノードであることを把握する。また、例えば、チャンクが00、01、10、11のうちの00であった場合、演算部11は、vectorの0番目のビット(0)を参照することで、次のノードはリーフノードであることを把握する。
上記のように演算部11は、vectorにより遷移先のノードが内部ノードであるかリーフノードであるかを把握できるが、このままでは、内部ノード/リーフノードのデータを取得するために、node array/leaf arrayにおけるどのIndexの要素にアクセスすればよいかわからない。そこで、本実施の形態では、内部ノードはbase0、base1を保持する。
base1は、node arrayにおける、当該内部ノードのvectorのビット1に対応する子の内部ノードの格納開始Indexを保持する。base0は、leaf arrayにおける、当該内部ノードのvectorのビット0に対応する子のリーフノードの格納開始Indexを保持する。
本実施の形態では、node arrayにおいては、各内部ノードについて、当該内部ノードの子となる内部ノードのデータがIndexの順番で格納されている。例えば、ある内部ノードについて、子の内部ノードが3つある場合、当該子の内部ノードの3つのデータは、node arrayにおいて、Indexが連続する3つのデータとして格納される。この3つのデータのうちIndexが先頭(最小)となるデータのIndexがbase1である。
また、leaf arrayにおいて、各内部ノードについて、当該内部ノードの子となるリーフノードのデータがIndexの順番で格納されている。例えば、ある内部ノードについて、子のリーフノードが3つある場合、当該子のリーフノードの3つのデータは、leaf arrayにおいて、Indexが連続する3つのデータとして格納される。この3つのデータのうちIndexが先頭(最小)となるデータのIndexがbase0である。なお、本実施の形態で使用するIndexは、格納場所を指す指標であり、これを「アドレス」と言い換えてもよい。
上記のようにしてnode array/leaf arrayにデータが格納されていることから、演算部11は、次のようにして、base0/base1を用いて子の内部ノード/リーフノードのデータにアクセスする。
vectorのあるビット位置(0番目から数えてv番目とする)の子の内部ノードへのアクセスに関し、演算部11は、vectorの0番目からv番目までのビット位置の1の個数を算出(カウント)する。つまり、vectorの右端から(v+1)ビットの中の1の個数を算出する。この個数をbc(bit count)とすると、演算部11は、node arrayにおいて、bcにbase1を加えた値から1を引いた値(bc+base1−1)のIndexにアクセスすることで該当内部ノードのデータを取得できる。
vectorのあるビット位置(0番目から数えてv番目とする)の子のリーフノードへのアクセスに関し、演算部11は、vectorの0番目からv番目までのビット位置の0の個数を算出(カウント)する。つまり、vectorの右端から(v+1)ビットの中の0の個数を算出する。この個数をbc(bit count)とすると、演算部11は、leaf arrayにおいて、bcにbase0を加えた値から1を引いた値(bc+base0−1)のIndexにアクセスすることで該当リーフノードのデータを取得できる。
図5には、上記の方法で、子の内部ノード(Index:2498)、及びリーフノード(Index:3127〜3129)にアクセスすることが示されている。また、リーフノードのアドレスには、そのリーフノードに到達した単語の意味等(あるいは意味等の格納場所へのポインタアドレス)が格納される。
一般にCPUにはビットの数を高速に算出するpopcntという機能が備えられており、本実施の形態では、この機能を有効に活用でき、高速に探索を行うことができる。なお、popcntを使用することは例であり、popcntを使用しないこととしてもよい。
図5は、チャンク長が2ビット、つまり、vectorが4ビットである例を示しているが、これは例であり、チャンク長/vectorは他の長さであってもよい。図6に、チャンク長が6ビット、つまり、vectorが64(26)ビットである場合の例を示す。図6には、既に説明したとおりに、内部ノードがvector、base0/base1を有し、ビットカウント及びbase0/base1により、子の内部ノード/リーフノードにアクセスできることが示されている。
本実施の形態では、内部ノードは、ビットベクトルと2つのbaseを持てばよく、分岐毎にポインタを有する方式に比べて、各ノードのデータ量を大幅に削減でき、結果として、検索対象データのデータ量を削減できる。
図7を参照して、演算部11が実行する検索処理の処理手順を説明する。この処理の前提として、演算部11にはキーデータが入力され、また、記憶部12には、上述した構造を持つ検索対象データ(node array/leaf array)が格納されているものとする。また、図7は、リーフノードに到達することで検索処理が終了する例を示している。
演算部11は、node arrayにおける最初の内部ノードからvectorを取得し(ステップ101)、また、キーデータ(入力文字列)から最初のチャンク(文字情報)を取得する(ステップ102)。
演算部11は、チャンクに該当するvectorの位置のビットを読み、当該ビットが1であるかどうか判定する(ステップ103)。当該ビットが1である場合、前述したように、ビットカウントbcを算出し、(bc+base1−1)のIndexに格納されている内部ノードにアクセスして、当該内部ノードのvectorを取得する(ステップ104)。
演算部11は、キーデータから次のチャンクを取得し(ステップ105)、再びステップ103の判定を実行する。
ステップ103の判定の結果、チャンクに該当するvectorの位置のビットが0である場合(ステップ103のNo)、ステップ106に進む。ステップ106において、演算部11は、前述したように、ビットカウントbcを算出し、(bc+base0−1)のIndexに格納されているリーフノードにアクセスして、当該リーフノードの値(例:単語の意味)を取得する。
(実施例2)
次に、実施例2として、実施例1で説明した方式に対して、リーフデータを圧縮できる方式を説明する。例えば、辞書として、単語と、その単語の品詞を対応付けた辞書を用いる場合において、重複する値(名詞、動詞、助詞等)を持つリーフノードが多く発生することが考えられる。実施例2は、実施例1の方式をベースとし、リーフノードを圧縮して保持できるようにしている。以下では、主に実施例1と異なる部分について説明する。
次に、実施例2として、実施例1で説明した方式に対して、リーフデータを圧縮できる方式を説明する。例えば、辞書として、単語と、その単語の品詞を対応付けた辞書を用いる場合において、重複する値(名詞、動詞、助詞等)を持つリーフノードが多く発生することが考えられる。実施例2は、実施例1の方式をベースとし、リーフノードを圧縮して保持できるようにしている。以下では、主に実施例1と異なる部分について説明する。
図8は、実施例2における内部ノードを示す図である。図8に示すように、実施例2においては、実施例1で説明したvector、base0、base1に加えて、leafvecが追加される。leafvecはvectorのビット長と同じビット長である。
また、leaf arrayにおける各内部ノードの子になるリーフノード(つまり、各段のリーフノード)に関して、同じ値を持つ連続するリーフノードは、連続が開始する最初のリーフノードのみが保持される。図8の例では、Indexが3127、3128、3129のリーフノードに関して、値は全部同じで「名詞」であり、この場合、Indexが3127のリーフノードのみが保持される。このような圧縮の結果、複数のリーフノードがある場合でも、同じ値を持つ複数のリーフノードを含まず、それぞれ異なる値となる。
leafvecの要素は0又は1のビットであり、右端から、圧縮前のリーフノードの連続が開始する位置に対応するビットに1が立てられている。例えば、図8の例では、最初のリーフノードから連続が始まるので、当該最初のリーフノードに対応する最初(0番目)のビットに1が立てられている。また、連続が終わり別の値のリーフノードが始まる場合(リーフノードが変化する場合)、その位置に1が立てられる。リーフノードが変化する場合とは、最初のリーフノードを含む。ここでの「連続」とは1個の場合を含む。つまり、リーフノードのデータが全て異なる場合、リーフノードに対応するleafvecのビット位置には全て1が立てられる。leafvecの使用方法は以下のとおりである。
演算部11が、チャンクに対応するvectorのビット(0番目から数えてv番目のビットとする)が0であることを検出すると、子がリーフノードであることを把握する。演算部11は、leafvecにおける右端の0番目から数えてv番目までのビット(v+1個のビット)における1のビットの個数を算出する。当該個数をbcとすると、vectorの場合と同様に、演算部11は、(bc+base0−1)のIndexのリーフノードにアクセスする。
図9に、実施例2における内部ノードとリーフノードのデータ例を示す。図9の例において、演算部11は、チャンクに基づき、(a)で示す内部ノードにおけるvectorの0番目から数えた1番目のビットが1であることを検知し、それに対応する(c)の内部ノードにアクセスすることが示されている。また、例えば、(a)の内部ノードにおいて、チャンクが0番目から数えた2番目(0)に対応する場合に、演算部11は、leafvecにおける2番目までの3ビットにおける1の個数を算出し、base0を用いて、当該個数に対応するリーフノード(L(0))にアクセスする。
リーフノードの圧縮は、上記のようにleafvecを用いる以外の方法で実現してもよい。以下、リーフノードの圧縮に係る他の方法を実施例3として説明する。ただし、実施例3の方法は、leafvecを用いる方法と実質的に同じである。
(実施例3)
図10は、実施例3における内部ノードを示す図である。図10に示すように、実施例3においては、実施例1で説明したvector、base0、base1に加えて、maskが追加される。maskはvectorのビット長と同じビット長である。
図10は、実施例3における内部ノードを示す図である。図10に示すように、実施例3においては、実施例1で説明したvector、base0、base1に加えて、maskが追加される。maskはvectorのビット長と同じビット長である。
また、leaf arrayにおける各内部ノードの子になるリーフノード(つまり、各段のリーフノード)に関して、同じ値を持つ連続するリーフノードは、連続が開始する最初のリーフノードのみが保持される。図10の例では、Indexが3127、3128、3129のリーフノードに関して、値は全部同じで名詞であり、この場合、Indexが3127のリーフノードのみが保持される。このような圧縮の結果、複数のリーフノードがある場合でも、同じ値を持つ連続する複数のリーフノードを含まない。
maskの要素は0又は1のビットであり、右端から、圧縮前のリーフノードの連続が開始する位置に対応するビットに0が立てられ、当該開始位置から同じ値の連続するリーフノードの位置に1(マスク)が立てられる。また、連続が終わり別の値のリーフノードが始まる場合(リーフノードが変化する場合)、その位置に0が立てられる。リーフノードが変化する場合とは、最初のリーフノードを含む。
なお、内部ノードに該当する位置は、1を立ててもよいし、0でもよいが、本例では0としている。図10の例では、3つのリーフノードが連続するから、最初のリーフノードに該当するビット位置に0が立てられ、以降のリーフノードに該当するビット位置にはマスクである1が立てられる。maskの使用方法は以下のとおりである。
演算部11が、チャンクに対応するvectorのビット(0番目から数えてv番目のビットとする)が0であることを検出すると、子がリーフノードであることを把握する。実施例3では、演算部11は、vectorとmaskのOR演算を行って、OR演算を行った後のvectorにおける右端の0番目から数えてv番目までのビット(v+1個のビット)における0のビットの個数を算出する。当該個数をbcとすると、演算部11は、(bc+base0−1)のIndexのリーフノードにアクセスする。
図11に、実施例3における内部ノードとリーフノードのデータ例を示す。図11の例において、演算部11は、チャンクに基づき、(a)で示す内部ノードにおけるvectorの0番目から数えた1番目のビットが1であることを検知し、それに対応する(c)の内部ノードにアクセスすることが示されている。また、例えば、(a)の内部ノードにおいて、チャンクが0番目から数えた2番目(0)に対応する場合に、演算部11は、mask後のvectorにおける2番目までの3ビットにおける0の個数を算出し、base0を用いて、当該個数に対応するリーフノード(L(0))にアクセスする。
maskは内部ノードの圧縮にも適用できる。maskを内部ノードの圧縮に適用する例を図12を参照して説明する。図12は、図6と同様に、チャンク長が6ビット、つまり、vectorが64(26)ビットである場合の例を示している。この例でも、実施例1で説明したvector、base0、base1に加えて、maskが追加される。maskはvectorのビット長と同じビット長である。
また、各段の内部ノードに関して、同じ値を持つ連続する内部ノードは、連続が開始する最初の内部ノードのみが保持される。図12の例では、(a)に示すように、同一のサブツリーを持つ内部ノードが3つある。この場合、(b)に示すように、3つのうちの最初の内部ノードのみが保持される。このような圧縮の結果、複数の内部ノードがある場合でも、同じ値を持つ連続する複数の内部ノードを含まない。
maskの要素は0又は1のビットであり、右端から、圧縮前の内部ノードの連続が開始する位置に対応するビットに1が立てられ、当該開始位置から同じ値の連続する内部ノードの位置に0(マスク)が立てられる。また、連続が終わり別の値の内部ノードが始まる場合(内部ノードが変化する場合)、その位置に1が立てられる。
図12の例では、3つの内部ノードが連続するから、最初の内部ノードに該当するビット位置に1が立てられ、以降の内部ノードに該当するビット位置にはマスクである0が立てられる。つまり、図12(b)に示すように、vectorの最初の1に対応するmaskのビットは1であり、次の1とその次の1に対応するmaskのビットは0である。maskの使用方法は以下のとおりである。
演算部11が、チャンクに対応するvectorのビット(0番目から数えてv番目のビットとする)が1であることを検出すると、子が内部ノードであることを把握する。演算部11は、vectorとmaskのAND演算を行って、AND演算を行った後のvectorにおける右端の0番目から数えてv番目までのビット(v+1個のビット)における1のビットの個数を算出する。当該個数をbcとすると、演算部11は、(bc+base1−1)のIndexの内部ノードにアクセスする。
(実施例4)
次に、実施例4について説明する。実施例4は、実施例2、3よりも更にリーフノードを圧縮できる方式である。実施例4における内部データの構造を図13に示す。図13に示すように、実施例4の内部データは、既に説明したvector、leafvec、base0、base1に加えて、「A」で示すように、leaf maskとmasked leafが追加されたものである。記憶部12にはnode arrayとleaf arrayが格納されている。
次に、実施例4について説明する。実施例4は、実施例2、3よりも更にリーフノードを圧縮できる方式である。実施例4における内部データの構造を図13に示す。図13に示すように、実施例4の内部データは、既に説明したvector、leafvec、base0、base1に加えて、「A」で示すように、leaf maskとmasked leafが追加されたものである。記憶部12にはnode arrayとleaf arrayが格納されている。
leaf maskはvectorと同じビット長の0/1のビットからなるデータである。masked leafは、あるリーフノードのデータである。以下、leaf maskとmasked leafを用いる場合の演算部11の動作を説明する。
図14のフローチャートを参照して、実施例4における検索装置10の演算部11の動作例を説明する。図14は、実施例1、2とは異なる処理の部分を特に説明するためのものである。
ステップ201において、演算部11は、現在のチャンクのvectorにおける該当ビット(0番目から数えてv番目のビットとする)が0であることを検出することで、リーフノードに遷移することを検出する。
ステップ202では、演算部11は、leaf maskにおいて0番目から数えてv番目のビットが1であるかどうかを判定する。これが1である場合(ステップ202のYes)、masked leafの値をリーフデータの値として取得する(ステップ203)。
ステップ202において、v番目のビットが1でない場合(ステップ202のNo)、演算部11は、実施例2と同様にして、leafvecの0番目からv番目までの1の個数(bc)を算出し、(bc+base0−1)のIndexのリーフノードにアクセスして値を取得する(ステップ204)。
次に、図15を参照して、実施例4におけるleaf maskに関連するデータの作成方法を説明する。以下で説明するデータの作成は、検索装置10が行ってもよいし、他の装置(コンピュータ)が行ってもよい。以下では、データの作成を行う装置を作成装置と呼ぶ。作成装置は、検索装置10又は他の装置である。作成装置が他の装置である場合、データ作成後に、作成データを検索装置10の記憶部12に格納する。
まず、作成装置は、圧縮なしでleaf arrayを計算する。これにより、例えば4分木であれば、親の内部ノード毎に、例えば図5のLで示すように、Indexが連続するリーフノードのデータが作成される。
また、64分木であれば、親の内部ノード毎に、leaf arrayの項目数は最大で64になる。また、例えば16分木の例において、リーフ情報が3種類のA、B、C(例えば、名詞、動詞、助詞)であるとすると、リーフ情報が、図15(a)に示すとおり、例えばABAA BBBA BCBB CCCCのようにleaf array内に並ぶ。
次に、作成装置は、マスクされるリーフ情報を選ぶ。本例では、Bをマスクして省略することにする。一般には、連続する断片が現れる回数が最も多いものをマスクするのが有効であることから、作成装置は、連続する断片が現れる回数が最も多いBをマスクすると決定する。なお、「連続する断片」は、ABAにおけるBのように1つの場合を含む。マスクされたリーフの情報Bは、masked leafに格納する。
次に、作成装置は、マスクされるリーフ情報が現れるスロットを、leaf mask に保存する。マスクされるリーフ情報が現れるスロットとは、vectorにおける当該リーフに対応するビット位置に相当する。例えば、vectorが0010である場合に、左端を1番目として数えて2番目のビット0に対応するリーフをマスクする場合、leaf maskに、0100が保存される。
また、作成装置は、leaf arrayにおいて、マスクされるリーフ情報のスロットを、直前の値と同じにする。これにより、図15(a)に示すリーフ情報から、図15(b)に示すように、「leaf mask:0100 1110 1011 0000」が得られ、「leaf array: AAAA AAAA ACCC CCCC」が得られる。なお、本例は、big endianであるため、左端から数える。図15(b)において、下線部分がマスクされた部分であり、数える方向での直前の値(左の値)と同じ値になっている。
次に、リーフマスク無しの場合と同じように、連続する部分を圧縮する。これにより、図15(c)に示すように、「leafvec:1000 0000 0100 0000」となり、「leaf array:AC」となる。
上記の処理の結果、図15(d)に示すように、「leaf mask: 0100 1110 1011 0000」、「masked leaf:B」、「leaf vector:1000 0000 0100 0000」、「leaf array:AC」が得られる。
なお、参考までに、リーフマスク無しで圧縮した場合のleaf arrayは「ABABABCBC」となり、実施例4により高い圧縮効果が得られることがわかる。
実施例4では、マスク1つ(例:64bit)とリーフ1つが追加されるが、不連続であったいくつかのリーフを省略することができ、leaf arrayのさらなる圧縮が実現できる。これは、リーフ1つの大きさ(leaf arrayの1エントリのサイズ)が16バイトなど大きかった場合などに特に有効となる。
なお、実施例2、3、4は、リーフノードを圧縮する例を示しているが、同じデータを持つ内部ノードに関しても、リーフノードの場合と同じようにして、圧縮することが可能である。また、リーフノードの圧縮と内部ノードの圧縮の両方を行うこととしてもよい。
(実施の形態の効果)
以上、説明したように、本実施の形態では、木のデータ量を大幅に削減できることから、例えば汎用CPUのキャッシュ(例:L1、L2、L3キャッシュ)に検索対象データを格納して検索処理を実施でき、高速な検索処理を実現できる。
以上、説明したように、本実施の形態では、木のデータ量を大幅に削減できることから、例えば汎用CPUのキャッシュ(例:L1、L2、L3キャッシュ)に検索対象データを格納して検索処理を実施でき、高速な検索処理を実現できる。
また、木の各レベルで、ビット単位で部分木の有無を表現するため、メモリ効率が良い。特に、例として64分木を用いる場合、64ビットずつ部分木の有無(子配列)を表現するため、64−bit CPUでの処理効率が良いという特徴を持つ。
また、vector等において、1であるビットを数え、配列の中の該当する子に1ステップで飛べるため、高速処理を実現でき、メモリ効率も良い。また、1であるビットを数えるために、popcnt CPU instruction を使用でき、高速処理を実現できる。また、汎用的な多進木(Multiway trie)をベースにしているため、拡張性・柔軟性が高く、経路表検索に限らず、様々な検索に適用できる。
更に、実施例2〜4で説明したリーフ情報の圧縮を行うことで検索対象データの量を小さくでき、更なる高速化を実現できる。
(実施の形態のまとめ)
以上、説明したように、本実施の形態により、辞書データを格納した記憶手段と、入力文字列に基づき前記辞書データに対する検索処理を行う演算手段と、を備える検索装置であって、前記記憶手段に格納される前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、前記演算手段は、入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行することを特徴とする検索装置が提供される。
以上、説明したように、本実施の形態により、辞書データを格納した記憶手段と、入力文字列に基づき前記辞書データに対する検索処理を行う演算手段と、を備える検索装置であって、前記記憶手段に格納される前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、前記演算手段は、入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行することを特徴とする検索装置が提供される。
前記辞書データにおける各内部ノードは、遷移先の1つの内部ノードの格納位置を示す第1のベース情報、及び、遷移先の1つのリーフノードの格納位置を示す第2のベース情報を含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第1のベース情報を用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第2のベース情報を用いて当該遷移先のリーフノードにアクセスするように構成してもよい。
前記辞書データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納され、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第1のベース情報と、前記ビットベクトルにおける内部ノードを示すビットの数とを用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第2のベース情報と、前記ビットベクトルにおけるリーフノードを示すビットの数とを用いて当該遷移先のリーフノードにアクセスすることとしてもよい。
前記辞書データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、前記辞書データにおける各内部ノードは、圧縮前のリーフノードの値が変化した格納位置を示すビットを有するリーフベクトルを含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第2のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスすることとしてもよい。
前記演算手段は、前記ビットベクトルと前記リーフベクトルのうちの前記ビットベクトルを先に調べ、当該ビットベクトルのビットの値に基づき前記リーフベクトルを使用することとしてもよい。
前記辞書データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、前記辞書データにおける各内部ノードは、圧縮前のリーフノードの値が変化した格納位置を示すビットを有するマスクベクトルを含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第2のベース情報と、前記マスクベクトルでマスクした前記ビットベクトルにおけるリーフノードを示すビットの数とを用いて当該遷移先のリーフノードにアクセスするようにしてもよい。
前記辞書データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納されており、同じ値を持つ内部ノードは圧縮され、複数の内部ノードは、同じ値を持つ複数の内部ノードを含まず、前記辞書データにおける各内部ノードは、圧縮前の内部ノードの値が変化した格納位置を示すビットを有するマスクベクトルを含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第1のベース情報と、前記マスクベクトルでマスクした前記ビットベクトルにおける内部ノードを示すビットの数とを用いて当該遷移先の内部ノードにアクセスすることとしてもよい。
前記辞書データの各内部ノードについて、遷移先となるリーフノードにおける所定の値がマスクされ、当該マスクされた値が別の値に変更された後に、同じ値を持つリーフノードが圧縮されたことにより、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、前記リーフノード配列において、格納位置が連続して格納されており、前記辞書データにおける各内部ノードは、前記マスクされた所定の値と、当該所定の値を持つリーフベクトルの圧縮前の位置を示すビットを有するリーフマスクと、圧縮前のリーフノードの値が変化した格納位置を示すビットからなるリーフベクトルとを含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記ビットベクトルにおける当該ビットの位置と同じ位置に、前記リーフマスクにビットが立っているか否かを判定し、立っている場合に、前記所定の値を当該遷移先のリーフノードの値として取得し、立っていない場合に、前記第2のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスすることとしてもよい。
前記演算手段は、当該演算手段により構成されるCPUのpopcnt命令を用いて前記ビットの数を算出することとしてもよい。
また、前記演算手段と前記記憶手段は、64ビットCPU上で構成することとしてもよい。また、前記チャンクは、6ビット長であり、前記ビットベクトルは、64ビット長であることとしてもよい。
また、前記演算手段と前記記憶手段は、64ビットCPU上で構成し、前記チャンクは、6ビット長であり、前記ビットベクトルは、64ビット長であり、前記演算手段は、前記64ビットCPUのpopcnt命令を用いて前記ビットの数を算出し、前記遷移先のノードへのアクセスを、ベース情報からの、当該ビットの数に基づくオフセットを用いて行うこととしてもよい。
また、前記演算手段は、前記キーデータから前記所定ビット長よりも長いビット長のチャンクを取得し、当該チャンクを用いて探索を行うことにより、ダイレクトにリーフノードに到達するようにしてもよい。
また、本実施の形態により、コンピュータを、前記検索装置における各手段として機能させるためのプログラムを提供することもできる。また、本実施の形態により、前記辞書データを格納したコンピュータ読み取り可能な記録媒体を提供することもできる。
なお、上述した「記憶手段」は、記憶部、記憶回路、記憶デバイスのいずれかと置き換えてもよい。また、上述した「演算手段」は、演算部、演算回路、演算デバイスのいずれかと置き換えてもよい。
また、本実施の形態に係る検索方法を、入力文字列に基づき辞書データに対する検索処理を行う検索方法であって、前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、前記検索方法は、入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報の値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行するステップを有することを特徴とする検索方法として構成してもよい。
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
10、20 検索装置
11 演算部
12 記憶部
13 入力部
14 出力部
11 演算部
12 記憶部
13 入力部
14 出力部
Claims (10)
- 辞書データを格納した記憶手段と、
入力文字列に基づき前記辞書データに対する検索処理を行う演算手段と、を備える検索装置であって、
前記記憶手段に格納される前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、
前記演算手段は、
入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する
ことを特徴とする検索装置。 - 前記辞書データにおける各内部ノードは、遷移先の1つの内部ノードの格納位置を示す第1のベース情報、及び、遷移先の1つのリーフノードの格納位置を示す第2のベース情報を含み、
前記演算手段は、
前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第1のベース情報を用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第2のベース情報を用いて当該遷移先のリーフノードにアクセスする
ことを特徴とする請求項1に記載の検索装置。 - 前記辞書データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納され、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、
前記演算手段は、
前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第1のベース情報と、前記ビットベクトルにおける内部ノードを示すビットの数とを用いて当該遷移先の内部ノードにアクセスし、
遷移先がリーフノードである場合に、前記第2のベース情報と、前記ビットベクトルにおけるリーフノードを示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
ことを特徴とする請求項2に記載の検索装置。 - 前記辞書データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、
前記辞書データにおける各内部ノードは、圧縮前のリーフノードの値が変化した格納位置を示すビットを有するリーフベクトルを含み、
前記演算手段は、
前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第2のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
ことを特徴とする請求項2に記載の検索装置。 - 前記辞書データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、
前記辞書データにおける各内部ノードは、圧縮前のリーフノードの値が変化した格納位置を示すビットを有するマスクベクトルを含み、
前記演算手段は、
前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第2のベース情報と、前記マスクベクトルでマスクした前記ビットベクトルにおけるリーフノードを示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
ことを特徴とする請求項2に記載の検索装置。 - 前記辞書データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納されており、同じ値を持つ内部ノードは圧縮され、複数の内部ノードは、同じ値を持つ複数の内部ノードを含まず、
前記辞書データにおける各内部ノードは、圧縮前の内部ノードの値が変化した格納位置を示すビットを有するマスクベクトルを含み、
前記演算手段は、
前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第1のベース情報と、前記マスクベクトルでマスクした前記ビットベクトルにおける内部ノードを示すビットの数とを用いて当該遷移先の内部ノードにアクセスする
ことを特徴とする請求項2に記載の検索装置。 - 前記辞書データの各内部ノードについて、遷移先となるリーフノードにおける所定の値がマスクされ、当該マスクされた値が別の値に変更された後に、同じ値を持つリーフノードが圧縮されたことにより、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、前記リーフノード配列において、格納位置が連続して格納されており、
前記辞書データにおける各内部ノードは、前記マスクされた所定の値と、当該所定の値を持つリーフベクトルの圧縮前の位置を示すビットを有するリーフマスクと、圧縮前のリーフノードの値が変化した格納位置を示すビットからなるリーフベクトルとを含み、
前記演算手段は、
前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記ビットベクトルにおける当該ビットの位置と同じ位置に、前記リーフマスクにビットが立っているか否かを判定し、立っている場合に、前記所定の値を当該遷移先のリーフノードの値として取得し、立っていない場合に、前記第2のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
ことを特徴とする請求項2に記載の検索装置。 - コンピュータを、請求項1ないし7のうちいずれか1項に記載の前記検索装置における各手段として機能させるためのプログラム。
- 請求項1ないし7のうちいずれか1項に記載の前記辞書データを格納したコンピュータ読み取り可能な記録媒体。
- 入力文字列に基づき辞書データに対する検索処理を行う検索方法であって、
前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、
前記検索方法は、
入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報の値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行するステップを有する
ことを特徴とする検索方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2018123685A JP2020004132A (ja) | 2018-06-28 | 2018-06-28 | 検索装置、検索方法、プログラム、及び記録媒体 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2018123685A JP2020004132A (ja) | 2018-06-28 | 2018-06-28 | 検索装置、検索方法、プログラム、及び記録媒体 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2020004132A true JP2020004132A (ja) | 2020-01-09 |
Family
ID=69100022
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2018123685A Pending JP2020004132A (ja) | 2018-06-28 | 2018-06-28 | 検索装置、検索方法、プログラム、及び記録媒体 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2020004132A (ja) |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH09245045A (ja) * | 1996-03-14 | 1997-09-19 | Fuji Xerox Co Ltd | 鍵検索方法および装置 |
JP2004537921A (ja) * | 2001-07-31 | 2004-12-16 | ノース・キャロライナ・ステイト・ユニヴァーシティ | 高速パケット転送のための方法及びシステム |
JP2008299867A (ja) * | 2002-02-27 | 2008-12-11 | France Telecom | データ構造によるコンピュータ表現及びそれに関連する符号化/復号化方法 |
JP2009277164A (ja) * | 2008-05-18 | 2009-11-26 | S Grants Co Ltd | ビット列検索装置、検索方法及びプログラム |
JP2012150562A (ja) * | 2011-01-17 | 2012-08-09 | Nippon Telegr & Teleph Corp <Ntt> | N分木内部ノードの圧縮方法及び装置及びプログラム |
JP2016170526A (ja) * | 2015-03-11 | 2016-09-23 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | 検索装置、検索方法、プログラム、及び記録媒体 |
-
2018
- 2018-06-28 JP JP2018123685A patent/JP2020004132A/ja active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH09245045A (ja) * | 1996-03-14 | 1997-09-19 | Fuji Xerox Co Ltd | 鍵検索方法および装置 |
JP2004537921A (ja) * | 2001-07-31 | 2004-12-16 | ノース・キャロライナ・ステイト・ユニヴァーシティ | 高速パケット転送のための方法及びシステム |
JP2008299867A (ja) * | 2002-02-27 | 2008-12-11 | France Telecom | データ構造によるコンピュータ表現及びそれに関連する符号化/復号化方法 |
JP2009277164A (ja) * | 2008-05-18 | 2009-11-26 | S Grants Co Ltd | ビット列検索装置、検索方法及びプログラム |
JP2012150562A (ja) * | 2011-01-17 | 2012-08-09 | Nippon Telegr & Teleph Corp <Ntt> | N分木内部ノードの圧縮方法及び装置及びプログラム |
JP2016170526A (ja) * | 2015-03-11 | 2016-09-23 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | 検索装置、検索方法、プログラム、及び記録媒体 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5960863B1 (ja) | 検索装置、検索方法、プログラム、及び記録媒体 | |
US7756859B2 (en) | Multi-segment string search | |
JP5950285B2 (ja) | 予め決められた複数のビット幅のデータに対して操作を行う命令を使用してツリーの検索を行うための方法、並びに、当該命令を使用してツリーの検索を行うためのコンピュータ及びそのコンピュータ・プログラム | |
US20070174261A1 (en) | Database retrieval apparatus, retrieval method, storage medium, and progam | |
JP2005525625A (ja) | データ構造によるコンピュータ表現及びそれに関連する符号化/復号化方法 | |
CN110245002A (zh) | ***交互方法、装置、设备及存储介质 | |
JP6726690B2 (ja) | 基本データシーブを用いて無損失削減されたデータに対する多次元検索、コンテンツ連想的な取出し、ならびにキーワードベースの検索および取出しの実行 | |
US10884982B2 (en) | Hash-based mount point lookup in virtual file systems | |
CN117763077A (zh) | 数据查询方法及装置 | |
CN101211346A (zh) | 一种优化存储器性能的方法 | |
JP2020004132A (ja) | 検索装置、検索方法、プログラム、及び記録媒体 | |
CN113495901B (zh) | 一种面向可变长数据块的快速检索方法 | |
US11921690B2 (en) | Custom object paths for object storage management | |
KR102146625B1 (ko) | 오토마타 기반 증분적 중위 확률 계산 장치 및 방법 | |
Bahrambeigy et al. | Bloom-Bird: A scalable open source router based on Bloom filter | |
US20160098411A1 (en) | Querying input data | |
JP6205463B2 (ja) | 検索装置、検索方法、プログラム、及び記録媒体 | |
CN115801020B (zh) | 确定有限状态自动机压缩方法、匹配方法、设备及介质 | |
KR102190285B1 (ko) | 공간효율적인 순위다중패턴매칭 알고리즘 | |
KR102158317B1 (ko) | 2차 q-그램에 대한 핑거프린트를 이용한 순위패턴매칭 알고리즘 | |
US20030187843A1 (en) | Method and system for searching for a list of values matching a user defined search expression | |
Campos et al. | A cache-aware data structure for representing boolean polynomials | |
Stefanakis | Design and implementation of a range trie for address lookup | |
CN117938173A (zh) | 告警数据压缩方法及装置 | |
CN115374769A (zh) | 词语的对齐方法、装置、电子设备及介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20210120 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20211201 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20211207 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20220531 |