JP7105982B2 - 構造化レコード取得 - Google Patents

Description

関連出願の相互参照
本願は、２０１８年７月２５日に出願された米国仮出願第６２／７０２，９９２号の利益を主張するものであり、この出願を、参照により本明細書に組み込む。

この説明は、構造化レコードの取得に関し、より具体的には、任意選択部分の階層構造を備えたレコードのインデックス化、及びインデックス化に基づくこのようなレコードの取得に関する。

いくつかの用途では、レコードは、送信又は保存のための簡潔な形式を提供するということを契機にしてフォーマットされる。いくつかの例において、このようなメッセージのための規格は何年も前に確立されており、業界の慣行に定着している。このような簡潔な形式の一例が、行政、商業及び輸送のための電子データ交換（ＥＤＩＦＡＣＴ，Electronic Data Interchange for Administration, Commerce and Transport）によって定義されており、その構文は国際規格ＩＳＯ９７３５（１９８８）において定義されている。この規格の使用が定着している業界の一例が航空業界であり、ここでは予約関連データの送信及び保存にＥＤＩＦＡＣＴ構文を用いている。

各ＥＤＩＦＡＣＴレコードは「メッセージ」と呼ばれる。メッセージは、一般に、メッセージの定義された部分内の順番付けられたセグメントの集まりで作成される。いくつかのセグメントを、メッセージの１より多くの部分において用いることができる。各部分において用いることができる（条件）又は用いねばならない（必須）セグメント、及びセグメントの許可された繰り返しの数は、特定の用途用に定義されている。いくつかの用途において、セグメントの集まりがグループとして繰り返し、グループと呼ばれる。セグメント及び／又はグループはネストすることができる。各セグメントには名前が付けられる（ＥＤＩＦＡＣＴセグメント名は３文字の英数字である）。各セグメントは１又は２以上の要素を有し、これは単一の値を備えた単純要素であってもよく、又はこれは複合要素であってもよい。複合要素は、２又は３以上の区切られた値からなる。セグメント内及び複合体内の要素は明示的に区切られ（例えば、別個の区切られた文字（例えば、「＋」及び「：」で）、各セグメントは明示的に終了する（例えば、終端文字「´」で）。

データベースシステムにはデータが表形式で保存されることが多く、各行が１つのレコードに対応し、各列が個別のフィールドに関連付けられ、これはこのフィールドがレコードにおいて任意選択であれば空となり得る。多くの可能であるが任意選択のフィールドがあれば、レコードの列の多くが空（例えば、Null）となり得る。効率的なインデックス化アプローチ、例えば、表の列における値に基づいて条件（例えば、クエリ）を満たすレコードの取得を可能にする１又は２以上の列についてインデックスを形成することが、このようなデータベースシステムに利用可能である。

全般的な態様において、構造化レコード取得に対するアプローチにより、レコードを表形式で解釈及び保存することを必要とすることなく、本来の簡潔なフォーマットでレコードを送信及び保存することが可能になる。表形式（例えば、「フラット」又はリレーショナルデータベース）でのレコードのこのような保存により、２倍のスペースが必要とされるかもしれず、より一般的には、多くの任意選択要素がある用途において実質的により多くのスペースが必要とされる。いくつかの実施形態において、各メッセージは、メッセージ構造の仕様に従って（例えば、メッセージについての「文法」に従って）解析される構造化レコードを含み、解析中、その構造における事前定義された位置におけるフィールド値が抽出され、レコード識別子を（位置，値）ペアに関連付けるインデックス構造に追加される。いくつかの例において、各（位置，値）ペアは、指定された位置でその値を有するレコードに対応するビットが設定されているビットベクトルに関連付けられたキーとして用いられる。特定の位置において指定された値を備えたレコードの取得は、取得されたビットベクトルを用いて、本来のフォーマットで保存された元のレコードを識別してこれにアクセスする。指定されたフィールドにおける値についてのブーリアンクエリを満たすレコードの取得は、クエリを満たすレコードの識別及びこれへのアクセスの前に、ブーリアンクエリの異なる部分（例えば、用語）に関連付けられたビットベクトルのブーリアン結合を用いることができる。

一態様において、概して、ある方法が、複数の構造化レコード（又はこのような構造化レコードを含むメッセージ）を保存するデータストアにおけるレコードを見つけることを対象としている。データストアに保存されている複数の構造化レコードにアクセスする。アクセスされる複数の構造化レコードの少なくともいくつかのレコードはそれぞれ、それぞれのレコードの複数のセグメントを含み、それぞれのレコードの複数のセグメントの各セグメントは、セグメントのネスト化階層における位置（例えば、コンテキストの場所）を有する。レコードの複数のセグメントの少なくともいくつかのセグメントは、１又は２以上の対応する値に関連付けられている。複数の構造化レコードはインデックス化される。このインデックス化は、複数の構造化レコードのレコードを複数のキーに関連付けるインデックスデータ構造を形成するステップを含む。各キーは、セグメント及びセグメントのネスト化階層におけるそのセグメントの位置に対応する値を含む。インデックスにおける各キーは、キーを関連するレコードに関連付ける対応する指標に関連付けられている。インデックスデータ構造において、複数の構造化レコードの少なくともいくつかの各レコードは、対応する１又は２以上のキーに関連付けられている。第１のレコードを第１のキーに関連付けるステップは、第１のレコードを解析して、第１のレコードの第１のセグメントに対応するとともにセグメントのネスト化階層における第１のセグメントの第１の位置に対応する第１の値を識別するステップと、第１の値及び第１の位置を含む第１のキーに関連付けられたインデックスデータ構造における特定の指標を更新するステップと、を含む。クエリを処理して、インデックスデータ構造を用いてクエリに一致する複数の構造化レコードのレコードを取得する。この処理は、クエリを処理して、少なくとも第１のキーを含む１又は２以上のキーのセットを決定するステップを含む。第１のキーは、第１のクエリ値及び第１のクエリ位置を含む。クエリに一致する複数の構造化レコードのサブセットの指標が決定される。この指標の決定は、第１のキーに基づいてインデックスデータ構造から第１の指標を取得するステップと、第１の指標に基づいて複数の構造化レコードの指標を決定するステップと、を含む。データストアからの複数の構造化レコードのサブセットは、この指標に従って取得される（又は取得されるようにもたらされる）。

いくつかの態様が次の特徴の１又は２以上を含むことができる。

構造化レコードにアクセスするステップは、データストアから構造化レコードを受信するステップを含み、構造化レコードのインデックス化は、インデックス化後にデータストアのコピーを維持することなく実行される。例えば、レコードは、インデックス化及び取得という目的のためにローカルフラット又はリレーショナルデータベースに取り込まなくてもよい。このアプローチの利点は、構造化レコードが受信されたデータストア以外に、インデックス化及び取得という目的のために構造化レコードの永続的又は長期的なコピーを維持する必要がないということである。必要とされるストレージが少なくなり、ローカルコピーとデータストアとの間に不整合を有する可能性が減少し得るため、これは利点となり得る。

構造化レコードにアクセスするステップは、構造化レコードを受信するステップと、構造化レコードを、受信されたレコードのフォーマットで、又は圧縮フォーマットで保存するステップと、を含む。構造化レコードのインデックス化には、データストアの表形式表現を形成することが必要とされない。特徴の利点は、構造化レコードのストレージが、少なくともそれらが受信された形式と同じくらいコンパクトであるということである。

セグメントのネスト化階層は、セグメントの文法を用いて、例えば、句構造化文法及び／又はＢＮＦ文法を用いて表される。

第１のレコードを解析するステップは、この文法を用いて、第１のレコード内のセグメントのネスティングに従って第１の位置を識別するステップを含む。

セグメントのネスト化階層におけるセグメントの各個別の位置は、異なる番号によって表される。

対応するキーに関連付けられた各指標は、そのキーに関連付けられた複数のレコードの１又は２以上のレコードのビットベクトル表現を含む。

複数のキーの各キーについて、ネスト化階層における位置は、ネスト化階層におけるパスとして表される。或いは、ネスト化階層における位置は数値識別子として表される。或いは、ネスト化階層における位置はタプルとして表される。

クエリは、第２のクエリ値及び第２のクエリ位置を含む第２のキーをさらに含み、複数の構造化レコードの指標を決定するステップは、第２のキーに基づいてインデックスデータ構造から第２の指標を取得するステップをさらに含む。複数のレコードのサブセットの指標の決定は、さらに第２の指標に基づく。

クエリは、第１のキーに関連付けられた第１の用語及び第２のキーに関連付けられた第２の用語を含む、用語のブーリアン結合を定義し、複数のレコードのサブセットの決定は、第１の指標と第２の指標のブーリアン結合に基づく（例えば、ビットベクトル指標のビット単位のブーリアン結合として）。

レコードの少なくともいくつかのセグメントは、１より多くの対応する値に関連付けられ、各値がセグメントにおいて異なるオフセットを有し、クエリは、セグメントに関連付けられた複数の値内のオフセットを表すオフセットをさらに含む。

オフセットは、セグメントの成分を識別する。

オフセットは、セグメント内の値をさらに識別する。

オフセットは、セグメントの成分の列挙への数値参照として成分を識別し、オフセットは、成分における値の列挙への数値参照としてセグメント内の値を識別する。

他の一態様において、概して、コンピュータ可読媒体上に非一時的な形式で保存されたソフトウェアが、上記の方法のいずれか１つのすべてのステップをコンピューティングシステムに実行させるための命令を含む。

他の一態様において、概して、クエリに一致するデータストアにおける複数の構造化レコードのレコードを見つけるためのコンピューティングシステムが、上記の方法のいずれか１つのすべてのステップを実行するように構成されている。

さらに他の一態様において、概して、データ構造が、非一時的な機械可読媒体に保存される。このデータ構造は、複数の構造化レコードを保持するデータストアに関連付けられたセグメントのネスト化階層の表現を含み、複数の構造化レコードの少なくともいくつかのレコードはそれぞれ、レコードの複数のセグメントを含む。データ構造は、複数の構造化レコードのレコードを複数のキーに関連付けるインデックスデータ構造をさらに含み、各キーは、セグメント及びデータストアに関連付けられたネスト化階層における位置に対応する値を含み、各キーは、そのキーをキーに関連付けられたレコードに関連付ける対応する指標に関連付けられている。このデータ構造は、データストアからのデータ取得のためのシステムに機能性を付与するために用いることができる。

さらに他の一態様において、概して、コンピュータメモリのためのデータ取得のためのシステムが、セグメントのネスト化階層の表現及びインデックスデータ構造に従って上記メモリを構成するための手段を含む。セグメントのネスト化階層の表現は、複数の構造化レコードを保持するデータストアに関連付けられ、複数の構造化レコードの少なくともいくつかのレコードはそれぞれ、レコードの複数のセグメントを含む。インデックスデータ構造は、複数の構造化レコードのレコードを複数のキーに関連付け、各キーは、セグメント及びデータストアに関連付けられたネスト化階層における位置に対応する値を含み、各キーは、そのキーをキーに関連付けられたレコードに関連付ける対応する指標に関連付けられている。

いくつかの態様が次の利点の１又は２以上を含むことができる。

値の位置的コンテキストに基づくインデックスの形成により、レコードのデータベースを従来の表形式で保存することを必要とすることなく、取得したいレコードの識別に対する時間及びスペースの効率的なアプローチが提供される。表形式への変換なしで、データのコンパクトなストレージが維持される一方、それにもかかわらず、所望のレコードを識別する時間効率の良いクエリの実行が提供される。クエリを処理するために次いで用いられる、インデックスの事前計算は、少なくともいくつかの実施形態において、インデックス構造を再構築する必要なく、レコードがデータストアに追加されると更新することができる。

本発明の他の特徴及び利点が、次の説明から、及び請求項から明らかになるであろう。

保管及び取得システムである。 図１のパーサ／インデクサを示すブロック図である。 メッセージ処理の第１の例示的な一例である。 メッセージ処理の第２の例示的な一例である。 図３及び４のメッセージを処理した後のインデックスストアの図である。 クエリ処理の例示的な一例である。 ＥＤＩＦＡＣＴベースの文法の一部の図である。

図１を参照すると、保存及び取得システム１００がメッセージストア１２０を含み、これはメッセージ１１２（集合的に入力メッセージ１１０）を保存するために用いられる。例えば、メッセージストアは、メッセージ１１２が保持される集中型又は分散型の電子データストレージ機能を含むことができる。各メッセージは構造化レコードを含む。以下の議論において、メッセージストア１２０はデータストアと呼ばれることもあり、これはメッセージに対応する構造レコードを保存する。いくつかの例において、メッセージストアは、データ通信リンクを介して（例えば、コンピュータネットワークを介して）複数のソースからメッセージを受信し、データ処理システムによるアクセスのために各メッセージのコピーを保持する。通常、システム１００の１つの機能は、ユーザ１５０（又は同等に自動化データ処理システム）に、コンテンツベースのクエリを満たすストア１２０におけるあらゆるメッセージを要求して、ユーザのためにストア１２０からのこれらのメッセージを識別してこれらにアクセスし、例えばユーザへの応答としてこれらのメッセージを提供する能力を提供することである。

いかなる特定の用途に限定されることなく、一例において、メッセージ１１２は、ＥＤＩＦＡＣＴメッセージの形式である。ＥＤＩＦＡＣＴ規格（ＩＳＯ９７３５（１９８８））によれば、各メッセージは、これを表すために用いられるバイト又は文字数、並びに各メッセージにおいて表される基本データ要素（例えば、数字、文字、文字列）の数の両方において、可変のサイズを有することができる。データメッセージは、メッセージのセクション内で１より多くの基本データ要素を組み合わせることができる階層構文を有し、これらのセクション自体をネストすることができる。ＥＤＩＦＡＣＴメッセージの特定の文脈において、これらのセクションはセグメントと呼ばれることがあり、基本データ要素は複数の要素の複合体を形成することができ、セグメントの集まりはグループを形成することができ、これはそれ自体がメッセージの階層構造に含まれ得る。

より具体的な用途として、再度この用途に限定されるように意図されることなく、このアプローチは、例えば航空会社の予約処理を含むフライト旅行情報処理に適用される。この文脈において、特定の飛行機で特定の時間に旅行する特定の個人に関連する各旅行は、一般に複数のメッセージに関連しているであろう。例えば、同じ旅行に、予約に関連するメッセージ、食事の要求に関連する他のメッセージ、飛行機の乗客の搭乗に関連する他のメッセージなどがあり得る。旅行情報処理における様々な機能には、個人（例えば、旅行代理店）及び自動化システム（例えば、旅行者に情報アクセスを提供するWebベースのアプリケーション）、並びに定期的にメッセージにアクセスする必要があり得るデータ処理システム（例えば、支払い処理システム、旅行特典プログラムなど）の両方によって、様々なタイプのクエリが必要とされ得る。

図１に戻ると、メッセージ１１２は、ストア１２０にレコード１２２として保存される。これらのレコードは、入力メッセージと同じフォーマットを有するか、或いは、例えば、メッセージの圧縮を通してサイズを減少させることができる、メッセージの直接変換であるフォーマットを有する。いずれの場合も、一般に、レコードの要素（例えば、基本値）は、行及び列の表配置にあるかもしれないため、メッセージ内の固定された場所にはない。

上で紹介したように、入力メッセージは、様々な階層構造を備えた、様々なコンテンツを有することができる。結果として、メッセージの要素が多くの異なるコンテキストにおいて生じる可能性がある。例えば、数百、数千、又はより多くの異なるコンテキストがあり得る。各コンテキストが表の異なる列に関連付けられた表配置が用いられたら、いかなる特定のレコードも比較的小さな数のコンテキストのみからの要素を有するため、表におけるほとんどのエントリが用いられない（すなわち、ヌル又は空）という結果になるだろう。

保存されたレコード１２２のフォーマットにかかわらず、システム１００は、インデックス化ベースのデータアクセス能力を提供する。この能力をサポートするため、システム１００はインデックスストア１４０を含み、これは通常、メッセージストア１２０に保存されたメッセージに関連するインデックス情報を保存する。

このシステムは、データストアのメッセージを、パーサ／インデクサ１３０を用いてインデックス化し、これは、各メッセージ１１２がメッセージストア１２０に到着すると（又はここへの通信パス上で）これをスキャンするか、或いは、各入力メッセージに対応する各レコード１２２がストア１２０に到着した後、これをスキャンし、インデックスストア１４０におけるインデックスデータを更新する。インデックスストア１４０は、それぞれが一意の（位置，値）ペアを表すキー間のマッピング、及びそのキーに一致するメッセージのセットの表現を提供する。

動作中、通常インデックスストア１４０を形成した後、ユーザ１５０がクエリ１５２を提供し、これはルックアップコンポーネント１６０に渡される。ルックアップコンポーネントは、インデックスストア１４０におけるインデックスデータにアクセスして、クエリに一致するレコードの表現（例えば、リスト又はビットベクトル）を決定する。これ又は同等の表現は、レトリーバ１７０に渡され、これは要求１７２をメッセージストア１２０に渡し、かわりにメッセージストアから対応するメッセージ１７４を受信する。レトリーバ１７０はこれらのメッセージをユーザ１５０に、例えば、クエリ１５２を満たすメッセージをメッセージ１１２と同じフォーマットで含む結果１８０として束ねて提供する。或いは、レトリーバは、メッセージが利用可能になると、これらをユーザに送り、又はさらなる他の代替案において、要求されたメッセージをユーザに直接送るようにメッセージストアに指示する。

インデックスストア１４０におけるインデックスデータは、レコードのセット１４２に配置される。各レコードは、要素の「位置」、及びその要素の値（すなわち、値のペア）を含むキーに関連付けられ、メッセージにおける指定された位置において指定された値を有するレコード１２２の場所の表現を有する。要素の位置は、要素のタイプ、並びにシステムが用いられている用途についての可能なメッセージのセット内の特定の階層コンテキストの両方を一意に識別する。例えば、旅行情報処理用途において、いくつかのメッセージは予約に関連するセクションを有する。予約についてのこのようなセクション内で、いくつかの予約は乗客に関連するセクションを有し、いくつかの予約は旅行代理店に関連するセクションを有することがある。乗客についてのセクションは住所についてのセクションを含むことがあり、これは次には、番地と通りについてのセクション、例えば「1 Main Street」を含むことがある。旅行代理店についてのセクションは住所についてのセクションを含むことがあり、これも番地と通りについてのセクション、例えば、「1 Commercial Way」を含むことがある。この簡略化された例において、住所セクションの構造は、それが乗客セクションの一部であるか、又は旅行代理店セクションの一部であるかに関係なく同じであることがある。しかしながら、予約－乗客－住所のコンテキストにおける住所は、予約－代理店－住所のコンテキストにおける住所とは異なる「位置」を有する。以下で説明するように、クエリすることができる要素のすべての可能なコンテキストには、その用途についての有効なメッセージ構造の仕様から決定される一意の識別子（例えば、整数）が割り当てられる。例えば、予約－乗客－住所のコンテキストについての住所には位置値１５８を割り当てることができる一方、予約－代理店－住所のコンテキストについての住所には位置値２４７を割り当てることができる。これらの値は、様々な方法で、例えば、インデックスエントリが所望されるコンテキストのセットの列挙において順番に、或いは、異なる入力コンテキストについて一意の番号を通常提供する関数を通してコンテキストが整数に変換されるハッシュ関数アプローチに基づいて、割り当てることができる。

レコード１２２の場所の様々なタイプの表現を用いることができる。コンパクトなストレージを提供する１つの実装形態において、表現は、対応する（位置，値）キーに関連するインデックスレコードが、各一致するレコードについて設定された１つのビットを備えたビットベクトルを有し、そのビットがメッセージストアにおけるレコード１２２の場所に関連する位置に設定されているビットベクトルである。例えば、レコード１００３でのメッセージが位置及び値に一致すれば、そのインデックスレコード１４２についてのビットベクトルの１００３番目のビットが設定される。いくつかの実施形態において、ビットベクトルは、例えば、ゼロのランがランの長さの数に圧縮されるランレングスコーディングアプローチで、又は他の一例として、設定されたビットに対応する位置の順序付きリストを用いて圧縮される。いずれの場合も、様々な実施形態において、インデックスストア１４０は、（位置，値）キー（例えば、位置＝１７５，値＝「1 Main St.」）から、識別子１７５が割り当てられた位置（すなわち、コンテキスト）でのレコードにおいてその値が生じるレコードの表現への効率的なマッピングを提供するデータ構造を含む。

図２を参照すると、パーサ／インデクサ１３０（図１で紹介した）の一実装形態が、メッセージのための文法２１２を利用する。概して、この文法は、許容されるメッセージのセットを定義する機能を果たし、特に、メッセージにおいて表されるセグメント、グループ、複合体、及び基本要素の許容されるネスティングのセットを定義する。いくつかの例において、この文法は、メッセージの一部（例えば、非終端部分、名前付きセグメントなど）の変換（例えば、「書き換え」）を非終端記号、セグメント、要素などの可能なシーケンスとして表現することができる句構造化文法として表すことができる。例えば、このような文法は、バッカスナウア形式（ＢＮＦ，Backus-Naur Form）に類似した形式で表現することができる。特定の用途についてのメッセージは、文脈自由及び文脈依存言語を含む、文法の様々な部類内でシーケンスを形成することができる。しかしながら、本明細書に記載のアプローチは、いかなる特定の形式の文法又はメッセージ「言語」に限定されないということが理解されるべきである。

文法の第２の機能は、メッセージの分析（すなわち、解析）における各要素の位置を、すべてのメッセージの可能な解析のスペースにおけるその要素の位置インデックスに関連付けることである。一般に、メッセージの完全な解析は１つしかないため、解析のプロセスは決定論的であり、メッセージにおける各要素は、文法の１つの可能なフレーズコンテキストにのみ関連付けられる。例えば、文法の一部に位置インデックスをタグ付けすることができ、又は位置インデックスを備えた要素のコンテキストに一致する別個の表（例えば、列挙又はハッシュテーブル）があり得る。上で紹介したように、これは、予約メッセージのコンテキストにおける乗客情報のコンテキストにおける番地と通りである要素は、メッセージに他の情報があるかどうかにかかわらず、同じ位置インデックスを有することになり、異なるコンテキストにおけるその同じ要素とは異なる位置インデックスを有することになるということを意味する。

引き続き図２を参照すると、文法２１２は、パーサ２１４が多くの異なる用途についての、例えば、ＥＤＩＦＡＣＴフォーマットを用いる多くの異なる用途についてのメッセージに対して汎用的であり得るという意味で、パーサ２１４に機能性を与えるが、文法２１２は、文法２１２が指定されている用途についてのあらゆる特定のメッセージ１２２を処理するのに必要とされる具体的な機能性を与える。概して、例示的な例の文脈において以下でさらに議論するように、パーサ２１４は、解析ツリー４１６であると見なすことができるものを生成し、これはメッセージの構成要素及びそれらの相互のネスティングを識別し、メッセージの部分（又はその部分の値）は、構成要素のそれぞれ（又は少なくともそれらの中にさらなるネスティングを有さず、したがってメッセージの基本要素である終端構成要素）に対応する。上で紹介したように、構成要素は、これらのグローバルに一意の位置インデックスに関連付けられ、これは、文法２１２でエンコードされている可能性があり、又はメッセージの構成要素のネストされたコンテキストに基づいて解析ツリーが構築された後に決定することができる。後者の場合、インデックス化されるべき各構成要素について、その構成要素のコンテキストは、そのコンテキストを位置インデックスにマップする、文法の表において検索することができる。

パーサ２１４の出力はインデクサ２１８によって処理され、これは、メッセージの一部（例えば、終端要素）の値を、少なくともインデックス化されるべきこれらの部分について、それらの位置インデックス及びメッセージインデックス（例えば、シーケンス番号）と組み合わせてタプル（ｐ，ｖ，ｎ）を形成し、ここでｐは位置インデックス、ｖは構成要素に関連するメッセージの部分の値、ｎはメッセージのインデックスである。インデクサは次いでこのタプルを用いて、例えば、ビットベクトル表現の場合、その（ｐ，ｖ）ペアに関連するビットベクトルにおいてｎ番目のビットを設定することによって、これらの構成要素のそれぞれについてインデックスレコード１４２を更新する。

図３を参照すると、第１の例示的な例において、メッセージ１２２がインデックスｎ＝１００３を有し（例えば、これは受信された１００３番目のメッセージである）、全体的な内容「予約１２３４５，乗客Smith, John, 1 Main St., Boston MA」を有する。この例示はＥＤＩＦＡＣＴフォーマットを用いていないが、そのフォーマットを用いる類似の例も同じ又は同様の処理ステップに従うであろうということが理解されるべきである。この例において、パーサ２１４は、この用途についての文法２１２を用いて、解析ツリー２１６を生成し、これは、図３に示すように例示することができる。すなわち、メッセージの解析は「予約」という最上位の構成要素を有し、これは、基本要素である予約番号、及び乗客情報部分の２つの部分を有する。乗客情報部分は次には名前部分及び住所部分を有し、名前部分は姓部分及び名部分を有し、住所部分は番地と通り部分及び市と州部分を有する。この例示において、各部分はその部分の位置インデックスで（括弧内に）注釈されている。例えば、予約番号は部分インデックス１１７で注釈されており、これは、コンテキストが生じ得る特定のメッセージにかかわらず、最上位の「予約」というコンテキストにおける「番号」に普遍的に割り当てられる。

パーサ２１４の様々な実装形態を用いることができる。例えば、ボトムアップパーサ（例えば、決定論的パーサ、例えばＬＲ（Left-Right）パーサ、又はＣＹＫ（Cocke-Younger-Kasami）パーサのチャート）を用いることができる。

この例示において、インデクサ２１８は（ｐ，ｖ，ｎ）タプルのセット２２０を生じさせる。例えば、予約番号では、タプルは（１１７，１２３４５，１００３）であり、値１２３４５が位置１１７においてメッセージ番号１００３において生じているということを意味している。追加のこのようなタプルを図３に示している。

図４を参照すると、メッセージインデックス１２０５を備えたメッセージ１２２の第２の例示的な例も予約に関連しており、図３に示すメッセージと共通のいくつかの要素を有する。このメッセージにおいて、予約部分は番号要素（この例において、図３と同じ予約番号）を有し、乗客部分ではなくメッセージは代理店部分を有する。パーサ２１４は文法２１２を用いて、メッセージの構成要素の位置インデックスを含む、解析ツリー２１６（又は同等のデータ構造）を形成する。インデクサ２１８は、図３を参照して先に議論したように、解析ツリーを処理して（ｐ，ｖ，ｎ）タプルを形成する。

この例において、予約番号は再度位置１１７にある。すなわち、最上位の予約内の番号についてのコンテキストは、図３のメッセージと同じコンテキストであり、したがって位置番号は同じである。この番号についてのタプルは（１１７，１２３４５，１２０５）である。他方、値が「1 Commercial Way」の、住所の番地と通り部分は、予約内の、代理店部分内の、住所内の、通り部分に対応する位置インデックス２８５にある。これは、予約内の、乗客部分内の、住所内、番地と通り部分に対応する位置１７５にある、図３における番地と通り部分「1 Main St.」とは対照的である。図示のように、インデクサ２１８は（ｐ，ｖ，ｎ）タプルのセットを生じさせる。

図５を参照すると、そして上で紹介したように、インデックスストア１４０は、それぞれが位置と値（ｐ，ｖ）のペアに関連付けられた複数のレコード１４２を含む。（ｐ，ｖ，ｎ）タプルは、インデックスストアがインデクサからタプル（ｐ，ｖ，ｎ）を受信したら、各メッセージ番号ｎについてのビットを１に設定することによってインデックスストア１４０に保存される。図示のように、（１１７，１２３４５）レコード（すなわち、あらゆる予約番号１２３４５について）は、図３及び４に示す例に対応して、少なくともビット１００３及び１２０５が設定されている。同様に、予約セグメントにおける乗客の姓に対応する（１６５，「Smith」）レコードは、ビット１００３が設定されている（図３に対応）が、ビット１２０５が設定されていない（図４に対応、乗客部分がない）。同様に、（２３６，「Acme Travel」）にはビット１２０５が設定されているが、ビット１００３は設定されていない。

上で紹介したように、図２～５に示す手順は、メッセージがメッセージストア１２０に到着したときに実行することができ、又は、例えば、１時間、又は１日などに追加されたすべてのメッセージについて数回に分けて実行することができる。いずれの場合も、いつでも、メッセージストア１２０におけるメッセージのいくつか又はすべてがインデックス化されており、インデックスストア１４０に表されている（それらがインデックス化可能なフィールドを有すれば）。上の議論において、すべての要素がインデックス化されるということに留意されたい。しかしながら、要素のサブセット又は位置のサブセットのみにインデックス化を制限することが好ましいことがある。例えば、おそらく予約番号はインデックス化されるが、番地と通りはされない。このような選択は、番地と通りを伴うクエリの効率を制限する可能性があるが、このような選択は、適切なスペースと時間のトレードオフを提供することができる。インデックスを用いて特定の番地と通り（例えば、「1 Main St.」)を検索することに対する代替案として、メッセージストアにおける各レコード１２２を解析して、番地と通りにおける所望の値を有するレコードを見つけることがある。

図６を参照すると、単一の位置（特定のコンテキストにおける要素）の値に基づくクエリプロセスの一例において、ユーザ１５０が、例えば、予約番号１２３４５についてのすべてのメッセージについてのクエリを発行する。ルックアップコンポーネント１６０は、インデックスストア１４０にアクセスして、このようなクエリに一致するメッセージレコード１２２を識別する。こうするため、番号要素の位置がまず決定され、この場合、予約のコンテキストにおける番号を位置１１７にマッピングする。このようなマッピングを行うため、ルックアップ１６０は、パーサ／インデクサ１２０の文法２１２と一致するデータへのアクセスを有する（例えば、パーサによって用いられる同じデータへの、又は異なるが整合しているデータ構造への直接アクセスによって）。対象の位置と値（ｐ，ｖ）のペアが（１１７，１２３４５）であると決定すると、ルックアップは、ビット１００３及び１２０５が設定されている、対応するビットベクトル１６２にアクセスする。このビットベクトル（又は同等の情報を備えたデータ構造）は、レトリーバ１７０に送られ、これは、メッセージストア１２０からレコード１００３及び１２０５を要求し、それらの対応するレコードを受信して、それらをユーザのための応答１８０にまとめる。

図６に示していないのは、より複雑なブーリアンクエリについての場合である。このようなブーリアンクエリでは、ルックアップは、クエリの各用語についてのビットベクトルにアクセスし、次いでビット単位のブーリアン演算を実行して、そのブーリアンクエリを満たすメッセージに対応する結合ビットベクトルを生成する。

いくつかの実装形態において、クエリプロセスは並列化することができる。例えば、ブーリアンクエリの場合、クエリにおける異なる用語についてのレコード１４２に並行してアクセスすることができる。これは、レコード１４２を、例えば位置に基づいて別個のデータセクションに分割することによってより効率的にすることができ、これによって並列ルックアップのためのデータ競合を回避する。並列処理についての他の選択肢は、インデックスストアからのビットベクトルの通信、又はブーリアン式に従ったビットの組み合わせを、メッセージストアからのレコードの要求とパイプライン処理することにある。例えば、ボトルネックがメッセージストア１２０自体へのアクセスである限り、このようなパイプライン処理は、可能な最高の全体的な検索速度を提供することができる。

上の議論では、ＥＤＩＦＡＣＴメッセージ構造の詳細への言及が制限されている。上に提供したＥＤＩＦＡＣＴメッセージフォーマットの説明に基づいて、ＥＤＩＦＡＣＴセグメント、グループ、及び複合体が解析ツリー内の構成要素（すなわち、文法の非終端記号）の役割を果たすことができる一方、基本要素は解析ツリーのリーフ（すなわち、文法の終端記号）を形成することができ、位置インデックスが割り当てられる。他の代替案において、複合体にも位置インデックスが割り当てられ、位置インデックスは、その複合体についての解析ツリーにおける位置、及びその複合体内の要素（例えば、位置１３７での複合体の第２の要素）のインデックスからなるペアとして表される。

ＥＤＩＦＡＣＴ構造化レコードは、図３～４の例示的な例よりいくらか複雑である。特に、メッセージにおける基本要素は、一般にＥＤＩＦＡＣＴセグメントの特定のネスティング内で発見され、そのセグメント内で、そのセグメント内の要素の特定の順序位置で、その位置が複合要素であれば、その複合要素内の基本要素の特定の順序位置で発見される。図３～４の例のように、「位置」を単一の列挙された（例えば、整数の）量として表すのではなく、ＥＤＩＦＡＣＴ固有の実装形態において、位置自体はタプルｐ＝（ｓｐ，ｅｐ，ｂｐ）として表され、ここでｓｐはアプリケーションドメインの可能なメッセージにおけるセグメントの各可能なネスティングについて別個の列挙量であり、ｅｐは基本又は複合要素のインデックスである（例えば、０が第１の要素、１が第２の要素などとなるようなゼロ原点など）。要素がセグメントにおけるインデックスｅｐで複合要素を備えていれば、ｂｐはその複合要素内の要素のインデックスである。要素が複合要素内になければ、その要素はセグメントにおけるインデックスｅｐで基本要素であり、ｂｐは任意に０に設定される。

重要なのは、基本要素の各可能なコンテキストが位置の個別の値を有するということであるが、位置がスカラー量である基本的必要性はないため、先の例における簡単な整数位置ｐをｐ＝（ｓｐ，ｅｐ，ｂｐ）のタプル表現に置き換えても、上述のアプローチは変更されないということに留意されたい。このＥＤＩＦＡＣＴ固有の実装形態の他の一態様は、セグメントのコンテキストのみが列挙される一方、セグメントのグループは要素に直接接触しないため、セグメントのグループのコンテキストには割り当てられないということである。

ここで図７を参照すると、特定のＥＤＩＦＡＣＴ用途における文法の例示的な一例が、セグメントの可能なネスティング、及びそれらの基本及び複合要素のリストとして表されている。図７の文法は、この用途における有効なメッセージに存在し得るすべての要素を描いているが、図３～４の例は特定のメッセージであるということに留意されたい。図７に示す文法は、ルートノードがセグメントの「予約」グループについてのものであるツリー表現である。セグメントの「予約」グループは、セグメントの「乗客」グループ又はセグメントの「代理店」グループ、又は両方、並びに、文法の小さな部分のみを示している図７に示されていない他のセグメントのグループ又はセグメントを含む（すなわち、その中に直接ネストされる）ことができる。セグメントの「乗客」グループは、「名前」セグメント（「ＴＩＦ」という名前）及び／又は「住所」セグメント（「ＡＤＲ」という名前）を含むことができる。「予約」グループ内の「乗客」グループ内の「名前」セグメントにはセグメント位置ｓｐ＝１が割り当てられる一方、「予約」グループ内の「乗客」グループ内の「住所」セグメントにはセグメント位置ｓｐ＝２が割り当てられる。

「名前」セグメントは、「名前」セグメントにおけるインデックスｅｐ＝０で「旅行者の姓及び関連情報」成分（component）を有する。この成分は、インデックスｂｐ＝０で「姓」要素を有する。したがって、「予約」グループ内の「乗客」グループ内の「名前」セグメント内の「旅行者の姓及び関連情報」成分内の「姓」要素としての「Smith」のような名前は、ｐ＝（ｓｐ，ｅｐ，ｂｐ）＝（１，０，０）の文法内に「位置」を有する。したがって、「Smith」という「名前」がメッセージ番号１００３に生じれば、インデクサは（（１，０，０），「Smith」，１００３）の形式のレコードを生成し、（（１，０，０），「Smith」）（又は同等に（１，０，０，「Smith」））によってアクセスされるインデックスレコードは、１００３番目のビットが設定されている。

同様の方法で、「住所成分記述」要素がインデックス１及び「住所詳細」成分にあり、これは「予約」グループにおける「乗客」グループにおける「住所」セグメントにおける第２の要素（インデックス１）であり、したがって位置ｐ＝（２，１，１）を有する。また同じ方法で、「住所成分記述」要素がインデックス１及び「住所詳細」成分にあり、これは「予約」グループにおける「代理店」グループにおける「住所」セグメントにおける第２の要素（インデックス１）であり、したがって、「予約」グループにおける「代理店」グループにおける「住所」セグメントはセグメントコンテキストｓｐ＝３を有するため、位置ｐ＝（３，１，１）を有する。

図７に示す文法の部分には３つのみのセグメントコンテキストが例示されているが、ＥＤＩＦＡＣＴレコード構造を備えたこの例の用途において、生じ得る異なるセグメントコンテキストは１０，０００を超えており、したがって図７は全体的な文法の非常に小さな部分である。

インデックスストア１４０について上述したインデックス構造は一実施例に過ぎないということが認識されるべきである。（ｐ，ｖ）アドレス指定ビットベクトルではなく、他の構造、例えば、平衡ツリーを用いることもできる。インデックス構造の特定の選択は、例えば、クエリ処理のための可能な並列処理及びパイプライン処理を含むクエリの処理のために配置されているインフラストラクチャに部分的に依存する。例えば、並列グラフベースの処理インフラストラクチャ（例えば、分散型データフローコンピューティングアーキテクチャを用いる）の文脈において、レコード及びビットベクトルストレージへの（ｐ，ｖ）アクセスは、位置のハッシュによる並列化、及びビットベクトル表現に示されるレコードの処理のパイプライン化に特に補正可能であり得る。他方、シングルプロセッサ（すなわち、シリアル処理）の場合では、各位置についての平衡ツリーのような代替構造が最も効果的であり得る。

上述のアプローチは、例えば、適切なソフトウェア命令を実行するプログラム可能なコンピューティングシステムを用いて実装することができ、又はこれはフィールドプログラマブルゲートアレイ（ＦＰＧＡ，field-programmable gate array）のような適切なハードウェア又は何らかのハイブリッド形式で実装することができる。例えば、プログラムされたアプローチにおいて、ソフトウェアは、それぞれが少なくとも１つのプロセッサ、少なくとも１つのデータストレージシステム（揮発性及び／又は不揮発性メモリ及び／又はストレージ要素を含む）、少なくとも１つのユーザインターフェース（少なくとも１つの入力デバイス又はポートを用いて入力を受信し、少なくとも１つの出力デバイス又はポートを用いて出力を提供するための）を含む、１又は２以上のプログラムされた又はプログラム可能なコンピューティングシステム（これは、分散型、クライアント／サーバ、又はグリッドのような様々なアーキテクチャのものであり得る）上で実行される１又は２以上のコンピュータプログラムにおける手順を含むことができる。ソフトウェアは、例えば、データフローグラフの設計、構成、及び実行に関連するサービスを提供する、より大きなプログラムの１又は２以上のモジュールを含むことができる。プログラムのモジュール（例えば、データフローグラフの要素）は、データリポジトリに保存されているデータモデルに準拠するデータ構造又は他の組織的なデータとして実装することができる。

ソフトウェアは、媒体の物理的特性（例えば、表面のピット及びランド、磁区、又は電荷）を用いて、揮発性又は不揮発性の記憶媒体、又は任意の他の非一時的な媒体に組み込まれているような、非一時的な形式で一定期間（例えば、ダイナミックＲＡＭのようなダイナミックメモリデバイスのリフレッシュ期間間の時間）保存することができる。命令をロードするための準備において、ソフトウェアは、ＣＤ－ＲＯＭ又は他のコンピュータ可読媒体（例えば、汎用又は専用のコンピューティングシステム又はデバイスによって可読な）のような有形の非一時的な媒体上に提供することができ、又はネットワークの通信媒体を介して、それが実行されるコンピューティングシステムの有形の非一時的な媒体に配信する（例えば、伝搬された信号にエンコードする）ことができる。処理の一部又はすべては、専用コンピュータで、又はコプロセッサ若しくはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）又は専用の特定用途向け集積回路（ＡＳＩＣ，application-specific integrated circuits）のような専用ハードウェアを用いて実行することができる。処理は、ソフトウェアによって指定された計算の異なる部分が異なる計算要素によって実行される分散方式で実施することができる。それぞれのこのようなコンピュータプログラムは好ましくは、本明細書に記載の処理を実行するためにストレージデバイス媒体がコンピュータによって読み取られるときにコンピュータを構成して動作させるため、汎用又は専用のプログラム可能なコンピュータによってアクセス可能なストレージデバイスのコンピュータ可読記憶媒体（例えば、固体メモリ若しくは媒体、又は磁気若しくは光学媒体）に保存又はダウンロードされる。本発明のシステムはまた、コンピュータプログラムで構成された有形の非一時的媒体として実装されると見なすことができ、このように構成された媒体は、コンピュータを特定の事前定義された方法で動作させて、本明細書に記載の処理ステップの１又は２以上を実行させる。

命令は、機械語命令、仮想機械命令、高水準プログラミング命令、及び／又はコンパイル若しくは解釈された命令を含む、異なるレベルにあってもよい。いくつかの実装形態において、機能の一部を完全に又は部分的に専用ハードウェアに実装することができる。例えば、図２に示す様々なキューは専用のハードウェアを有することができ、これは実施されているキューイングアプローチの効率を増加させる、又は待ち時間を減少させることができる。いくつかの実装形態は、ソフトウェアと専用ハードウェアコンポーネントの組み合わせを用いる。

本発明のいくつかの実施形態を説明してきた。それにもかかわらず、前述の説明は、次の特許請求の範囲によって定義される、本発明の範囲を説明するものであり、これを限定するように意図されていないということが理解されるべきである。したがって、他の実施形態も次の特許請求の範囲内にある。例えば、本発明の範囲から逸脱することなく様々な修正を行うことができる。加えて、上述のステップのいくつかは順序に依存しないことがあり、したがって記載のものとは異なる順序で実行することができる。

Claims (17)

1. 複数の構造化レコードを保存するデータストアにおけるレコードを見つけるための、ソフトウェア命令及びデータレコードを保存するために少なくとも１つのストレージデバイスに接続された少なくとも１つのプロセッサを備えるプログラム可能なコンピューティングシステムで実行される方法であって、
   前記ソフトウェア命令を実行する前記プログラム可能なコンピューティングシステムによって、前記データストアに保存されている前記複数の構造化レコードにアクセスするステップであって、前記複数の構造化レコードの少なくともいくつかのレコードがそれぞれ、それぞれのレコードの複数のセグメントを含み、それぞれのレコードの前記複数のセグメントの各セグメントが、セグメントのネスト化階層における位置を有し、それぞれのレコードの前記複数のセグメントの少なくともいくつかのセグメントが、１又は２以上の対応する値に関連付けられている、前記複数の構造化レコードにアクセスするステップと、
   前記ソフトウェア命令を実行する前記プログラム可能なコンピューティングシステムによって、前記複数の構造化レコードをインデックス化するステップであって、
   前記ソフトウェア命令を実行する前記プログラム可能なコンピューティングシステムによって、インデックスデータ構造を形成するステップであって、前記インデックスデータ構造が、前記複数の構造化レコードのレコードを複数のキーに関連付け、各キーが、セグメント及びセグメントの前記ネスト化階層における前記セグメントの位置に対応する値を含み、各キーが、前記キーを関連するレコードに関連付ける対応する指標に関連付けられている、前記インデックスデータ構造を形成するステップと、
   前記インデックスデータ構造において、前記ソフトウェア命令を実行する前記プログラム可能なコンピューティングシステムによって、前記複数の構造化レコードの少なくともいくつかの各レコードを対応する１又は２以上のキーに関連付けるステップであって、第１のレコードを第１のキーに関連付けるステップが、前記第１のレコードを解析して、前記第１のレコードの第１のセグメントに対応するとともにセグメントの前記ネスト化階層における前記第１のセグメントの第１の位置に対応する第１の値を識別するステップと、前記第１の値及び前記第１の位置を含む前記第１のキーに関連付けられた前記インデックスデータ構造における特定の指標を更新して、前記第１のレコードを識別するステップと、を含む、前記複数の構造化レコードの少なくともいくつかの各レコードを対応する１又は２以上のキーに関連付けるステップと、
   を含む、前記複数の構造化レコードをインデックス化するステップと、
   前記ソフトウェア命令を実行する前記プログラム可能なコンピューティングシステムによって、クエリを処理して、前記インデックスデータ構造を用いて前記クエリに一致する前記複数の構造化レコードのレコードを取得するステップであって、
   第１のクエリ位置及び第１のクエリ値を表す少なくとも第１のキーを含む１又は２以上のキーのセットを決定するステップを含む、前記ソフトウェア命令を実行する前記プログラム可能なコンピューティングシステムによって、前記クエリを処理するステップと、
   前記ソフトウェア命令を実行する前記プログラム可能なコンピューティングシステムによって、前記クエリに一致する前記複数の構造化レコードの指標を決定するステップであって、前記第１のキーに基づいて前記インデックスデータ構造から第１の指標を取得するステップと、前記第１の指標に基づいて前記複数の構造化レコードの前記指標を決定するステップと、を含む、前記複数の構造化レコードの指標を決定するステップと、
   前記ソフトウェア命令を実行する前記プログラム可能なコンピューティングシステムによって、前記指標に従って前記データストアから前記複数の構造化レコードのサブセットを取得するステップと
   を含む、前記複数の構造化レコードのレコードを取得するステップと
   を含む、前記方法。
2. 前記構造化レコードにアクセスするステップが、前記データストアから前記構造化レコードを受信するステップを含み、
   前記構造化レコードをインデックス化するステップが、インデックス化後に前記データストアのコピーを維持することなく実行される、請求項１に記載の方法。
3. 前記構造化レコードにアクセスするステップが、
   前記構造化レコードを受信するステップと、
   前記構造化レコードを、受信されたレコードのフォーマットで、又は圧縮フォーマットで、前記データストアに保存するステップと
   を含み、
   前記構造化レコードの前記インデックス化は、前記データストアの表形式表現を形成することを必要としない、請求項１に記載の方法。
4. セグメントの前記ネスト化階層が、セグメントの文法を用いて表され、
   前記第１のレコードを解析するステップが、前記文法を用いて、前記第１のレコード内のセグメントのネスティングに従って前記第１の位置を識別するステップを含む、請求項１～３のいずれかに記載の方法。
5. セグメントのネスト化階層におけるセグメントの各個別の位置が、異なる番号によって表される、請求項１～４のいずれかに記載の方法。
6. 各指標が、対応するキーに関連付けられ、前記キーに関連付けられた前記複数のレコードの１又は２以上のレコードのビットベクトル表現を含む、請求項１～５のいずれかに記載の方法。
7. 前記複数のキーの各キーについて、前記ネスト化階層における位置が、前記ネスト化階層におけるパスとして表される、請求項１～６のいずれかに記載の方法。
8. 前記複数のキーの各キーについて、前記ネスト化階層における位置が数値識別子として表される、請求項１～６のいずれかに記載の方法。
9. １又は２以上のキーの前記セットが、第２のクエリ値及び第２のクエリ位置を含む第２のキーを含み、
   前記複数の構造化レコードの前記指標を決定するステップが、前記第２のキーに基づいて前記インデックスデータ構造から第２の指標を取得するステップをさらに含み、
   前記複数のレコードの前記サブセットの前記指標を決定するステップがさらに前記第２の指標に基づく、請求項１～８のいずれかに記載の方法。
10. 前記クエリが、前記第１のキーに関連付けられた第１の用語及び前記第２のキーに関連付けられた第２の用語を含む、用語のブーリアン結合を定義し、
    前記複数のレコードの前記サブセットの前記指標を決定するステップが、前記第１の指標と前記第２の指標のブーリアン結合に基づく、請求項９に記載の方法。
11. レコードの少なくともいくつかのセグメントが、１より多くの対応する値に関連付けられ、各値がセグメントにおいて異なるオフセットを有し、前記クエリが、セグメントに関連付けられた複数の値内のオフセットを表すオフセットをさらに含む、請求項１～１０のいずれかに記載の方法。
12. 前記オフセットが前記セグメントの成分を識別する、請求項１１に記載の方法。
13. 前記オフセットが前記セグメント内の値をさらに識別する、請求項１２に記載の方法。
14. 前記オフセットが、前記セグメントの成分の列挙への数値参照として前記成分を識別し、前記オフセットが、前記成分における値の列挙への数値参照として前記セグメント内の前記値を識別する、請求項１３に記載の方法。
15. 前記構造化レコードが、許容されるレコードのセット及びセグメントの前記ネスト化階層を定義する仕様に準拠し、
    前記仕様が、事前定義されたセグメントのネスト化階層における、個別のネスト化コンテキストのそれぞれの識別子を含み；かつ
    前記クエリを処理するステップが、
    クエリセグメント、及びセグメントの前記ネスト化階層の他のセグメント内の前記クエリセグメントのネスティングを指定する第１のクエリコンテキストを識別する少なくとも前記第１のキーを含み、かつ第１のクエリ値を含む、前記１又は２以上のキーのセットを決定することを含む、前記クエリを処理することを含む、請求項１に記載の方法。
16. コンピュータ可読媒体上に非一時的な形式で保存されたソフトウェアであって、請求項１～１５のいずれかのすべてのステップをコンピューティングシステムに実行させるための命令を含む、ソフトウェア。
17. クエリに一致するデータストアにおける複数の構造化レコードのレコードを見つけるためのコンピューティングシステムであって、請求項１～１５のいずれかのすべてのステップを実行するように構成されている、コンピューティングシステム。

Images