JP2021517306A - データベースにおけるトライデータ構造の有効使用 - Google Patents

データベースにおけるトライデータ構造の有効使用 Download PDF

Info

Publication number
JP2021517306A
JP2021517306A JP2020549557A JP2020549557A JP2021517306A JP 2021517306 A JP2021517306 A JP 2021517306A JP 2020549557 A JP2020549557 A JP 2020549557A JP 2020549557 A JP2020549557 A JP 2020549557A JP 2021517306 A JP2021517306 A JP 2021517306A
Authority
JP
Japan
Prior art keywords
try
node
result
key
input
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.)
Granted
Application number
JP2020549557A
Other languages
English (en)
Other versions
JP7364581B2 (ja
Inventor
バウアー，ウォルター
Original Assignee
センシェア ゲーエムベーハー
センシェア ゲーエムベーハー
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by センシェア ゲーエムベーハー, センシェア ゲーエムベーハー filed Critical センシェア ゲーエムベーハー
Publication of JP2021517306A publication Critical patent/JP2021517306A/ja
Application granted granted Critical
Publication of JP7364581B2 publication Critical patent/JP7364581B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24553—Query execution of query operations
    • G06F16/24558—Binary matching operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2237—Vectors, bitmaps or matrices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2246—Trees, e.g. B+trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24553—Query execution of query operations
    • G06F16/24561—Intermediate data storage techniques for performance improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/10—Complex mathematical operations
    • G06F17/11—Complex mathematical operations for solving equations, e.g. nonlinear equations, general mathematical optimization problems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30029—Logical and Boolean instructions, e.g. XOR, NOT

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • Mathematical Physics (AREA)
  • Computational Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Operations Research (AREA)
  • Algebra (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本発明は、データベース又は情報検索システムに記憶されたキーの１つ又は複数の集合に対する論理積、論理和、差分、及び排他的論理和等の演算を含むデータベース又は情報検索システムにおいてクエリを実行する時間効率的な方法を提供する。新規の実行モデルでは、全てのデータソース及び演算子はトライであり、高次集合演算の入力トライでは、オンデマンドで評価される低次集合演算の出力であることができる。２つ以上の入力トライは、各集合演算に従って結合されて、各結果トライのノードに関連付けられたキーの集合を取得する。ビットマップに基づくトライの実装の物理的代数は、集合演算の論理的代数に直接対応し、ビット単位ブール演算による効率的な実装を可能にする。

Description

発明の技術分野
本発明は、一般的には、データベース及び情報検索システムにおけるトライデータ構造の有効使用及び高性能を有するそのようなシステムへの問い合わせに関する。
発明の背景
データベース及び情報検索システムは、構造化情報及び非構造化情報の処理に使用されている。一般に、構造化データはデータベース（例えば、関係データベース）の領域であり、一方、非構造化情報は情報検索システム（例えば、全文サーチ）の領域である。データベースエンジンは、データを格納し検索する、データベース管理システム（又は他のアプリケーション）の部分である。情報検索システムでは、この機能はサーチエンジンによって実行される。
索引付けは、データベース又は情報検索システムの性能改善に使用される。クエリ用のインデックス（「キー」によるルックアップ又はアクセスとも呼ばれる）なしでは、結果を届けるためにデータベース全体又は情報ベース全体をスキャンする必要があり、遅すぎて有用ではない。
データベースインデックスは、書籍により提供されるインデックスと同等である：特定のキーワードを見つけるために、ユーザは書籍全体を読む必要はなく、その代わり、インデックス中の特定のキーワードを調べることができ、インデックスは、そのキーワードが関連するページへの参照を含む。これはサーチエンジンの背後にある基本原理でもある：任意の所与のサーチ語について、サーチエンジンは、適切なインデックスを調べることによりサーチ語を含むドキュメントを素早く見つける。情報検索システムの一例のクエリは全文サーチであり、その言葉（単語）はキーとして格納され、ドキュメントＩＤもキーとして格納される（例えば、以下の図７０の説明を参照）。例えば、「林檎（apple）」という言葉を１０及び３３のＩＤを有するドキュメントで見つけることができる場合、２つの複合キー（「林檎」、１０）及び（「林檎」、３３）がインデックスに格納される。これらの言葉はキーとして格納され、それにより、例えば、「林檎」及び「梨（pear）」のサーチを行うことができる。
索引付けの従来の手法は、いわゆるＢツリーインデックスを使用するものであった。１９７２年にR. Bayer及びE. McCreightによって発明されたＢツリーはなお、この目的で使用される主要なデータ構造である。しかしながら、Ｂツリーインデックスには主な欠点がある。例えば、データにアクセスする時間は、データ量に伴って対数的に増大する。データサイズが１桁増大すると、アクセス時間は概ね２倍になり、データサイズが２桁増大すると、アクセス時間は３倍になる等々である。更に、Ｂツリーインデックスは、いわゆる低基数基準の場合、クエリ性能を改善するのに役立たない。例えば、「男性（male）」、「女性（female）」、及び「未知（unknown）」という値を有する属性「性別（gender）」へのインデックス作成は、全てのレコードのスキャン及びフィルタリングと比較して性能を改善しない。最後に、多次元クエリ、すなわち、複数の基準／属性を含むクエリは、効率的に扱うことが難しく、その理由は、Ｂツリーインデックスを効率的に結合する（組み合わせる）ことができないためである。
M. Boehm et al.,“Efficient In-Memory Indexing with Generalized Prefix-Trees”, in: T. Haerder et al.(eds.), BTW. LNI, vol. 180, pp. 227-246, Kaiserslautern, Germany(2011)は、「トライ」又はトライデータ構造を使用することによってデータベースインデックスを格納し処理することを示唆している。トライとはツリーデータ構造であり、「基数木」又は「プレフィックス木」と呼ばれることもある。トライ（trie）という用語は「reTRIEval（検索）」という言葉に由来する。ノード内部にキーを格納する代わりに、トライのノードへのパスは、関連付けられたキーを定義し、ここで、ルートは空キーを示す。より具体的には、各ノードには、値（本明細書では「ノードの値」と呼ばれることもある）を親ノードからのポインタにより示し得るキー部分が関連付けられる。値は、可能な値の予め定義された英字から選択される。ルートノードからトライ内の別のノード、例えば、リーフノードへのパスは、ノードに関連付けられたキー（又は内部ノード、すなわち、リーフノードではないノードである場合、「キープレフィックス」）を定義し、キーは、パス上のノードに関連付けられたキー部分を連結したものである。トライの時間複雑性は、トライ内に存在するキーの量に依存せず、キーの長さに依存する。
空間効率的なトライデータ構造
トライデータ構造を実施する一方法は、ノードをメモリに別個に格納することであり、各ノードは、ノードがリーフノードであるか否かを示すノードタイプ情報、その子ノードへのポインタの配列（少なくともノードがリーフノードではない場合）、及びリーフノードの場合、恐らくはペイロード、例えば、キーに関連付けられた値を含む。この手法を使用すると、ノードからノードへのトラバースは一定時間の動作であり、その理由は、各子ポインタが、各キー部分を表す配列エントリに対応するためである。しかしながら、少数のみの子ノードを有するノードの場合、対応する配列が多くの空エントリを含み格納するため、メモリ使用は非常に非効率的であり得る。これは、より大きな英字が使用される場合、特に当てはまり、その理由は、大量の子ポインタを格納する必要があるためである。
メモリ空間をより効率的に使用するために、空ポインタの格納を回避するトライデータ構造の実施が開発された。そのような解決策の本質は、可能な全てのポインタを含む配列の代わりに、非空ポインタのみのリストをそれぞれのキー部分値と共に格納することにある。この手法の欠点は、ノードからノードにトラバースするために、各親ノード内のリストをスキャンする必要があるか、又はリストがキー部分の値により順序付けられる場合、バイナリサーチを実行する必要があることである。加えて、キー部分の特定の値の特定のポインタを識別する必要があるため、キー部分の関連値も格納する必要があり、メモリ空間効率を下げる。
トライデータ構造をコンパクト形式で格納する他の方法も開発されている。例えば、Ph. Bagwell,“Fast And Space Efficient Trie Searches”, Technical Report, EPFL, Switzerland(2000)には、ビットマップに基づくトライデータ構造が開示されている。そのようなトライデータ構造はビットマップを使用して、親ノードの全ての非空ポインタを記す。特に、ビットマップ内の設定ビットは有効（非空）分岐を記す。各親ノードも１つ又は複数のポインタを含み、各ポインタには、ビットマップ内で設定されたビットが関連付けられ、各ポインタは親ノードの子ノードを指す。子ノードのキー部分の値は、子ノードを指すポインタに値が関連付けられた親ノードに含まれるビットマップ内の（設定された）ビットの値により決まる。
ポインタは所定の長さ又はサイズを有し、ビットがビットマップにおいて設定されるのと同順又は逆順に格納することができる。ビットマップにおいて設定されたビットに関連付けられたポインタのメモリアドレスは、ビットマップにおいて設定された最下位ビットの数に基づいて容易に計算することができる。各ポインタ、ひいては次の子ノードのこの特定は、単純なビット演算及び設定ビット数を特定するＣＴＰＯＰ（ポピュレーションカウント）演算を使用して、設定される最下位ビットの量を効率的に計算することができるため、高速である。例えば、そのようなポピュレーションカウント方法は、Javaプログラミング言語で利用可能であり、「Ｌｏｎｇ．ｂｉｔＣｏｕｎｔ（）」と呼ばれる。ＣＴＰＯＰ自体は、「ビットハック」を使用してかなり効率的に実施することができ、多くの近代のＣＰＵは実に、固有命令としてＣＴＰＯＰを提供している。
ビットマップは、有効分岐が関連付けられた英字値を示すため、格納する必要があるのは既存（非空）のポインタのみである。したがって、メモリ使用を低減することができる。他方、特定のポインタのアドレスは、ビットマップ内の設定ビットの中での関連ビットのアラン句に基づいて一定時間で容易に特定することができる。最後に、子ノードへのポインタに関連付けられたビットの値は、子ノードのキー部分値を効率的に表す。したがって、ビットマップに基づくトライデータ構造は、図４に示されるリストに基づくトライデータ構造と比較して、メモリ割り振りを取り扱い、トライを処理するより効率的な手法を提供する。
しかしながら、本発明者は、多くの用途状況で、メモリ空間の使用が非効率的であることを発見した。これは、トライが疎に存在し、及び／又は空間を無駄にする、それぞれ１つの子ポインタを有するノード連鎖に劣化する場合、特に当てはまる。したがって、データベースアプリケーション又は情報検索システムによって使用されるトライの格納に必要なメモリ空間を更に低減し、特に、トライをトラバースするのに必要な速度をあまり上げずに、トライの実施に必要なポインタ及び／又はビットマップの格納に必要なメモリ量を低減することが望ましい。
キー符号化
通常、従来技術で使用されるトライの英字の基数は、ユニコードのような大きな英字からの文字に対応できるようにするために、比較的大きく、例えば、２５６である。２５６個の異なる値を用いると、８ビット（２８＝２５６）、すなわち１バイトを符号化することができる。しかしながら、トライが上述したようにビットマップを使用する場合、ビットマップの幅は、英字の基数に伴って増大する。例えば、基数が２５６の英字は、２５６ビットのビットマップサイズを必要とする。そのような大きなビットマップは特に、トライが疎に存在する場合、空間非効率的であり得、その理由は、２５６ビットをあらゆるノードに割り振る必要があるが、それらの一部しか使用されないことがあるためである。更に、近代のコンピュータのレジスタのビット幅は通常、わずか６４ビットであるため、例えば、２５６ビットを有する大きなビットマップは、時間効率的に処理することができない。仮にトライが更に大きな英字の文字に適応するので、効率問題は更に大きくなる。したがって、従来技術において文字を空間効率的且つ時間効率的に格納することができる英字の基数は制限される。
更に、従来技術では、トライは、予め定義されたデータ型の格納のみに使用され、データ型は通常、数字又は文字のような原始的なデータ型に制限される。そのような使用は、トライに格納することができるキーに制約を課し、トライデータ構造をデータベース又は情報検索システムインデックスの格納に適さないようにする恐れがある。
したがって、本発明の更なる目的は、柔軟に使用することができるトライ及び／又は柔軟にトライを使用する方法を提供することである。実際に、本発明の目的は、汎用データベース又は情報検索システムインデックスとして使用することができるトライデータ構造及び汎用データベース又は情報検索システムインデックスとしてトライデータ構造を使用する方法を提供することである。更に、本発明の目的は、２つ以上のデータ項目を含むデータベースクエリを時間効率的に処理することができるようにデータベースインデックスのキーを格納するトライを提供することである。
クエリ実行
データベースで実行されるクエリは一般に、論理代数（例えば、ＳＱＬ）で表現される。それらの実行のために、クエリは物理代数：物理クエリ実行プラン（ＱＥＰ：physical query execution plan）に変換される必要がある。クエリは書き換えられ、最適化され、クエリ実行エンジン（ＱＥＥ）がデータベースに対する先行ステップにより生成されたＱＥＰを実行するようなＱＥＰが準備される。
処理のために、ＱＥＰは一般に、クエリ結果の生成を目的とした１組の関連演算子を含む。大半のデータベースはＱＥＰをツリーで表し、ツリーでは、ノードは演算子であり、リーフはデータソースであり、エッジは生産者−消費者形態での演算子間の関係である。
多くのデータベースエンジンは、ＱＥＥ内の反復子ベースの実行モデルに従い、このモデルでは、演算子は以下のメソッドを実施する：Ｏｐｅｎ（データの生成に向けて演算子を準備する）、Ｎｅｘｔ（演算子消費者の需要下で新しいデータユニットを生成する）、Ｃｌｏｓｅ（実行を終了させ、リソースを解放する）。ルート演算子から始まるこれらの演算の１つの呼び出しは、データソース（及びリーフ）に達するまで、演算子の子に伝搬する等々である。このようにして、制御は消費者から生産者に流れ落ち、データは、クエリ実行プラン演算子ツリー内で生産者から消費者まで上に流れる。そのような手法は、各演算子がグローバル知識を必要としないため、クリーンな設計及びカプセル化を提供する。
しかしながら、そのような実行モデルには深刻な欠点がある。まず第１に、各演算子はグローバル知識を有さないため、グローバルの視点から有益な最適化を適用することができない。加えて、クエリプランは静的であるため、クエリ実行中に適応的最適化を適用することは困難であることが分かり得る。その結果、良好なＱＥＰの作成には、複雑なアルゴリズムを含むクエリオプティマイザに強く依存する。そして最後に、反復子手法は、演算子呼び出し毎にたった１つのデータユニット、例えばレコードしか送出しない。この手法は、それら自体が小さな結果集合を返す大きなサブ結果集合を結合する演算子には非効率的である。
これらの欠点の１つの一例として、データベースに対して実行すべきクエリが、ＡがレコードＩＤの短いリスト、例えば（１，２，…，１０）を返すが、Ｂ及びＣが長いリスト、例えば（１，２，…，１０，０００）及び（２０，０００，…，５０，０００）を返す「Ａ ｉｎｔｅｒｓｅｃｔ（Ｂ ｕｎｉｏｎ Ｃ）」等の表現である場合。クエリオプティマイザが予測機能を有さず、実行前にクエリを（Ａ ｉｎｔｅｒｓｅｃｔ Ｂ）ｕｎｉｏｎ（Ａ ｉｎｔｅｒｓｅｃｔ Ｃ）に書き換えない場合、クエリはかなり非効率的である。
したがって、論理積（ＡＮＤ）、論理和（ＯＲ）、及び否定論理積（ＡＮＤ ＮＯＴ）等の演算を含むデータベースクエリ又は情報検索システムクエリをデータベース若しくは情報検索システムに格納された２つ以上の組のキー又はデータベース若しくは情報検索システムの入力若しくは結果キーの集合に対して実行する、より時間効率的な情報を有することが望ましい。
更に、従来技術によるデータベースの範囲クエリ性能は、インデックスのサイズ（データベースに含まれ、インデックスにより索引付けられるレコード数）に伴って低減する。したがって、インデックスサイズの増大に伴って上手くスケーリングされた、範囲クエリを実行するより時間効率的な方法を有することが望ましい。
これらの目的の１つ又は複数は、独立クレームの趣旨により達成される。好ましい実施形態は従属クレームの趣旨である。
本発明は、Ｂツリー及び導関数がなお主要戦略であるデータベースアプリケーションの索引付け解決策及び通常、逆インデックスが使用される情報検索アプリケーションの索引付け解決策を提供する。逆インデックスとは、言葉が、その言葉を含むドキュメントを列挙するインデックスである。トライはレベル毎に処理されるため、本発明は、階層トライ構造を利用して、遅延評価を可能にすることができる。したがって、本発明は、第１レベルのトライを連想配列として使用して、逆インデックスを実施することができ、ここで、言葉はトライ内に格納されたキーである。第２レベル（すなわち、連想配列のリーフノードとして）において、本発明はトライを集合として使用して、ドキュメントのリスト（すなわち、ＩＤの集合）を実施することができる。したがって、本発明では、Ｂツリー及び逆インデックスを１つの汎用解決策で置換することができ、したがって、この１つの汎用解決策を「コンフルエンスインデックス（confluence index）」と呼称することができる。
本発明のインデックスデータ構造及びクエリ処理モデルは、ビット単位のトライに基づき、従来技術によるインデックス構造に取って代わる潜在性を有する：データ構造は頻繁に更新することができ、低基数及び高基数を有するキーに対して機能し、圧縮／圧縮解除（データ構造はコンパクトであり、又は幾つかの場合、簡潔でさえある）なしで空間効率的である。加えて、トライに基づくため、キー演算による挿入、更新、削除、及びクエリにＯ（｜Ｍ｜）一定時間複雑性を継承する（｜Ｍ｜はキーの長さ）。これは、ツリーに基づく手法にとって通常のＯ（ｌｏｇｎ）複雑性よりもよい（ｎはインデックス内のキーの数である）。そして、本発明のインデックスデータ構造及びクエリ処理モデルは、データベースの充填から独立したクエリ時間を提供することができる。好ましい実施形態では、クエリ処理での設定演算子の結果は、トライとして「見える」。これにより、機能構成及び遅延評価が可能になる。副次的影響として、物理代数は論理代数にそのまま対応し、クエリオプティマイザで通常行われる所与のクエリに適した物理的実行プランを作成するタスクを簡易化する。本発明の第１の実施形態は、電子データベースアプリケーション又は情報検索システムで使用されるトライであり、トライは１つ又は複数のノードを含み、２つ以上の子ノードを有する、トライに含まれる親ノード、好ましくは各親ノードは、ビットマップ及び１つ又は複数のポインタを含み、各ポインタにはビットマップにおいて設定されたビットが関連付けられ、各ポインタは親ノードの子ノードを指す。トライは、１つのみの子ノードを有する、トライに含まれる親ノード、好ましくは、親ノードは、子ノードへのポインタを含まず、及び／又は子ノードは、メモリにおいて、親ノードに相対して予め定義された位置に格納されることを特徴とする。
第２の実施形態によれば、第１の実施形態において、１つのみの子ノードを有する親ノードの子ノードは、メモリにおいて、親ノードの直後の位置に格納される。
第３の実施形態によれば、第１又は第２の実施形態において、ノード、好ましくは各子ノードには、キー部分が関連付けられ、トライ内のルートノードから別のノード、特にリーフノードへのパスがキーを定義し、キーは、パス内のノードに関連付けられたキー部分を連結したものである。
末端最適化
本発明の第４の実施形態は、電子データベースアプリケーション又は情報検索システムで使用されるトライであり、トライは１つ又は複数のノードを含み、２つ以上の子ノードを有する、トライに含まれる親ノード、好ましくは少なくとも各親ノードはビットマップを含み、ノード、好ましくは各子ノードには、キー部分が関連付けられ、親が２つ以上の子ノードを有する、子ノード、好ましくは少なくとも各子ノードのキー部分の値は、子ノードが関連付けられたビットを有する親ノードに含まれるビットマップ内の（設定）ビットの値によって決まる。トライは、１つのみの子ノードを有し、全ての子孫ノードが多くとも１つの子ノードを有するノード、好ましくは各ノードは、末端分岐ノードと記され、末端分岐ノード、好ましくは各末端分岐ノードの子孫ノード、好ましくは各子孫ノードに関連付けられたキー部分の値は、子孫ノードの親ノードに含まれるビットマップ内の（設定）ビットの値によって決まらないことを特徴とする。
第５の実施形態によれば、第４の実施形態において、末端分岐ノードは２つ以上の子孫ノードを有する。
第６の実施形態によれば、第４又は第５の実施形態において、末端分岐ノードの親は２つ以上の子ノードを有する。
第７の実施形態によれば、第４〜第６の実施形態において、末端分岐ノードとしての記しは、ビットが設定されていないビットマップである。
第８の実施形態によれば、第７の実施形態において、末端分岐ノードのビットマップは、２つ以上の子ノードを有する親ノードに含まれるビットマップと同じ長さ又はフォーマットを有する。
第９の実施形態によれば、第４〜第８の実施形態の何れか１つにおいて、トライに含まれる末端分岐ノード、好ましくは各末端分岐ノード及び／又は末端分岐ノードの子孫ノード、好ましくは各子孫ノードは、子ノードへのポインタを含まず、及び／又は子ノードは、メモリにおいて、親ノードに相対して予め定義された位置に、好ましくは、メモリにおいて親ノードの直後の位置に格納される。
第１０の実施形態によれば、第４〜第９の実施形態の何れか１つにおいて、末端分岐ノード、好ましくは各末端分岐ノードの子孫ノード、好ましく各子孫ノードに関連付けられたキー部分の値は、子孫ノードの親ノードに含まれる。
第１１の実施形態によれば、第４〜第１０の実施形態の何れか１つにおいて、末端分岐ノード、好ましくは各末端分岐ノードの子孫ノード、好ましくは全ての子孫ノードに関連付けられたキー部分の値は、末端分岐ノード後に連続して格納される。
第１２の実施形態によれば、第４〜第１１の実施形態の何れか１つにおいて、末端分岐ノード、好ましくは各末端分岐ノードの子孫ノード、好ましくは各子孫ノードに関連付けられたキー部分の値の符号化は、２つ以上の子ノードを有する親ノードに含まれるビットマップよりも、必要とするメモリ空間が少ない。
第１３の実施形態によれば、第４〜第１２の実施形態の何れか１つにおいて、末端分岐ノード、好ましくは各末端分岐ノードの子孫ノード、好ましくは各子孫ノードに関連付けられたキー部分の値は、二進数として符号化される。
第１４の実施形態によれば、第４〜第１３の実施形態の何れか１つにおいて、２つ以上の子ノードを有する親ノード、好ましくは各親ノードに含まれるビットマップは、３２ビット、６４ビット、１２８ビット、又は２５６ビットを有し、末端分岐ノード、好ましくは各末端分岐ノードの子孫ノード、好ましくは各子孫ノードに関連付けられたキー部分は、５ビット、６ビット、７ビット、又は８ビットによりそれぞれ符号化される。
第１５の実施形態によれば、第４〜第１４の実施形態の何れか１つにおいて、末端分岐ノード、好ましくは各末端分岐ノードの子孫ノード、好ましくは各子孫ノードに関連付けられたキー部分の値は、整数値として符号化される。
第１６の実施形態によれば、第４〜第１４の実施形態の何れか１つにおいて、親ノードである末端分岐ノードの子孫ノード、好ましくは、親ノードである各子孫ノードは、設定ビットが子ノードに関連付けられたキー部分の値を決めるビットマップを含まない。
第１７の実施形態によれば、第４〜第１６の実施形態の何れか１つにおいて、２つ以上の子ノードを有する、トライに含まれる親ノード、好ましくは、少なくとも各親ノードは、１つ又は複数のポインタを含み、各ポインタには、親ノードに含まれるビットマップに設定されたビットが関連付けられ、各ポインタは親ノードの子ノードを指す。
第１８の実施形態によれば、第４〜第１７の実施形態の何れか１つにおいて、トライは第１又は第２の実施形態によるトライである。
ビットマップ圧縮
本発明の第１９の実施形態は、電子データベースアプリケーション又は情報検索システムで使用されるトライであり、トライは１つ又は複数のノードを含み、２つ以上の子ノードを有するノード、好ましくは少なくとも各親ノードは、論理ビットマップの形態のビットマップ及び幾つかのポインタを含み、各ポインタには論理ビットマップにおいて設定されたビットが関連付けられ、各ポインタはノードの子ノードを指す。トライは、論理ビットマップが複数のセクションに分割され、ヘッダビットマップ及び幾つかのコンテンツビットマップにより符号化され、各セクションには、ヘッダビットマップ内のビットが関連付けられ、１つ又は複数のビットが設定された論理ビットマップの各セクションについて、ヘッダビットマップにおいて、セクションに関連付けられたビットは設定され、セクションはコンテンツビットマップとして格納されることを特徴とする。
第２０の実施形態によれば、第１９の実施形態において、ビットが設定されていない論理ビットマップの各セクションについて、ヘッダビットマップにおいて、セクションに関連付けられたビットは設定されず、セクションはコンテンツビットマップとして格納されない。
第２１の実施形態によれば、第１９又は第２０の実施形態の何れかにおいて、セクションのそれぞれはコヒーレントである。
第２２の実施形態によれば、第１９〜第２１の実施形態の何れかにおいて、全てのセクションは同じサイズを有する。
第２３の実施形態によれば、第２２の実施形態において、セクションのサイズは１バイトである。
第２４の実施形態によれば、第１９〜第２３の実施形態の何れか１つにおいて、コンテンツビットマップとして記憶されるセクションの量は、ヘッダビットマップにおいて設定されたビット数に等しい。
第２５の実施形態によれば、第１９〜第２４の実施形態の何れか１つにおいて、ヘッダビットマップのサイズは１バイトである。
第２６の実施形態によれば、第１９〜第２５の実施形態の何れか１つにおいて、コンテンツビットマップは、メモリにおいてヘッダビットマップに相対して予め定義された位置に格納される。
第２７の実施形態によれば、第１９〜第２６の実施形態の何れか１つにおいて、論理ビットマップのコンテンツビットマップは、配列、リスト、又は連続した物理若しくは仮想メモリロケーションに格納される。
第２８の実施形態によれば、第１９〜第２７の実施形態の何れか１つにおいて、コンテンツビットマップは、コンテンツビットマップのセクションに関連付けられた設定ビットがヘッダビットマップに配置される順と同順又は逆順で格納される。
第２９の実施形態によれば、第１９〜第２８の実施形態の何れか１つにおいて、論理ビットマップの全てのコンテンツビットマップ内のあるコンテンツビットマップのランクは、ヘッダビットマップ内の全ての設定ビット内の、コンテンツビットマップのセクションに関連付けられた設定ビットのランクに対応する。
第３０の実施形態によれば、第１９〜第２９の実施形態の何れか１つにおいて、ノードに含まれるポインタ、好ましくはノードの各ポインタ及び／又はリーフノードではない各ノードのポインタは、第１９〜第２９の実施形態の何れか１つにおける論理ビットマップに定義された符号化方法で符号化される。
第３１の実施形態によれば、第１９〜第３０の実施形態の何れか１つにおいて、トライは第１〜第１８の実施形態の何れか１つにおけるトライである。
第３２の実施形態によれば、第１９〜第３１の実施形態の何れか１つにおいて、ノード、好ましくは各子ノードにはキー部分が関連付けられ、ルートノードからトライ内の別のノード、特にリーフノードへのパスはキーを定義し、キーは、パス内のノードに関連付けられたキー部分を連結したものである。
制御情報を含むキー
本発明の第３３の実施形態は、電子データベースアプリケーション又は情報検索システムで使用されるトライであり、トライは１つ又は複数のノードを含み、ノード、好ましく各子ノードにはキー部分が関連付けられ、ルートノードからトライ内の別のノード、特にリーフノードへのパスはキーを定義し、キーは、パス内のノードに関連付けられたキー部分を連結したものである。トライは、キーが制御情報及びコンテンツ情報を含むことを特徴とする。
第３４の実施形態によれば、第３３の実施形態において、キーは、コンテンツ情報を含む１つ又は複数のキー部を含み、キー部のそれぞれについて、制御情報は、キー部に含まれるコンテンツ情報のデータ型を指定するデータ型情報要素を含む。
第３５の実施形態によれば、第３４の実施形態において、キー部、好ましくは各キー部は、キー部に含まれるコンテンツ情報のデータ型を指定するデータ型情報要素を含む。
第３６の実施形態によれば、第３５の実施形態において、データ型情報要素は、好ましくはコンテンツ情報要素前に、コンテンツ情報要素により配置される。
第３７の実施形態によれば、第３４の実施形態において、データ型情報要素は一緒に配置され、好ましくは、データ型が指定されるコンテンツ情報要素と同順又は逆順で配置される。
第３８の実施形態によれば、第３７の実施形態において、制御情報は、キーにおいてコンテンツ情報前に配置される。
第３９の実施形態によれば、第３４〜第３８の実施形態の何れか１つにおいて、キーは、異なるデータ型のコンテンツ情報を含む２つ以上のキー部を含む。
第４０の実施形態によれば、第３４〜第３９の実施形態の何れか１つにおいて、データ型の少なくとも１つは、固定サイズのデータ型である。
第４１の実施形態によれば、第４０の実施形態において、固定サイズのデータ型は整数、長整数、倍精度浮動小数点、又は時刻／日付けプリミティブである。
第４２の実施形態によれば、第３４〜第４１の実施形態の何れか１つにおいて、データ型の少なくとも１つは、可変サイズのデータ型である。
第４３の実施形態によれば、第４２の実施形態において、可変サイズのデータ型は、文字列、好ましくはユニコード文字列、又は可変精度整数である。
第４４の実施形態によれば、第３４〜第４３の実施形態の何れか１つにおいて、キー部の情報は、２つ以上のキー部分に含まれる。
第４５の実施形態によれば、第３４〜第４４の実施形態の何れか１つにおいて、キー部に含まれるコンテンツ情報のデータ型は、可変サイズのデータ型であり、コンテンツ情報要素の終わりは、特定のシンボルにより又はキー部を含むキー部分の特定の１つ内の特定のビットにより記される。
第４６の実施形態によれば、第３４〜第４５の実施形態の何れか１つにおいて、制御情報は、最後のキー部を識別する情報を含む。
第４７の実施形態によれば、第３３〜第４６の実施形態の何れか１つにおいて、制御情報は、トライが動的集合の格納に使用されるか、それとも連想配列の格納に使用されるかについての情報を含む。
第４８の実施形態によれば、第３３〜第４７の実施形態の何れか１つにおいて、トライは、第１〜第３２の何れか１つによるトライである。
第４９の実施形態によれば、第３３〜第４８の実施形態の何れか１つにおいて、２つ以上の子ノードを有するノード、好ましくは少なくとも各親ノードは、ビットマップ及び幾つかのポインタを含み、各ポインタには、ビットマップにおいて設定されたビットが関連付けられ、各ポインタはノードの子ノードを指す。
インタリーブ多項目キー
本発明の第５０の実施形態は、電子データベースアプリケーション又は情報検索システムで使用されるトライであり、トライは１つ又は複数のノードを含み、ノード、好ましくは各子ノードにはキー部分が関連付けられ、トライ内のルートノードから別のノード、特にリーフノードへのパスが、ノードが関連付けられたキーを定義し、キーは、パス上のノードに関連付けられたキー部分を連結したものである。トライは、２つ以上のデータ項目はキーにおいて符号化され、データ項目の最後における１つ又は２つ、好ましくは各データ項目は、２つ以上の構成要素からなり、キーは２つ以上の連続セクションを含み、セクションの少なくとも１つ又は２つ、好ましくは各セクションは、キーに符号化されたデータ項目の２つ以上の構成要素を含むことを特徴とする。
第５１の実施形態によれば、第５０の実施形態において、キーのセクション、好ましくは各セクションは、キーに符号化されたデータ項目のそれぞれから少なくとも及び／又は多くとも１つの構成要素を含む。
第５２の実施形態によれば、第５０又は第５１の実施形態の何れか１つにおいて、キーの２つ以上、好ましくは全てのセクションについて、異なるデータ項目に属する構成要素は、セクション内で同じ順序で並べられる。
第５３の実施形態によれば、第５０〜第５２の実施形態の何れか１つにおいて、データ項目の構成要素を含むセクションの順序は、データ項目内の構成要素の順序に対応する。
第５４の実施形態によれば、第５０〜第５３の実施形態の何れか１つにおいて、子ノード、好ましくは子ノードのそれぞれに関連付けられたキー部分は、データ項目の構成要素の一部に対応する。
第５５の実施形態によれば、第５０〜第５３の実施形態の何れか１つにおいて、子ノード、好ましくは子ノードのそれぞれに関連付けられたキー部分は、データ項目の１つの構成要素に対応し、及び／又はデータ項目、好ましくは各データ項目の構成要素、好ましくは各構成要素は、トライの１つの子ノードに関連付けられたキー部分に対応する。
第５６の実施形態によれば、第５０〜第５３の実施形態の何れか１つにおいて、子ノード、好ましくは子ノードのそれぞれに関連付けられたキー部分は、データ項目の２つ以上の構成要素に対応する。
第５７の実施形態によれば、第５０〜第５６の実施形態の何れか１つにおいて、キーのデータ項目の２つ以上、好ましくは全ては、同じ数の構成要素を有する。
データ項目及びその構成要素のタイプ
第５８の実施形態によれば、第５０〜第５７の実施形態の何れか１つにおいて、２つ以上のデータ項目はジオロケーションデータを表す。
第５９の実施形態によれば、第５０〜第５８の実施形態の何れか１つにおいて、データ項目は、経度、緯度、文字列、又はこれらの２つ以上の組合せを表す。
第６０の実施形態によれば、第５０〜第５９の実施形態の何れか１つにおいて、データ項目の構成要素は、データ項目の二進符号化のビット群である。
第６１の実施形態によれば、第６０の実施形態において、ビット群は６ビットを含む。
第６２の実施形態によれば、第５０〜第６１の実施形態の何れか１つにおいて、データ項目は数である。
第６３の実施形態によれば、第６２の実施形態において、データ項目は整数、長整数、又は倍長整数である。
第６４の実施形態によれば、第６２又は第６３の実施形態の何れか１つにおいて、データ項目は６４ビット整数である。
第６５の実施形態によれば、第６２〜第６４の実施形態の何れか１つにおいて、データ項目の構成要素は数字である。
第６６の実施形態によれば、第６５の実施形態において、数字は予め定義された基数、好ましくは６４を有する。
第６７の実施形態によれば、第５０〜第６６の実施形態の何れか１つにおいて、データ項目は文字列である。
第６８の実施形態によれば、第６７の実施形態において、データ項目の構成要素は１文字である。
第６９の実施形態によれば、第５０〜第６８の実施形態の何れか１つにおいて、データ項目はバイトの配列である。
第７０の実施形態によれば、第５０〜第６９の実施形態の何れか１つにおいて、トライは第１〜第４９の実施形態の何れか１つにおけるトライである。
第７１の実施形態によれば、第７０の実施形態において、第３４の実施形態に従属する場合、データ項目は、キー部又はキー部に含まれるコンテンツ情報に対応する。
第７２の実施形態によれば、第３３〜第７１の実施形態の何れか１つにおいて、２つ以上の子ノードを有するノード、好ましくは少なくとも各親ノードは、ビットマップ及び幾つかのポインタを含み、各ポインタにはビットマップにおいて設定されたビットが関連付けられ、各ポインタはノードの子ノードを指す。
一般的なトライ特徴
ビットマップ及びメモリの詳細
第７３の実施形態によれば、第１〜３２、第４９、又は第７２の実施形態の何れか１つにおいて、ビットマップは、予め定義されたサイズの整数としてメモリに記憶される。
第７４の実施形態によれば、第１〜第３２、第４９、第７２、又は第７３の実施形態の何れか１つにおいて、ビットマップのサイズは３２ビット、６４ビット、１２８ビット、又は２５６ビットである。
第７５の実施形態によれば、第１〜第３２、第４９、又は第７２〜第７４の実施形態の何れか１つにおいて、トライは、標的コンピュータシステムで格納され処理されるのに適し、ビットマップのサイズは、標的コンピュータシステムのＣＰＵのレジスタ、システムバス、データバス、及び／又はアドレスバスのビット幅に等しい。
第７６の実施形態によれば、第１〜第３２、第４９、又は第７２〜第７５の実施形態の何れか１つにおいて、トライのビットマップ及び／又はポインタ及び／又はノードは、配列、好ましくは長整数若しくはバイトのインアンド配列、リスト、又は連続した物理若しくは仮想メモリロケーションに格納される。
第７７の実施形態によれば、第１〜第１６、第２６、第２７、又は第７６の実施形態の何れか１つにおいて、メモリは、物理若しくは仮想メモリ、好ましくは連続メモリであり、又は物理若しくは仮想メモリ、好ましくは連続メモリを含む。
ポインタ
第７８の実施形態によれば、第１〜第３２、第４９、又は第７２〜第７７の実施形態の何れか１つにおいて、２つ以上の子ノードを有する親ノード、好ましくは少なくとも各親ノードに含まれるポインタの量は、前記親ノードに含まれるビットマップにおいて設定されたビット量に等しい。
第７９の実施形態によれば、第１〜第３２、第４９、又は第７２〜第７８の実施形態の何れか１つにおいて、親ノードの全てのポインタ内のあるポインタのランクは、親ノードのビットマップ内の全ての設定ビット内のそのポイントに関連付けられた設定ビットのランクに対応する。
第８０の実施形態によれば、第１〜第３２、第４９、又は第７２〜第７９の実施形態の何れか１つにおいて、ポインタは、ビットがビットマップにおいて設定されるのと同順又は逆順に格納される。
第８１の実施形態によれば、第１〜第３３、第４９、又は第７２〜第８０の実施形態の何れか１つにおいて、親ノードに含まれるポインタは、子ノードに含まれるビットマップを指す。
第８２の実施形態によれば、第１〜第３３、第４９、又は第７２〜第８１の実施形態の何れか１つにおいて、トライのリーフノード、好ましくは各リーフノードに含まれるポインタの数はゼロである。
キー部分
第８３の実施形態によれば、第３、又は第３３〜第８２の実施形態の何れか１つにおいて、親が２つ以上の子ノードを有する子ノード、好ましくは少なくとも各子ノードのキー部分の値は、ビットが子ノードに関連付けられた親ノードに含まれるビットマップ内の（設定）ビットの値によって決まる。
第８４の実施形態によれば、第４〜第１８又は第８３の実施形態の何れか１つにおいて、キー部分に利用可能な異なる値の最大量は、ビットマップのサイズによって定義される。
第８５の実施形態によれば、第４〜第１８、第８３、又は第８４の実施形態の何れか１つにおいて、ビットマップのサイズは、キー部分に可能な英字を定義する。
第８６の実施形態によれば、第３又は第３２〜第８５の実施形態の何れか１つにおいて、トライ内の各キー部分は、同じ予め定義されたサイズの値を格納可能である。
第８７の実施形態によれば、第８６の実施形態において、予め定義されるサイズは、５ビット値、６ビット値、７ビット値、又は８ビット値に対応する。
効率的な範囲クエリのキー符号化
第８８の実施形態によれば、第１〜第８７の実施形態の何れか１つにおいて、データ項目の値、好ましくは全てのデータ項目の値の符号化は、データ項目のデータ型を符号なし整数を本質的な特徴とするオフセット二進数表現に変換することによって得られる。
第８９の実施形態によれば、第８８の実施形態において、整数は長整数である。
第９０の実施形態によれば、第８８又は第８９の実施形態の何れか１つにおいて、データ項目のデータ型が浮動小数点数である場合、符号化は、データ項目のデータ型をオフセット二進数表現に変換することによって得られる。
第９１の実施形態によれば、第８８〜第９０の実施形態の何れか１つにおいて、データ項目のデータ型が２の補数の符号付き整数である場合、符号化は、データ項目のデータ型をオフセット二進数表現に変換することによって得られる。
他
第９２の実施形態によれば、第１〜第９１の実施形態の何れか１つにおいて、トライは、動的集合又は連想配列を格納する。
トライへのブール演算
本発明の第９３の実施形態は、電子データベース又は情報検索システムからデータを検索する方法であって、２つ以上の入力トライの表現を取得するステップと、結果トライの少なくとも部分を評価するステップであって、結果トライは、論理演算を使用した入力トライの組合せである、評価するステップと、出力として、結果トライの表現、結果トライのノードに関連付けられたキー及び／又は他のデータ項目の集合若しくは部分集合、又は結果トライのノードに関連付けられたキーから導出されるキー若しくは値の集合を提供するステップとを含む。
第９４の実施形態によれば、第９３の実施形態において、結果トライのリーフに関連付けられたキー及び／又は他のデータ項目は、出力として提供される。
第９５の実施形態によれば、第９３又は９４の実施形態において、出力として提供されるキーの集合は、トライで提供される。
第９６の実施形態によれば、第９３又は９４の実施形態の何れか一方において、出力として提供されるキーの集合は、カーソル又は反復子として提供される。
第９７の実施形態によれば、第９３〜９６の実施形態の１つにおいて、トライの部分はノード及び／又はトライの分岐である。
第９８の実施形態によれば、第９３〜９７の何れか１つにおいて、トライの表現は、物理的トライデータ構造又はトライを評価することが可能なトライ演算子へのハンドルである。
第９９の実施形態によれば、第９３〜９８の実施形態の何れか１つにおいて、トライの表現は、トライのルートノードを表し、トライノードインターフェースを実装し、トライノードインターフェースは、トライノードを表し、それが表すトライノードの子ノードをクエリ及び／又はトラバースする方法又は関数を提供する。
第１００の実施形態によれば、第９３〜９９の実施形態の何れか１つにおいて、トライ又はトライの部分を評価することは、トライ又はトライの部分をトラバースすることを含む。
第１０１の実施形態によれば、第１００において、トライ又はトライの部分を評価することは、トラバースされたノードがトライに存在することの情報を提供することを含む。
第１０２の実施形態によれば、第１００又は１０１の実施形態の何れか一方において、トライ又はトライの部分を評価する間、任意の所与の瞬間において、トライ又はトライの部分のトラバースのためにその瞬間に実現する必要がある、トライ又はトライの部分の物理的データ構造の少なくとも部分が実現される。
第１０３の実施形態によれば、実施形態１００〜１０２の何れか１つにおいて、任意の所与の瞬間において、トライ又はトライの部分の物理的データ構造の全体未満が実現され、好ましくは、トライ又はトライの部分のトラバースのためにその瞬間に実現する必要がある、トライ又はトライの部分の物理的なデータ構造の部分のみが実現される。
第１０４の実施形態によれば、実施形態９３〜１０２の何れか１つにおいて、トライ又はトライの部分を評価することは、トライ又はトライの部分の物理的データ構造を全体として実現することを含む。
第１０５の実施形態によれば、実施形態９３〜１０４の何れか１つにおいて、入力トライの少なくとも１つは、結果トライの少なくとも部分を評価するステップ中に少なくとも部分が評価される仮想トライである。
第１０６の実施形態によれば、実施形態１０５において、少なくとも、仮想トライの表現を取得する瞬間において、仮想トライの物理的データ構造は全体として存在しない。
第１０７の実施形態によれば、実施形態１０５又は１０６の何れか一方において、仮想トライ又は仮想トライの部分の物理的データ構造は全体として実現されない。
第１０８の実施形態によれば、実施形態１０５〜１０７の何れか１つにおいて、少なくとも、結果トライの少なくとも部分の評価に必要な仮想トライの部分が評価される。
第１０９の実施形態によれば、実施形態１０５〜１０８の何れか１つにおいて、結果トライの少なくとも部分の評価に必要ない仮想トライの部分の少なくとも幾つかは、評価されず、好ましくは、結果トライの少なくとも部分の評価に必要な仮想トライの部分のみが評価される。
第１１０の実施形態によれば、実施形態１０５〜１０９の何れか１つにおいて、仮想トライの少なくとも部分は、結果トライの少なくとも部分が評価された後、評価される。
第１１１の実施形態によれば、実施形態１０５〜１１０の何れか１つにおいて、結果トライの部分及び仮想トライの部分は、インタリーブ方式で評価される。
第１１２の実施形態によれば、実施形態１０５〜１１１の何れか１つにおいて、２つ以上の入力トライは高次入力トライであり、結果トライは高次結果トライであり、少なくとも１つの仮想トライの表現は、２つ以上の低次入力トライの表現を取得するステップと、低次結果トライを少なくとも部分的に評価するステップであって、低次結果トライは低次入力トライの低次論理演算を使用した結合である、評価するステップと、低次結果トライの表現を出力として提供するステップとを実行する低次結合演算子の出力として提供される。
第１１３の実施形態によれば、実施形態１１２において、低次結果トライの表現を出力として提供するステップは、低次結果トライを少なくとも部分的に評価するステップが完了する前、実行される。
第１１４の実施形態によれば、実施形態１１２又は１１３の何れか一方において、低次論理演算は、高次論理演算と同じ論理演算である。
第１１５の実施形態によれば、実施形態１１２又は１１３の何れか一方において、低次論理演算は、高次論理演算と異なる論理演算である。
第１１６の実施形態によれば、実施形態１１２〜１１５の何れか１つにおいて、低次入力トライの少なくとも１つは、表現が低次結合演算子の出力として提供される、必要な変更を加えた実施形態１０５〜１１１の何れか１つにおいて定義される仮想トライである。
第１１７の実施形態によれば、実施形態９３〜１１６の何れか１つにおいて、入力トライは、電子データベース若しくは情報検索システムに記憶されたキーの集合又は電子データベース若しくは情報検索システムに記憶されたキーの１つ若しくは複数の集合から導出された結果キーの集合を記憶する。
第１１８の実施形態によれば、実施形態９３〜１１７の何れか１つにおいて、トライは１つ又は複数のノードを含み、各子ノードにはキー部分が関連付けられ、ルートノードからトライにおける別のノードへのパスは、ノードに関連付けられるキーを定義し、キーは、パス上のノードに関連付けられたキー部分を連結したものである。
第１１９の実施形態によれば、実施形態９３〜１１８の何れか１つにおいて、論理演算を使用した２つ以上の入力トライの結合は、各入力トライにより記憶されたキーの各集合が論理演算を使用して結合される場合に取得されるキーの集合を記憶するトライである。
第１２０の実施形態によれば、実施形態９３〜１１９の何れか１つにおいて、論理演算が差である場合、結果トライの親ノードは第１の入力トライの親ノードであり、結果トライの親ノードのリーフは、第１の入力トライ内の対応する親ノードの子ノードの集合と他の入力トライ内の任意の対応する親ノードの子ノードの集合との論理演算を使用した結合であり、論理演算が差ではない場合、結果トライ内の各ノードの子ノードの集合は、入力トライ内の対応するノードの子ノードの集合の論理演算を使用した結合であり、異なるトライのノードに関連付けられたキーが同一である場合、異なるトライの２つ以上のノードは互いに対応する。
第１２１の実施形態によれば、実施形態９３〜１２０の何れか１つにおいて、結果トライのノードの子ノードの集合は、論理演算を使用して、結果トライのノードに対応する入力トライのノードの子ノードの集合を結合することにより決定される。
結合ステップ
第１２２の実施形態によれば、実施形態９３〜１２１の何れか１つにおいて、結果トライ又は結果トライの部分を評価するステップは、結果トライのルートノードに対して結合関数を実行することを含み、結果トライの入力ノードに対して結合関数を実行することは、論理演算を使用して、結果トライの入力ノードに対応する入力トライのノードの子ノードの集合を結合することにより結果トライの入力ノードの子ノードの集合を決定することと、結果トライの入力ノードに決定された子ノードのそれぞれに対して結合関数を実行することとを含む。
第１２３の実施形態によれば、実施形態９３〜１２２の何れか１つにおいて、結果トライ又は結果トライの部分を評価するステップは、深さ優先探索、幅優先探索、又はそれらの組合せを使用して実行される。
第１２４の実施形態によれば、実施形態１２３において、深さ優先探索において結果トライ又は結果トライの部分を評価するステップを実行することは、入力ノードの子ノードの１つに対して結合関数を実行することと、結合関数がその子ノードの次の兄弟ノードに対して実行される前、その子ノードにより形成されたサブトライをトラバースすることとを含む。
第１２５の実施形態によれば、実施形態１２３又は１２４の何れか一方において、幅優先探索において結果トライ又は結果トライの部分を評価するステップを実行することは、結果トライの入力ノードに対して決定された子ノードのそれぞれに対して結合関数を実行することと、結果トライの入力ノードの孫ノードの何れかに対して結合関数を実行する前、結果トライの入力ノードに対して決定された子ノードのそれぞれの子ノードの集合を決定することとを含む。
ビットマップ
第１２６の実施形態によれば、実施形態９３〜１２５の何れか１つにおいて、入力トライにおけるノード、好ましくは入力トライ内の少なくとも全ての親ノードはビットマップを含む。
第１２７の実施形態によれば、実施形態１２６において、トライ内の子ノードのキー部分の値は、ビットが子ノードに関連付けられた子ノードの親ノードに含まれるビットマップ内の（設定）ビットの値によって決まる。
第１２８の実施形態によれば、実施形態１２６又は１２７の何れか一方において、論理演算を使用して、結果トライのノードに対応する入力トライのノードの子ノードの集合を結合することは、好ましくは、論理演算を使用して、結果トライのノードに対応する入力トライのノードのそれぞれのビットマップをビット単位で結合し、それにより、結合ビットマップを取得することを含む。
第１２９の実施形態によれば、実施形態１２８において、結果トライのノードの子ノードは、結合ビットマップに基づいて、好ましくは結合ビットマップのみに基づいて決定及び／又は評価される。
第１３０の実施形態によれば、実施形態１２８又は１２９の何れか一方において、ビットマップを結合するステップは、結果トライのノードの子ノードが決定及び／又は評価される前、及び／又は結果トライの評価が結果トライのノードの子ノードにトラバースする前、実行される。
論理演算
第１３１の実施形態によれば、実施形態９３〜１３０の何れか１つにおいて、論理演算は論理積、論理和、差分、又は排他的論理和である。
第１３２の実施形態によれば、実施形態１３１において、論理演算を使用することは、ＡＮＤブール演算、ＯＲブール演算、ＡＮＤ ＮＯＴブール演算、又はＸＯＲブール演算を使用することを含む。
第１３３の実施形態によれば、実施形態９３〜１３２の何れか１つにおいて、論理演算を使用することは、ビット単位ＡＮＤブール演算、ビット単位ＯＲブール演算、ビット単位ＡＮＤ ＮＯＴブール演算、又はビット単位ＸＯＲブール演算を使用してノードのビットマップを結合することを含む。
範囲クエリ
第１３４の実施形態は、電子データベース若しくは情報検索システムに記憶されたキーの集合又は電子データベース若しくは情報システムに記憶されたキーの１つ若しくは複数の集合から導出された結果キーの集合に対して範囲クエリを実行することにより、電子データベース又は情報検索システムからデータを検索する方法であって、１つ又は複数の範囲の定義を取得するステップと、
実施形態９３〜１３３の何れか１つの電子データベース又は情報検索システムからデータを検索する方法を実行するステップと、
を含み、１つの入力トライは、１つ又は複数の範囲についてサーチされるキーの集合又は結果キーの集合を記憶する入力集合トライであり、別の入力トライは、定義が取得された１つ又は複数の範囲に含まれる全ての値を記憶する範囲トライであり、論理演算は論理積である、方法である。
第１３５の実施形態によれば、実施形態１３４において、範囲は、特定のデータ型の第１の値と第２の値との間の全ての値を含む順序付き離散値の集合である。
第１３６の実施形態によれば、実施形態１３５において、範囲は第１の値及び／又は第２の値を含む。
第１３７の実施形態によれば、実施形態１３４〜１３６の何れか１つにおいて、実施形態９３〜１３３の何れか１つの方法を実行するステップにおいて、実施形態９３〜１１１の何れか１つの方法が実行され、仮想トライである入力トライの少なくとも１つは範囲トライである。
１項目入力集合トライ
第１３８の実施形態によれば、実施形態１３７において、１つ又は複数の範囲の定義は、１データ項目の１つ又は複数の範囲の定義を含む。
多項目入力集合トライ
第１３９の実施形態によれば、実施形態１３４〜１３７の何れか１つにおいて、入力集合トライのリーフに関連付けられたキーは、特定のデータ型の２つ以上のデータ項目を符号化する。
第１４０の実施形態によれば、実施形態１３９において、１つ又は複数の範囲の定義は、データ項目の１つ又は複数の１つ又は複数の範囲の定義を含む。
１項目範囲トライからの多項目範囲トライの取得
第１４１の実施形態によれば、実施形態１３９又は１４０の何れか一方において、範囲トライは、入力集合トライのリーフに関連付けられたキーにより符号化されるデータ項目のそれぞれの１項目範囲トライを結合することによって得られる多項目範囲トライであり、データ項目の１項目範囲トライは、データ項目の１つ又は複数の範囲に含まれる全ての値を格納する。
第１４２の実施形態によれば、実施形態１４１において、１項目範囲トライの結合は、多項目範囲トライとの入力集合トライの結合を実施する関数内で実行される。
第１４３の実施形態によれば、実施形態１４１において、１項目範囲トライの結合は、多項目範囲トライとの入力集合トライの結合を実施する関数への入力として、多項目範囲トライを提供する関数によって実行される。
第１４４の実施形態によれば、実施形態１４１〜１４３の何れか１つにおいて、１項目範囲トライは、１項目範囲トライ、好ましくは、必要な変更を加えた実施形態１０５〜１１１の何れか１つにおいて定義される仮想トライを結合する演算中、少なくとも部分が評価される仮想トライである。
第１４５の実施形態によれば、実施形態１４１〜１４４の何れか１つにおいて、範囲の定義が取得されない各データ項目の１項目範囲トライは、データ項目の可能な値の全範囲を記憶する。
第１４６によれば。実施形態１４１〜１４４の何れか１つの方法、多項目範囲トライは、１項目範囲トライに記憶されたデータ項目の値の全ての組合せを記憶する。
範囲トライの構造
第１４７の実施形態によれば、実施形態１４１〜１４６の何れか１つにおいて、範囲トライは、入力集合トライと同じ構造又はフォーマットを有する。
第１４８の実施形態によれば、実施形態１４７において、範囲トライのリーフに関連付けられたキーは、入力集合トライのリーフに関連付けられたキーと同じデータ型のデータ項目を符号化する。
第１４９の実施形態によれば、実施形態１４７又は１４８の何れか一方において、範囲トライにおいて、特定のデータ型のデータ項目又はそのようなデータ項目の構成要素は、入力集合トライ内の対応するデータ項目又はデータ項目の構成要素と同じレベルのノードに符号化される。
範囲クエリの出力
第１５０の実施形態によれば、実施形態１３４〜１４９の何れか１つにおいて、方法は、入力集合トライのリーフに関連付けられたキーの集合を出力として提供する。
第１５１の実施形態によれば、実施形態１３９〜１４９の何れか１つにおいて、方法は、入力集合トライのリーフに関連付けられたキーによって符号化されたデータ項目のサブセットを符号化する縮小項目キーの集合を出力として提供する。
第１５２の実施形態によれば、実施形態１５１において、範囲トライとの入力集合トライの結合の結果として、縮小項目キーに符号化されないデータ項目に関連する入力集合トライの異なる分岐から得られる縮小項目キーの集合は、出力を提供する前、マージされる。
第１５３の実施形態によれば、実施形態１５１又は１５２の何れか一方において、範囲トライとの入力集合トライの結合の結果として得られる縮小項目キーの集合は、出力を提供する前、新たに作成されたトライに書き込まれ、それにより、出力を提供する前、複製キーをなくす。
ファジーサーチ
第１５４の実施形態は、文字列近似照合を実行することにより電子データベース又は情報検索システムからデータを検索する方法であって、文字のサーチ文字列を取得するステップと、サーチ文字列及び／又はサーチ文字列の変形を含む近似文字列の集合を記憶する一致トライを構築するステップと、結果トライの少なくとも部分を評価するステップであって、結果トライは論理積演算を使用した、電子データベース又は情報検索システムに記憶された文字列の集合を記憶したストレージトライと一致トライとの結合である、評価するステップと、出力として、結果トライのノードの結果集合に関連付けられた文字列及び／又は他のデータ項目を提供するステップであって、トライは１つ又は複数のノードを含み、各子ノードにはキー部分が関連付けられ、ルートノードからトライ内の別のノードへのパスは、ノードに関連付けられたキーを定義し、キーはパス上のノードに関連付けられたキー部分を連結したものである、提供するステップとを含む方法である。
第１５５の実施形態によれば、実施形態１５４において、一致トライに記憶された文字列の集合に含まれる文字列は、電子データベース又は情報検索システムに永続的に記憶される。
第１５６の実施形態によれば、実施形態１５４又は１５５の何れか一方において、一致トライに記憶された文字列の集合に含まれる文字列は、電子データベース又は情報検索システム内のエントリを表す。
第１５７の実施形態によれば、実施形態１５４〜１５６の何れか１つにおいて、一致トライ内の１つ又は複数の子ノードは、２つ以上の親ノードを有する。
第１５８の実施形態によれば、実施形態１５４〜１５７の何れか１つにおいて、ストレージトライ及び結果トライ内の各子ノードは、１つのみの親ノードを有する。
第１５９の実施形態によれば、実施形態１５４〜１５８の何れか１つにおいて、結果トライは、ストレージトライにより記憶されたキーの集合が一致トライにより記憶されたキーの集合と論理積演算された場合、取得されたキーの集合を記憶するトライである。
第１６０の実施形態によれば、実施形態１５４〜１５８の何れか１つにおいて、結果トライ内の各ノードの子ノードの集合は、一致トライ内の対応するノードの子ノードの集合とストレージトライ内の対応するノードの子ノードの集合との論理積であり、同じキーが異なるトライのノードに関連付けられている場合、異なるトライのノードは互いに対応する。
第１６０の実施形態によれば、実施形態１５４〜１６０の何れか１つにおいて、一致トライは、少なくとも部分が、結果トライの少なくとも部分を評価するステップ中に評価又は動的に生成される仮想トライである。
第１６１の実施形態によれば、実施形態１６０において、仮想トライ又は仮想トライの部分の物理的データ構造は全体として実現されない。
第１６２の実施形態によれば、実施形態１６０又は１６１の何れか一方において、少なくとも、結果トライの少なくとも部分の評価に必要な仮想トライの部分は評価される。
第１６３の実施形態によれば、実施形態１６０〜１６２の何れか１つにおいて、結果トライの少なくとも部分の評価に必要ない仮想トライの部分の少なくとも幾つかは評価されず、好ましくは、結果トライの少なくとも部分の評価に必要な仮想トライの部分のみが評価される。
第１６４の実施形態によれば、実施形態１６０〜１６３の何れか１つにおいて、仮想トライの少なくとも部分は、結果トライの少なくとも部分が評価された後、評価される。
第１６５の実施形態によれば、実施形態１６０〜１６４の何れか１つにおいて、結果トライの部分及び仮想トライの部分は、インタリーブ方式で評価される。
第１６６の実施形態によれば、実施形態１５４〜１６５の何れか１つにおいて、トライ又はトライの部分を評価することは、トライ又はトライの部分をトラバースすることを含む。
第１６７の実施形態によれば、実施形態１５４〜１６６の何れか１つにおいて、トライ又はトライの部分を評価することは、トラバースされたノードがトライに存在することの情報を提供することを含む。
第１６８の実施形態によれば、実施形態１５４〜１６７の何れか１つにおいて、トライ又はトライの部分の評価中、任意の所与の瞬間において、少なくとも、トライ又はトライの部分をトラバースするためにその瞬間に実現する必要があるトライ又はトライの部分の物理的データ構造の部分が実現される。
第１６９の実施形態によれば、実施形態１５４〜１６８の何れか１つにおいて、任意の所与の瞬間において、トライ又はトライの部分の物理的データ構造の全体未満が実現され、好ましくは、トライ又はトライの部分をトラバースするためにその瞬間において実現する必要があるトライ又はトライの部分の物理的データ構造の部分のみが実現される。
第１７０の実施形態によれば、実施形態１５４〜１６９の何れか１つにおいて、トライ又はトライの部分を評価することは、トライ又はトライの部分の物理的データ構造を全体として実現することを含む。
第１７１の実施形態によれば、実施形態１５４〜１７０の何れか１つにおいて、出力において提供されるデータ項目は、結果トライのノードの結果集合のノードに関連付けられた文字列、好ましくはドキュメント識別子を含むデータユニットを表す。
第１７２の実施形態によれば、実施形態１５４〜１７１の何れか１つにおいて、ストレージトライは、好ましくは、ドキュメントに含まれる文字列及びドキュメント識別子のそれぞれを２つのキー部、例えば（文字列、長）として格納するインデックストライ又は物理インデックストライである。
第１７３の実施形態によれば、実施形態１５４〜１７２の何れか１つにおいて、一致トライは一致ノードの集合を含み、各一致ノードには、近似文字列の集合からの文字列の１つに対応する１つ又は複数のキーが関連付けられ、ノードの結果集合は、一致トライ内の一致ノードの集合に対応する結果トライのノードの集合であり、結果トライのノードに関連付けられたキーが、一致トライのノードに関連付けられたキーと同一である場合、結果トライのノードは一致トライのノードに対応する。
第１７４の実施形態によれば、実施形態１５４〜１７３の何れか１つにおいて、方法は、数Ｎを取得するステップを更に含み、サーチ文字列の変形は、サーチ文字列での多くともＮ個の１文字挿入、削除、及び／又は置換によって取得することができる文字列の集合からなる。
第１７５の実施形態によれば、実施形態１５４〜１７４の何れか１つにおいて、一致トライを構築するステップは、近似文字列の集合を表す有限オートマトンを構築することと、有限オートマトンから一致トライを導出することとを含む。
第１７６の実施形態によれば、実施形態１〜１７５において、有限オートマトンの２つの状態間の遷移、好ましくはあらゆる遷移には、特定の文字、好ましくはサーチ文字列に含まれる文字、ワイルドカード文字、又は空文字列が関連付けられる。
第１７７の実施形態によれば、実施形態１７５又は１７６の何れか一方において、有限オートマトンを構築するステップは、近似文字列の集合を表す非決定性有限オートマトンを構築することと、非決定性有限オートマトンから決定性有限オートマトンを導出することとを含み、一致トライは決定性有限オートマトンから導出される。
第１７８の実施形態によれば、実施形態１〜１７７において、決定性有限オートマトンの２つの状態間の遷移、好ましくはあらゆる遷移には、特定の文字、好ましくはサーチ文字列に含まれる文字又はワイルドカード文字が関連付けられる。
第１７９の実施形態によれば、実施形態１５４〜１７８の何れか１つにおいて、一致トライ及びストレージトライ内のノード、好ましくは少なくとも全ての親ノードは、ビットマップを含み、トライ内の子ノードのキー部分の値は、ビットが子ノードに関連付けられた子ノードの親ノードに含まれるビットマップ内の（設定）ビットの値によって決まる。
第１８０の実施形態によれば、先の実施形態において、結果トライのノードの子ノードを決定することは、結果トライのノードに対応する一致トライのノード及びストレージトライのノードの子ノードの集合を論理積演算することを含む。
第１８１の実施形態によれば、先の実施形態において、一致トライのノード及びストレージトライのノードの子ノードの集合を論理積演算することは、ビット単位ＡＮＤ演算を使用して一致トライのノード及びストレージトライのノードのビットマップを結合し、それにより、結合されたビットマップを取得することを含む。
第１８２の実施形態によれば、先の実施形態において、結果トライのノードの子ノードは、結合ビットマップに基づいて、好ましくは結合ビットマップのみに基づいて決定及び／又は評価される。
第１８３の実施形態によれば、実施形態１８１又は１８２の何れか一方において、ビットマップを結合するステップは、結果トライのノードの子ノードが決定及び／又は評価される前、及び／又は結果トライの評価が結果トライのノードの子ノードにトラバースする前、実行される。
第１８４の実施形態によれば、実施形態１７１及び実施形態１７９〜１８３の何れか１つにおいて、有限オートマトンから一致トライを導出するステップは、遷移に関連付けられた特定の文字又はワイルドカード文字の符号化により有限オートマトンの２つの状態間の遷移、好ましくはあらゆる遷移を関連付けることにより、拡張有限オートマトンを取得することを含み、この符号化は、長さ及び／又はフォーマットが一致トライの親ノードに含まれるビットマップに等しい１つ若しくは複数のビットマップからなり、又は１つ若しくは複数のビットマップを表し、一致トライは拡張有限オートマトンから導出される。
第１８５の実施形態によれば、実施形態１〜１８４において、特定の文字の符号化の場合、厳密に１ビットが、符号化に含まれるか、又は表されるビットマップのそれぞれにおいて設定される。
第１８６の実施形態によれば、実施形態１８４又は１８５の何れか一方において、ワイルドカード文字の符号化の場合、全ての有効文字符号化のビットは、符号化に含まれ、又は符号化によって表されるビットマップにおいて設定され、遷移元の状態に関連付けられた特定の文字の符号化を除く全ての有効文字符号化のビットは、符号化に含まれ、又は符号化によって表されるビットマップにおいて設定される。
第１８７の実施形態によれば、実施形態１７９〜１８６の何れか１つにおいて、一致トライ、ストレージトライ、又は結果トライに格納された文字は、各トライのＭ＞１個、好ましくは５＞Ｍ個のキー部分によって符号化される。
第１８８の実施形態によれば、実施形態１〜１８７において、有限オートマトンから一致トライを導出するステップは、有限オートマトンの２つの状態間の遷移、好ましくはあらゆる遷移をＭ−１レベルの中間状態と、中間状態のＭ−１個を介して２つの状態をリンクするＭ個の遷移の１つ又は複数のシーケンスとで置換することにより、又は有限オートマトンの２つの状態間の遷移、好ましくはあらゆる遷移に、Ｍ−１レベルの中間状態と、中間状態のＭ−１個を介して２つの状態をリンクするＭ個の遷移の１つ又は複数のシーケンスを関連付けることにより、近似文字列の集合を表す完全有限オートマトンを取得することを含み、シーケンス内のＭ個の遷移のそれぞれには、長さ及び／又はフォーマットが一致トライの親ノードに含まれるビットマップに等しいビットマップからなり、又は表される中間符号化が関連付けられ、一致トライは完全有限オートマトンから導出される。
第１８９の実施形態によれば、実施形態１８８において、有限オートマトンの２つの状態間の遷移に、特定の文字が関連付けられる場合、シーケンスのＭ個の遷移が関連付けられた中間符号化に含まれ、又は表されるビットマップを連結したものは、特定の文字の符号化であり、ビットマップのそれぞれにおいて厳密に１ビットが設定される。
第１９０の実施形態によれば、実施形態１８８又は１８９の何れか一方において、有限オートマトンの２つの状態間の遷移にワイルドカードが関連付けられる場合、シーケンスのＭ個の遷移が関連付けられた中間符号化に含まれ、又は表されるビットマップを連結したものは、全ての有効文字符号化のビットが、符号化に含まれ、若しくは表されるビットマップにおいて設定され、又は遷移の発端である状態に関連付けられた特定の文字の符号化を除く全ての有効文字符号化のビットが、符号化に含まれ、若しくは表されるビットマップにおいて設定される符号化及び／又は特定の文字の符号化の１つ又は複数の部分又は全ての有効文字符号化のビットが符号化に含まれ、又は表されるビットマップにおいて設定され、若しくは遷移が発端とする状態に関連付けられた特定の文字の符号化を除く全ての有効文字符号化のビットが、符号化に含まれ、又は表されるビットマップにおいて設定される符号化の１つ又は複数の部分を含む１つ又は複数の符号化を含む。
第１９１の実施形態によれば、実施形態１８４〜１８６の何れか１つ、又は実施形態１８８〜１９０の何れか１つにおいて、拡張有限オートマトン又は完全有限オートマトンはそれぞれ、幾つかの行を含むデータ構造により表され、又は格納され、各行は、拡張有限オートマトン又は完全有限オートマトンの１つの状態を表し、状態を発端とする遷移のそれぞれにタプルを含み、各タプルは、遷移に関連付けられた符号化と、遷移が終わる状態への参照とを含む。
第１９２の実施形態によれば、実施形態１〜１９１において、データ構造は、遷移が終わる各状態について、好ましくは状態への各参照においてビットとして符号化される、この状態が一致状態であるか否かについての情報を含む。
第１９３の実施形態によれば、実施形態１９１又は１９２の何れか一方において、データ構造は、遷移元の拡張有限オートマトン又は完全有限オートマトンの状態のそれぞれの行を含む。
トライデータ構造
第１９４の実施形態によれば、実施形態９３〜１９３の何れか１つにおいて、トライは実施形態１〜９２の何れか１つに記載のトライである。
発明の異なるカテゴリ
第１９５の実施形態は、特に、キー若しくはキー及び値を格納し、クエリの結果キー若しくはキー及び値を格納し、又はクエリの入力キー若しくはキー及び値を格納する、電子データベースアプリケーション又は情報検索システムにおいて実施形態１〜９２の何れか１つにおけるトライを使用するコンピュータ実施方法である。
第１９６の実施形態は、実施形態１〜９２の何れか１つにおけるトライを生成するコンピュータ実施方法である。
第１９７の実施形態は、実施形態１〜９２の何れか１つにおけるトライを格納した非一時的コンピュータ可読媒体である。
本発明の第１９８の実施形態は、実施形態１〜９２の何れか１つにおけるトライを表す電子データのストリームである。
第１９９の実施形態は、実施形態１〜９２の何れか１つにおけるトライにより、キー若しくはキー及び値、クエリの結果キー若しくはキー及び値、又はクエリの入力キー若しくはキー及び値を格納する電子データベース又は情報検索システムである。
第２００の実施形態は、実施形態９３〜１９６の何れか１つにおける方法を実行する命令を含む、コンピュータプログラム、特にデータベースアプリケーション情報検索システムプログラムである。
第２０１の実施形態は、実施形態９３〜１９６の何れか１つにおける方法を実行するように構成された、１つ又は複数のプロセッサ及びメモリを含むデータ処理デバイス又はシステムである。
第２０２の実施形態は、実施形態２０１におけるコンピュータプログラムを記憶した好ましくは非一時的コンピュータ可読媒体である。
図面の簡単な説明
以下、本発明について、好ましい実施形態に関連して図面を参照して更に詳細に説明する。
従来技術によるデータベースで使用されるトライデータ構造の一例を示す。 従来技術で使用されるトライデータ構造の別の例を示す。 図２のトライデータ構造の従来技術による実施を示す。 図２のトライデータ構造の別の従来技術による実施を示す。 図２のトライデータ構造の別の従来技術による実施を示す。 従来技術によるトライにおいて、ノードの子ポインタがいかに決定されるかを示す。 本発明によるトライにおいて、リーフノードがマップにいかに格納されるか及び「最後」のビットマップがいかに集合に格納されるかを示す。 本発明によるトライにおいて、リーフノードがマップにいかに格納されるか及び「最後」のビットマップがいかに集合に格納されるかを示す。 本発明によるトライにおいて、リーフノードがマップにいかに格納されるか及び「最後」のビットマップがいかに集合に格納されるかを示す。 本発明による第１の空間最適化が効率的であるトライの一例を提供する。 本発明による第１の空間最適化を示す。 本発明による第２の空間最適化が効率的なトライの一例を提供する。 本発明による第２の空間最適化の汎用格納構成を示す。 本発明による第２の空間最適化を示す。 本発明により空間最適化されたトライのノードがいかに、汎用的にアクセスされるかを示す。 本発明により空間最適化されたトライへのキーの挿入を示す。 本発明により空間最適化されたトライへのキーの挿入を示す。 本発明により空間最適化されたトライへのキーの挿入を示す。 本発明による第１及び第２の空間最適化の効率を測定するために行われた実験の結果を示す。 本発明による第３の空間最適化を示す。 本発明による第３の空間最適化の効率を測定するために行われた実験の結果を示す。 本発明によるトライに格納すべき制御情報及びコンテンツ情報をキー内に配置する第１の方法を示す。 本発明によるトライに格納すべき制御情報及びコンテンツ情報をキー内に配置する第２の方法を示す。 本発明によるキー符号化の一例を示す。 本発明により符号化されたキーを格納するトライを示す。 値（Ｘ＝１２，Ｙ＝４５）を有する二次元キーの一例を示す。 図２１に示されたキーをいかに本発明によるトライに格納することができるかの一例を与える。 従来技術でのデータベースクエリ処理フェーズを示す。 従来技術によるデータベースで使用される例示的なクエリ実行プランを示す。 従来技術によるデータベースにおけるクエリ実行モデルに従った演算子制御及びデータフローを示す。 従来技術によるデータベースのクエリ実行プランに従った１度に１タプルの処理を示す。 従来技術によるデータベースのクエリ実行モデルに従った１度に１演算子の処理を示す。 本発明のクエリ実行モデルに従ったトライ制御及びデータフローを示す。 本発明のクエリ実行モデルによる別のトライ制御及びデータフローを示す。 本発明による２つのトライに論理積演算を適用する一例を示す。 本発明による論理積が実行される２つのトライ例を示す。 レベル１及びレベル２で図３１の２つのトライ例のビットマップに対して実行されたビット毎のＡＮＤ演算を示す。 図３１の２つのトライへの論理積演算中の分岐スキップを示す。 図３１の２つのトライへの論理積演算の結果トライを示す。 本発明による、２つのトライに論理和演算子を適用する一例を示す。 図３５の２つのトライへの論理和演算の結果トライを示す。 本発明による、２つのトライに差分演算子を適用する一例を示す。 図２９Ａに示されるデータフローにより結合すべき３つのトライを示す。 図３７Ａに示されるトライの結合結果を示す。 本発明による、範囲クエリにおける論理積演算し、入力集合トライ、及び範囲トライの相互作用を示す。 本発明による範囲クエリを実行する方法の一例を示す。 本発明による二次元範囲クエリを実行する方法の一例を示す。 図４０の一次元範囲トライがインタリーブされていかに結合されるかを示す。 図４１の結果として得られたインタリーブ範囲トライを示す。 図４０の一次元範囲トライが非インタリーブでいかに結合されるかを示す。 図４３の結果として得られた非インタリーブ範囲トライを示す。 入力集合トライが非インタリーブで格納される場合、範囲クエリ中、図４０の入力集合トライのどのノードが訪問されるかを示す。 入力集合トライがインタリーブで格納される場合、範囲クエリ中、図４０の入力集合トライのどのノードが訪問されるかを示す。 一次元出力を有する本発明による二次元範囲クエリを示す。 最大編集距離２を有するサーチ文字列「ａｂｃ」に一致する非決定性有限オートマトンを示す。 編集距離１の場合の「ａｂｃ」に一致する決定性有限オートマトンを示す。 図４８Ｂのオートマトンの遷移の拡大を示し、ユニコード文字の符号化方式及び図２１を参照して説明したユニコード文字の文字列が使用される。 １０ビットの各ユニコード文字が２つのキー部分により表されるマッチトライの結果上部を示す。 図４８Ｄのマッチトライを導出することができる完全有限オートマトンの状態を表すのに使用することができる、複数の配列の１配列としてのデータ構造を示す。 ミュンヘンのエリア内の小さな矩形内の全ロケーションの実験的ジオデータサーチクエリの仕様を示す。 第１の一連の実験的ジオデータサーチクエリを実行するデータベースにロードされた残りのレコードを示す。 第２の一連の実験的ジオデータサーチクエリを実行するデータベースにロードされた残りのレコードを示す。 実験的ジオデータサーチクエリにより決定された暫定結果集合及び最終結果集合を示す。 従来技術による手法の性能測定結果を示す。 本発明による標準索引付け手法で使用される非インタリーブ二次元インデックストライでの抽象ビューを示す。 本発明による標準索引付け手法でのマルチＯＲ演算子の使用を示す。 本発明による標準索引付け手法で使用される構成要素の概要を提供する。 本発明による標準索引付け手法の性能測定結果を示す。 本発明による可変精度索引付け手法の第１レベルインデックスの一例を示す。 本発明による可変精度索引付け手法の第２レベルインデックスの一例を示す。 本発明による可変精度索引付け手法の性能測定結果を示す。 本発明による二次元索引付け手法において、インタリーブで格納された２項目キーの部分が、互いと又は範囲トライの部分といかに結合されるかを示す。 本発明による二次元索引付け手法の性能測定結果を示す。 本発明によるシングルインデックス索引付け手法での３項目キーを格納するインデックスの構造を示す。 本発明によるシングルインデックス索引付け手法で使用される構成要素の概要を提供する。 本発明によるシングルインデックス索引付け手法の性能測定結果を示す。 結果サイズの増大に伴ってクエリ性能を測定した実験の結果を示す。 対数ｘ軸を有する図で図６６の結果を示す。 インデックスサイズの増大に伴って索引付け性能を測定した実験の結果を示す。 異なる索引付け手法の空間要件を示す。 情報検索アプリケーションにおいて、従来技術のインデックスを使用したデータベースと本発明によるインデックスを使用したデータベースとを索引付け性能、インダックスサイズ、及びクエリ性能に関して比較する。 情報検索アプリケーションにおいて、従来技術のインデックスを使用したデータベースと本発明によるインデックスを使用したデータベースとを索引付け性能、インダックスサイズ、及びクエリ性能に関して比較する。 情報検索アプリケーションにおいて、従来技術のインデックスを使用したデータベースと本発明によるインデックスを使用したデータベースとを索引付け性能、インダックスサイズ、及びクエリ性能に関して比較する。 情報検索アプリケーションにおいて、従来技術のインデックスを使用したデータベースと本発明によるインデックスを使用したデータベースとを索引付け性能、インダックスサイズ、及びクエリ性能に関して比較する。 情報検索アプリケーションにおいて、従来技術のインデックスを使用したデータベースと本発明によるインデックスを使用したデータベースとを索引付け性能、インダックスサイズ、及びクエリ性能に関して比較する。 情報検索アプリケーションにおいて、従来技術のインデックスを使用したデータベースと本発明によるインデックスを使用したデータベースとを索引付け性能、インダックスサイズ、及びクエリ性能に関して比較する。
発明の好ましい実施形態の詳細な説明
図１は、従来技術によるデータベースで使用されるトライデータ構造の一例を示す。図１は、各子ノード（すなわち、ルートノードを除く全てのノード）にはキー部分が関連付けられ、キー部分の値は、親ノードからのポインタによって示され、英数字｛０，…，９｝から選択され、すなわち、ルートノードを除く各レベルのノードには１桁の数字が関連付けられるトライデータ構造１０１を示す。ルートノードからトライ内の別のノードへのパスは、ノードが関連付けられたキーを定義し、キーは、パス上のノードに関連付けられたキー部分を連結したものである。トライ１０１には値「００７」を有するキーが関連付けられ、トライ１０１のリーフノード１０８には値「０４２」を有するキーが関連付けられているため、トライ１０１は、値「００７」及び「０４２」を有するキーを「格納」する。
第１レベル１１０に配置されたルートノード１０２は、値「０」のキー部分が関連付けられた１つの子ノード１０４を有する。したがって、ルートノード１０２から、トライ１０１の第２レベル１１１に配置された子ノード１０４へのポインタ１０３があり、子ノード１０４は値「０」を示す。第２レベルの子ノード１０４から、２つの異なるポインタが、第３レベル１１２に配置されたノード１０５、１０６を指し、これらのノード１０５、１０６のそれぞれから、１つの更なるポインタがリーフノード１０７、１０８をそれぞれ指す。したがって、ルートからリーフノードへのパス上のノードのキー部分を連結したものが、値「００７」及び「０４２」を有するキーになる。
図２は、従来技術で使用されるトライデータ構造の更なる例を示す。この例のトライデータ構造は図１のものと同様であるが、より大きな英字の、ノードに関連付けられたキー部分の可能な値を有する。特に、図２は２５６変数トライデータ構造を示し、キー部分値の表現は８ビット（すなわち、１バイト）のサイズを有する。
図２のトライデータ構造は、２つの異なるキー「００００ＦＤ」及び「００２Ａ０２」を格納し（リーフノードに関連付けられた２つの異なるキーを有し）、４つのレベル２１０〜２１４を有する。第１レベル２１０に配置されたルートノード２０２は、キー部分値「００」が関連付けられた子ノード２０４へのポインタを有する。子ノード２０４は、キー部分値「００」及び「２Ａ」がそれぞれ関連付けられた子ノード２０５、２０６への２つのポインタを含む。第３レベル２１２に配置された各子ノード２０５、２０６は、リーフノード２０７、２０８への１つのポインタをそれぞれ含む。リーフノード２０７、２０８は第４レベル２１３に配置される。リーフノード２０７にはキー部分値「ＦＤ」が関連付けられ、リーフノード２０８にはキー部分値「０２」が関連付けられている。
図３は、図２のトライデータ構造の従来技術による実施を示す。ポインタが関連付けられたノードは全体的に、メモリにおいて割り振られる。したがって、この状況では、空（無）ポインタであってもメモリ空間を占有する。例えば、ルートノード３０２は、配列３０６に割り振られた２５６個のポインタを有し、キー部分値「００」が関連付けられ、子ノード３０４を指す１つのポインタ３０３のみが空ではない。子ノードは同じように実施される。
図４は、メモリ空間をより効率的に使用する既知の解決策を提供する、図２のトライデータ構造の例示的な実施を示し、空（ヌル）ポインタの格納を回避する。解決策の本質は、可能な全てのポインタを含む配列の代わりに、各キー部分値と共に非空ポインタのみのリストを格納することにある。例えば、キー部分値「００」が関連付けられた１つの子ノードを有するルートノード４０２は、１つのエントリを有するリストを含む。リストのエントリは、キー部分値４０３と、子ノード４０５を指す、関連付けられたポインタ４０４とを含む。他の子ノードもそれに従って実施される。
図５は、親ノードの全ての非空ポインタを記すのに使用されるビットマップに基づいて割り振り問題への既知の解決策を提供する、図２のトライデータ構造の別の例示的な実施を示す。換言すれば、ビットマップ内の設定ビットは有効（非空）分岐を記す。各親ノードは１つ又は複数のポインタも含み、各ポインタにはビットマップ内の設定ビットが関連付けられ、各ポインタは親ノードの子ノードを指す。
子ノードのポインタを決定するためには、先行する子ポインタの量を計算する必要がある。ポインタを見つけるためのオフセットは、図６に示されるように、標的位置前にビットマップ内で設定された最下位ビットの量である。このコンパクトなトライノード構造は、無ポインタを格納する必要性をなくし、それと同時に、非常に高速なアクセスを可能にする。
図５の例のトライデータ構造は英字基数２５６を有し、その結果、ビットマップサイズは２５６ビットになる。換言すれば、各ビットマップは、２５６個の異なるキー部分値（又は子ノード）の２５６個のポインタを識別することができる。２５６個の異なる値を用いて、８ビット（２８）すなわち１バイトを符号化することができる。
ルートノード５０２は、ビットマップに設定された、キー部分値「００」を表す１ビットを有する。したがって、ルートノード５０２は、子ノード５０４への１つのみのポインタ５０３を含み、子ノードには値「００」を有するキー部分が関連付けられる。子ノード５０４は、ビットマップにおいて設定された２つのビット５０５、５０７、すなわち、キー部分値「２Ａ」及び「００」を表すビットを有する。したがって、子ノード５０４は、各子ノード５０９、５１０をそれぞれ指す２つのポインタ５０７及び５０８を含む。
値「２Ａ」を有するビットマップ内のビットに関連付けられたポインタ５０６は、キー部分値「２Ａ」を表すビット５０５から開始して、幾つの最下位ビットが設定されているかを計算することによりアドレス指定される。この場合、１つの最下位ビット、すなわち、ビット５０６しか設定されておらず、したがって、１ポインタのオフセットがあり、探しているポインタが、子ノード５０４に含まれる２番目のポインタであると判断することができる。
本発明によるトライの好ましい実施形態の一般特徴
全てのトライのように、本発明によるトライ又はトライデータ構造は、１つ又は複数のノードを含む。図１〜図６を参照して上述した従来技術によるトライと同様に、好ましい実施形態のトライのノード、好ましくは各子ノードにはキー部分が関連付けられ、ルートノードからトライ内の別のノード、特にリーフノードへのパスは、キーを定義し、キーは、パス内のノードに関連付けられたキー部分を連結したものである。ルートノードにはキー部分が関連付けられず、トライが、他の目的を果たすため、キー部分が関連付けられない更なるノードを含み得ることが理解されよう。例えば、サブツリー内のエントリの数は、通常は全ツリーをトラバースする必要があるカウント動作を回避又は加速させるために、そのようなノードに格納することができる。
本発明によるトライの好ましい実施形態では、２つ以上の子ノードを有するノード、好ましくは少なくとも各親ノードは、ビットマップ及び幾つかのポインタを含む。各ポインタには、ビットマップにおいて設定されたビットが関連付けられ、各ポインタはノードの子ノードを指す。通常、ビットは、値が「１」である場合、ビットマップにおいて「設定」されている。しかしながら、特定の実施形態では、ビットは、値が「０」である場合、「設定」されているものとしてカウントし得る。本明細書では、ビットマップ内のビットは、その値が、図５に示される従来技術によるトライを参照して先に説明したように、ビットマップ内のビットが有効分岐を記すという考えが関連付けられた値に対応する場合、「設定」されているものとしてカウントされる。
好ましくは、ビットマップは、予め定義されたサイズの整数としてメモリに格納される。更に、ビットマップのサイズは、好ましくは、３２ビット、６４ビット、１２８ビット、又は２５６ビットである。トライを格納し処理する標的コンピュータシステムの動作性能は、標的コンピュータシステムのＣＰＵのレジスタ、システムバス、データバス、及び／又はアドレスバスのビット幅に等しいようにビットマップのサイズを選ぶことにより上げることができる。
例えば、上述したように、ビットマップにおいて設定されたビットに関連付けられたポインタのメモリアドレスは、ビットマップにおいて設定された最下位ビットの数に基づいて計算することができる。この特定は、単純なビット演算と、設定ビットの数を特定するＣＴＰＯＰ（ポピュレーションカウント）演算とを使用して非常に効率的に行うことができる。多くの近代のＣＰＵは実に、固有命令としてＣＴＰＯＰを提供している。しかしながら、近代のＣＰＵでは長整数は６４ビット幅であるため、ＣＴＰＯＰは６４ビットでしか機能しない。これは、２５６ビットのビットマップを使用する従来技術によるトライにとっては、演算が最高で４回（４×６４＝２５６）実行されることを意味する。代替的には、従来技術によるトライは、最初の３つのビットマップを有する先行ビットマップの合計ビットカウントを格納する。次に、最下位ビットの数は、ビットの最後の群のＣＴＰＯＰ＋ビットの先行群のビットカウントとして計算することができる。
現在、大半のコンピュータシステムでは、システムビット幅は６４ビットであり、６４ビットというビットマップサイズは現在、最も好ましいサイズであり、本発明の実施例で本発明者により使用された。この結果、６４変数トライが生成され、これは、あらゆるノードが６４シンボルの英字シンボルを格納することができ、すなわち、６ビット（２６＝６４）を符号化することができることを意味する。以下に説明するように、本発明の実施形態によるトライは、幾つかのノード及びそれに関連付けられたキー部分を使用して、プリミティブデータ型に含まれる情報を格納し得る。例えば、６４ビット長整数によって表されるキーを格納するには、１１レベルを有する６４変数トライが必要である（１１＊６ビット＞＝６４）。
ビットマップ及び／又はポインタは、例えば、配列、リスト、又は連続した物理若しくは仮想メモリロケーションに格納し得る。なお、「メモリ」という用語が本明細書で使用される場合は常に、物理的又は仮想的なメモリを指し得、好ましくは連続メモリを指し得る。好ましい実施形態では、長整数（６４ビット）は、ビットマップを表すために使用されるとともに、子ポインタのそれぞれを表すのにも使用される。メモリにおいてノードを別個に割り振る代わりに、ノードは長整数の配列に格納され、ノードのメモリポインタを有する代わりに、現在のノードはこの配列へのインデックスにより指定される。子ポインタは、配列内のノード位置のインデックスであり得る。その場合、トライをトラバースするとき、現在のノードインデックスに基づいて子ノードのインデックスを見つけるためのオフセットは、ビットマップの標的位置前にビットマップにおいて設定された最下位ビットの量に１を加算したものである。
好ましい実施形態は幾つかのそのような配列を用いて機能する。ポインタの一部分、例えば下部は、配列内のインデックスであり、ポインタの別の部分、例えば上部は配列への参照である。任意の大きなサイズの配列を割り振ることは常に可能であるわけではないため、これはメモリ管理目的で行われる。例えば、Javaでは、配列のサイズは３２ビット整数に制限され、これにより、２３１（正の値のみ）＝２，１４７，４８３，６４８の配列サイズになる。しかしながら、多くの現実世界用途では、１６ＭＢ以上を含む配列が必要とされ、これは６４ビット長整数配列では２００万個のエントリに対応する。
図５及び図６の従来技術によるトライのように、２つ以上の子ノードを有する親ノード、好ましくは少なくとも各親ノードは通常、前記親ノードに含まれるビットマップにおいて設定されたビット量に等しいポインタ量を含む。例えば、図５のノード５０４は、設定された２ビット５０５、５０６を有するビットマップを有し、２つのポインタ５０７、５０８を含む。親ノードの全ポインタ内でのポインタのランクは、好ましくは、親ノードのビットマップ内の全ての設定ビット内の、ポインタに関連付けられた設定ビットのランクに対応する。例えば、図５の親ノード５０４では、第１のポインタ５０７はビットマップの第１の設定ビット５０５に対応し、第２のポインタ５０８は第２の設定ビット５０６に対応する。ポインタは通常、ビットがビットマップにおいて設定された順と同順又は逆順に格納される。各ポインタは、好ましくは、例えば図９及び図１２において以下に示されるように、子ノードに含まれるビットマップ（のアドレス）、例えば、このビットマップの開始アドレスを指す。
図５及び図６の従来技術によるトライでのように、親が２つ以上の子ノードを有する好ましい実施形態のトライの子ノード、好ましくは少なくとも各子ノードのキー部分の値は、ビットが子ノードに関連付けられた親ノードに含まれるビットマップにおける（設定）ビットの値によって決まる。したがって、キー部分に利用可能な異なる値の最大量は通常、ビットマップのサイズによって定義され、及び／又はビットマップのサイズは、キー部分に可能な英字を定義する。
本発明の好ましい実施形態では、トライ内の各キー部分は、同じ予め定義されるサイズの値、例えば５ビット値（ビットマップのサイズが３２ビットである場合）、６ビット値（ビットマップのサイズが６４ビットである場合）、７ビット値（ビットマップのサイズが１２８ビットである場合）、又は８ビット値（ビットマップのサイズが２５６ビットである場合）を格納することが可能である。ノード又はキー部分によって表される文字の英字は、そのサイズを有する可能な全てのビット群の集合である。例えば、キー部分が６ビット値を格納可能な場合、英字は、６ビットを含む全てのビット群の集合である。
本発明によるトライデータ構造は、キー値マップ（「連想配列」とも呼ばれる）の実施に使用することができ、値はリーフノード及びキー集合（「動的集合」とも呼ばれる）に格納され、データはリーフノードに格納されない。所与のキーの値を調べるために、あらゆるキーが１つのみの値を有する場合、マップが使用され、一方、所与の集合が所与のキーを含むか否かを判断するためには、集合が使用される。両方の場合で同様に、キーへの集合演算（論理和、論理積、又は差分等）は頻繁に必要とされる演算である。
図７Ａ〜図７Ｃは、コンパクトに、全ての値に一定時間内でアクセスすることができるように、リーフノードがマップにいかに格納されるか及び「最後」のビットマップがいかに集合に格納されるかを示す。図７Ａは、より長い文字列又はテキスト等のより大きな及び／又は可変サイズ値のデータ型を有するキー値マップの場合、リーフノードがいかに格納されるかを示す。図７Ａに示されるように、値は別個に格納される。値への追加のポインタｉｄｘに必要な空間は、ポインタのサイズと比較して値のサイズが大きい場合、ごくわずかである。
値データ型が、日付け又は整数等の固定サイズである場合、値を「直列」に格納する、例えば、図７Ｂに示されるように、親ノードのビットマップの直後に格納することがより効率的である。例えば、長−長マップ、すなわち、キーが長整数型であり、値も長整数型であるマップは、直列化を用いる本発明の好ましい実施形態によりトライデータ構造により効率的に実施することができる。直列化は、固定サイズ値データ型である場合、位置は、例えば、ＣＴＰＯＰ（ビットマップ＋（ビット位置−１））＊サイズとして計算することができるため、固定サイズ値データ型でのみ機能する。逆に、可変サイズ値データ型の場合、位置を特定するために、全ての値のエントリを経る必要がある。
図７Ｃは、「最後」のビットマップを記憶する直列を集合にいかに使用することができるかを示す。値がないため、最後のビットマップはそれ自体、ポインタの必要なく直列化される。なお、本明細書で使用される用語では、物理レベルでのこれらの「最後」のビットマップは、リーフノードの親ノードの部分であるが、これらのビットマップにおいて設定されたビットは、論理レベルでのリーフノードのキー部分の値を示す。
トライデータ構造は、キーを順序付きで格納し、したがって、キーを順にトラバースすることができる。例えば、６４ビット長整数キーは、最上位６ビット（又は６４＝４＋１０＊６であるため、４ビット）から始まって最下位６ビットまで格納し得る。この方法では、整数は符号なし長整数として扱われる。通常、２の補数を使用して符号化される符号付き整数の場合、正確な順序を有するために、例えば、６４ビット長整数の場合２６４−１を追加することによりオフセット二進表現に変換しなければならない。浮動小数点数も同様に扱われる。したがって、浮動小数点数又は２の補数の符号付き整数等のキーのデータ項目の値の符号化は、データ項目のデータ型を、符号なし整数、例えば、符号なし長整数で構成されるオフセット二進表現に変換することを含み得る。
空間効率的トライデータ構造
多くの用途状況では、メモリ空間の使用は非効率的である。これは、トライが疎に存在し、及び／又は各ノードが１つのみの子ポインタを有するノード連鎖に劣化する場合、特に当てはまる。
連鎖ノード最適化
本発明者は、経験的研究において、任意のキーについて、典型的な用途状況でのトライが、１つのみの子を有する多くのノードを有することを発見した。これは、多くのキーが共通のプレフィックス、インフィックス、又はポストフィックスを共有するためである。そのような状況では、従来技術によるトライは、１つの子ポインタを有するノードの連鎖に劣化し、従来技術によるトライデータ構造の空間効率は低い。
本発明の第１の空間最適化は、ノードが１つのみの子を有する場合、すなわち、親ノードに含まれるビットマップにおいて、１つのみのビットが設定される場合、子ポインタをなくす。本明細書ではこの手法を「連鎖ノード最適化（chained node optimization）」と呼ぶ。連鎖ノード最適化が効率的なトライの一例を図８に示す。トライのレベル４にあるリーフノード８４１、８４２、８４３は、レベル０におけるルートノード８００、ルートノード８００の唯一の子ノードであるレベル１におけるノード８１０、ノード８１０の唯一の子ノードであるレベル２におけるノード８２０、及びノード８２０の唯一の子ノードであるレベル３におけるノード８３０を含む共通のプレフィックスを共有する。
本発明の第１の空間最適化は、１つ又は複数のノードを含むトライであって、２つ以上の子ノードを有する、トライに含まれる親ノード、好ましくは各親ノードは、ビットマップ及び１つ又は複数のポインタを含み、各ポインタにビットマップにおいて設定されたビットが関連付けられ、各ポインタは親ノードの子ノードを指す、トライに適用される。最適化は、１つのみの子ノードを有する、トライに含まれる親ノード、好ましくは各親ノードが、子ノードへのポインタを含まず、及び／又は子ノードがメモリにおいて、親ノードに相対して予め定義された位置に格納されることによって達成される。好ましくは、１つのみの子ノードを有する親ノードの子ノードは、メモリにおいて親ノードの直後に格納される。
本発明による第１の空間最適化を図９に示し、図９は、連鎖ノード最適化前のトライ９１０の部分と、連鎖ノード最適化が適用された後のトライ９１０に対応するトライ９２０の部分とを示す。上述した好ましい実施形態と同様に、トライ９１０、９２０におけるノードは、長整数の配列内に格納され、これは、トライ９１０、９２０の部分の図の左側にある表現「ｌｏｎｇ［］」によって示される。
トライ９１０は、１ビットのみが設定され（１）、他の全てのビットは設定されない（０）ノード９１１の（６４ビット幅）ビットマップにより示されるように、１つのみの子を有する第１のノード９１１を含む。従来技術によるトライのように、ノード９１１は結果として、ノード９１１の子ノードであるノード９１２を指す長整数である１つのポインタ９１４を含む。ノード９１２は、ノード９１２の（６４ビット幅）ビットマップにおいて設定された２ビット及びノード９１２に含まれる２つのポインタ９１５、９１６によって示されるように、図９に示されていない２つの子ノードを有する。ノード９１１とノード９１２との間の３つのドット（「．．．」）によって示されるように、ノード９１２は通常、ノード９１１の直後のメモリロケーションに格納されず、長整数の配列内の任意の場所に格納することができる。
トライ９２０もまた、１ビットのみが設定され（１）、他の全てのビットは設定されない（０）ノード９２１の（６４ビット幅）ビットマップにより示されるように、１つのみの子を有する第１のノード９２１を含む。しかしながら、トライ９１０におけるノード９１１とは対照的に、トライ９２０におけるノード９２１は、ノード９２１の子ノードであるノード９２２を指すポインタを含まない。その代わり、ノード９２２は、好ましい場合、ノード９２１の直後のメモリロケーションに格納されるが、代替的には、親ノード９２１に相対するメモリ内の位置が予め定義される限り、長整数の配列内の任意の場所に格納することができる。例えば、子ノード９２２は、親ノード９２１の直前に格納することができ、又は親ノード９２１と子ノード９２２との間に固定長の別のデータオブジェクトが存在することができる。トライ９１０のノード９１２のように、トライ９２０のノード９１２は、メモリ（長整数の配列）内のロケーションがノード９２２に含まれる２つのポインタ９２５及び９２６によって示される、図９に示されていない２つの子ノードを有する。
ノードに含まれるビットマップ及び各ポインタの両方が長整数により、すなわち、同じデータ型又は同じ長さのデータ型により表される図９の実施形態例では、本発明による連鎖ノード最適化は、１つのみの子ノードを有するノードの格納に必要なメモリ空間を５０％低減する。
末端最適化
本発明の第２の空間最適化は、トライの「端部」が１ノードの連鎖又は列、すなわち、共通のポストフィックスを有さない多くのキーを含むトライのメモリでのよりコンパクトな表現を提供する。第２の空間最適化が効率的なトライの一例を図１０に示す。図１０におけるトライのリーフノード１０４１、１０４２、１０４３、１０４４、１０４５はそれぞれ、独立した（非共通）ポストフィックスの部分である。各ポストフィックスは、トライのレベル３において１つのノード１０２１、１０２２、１０２３、１０２４、１０２５、トライのレベル４において１つのノード１０３１、１０３２、１０３３、１０３４、１０３５、及びレベル５において１つのリーフノードを含む。レベル３におけるノード１０２１、１０２２、１０２３、１０２４、１０２５及びレベル４におけるノード１０３１、１０３２、１０３３、１０３４、１０３５はそれぞれ、１つのみの子を有する。
第２の空間最適化によれば、１ノードの列の開始におけるノードは、「末端分岐ノード」と記される。図１０では、末端分岐ノードは、トライのレベル３におけるノード１０２１、１０２２、１０２３、１０２４、１０２５である。列内の残りのノードのキー部分の値は単に、それらの親ノードに含まれるビットマップ内の（設定）ビットの値によって決まるのではなく、「ネイティブ」又は文字通りの符号化で連続して格納される。本明細書では、この手法を「末端最適化」と呼ぶ。
したがって、本発明の第２の空間最適化は、１つ又は複数のノードを含むトライであって、２つ以上の子ノードを有する、トライに含まれる親ノード、好ましくは少なくとも各親ノードは、ビットマップを含み、ノード、好ましくは各子ノードにはキー部分が関連付けられ、親が２つ以上の子ノードを有する子ノード、好ましくは少なくとも各子ノードのキー部分の値は、ビットが子ノードに関連付けられた親ノードに含まれるビットマップ内の（設定）ビットの値によって決まる、トライに適用される。
ノードがメモリにおいて独立して割り振られるPh. Bagwell,“Fast And Space Efficient Trie Searches”, Technical Report, EPFL, Switzerland (2000)では、「ツリーテール圧縮」と呼ばれる手法が、文字列ノードへのポインタを参照し、又は末端分岐ノードに直接、末端列の数値を格納する。しかしながら、この手法は空間効率的ではなく、その理由は、オフセット及びノードタイプ（ビットマップを有するノード又は文字／ポインタリストを有するノード）をノードに格納する必要があるためである。
本発明による末端最適化は、ビットが設定されていないビットマップにより、トライ内の１つのみの子ノードを有し、全ての子孫ノードが多くとも１つの子ノードを有するノード、好ましくは各ノードを末端分岐ノードと記すことにより、この問題を解決する。本発明は、常に少なくとも１ビットが設定された好ましい実施形態の標準ノードに含まれるビットマップの特別な品質を使用する。これは、全てゼロのビットマップを有するノードが、子ノードを有さないノードであるが、子ノードを有さないノードは、メモリにおいて表す必要がないためである。したがって、特別な意味は、ビットが設定されていないビットマップに起因することができ、末端分岐ノードのビットマップは、２つ以上の子ノードを有する親ノードに含まれるビットマップと同じ長さ又はフォーマットを有することができる。
末端分岐ノード、好ましくは各末端分岐ノードの子孫ノード、好ましくは各子孫ノードに関連付けられたキー部分の値は、子孫ノードの親ノードに含まれるビットマップにおける（設定）ビットの値によって決まらない。むしろ、キー部分の値は、表現に必要なメモリ空間が、２つ以上の子ノードを有する親ノードに含まれるビットマップよりも少ないように符号化される。通常、キー部分の値は、整数値等の二進数（数）として符号化される。例えば、標準ノードに含まれるビットマップが３２ビット、６４ビット、１２８ビット、又は２５６ビットをそれぞれ有する場合、末端分岐ノードの子孫ノードに関連付けられたキー部分は５ビット、６ビット、７ビット、又は８ビットによりそれぞれ符号化される。
本発明の好ましい実施形態による末端最適化の一般格納構成を図１１に示す。ビットが設定されていない６４ビット幅ビットマップの後、二進数として符号化される幾つかの（通常、少なくとも２つの）６ビットキー部分が続く。しかしながら、好ましい実施形態では、各６ビットキー部分は８ビットブロック（１バイト）に格納される。利用可能な８ビットのうち６ビットしか使用しないため、これはいくらかの空間を無駄にするが、８ビット内の６から８ビットのうちの８への変換及びこの逆の変換は、実施の複雑性を上げ、性能を低下させる。本発明者によって行われた測定では、空間の無駄が許容できるものであり、８ビットのうちの８を格納することによる空間改善はごくわずかであることが示された。
末端分岐ノード及び／又はその子孫ノードは、それらの１つの子ノード（もしあれば）へのポインタを含む必要がなく、その理由は、図１２に示されるように、子ノードがメモリにおいて親ノードに相対して予め定義された位置に、好ましくは親ノードの直後に格納することができるためである。更に、末端分岐ノード、好ましくは各末端分岐ノードの子孫ノード、好ましくは全ての子孫ノードに関連付けられたキー部分の値は、末端分岐ノード後、連続して格納される。最後に、図１２において観察することができるように、１ノード列では、末端分岐ノードの場合のみ、ノードを末端分岐ノードと記すためにビットマップを有する必要があり、一方、末端分岐ノードの子孫ノードはいずれも、ビットマップ、特に設定ビットが子ノードに関連付けられたキー部分の値を決めるビットマップを含む必要がない。
図１４Ｃに示され、後述される例から明らかになるように、最も好ましい実施形態による末端最適化は、末端分岐ノードが２つ以上の子孫ノードを有する場合のみ、連鎖ノード最適化よりも空間効率的である。更に、１ノード列内の最初のノードが既に末端分岐ノードと記されており、したがって、末端分岐ノードの親が２つ以上の子ノードを有する場合、最大の空間節約を達成することができる。
本発明による第２の空間最適化を図１２に示し、図１２は、末端最適化前のトライ１２１０の部分と、末端最適化が適用された後のトライ１２１０に対応するトライ１２２０の部分とを示す。トライ１２１０、１２２０のノードはここでも、長整数の配列に格納される。
トライ１２１０は、１ビットのみが設定され（１）、他の全てのビットは設定されない（０）ノード１１１１のビットマップにより示されるように、１つのみの子を有する第１のノード１２１１を含む。一番右側のビットが値「０」を有し、一番左側のビットが値「６３」を有する６４ビット幅ビットマップ内の左から４番目のビットであることから分かるように、設定されている１ビットは値「６０」を有する。ノード１２１１は、ノード１２１１の子ノードであるノード１２１２を指す長整数である１つのポインタ１２１３を含む。ノード１２１１とノード１２１２との間の３つのドット（「．．．」）によって示されるように、ノード１１１２は通常、ノード１１１１の直後のメモリロケーションに格納されず、長整数の配列内の任意の場所に格納することができる。値「０１」を有するビットである、ノード１２１２の６４ビット幅ビットマップにおいて設定された右から２番目のビットによって示されるように、ノード１２１２も１つの子ノードを有する。しかしながら、ノード１２１２の子ノードはリーフノードであるため、ノード１２１２は子ノードへのポインタを含まず、リーフ部１２１４を含み、リーフ部１２１４は、ポインタ、マップの値（図７Ａ及び図７Ｂ参照）、又は集合の場合、空（図７Ｃ参照）であり得る。リーフノードはメモリにおいて表現されない。なお、好ましい実施形態では、トライの深さ又はトライに格納されるキーの長さは既知であるため、特定の「リーフインジケータ」は必要ない。
観察することができるように、ノード１２１１は末端分岐ノードであり、その理由は、１つのみの子ノード１２１２を有し、全ての子孫ノード（１２１２及び１２１２の子ノード）が多くとも１つの子ノードを有する（ノード１２１２は１つの子ノードを有し、ノード１２１２の子ノードは子ノードを有さない）ためである。トライ１２２０は、末端最適化を適用した結果として、トライ１２１０から得られる。トライ１２１０のノード１２１１に対応するトライ１２２０のノード１２２１は、ビットが設定されていない６４ビット幅ビットマップを提供することにより末端分岐ノードとして記されている。トライ１２１１の子ノード１２１２に対応する子ノード１２２２に関連付けられたキー部分の値は、ノード１２２１のビットマップにおける（設定）ビットの値によって決まらない。むしろ、キー部分の値は、図１２において数字「６０」によって示されるように、ノード１２２１に含まれる、整数等の二進数として符号化される。キー部分の値のそのような表現は、たった６ビット（６４＝２６）しか必要とせず、したがって、必要とするメモリ空間は、２つ以上の子ノードを有する親ノードに含まれる６４ビット幅ビットマップよりもはるかに少ない。例えば、値６０は二進数「１１１１００」として符号化し得る。
末端分岐ノード１２２１は、子ノード１２２２へのポインタを含まない。むしろ、子ノード１２２２は、親ノード１２２１に相対したメモリ内の予め定義された位置、すなわち、親ノードの直後に格納される。ノード１２２２は、末端分岐ノード１２２１の子孫ノードであり、ビットマップを含まず、子ノードへのポインタを含まず、図１２において数字「０１」によって示されるように、ノード１２２２の子ノードに関連付けられたキー部分の値を符号化する二進数のみを含む。例えば、値０１は二進数「０００００１」として符号化し得る。ノード１２２２の表現の後、メモリではリーフ部１２２４が続く。ここでも、リーフ部１２２４は、ポインタ、マップの値（図７Ａ及び図７Ｂ参照）、又は集合の場合、空（図７Ｃ参照）であり得る。
ビットマップ及びノードに含まれる各ポインタの両方が長整数によって表される図１２の実施形態例では、末端最適化されたトライ１２２０は、ノード１２２１及び１２２２の格納に６４＋６＋６＝７６ビットを必要とする。これと比較して、最適化されていないトライ１２１０は、同じ情報（ノード１２１１及び１２１２、トライ１２１０及び１２２０の両方に存在するリーフ部１２１４はカウントに含めない）の格納に６４＋６４＋６４＝１９２ビットを必要とする。
好ましい実施形態でのように、長整数の配列がトライの格納に使用される場合、本発明による末端最適化は、位置合わせ損失を被る。最悪の場合、１つの６ビットキー部分が６４ビット長整数に格納される。しかしながら、実験では、平均で、末端分岐ノードの子孫ノードの格納に使用される空間の５０％が占有されることが示された。更に、末端最適化はそれでもなお、必要とする空間は、ポインタ又は連鎖ノード最適化を用いて幾つかのシングル子ノードを格納するよりもはるかに少ない。
標準ノード、連鎖ノード最適化によって最適化されたノード、及び末端最適化によって最適化されたデータに均一にアクセスする方法について、図１３を参照してこれより概説する。実施例においてクエリ実行モデルで使用されるノードアクセスの主な方法は、トライノードの全ての非空子ポインタでビットが設定されたビットマップを返すｇｅｔＢｉｔＳｅｔ（）及びビット数によって指定される所与のノード分岐の子ノードを返すｇｅｔＣｈｉｌｄＮｏｄｅ（ｂｉｔＮｕｍ）である。これらの方法は両方とも、インターフェースＣＤＢＩＮｏｄｅによって提供され、ここで、ＣＤＢＩは「コンフルエンスデータベースインデックス」を表す。別のインターフェースＣＤＢＩＮｏｄｅＭｅｍは、ＣＤＢＩＮｏｄｅインターフェースを通してのオブジェクト指向アクセスをデータモデルに提供する。
解決する必要がある問題は、統一された中央場所で、コードの多くの場所で別個に対処する必要なく３つの事例をいかに扱うかであった。本発明者によって発見された解決策によれば、図１３に示すように、ノードは、ノードポインタ（インデックス）を介するのみならず、ベースノードインデックス（「ｎｏｄｅＲｅｆ」）及びノード内のインデックス（「ｉｄｘＩｎＮｏｄｅ」）も介して参照され、ポインタのない連鎖及び末端を、末端ノードの連鎖の冒頭を指すベースノードインデックスを有する１つのノードとして扱う。このようにして、メモリ空間最適化は、「ｇｅｔ」演算に大きな複雑性を追加せず、したがって、性能は低下しない。
ｎｏｄｅＲｅｆは常に最初のビットマップを指すため、ｇｅｔＢｉｔＳｅｔ（）及びｇｅｔＣｈｉｌｄＮｏｄｅ（ｂｉｔＮｕｍ）の実装において３つの事例を検出するのに使用される：
−ビットマップは、２つ以上の設定ビットを有する場合、通常ノードに属する。ｇｅｔＢｉｔＳｅｔ（）はそのビットマップを返し、ｇｅｔＣｈｉｌｄＮｏｄｅ（ｂｉｔＮｕｍ）は、ｉｄｘ（子ノードへのポインタ）を決定し、ｎｏｄｅＲｅｆがそれに設定された（且つｉｄｘＩｎＮｏｄｅが０に設定された）新しいＣＤＢＩＮｏｄｅＭｅｍを返す。
−ビットマップは、０である（ビットが設定されていない）場合、末端分岐ノードに属する。ｇｅｔＢｉｔＳｅｔ（）は、ｉｄｘＩｎＮｏｄｅ位置に文字通り格納された６ビット値をビットマップに変換して返し、ｇｅｔＣｈｉｌｄＮｏｄｅ（ｂｉｔＮｕｍ）は、同じｎｏｄｅＲｅｆ及びｉｄｘＩｎＮｏｄｅ＋１を有する新しいＣＤＢＩＮｏｄｅＭｅｍを返す。
−ビットマップは、１ビットが設定されている場合、連鎖ノードに属する。ｇｅｔＢｉｔＳｅｔ（）はｉｄｘＩｎＮｏｄｅ位置におけるビットマップを返し、ｇｅｔＣｈｉｌｄＮｏｄｅ（ｂｉｔＮｕｍ）はここでも、同じｎｏｄｅＲｅｆ及びｉｄｘＩｎＮｏｄｅ＋１を有する新しいＣＤＢＩＮｏｄｅＭｅｍを返す。ＣＤＢＩＮｏｄｅＭｅｍは、時間がかかる新しい子ノードを作成せず、ただｎｏｄｅＲｅｆ及びｉｄｘＩｎＮｏｄｅ（ｇｏｔｏＣｈｉｌｄＮｏｄｅメソッド）を更新するだけで、すなわち、プロキシとして機能する既存のオブジェクトを変更することにより、フライウェイトパターンとして使用することもできる。
図１４Ａ〜図１４Ｃは、第１のキーはキー部分値［００，０２，０２］を有し、第２のキーはキー部分値［００，０３，００，０１］を有する２つのキーを空のトライに挿入する場合のトライの成長を示す。図１４Ａは、値０を有するルートインデックスポインタによって示される空トライを示す。図１４Ｂは、キー部分値［００，０２，０２］を有する第１のキーを追加した後のトライを示す。前のエントリがないため、第１のキーは末端最適化を使用して格納される。図１４Ｃは、キー部分値［００，０３，００，０１］を有する第２のキーを追加した後のトライを示す。既存の末端ノードは分割される。１つのみの子を有するため、一致するプレフィックス（「００」）は連鎖ノードとして格納され、その後、２つの子ノード（「０２」及び「０３」）を有する通常ノードが続く。第１のキーの残り（「０２」）は、リーフ部を有するノードとして格納される（末端最適化を用いての格納はより多くの空間を必要とする）。第２のキーの残り（「００」及び「０１」）はここでも、末端最適化を使用して格納される。
本発明の様々な実施形態によるデータ構造の空間要件を測定するために、完全長整数値範囲を有する長整数の無作為集合が格納される実験を行った。図１５は測定結果を示し、ｘ軸は、トライインデックスにロードされたエントリ数を対数尺度で示し、ｙ軸は、１エントリの格納に必要とされた平均バイト数を示す。
連鎖ノード最適化単独で、空間要件は約４０％低下し、末端最適化単独で約６０％〜約７０％低下したことを観察することができる。連鎖ノード最適化と末端最適化との組合せは、末端最適化単独と比較して目に見える空間改善を提供しなかった（グラフは末端最適化の場合と重なる）。しかしながら、本発明者により実行された経験的測定は、両最適化を一緒に適用することに価値がまだあること示した。連鎖ノード最適化が末端最適化に加えて適用される場合、辿る必要があるポインタ数が少なく、データ局所性がより高く、メモリ階層（ＣＰＵキャッシュ）を守るため、性能は高まる。
ビットマップ圧縮
本発明の第３の空間最適化は、メモリにおいて、トライが疎に存在するトライのよりコンパクトな表現を提供する。これは、同じ値のセクション（例えば、疎に存在するノードの場合、値０を有するセクション又は密に存在するノードの場合、値１を有するセクション）を群化し効率的に格納することにより、ビットマップ（例えば、子ノードのキー部分値を示すビットマップ）のメモリ空間を低減することができる。本明細書ではこの第３の空間最適化を「ビットマップ圧縮」と呼ぶ。
本発明の第３の空間最適化は、１つ又は複数のノードを含むトライに適用され、ここで、２つ以上の子ノードを有するノード、好ましくは少なくとも各親ノードは、論理ビットマップの形態のビットマップと、幾つかのポインタとを含み、各ポインタには論理ビットマップにおいて設定されたビットが関連付けられ、各ポインタはノードの子ノードを指す。論理ビットマップは、本発明の他の態様に関して述べたように、キー部分値を含むビットマップに対応する。最適化は、論理ビットマップが複数のセクションに分割され、ヘッダビットマップ及び幾つかのコンテンツビットマップによって符号化されることにより達成され、ここで、各セクションにはヘッダビットマップ内のビットが関連付けられ、１つ又は複数のビットが設定された論理ビットマップの各セクションについて、ヘッダビットマップ内のセクションに関連付けられたビットは設定され、セクションはコンテンツビットマップとして格納される。
ヘッダビットマップ及び幾つかのコンテンツビットマップを使用して、論理ビットマップを格納することは、ビットが設定されていない論理ビットマップのセクションのコンテンツビットマップを省くことによって必要とされるメモリ空間を大幅に低減することができる。換言すれば、少なくとも１つの設定ビットを有するコンテンツビットマップ（すなわち、論理ビットマップのセクション）のみがメモリに格納される。論理ビットマップの各セクションが少なくとも１つの設定ビットを有する最悪の状況では、追加のヘッダビットマップを格納する必要があるため、メモリ使用はわずかに増大する。しかしながら、ノードは一般に疎に存在し、したがって通常、ビットマップ圧縮を使用する場合、必要なメモリは少なくなる。
本発明のビットマップ圧縮の一実施形態を図１６に示し、図１６は、ビットマップ圧縮なしの論理ビットマップ１６０２を含む親ノードを有するトライ１６０１のセクションを上部に示す。図１６の下部において、ビットマップ圧縮がトライ１６０１の親ノードに適用された後に得られた親ノードを有するトライ１６１１のセクションを示す。トライ１６１１の親ノードは、ビットマップ圧縮から生じたヘッダビットマップ１６１２及び２つのコンテンツビットマップ１６１３、１６１４を含む。
両トライ１６０１、１６１１内の親ノードはポインタ１６０３〜１６０５を更に含む。トライ１６０１において、各ポインタには、論理ビットマップ１６０２において設定されたビット１６０６〜１６０８が関連付けられる。トライ１６１１では、ポインタ１６０３〜１６０５には、コンテンツビットマップにおいて設定されたビット１６１６〜１６１８が関連付けられる。
トライ１６０１内の論理ビットマップは、下部１６１１において、論理ビットマップ１６０２をセクション１６２１（例えば、８ビットの）に分割し、少なくとも１つの設定ビットを有するセクション１６２２、１６２３をコンテンツビットマップ１６１３、１６１４に格納することにより、ヘッダビットマップ１６１２及びコンテンツビットマップ１６１３、１６１４に変換される。設定されたビットがないセクションは、コンテンツビットマップとして格納されない。ヘッダビットマップ１６１２内の各ビットは、論理ビットマップの異なるセクションを表す。コンテンツビットマップ１６１３、１６１４は、ヘッダビットマップ１６１２において設定された各ビット１６１９、１６２０によって参照される。コンテンツビットマップ１６１３、１６１４は、セクションに関連付けられた設定ビット１６１９、１６２０がヘッダビットマップ１６１２に配置されるのと同順（図示せず）又は逆順で格納し得る。換言すれば、論理ビットマップの全てのコンテンツビットマップ内のあるコンテンツビットマップのランクは、ヘッダビットマップ内の全ての設定ビット内のそのコンテンツビットマップのセクションに関連付けられた設定ビットのランクに対応し得る。このようにして、トライを処理しながらコンテンツビットマップを容易にアドレス指定することができる。また、論理ビットマップのセクションは、好ましくは、メモリ内で全てコヒーレントである。したがって、論理ビットマップ全体は、ヘッダビットマップに続く幾つかのコンテンツビットマップにより、メモリにおいてコヒーレントに表すことができる。
好ましい実施形態では、全てのセクションは同じサイズを有する。同じサイズのセクションは、セクションの構造についての更なる情報が必要ないため、論理ビットマップの圧縮及び圧縮解除の効率的な処理を可能にする。また、ヘッダビットマップもセクションと同じサイズであり得る。
ヘッダビットマップ及びコンテンツビットマップの格納に異なる構造を使用することもできる。論理ビットマップのヘッダビットマップ及びコンテンツビットマップは、配列、リスト、又は連続した物理若しくは仮想メモリロケーションに格納し得る。図１６に示すように、ヘッダビットマップ及びコンテンツビットマップが１バイトのサイズを有する場合、ビットマップは、トライ１６０１又は図９及び図１２〜図１４のトライで行われるように、長整数の配列の代わりにバイトの配列に格納し得、これにより位置合わせ損失が低減する。コンテンツビットマップは、好ましくは、ヘッダビットマップに相対して予め定義されたメモリ位置に格納される。コンテンツビットマップ及びヘッダビットマップを互いの近くに格納することにより、処理効率を改善し得る。図１６では、コンテンツビットマップは、メモリにおいてヘッダビットマップの直後に格納される。
上述したビットマップ圧縮は、子ノードの参照に使用されるポインタのようなポインタに適用することもでき、直列化リーフビットマップに適用することもできる。これは通常、空間効率を更に改善するが、性能を損ない、その理由は、特定のポインタのオフセットを計算する際、可変サイズ符号化により、ポインタを通して反復する必要があるためである。
ビットマップ圧縮は、本発明の他の態様と組み合わせ得る。例えば、ポインタ低減と組み合わせて、ビットが設定されていない（論理）ビットマップにより記される本発明による末端分岐ノードは、いかなるコンテンツビットマップもなく、ヘッダビットマップのみとして符号化し得る。
図１７は、図１５を参照して上述した実験の結果を示す。しかしながら、連鎖ノード最適化及び末端最適化に加えて、ビットマップ圧縮が適用された。図１５との比較において観察することができるように、ビットマップ圧縮により達成された空間節約は、連鎖ノード又は末端最適化が適用されない場合、約４０％であり、連鎖ノードのみが加えて適用された場合、約５０％〜約７０％であり、末端最適化のみ又は連鎖ノード及び末端最適化の両方が加えて適用された場合、約３０％〜約６０％である。
キー符号化
本発明は、固定サイズ又は可変サイズのキー（例えば、文字列）を有する異なるプリミティブデータ型のキー及びトライ内のプリミティブデータ型の２つ以上の項目を含む複合キーを格納する方法を提供する。
制御情報を含むキー
本発明の好ましい実施形態では、キーは、キーに格納された構成要素の数、データ型、又は長さについての事前知識なしであっても、例えば、カーソルにより反復することができるような柔軟な方法で符号化することができる。
これらの実施形態は、データベースアプリケーション又は情報検索システムで使用されるトライ、例えば、上述したトライ及びトライデータ構造の実施形態の１つによるトライ又はトライデータ構造に適用される。トライは１つ又は複数のノードを含み、ノード、好ましくは各子ノードにはキー部分が関連付けられ、ルートノードからトライ内の別のノード、特にリーフノードへのパスは、ノードに関連付けられたキーを定義し、キーは、パス上のノードに関連付けられたキー部分を連結したものである。上述した柔軟性は、キーが、コンテンツ情報に加えて制御情報を含むことにより達成される。
キーは通常、１つ又は複数のキー部を含み、各キー部はコンテンツ情報を含み、コンテンツ情報は、キーに含まれる全体コンテンツ情報の一部である。キー部のそれぞれについて、制御情報は好ましくは、キー部に含まれるコンテンツ情報のデータ型を指定するデータ型情報要素を含む。
原理上、キー部に関連付けられた制御情報及びコンテンツ情報を配置する２つの方法がある。第１の方法を図１８に示し、図１８では、キー部又は好ましくは各キー部１０、２０、３０は、データ型情報要素（図１８における陰影付き要素）及びコンテンツ情報要素を含む。データ型情報要素は、コンテンツ情報要素のデータ型を指定する。これは、制御情報及びコンテンツ情報が両方とも異なるキー部１０、２０、３０にわたり分散していることを意味する。この場合、キーのデータ型情報要素又は各データ型情報要素は通常、好ましくはデータ型情報要素の（直）前に、キー内のデータ型情報要素に関連付けられたコンテンツ情報要素によって配置される。したがって、データ型情報要素は、キー部１０、２０、３０のプレフィックス又はヘッダ要素のようである。
キー部に関連付けられた制御情報及びコンテンツ情報を配置する第２の方法を図１９に示し、図１９は、データ型情報要素（図１９における陰影付き要素）は、一緒に配置され、好ましくは、データ型を指定するコンテンツ情報要素と同順又は逆順で配置される。データ型情報要素のような制御情報は、好ましくは、キーのプレフィックス又はヘッダ要素として、キーにおいてコンテンツ情報の前に配置される。本発明者によって行われた研究では、同じデータ型を有するキーが同じプレフィックス（トライ内の開始ノード）を有し、したがって、トライ内で必要とされるノード数が低減し、空間節約に繋がるため、データ型情報要素を格納するこの第２の方法が好ましいことが分かった。
キー部に関連付けられたコンテンツ情報のデータ型は整数、長整数、倍精度浮動小数点、若しくは時間／日付けプリミティブの場合等の固定サイズであってもよく、又は文字列、例えば、ユニコード文字列若しくは可変精度整数の場合等の可変サイズであってもよい。本発明の幾つかの実施形態では、キーは、異なる（プリミティブ）データ型のコンテンツ情報を含む２つ以上のキー部を含む。
図２０及び図２１を参照して以下に説明するように、制御情報は、例えば、データ型情報要素の高位ビットのステータスによって最後のキー部を識別する情報を含み得る。代替的には、キー部カウントは別個に格納することができる。更に、制御情報は、トライが動的集合の格納に使用されるか、それとも連想配列の格納に使用されるかについての情報を含み得る。
キー部のコンテンツ情報は、１つのキー部分に含まれ得るが、通常、２つ以上のキー部分に含まれる。固定サイズのキー部の場合、キー部に含まれるコンテンツ情報を含むために必要なキー部分の数は通常、既知である。キー部に含まれるコンテンツ情報のデータ型が可変サイズのデータ型である場合、コンテンツ情報要素の終わりは、特定のシンボル、例えば、文字列の最後の文字としてヌル文字（「
Figure 2021517306
 」、ＡＳＣＩＩではＮＵＬと呼ばれる）を有するヌル終端文字列により記し得る。代替的又は好ましくは、図２１を参照してユニコード文字列について以下に説明するように、キー部を含むキー部分の特定の１つ内の特定のビットによって記し得る。
上述したように、キー部のコンテンツ情報は多くの場合、２つ以上のキー部分に含まれるが、キー部分は、好ましくは、２つ以上のキー部のコンテンツ情報を含まない。換言すれば、キー部のコンテンツ情報は、キー部分の境界と位置合わせされる。同様に、キー部分は、好ましくは、データ型情報要素、キー部カウント、又はトライが動的集合の格納に使用されるか、それとも連想配列の格納に使用されるかについての情報のような２つ以上の制御情報要素の情報を含まない。この手法は通常、大きな位置合わせ損失なしで、実装をより容易且つ効率的にする。更に、これにより、以下に説明するように、異なるキー部のコンテンツ情報をインタリーブ様式で格納できるようになる。
本発明によるキー符号化の一例を図２０に示す。トライに格納するキーは、制御情報２０１０及びコンテンツ情報２０２０を含む。キーは、コンテンツ情報を含む幾つかのキー部を含み、キー部のそれぞれについて、制御情報２０１０は、キー部に含まれるコンテンツ情報のデータ型を指定するデータ型情報要素２０１２、２０１３を含む。更に、制御情報２０１０は、トライが動的集合の格納に使用されるか、それとも連想配列の格納に使用されるかについての情報２０１１を含む。トライが連想配列の格納に使用される場合、キーに関連付けられたトライのリーフノードは通常、リーフ値２０３０又はそのようなリーフ値へのポインタを含む。
上述したように、本発明の好ましい実施形態では、トライ内の各親ノードは６４ビット幅ビットマップを含み、したがって、トライ内の各キー部分は６ビット値を格納することが可能である。トライが動的集合の格納に使用されるか、それとも連想配列の格納に使用されるかについての情報２０１１は、第１のキー部分によって格納され、したがって、６ビットがこの情報に使用される。実際には、このイエス／ノー情報に対して１ビットで十分であるが、上述した位置合わせの理由で、６ビット値を格納可能なキー部分全体が使用される。情報は、各ビットが設定された６４ビット幅ビットマップ及びノード２０４１の各子ノードへのポインタ（ｉｄｘ）を含む情報がノード２０４１に符号化される。
データ型情報要素２０１２、２０１３のそれぞれも、１つのキー部分によって格納され、その値はノード２０４２、２０４３のビットマップに符号化される。５ビットがデータ型情報に使用され、それにより、３２個の異なるタイプの識別子が可能である。各キー部分によって格納することができる６番目のビット、例えば、キー部分の高位ビットは、データ型情報要素に関連付けられたキー部がキー内の最後のキー部であるか否かを示すのに使用される。図２０の例では、データ型情報要素２０１３の高位ビットは、データ型情報要素２０１３に関連付けられたキー部がキー内の最後のキー部であることを示すように設定される。
各キー部に含まれるコンテンツ情報も、一般に６ビットの値２０２１、２０２２に分解され、各値は１つのキー部分によって格納される。ビットマップが（６ビット）値２０２１、２０２２の符号化に使用されるノードは、スペースの理由で図２０に示されていない。例えば、キー部が３２ビット整数値を含む場合、この３２ビット値は６つのキー部分によって格納され、そのうちの最初のキー部分は２ビット値を格納し、最後の５つはそれぞれ６ビット値を格納する（３２＝２＋６＋６＋６＋６＋６）。
図２１は、本発明により符号化されたキーを格納するトライを示す。トライの各親ノードは、６４ビット幅ビットマップを含む。キーは、値「１００」を有する３２ビット整数を含む第１のキー部と、値「ａｂ」を有する文字列を含む第２のキー部とを含む。キーの制御情報は、（１）動的集合識別子、（２）整数識別子、及び（３）最後のタイプのマーカを有する文字列型識別子を含む。キーのコンテンツ情報は、（１）３２ビット整数値「１００」及び（２）ユニコードで符号化された文字列値「ａｂ」を含む。
動的集合識別子は値０の６ビット数（０ｘ００）である。したがって、図２１のトライのルートノード２１００のビットマップは、値「０」が設定されたビットを有し、このビットに関連付けられた第２レベルのノードには、値「０」のキー部分が関連付けられる。整数識別子は値５の６ビット数（０ｘ０５）である。したがって、第２レベルのノードのビットマップは、値「５」が設定されたビットを有し、このビットに関連付けられた第３レベルのノードには、値「５」のキー部分が関連付けられる。最後のキー部のマーカを有する文字列型識別子は、値３９の６ビット数（０ｘ２７）である。したがって、第３レベルのビットマップは値「３９」が設定されたビットを有し、このビットに関連付けられた第４レベルのノードには、値「３９」のキー部分が関連付けられる。
整数値「１００」は、「００ ００００００ ００００００ ００００００ ０００００１ １００１００」として３２ビット二進数で符号化される。したがって、整数値「１００」の格納に使用されるレベル５〜レベル１０のノードに関連付けられたキー部分には、値０（０ｘ００）、０（０ｘ００）、０（０ｘ００）、０（０ｘ００）、１（０ｘ０１）、及び３６（０ｘ２４）がそれぞれ関連付けられる。
文字列値「ａｂ」は、文字「ａ」のユニコード値の後に、文字「ｂ」のユニコード値が続くものとして符号化される。各ユニコード文字は、ユニコード値に応じて２〜４個のキー部分を使用して格納され、これは１０ビット、１５ビット、又は２１ビットを必要とし得る。本発明の好ましい実施形態で使用されるユニコード文字の符号化方式は以下である：
１０ビットユニコード文字：００ｘｘｘｘ ｘｘｘｘｘｘ
１５ビットユニコード文字：０１０ｘｘｘ ｘｘｘｘｘｘ ｘｘｘｘｘｘ
２１ビットユニコード文字：０１１ｘｘｘ ｘｘｘｘｘｘ ｘｘｘｘｘｘ ｘｘｘｘｘｘ
文字列内の最後の文字は、高位ビットを設定することによって記され、これにより、最後の文字の符号化方式は以下になる：
１０ビットユニコード文字：１０ｘｘｘｘ ｘｘｘｘｘｘ
１５ビットユニコード文字：１１０ｘｘｘ ｘｘｘｘｘｘ ｘｘｘｘｘｘ
２１ビットユニコード文字：１１１ｘｘｘ ｘｘｘｘｘｘ ｘｘｘｘｘｘ ｘｘｘｘｘｘ
ユニコード文字「ａ」は値９７（０ｘ６１）を有し、「０００１ １００００１」として１０ビットを用いてユニコードで符号化される。好ましい実施形態で使用される符号化方式によれば、ユニコード文字「ａ」は「０００００１ １００００１」として符号化される。ユニコード文字「ｂ」は値９８（０ｘ６２）を有し、「０００１ １０００１０」として１０ビットを用いてユニコードで符号化される。好ましい実施形態で使用される符号化方式によれば、ユニコード文字「ｂ」は「１００００１ １０００１０」として符号化され、「ｂ」は値「ａｂ」を有する文字列内の最後の文字であるため、高位ビットが設定される。したがって、文字列値「ａｂ」の格納に使用されるレベル１１〜１４のノードに関連付けられたキー部分には、値１（０ｘ０１）、３３（０ｘ２１）、３３（０ｘ２１）、及び３４（０ｘ２２）がそれぞれ関連付けられる。
インタリーブされた多項目キー
本発明の実施形態は、２つ以上のデータ項目を含むクエリをより効率的に実行することができるようにデータを格納する方法を提供する。本発明による手法は特に、より効率的に問い合わせることができるように、キー若しくはキー及び値をデータベース又は情報検索システムに格納し、データベース又は情報検索システムクエリの結果キー若しくは結果キー及び結果値を格納し、又はクエリをより効率的に実行することができるように、データベースクエリの入力キー若しくは入力キー及び入力値を格納するのに有用である。
本発明のデータを格納する方法は上述したデータ構造を有するトライ等のトライを使用し、トライはノードを含み、ノード、好ましくは各子ノードにはキー部分が関連付けられ、ルートノードからトライ内の別のノードへのパスは、ノードに関連付けられたキーを定義し、キーは、パス上のノードに関連付けられたキー部分を連結したものである。複数のデータ項目を含むクエリにおいて性能利得を達成するために、２つ以上のデータ項目がキーに符号化され、少なくとも１つ又は２つのデータ項目、好ましくは各データ項目は２つ以上の構成要素からなる。キーは、２つ以上の連続セクションを含み、少なくとも１つ又は２つのセクション、好ましくは各セクションは、キーに符号化されたデータ項目の２つ以上の構成要素を含む。「項目」は、本明細書では「次元」と呼ばれることもあり、上記の「キー部」又は「キー部のコンテンツ情報」と呼ばれるものに対応し得る。
図２２は、値（Ｘ＝１２，Ｙ＝４５）を有する二次元キー、すなわち、２つのデータ項目Ｘ及びＹを符号化するキーの一例を示す。これらのデータ項目は両方とも、項目Ｘの場合、２つの構成要素、すなわち、「１」及び「２」からなり、項目Ｙの場合、「４」及び「５」からなる。キーは、２つの連続セクションＳ１及びＳ２を含む。両セクションは、キーに符号化されたデータ項目ｘ及びｙのそれぞれの１つの構成要素を含み、セクションＳ１は、データ項目Ｘの１番目の構成要素「１」及びデータ項目ｙの１番目の構成要素「４」を含み、セクションＳ２は、データ項目Ｘの２番目の構成要素「２」及びデータ項目Ｙの２番目の構成要素「５」を含む。好ましい実施形態では、キーが、Ｘ１Ｙ１Ｘ２Ｙ２等のインタリーブ様式で複数のデータ項目を符号化すると言える。
好ましい実施形態によれば、キーの符号化は、キーのセクション、好ましくは各セクションが、キーにおいて符号化された各データ項目から少なくとも及び／又は多くとも１つの構成要素を含むようなものである。例えば、図２２に示されるキーの両セクションＳ１及びＳ２は、キーに符号化されるデータ項目Ｘ＝１２及びＹ＝４５のそれぞれの厳密に１つの構成要素を含む。
更に、キーの２つ以上、好ましくは全てのセクションについて、異なるデータ項目に属する構成要素は、セクション内で同じシーケンスで並べられる。例えば、図２２に示されるキーの両セクションにおいて、構成要素は、データ項目Ｘの構成要素が最初に来て、データ項目Ｙの構成要素が次に来るようなシーケンスで並べられる。
更に、データ項目の構成要素を含むセクションの順序は、好ましくは、データ項目内の構成要素の順序に対応する。例えば、図２２に示されるキーでは、セクションＳ１の後にセクションＳ２が続き、これは各項目内でキーが構成要素を含む順序に対応し、Ｓ１は項目Ｘの構成要素「１」を含み、これは、項目Ｘ内で、セクションＳ２に含まれる構成要素「２」の前に来る。Ｓ１は項目Ｙの構成要素「４」も含み、これは、項目Ｙ内で、セクションＳ２に含まれる構成要素「５」の前に来る。
キーの２つ以上、好ましくは全てのデータ項目は、同数の構成要素を有する。例えば、図２２に示されるキーに符号化される項目Ｘ及びＹは両方とも２つの構成要素を有する。しかしながら、キーのデータ項目は、異なる数の構成要素を有することもできる。これは、例えば、１つの項目が６４ビット整数であり、別の項目が３２ビット整数である場合であり得る。キーがＸ１Ｙ１Ｘ２Ｙ２等の厳密に規則正しいインタリーブ様式でデータ項目を符号化する場合、少数の構成要素を有するデータ項目を充填し得、結果として、例えば、Ｘ１Ｙ１Ｘ２Ｙ２Ｘ３＊Ｘ４＊等になる。代替的には、例えば、Ｘ１Ｙ１Ｘ２Ｙ２Ｘ３Ｘ４になるようにインタリーブ手法を変更する必要があり得る。
図２３は、図２２に示されるキーをトライにいかに格納することができるかの一例を与える。好ましい実施形態では、子ノード、好ましくは各子ノードに関連付けられたキー部分は、データ項目の一構成要素に対応する。換言すれば、データ項目、好ましくは各データ項目の構成要素、好ましくは各構成要素は、トライの１つの子ノードに関連付けられたキー部分に対応する。図２３の例では、第２レベルのノード２３０２には、項目Ｘの最初の構成要素に対応するキー部分１が関連付けられ、第３レベルのノード２３０３には、項目Ｙの最初の構成要素に対応するキー部分４が関連付けられ、第４レベルのノード２３０４には、項目Ｘの２番目の構成要素に対応するキー部分２が関連付けられ、第５レベルのノード２３０５には、項目Ｙの２番目の構成要素に対応するキー部分５が関連付けられる。これは好ましくないが、子ノードに関連付けられたキー部分は、データ項目の構成要素の一部のみ又はデータ項目の２つ以上の構成要素に対応することもできる。
図２２及び図２３の例では、データ項目Ｘ及びＹは２桁の十進数であり、構成要素は十進数である。本発明によるトライに格納されるキーに符号化されるデータ項目の他の例は、経度又は緯度等のジオロケーションデータ、インデックス、整数、長整数若しくは倍長整数、３２ビット整数、若しくは６４ビット整数等の任意の種類若しくはデータ型の数、文字列、バイト配列、又はこれらの２つ以上の組合せである。
データ項目が数である場合、データ項目の構成要素は数字（図２２及び図２３の例のように）であり得る。データ項目が文字列の場合、データ項目の構成要素は一文字であり得る。データ項目がバイト配列の場合、データ項目の構成要素は１バイトであり得る。
しかしながら、好ましい実施形態では、データ項目の構成要素は、データ項目の二進数符号化のビット群であり、ビット群は好ましくは６ビットを含む。これは、先に説明したように、好ましい実施形態では、子ノードのキー部分の値が、ビットが子ノードに関連付けられた親ノードに含まれるビットマップ内の（設定）ビットの値によって決まるためである。その結果、ビットマップのサイズは、キー部分に可能な英字を定義する。例えば、各ビットマップが６４ビットサイズを有する場合、ノードのキー部分に利用可能な異なる値の数は２６である。これは、データ項目の二進数符号化の６ビットを含むビット群を、ノードに関連付けられたキー部分で表すことができることを意味する。３２ビットビットマップが使用される場合、５ビットを含む群を表すことができる等である。
例えば、データ項目が６４ビット長整数であり、各構成要素が、整数の二寸数符号化の６ビット群である場合、データ項目は６４／６＝１１個の構成要素を有する。データ項目がユニコードで符号化される文字である場合、先に説明したように、２ビット〜６４ビットの構成要素を有し得る。データ項目が、幾つかの文字で構成される文字列である場合、好ましい実施形態における構成要素はなお６ビット群であり、すなわち、文字列は、任意の他のデータ項目のように、同じタイプの構成要素（６ビット群）を有する。文字列の数構成要素は、１文字の構成要素の数を文字列内の文字数で乗算したものに対応する。
ビット群、例えば、６ビット群として好ましい実施形態の構成要素を見なす代わりに、予め定義された基数又は底、例えば６４を有する数字として見なすこともできる。
複数のデータ項目を有するキーを格納するインタリーブ方法は、図４５及び図４６並びに図６１〜図６５を参照した範囲クエリの以下の説明から容易に明らかになるように、複数のデータ項目を含む範囲クエリの性能を大きく改善することができる。更に、インタリーブ格納が、双方向サーチ及び複数のデータ項目を含む「ＮＯＴ」演算を含むサーチで性能を改善することができることを当業者は理解しよう。
集合演算
本発明の実施形態は、データベース若しくは情報検索システムに格納された２以上のキーの集合又はデータベースクエリ若しくは情報検索システムクエリの結果キーの集合に対する論理積（ブールＡＮＤ）、論理和（ブールＯＲ）、差分（ブールＡＮＤ ＮＯＴ）、及び排他的論理和（ブールＸＯＲ）等の演算を含むデータベース又は情報検索システムにおいてクエリを実行する時間効率的な方法を提供する。本明細書では、これらの演算は「集合演算」又は「論理演算」と呼ばれる。
なお大半のデータベースはＶｏｌｃａｎｏ処理モデルを使用しており、これは「一度に１タプル」を意味する。しかしながら、これは、複数レベルのキャッシュ及びインメモリデータベースを考慮すると、近代のＣＰＵアーキテクチャには効率的ではない。物理的実行プラン内の全ての演算は密にインタリーブされて実行されるため、演算子の結合命令フットプリントは、大きすぎて命令キャッシュに収まらないことがあり、演算子の結合状態は、大きすぎてデータキャッシュに収まらないことがある。したがって、幾つかのデータベースは一度に１演算子モデル又は両方の組合せであるベクトル化実行モデルを適用する。本発明によるインデックスデータ構造及び統一されたレベル単位処理モデルは、インデックストライへのアクセス及び演算子実装に関して非常にリーンな命令フットプリントを生じさせる。
図２４は、従来技術によるデータベースクエリ処理の様々なフェーズの例示的な流れ図を示す。クエリは解析され（２４０１）、書き換えられ（２４０２）、最適化され（２４０３）、クエリ実行エンジン（ＱＥＥ２４０５）がデータベース２４０６への先行ステップにより生成されたＱＥＰを実行することができるようにクエリ実行プランＱＥＰが準備され改善される（２４０４）。
図２５は、従来技術によるデータベースで使用される例示的なＱＥＰを示す。ＱＥＰはツリーで表され、ツリーでは、親ノード２５０１、２５０２は演算子であり、リーフ２５０３、２５０４はデータソースである。最初の演算では、テーブルスキャン２５０４からの結果はソート演算子２５０２によってソートされる。２番目の演算では、ソートの結果はインデックススキャン２５０３の結果と併合結合される。
図２６は、従来技術によるデータベースの反復子ベースの実行モデルにおける演算子制御及びデータフローを示し、ここでは、演算子は以下のメソッドを実施する：Ｏｐｅｎ（データの生成に向けて演算子を準備する）、Ｎｅｘｔ（演算子消費者の需要下で新しいデータユニットを生成する）、及びＣｌｏｓｅ（実行を終了させ、リソースを解放する）。Ｎｅｘｔメソッドへの各呼び出しは新しいタプルを生成する。
反復子ベースの実行モデルは、演算子の統一モデルを提供し、この統一モデルは、データソース（データベーステーブル又はデータベースインデックス）のデータモデルから独立し、演算子ノードの中間結果を統一する。しかしながら、データの１つのみのユニット、例えば、レコードのみが演算子呼び出し毎に送られる。この手法は、それら実施形態が小さな結果集合を返す大きなサブ結果集合を結合する演算子にとっては非効率的である。
図２７に示されるように、タプルを他の演算子に渡してもよく、図２７は、従来技術によるデータベースのクエリ実行モデルによる一度の１タプル処理を示す。ルート演算子２７０１から始まり、ｎｅｘｔ（）への呼び出しは演算子の子２７０２、２７０３に伝搬され、データソース（及びツリー表現のリーフ）に達するまで以下同様である。このようにして、制御は消費者から生産者まで下に流れ、データはクエリ実行プラン演算子ツリー内で生産者から消費者に上に流れる。
１度に１タプル処理モデルは、小さな中間結果、ひいては低メモリ要件を有する。実行プラン内の演算子は密にインタリーブされて実行され、かなり複雑であり得る。しかしながら、膨大な量の関数呼び出し及び全演算子の結合状態は、大きな関数呼び出しオーバーヘッド並びに命令及びデータキャッシュミスを生じさせ、その理由は、フットプリントが往々にして大きすぎ、ＣＰＵキャッシュに収まらないためである。
反復子ベースの実行モデル及び１度に１タプル処理モデルは両方とも、効率的であるには、高度なクエリオプティマイザを必要とする。
図２８は、リストのような、適したデータ構造で、演算子の結果として全てのタプルを即座に返す、従来技術によるデータベースのクエリ実行モデルによる１度に１演算子処理を示す。１度に１演算子手法は、低関数呼び出しオーバーヘッドを有する密なループを有してキャッシュ効率的であるが、データキャッシュに収まらず、更にはメインメモリにも収まらないことがある大きな中間結果を演算子毎に生み出し、この手法を無用なものにし得る。
本発明は、全てのデータソースがトライである新規の実行モデルにより従来技術の問題を解決する。２つ以上の入力トライが各論理演算（集合演算）に従って組み合わせられて、各結果トライのノードに関連付けられたキーの集合を取得する。
次に、データベースクエリは、出力として結果トライの表現、結果トライのノードに関連付けられたキーの集合若しくは結果トライのノードに関連付けられたキーの部分集合、特に結果トライのリーフに関連付けられたキー、又は結果トライのノードに関連付けられたキーから導出されるキー若しくは値の集合を提供する。代替的には、ドキュメント識別子のように結果トライのノードに関連付けられた他のデータ項目を提供し得る。出力として提供されるキーの集合は、トライで、例えば物理的トライデータ構造で提供し得る。「結果トライ」の概念は、本明細書では、論理演算を使用して入力をトライを結合する場合、取得する必要があるキーの集合を定義するのに使用されることに留意されたい。しかしながら、結果トライは、入力トライの結合中、必ずしも物理的トライデータ構造で形成される必要はなく、キーの出力集合は、例えば、カーソル又は反復子により提供することもできる。
一般的に言えば、論理演算を使用した２つ以上の入力トライの結合は、各入力トライにより記憶されたキーの各集合が論理演算を使用して結合される場合、取得されるキーの集合を記憶する（結果）トライを生成する。特に、論理演算が差（ＡＮＤ ＮＯＴ）である場合、結果トライ内の親ノードは第１の入力トライ内の親ノードであり、結果トライの親ノードのリーフは、第１の入力トライ内の対応する親ノードの子ノードの集合と他の入力トライがある場合、他の入力トライ内の対応する親ノードの子ノードの集合とのＡＮＤ ＮＯＴ結合である。論理演算が差分ではない場合、例えば、論理演算が論理積（ＡＮＤ）、論理和（ＯＲ）、又は排他的論理和（ＸＯＲ）である場合、結果トライ内の各ノードの子ノードの集合は、入力トライ内の対応するノードの子ノードの集合の論理演算（例えば、ＡＮＤ、ＯＲ、又はＸＯＲ）を使用した結合である。この状況では、各子ノードにキー部分に関連付けられ、ルートノードからトライ内の別のノードへのパスが、ノードに関連付けられたキーを定義し、キーは、パス上のノードに関連付けられたキー部分を連結したものであり、異なるトライの２つ以上のノードは、異なるトライのノードに関連付けられたキーが同一である場合、互いに「対応」する。
好ましい実施態様では、あらゆる演算子はそれ自体、例えば、各トライ（ノード）インターフェース実装することにより、クエリ実行プランツリー内のルート演算子ノードまで、消費者が論理演算を使用する別の演算子である場合を含めて消費者へのトライとして再び出現する。そのようなトライノードインターフェースはトライノードを表し、表すトライノードの子ノードにクエリ及び／又はトラバースする方法又は関数を提供し、トライの表現はトライのルートノードを表す。したがって、反復子インターフェースを使用する代わりに、ノードインターフェースを使用することができる。これにより、機能構成及びより簡易でクリーンなソフトウェアアーキテクチャが可能になり、データベースエンジンの性能を更に改善し、その理由は、実装複雑性の低さが直接、関数呼び出しオーバーヘッドの低減並びにデータ及び命令キャッシュミスの低減に繋がるためである。
好ましくは、トライを実装するデータ構造は上述したようなものである。特に、入力トライ内のノード、特に、少なくとも入力トライ内の全ての親ノードがビットマップを含み、トライ内の子ノードのキー部分の値が、ビットが子ノードに関連付けられた親ノードに含まれるビットマップのビット（集合）の値により決定される場合、有利である。通常、結果トライのノードの子ノードの集合は、論理演算を使用して、結果トライのノードに対応する入力トライのノードの子ノードの集合を結合することにより決定される。そのような実施態様では、入力トライの対応するノードの子ノードの集合の結合は、ビット単位ＡＮＤ、ビット単位ＯＲ、ビット単位ＡＮＤ ＮＯＴ、又はビット単位ＸＯＲ等の論理演算を使用して入力トライの対応するノードのそれぞれのビットマップをビット単位で結合することにより容易に実行することができる。結合ビットマップが得られ、結合の結果が結合ビットマップに基づいて実行される。換言すれば、結果トライのノードの子ノードは、結合ビットマップに基づいて、好ましくは結合ビットマップのみに基づいて決定（評価）される。その結果、ビットマップを結合するステップは、結果トライのノードの子ノードが決定される前且つ結果トライの評価が結果トライのノードの子ノードにトラバースされる前、実行される。
したがって、トライの実施態様における物理代数は、集合演算の論理代数に直接対応する。従来技術では、ビットマップはトライにおいて、ポインタに必要なメモリ空間を低減するためだけに使用されるが、本発明は、トライに対して集合演算を実行するためにビットマップを利用する。
上述したように、「ＣＤＢＩＮｏｄｅ」と呼ばれるトライノードインターフェースの例示的な実施態様は以下の主要メソッドを有する：ｇｅｔＢｉｔＳｅｔ（）−トライノードの全ての非空子ポインタの設定ビットを有するビットマップを返す−及びｇｅｔＣｈｉｌｄＮｏｄｅ（ｂｉｔＮｕｍ）−ビット数によって指定される所与のノード分岐の子ノードを返す。
図２９は、本発明のクエリ実行モデルによるトライ制御及びデータフローを示す。演算子２９０３は、集合演算、例えば、論理積、論理和、差分、又は排他的論理和を入力ベースデータの２つの集合２９０１、２９０２に対して実行する。ベースデータの２つの集合はそれぞれ入力トライで提供され、例えば、物理的トライデータ構造に記憶され、２つの入力トライは、各集合演算に従って演算子２９０１により結合される。演算子２９０３はそれ自体、入力トライと同じトライ（ノード）インターフェースを実施することにより、その消費者にとってトライとして見える。エグゼキュータ２９０４は、上述したトライノードメソッドｇｅｔＢｉｔＳｅｔ及びｇｅｔＣｈｉｌｄＮｏｄｅを呼び出して、エグゼキュータと演算子との間の破線矢印で示されるように、演算子２９０３によって提供される結果をトラバースする。演算子と入力トライとの間の破線矢印によって示されるように、集合演算子を実行する際、同じメソッドｇｅｔＢｉｔＳｅｔ及びｇｅｔＣｈｉｌｄＮｏｄｅは、演算子２９０３によって呼び出されて、入力トライ２９０１、２９０２をトラバースする。実線矢印で示されるデータフロー方向において、ビットマップ及び子トライノードは入力トライ２９０１、２９０２から演算子２９０３に、そして演算子２９０３からエグゼキュータ２９０４に渡される。
理解されるように、高次集合演算の入力トライの１つ又は複数は、トライに対する同じ又は異なる論理演算子を使用した別の（低次）集合演算の出力であり得る。上述したように、トライへの低次集合演算のそのような出力は、物理的トライデータ構造として提供し得る。しかしながら、好ましい実施形態では、高次集合演算の入力トライは、低次集合演算の出力であり、仮想トライとして提供される。仮想トライは、高次演算で使用されるトライを評価可能な低次演算子として理解することができる。この場合、高次演算子が入力トライの表現を受信し、入力トライの少なくとも１つが低次演算子の出力として提供される瞬間において、その入力トライの物理的データ構造は全体として存在せず、実際には決して全く実現されない。
そのような状況を図２９Ａに示し、図２９Ａでは、高次演算子２９０６は、例えば、物理的トライデータ構造で提供された入力ベースデータの集合２９０５及び低次演算子２９０３の出力に対して高次集合演算を実行する。高次演算子２９０５は、入力ベースデータ２９０５と低次演算子２９０３の出力との高次集合演算を使用した結合である高次結果トライの少なくとも部分を評価する。低次演算子２９０３は少なくとも部分的に低次結果トライを評価し、低次結果トライは、低次集合演算を使用した、例えば、物理的トライデータ構造で提供される入力ベースデータの２つの集合２９０１、２９０２の結合である。低次集合演算は、高次集合演算と同じ演算又は異なる演算であり得る。本明細書で使用される場合、「トライの部分」という表現はトライのノード及び／又は分岐を指し得る。
低次結果トライの少なくとも部分は、高次結果トライの少なくとも部分を評価するステップ中のみ、計算される。低次結果トライの部分は、高次演算子の需要に応じて評価され、したがって、高次結果トライの部分及び低次入力結果トライの部分は、インタリーブ方式で評価される。したがって、低次結果トライの少なくとも部分は、高次結果トライの少なくとも部分が計算された後でのみ計算される。
理解されるように、高次演算子２９０５が高次結果トライを評価する際、低次結果トライの全ての部分を評価する必要があるわけではない。したがって、高次結果トライの評価に必要ではない低次結果トライの部分の少なくとも幾つか−好ましくは全て−は、評価されない。しかしながら、明かに、少なくとも、高次結果トライの評価に必要な低次結果トライの部分は評価する必要がある。
図３０は、論理積（ブールＡＮＤ）演算子３００３を２つの入力トライ３００１、３００２に適用する一例を示す。入力トライは、読みやすさのために８変数であるが、好ましい実施態様では、上述したようなトライデータ構造が使用される。入力トライ３００１は、キー「１３」、「１４」、及び「５５」が関連付けられた３つのリーフノードを含む。入力トライ３００２も、キー「１３」、「１５」、及び「６４」に関連付けられた３つのリーフノードを含む。トライ３００５は、入力トライ３００１、３００２のＡＮＤ結合によって得られた結果トライを表現している。
観察することができるように、結果トライ内の各ノードの子ノードの集合は、入力トライ内の対応するノードの子ノードの集合のＡＮＤ結合である。例えば、結果トライ３００５のルートノードは、キー「１」が関連付けられた１つの子ノードを有する。この１つの子ノードは、入力トライ３００１のルートノードの子ノードの集合（「１」，「５」）と、入力トライ３００２のルートノードの子ノードの集合（「１」，「６」）との論理積を形成する場合、得られる。更に、キー「１」が関連付けられたノードも１つの子ノードを有し、これにはキー「１３」が関連付けられる。実際に、ノード「１３」は、入力トライ３００１のノード「１」の子ノードの集合（「１３」，「１４」）と、入力トライ３００２の対応するノード「１」の子ノードの集合（「１３」，「１５」）との論理積を形成する場合、得られる。
したがって、論理積演算の結果トライ、ここでは結果トライ３００５は、全てのノード及び各入力トライ、ここでは入力トライ３００１、３００２に含まれるノードのみを含む。特に、ここではキー「１３」に関連付けられたノードである結果トライのリーフノードの集合は、全てのリーフノード及び入力トライのそれぞれ全てに含まれるリーフノードのみを含む。
論理積演算子３００３の好ましい実施形態によって実行されるアルゴリズムは、以下のように擬似コードで記載することができる：
１．ｎｏｄｅＡ＝トライＡのルートノード
２．ｎｏｄｅＢ＝トライＢのルートノード
３．ｎｏｄｅＡのｇｅｔＢｉｔＳｅｔ−＞００１０００１０
４．ｎｏｄｅＢのｇｅｔＢｉｔＳｅｔ−＞０１００００１０
５．ビット単位ａｎｄ−＞００１０００１０
６．ｆｏｒ全ての設定ビット
ｎｏｄｅＡ＝ｎｏｄｅＡのｇｅｔＣｈｉｌｄＮｏｄｅ
ｎｏｄｅＢ＝ｎｏｄｅＢのｇｅｔＣｈｉｌｄＮｏｄｅ
ｉｆリーフノードが
ビット単位ａｎｄを実行する
ｅｌｓｅ
反復（ステップ３）
この好ましい実施形態では、全てのトライノードは上述したようにビットマップを含む。更に、トライは、上述したようにｇｅｔＢｉｔＳｅｔメソッド及びｇｅｔＣｈｉｌｄＮｏｄｅメソッドを含むインターフェースを実施するノードによって形成される。ビット単位ＡＮＤ演算が２つの入力トライの対応するノードのビットマップ間で実行されて、２つの対応するノードが共通に有する子ノードの集合を求める。
図３１〜図３４を参照して以下に示すように、本発明の解決策は、階層トライ構造を利用する。階層トライ構造では、トライはレベル毎に処理されるため、遅延評価が可能である。したがって、集合演算の性能を大幅に改善することができる。
図３１は、論理積演算が実行される、例としての２つの入力トライ３１１０、３１２０を示す。全てのトライのように、入力トライ３１１０及び３１２０は、レベル１に１つの（ルート）ノードを有する。入力トライ３１１０は、入力トライ３１１０のルートノードに含まれるビットマップ３１１１内で４番目及び７番目のビットが設定されていることにより示されるように、レベル２に２つのノードを有する。入力トライ３１２０は、入力トライ３１２０のルートノードに含まれるビットマップ３１２１内で７番目のビットが設定されていることにより示されるように、レベル２に１つのノードを有する。両入力トライは、レベル２のノードの各ビットマップ内で設定されているビットに従属する三角形で示されるように、レベル３又はそれ以降のレベルに更なるサブトライを有する。
図３２は、レベル１及び２における入力トライ３１１０及び３１２０の対応するノードのビットマップに対して実行されたビット単位ＡＮＤ演算を示す。入力トライのレベル１におけるルートノードは常に、互いに対応し、したがって、それらのビットマップは、第１のビット単位ＡＮＤ演算を用いて結合される。入力トライ３１１０のルートノードのビットマップ３１１１において４番目及び７番目のビットが設定されており、入力トライ３１２０のルートノードのビットマップ３１２１において７番目のビット（のみ）が設定されているため、結合ビットマップ３２０１において、７番目のビット（のみ）が設定される。レベル２において、入力トライ３１１０のルートのビットマップ３１１１の７番目のビットに従属するノードは、入力トライ３１２０のルートのビットマップ３１２１の７番目のビットに従属するノードに対応し、一方、入力トライ３１１０のルートのビットマップ３１１１の２番目のビットに従属するノードは、入力トライ３１２０内に対応するノードを有さない。したがって、ビットマップ３１１３及び３１２２（のみ）が、レベル２においてビット単位ＡＮＤ演算を用いて結合され、３番目及び６番目のビットが、結合ビットマップ３２０２において設定される。
図３３は、入力トライ３１１０及び３１２０に対する論理積演算中の分岐スキップを示す。２つの入力トライのルートノードのビットマップ３１１１及び３１２１へのビット単位ＡＮＤ演算は、７番目のビットのみが設定された結合ビットマップ３２０１を生成するため、論理積演算は、入力トライ３１１０のルートノードのビットマップ３１１１の４番目のビットに従属する入力トライ３１１０の分岐をトラバースする必要がない。これは図３３において、ビットマップ３１１１の４番目の位置における「Ｘ」及びスキップされた分岐の描画に使用される破線によって示される。同様に、レベル２において、入力トライ３１１０内のノードのビットマップ３１１３において７番目のビットのみが設定されているが、入力トライ３１２０内の対応するノードのビットマップ３１２２においては設定されていない。したがって、論理積演算は、ビットマップ３１１３の７番目のビットに従属する分岐をトラバースする必要はない。
最後に、図３４は、トライ３１１０及び３１２０への論理積演算の結果トライを示す。レベル１及びレベル２での結果トライのノードに関連付けられたビットマップ３２０１及び３２０２はそれぞれ、図３２に示されるビット単位ＡＮＤ演算によって計算された結合ビットマップに対応する。
図３１〜図３４の例は、一般に、入力トライを結合する集合演算の過程で、入力トライの分岐の幾つかをトラバースする必要がないことを示し、これは性能を劇的に増大させることができる。結合ビットマップを使用して、いずれの分岐を更にトラバースする必要があり、いずれの分岐をスキップできるかを判断し得る。この手法は、「結果予測」又は「ツリー刈込み」と呼ぶことができる。
図３５は、論理和（ブールＯＲ）演算子３５０３を図３０の２つの入力トライ３００１、３００２に適用する一例を示す。入力トライ３００１、３００２のＯＲ結合によって得られた結果トライ３６０５の表現を図３６に示す。
観察することができるように、結果トライ内の各ノードの子ノードの集合は、入力トライ内の対応するノードの子ノードの集合のＯＲ結合である。例えば、結果トライ３６０５のルートノードは、キー「１」、「５」、及び「６」が関連付けられた３つの子ノードを有する。これらの３つの子ノードは、入力トライ３００１のルートノードの子ノードの集合（「１」，「５」）と、入力トライ３００２のルートノードの子ノードの集合（「１」，「６」）との論理和を形成する場合、得られる。キー「１」が関連付けられたノードも、キー「１３」、「１４」、及び「１５」が関連付けられた３つの子ノードを有する。実際に、これらのノードは、入力トライ３００１のノード「１」の子ノードの集合（「１３」，「１４」）と、入力トライ３００２の対応するノード「１」の子ノードの集合（「１３」，「１５」）との論理和を形成する場合、得られる。最後に、キー「５」及び「６」がそれぞれ関連付けられた結果トライ内のノードはそれぞれ、キー「５５」及び「６４」がそれぞれ関連付けられた１つの子ノードを有し、これらは入力トライ３００１及び３００２のそれぞれの対応するノードの子ノードである。
したがって、論理和演算の結果トライ、ここでは結果トライ３６０５は、入力トライ、ここでは入力トライ３００１、３００２の何れかに含まれるノードを全て含む。特に、結果トライのリーフノードの集合、ここでは「１３」、「１４」、「１５」、「５５」、及び「６４」に関連付けられたノードは、何れかの入力トライに含まれるリーフノードを全て含む。
論理和演算子３５０３の好ましい実施形態によって実行されるアルゴリズムは、以下のように疑似コードで記載することができる。
１．ｎｏｄｅＡ＝トライＡのルートノード
２．ｎｏｄｅＢ＝トライＢのルートノード
３．ｎｏｄｅＡのｇｅｔＢｉｔＳｅｔ−＞００１０００１０
４．ｎｏｄｅＢのｇｅｔＢｉｔＳｅｔ−＞０１００００１０
５．ビット単位ｏｒ−＞０１１０００１０
６．ｆｏｒ全ての設定ビット
ｉｆビットがｎｏｄｅＡ及びｎｏｄｅＢで設定されている
ｎｏｄｅＡ＝ｎｏｄｅＡのｇｅｔＣｈｉｌｄＮｏｄｅ
ｎｏｄｅＢ＝ｎｏｄｅＢのｇｅｔＣｈｉｌｄＮｏｄｅ
ｉｆリーフノードが
ビット単位ｏｒを実行する
ｅｌｓｅ
再帰（ステップ３）
ｉｆビットがｎｏｄｅＡのみで設定されている
ｎｏｄｅＡ＝ｎｏｄｅＡのｇｅｔＣｈｉｌｄＮｏｄｅ
ＴｒｉｅＡのみ再帰（ビット単位ｏｒをスキップ）
ｉｆビットがｎｏｄｅＢのみで設定されている
ｎｏｄｅＢ＝ｎｏｄｅＢのｇｅｔＣｈｉｌｄＮｏｄｅ
ＴｒｉｅＢのみ再帰（ビット単位ｏｒをスキップ）
ここでも、上述したように、全てのトライノードはビットマップを含み、トライは、上述したように、ｇｅｔＢｉｔＳｅｔメソッド及びｇｅｔＣｈｉｌｄＮｏｄｅメソッドを含むインターフェースを実施するノードにより形成される。ビット単位ＯＲ演算は、２つの入力トライの対応するノードのビットマップ間で実行されて、２つの対応するノードの何れかに含まれる子ノードの集合を求める。ビットが２つの対応するノードの一方のみのビットマップにおいて設定されている場合、その一方のノードに従属するサブトライは結果トライに追加され、これは、上記疑似コードでは、「ＴｒｉｅＡのみ再帰」／「ＴｒｉｅＢのみ再帰」によって示されている。
図３７は、差分（ブールＡＮＤ ＮＯＴ）演算子３７０３を図３０の２つの入力トライ３００１、３００２に適用する一例を示す。トライ３７０５は、入力トライ３００１、３００２のＡＮＤ ＮＯＴ結合によって得られた結果トライの表現である。
観察することができるように、結果トライ３７０５の全ての親ノードは、第１の入力トライ３００１の親ノードに対応する。結果トライ３７０５の親ノードに従属するリーフノードは、第１の入力トライ３００１内の対応する親ノードの子ノードの集合と、入力トライ３００２内の任意の対応する親ノードの子ノードの集合とのＡＮＤ ＮＯＴ結合である。
例えば、結果トライ３７０５のルートノードは、それら自体が親ノードである、キー「１」及び「５」が関連付けられた２つの子ノードを有する。これらの２つのノードは、それら自体が親ノードである、入力トライ３００２のルートノードの２つの子ノードに対応する。キー「１」が関連付けられたノードは１つの子ノードを有し、この子ノードはリーフノードであり、キー「１４」が関連付けられる。このリーフノードは、第１の入力トライ３００１のノード「１」の子ノードの集合（「１３」，「１４」）と、入力トライ３００２の対応するノード「１」の子ノードの集合（「１３」，「１５」）との差分を形成する場合、得られる。最後に、キー「５」が関連付けられた結果トライ内のノードは１つの子ノードを有し、この子ノードにはキー「５５」が関連付けられ、第１の入力トライ３００１のキー「５」を有するノードの子に対応する。キー「５」を有するこのノードは、入力トライ３００２内に対応するノードを有さない。
したがって、差分演算の結果トライ、ここでは結果トライ３６０５は、第１の入力トライ、ここでは入力トライ３００１に含まれる全ての親ノードを含む。結果トライのリーフノードの集合、ここではキー「１４」及び「５５」が関連付けられたノードは、第１の入力トライ、ここではトライ３００１の全てのリーフノードから、第２の入力トライ、ここではトライ３００２のリーフノードを差し引いたものを含む。
差分演算子３７０３の好ましい実施形態によって実行されるアルゴリズムは、以下のように擬似コードで記載することができる：
１．ｎｏｄｅＡ＝トライＡのルートノード
２．ｎｏｄｅＢ＝トライＢのルートノード
３．ｎｏｄｅＡのｇｅｔＢｉｔＳｅｔ−＞００１０００１０
４．ｎｏｄｅＢのｇｅｔＢｉｔＳｅｔ−＞０１００００１０
５．ｎｏｄｅＡのビット集合−＞００１０００１０
６．ｆｏｒ全ての設定ビット
ｉｆ ｎｏｄｅＡ及びｎｏｄｅＢにおいてビットが設定されている
ｎｏｄｅＡ＝ｎｏｄｅＡのｇｅｔＣｈｉｌｄＮｏｄｅ
ｎｏｄｅＢ＝ｎｏｄｅＢのｇｅｔＣｈｉｌｄＮｏｄｅ
ｉｆリーフノードが
ビット単位ａｎｄ−ｎｏｔを実行する
ｅｌｓｅ
再帰（ステップ３）
ｉｆビットがｎｏｄｅＡのみで設定されている
ｎｏｄｅＡ＝ｎｏｄｅＡのｇｅｔＣｈｉｌｄＮｏｄｅ
ＴｒｉｅＡのみ再帰（ビット単位ａｎｄ−ｎｏｔをスキップ）
ここでも、上述したように全てのトライノードは形成され、インターフェースを実施する。ビットが、入力トライ３００１及び３００２の両方の対応するノードのビットマップにおいて設定される場合、両トライでの再帰がある。ビットが、第１の入力トライ３００１のノードのビットマップにおいてのみ設定されている場合、そのノードに従属するサブトライが結果トライに追加され、これは、上記擬似コードにおいて「ＴｒｉｅＡのみ再帰」によって示されている。トライ３００２のノードのビットマップにおいてのみ設定されているビットは無視される。ビット単位ＡＮＤ ＮＯＴ演算は、２つの入力トライの対応するノードの子ノードがリーフノードである場合のみ、２つの入力トライの対応するノードのビットマップ間で実行される。
演算子の実行は、トライレベル（好ましい実施態様では、各レベルは基数／底６４の１桁である）にわたる再帰降下である。各レベルにおいて、各ノードのビットマップは、予測ビットを通しての再帰が続く結果予測として使用される。したがって、入力トライの結合は、結果トライのルートノードに対して結合関数を実行することを含む。結果トライの入力ノードに対して結合関数を実行することは、論理演算を使用して結果トライの入力ノードに対応する入力トライのノードの子ノードの集合を結合し、結果トライの入力ノードに特定された各子ノードの結合関数を実行することにより、結果トライ（空であることもある）の入力ノードの子ノードの集合を特定することを含む。既に上述したように、結果トライのルートノード及び／又は入力ノードを物理的に生成する必要はない。
結果トライを評価するステップは、深さ優先探索、幅優先探索、又はそれらの組合せを使用して実行し得る。深さ優先探索において結果トライを評価することは、入力ノードの子ノードの１つに対して結合関数を実行することと、結合関数が子ノードの次の兄弟ノードに対して実行される前、その子ノードにより形成されるサブトライをトラバースすることとを含む。幅優先探索において結果トライを評価することは、結果トライの入力ノードに決定された子ノードのそれぞれに対して結合関数を実行することと、結果トライの入力ノードの任意の孫ノードに対して結合関数を実行する前、結果トライの入力ノードに決定された子ノードのそれぞれの子ノードの集合を決定することとを含む。
集合演算の入力トライの１つ又は複数は、仮想トライ、すなわち、入力トライを結合する演算中、オンデマンドで動的に生成されるトライであり得る。通常、論理演算を使用した入力トライの結合に必要な仮想トライの部分のみが動的に生成される。仮想入力トライが適用される幾つかの状況があり、そのうちの１つは、後述するデータベース範囲クエリの実装である。別の状況は、高次集合演算の入力トライの１つ又は複数が、図２９Ａを参照して上述した、トライに対する低次集合演算の出力である状況である。
仮想トライは、仮想トライが、例えば集合演算子の入力トライとして受信される場合、物理的データ構造が全体として存在しないトライである。仮想トライは、トライを評価可能な演算子として理解することができる。好ましくは、演算子は、トライのルートノードを表し、トライノードインターフェースを実装し、トライノードインターフェースはトライノードを表し、表すトライノードの子ノードをクエリ及び／又はトラバースする方法又は関数を提供する。
トライ又はトライの部分の「評価」は、トライ又はトライの部分の「レンダリング」又は「合成」と呼ぶこともでき、通常、トライ又はトライの部分をトラバースすることと、トラバースされたノードがトライに存在することの情報を提供することとを含む。トライ又はトライの部分の物理的データ構造を全体として実現することを含み得る。しかしながら、好ましい実施形態では、任意の所与の瞬間において、トライ又はトライの部分の物理的データ構造の全体未満が実現され、好ましくは、トライ又はトライの部分をトラバースするためにその瞬間において実現する必要がある、トライ又はトライの部分の物理的データ構造の部分のみが実現される。明らかなことに、トライ又はトライの部分を評価する間、任意の所与の瞬間において、少なくとも、トライ又はトライの部分をトラバースするためにその瞬間において実現する必要があるトライ又はトライの部分の物理的データ構造の部分が実現される。
好ましい実施形態では、仮想トライがトライ（ノード）インターフェースを実装する場合、トライ又はトライの部分は、上述したように、ｇｅｔＢｉｔＳｅｔメソッド及びｇｅｔＣｈｉｌｄＮｏｄｅメソッドを使用して評価される。例えば、入力トライの１つが仮想トライである高次論理積演算中、高次論理積演算子はアクセスし、仮想範囲トライは、アプリケーションプログラミングインターフェース（ＡＰＩ）を通して高次結果トライを評価するのに必要な仮想トライの構成要素を「オンザフライ」で送出する。例えば、仮想トライの現在ノードのビットマップは、ｇｅｔＢｉｔＳｅｔ（）メソッドを通してアクセスし得、子ノードは、先に紹介したｇｅｔＣｈｉｌｄＮｏｄｅ（）メソッドを通してアクセスし得る。ＡＰＩは一方では各ビットマップを返し、他方ではオブジェクトを返し−実際のトライの子ノードの代わりに−、次の再帰の各ビットマップを提供する。高次演算子の場合、仮想トライは物理的トライデータ構造に実装されるトライと全く同じように見える。
通常、仮想トライの表現は、仮想トライの何らかの演算の入力として使用する演算子に与えられる。仮想トライの少なくとも部分は、演算を実行するステップ中、評価される（オンデマンドで）。演算を実行するために、仮想トライの部分の全てにアクセスする必要があるわけではない場合、演算の実行に必要ない部分の少なくとも部分は評価されず、好ましくは、演算の実行に必要な仮想トライの部分のみが評価される。これは、図２９Ａに示される場合での図３７Ａ及び図３７Ｂに示され、仮想トライは低次集合演算子２９０３であり、仮想トライの表現は、入力トライとして高次集合演算子２９０６に提供され、高次集合演算子２９０６は仮想トライを高次結果トライの少なくとも部分の評価に使用する。高次結果トライは、論理演算を使用した、集合演算子２９０６の入力トライ、すなわち、仮想トライ及びベースデータ２９０５の結合である。図３７Ａ及び図３７Ｂの場合、高次集合演算はＡＮＤ演算であり、低次集合演算はＯＲ演算である。
図３７Ａは３つのトライＡ、Ｂ、及びＣを示す。好ましい実施形態では、上述したように、トライは３２進数、６４進数である。したがって、子ノードへのポインタを参照するビットマップは３２ビット又は６４ビットを含み得る。簡潔にするために、例は４進数トライを示す。トライは、トライＡではトライルート３７０１、トライＢではトライルート３７０２、トライＣではトライルート３７０３により示されている。上述したように、各トライはビットマップ３７０４、３７０５、３７０６を含む。
図３７Ｂは、中間結果として（Ａ ｏｒ Ｂ）を実現させずに又は生じさせずに、すなわち、物理的トライデータ構造を作成せずに、（（Ａ ｏｒ Ｂ）ａｎｄ Ｃ）評価がいかに行われるかを示す。図は、２レベルでの式ツリー及びその評価を示す。第１のレベルでは、トライＡ（３７０４）及びトライＢ（３７０５）のルートノードのビットマップが、ビット単位ＯＲ演算により結合され、ビットマップ３７０９を生成する。ビットマップ３７０９は、トライＣのルートノードのビットマップ３７０６とビット単位ＡＮＤ演算により結合される。その結果生成されたビットマップ３７１０は、トライＣとの一致がないため、トライＢをそれ以上の考慮から除外する。その結果生成された物理的トライデータ構造は、ルートノード３７１２を用いて示される。第２のレベルにおいて、トライＡ及びトライＣのビットマップ３７０７及び３７０８は結合され−トライＢはここでは一致がない−、ビットマップ３７１１を生成する。
図３７Ａ及び図３７Ｂの例から見て取ることができるように、低次ＯＲ演算の結果が、完全に評価された物理的トライデータ構造としてではなく高次ＡＮＤ演算子への仮想入力トライとして提供されることにより、「レイジー評価（lazy evaluation）」が可能になる。低次ＯＲ演算の低次結果トライは、高次ＡＮＳ演算の高次結果トライの評価中、評価される。したがって、低次結果トライの少なくとも部分は、高次結果トライの少なくとも部分が評価された後、評価される。実際に、高次結果トライの部分及び低次結果トライの部分はインタリーブ方式で評価され、低次結果トライの部分は、高次演算子の需要に応じて評価される。これにより、高次結果トライの評価に必要な低次結果トライの部分のみを評価することができる。
なお、幾つかの演算では、例えば、結果のカウント（濃度）のみが必要な場合、物理的結果トライデータ構造を実際に実現する必要はない。当業者ならまた理解するように、高次演算子は、例えば高次結果トライが更に高次の演算子の入力として使用される場合、高次結果トライの部分のみを評価し得る。同様に、低次演算子の入力トライは、物理的トライデータ構造である必要はなく、ここでも仮想トライであり得、これは例えば、更に低次の演算子の出力である。最後に、演算子が通常、入力トライの表現を取得し、ここで、トライの表現は、ポインタのような物理的トライデータ構造へのハンドルであり得ることに留意する。仮想トライの場合、表現は、トライを評価可能なトライ演算子へのハンドルであり得る。
範囲クエリ
論理積演算（ブールＡＮＤ）による２つ以上のトライの結合は、有利なことに、範囲クエリを効率的に実行するのに使用することができる。「範囲」は、特定のデータ型の第１の値と第２の値との間の全ての値を含む順序付き離散値の集合として説明することができ、ここで、第１及び／又は第２の値は、範囲内に含まれることもあれば、又は含まれないこともある。範囲クエリは、値が、１つ又は複数の指定された値の範囲に対応する（一致する）、キーの集合内のキーを返す。
本発明による範囲クエリは、１つ又は複数の範囲についてサーチすべきキーの集合を格納したトライ（以下、「入力集合トライ」）と、１つ又は複数の範囲に含まれる全ての値を格納するトライ（以下、「範囲トライ」）との論理積演算によって実行される。トライは、好ましくは、上述したように実施される。サーチすべきキーの集合には通常、入力集合トライのノードが関連付けられ、一致する値の範囲を示す値（キー）には通常、範囲トライのノード、特に範囲トライのリーフノードが関連付けられる。サーチすべきキーの集合は通常、データベースに格納されたキーの集合、又はデータベースクエリの結果キー若しくは入力キーの集合、又は情報検索システムに格納されたキーの集合、又は情報検索システムクエリの結果キー若しくは入力キーの集合である。
クエリを実行する１つ又は複数の範囲の定義は、ユーザ入力又は他の方法によって得られる。定義は範囲トライの生成に使用され、範囲トライのノード（通常、リーフノード）に関連付けられた値は、１つ又は複数の範囲に含まれる値に対応する。次のステップにおいて、入力集合トライは、上述したように、論理積演算により使用して範囲トライと結合されて、結果トライのノードに関連付けられたキーの集合を取得する。最後に、結果トライのノードに関連付けられたキーの集合又は結果トライのノードに関連付けられたキー、特に結果トライのリーフノードに関連付けられたキーのサブセット、又は結果トライのノードに関連付けられたキーから導出されたキー若しくは値の集合が、出力として得られる。
図３８は、１つ又は複数の範囲についてサーチすべきキーの集合を格納する入力集合トライ３８０１及び１つ又は複数の範囲に含まれる全ての値を格納するように生成された範囲トライ３８０２を示す。トライ３８０１及び３８０２は両方とも、論理積演算子３８０３によって結合されて、範囲トライ３８０２に格納された１つ又は複数の範囲内に値がある入力集合トライ３８０１内のキーの集合を取得する。上述したように、入力集合トライ及び範囲トライのみならず、論理積演算子それ自体も、図３８において３つの三角形によって示されるように、各トライ（ノード）インターフェースを実施し得る。トライノードインターフェースが、上述したｇｅｔＢｉｔＳｅｔ（）メソッド及びｇｅｔＣｈｉｌｄＮｏｄｅ（ｂｉｔＮｕｍ）メソッドを有する場合、論理積演算子３８０３はこれらの演算を呼び出して、図３８おいて破線矢印で示されるように、入力集合トライ３８０１及び範囲トライ３８０２をトラバースし得る。実線矢印で示されるデータフロー方向において、ビットマップ及び子トライノードは、集合トライ３８０１及び範囲トライ３８０２から論理積演算子３８０３に渡される。
図３９は、本発明による範囲クエリを実行する方法の一例を示す。入力集合トライ３９０１のリーフノードには、値「１３」、「１４」、及び「５５」を有する３つのキーが関連付けられる。範囲トライ３９０２は、値が範囲すなわち［１４，…，５６］内にあるキーが関連付けられた全てのリーフノードを含むように生成される。範囲トライの各レベルにおいて、範囲の終わりにあるノード（範囲トライ３９０２の例では、ノード１及び５）は、結果に部分的に寄与する。範囲の終わりの間のノード（範囲トライ３９０２の例では、ノード２、３、及び４）及びそれらに従属するサブトライは、結果に完全に寄与する。論理積演算子３９０３による入力トライ３９０１と範囲トライ３９０２とのＡＮＤ結合は、結果トライ３９０５のノードに関連付けられたキーの集合を取得する。エグゼキュータ３９０４は、例えば、結果トライ３９０５に関連付けられたキーの値、すなわち、「１４」及び「５５」を出力し得る。この出力は、範囲［１４，…，５６］内にある入力集合トライ３９０１のリーフノードが関連付けられた全てのキーの値に対応する。
論理積演算子３９０３によって実行されるアルゴリズムは、以下のように疑似コードで記載することができる：
１．ｎｏｄｅＡ＝トライＡのルートノード（入力集合トライ）
２．ｎｏｄｅＢ＝トライＢのルートノード（範囲トライ）
３．ｎｏｄｅＡのｇｅｔＢｉｔＳｅｔ−＞００１０００１０
４．ｎｏｄｅＢのｇｅｔＢｉｔＳｅｔ−＞０１１１１１１０
５．ビット単位ａｎｄ−＞００１０００１０
６．ｆｏｒ全ての設定ビット
ｎｏｄｅＡ＝ｎｏｄｅＡのｇｅｔＣｈｉｌｄＮｏｄｅ
ｎｏｄｅＢ＝ｎｏｄｅＢのｇｅｔＣｈｉｌｄＮｏｄｅ
ｉｆリーフノードが
ビット単位ａｎｄを実行する
ｅｌｓｅ
再帰（ステップ３）
範囲トライ３９０２は、範囲トライが非常に多くのノードを含み得ることを示す一例である。したがって、全てのノードを有する範囲トライ３９０２の実現は、時間及びメモリ空間に関してコストがかかる。このため、範囲トライは、すでに上記に記載の仮想トライ、すなわち、論理積演算中、需要に応じて動的に生成されるトライとして実施し得る。これは、図３９において、破線で描かれた範囲トライ３９０２の三角形の中味によって示されている。
論理積演算中、論理積演算子はアクセスし、仮想範囲トライは、アプリケーションプログラミングインターフェース（ＡＰＩ）を通して論理積演算の結果トライの評価に必要な仮想トライの構成要素を「オンザフライ」で送出する。例えば、仮想トライの現在ノードのビットマップに先に紹介したｇｅｔＢｉｔＳｅｔ（）メソッドを通してアクセスし得、子ノードにｇｅｔＣｈｉｌｄＮｏｄｅ（）メソッドを通してアクセスし得る。ＡＰＩは一方では各ビットマップを返し、他方ではオブジェクトを返し−実際のトライの子ノードの代わりに−、次の再帰の各ビットマップを提供する。論理積演算子の場合、仮想トライは物理的トライデータ構造に実装されるトライと全く同じように見える。
通常、論理積演算の結果トライの評価に必要ない仮想トライの部分の少なくとも幾つかは評価されず、好ましくは、論理積演算により入力集合トライと範囲トライとを結合するのに必要な仮想範囲トライの部分のみが動的に生成される。図３９の例では、上述した分岐スキップに起因して、範囲トライのルートノードのビットマップにおいて設定されたビット２、３、４、及び５が関連付けられた仮想サブトライは、論理積演算中、アクセスされず、このため、それらのノードのいずれも物理的に生成（レンダリング又は合成）されない。
本発明による範囲クエリの幾つかの実施形態では、図３９に示される実施形態のように、入力集合トライのリーフに関連付けられたキーは、特定のデータ型の１つのデータ項目を符号化する。これらの実施形態は、「一次元」範囲クエリと呼ぶこともできる。一次元範囲クエリでは、１つ又は複数の範囲の定義は、その１つのデータ項目の１つ又は複数の範囲の定義を含む。
多次元範囲クエリ処理
本発明による範囲クエリの他の実施形態では、入力集合トライのリーフノードに関連付けられたキーは、特定のデータ型の２つ以上のデータ項目を符号化する。この場合、１つ又は複数の範囲の定義は、データ項目のうちの１つ又は複数のデータ項目の１つ又は複数の範囲の定義を含む。そのような実施形態は「多次元」範囲クエリと呼ぶこともできる。原理上、各次元の範囲クエリを実行し、結果の論理積を実行することが可能であるが、関わるトライ及び演算子が多すぎるため、効率的ではない。
本発明による効率的な多項目又は多次元範囲クエリ処理の一例を図４０に示す。入力集合トライ４００１は二次元又は２項目トライであり、そのリーフノードのそれぞれには、値対（ｘ，ｙ）を指定するキーが関連付けられる。図５４〜図５７を参照して以下に説明するように、そのような値対を使用して、例えば、ジオロケーションデータの経度及び緯度又は（経度，ＩＤ）又は（緯度，ＩＤ）のような複合キーを指定することができる。この例での次元ｘ及びｙのそれぞれは、読みやすさのために８変数系での２つの数字を含むが、好ましい実施形態では、上述したようなトライデータ構造が使用される。以下の説明から明らかになるように、ｘ次元及びｙ次元は、１キー内の複数のデータ項目の上述したインタリーブ符号化に従って、入力集合トライ４００１にインタリーブ様式で格納される。
入力集合トライ４００１は、レベル１においてルートノードを有する。ルートノードに関連付けられたビットマップは、ｘ次元の第１の数字の値を示す。ビット「１」及び「５」が、ルートノードに関連付けられたビットマップにおいて設定され、これは、入力集合トライに格納されたキーのｘ次元の第１の数字が「１」又は「５」の何れかであることを示す。レベル２におけるノードに関連付けられたビットマップは、ｙ次元の第１の数字の値を示す。ビット「３」及び「４」が、ルートノードのビット「１」に従属するレベル２におけるノードに関連付けられたビットマップにおいて設定され、ビット「６」が、ルートノードのビット「５」に従属するレベル２におけるノードに関連付けられたビットマップにおいて設定される。これは、ｘ次元が「１」で開始するキーのｙ次元の第１の数字が「３」又は「４」の何れかであり、ｘ次元が「５」で開始するキーのｙ次元の第１の数字が「６」であることを示す。レベル３においてノードに関連付けられたビットマップは、ｘ次元の第２の数字の値を示す。これらのビットマップにおいて設定されたビットは、ｙ次元が「３」で開始されるｘ次元「１２」及び「１６」を有するキーがあり、ｙ次元が「４」で開始されるｘ次元「１２」及び「１５」を有するキーがあり、ｙ次元が「６」で開始されるｘ次元「５６」を有するキーがあることを示す。レベル４におけるノード及びレベル５におけるノードのビットマップは図４０に示されておらず、レベル４におけるノードに従属する小さな三角形によってのみ示されている。
多項目の範囲トライ又は多次元範囲クエリは、１項目又は入力集合トライのリーフに関連付けられたキーによって符号化された各データ項目の一次元範囲トライを結合することによって得られる多項目範囲トライであり得、データ項目の１項目範囲トライは、データ項目の１つ又は複数の範囲に含まれる全ての値を格納する。１項目範囲トライは、上述したような仮想範囲トライであり得る。これは、１項目範囲トライを結合して多項目範囲トライを得るため、又は論理積演算によって入力集合トライと１項目トライとを結合するために必要な仮想１項目トライの部分のみが動的に生成されることを意味する。
図４０の例では、二次元範囲クエリについて２つの一次元入力範囲が得られる：ｘ次元の範囲［１５，…，５５］及びｙ次元の範囲［３０，３１］。ｘ次元の範囲［１５，…，１５］を格納する（仮想）範囲トライ４００２が作成され、ｙ次元の範囲［３０，…，３１］を格納する（仮想）範囲トライ４００３が作成される。
幾つかの多次元範囲クエリでは、データ項目（次元）の幾つかについて、範囲の定義が取得されないことがある。例えば、ユーザは、図４０の二次元入力集合トライ４００１に対して範囲クエリ処理を実行するためのｘ次元の範囲［１５，…，５５］のみを指定し、ｙ次元の範囲の定義を指定しないことがある。これは、ユーザが、ｙ次元の値に関係なく、ｘ次元の値が１５と５５との間にある入力集合トライ４００１内に格納された全てのキーに関心があることを意味する。範囲が指定されない次元はスキップ又は無視すべきである。これは、範囲の定義が得られないデータ項目にであっても、データ項目の可能な全範囲の値を格納する（仮想）１項目範囲トライを作成することによって達成することができる。そのようなトライは「ワイルドカードトライ」と呼ぶこともできる。例えば、一実施態様では、ＭａｔｃｈＡｌｌトライは、上記トライ（ノード）インターフェース（「ＣＤＢＩＮｏｄｅ」）を実施するトライである。その任意のノードでｇｅｔＢｉｔＳｅｔ（）メソッドを呼び出すと、全てのビットが設定されたビットマップが常に返される。
１項目又は一次元範囲トライの結合から得られる多項目又は多次元範囲トライは通常、１項目（一次元）範囲トライに格納されたデータ項目の値の全ての組合せを格納する。例えば、ｘ次元の範囲が［１１，…，１３］であり、ｙ次元の範囲が［７，…，８］である場合、結合された二次元範囲トライは、（ｘ，ｙ）値対（１１，７）、（１１，８）、（１２，７）、（１２，８）、（１３，７）、及び（１３，８）のキーを格納する。
図４１は、図４０の一次元範囲トライ４００２及び４００３の異なる部分がいかに結合されて、図４２に示されているインタリーブされた二次元範囲トライを得るかを示す。図４２において観察することができるように、結合された二次元範囲トライ内のｘ次元及びｙ次元は、図４０の入力集合トライ４００１と同じインタリーブされた様式で格納される。比較として、図４３は、図４０の一次元範囲トライ４００２及び４００３がいかに結合されて、図４４に示される非インタリーブ二次元範囲トライを得るかを示す。抽象的な視点から、これは、全てのＸ値キーを含むトライを生成し、各リーフノードは、全てのＹ値キーを含むトライのルートである。
本発明の好ましい実施形態では、これは、一次元及び多次元範囲クエリの両方に当てはまり、範囲トライは、入力集合トライと同じ構造又はフォーマットを有する。したがって、多次元入力集合トライがデータ項目をインタリーブ様式で格納する場合、多次元範囲トライは好ましくは、インタリーブ格納を使用し、入力集合トライが非インタリーブ様式でデータ項目を格納する場合、多次元範囲トライも好ましくは、インタリーブ格納を使用しない。更に、範囲トライのリーフに関連付けられたキーは、好ましくは、入力集合トライのリーフに関連付けられたキーと同じデータ型のデータ項目を符号化する。最後に、範囲トライにおいて、特定のデータ型のデータ項目又はそのようなデータ項目の構成要素は好ましくは、入力集合トライ内の対応するデータ項目又はデータ項目の構成要素と同じレベルのノードにおいて符号化される。
多項目又は多次元範囲クエリ処理の幾つかの実施形態では、多項目又は多次元範囲を得るための１項目又は一次元範囲トライの結合は、多項目範囲トライとの入力集合トライの結合を実施する関数（例えば、論理積演算子）への入力として多項目範囲トライを提供する関数によって実行される。これは、結合がインタリーブ演算子６４０４によって実行される図６４の例に示される。
他の実施形態では、多項目又は多次元範囲トライを得るための１項目又は一次元範囲トライの結合は、範囲トライとの入力集合トライの論理積を実施する関数又は演算子内で実行される。この場合、多次元範囲トライは概念的にのみ存在する。実際には、範囲トライとの入力集合トライの結合を実施する関数又は演算子は、複数の（仮想）一次元範囲トライが一緒に（仮想）多次元範囲トライを形成した場合等、（仮想）一次元範囲トライにアクセスする。範囲が指定されていない次元がある場合、これらの次元は、例えば、上述したようにワイルドカードトライを作成することにより、範囲トライとの入力集合トライの論理積を実施する関数又は演算子によってスキップ又は無視される。
図４０の例では、結合は二次元論理積（ＡＮＤ）演算子４００４によって実行される。論理積演算子４００４によって実行されるアルゴリズムは、以下のように疑似コードで記載することができる：
１．ｎｏｄｅＡ＝トライＡのルートノード（入力集合トライ）
２．ｎｏｄｅＢ＝トライＢのルートノード（ｘ次元の範囲）
３．ｎｏｄｅＣ＝トライＣのルートノード（ｙ次元の範囲）
４．ｎｏｄｅＡのｇｅｔＢｉｔＳｅｔ−＞００１０００１０
５．ｎｏｄｅＢのｇｅｔＢｉｔＳｅｔ−＞００１１１１１０
６．ビット単位ａｎｄ−＞００１０００１０
７．ｆｏｒ全ての設定ビット
ｎｏｄｅＡ＝ｎｏｄｅＡのｇｅｔＣｈｉｌｄＮｏｄｅ，
８．ｎｏｄｅＡのｇｅｔＢｉｔＳｅｔ−＞０００１１０００
９．ｎｏｄｅＣのｇｅｔＢｉｔＳｅｔ−＞００００１０００
１０．ビット単位ａｎｄ−＞００００１０００
１１．ｆｏｒ全ての設定ビット
子ｎｏｄｅＡの子ノードを取得，
ｎｏｄｅＢ＝ｎｏｄｅＢのｇｅｔＣｈｉｌｄＮｏｄｅ
ｎｏｄｅＣ＝ｎｏｄｅＣのｇｅｔＣｈｉｌｄＮｏｄｅ
ｉｆリーフノードが
ビット単位ａｎｄを実行する
ｅｌｓｅ
再帰（ステップ４）
（仮想）多次元範囲トライは、一次元範囲トライが実際に結合されて（仮想）多次元範囲トライを取得した場合、少なくとも、多次元範囲トライが入力集合トライと同じ構造又はフォーマットを有するとき、結果トライ内の各ノードの子ノードの集合が、入力集合トライ内の対応するノードの子ノードの集合と、多次元範囲トライとのＡＮＤ結合の結果であるという意味で、概念的に作成される。
例えば、図４０は、入力集合トライ４００１のように、ｘ次元及びｙ次元をインタリーブ様式で格納する結果トライ４００６を示す。結果トライ４００６は、値（ｘ＝１，ｙ＝３）を有するキーが関連付けられたノード４００７を有する。このノードは、値ｘ＝１を有するキーが関連付けられたノード４１０８の子ノードの集合全体を表す。結果トライ４００６のノード４００７に対応する入力集合トライ４００１のノードはノード４００９であり、ノード４００９は、値ｘ＝１を有するキーが関連付けられたノードである。図４０の一次元範囲トライ４００２及び４００３が実際に結合される場合に得られ、入力集合トライ４００１と同じ構造及びフォーマットを有する多次元範囲トライ４１００を図４１に示す。結果トライ４００６のノード４００７に対応する多次元範囲トライ４１００のノードはノード４１０１であり、ノード４１０１は、値ｘ＝１を有するキーが関連付けられたノードである。入力集合トライ４００１のノード４００９の子ノードの集合（ノード４０１０及び４０１１）と、多次元範囲トライ４１００のノード４１０１の子ノードの集合（ノード４１０２）とのＡＮＤ結合は、結果トライ４００６のノード４００７を生成する。
多次元又は多項目入力集合トライの異なる次元又は項目をインタリーブ様式で格納することは、多くの場合、図４５及び図４６を参照してこれより説明するように、より効率的な範囲クエリに繋がる。
図４５は、図４０の入力集合トライ４００１と同じ値であるが、非インタリーブ様式で格納する入力集合トライ４５０１を示す。入力集合トライ４００１と全く同じように、入力集合トライ４５０１は、レベル１においてルートノードを有し、ルートノードに関連付けられたビットマップは、ｘ次元の第１の数字の値を示す。しかしながら、入力集合トライ４５０１のレベル２におけるノードに関連付けられたビットマップは、インタリーブ入力集合トライ４００１におけるｙ次元の第１の数字ではなく、ｘ次元の第２の数字の値を示す。レベル３におけるノードに関連付けられたビットマップは、ｙ次元の第１の数字の値を示し、レベル４におけるノードのビットマップ（図４５に示されず）は、ｙ次元の第２の数字の値を示す。
本発明により、各（非インタリーブと同様に）二次元範囲トライとの入力集合トライ４５０１のＡＮＤ結合を実行する場合、範囲Ｘ＝［１５，…，５５］及びＹ＝［３０，…，３１］を有する二次元範囲クエリについてトラバースされるノードは、図４５において陰影が付されている（レベル５におけるノードは示されない）。レベル４において１つのみのノード（ｘ＝１６，ｙ＝３）が陰影付きノードであるが、３つのより上位のレベルでは、合計で６つのノードをトラバース（訪問）する必要がある：ルートノード、ｘ＝１、ｘ＝５、ｘ＝１５、ｘ＝１６、及びｘ＝５３。
比較として、図４６は、図４０のインタリーブ入力集合トライ４００１を示し、ここでも、本発明により範囲Ｘ＝［１５，…，５５］及びＹ＝［３０，…，３１］を有する二次元範囲クエリについてトラバースされるノードは、陰影が付されている（レベル５におけるノードは示されない）。図４５と同じレベル４における１つのノード（ｘ＝１６，ｙ＝３）は、陰影付きノードであるが、３つのより上位のレベルでは、合計で４つのノードをトラバースする必要がある：ルートノード、ｘ＝１、ｘ＝５、及び（ｘ＝１，ｙ＝３）。
この理由は、非インタリーブ入力集合トライ４５０１では、範囲［１５，…，５５］内に入る全てのｘ値が最後の（第２の）数字まで特定されるが、インタリーブ入力集合トライ４００１では、ｙ次元の第１の数字を見ることにより、トラバースする価値がないノードをより素早くなくすことができるためである。別の次元の第１の数字を見ることによってノードをなくす機会は、同じ次元の更なる数字を見ることによりノードをなくす機会よりも多い。理解されるように、異なる次元が有する数字が多いほど、インタリーブ式格納の性能利得は大きくなる。
上述したように、範囲クエリ処理は、例えば、一次元範囲クエリの場合又はユーザが入力集合トライに格納された多次元キーの全ての次元に興味を有する場合、出力として、入力集合トライのリーフに関連付けられたキーの集合を提供し得る。代替的には、範囲クエリ処理は、出力として、入力集合トライのリーフに関連付けられたキーによって符号化されたデータ項目のサブセットを符号化する縮小項目キーの集合を提供し得る。この一例を図４７及び図４８に示す。
図４７では、二次元又は二項目トライ入力集合トライ４７０１は、図４０の入力集合トライ４００１と同じであり、各リーフノードには、値対（ｘ，ｙ）を指定するキーが関連付けられる。ユーザは、例において、入力集合トライに格納されている全てのｘ値に興味を有する。したがって、詳細に示されていないが、一次元範囲トライ４７０２は、ｘ次元の可能な全ての範囲全体を格納するワイルドカードトライであり、一次元範囲トライ４７０３は、ｙ次元の可能な値の範囲全体を格納するワイルドカードトライである。
図４０の一次元範囲トライ４００２及び４００３のように、一次元範囲トライ４７０２及び４７０３は、少なくとも概念的に結合されて、二項目又は二次元範囲トライを取得する。一次元範囲トライは両方ともワイルドカードトライであるため、二次元範囲トライは可能な全ての値対（ｘ，ｙ）を含む。次に、二次元範囲トライは、二次元論理積（ＡＮＤ）演算子４７０４によって二次元入力集合トライ４７０１と結合される。図４０の二次元論理積（ＡＮＤ）演算子４００４のように、論理積演算子４７０４は、論理積演算に従って二次元入力集合トライを二次元範囲トライと結合して、各結果トライのノードに関連付けられたキーの集合を取得する。更に、先に説明したように、結果トライ内の各ノードの子ノードの集合は、二次元入力集合トライ内の対応するノードの子ノードの集合と、二次元範囲トライ内の対応するノードの子ノードの集合とのＡＮＤ結合である。二次元範囲トライは可能な全ての値対（ｘ，ｙ）を格納しているため、結果トライは入力集合トライと同一である。
図４０の論理積演算子４００４とは対照的に、ユーザは入力集合トライに格納されているｘ値にしか興味がないため、図４７の論理積演算子４７０４は、入力集合トライのリーフに関連付けられた（ｘ，ｙ）キーの集合を出力として提供しない。むしろ、論理積演算子４７０４は、出力として、ｘ次元のみの値の集合、この例では、入力集合トライに格納されている全てのｘ値の集合を提供する。
範囲クエリ処理が、出力として、縮小項目キーの集合を提供する場合、図４７のように、縮小項目キーに符号化されないデータ項目に関連する入力集合トライの異なる分岐から得られる縮小項目キーの集合は、複製を含まないことができる。例えば、図４７から分かるように、入力集合トライ４７０１内にはｘ値が１２である少なくとも２つのリーフノードがあり、すなわち、ｙ値の第１の数字は３（１２，３，…）である少なくとも１つ及びｙ値の第１の数字が４（１２，４，…）である少なくとも１つがある。特に出力集合が上流演算子で使用される場合、出力を提供する前に複製キーをなくすために、縮小項目キーに符号化されないデータ項目に関連する入力集合トライの異なる分岐から得られる縮小項目キーの集合は、出力を提供する前にマージされる。二次元では、マージは、許容可能に効率的に、入力集合トライのレベル毎に実行することができる。しかしながら、多くの場合、縮小項目キーの集合を新たに作成されたトライに書き込み、それにより、複製が自動的になくなることが最も効率的であろう（例えば、入力集合トライが３つ以上の次元を有する場合）。
図４７の例では、出力集合内の複製ｘ値をなくすために、論理積演算による二次元範囲トライとの入力集合トライ４７０１の結合の結果として得られたｘ値キーの集合は、ｘ値のみを有するキーがノードに関連付けられた、新たに作成された一次元トライに書き込まれる。この新たに作成された一次元トライを図４８に示す。リーフノードに関連付けられたキーの値は、入力集合トライ４７０１に格納された全てのｘ値の集合に対応する。
ｘ値のみを出力する二次元論理積演算子４００４によって実行されるアルゴリズムは、以下のように擬似コードで記載することができる：
１．ｎｏｄｅＡ＝トライＡのルートノード（入力集合トライ）
２．ｎｏｄｅＢ＝トライＢのルートノード（ｘ次元のワイルドカードトライ）
３．ｎｏｄｅＣ＝トライＣのルートノード（ｙ次元のワイルドカードトライ）
４．ｎｏｄｅＡのｇｅｔＢｉｔＳｅｔ−＞００１０００１０
５．ｎｏｄｅＢのｇｅｔＢｉｔＳｅｔ−＞１１１１１１１１
６．ビット単位ａｎｄ−＞００１０００１０
７．ｆｏｒ全ての設定ビット
ｎｏｄｅＡ＝ｎｏｄｅＡのｇｅｔＣｈｉｌｄＮｏｄｅ，
８．ｎｏｄｅＡのｇｅｔＢｉｔＳｅｔ−＞０００１１０００
９．ｎｏｄｅＣのｇｅｔＢｉｔＳｅｔ−＞１１１１１１１１
１０．ビット単位ａｎｄ−＞０００１１０００
１１．ｆｏｒ全ての設定ビット
子ｎｏｄｅＡの子ノードを取得，
ｎｏｄｅＢ＝ｎｏｄｅＢのｇｅｔＣｈｉｌｄＮｏｄｅ
ｎｏｄｅＣ＝ｎｏｄｅＣのｇｅｔＣｈｉｌｄＮｏｄｅ
ｉｆリーフノードが
ビット単位ａｎｄを実行する
結果キー（ｘのみ）を出力トライに書き込む
ｅｌｓｅ
再帰（ステップ４）
図４７の例では、ｘ次元の値のみが出力として提供される。理解されるように、ｙ次元の値のみが出力として提供される場合、同じ原理が適用される。更に、一次元範囲トライ４７０２及び４７０３は両方ともワイルドカードトライであるため、入力集合トライ４７０１に格納された全てのｘ値は、出力として提供される。理解されるように、一次元範囲トライ４７０２及び／又は４７０３が、全ての可能なｘ値及び／又はｙ値のサブセットのみを格納する場合、入力集合トライ４７０１に格納された全てのｘ値のサブセットのみを出力として提供し得る。例えば、仮に一次元範囲トライ４７０２が図４０の範囲トライ４００２と同じであり、範囲［１５，…，５５］内のｘ値のみを格納する場合、論理積演算子４００４によって提供される出力は、ｘ＝１２の値を含まないであろう。別の例として、仮に一次元範囲トライ４７０２及び４７０３が両方とも、図４０の各範囲トライ４００２及び４００３と同じであり、範囲［１５，…，５５］内のｘ値のみを格納し、そしてそれぞれ範囲［３０，…，３１］内のｙ値のみを格納する場合、論理積演算子４００４によって提供される出力は、ｘ＝１６の値のみを含むことになろう。
ファジーサーチ
テキスト検索用途での往々にしての要件は、近似文字列一致−ファジーサーチ機能とも呼ばれる−を提供することである。これは、パターンに厳密ではなく概ね一致する文字列の発見である。
この「ファジーさ」（２つの文字列シーケンス間の差）の典型的な尺度は、レーベンシュタイン距離である。２つの文字列間のレーベンシュタイン距離は、ある文字列を別の文字列に変更するのに必要な一文字編集（文字の挿入、削除、又は置換）の最小数である。
上述した仮想範囲トライと同様に、本発明の一態様は、インデックストライのようなストレージトライとブールＡＮＤを使用して論理積演算されて、一致するキー列又は一致するキー列を含むドキュメントを返す、好ましくは仮想のファジー一致トライに関する。インデックストライは、上述したように、２つのキー部（文字列，長）として、発生した言葉及びドキュメントＩＤをそれぞれ格納し得る。
本発明のこの態様によれば、データは、近似文字列一致を実行することによって電子データベース又は情報検索システムから検索される。まず、サーチ文字列が取得される。次に、サーチ文字列及び／又はサーチ文字列の変形を含む近似文字列の集合を格納している一致トライが構築される。一致トライは、論理積演算を使用して、電子データベース若しくは情報検索システムに格納された文字列の集合又は電子データベースクエリ若しくは情報検索システムクエリの結果文字列を格納したストレージトライと結合される。換言すれば、結果トライの少なくとも部分は評価され、結果トライは、論理積演算を使用した、電子データベース又は情報検索システムに記憶された文字列の集合を記憶したストレージトライとの一致トライの結合である。結果トライは、ストレージトライにより記憶されたキーの集合が一致トライにより記憶されたキーの集合と論理積演算される場合、取得されるキーの集合を記憶したトライである。
ストレージトライは、例えば、（文字列，長）等の２つのキー部として、ドキュメントに含まれる文字列及び各ドキュメント識別子を格納するインデックストライであり得る。一致トライに記憶された文字列の集合に含まれる文字列は通常、電子データベース又は情報検索システムに永続的に記憶され、及び／又は電子データベース又は情報検索システム内のエントリを表す。
上述した論理積のように、結果トライが取得される。結果トライ内の各ノードの子ノードの集合は、一致トライ内の対応するノードの子ノードの集合と、ストレージトライ内の対応するノードの子ノードの集合との論理積であり、同じキーが異なるトライのノードに関連付けられている場合、異なるトライのノードは互いに対応する。通常、一致トライ、ストレージトライ、及び結果トライは、同じ構造又はフォーマットを有する。このセクションにおいて別段のことが記される場合を除き、上述したトライへの論理積演算の全ての態様は、ファジーサーチの状況でのトライの論理積にも当てはまる。
上述したように、トライは１つ又は複数のノードを含み、各子ノードにはキー部分が関連付けられ、ルートノードからトライ内の別のノードへのパスは、ノードに関連付けられたキーを定義し、キーは、パス上のノードに関連付けられたキー部分を連結したものである。トライは、上述したトライデータ構造を使用して実施することができる。しかしながら、上述した例とは異なり、一致トライは通常、無向サイクルである。これは、一致トライ内の子ノードが２つ以上の親ノードを有し得ることを意味する。無向サイクルの例は図４８Ｂ〜図４８Ｅに提供され、詳細に後述する。これとは対照的に、ストレージトライ及び結果トライ内の各子ノードは通常、１つのみの親ノードを有する。
本発明によるファジーサーチは、一致トライが、ストレージトライとの一致トライの論理積中、動的に生成される仮想トライであるそれ、特に効率的である。「遅延評価」と呼ばれることもある、ストレージトライとの一致トライの論理積に必要な仮想トライの部分のみが（動的に）生成される。このセクションにおいて別段のことが記される場合を除き、上述した仮想トライの全ての態様は、ファジーサーチの状況での仮想一致トライの使用にも当てはまる。
ファジーサーチの出力として、文字列及び／又は結果トライのノードの結果集合に関連付けられたドキュメント識別子等の他のデータ項目が提供される。通常、一致トライは一致ノードの集合を含み、各一致ノードには、近似文字列の集合からの文字列の１つに対応する１つ又は複数のキーが関連付けられる。この場合、ノードの結果集合は、一致トライ内の一致ノード（結果トライのノードに関連付けられたキーが、一致トライのノードに関連付けられたキーと同一である場合、結果トライのノードは一致トライのノードに対応する）の集合に対応する結果トライのノードの集合であり得る。これは、一致トライの一致ノードに対応する結果トライのノードに関連付けられた、ドキュメント識別子のような文字列データ項目のみが出力として提供されることを意味する。
図４８Ａ〜図４８Ｅを参照して、サーチ文字列及び／又はサーチ文字列の変形を含む近似文字列の集合を格納する（仮想）一致トライをいかに生成することができるかについてこれより説明する。一致トライは、近似文字列の集合を表す有限オートマトンから導出される。まず、近似文字列の集合を表す非決定性有限オートマトンが構築される。非決定性オートマトンでは、２つの状態間のあらゆる遷移には通常、サーチ文字列に含まれる特定の文字、又はワイルドカード文字、又は空文字列が関連付けられる。非決定性有限オートマトンから、近似文字列の集合を表す決定性有限オートマトンも導出することができ、決定性有限オートマトンの２つの状態間の遷移には通常、サーチ文字列に含まれる特定の文字又はワイルドカード文字が関連付けられる。次に、一致トライが決定性有限オートマトンから導出される。
図４８Ａは、レーベンシュタインオートマトンとも呼ばれる、最大編集距離２を有するサーチ文字列「ａｂｃ」に一致する非決定性有限オートマトン（ＮＦＡ）を示す。当業者には既知のように、有限オートマトンは、状態と、状態間の遷移とを含む。参照番号０００１で記された状態は開始状態であり、状態０００６は０編集の場合の一致終了状態であり、状態０００７は１編集の場合の状態であり、状態０００８は２編集の場合の状態である。より大きな編集距離では、追加の状態行を上に追加する必要があり、より大きな文字列は右に追加の状態を生成する。
状態０００２は、一致する最初の文字（「ａ」）の状態遷移である。入力として「ａｂｃ」の場合、最終状態０００６に達する。状態０００３は、例えば、「ｘａｂｃ」がオートマトンに提供される場合、冒頭に挿入された文字の状態遷移である。状態遷移０００４は文字置換を反映し、例えば、「ｙｂｃ」をオートマトンに提供する。最後に、遷移０００５は文字削除を反映し、例えば、「ｂｃ」をオートマトンに提供する。
見て分かるように、図４８Ａのオートマトンは非決定性である。例えば、最初の入力文字として「ａ」を提供すると、状態０１、１１、１０、１２、２１、２２、及び３２が生じる。「ａｂｃ」は、「ａ」にするために２つの文字を削除する必要があるため、状態のこの集合は一致状態（３２、参照番号０００８）を含む。
ＮＦＡは、例えば、いわゆる冪集合構築法を使用して決定性有限オートマトン（ＤＦＡ）に変換することができる。レーベンシュタインオートマトンＤＦＡを効率的に作成する他の方法は、Klaus Schulz及びStoyan Mihovによって提案されたものを含む。図４８Ｂは、編集距離１で「ａｂｃ」を照合して、例での状態数を低減するそのようなＤＦＡを示す。参照番号１００１で記された状態は開始状態である。参照番号１００２は、特定の文字（「ｂ」）の遷移を指す。参照番号１００３は、任意の他の文字（ワイルドカード）の遷移を指す。１００５と記された状態のようなグレー状態は一致状態である。
好ましい実施形態では、一致トライ及びストレージトライ内の親ノードは、ビットマップを含み、トライ内の子ノードのキー部分の値は、ビットが子ノードに関連付けられた子ノードの親ノードに含まれるビットマップ内の（設定）ビットの値によって決まる。そのようなトライデータ構造は、上記例において説明されている。一致トライの子ノードとストレージトライの子ノードとの論理積は、論理積演算を使用して各子ノードのビットマップを結合することによって達成することができるため、特に効率的な論理積演算が可能になる。
そのようなデータ構造を有する一致トライは、特定の文字又は遷移に関連付けられたワイルドカード文字の符号化により有限オートマトンの状態間の遷移を関連付けることにより、拡張有限オートマトンを得ることによって（決定性）有限オートマトンから導出することができ、符号化は、長さ及び／又はフォーマットが一致トライの親ノードに含まれるビットマップに等しい１つ又は複数のビットマップからなり、又はビットマップを表す。特定の文字の符号化の場合、符号化に含まれるか、又は符号化によって表されるビットマップのそれぞれにおいて、厳密に１ビットが設定される。ワイルドカード文字の符号化の場合、全ての有効文字符号化のビットが、符号化に含まれるか、又は符号化によって表されるビットマップにおいて設定され、それにより、全ての有効文字符号化（又は遷移元の状態に関連付けられた特定の文字の符号化を除く全ての有効文字符号化のビット）を「マスキング」する。換言すれば、ワイルドカードの符号化は、全ての有効文字符号化（又は遷移元の状態に関連付けられた特定の文字の符号化を除く全ての有効文字符号化）のビットマップのＯＲ結合である。
図４８Ｃは、図４８ＢのＤＦＡの遷移のそのような拡張を示し、図２１を参照に上述したユニコード文字及びユニコード文字の文字列の符号化方式が使用される。読みやすさのために、１０ビットユニコード文字符号化のみが使用される。これらの符号化は、それぞれ６４ビットの２つのビットマップを使用する。上述したように、これらのビットマップのそれぞれにおいて厳密に１ビットが設定されるため、それぞれ６ビット（２６＝６４）を符号化することが可能である。
符号化２００１は、２つの６ビット値１（「０００００１」）及び３３（「１０００１」）として符号化される「ａ」を表し、ビット位置当たりの符号化は、
Figure 2021517306
 である。
００００＝０、０００１＝１、００１０＝２、００１１＝３、…、１１１１＝Ｆである十六進数表現では、これは０ｘ０００００００００００００００２及び０ｘ０００００００２００００００００に対応する。
符号化２００３は、２つの６ビット値１（「０００００１」）及び３４（「１００１０」）として符号化された「ｂ」を表し、ビット位置当たりの符号化は、
Figure 2021517306
 である。
十六進数表現では、これは０ｘ０００００００００００００００２及び０ｘ０００００００４００００００００に対応する。
ワイルドカードの場合、許された全ての文字−この場合、完全なユニコード英字−の符号化のビットは設定される。例えば、符号化２００２は、全ての１０ビット符号化ユニコード文字、すなわち、６ビット値「００００００」…「００１１１１」及び「００００００」…「１１１１１１」を表すように設定されたビットを有し、ビット位置当たりの符号化は、
Figure 2021517306
 である。
十六進数表現では、これは０ｘ００００００００００００ＦＦＦＦ及び０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦに対応する。
符号化２００４及び２００５は同じ文字「ｂ」を示し、一方は非最終の場合であり、一方は一致状態、すなわち、「ｂ」が入力文字列の最後の文字である場合のものである。符号化２００６及び２００７は、ワイルドカード文字のアナログの場合を示す。２００８及び２００９は、文字「ｃ」及びワイルドカードの最終一致状態の場合を示す。
非一致状態に繋がる全てのユニコード文字の完全なワイルドカードマスク（図２１を参照して先に説明したように、１０ビット、１５ビット、及び２１ビット符号化）は：
Figure 2021517306
 である。
一致状態に繋がる全てのユニコード文字の完全なワイルドカードマスクは：
Figure 2021517306
 である。
図４８Ｄは、２つのキー部分によって表される各１０ビットユニコード文字を有する、結果として生成された一致トライの上部を示す。トライへのブールＡＮＤ演算子はまず、ビットマップを必要とし、後に一致する子に降下するため、特定の文字は１ビットとして符号化され、ワイルドカードは、全ての有効文字符号化で設定されたビットを有するビットマップとして符号化される。
そのような一致トライは、上述した任意の有限オートマトンから、特に拡張有限オートマトンから直接導出することができる。しかしながら、一致トライ、ストレージトライ、又は結果トライに格納された文字が、各トライのＭ＞１個のキー部分により、すなわち、２つ以上のレベルのノードによって符号化される場合、一致トライは好ましくは、近似文字列の集合を表す完全有限オートマトンから導出される。好ましくは、Ｍは２〜４である。
有限オートマトンの２つの状態間の遷移、好ましくはあらゆる遷移により、又は有限オートマトンの１つの状態間の遷移、好ましくはあらゆる遷移を、Ｍ−１子の中間状態を介して２つの状態をリンクするＭ個の遷移の１つ又は複数のシーケンスで置換又は関連付けることにより、好ましくは上述した決定性有限オートマトンから、より好ましくは拡張有限オートマトンからの完全有限オートマトン。したがって、完全な文字列に関連付けられていない状態は有限オートマトンに追加される。
例えば、図４８Ｂ及び図４８Ｃの有限オートマトンでは、状態０に発端し、状態１で終わる遷移がある。完全有限オートマトンでは、図４８Ｄから明らかになるように、この遷移は、中間状態１１０と、状態１と状態１１０との間の遷移及び状態１１０と状態１との間の別の遷移を含む一連の遷移とで置換される。別の例として、図４８Ｂ及び図４８Ｃの有限オートマトンでは、状態０に発端し、状態１０で終わる遷移がある。完全有限オートマトンでは、この遷移は、中間状態１１０と、状態１と状態１１０との間の遷移及び状態１１０と状態１０との間の別の遷移を含む一連の遷移とによって置換される。第３の例として、図４８Ｂ及び図４８Ｃの有限オートマトンでは、状態０に発端し、状態１４で終わる遷移がある。完全有限オートマトンでは、この遷移は、中間状態１１０及び１１１と、２つの遷移シーケンスとによって置換される。第１の遷移シーケンスは、状態１と状態１１０との間の遷移及び状態１１０と状態１４との間の別の遷移を含む。第２の遷移シーケンスは、状態１と状態１１１との間の遷移及び状態１１１と状態１４との間の別の遷移を含む。
シーケンス内のＭ個の遷移のそれぞれには、長さ及び／又はフォーマットが一致トライの親ノードに含まれるビットマップに等しいビットマップからなるか、又はビットマップを表す中間符号化が関連付けられ、一致トライは完全有限オートマトンから導出される。符号化は、全体文字の符号化の一部のみ、図４８Ｄの一致トライを導出することができる完全有限オートマトンの例では、全体文字の符号化の半分を表すため、本明細書では「中間」と呼ばれる。
例えば、図４８Ｄの一致トライを導出することができる完全有限オートマトンでは、状態０と状態１１０との間の遷移には、以下のビットマップからなるか、又は以下のビットマップを表す符号化が関連付けられる。
Figure 2021517306
十六進数表現では、これは０ｘ０００００００００００００００２に対応する。状態０と状態１１０との間の遷移とのこの符号化の関連付けは、符号化２００１その遷移間の上部破線矢印で示される。この矢印が指す「１」は、図４８Ｄの一致トライの親ノード０に含まれるビットマップ内のビット番号１（２番目のビット）を表す。
別の例として、図４８Ｄの一致トライを導出することができる完全有限オートマトンでは、状態０と状態１１１との間の遷移には、以下のビットマップからなるか、又は以下のビットマップを表す符号化が関連付けられる。
Figure 2021517306
十六進数表現では、これは０ｘ００００００００００００ＦＦＦＦに対応する。状態０と状態１１１との間の遷移とのこの符号化の関連付けは、符号化２００２その遷移間の上部破線矢印で示される。この矢印が指す「０，２，…，６３」は、図４８Ｄの一致トライの親ノード０に含まれるビットマップ内のビット番号０、２、…、６３（１番目、３番目、…、６４番目のビット）を表す。
有限オートマトンの２つの状態間の遷移に特定の文字が関連付けられる場合、シーケンスのＭ個の遷移に関連付けられた中間符号化に含まれるか、又は表されるビットマップを連結したものは、特定の文字の符号化であり、各ビットマップにおいて厳密に１ビットが設定される。
図４８Ｂ及び図４８Ｃの有限オートマトンの例では、状態０と状態１との間の遷移には文字「ａ」が関連付けられる。したがって、図４８Ｄの一致トライを導出することができる完全有限オートマトンでは、状態０と状態１との間の（状態１１０を介した）２つの遷移に関連付けられた中間符号化に含まれるか、又は表されるビットマップを連結したものは、文字「ａ」の符号化であり、各ビットマップにおいて厳密に１ビットが設定される。この符号化は以下である。
Figure 2021517306
十六進数表現では、これは０ｘ０００００００００００００００２及び０ｘ０００００００２００００００００に対応する。
有限オートマトンの２つの状態間の遷移にワイルドカード文字が関連付けられる場合、シーケンスのＭ個の遷移に関連付けられた中間符号化に含まれるか、又は表されるビットマップを連結したものは、符号化に含まれるか、若しくは表されるビットマップにおいて全ての有効文字符号化のビットが設定されるか、又は遷移元の状態に関連付けられた特定の文字の符号化を除く全ての有効文字符号化のビット 符号化を含む。
図４８Ｂ及び図４８Ｃの有限オートマトンの例では、状態０と状態１４との間の遷移にはワイルドカード文字が関連付けられる。したがって、図４８Ｄの一致トライを導出することができる完全有限オートマトンでは、状態０と状態１４との間の（状態１１１を介した）２つの遷移に関連付けられた中間符号化のシーケンスの１つに含まれるか、又は表されるビットマップを連結したものは、ワイルドカード文字の符号化である。この符号化は以下である：
Figure 2021517306
十六進数表現では、これは０ｘ００００００００００００ＦＦＦＦ及び０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦに対応する。
更に、有限オートマトンの２つの状態間の遷移にワイルドカード文字が関連付けられる場合、シーケンスのＭ個の遷移に関連付けられた中間符号化に含まれるか、又は表されるビットマップを連結したものは通常、特定の文字の符号化の１つ又は複数の部分と、符号化に含まれるか、若しくは表されるビットマップにおいて全ての有効文字符号化のビットが設定されるか、又は遷移元の状態に関連付けられた特定の文字の符号化を除く全ての有効文字符号化のビット符号化の１つ又は複数の部分とを含む１つ又は複数の符号化を含む。
例えば、図４８Ｄの一致トライを導出することができる完全有限オートマトンでは、状態０と状態１４との間の（状態１１０を介した）２つの遷移に関連付けられた中間符号化のシーケンスの１つに含まれるか、又は表されるビットマップを連結したものは、文字「ａ」の符号化の第１の部分（これは、文字「ｂ」の符号化の第１の部分でもある）と、ワイルドカード文字の符号化の第２の部分とを含む符号化である。この符号化は以下である：
Figure 2021517306
十六進数表現では、これは０ｘ０００００００００００００００２及び０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦに対応する。
拡張有限オートマトン又は完全有限オートマトンはそれぞれ、各行が拡張有限オートマトン又は完全有限オートマトンの１つの状態を表す幾つかの行と、それぞれが遷移に関連付けられた符号化及び遷移が終わる状態への参照を含む、状態を発端とする各遷移のタプルとを含むデータ構造により表し、又は格納することができる。図４８Ｅは、特に効率的に図４８Ｄの一致トライを導出することができる完全有限オートマトンの状態を表すのに使用することができる、１つ又は複数の配列としてそのようなデータ構造を示す。そのようなデータ構造は、好ましくは状態への各参照におけるビットとして符号化される、遷移が終わる各状態について、この状態が一致状態であるか否かについての情報を含むことができる。データ構造は通常、遷移元の拡張有限オートマトン又は完全有限オートマトンのそれぞれの各状態に行を含む。
この（仮想）一致トライ手法に伴う恩恵は、複雑な状態マシン等を使用する必要がないため、効率的な実行に繋がる実装の簡易性に起因するとともに、好ましい実施形態においてＡＮＤ演算子がビットマップに対して機能する方法にも起因した良好な性能である。
インデックス手法及び性能測定
本発明の様々な実施形態による範囲クエリの性能を測定するために、実験を行い、その結果について図５３〜図７０を参照して以下に考察する。一例として、空間クエリを用いるジオロケーション用途を使用した。サンプルデータは、欧州領域のＯｐｅｎＳｔｒｅｅｔＭａｐデータから導出し、これはｈｔｔｐ：／／ｄｏｗｎｌｏａｄ．ｇｅｏｆａｂｒｉｋ．ｄｅ／ｅｕｒｏｐｅ．ｈｔｍｌから取得することができる。一例のデータベース内の各エントリは、１０桁のＩＤ、各経度及び緯度の少数点以下７桁を有する値、並びに通りの名称及び家屋番号を表す文字列を含んだ。
Figure 2021517306
第１の実験は、インデックスサイズ（索引付けられるレコードの量）が一定結果サイズのクエリ処理性能にいかに影響するかを調べるために行った。データベースに問い合わせて、ミュンヘン地域内の小さな矩形（図４９に示されるように、経度１１．５８１９８１＋／−０．０１及び緯度４８．１３５１２５＋／−０．０１）内の全てのロケーションのＩＤを返した。データベースは合計で約２８５０万のレコードを含み、そのうち３，１４３個が一致した。
第１の測定シリーズでは、一致レコードがまずデータベースにロードされ、次に、約２８５０万個の他のレコードがデータベースに追加された。これらの他のレコードを図５０において陰影付きエリアとして示す。１００，０００個のレコードが追加される都度、追加後、クエリを行い、その実行時間を測定した。明らかに、あらゆるクエリは３，１４３の一致を返した。
第２の測定シリーズでも、まず矩形内の一致レコードをデータベースにロードするが、残りのレコードは、一致する経度又は緯度の「帯」内のレコードなしでロードした。第２の測定シリーズでロードした残りのレコードを図５１に示す。
第１の実験を索引付け及びジオロケーションクエリの５つの異なる手法で実行した。
本明細書では「従来技術による索引付け」と呼ばれる従来技術による手法では、経度及び緯度を含む空間索引付けをサポートするApache Lucene ６．０．１データベースエンジンのSpatialPrefixTreeを使用した（https://lucene.apache.org, package org.apache.lucene.spatial.prefix.tree）。SpatialPrefixTreeはトライではなく、空間クエリに最適化された逆インデックスの作成に使用された。したがって、ここでとられる手法の良好なベンチマークを提供した。
指定された矩形内の全てのロケーションを問い合わせるために、範囲クエリを両次元で実行した。クエリはそれぞれ、カーソルベースの反復子によって収集されて暫定結果集合を作成した、指定された経度帯又は緯度帯に配置されたレコードを表すＩＤの集合を返した。暫定結果集合を論理積演算して、最終結果集合を取得した。これを図５２に示し、図５２では、陰影付きエリアは指定された経度及び緯度の帯（暫定結果集合）を記し、黒色エリアは指定された矩形（最終結果集合）を記す。SpatialPrefixTreeはトライではなく、空間クエリに最適化された逆インデックスの作成に使用される。クエリ性能は、図５８〜図６０を参照して以下に説明するトライの可変精度索引付けと同様に、解像度の幾つかのレベルで幾つかのインデックスを作成することにより改善した。
図５３は、従来技術による手法の測定結果を示す。ｘ軸はデータベースにロードされたレコード数を示し、ｙ軸は、対数尺度での毎秒当たり実行されたクエリ数を示す。一致した帯をデータベースにロードした場合及びしない場合で、クエリ性能は、データベース内のレコード数の増大に伴って低下することを観察することができる。この性能挙動は、アクセス時間がインデックスの充填レベルに依存する従来技術によるデータベースに典型的である。
上述したトライの好ましい実施形態を使用してジオロケーションを索引付け問い合わせる第１の手法を行い、これを本明細書では「標準索引付け」と呼ぶ。経度に１つのインデックスが好ましい実施形態の第１の二次元トライによって作成され、緯度に別のインデックスが好ましい実施形態の第２の二次元トライによって作成された。換言すれば、各二次元インデックストライは２つの項目、すなわち、（経度，ＩＤ）又は（緯度，ＩＤ）をそれぞれ格納した。二次元インデックストライは、図４４のトライにおいて先に示したように、非インタリーブ様式で格納され、経度／緯度が第１のキー部を形成し、ＩＤが第２のキー部を形成した。抽象的な視点から、これにより、全ての経度／緯度を含むトライが生成され、各リーフノードは、図５４に示すように、各経度／緯度を有する全てのロケーションのＩＤを含むトライのルートである。
第１のキー部（経度／緯度）にわたる範囲クエリは、一致した経度／緯度を有するロケーションのＩＤのトライルートを返した。トライインターフェースを用いてこれらの結果を届けるために、図５５に示すように、トライインターフェースを提供するマルチＯＲ演算子を使用してトライルートのリストを結合した。したがって、図５６に示すように、本発明による標準索引付けは２つのインデックストライ５６０１、５６０３を使用し、各インデックストライは２つのキー部（経度，ＩＤ）又は（緯度，ＩＤ）を有した。トライの第１のキー部について、仮想経度／緯度トライ５６０２、５６０４を使用して範囲クエリを実行した。マルチＯＲ演算子５６０５、５６０６を使用して各範囲クエリの結果を結合した。ＡＮＤ演算子５６０７を使用して２つのマルチＯＲ演算子の結果を結合し、最終結果を届けた。
図５７は、標準索引付けの測定結果を示す。一致レコードをデータベースにロードしない場合、クエリ処理時間は一定であり、これは、トライが一定のアクセス時間を有する、すなわち、充填レベルから独立することによることを観察することができる。クエリ処理時間はまた、従来技術による手法を使用した場合の約１／１０であり、LuceneデータベースエンジンのSpatialPrefixTreeが空間クエリに最適化されることを考慮して、これは注目に値する。
一致レコードをデータベースにロードする場合、標準索引付けのクエリ性能は低下し、これは、独立した経度クエリ及び緯度クエリのますます多くの結果を結合する必要があったためである。一致レコードを用いての標準索引付けの性能は、ノード（ＩＤ）の長いリストが生じるため、あまりよくない。性能を改善するために、ＯＲ演算によって結合する必要があるノードの量を低減する必要がある。
本明細書において「可変精度索引付け」と呼ばれる手法では、ＯＲ演算する必要があるノードの量は、可変精度を有する複数のインデックスを維持し、階層を作成することによって劇的に低減することができる。これは、上述した従来技術によるデータベースエンジンにおいて幾つかの解像度レベルの幾つかのインデックスを作成することの概念と同等である。例えば、２桁十進数を格納するトライにおいて範囲を使用することにより、プレフィックスを表す各レベルにインデックスを有することができる。
−０， １， ２， ．．． ９
−００， ０１， ０２， ．．．， ０９， １０， ．．． ９９
例として、第１レベルのＸ値（最初のキー部）のインデックスを図５８に示し、Ｘ値の第２レベルのインデックスを図５９に示し、２番目のキー部（Ｙ項目）はＩＤであることができる。図５８に示される第１レベルのインデックス内のエントリ（最初のキー部又はＸ項目のリーフ）は、各プレフィックス範囲内のＸ値の全てのＩＤ（２番目のキー部のトライ）を含む。１０〜５３のＸ値のクエリは、図５８のインデックスへの範囲１、…、４のクエリの結果（破線矩形で記された２つのヒット）と、図５９のインデックスへの範囲５０、…、５３のクエリの結果（破線矩形で記された１つのヒット）とを結合する。これにより、図５９のインデックストライのみを使用する場合の５つのノードの代わりに、続くマルチＯＲ演算で結合する必要があるノードは３つのみである。
本発明者が行った実際の実験は、各精度ステップに６ビットを使用した。精度長はキーの最初のバイトに格納された。トライは１１のレベルを有し、トライ内のノードは、ルートレベルで最高で１６個の子ノードを有し、１０の後続レベル（リーフノードを含む）で最高で６４個の子ノードを有した。これは、ルートレベルにおいて最大で１６−２個のノード及びトライの左右の部分での次のレベルで２＊（６４−１）個のノードをＯＲ演算する必要があったことを意味する。これにより、ＯＲ演算する必要がある上限は１６−２＋２＊（６４−１）＊１０＝１２７４個のトライになる。範囲クエリを受けるあらゆるキー値は、１１個の精度レベルで格納した。上述した仮想範囲トライに基づく範囲クエリを使用して、クエリを実行した。必要とされるノードを選択するのに必要な全てのキーのリストを作成した。
図６０は、可変精度索引付けの測定結果を示す。一致帯がロードされない場合、クエリ実行は非常に高速（標準索引付けを使用する場合よりも約１０倍高速）であり、一定時間を有する。一致レコードがデータベースにロードされる場合であっても、クエリ性能は略一定である。しかしながら、以下に示すように、可変精度索引付けは、メモリ需要及び索引付け性能に関して高価である。
本明細書では「二次元索引付け」と呼ばれるジオロケーションを索引付け問い合わせる別の手法は、標準索引付けよりも高速であるが、可変精度索引付けの欠点がない解決策あることを示した。図６１に示すこの手法では、データベースエントリの経度／緯度及びＩＤは、例えば、図３２及び図４６を参照して上述した構造を有するインタリーブトライに格納された。標準索引付けと同様に、経度及び緯度は、２つの異なるトライであるトライ６１１０（経度，ＩＤ）及びトライ６１２０（緯度，ＩＤ）で別個に索引付けられた。
矩形を問い合わせるために、経度範囲を指定する仮想範囲トライ６１３０及び緯度範囲を指定する仮想範囲トライ６１４０を作成した。経度インデックスが経度範囲トライと論理積演算され、同時に、緯度インデックスが緯度範囲トライと論理積演算される場合、論理積の中間結果は、以下に説明するように結合された。
最初のステップにおいて、図６１において矢印６１５１で示されるように、ビット単位ＡＮＤ演算を経度インデックストライ６１１０のルートノード６１１１のビットマップと、経度範囲トライ６１３０のルートノードとの間で実行する。同様に、図６１において矢印６１５２で示されるように、ビット単位ＡＮＤ演算を緯度インデックストライ６１２０のルートノード６１２１のビットマップと、緯度範囲トライ６１３０のルートノードとの間で実行する。
図６１におけるノード６１１２及び６１２２は、インデックストライ６１１０及び６１２０のレベル２におけるノードを表す。レベル２におけるこれらのノードのそれぞれは、インデックス内のＩＤキー部のルートノードである。したがって、経度インデックストライ６１１０のルートノード６１１１のビットマップと、経度範囲トライ６１３０のルートノードとの間のビット単位ＡＮＤ演算は、指定された経度範囲を有するロケーションに属するＩＤの第１のキー部分を生成し、緯度インデックストライ６１２０のルートノード６１２１のビットマップと、緯度範囲トライ６１４０のルートノードとの間ビット単位ＡＮＤ演算は、指定された緯度範囲を有するロケーションに属するＩＤの第１のキー部分を生成する。
２番目のステップにおいて、指定された経度範囲及び緯度範囲の両方に入るロケーションに属さないインデックストライ内のキーは以下のようにフィルタリングされて除外される：最初のステップによって生成された経度／緯度インデックストライ６１１０／６１２０のノードのビットマップは、ビット単位ＯＲ演算によって結合され、図６１において矢印６１５３で示されるように、ビット単位ＯＲ演算の結果間でビット単位ＡＮＤ演算を実行する。
図６１におけるノード６１１３及び６１２３は、インデックストライ６１１０及び６１２０のレベル３におけるノードを表す。レベル３におけるこれらの各ノードは、インデックストライに格納された経度／緯度キー部の第２のキー部分を格納する。３番目のステップにおける演算は、２番目のステップにおいてフィルタリングされて除外されなかったキーに属するレベル３におけるノードを用いて続く。ビット単位ＡＮＤ演算が、図６１において矢印６１５４、６１５５で示されるように、これらのノードのビットマップと、各範囲トライ６１３０、６１４０の対応するノード（レベル２における）との間で実行される。
図６１におけるノード６１１４及び６１２４は、インデックストライ６１１０及び６１２０のレベル４におけるノードを表す。レベル４におけるこれらの各ノードは、インデックストライに格納されたＩＤキー部の第２のキー部分を格納する。４番目のステップにおける演算は、３番目のステップにおけるビット単位ＡＮＤ演算の結果として生成されたレベル４におけるノードを用いて続く。２番目のステップと同様に、同じ親ノードを有する最初のステップにより生成された経度／緯度インデックストライ６１１０／６１２０のノードのビットマップは、ビット単位ＯＲ演算によって結合され、図６１において矢印６１５６で示されるように、ビット単位ＡＮＤ演算が、ビット単位ＯＲ演算の対応する結果間で実行される。
演算は、インデックストライのリーフノードに達するまで、同じように続けられた。まとめると、一次元（ｘ）のみを有するインデックスが交互になった「ビュー」を返すマッチャーを使用して２つのインデックスを結合した。第２の次元は、マッチャーの出力において抑制された。
図６２は、二次元索引付けの測定結果を示す。ここでも、一致帯がデータベースにロードされない場合、クエリ時間は一定であった。一致帯がデータベースにロードされる場合、クエリ性能は標準索引付けと比較して有意に改善した。
次元を照合し抑制する戦略は原理上、３つ以上の次元に適用することができる。しかしながら、これは、ノードの大きな連鎖を生じさせる：ｘ次元の各ノードはｙ次元の６４個の子を有し得、ｙ次元の６４個の子はここでも、６４個の子を有し得、合計で既に４０９６個の子を有し得る
本明細書では「シングルインデックス索引付け」と呼ばれるジオロケーションを索引付け問い合わせる最後の手法では、１つのみの多次元インデックスが作成され、多次元インデックスは、例えば、図３２及び図４６を参照して上述したように、経度及び緯度の両方を１つのインタリーブトライに格納する。このインデックストライの概略を図６３に示す。図６３では、経度及び緯度を表す第１及び第２のキー部Ｘ及びＹはインタリーブ様式で格納され、ロケーションのＩＤを表す第３のキー部は、Ｘ／Ｙトライのリーフに従属するサブトライに格納される。各サブトライに格納されたＩＤは、同じ経度及び緯度を有するロケーションの集合に属する。
矩形を問い合わせるために、例えば、図４０を参照して上述したように次元範囲クエリを実行した。図６４に示されるように、経度の範囲は、第１の一次元仮想範囲トライ６４０２によって指定され、緯度の範囲は、第２の一次元仮想範囲トライ６４０３によって指定された。両一次元範囲トライは、インタリーブ演算子６４０４によって結合されて、インタリーブ二次元範囲トライを形成する。一致する経度及び緯度に属するＩＤサブトライの集合を得るために、ＡＮＤ演算子６４０５は、二次元範囲トライとインデックストライ６４０１のＸ／Ｙ部分との間で論理積を実行する。
図６５は、シングルインデックス索引付けの測定結果を示す。シングルインデックス索引付けが完全なスケーラビリティを提供し、一致帯がロードされた場合であっても、クエリ性能がデータベース内のレコード数に著しく依存しないことを観察することができた。なお、性能における急な山は、Java仮想マシンガベージコレクションによって生じた。
図６６は、結果サイズの増大に伴ってクエリ性能（毎秒当たりのクエリ数）を測定した第２の実験の結果を示す。クエリ矩形は、緯度及び経度で＋／−０．０１度から＋／−０．２０度に増大した。２８５０万レコードをまず、データベースにロードした。可変精度索引付けが、より大きな結果で最良にスケーリングされる（なお、メモリ制約に起因して、可変精度索引付けでは部分データのみをロードすることができた）ことを観察することができた。シングルインデックス索引付けも良好な性能を提供する。これは特に、緯度及び経度に加えて、ＩＤもインタリーブ様式で格納される場合、当てはまる。三重インタリーブインデックス結果の性能利得が、増大した数の共通プレフィックスパスから生じると考えられ、これは、より小さなメモリフットプリント（４６．０１バイト／ポイント対４４．７６バイト／ポイント）によっても証明される。ツリー内の分岐数が少なく、ツリーをトラバースする再帰ステップ数の減少に繋がり得るため、性能はより良好であり得る。
Luceneデータベースを使用した従来技術による索引付けは、全ての結果サイズで略一定の結果を届けたが、シングルインデックス索引付けよりも低い性能レベルであった。標準索引付け（インタリーブされない２つのインデックス）及び二次元索引付け（インタリーブされた２つのインデックス）の性能は、小さな結果サイズでのLuceneデータベースを使用した従来技術による索引付けよりも良好であったが、大きな結果サイズでは性能が低下した。図６７は、図６６と同じであるが、ｘ軸に対数尺度を有する結果を示す。この表現では、本発明によるインデックスのクエリ性能が、結果サイズが増大する場合、直線で低下することが分かる。これは、特に２つのシングルインデックス手法が線形スケーラビリティを有し、すなわち、結果サイズが２倍になると、クエリ時間も２倍になることを意味する。
第３の実験では、索引付け性能（毎秒当たり索引付けされるエントリ数）を測定した。２８５０万個のレコードをロードし、１００，０００個の追加レコード毎に時間を測定した。従来技術によるインデックス及び全てのトライベースの手法は、インデックスの増大に伴って実際に一定の性能を提供することを観察することができる。結果を図６８にまとめる。上述したように、可変精度索引付けの性能は、２ｘ１１個のインデックスエントリをレコード毎に作成する必要があるであるため、あまりよくない。可変精度索引付けと同様の手法である従来技術によるインデックス（Lucene）の性能は更に悪かった。トライベースの標準索引付け及び二次元索引付けは両方ともレコード毎に２つのインデックスエントリを作成し、したがって、同様の索引付け性能を有する。シングルインデックス索引付けは、レコード毎に１つのみのインデックスを作成し、性能が最良である。なお、トライベースの手法では、黒色列は非圧縮トライの結果を表し、明るい列はビットマップ圧縮を使用したトライの結果を表す。
図６９は、索引付けられたロケーション当たりの異なるインデックスによって必要とされるメモリ空間を比較する。従来技術によるLuceneインデックスは、ビットマップ圧縮を用いた（明るい列）トライベースの標準索引付け及び二次元索引付けよりも多くの空間を使用し、ビットマップ圧縮を用いない場合であっても、シングルインデックス索引付けよりも多くの空間を使用した。トライベースの可変精度索引付けは、任意の他の手法よりもはるかに多くの空間を必要とした。
標準索引付けが、低又は中基数を有する属性で十分に良好に機能すると結論付けることができる。例えば、製品価格は通常、連続値を有さず、３．９９、４．４９、４．８９等の離散値を有する。ミリ秒精度を有するタイムスタンプとして注文日のような何かを格納する代わりに、値空間を「より」離散させるという要件を満たすために、日精度又は時間精度で格納することで十分であり得る。連続値空間を用いて列を索引付けるために、可変精度索引付けは、特に多次元クエリで使用される場合、より良好な性能を提供する。しかしながら、遅い索引付け及び高いメモリ需要に起因して、可変精度索引付けの使用は、静的用途且つ十分なメモリが利用可能な場合でのみ推奨することができる。密に結びついた次元の場合、シングルインデックス索引付けが、予期される結果サイズが中程度である場合、最良の解決策である。
多次元インデックスは、空間クエリの状況で本明細書に提示されたが、トライベースの範囲クエリは、多くの他の状況、例えば、グラフデータベースに適用することもできる。プロパティグラフデータベースは、エッジで結ばれたノードに基づき、ノード及びエッジは両方ともプロパティを有する。ノード及びエッジがそれぞれ一意のＩＤで表される場合、ノード−エッジ−ノードの三つ組みを表し、これらの３つのＩＤを次元として使用して問い合わせることができる。なお、同じことは、リソース記述フレームワーク（ＲＤＦ）用語で三つ組みと呼ばれる主語−述語−目的語表現を用いるＲＤＦの状況にも当てはまる。
上述したように、本発明は、生じた各言葉及びドキュメントＩＤを２つのキー部（文字列，長）として格納することにより、フルテキストサーチ用途にも容易に使用することができる。本発明はプレフィックスツリーに基づくため、プレフィックスツリーの文字列サーチ機能を受け継ぐ。例えば、ファジー（類似性）サーチの効率的な実施に使用することができる。
実際に、本発明者により実行された測定は、情報検索用途での競争力のある性能を示す。本願の優先日の少し前に実行された実験では、５００，０００の英語Ｗｉｋｉｐｅｄｉａ記事を索引付けた。図７０Ａは、文字数／秒単位でのLucene情報検索ソフトウェアライブラリと比較した本発明の実施形態の平均索引付け性能を示す。本発明のシステムが、長整数の配列が使用された場合（黒色列）のみ、わずかに低い索引付け性能を届けたことが分かる。予期されたように、バイトの配列を用いたビットマップ圧縮が使用された場合（明るい列）、索引付け性能はいくらか低かった。
図７０Ｂはインデックスサイズ（％単位でのインデックスサイズ／テキストサイズ）を比較する。驚くことに、長整数の配列に基づくメモリモデル（黒色列）であってもLuceneと同等であった−位置合わせ損失があったが。バイトの配列を用いたビットマップ圧縮に基づくメモリモデル（明るい列）は、Luceneよりも必要とする空間が少なかった。
図７０Ｃはクエリ性能（クエリ数／秒）を示す。この実験での用語クエリは、「from」と組み合わせて単語「which」又は「his」を含む全てのドキュメントをサーチして、いくらかの複雑性及び量を提供した。複数の同時スレッドを用いて、本発明のシステムの性能は、Luceneよりも最高で７倍高い。
この実験でのファジークエリは、「chica」と同様の単語を含むドキュメントをサーチした。類似性は、編集距離１（レーベンシュタイン距離）により、すなわち、最大で１文字の削除、挿入、及び置換を用いて定義される。この規律では、本発明のシステムは、Luceneよりも４倍〜６倍高速であることが証明された。Lucene及び本発明のシステムの両方が厳密に同量の結果ドキュメントを届けたことに留意することに価値がある：用語クエリでは３１９，８０９、ファジークエリでは３０，９９４。
上述した実験を本願の出願日の少し前、すなわち、約１年後に繰り返した。繰り返した実験の結果は図７０Ｄ〜図７０Ｆに見ることができる。
図７０Ｄにおいて見て取ることができるように、索引付け性能はここで、先の実験よりも低かった。本発明のシステムでは、メモリ管理がここで、いくらかの性能を犠牲にして完全に実施されたため、低かった。Luceneシステムでは、Lucene索引付けが１スレッド／ＣＰＵコアのみで実行されたため、低かった。これは、本発明によるシステムも１スレッド／ＣＰＵコアのみを用いて実施されたため、よりよい比較性を得るために行われた。なお、本発明のシステムによる索引付けは、並列化することもできるが、これは本発明者によってまだ実施されていない。
図７０Ｅは、インデックスサイズが先の実験と比較して実際に同じままであることを示す。
図７０Ｆは、本発明のシステムのクエリ性能が、特にファジーサーチにおいて先の実験と比較して改善したことを示す。先の実験では、図４８Ｃに示すように、完全文字列に関連付けられた状態に対応するノードのみを含むＤＦＡのみが前もって生成された。図４８Ｄに示される中間状態（完全文字列に関連付けられていない有限オートマトンの状態）は、文字の符号化が２つ以上のキー部分を必要とすることに起因して存在し、論理積演算中、オンザフライで動的に特定された。これとは対照的に、後の実験では、状態及び遷移の完全な集合を有する有限オートマトンが前もって生成され、図４８Ｅに示されるように、複数の配列（マトリックス）の配列として格納された。この手法は、約２倍のクエリ性能の改善２もたらした。Luceneシステムは、先の実験と比較して同様の倍数で改善し、この改善は、本願の優先日と出願日との間にLuceneシステムで行われた特定の最適化に起因する。

Claims (42)

  1. 電子データベース又は情報検索システムからデータを検索する方法であって、
    ２つ以上の高次入力トライの表現を取得するステップと、
    高次結果トライの少なくとも部分を評価するステップであって、前記高次結果トライは、論理演算を使用した前記高次入力トライの結合である、評価するステップと、
    出力として、前記結果トライの表現、前記結果トライのノードに関連付けられたキー及び／又は他のデータ項目の集合若しくは部分集合、又は前記結果トライのノードに関連付けられたキーから導出されるキー若しくは値の集合を提供するステップと、
    を含み、
    前記高次入力トライの少なくとも１つの前記表現は、
    ２つ以上の低次入力トライの表現を取得するステップと、
    低次結果トライを少なくとも部分的に評価するステップであって、前記低次結果トライは、前記低次入力トライの低次論理演算を使用した結合である、少なくとも部分的に評価するステップと、
    出力として前記低次結果トライの前記表現を提供するステップと、
    を実行する低次結合演算子の出力として提供され、
    前記低次結果トライの少なくとも部分は、前記高次結果トライの少なくとも部分を評価するステップ中、評価される、方法。
  2. 前記結果トライのリーフに関連付けられたキー及び／又は他のデータ項目は、出力として提供される、請求項１に記載の方法。
  3. 出力として提供された前記キーの集合は、トライで提供される、請求項１又は２に記載の方法。
  4. 出力として提供された前記キーの集合は、カーソル又は反復子により提供される、請求項１又は２に記載の方法。
  5. 前記トライの前記部分は、ノード及び／又は前記ノードの分岐である、請求項１〜４の何れか一項に記載の方法。
  6. トライの表現は、物理的トライデータ構造又は前記トライを評価することが可能なトライ演算子へのハンドルである、請求項１〜５の何れか一項に記載の方法。
  7. トライの表現は、トライのルートノードを表し、トライノードインターフェースを実装し、トライノードインターフェースは、トライノードを表し、それが表す前記トライノードの子ノードをクエリ及び／又はトラバースする方法又は関数を提供する、請求項１〜６の何れか一項に記載の方法。
  8. トライ又はトライの部分を評価することは、前記トライ又は前記トライの前記部分をトラバースすることを含む、請求項１〜７の何れか一項に記載の方法。
  9. トライ又はトライの部分を評価することは、前記トラバースされたノードが前記トライに存在することの情報を提供することを含む、請求項８に記載の方法。
  10. 前記トライ又はトライの部分を評価する間、任意の所与の瞬間において、少なくとも、前記トライ又は前記トライの前記部分の前記トラバースのためにその瞬間に実現する必要がある、前記トライ又は前記トライの前記部分の前記物理的データ構造の部分が実現される、請求項８又は９に記載の方法。
  11. 任意の所与の瞬間において、前記トライ又は前記トライの前記部分の前記物理的データ構造の全体未満が実現され、好ましくは、前記トライ又は前記トライの前記部分の前記トラバースのためにその瞬間に実現する必要がある、前記トライ又は前記トライの前記部分の前記物理的なデータ構造の部分のみが実現される、請求項８〜１０の何れか一項に記載の方法。
  12. トライ又はトライの部分を評価することは、前記トライ又は前記トライの前記部分の前記物理的データ構造を全体として実現することを含む、請求項１〜１０の何れか一項に記載の方法。
  13. 少なくとも、前記低次結果トライの前記表現を取得する瞬間において、前記低次結果トライ又は前記低次結果トライの部分の前記物理的データ構造は全体として、存在しない、請求項１〜１２の何れか一項に記載の方法。
  14. 前記低次結果トライ又は前記低次結果トライの前記部分の前記物理的データ構造は、全体として、実現されない、請求項１〜１３の何れか一項に記載の方法。
  15. 少なくとも、前記高次結果トライの少なくとも部分の前記評価に必要な前記低次結果トライの部分が評価される、請求項１〜１４の何れか一項に記載の方法。
  16. 前記結果トライの少なくとも部分の前記評価に必要ない前記低次結果トライの部分の少なくとも幾つかは、評価されず、好ましくは、前記高次結果トライの少なくとも部分の前記評価に必要な前記低次結果トライの部分のみが評価される、請求項１〜１５の何れか一項に記載の方法。
  17. 前記低次結果トライの少なくとも部分は、前記高次結果トライの少なくとも部分が評価された後、評価される、請求項１〜１６の何れか一項に記載の方法。
  18. 前記高次結果トライの部分及び前記低次結果トライの部分は、インタリーブ方式で評価される、請求項１〜１７の何れか一項に記載の方法。
  19. 出力として前記低次結果トライの前記表現を提供するステップは、前記低次結果トライを少なくとも部分的に評価するステップが完了する前、実行される、請求項１〜１８の何れか一項に記載の方法。
  20. 前記低次論理演算は、前記高次論理演算と同じ論理演算である、請求項１〜１９の何れか一項に記載の方法。
  21. 前記低次論理演算は、前記高次論理演算と異なる論理演算である、請求項１〜１９の何れか一項に記載の方法。
  22. 前記低次入力トライの少なくとも１つは、更に低次の結合演算子の出力として提供され、前記低次入力トライの少なくとも１つの少なくとも部分は、前記低次結果トライの少なくとも部分を評価するステップ中、評価される、請求項１〜２２の何れか一項に記載の方法。
  23. 入力トライは、前記電子データベース又は情報検索システムに記憶されたキーの集合を記憶し、又は、前記電子データベース又は情報検索システムに記憶されたキーの１つ又は複数の集合から導出された結果キーの集合を記憶する、請求項１〜２２の何れか一項に記載の方法。
  24. トライは１つ又は複数のノードを含み、各子ノードにはキー部分が関連付けられ、前記ルートノードから前記トライ内の別のノードへのパスは、前記ノードに関連付けられるキーを定義し、前記キーは、前記パス上の前記ノードに関連付けられた前記キー部分を連結したものである、請求項１〜２３の何れか一項に記載の方法。
  25. ２つ以上の入力トライの論理演算を使用した結合は、前記入力トライのそれぞれにより記憶されたキーの各集合が前記論理演算を使用して結合される場合、取得されるキーの集合を記憶するトライである、請求項１〜２４の何れか一項に記載の方法。
  26. 論理演算が差である場合、前記結果トライの親ノードは前記第１の入力トライの親ノードであり、前記結果トライの親ノードのリーフは、前記第１の入力トライ内の対応する親ノードの子ノードの集合と他の入力トライ内の任意の対応する親ノードの子ノードの集合との前記論理演算を使用した結合であり、
    論理演算が差ではない場合、前記結果トライ内の各ノードの子ノードの前記集合は、前記入力トライ内の対応するノードの子ノードの前記集合の前記論理演算を使用した前記結合であり、
    異なるトライの前記ノードに関連付けられた前記キーが同一である場合、前記異なるトライの２つ以上のノードは互いに対応する、請求項１〜２５の何れか一項に記載の方法。
  27. 前記結果トライのノードの子ノードの前記集合は、前記論理演算を使用して、前記結果トライの前記ノードに対応する前記入力トライの前記ノードの子ノードの前記集合を結合することにより決定される、請求項１〜２６の何れか一項に記載の方法。
  28. 結果トライ又は結果トライの部分を評価するステップは、
    前記結果トライのルートノードに対して結合関数を実行することを含み、
    前記結果トライの入力ノードに対して前記結合関数を実行することは、
    前記論理演算を使用して、前記結果トライの前記入力ノードに対応する前記入力トライの前記ノードの子ノードの前記集合を結合することにより前記結果トライの前記入力ノードの子ノードの前記集合を決定することと、
    前記結果トライの前記入力ノードに決定された前記子ノードのそれぞれに対して前記結合関数を実行することと、
    を含む、請求項１〜２７の何れか一項に記載の方法。
  29. 結果トライ又は結果トライの部分を評価するステップは、深さ優先探索、幅優先探索、又はそれらの組合せを使用して実行される、請求項１〜２８の何れか一項に記載の方法。
  30. 深さ優先探索において結果トライ又は結果トライの部分を評価するステップを実行することは、前記入力ノードの前記子ノードの１つに対して前記結合関数を実行することと、前記結合関数がその子ノードの次の兄弟ノードに対して実行される前、その子ノードにより形成された前記サブトライをトラバースすることとを含む、請求項２９に記載の方法。
  31. 幅優先探索において結果トライ又は結果トライの部分を評価するステップを実行することは、前記結果トライの前記入力ノードに対して決定された前記子ノードのそれぞれに対して前記結合関数を実行することと、前記結果トライの前記入力ノードの孫ノードの何れかに対して前記結合関数を実行する前、前記結果トライの前記入力ノードに対して決定された前記子ノードのそれぞれの子ノードの集合を決定することとを含む、請求項２９又は３０に記載の方法。
  32. 入力トライにおけるノード、好ましくは入力トライ内の少なくとも全ての親ノードはビットマップを含む、請求項１〜３１の何れか一項に記載の方法。
  33. トライ内の子ノードの前記キー部分の前記値は、ビットが子ノードに関連付けられた前記子ノードの親ノードに含まれる前記ビットマップ内の（設定）ビットの前記値によって決まる、請求項３２に記載の方法。
  34. 前記論理演算を使用して、前記結果トライのノードに対応する前記入力トライの前記ノードの子ノードの前記集合を結合することは、好ましくは、前記論理演算を使用して前記結果トライの前記ノードに対応する前記入力トライの前記ノードのそれぞれの前記ビットマップをビット単位で結合し、それにより、結合ビットマップを取得することを含む、請求項３２又は３３に記載の方法。
  35. 前記結果トライの前記ノードの前記子ノードは、前記結合ビットマップに基づいて、好ましくは前記結合ビットマップのみに基づいて決定及び／又は評価される、請求項３４に記載の方法。
  36. 前記ビットマップを結合するステップは、前記結果トライの前記ノードの前記子ノードが決定及び／又は評価される前、及び／又は前記結果トライの前記評価が前記結果トライの前記ノードの前記子ノードにトラバースする前、実行される、請求項３４又は３５に記載の方法。
  37. 論理演算は論理積、論理和、差分、又は排他的論理和である、請求項１〜３６の何れか一項に記載の方法。
  38. 論理演算を使用することは、ＡＮＤブール演算、ＯＲブール演算、ＡＮＤ ＮＯＴブール演算、又はＸＯＲブール演算を使用することを含む、請求項３７に記載の方法。
  39. 論理演算を使用することは、ビット単位ＡＮＤブール演算、ビット単位ＯＲブール演算、ビット単位ＡＮＤ ＮＯＴブール演算、又はビット単位ＸＯＲブール演算を使用してノードのビットマップを結合することを含む、請求項１〜３８の何れか一項に記載の方法。
  40. 請求項１〜３９の何れか一項に記載の方法を実行する命令を含む、コンピュータプログラム、特にデータベースアプリケーション又は情報検索システムプログラム。
  41. 請求項１〜３９の何れか一項に記載の方法を実行するように構成された、１つ又は複数のプロセッサ及びメモリを含むデータ処理デバイス又はシステム。
  42. 請求項４０のコンピュータプログラムを記憶した好ましくは非一時的コンピュータ可読媒体。
JP2020549557A 2017-03-15 2018-09-19 データベースにおけるトライデータ構造の有効使用 Active JP7364581B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP17161140.3A EP3376407B1 (en) 2017-03-15 2017-03-15 Efficient use of trie data structure in databases
EPPCT/EP2018/056592 2018-03-15
PCT/EP2018/056592 WO2018167235A1 (en) 2017-03-15 2018-03-15 Efficient use of trie data structure in databases
PCT/EP2018/075389 WO2019174761A1 (en) 2017-03-15 2018-09-19 Efficient use of trie data structure in databases

Publications (2)

Publication Number Publication Date
JP2021517306A true JP2021517306A (ja) 2021-07-15
JP7364581B2 JP7364581B2 (ja) 2023-10-18

Family

ID=58347218

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2019547991A Active JP7171592B2 (ja) 2017-03-15 2018-03-15 データベースにおけるトライデータ構造の有効使用
JP2020549557A Active JP7364581B2 (ja) 2017-03-15 2018-09-19 データベースにおけるトライデータ構造の有効使用
JP2019204696A Active JP7198192B2 (ja) 2017-03-15 2019-11-12 データベースにおけるトライデータ構造の有効使用

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2019547991A Active JP7171592B2 (ja) 2017-03-15 2018-03-15 データベースにおけるトライデータ構造の有効使用

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2019204696A Active JP7198192B2 (ja) 2017-03-15 2019-11-12 データベースにおけるトライデータ構造の有効使用

Country Status (5)

Country Link
US (3) US11899667B2 (ja)
EP (3) EP3376407B1 (ja)
JP (3) JP7171592B2 (ja)
CN (2) CN110637291A (ja)
WO (2) WO2018167235A1 (ja)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3627343A1 (en) 2018-09-19 2020-03-25 censhare AG Efficient in-memory multi-version concurrency control for a trie data structure based database
CN110968555B (zh) * 2018-09-30 2023-07-04 北京国双科技有限公司 维度数据处理方法和装置
GB201902772D0 (en) * 2019-03-01 2019-04-17 Palantir Technologies Inc Fuzzy searching 7 applications thereof
US11416661B2 (en) * 2019-08-07 2022-08-16 Synopsys, Inc. Automatic derivation of integrated circuit cell mapping rules in an engineering change order flow
WO2021042081A1 (en) * 2019-08-30 2021-03-04 Mosys, Inc. Graph memory engine
US11416473B2 (en) * 2019-12-20 2022-08-16 Oracle International Corporation Using path encoding method and relational set operations for search and comparison of hierarchial structures
US11822530B2 (en) * 2020-01-22 2023-11-21 Alibaba Group Holding Limited Augmentation to the succinct trie for multi-segment keys
CN112182021B (zh) * 2020-11-03 2022-10-18 浙江大搜车软件技术有限公司 一种用户数据查询方法、装置和系统
CN112528102A (zh) * 2020-12-15 2021-03-19 深圳供电局有限公司 一种基于布尔逻辑判断的规范词条匹配方法
US11714795B2 (en) * 2021-09-23 2023-08-01 Sap Se Partial compression of tree-based index structure
CN114547380B (zh) * 2022-01-25 2022-11-15 北京元年科技股份有限公司 数据遍历查询方法、装置、电子设备及可读存储介质
US20230394021A1 (en) * 2022-06-07 2023-12-07 Oracle International Corporation Computing similarity of tree data structures using metric functions defined on sets
US11847118B1 (en) * 2022-06-22 2023-12-19 Microsoft Technology Licensing, Llc Query set optimization in a data analytics pipeline
CN116383454B (zh) * 2023-04-10 2024-01-30 星环信息科技(上海)股份有限公司 图数据库的数据查询方法、电子设备及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012049883A1 (ja) * 2010-10-15 2012-04-19 日本電気株式会社 データ構造、インデックス作成装置、データ検索装置、インデックス作成方法、データ検索方法およびコンピュータ読み取り可能な記録媒体

Family Cites Families (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US656010A (en) * 1900-02-16 1900-08-14 Charles Waller Bowling Churn.
US5528701A (en) * 1994-09-02 1996-06-18 Panasonic Technologies, Inc. Trie based method for indexing handwritten databases
US5787430A (en) * 1994-06-30 1998-07-28 International Business Machines Corporation Variable length data sequence backtracking a trie structure
JP3152868B2 (ja) * 1994-11-16 2001-04-03 富士通株式会社 検索装置および辞書／テキスト検索方法
US6175835B1 (en) 1996-07-26 2001-01-16 Ori Software Development, Ltd. Layered index with a basic unbalanced partitioned index that allows a balanced structure of blocks
US7249149B1 (en) * 1999-08-10 2007-07-24 Washington University Tree bitmap data structures and their use in performing lookup operations
US6560610B1 (en) * 1999-08-10 2003-05-06 Washington University Data structure using a tree bitmap and method for rapid classification of data in a database
GB2368413B (en) 2000-10-27 2002-09-11 3Com Corp Method and apparatus for searching databases employing a trie search structure
US6691124B2 (en) 2001-04-04 2004-02-10 Cypress Semiconductor Corp. Compact data structures for pipelined message forwarding lookups
WO2003060771A1 (en) 2002-01-14 2003-07-24 Jerzy Lewak Identifier vocabulary data access method and system
US6694323B2 (en) 2002-04-25 2004-02-17 Sybase, Inc. System and methodology for providing compact B-Tree
US7162481B2 (en) * 2002-12-06 2007-01-09 Stmicroelectronics, Inc. Method for increasing storage capacity in a multi-bit trie-based hardware storage engine by compressing the representation of single-length prefixes
US7096235B2 (en) * 2003-03-27 2006-08-22 Sand Technology Systems International, Inc. Computer implemented compact 0-complete tree dynamic storage structure and method of processing stored data
US20060015526A1 (en) 2004-07-16 2006-01-19 Juergen Sattler Method and apparatus for supporting context links for application program text
JP4796970B2 (ja) * 2004-11-17 2011-10-19 株式会社ターボデータラボラトリー ツリーデータの検索・集計・ソート方法及びプログラム
US7565380B1 (en) 2005-03-24 2009-07-21 Netlogic Microsystems, Inc. Memory optimized pattern searching
JP4821287B2 (ja) 2005-11-28 2011-11-24 Ｋｄｄｉ株式会社 構造化文書の符号化方法、符号化装置、符号化プログラム、復号装置及び符号化された構造化文書のデータ構造
US7797319B2 (en) * 2006-05-15 2010-09-14 Algebraix Data Corporation Systems and methods for data model mapping
CN101277252A (zh) * 2007-03-30 2008-10-01 迈普（四川）通信技术有限公司 多分支Trie树的遍历方法
US8250171B2 (en) 2007-06-22 2012-08-21 Pioneer Corporation Content delivery apparatus, content delivery method, and content delivery program
CN101499094B (zh) * 2009-03-10 2010-09-29 焦点科技股份有限公司 一种数据压缩存储并检索的方法及系统
US8179898B2 (en) * 2009-06-11 2012-05-15 Alcatel Lucent Packet processing using braided tries
CN103339624A (zh) * 2010-12-14 2013-10-02 加利福尼亚大学董事会 支持地理结构数据的交互式模糊搜索的高效前缀搜索算法
US9158758B2 (en) * 2012-01-09 2015-10-13 Microsoft Technology Licensing, Llc Retrieval of prefix completions by way of walking nodes of a trie data structure
US8868926B2 (en) * 2012-04-06 2014-10-21 Exablox Corporation Cryptographic hash database
JP5871698B2 (ja) * 2012-04-06 2016-03-01 日本電信電話株式会社 情報蓄積検索装置
US8923298B2 (en) * 2012-05-04 2014-12-30 Futurewei Technoligies, Inc. Optimized trie-based address lookup
US9098601B2 (en) * 2012-06-27 2015-08-04 Futurewei Technologies, Inc. Ternary content-addressable memory assisted packet classification
US8732207B2 (en) * 2012-07-02 2014-05-20 International Business Machines Corporation Attribute-based linked tries for rule evaluation
US8612402B1 (en) * 2012-10-26 2013-12-17 Stec, Inc. Systems and methods for managing key-value stores
EP2804114A1 (en) * 2013-05-16 2014-11-19 Fujitsu Limited Database controller, method, and program for managing a distributed data store
US20160196303A1 (en) 2013-08-21 2016-07-07 Nec Solution Innovators, Ltd. String search device, string search method, and string search program
US9529835B2 (en) 2014-02-28 2016-12-27 Red Hat Israel, Ltd. Online compression for limited sequence length radix tree
US10176605B2 (en) * 2014-03-26 2019-01-08 Brigham Young University Dynamic display of heirarchal data
CN106716412B (zh) 2014-09-25 2020-08-14 甲骨文国际公司 用于支持分布式计算环境中的零拷贝二进制基数树的系统和方法
US20160103858A1 (en) * 2014-10-13 2016-04-14 Freescale Semiconductor, Inc. Data management system comprising a trie data structure, integrated circuits and methods therefor
US10146806B2 (en) * 2015-02-12 2018-12-04 Oracle International Corporation Adaptive resolution hsitogram
WO2016144367A1 (en) * 2015-03-12 2016-09-15 Hewlett Packard Enterprise Development Lp Database records associated with a trie
US10565230B2 (en) * 2015-07-31 2020-02-18 Netapp, Inc. Technique for preserving efficiency for replication between clusters of a network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012049883A1 (ja) * 2010-10-15 2012-04-19 日本電気株式会社 データ構造、インデックス作成装置、データ検索装置、インデックス作成方法、データ検索方法およびコンピュータ読み取り可能な記録媒体

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
XIAOYAN ZHAO: "Trie Methods for Structured Data on Secondary Storage", , JPN7021005623, October 2000 (2000-10-01), CA, ISSN: 0004850623 *

Also Published As

Publication number Publication date
WO2019174761A9 (en) 2021-02-04
EP3376407B1 (en) 2020-09-16
JP2020098583A (ja) 2020-06-25
JP7198192B2 (ja) 2022-12-28
WO2019174761A1 (en) 2019-09-19
EP3596629A1 (en) 2020-01-22
US20190317940A1 (en) 2019-10-17
JP7171592B2 (ja) 2022-11-15
US11275740B2 (en) 2022-03-15
JP2020514894A (ja) 2020-05-21
EP3765969A1 (en) 2021-01-20
US20190324960A1 (en) 2019-10-24
US11347741B2 (en) 2022-05-31
WO2018167235A1 (en) 2018-09-20
US20210049141A1 (en) 2021-02-18
EP3376407A1 (en) 2018-09-19
US11899667B2 (en) 2024-02-13
CN112219199A (zh) 2021-01-12
CN110637291A (zh) 2019-12-31
JP7364581B2 (ja) 2023-10-18

Similar Documents

Publication Publication Date Title
JP2021517306A (ja) データベースにおけるトライデータ構造の有効使用
Lu et al. Multi-model databases: a new journey to handle the variety of data
Sidirourgos et al. Column imprints: a secondary index structure
CA3003756C (en) Storing and retrieving data of a data cube
US7774346B2 (en) Indexes that are based on bitmap values and that use summary bitmap values
US9390115B2 (en) Tables with unlimited number of sparse columns and techniques for an efficient implementation
US11294816B2 (en) Evaluating SQL expressions on dictionary encoded vectors
Perego et al. Compressed indexes for fast search of semantic data
Chien et al. Geometric BWT: compressed text indexing via sparse suffixes and range searching
Srivastava et al. TBSAM: An access method for efficient processing of statistical queries
Wang et al. Rencoder: A space-time efficient range filter with local encoder
US11327995B2 (en) Complex data type encoding within columnar database
Gupta et al. Performance comparison of property map and bitmap indexing
US11868331B1 (en) Systems and methods for aligning big data tables in linear time
Jing-hua et al. OLAP aggregation based on dimension-oriented storage
Li et al. A labeling scheme for dynamic XML trees based on history-offset encoding
Raigoza et al. Temporal join processing with hilbert curve space mapping
Xia et al. Research on storage and query of massive multidimensional data
Bast Efficient and Effective Search on Wikidata Using the QLever Engine
Yeh et al. Indexing XML Objects with Ordered Schema Trees.
Zhang et al. Query optimization with value path materialization in column-stored DWMS
Wang et al. Group-Scope query and its access method
Kapopoulos et al. Efficient Management of Persistent Knowledge
Minter et al. Querying Objects with Criteria
WO2015026949A1 (en) Thin database indexing

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20201106

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20211126

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20211222

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220322

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20220817

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20221219

C116 Written invitation by the chief administrative judge to file amendments

Free format text: JAPANESE INTERMEDIATE CODE: C116

Effective date: 20230105

C22 Notice of designation (change) of administrative judge

Free format text: JAPANESE INTERMEDIATE CODE: C22

Effective date: 20230105

C22 Notice of designation (change) of administrative judge

Free format text: JAPANESE INTERMEDIATE CODE: C22

Effective date: 20230228

C22 Notice of designation (change) of administrative judge

Free format text: JAPANESE INTERMEDIATE CODE: C22

Effective date: 20230406

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230817

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20231005

R150 Certificate of patent or registration of utility model

Ref document number: 7364581

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150