JP5687219B2 - データ検索システム、データ検索方法及びデータ検索プログラム - Google Patents

Description

本発明は、データを検索する技術に関する。

現在、インターネット等の通信ネットワークを経由して映像や音声等のコンテンツを提供するＶＯＤ（Video On Demand）サービスが拡大している。ＶＯＤサービスでは、登録している大量のコンテンツを管理する手法として、各コンテンツのメタデータを予め作成しておき、それを利用してユーザからの要望に応じたコンテンツを検索する方法が採用されている。

メタデータとは、コンテンツに関する属性データ（例えば、コンテンツの作成日時、コンテンツのデータ形式、コンテンツのタイトル、コンテンツの概要、コンテンツの価格、その購入ＩＤ等）を項目化して集約したデータである。ＸＭＬ（Extensible Markup Language）等で記載された構造化データの形式を有し、テキストドキュメントとしてデータベース内に記憶・管理されている。

このようなメタデータは、デジタル情報の管理手段として有望視されており、今後も多くのメタデータが作成され、利用されることが期待されている。

ここで、メタデータ内に記載された多くの項目は、データベース上で高速検索され、所期される情報が適時に取り出されることが必要であることから、そのための様々な技術が考えられている。

〔メタデータのインデックス構築〕
特許文献１によれば、メタデータ内の構造化データの各項目に対して、インデックスを構築してインデックステーブルを生成すると共に、各項目において頻出する値をその項目名とペアで１つの要素として集合インデックスを構築しておく技術が開示されている。

そのようなインデックスを利用しない場合、データベースに記憶されている全てのメタデータを検索する必要があるため非効率となる。一方、インデックスを利用する場合、インデックステーブル上のインデックスを読み取り、検索条件に一致したメタデータの格納位置情報を読み取ってメタデータにアクセスするため、検索効率を向上させることができる。

また、現在インデックスとして広く使われているものに、Ｂツリーインデックスがある。このＢツリーインデックスは、ルートノード、ブランチノード、リーフノードに分かれた多段インデックスの木構造で構成され、メタデータを探索するために必要となるインデックスの段数はどのメタデータでも同じであるため、どのようなキー値を持つインデックスであっても一定時間で探索することができる。

〔データのオンメモリ化技術〕
非特許文献１によれば、構造化データ内における複数のデータ項目を纏めたテーブルを主記憶装置であるメモリに格納し（オンメモリ化）、高速にコンテンツを検索する技術が開示されている。

特開２０１０−２６７０８０号公報

「IN-MEMORY DATABASE」、ORACLE TIMESTEN、［online］、［平成24年1月13日検索］、＜URL: http://www.oracle.com/technetwork/database/timesten/overview/ds-timesten-imdb-129255.pdf?ssSourceSiteId=ocomjp＞ 「Oracle TimesTen In-Memory Database SQLリファレンス・ガイド」、リリース7.0、ORACLE TIMESTEN、［online］、［平成24年1月13日検索］、＜URL: http://otndnld.oracle.co.jp/document/products/timesten/html/E05176-02/toc.htm＞

しかしながら、先述したようなインデックス構築技術によれば、特にＢツリーインデックスにおいて更新が頻繁に発生すると、リーフ分割により新規リーフが増加する一方で、更新前にメタデータが存在していて更新後に削除されたリーフは空きリーフとなり残ることから、リーフが散在することになる。

この状態で、ユーザからの要求に応じてデータの返却範囲検索を行うと、空になったリーフを参照するＩ／Ｏが発生するため、返却範囲検索時に遅延を引き起こす原因となる。このような追加や削除などの更新によりインデックス構造が変化して非効率なデータ検索になる事象は、Ｂツリーインデックスに限らず、他のインデックス方法でも同様に発生する。

このような問題を解決するにはインデックスの再構築が必要になるが、メタデータの数が大量になると当該再構築に多くの時間が必要になるため、その構築中はそのインデックスを使用することができなくなる。また、データの更新が頻発すると、メタデータを格納しているメモリのフラグメンテーションが発生しやすくなり、やはり検索処理の性能が低下してしまう。

また、先述したようなオンメモリ化技術は、複数のデータ項目を単純に纏めたデータテーブルをメモリに格納しておく技術であるが、データの返却範囲検索を高速に行うためにメモリを利用した場合には、メモリの記憶容量は外部記憶装置よりも小さいため、格納されるデータテーブルのサイズが限定されてしまう。なお、非特許文献２には、データの冗長性を解消する技術が記載されているが、当該技術に基づいてデータベーステーブルを生成するには高度な知識が必要となる。

本発明は、上記課題を鑑みてなされたものであり、その課題とするところは、データを高速に検索することにある。

請求項１に記載のデータ検索システムは、ロードデータを生成するロードデータ生成装置と、前記ロードデータを用いてデータを検索するオンメモリ検索装置と、を備えたデータ検索システムにおいて、前記ロードデータ生成装置は、構造化文書記憶手段から構造化文書データを取得する構造化文書データ取得手段と、前記構造化文書データに含まれる複数の属性データをバイナリ化して複数のカラムにそれぞれ格納して連続させたロードデータを生成し、前記生成する際に、少なくとも２つのロードデータにおいて同じバイナリ化された属性データが格納される場合、一方のロードデータのカラムに当該属性データのバイナリ化値を格納し、他方のロードデータのカラムに前記一方のロードデータのカラムの前記一方のロードデータ内での位置を示すインデックス値を格納するロードデータ生成手段と、を有し、前記オンメモリ検索装置は、前記他方のロードデータのカラムを前記一方のロードデータのカラムにリンク付けたカラムポインタリストを生成して非稼働中の記憶手段へ格納するロードデータ処理手段と、参照先の記憶手段を稼働中の記憶手段から前記非稼働中の記憶手段に切り替え、切り替え先の記憶手段のカラムポインタリストから所望のデータを検索するオンメモリ検索手段と、を有し、前記ロードデータ生成手段は、前記一方のロードデータのカラムがリスト型カラムの場合、前記一方のロードデータ内での当該カラムの位置を示す第１のインデックス値と、前記リスト型カラム内の要素への位置を示す第２のインデックス値とを前記他方のロードデータのカラムに格納し、前記一方のロードデータのカラムがリスト型カラム以外の場合、前記第１のインデックス値のみを前記他方のロードデータのカラムに格納することを特徴とする。

請求項２に記載のデータ検索システムは、請求項１に記載のデータ検索システムにおいて、前記ロードデータ生成装置は、前記生成したロードデータを分割して複数の前記オンメモリ検索装置に送信し、前記複数のオンメモリ検索装置の各検索結果をデータ検索要求に合うように整えるコンセントレータ装置を更に有し、前記コンセントレータ装置は、前記データ検索要求に返却範囲が含まれている場合、前記データ検索要求を書き換えることを特徴とする。
請求項３に記載のデータ検索システムは、請求項１又は２に記載のデータ検索システムにおいて、前記ロードデータ生成装置は、前記生成したロードデータを分割して複数の前記オンメモリ検索装置に送信し、前記複数のオンメモリ検索装置の各検索結果をデータ検索要求に合うように整えるコンセントレータ装置を更に有し、当該コンセントレータ装置は、前記データ検索要求に並び替え要求が含まれている場合、前記データ検索要求を書き換えることを特徴とする。
請求項４に記載のデータ検索システムは、請求項２に従属する請求項３に記載のデータ検索システムにおいて、前記コンセントレータ装置は、前記複数のオンメモリ検索装置の各検索結果に含まれる検索結果データを並び替え要求順にキューに格納する手段と、前記キューの先頭から順番に返却範囲内の検索結果データをデータ検索要求元へ順次送信する手段と、を有することを特徴とする。

請求項５に記載のデータ検索方法は、ロードデータを生成するロードデータ生成装置と、前記ロードデータを用いてデータを検索するオンメモリ検索装置と、で行うデータ検索方法において、前記ロードデータ生成装置は、構造化文書記憶手段から構造化文書データを取得する構造化文書データ取得ステップと、前記構造化文書データに含まれる複数の属性データをバイナリ化して複数のカラムにそれぞれ格納して連続させたロードデータを生成し、前記生成する際に、少なくとも２つのロードデータにおいて同じバイナリ化された属性データが格納される場合、一方のロードデータのカラムに当該属性データのバイナリ化値を格納し、他方のロードデータのカラムに前記一方のロードデータのカラムの前記一方のロードデータ内での位置を示すインデックス値を格納するロードデータ生成ステップと、を有し、前記オンメモリ検索装置は、前記他方のロードデータのカラムを前記一方のロードデータのカラムにリンク付けたカラムポインタリストを生成して非稼働中の記憶手段へ格納するロードデータ処理ステップと、参照先の記憶手段を稼働中の記憶手段から前記非稼働中の記憶手段に切り替え、切り替え先の記憶手段のカラムポインタリストから所望のデータを検索するオンメモリ検索ステップと、を有し、前記ロードデータ生成ステップでは、前記一方のロードデータのカラムがリスト型カラムの場合、前記一方のロードデータ内での当該カラムの位置を示す第１のインデックス値と、前記リスト型カラム内の要素への位置を示す第２のインデックス値とを前記他方のロードデータのカラムに格納し、前記一方のロードデータのカラムがリスト型カラム以外の場合、前記第１のインデックス値のみを前記他方のロードデータのカラムに格納することを特徴とする。

請求項６に記載のデータ検索方法は、請求項５に記載のデータ検索方法において、前記ロードデータ生成装置は、前記生成したロードデータを分割して複数の前記オンメモリ検索装置に送信し、コンセントレータ装置は、前記オンメモリ検索装置へのデータ検索要求に並び替え要求が含まれている場合、前記データ検索要求を書き換えるステップと、前記複数のオンメモリ検索装置の各検索結果を前記データ検索要求に合うように整えるステップと、を有することを特徴とする。
請求項７に記載のデータ検索方法は、請求項５又は６に記載のデータ検索方法において、前記ロードデータ生成装置は、前記生成したロードデータを分割して複数の前記オンメモリ検索装置に送信し、コンセントレータ装置は、前記オンメモリ検索装置へのデータ検索要求に並び替え要求が含まれている場合、前記データ検索要求を書き換えるステップと、前記複数のオンメモリ検索装置の各検索結果を前記データ検索要求に合うように整えるステップと、を有することを特徴とする。
請求項８に記載のデータ検索方法は、請求項６に従属する請求項７に記載のデータ検索方法において、前記コンセントレータ装置は、前記複数のオンメモリ検索装置の各検索結果に含まれる検索結果データを並び替え要求順にキューに格納するステップと、前記キューの先頭から順番に返却範囲内の検索結果データをデータ検索要求元へ順次送信するステップと、を有することを特徴とする。

請求項９に記載のデータ検索プログラムは、請求項５乃至８のいずれかに記載のデータ検索方法をコンピュータに実行させることを特徴とする。

以上より、本発明によれば、構造化文書データに含まれる属性データをバイナリ化するため、ロードデータを軽量化することができる。更に、２つのロードデータにおいて同じバイナリ化された属性データが格納される場合、一方のロードデータのカラムに当該属性データのバイナリ化値を格納し、他方のロードデータのカラムに当該一方のロードデータのカラムの当該一方のロードデータ内での位置を示すインデックス値を格納するため、同一である属性データの冗長性を排除してロードデータを軽量化することができる。これらより、オンメモリ化に適した軽量のロードデータを生成できることから、オンメモリ検索装置数の拡張が容易となり、結果として、膨大なデータ（構造化文書データ）を高速に検索することが可能となる。

本発明によれば、データを高速に検索できる。

第１の実施の形態に係るデータ検索システムの全体構成を示す図である。 属性分解定義ファイル例を示す図である。 属性分解イメージを示す図である。 カラムタイプとデータマーカとの対応関係を示す図である。 日付型カラムのロードデータ内での格納イメージを示す図である。 数値型カラムのロードデータ内での格納イメージを示す図である。 文字列型カラムのロードデータ内での格納イメージを示す図である。 バイナリ型カラムのロードデータ内での格納イメージを示す図である。 リスト型カラム（数値型）のロードデータ内での格納イメージを示す図である。 リスト型カラム（文字列型）のロードデータ内での格納イメージを示す図である。 リスト型カラム（バイナリ型）のロードデータ内での格納イメージを示す図である。 リンク型カラムのロードデータ内での格納イメージを示す図である。 リンク型カラム（リスト型）のロードデータ内での格納イメージを示す図である。 リンク型カラム（文字列型）のロードデータ内での格納イメージを示す図である。 ロードデータのメモリ展開イメージ（実体のあるカラムの場合）を示す図である。 ロードデータのメモリ展開イメージ（リンク型カラムの場合）を示す図である。 メモリの切り替えイメージを示す図である。 オンメモリ検索装置１台での通常検索イメージを示す図である。 第２の実施の形態に係るデータ検索システムの全体構成を示す図である。 オンメモリ検索装置複数台での通常検索イメージを示す図である。 オンメモリ検索装置複数台での返却範囲書き換え検索イメージを示す図である。 オンメモリ検索装置複数台による検索結果の返却処理フローを示す図である。 オンメモリ検索装置複数台による検索結果の返却例を示す図である。

以下、本発明を実施する一実施の形態について図面を用いて説明する。但し、本発明は多くの異なる様態で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。

〔第１の実施の形態〕
図１は、第１の実施の形態に係るデータ検索システムの全体構成を示す図である。このデータ検索システム１は、ロードデータ生成装置１００とオンメモリ検索装置２００とで主に構成され、それら各装置は相互に通信可能である。

ロードデータ生成装置１００は、構造化文書データベース２から構造化文書データを取得する構造化文書データ取得部１１と、取得した構造化文書データを用いて、データ検索時に使用されるロードデータを生成するロードデータ生成部１２と、を備えている。

オンメモリ検索装置２００は、ロードデータ生成装置１００で生成されたロードデータを受け取ってメモリ２２に格納するロードデータ処理部２１と、格納されたロードデータを検索・読出可能に記憶しておくメモリ２２と、通信ネットワーク３を通じて１つ以上のクライアント端末４からデータ検索が要求された場合に、メモリ２２に格納されたロードデータから該当するデータを検索・取得して要求元に返信するオンメモリ検索部２３と、を備えている。

以下、それら各装置１００、２００の機能や動作について説明する。なお、構造化文書データベース２に記憶されている構造化文書データとは、映像等のコンテンツに関連する様々な属性データ（例えば、コンテンツの作成日時、コンテンツのデータ形式、コンテンツのタイトル、コンテンツの概要、コンテンツの価格、コンテンツの購入日時、その購入ＩＤ等）を項目化して集約・列記したデータであり、ＸＭＬ等の言語で記載・作成されている。背景技術で説明したように、一般的には、メタデータと称されている。

＜ロードデータ生成装置の機能及び動作について＞
ロードデータ生成装置１００は、まず、構造化文書データ取得部１１により、構造化文書データベース２から構造化文書データを取得して、次に、ロードデータ生成部１２により、予め定義された属性分解定義ファイルに従って、構造化文書データ内の要素内容や属性値等を抽出して、テーブル構造に整理する。

属性分解定義ファイルは、生成されるテーブルの構造を記述した事前定義ファイルであり、構造化文書データ内の要素内容や属性値（以下、属性データ）を、「どのテーブル名の、どの列名（以下、カラム名）のカラムに、どの型（以下、カラムタイプ）で格納するか」が記載されている。

例えば、図２に示すように定義された属性分解定義ファイルの場合、“ｃｒｉｄ”や“ｆｒａｇｍｅｎｔｔｙｐｅ”等のカラム名を有する“ＰｕｒｃｈａｓｅＩｎｆｏｒｍａｔｉｏｎ”という名のテーブルが生成される。この属性分解定義ファイルに基づいて図３の上に示すような構造化文書データを整理すると、同図の下に示すようなテーブルが生成される。

属性分解定義ファイルは必要に応じて複数設定・登録されており、例えば、１つの構造化文書データから、それに応じた１つ以上のテーブルが生成される。具体的には、先の“ＰｕｒｃｈａｓｅＩｎｆｏｒｍａｔｉｏｎ”という名の購入情報を纏めたテーブルや、その他、ユーザ情報を纏めたテーブル、課金情報を纏めたテーブル等が生成される。属性分解定義ファイル内での定義によっては、全ての属性データを纏めたマスターテーブルが生成される。

その後、ロードデータ生成部１２により、生成されたテーブルのカラム内の各属性データをバイナリ化し、バイナリ化された全ての属性データを連続させて、その連続により生成された一連のデータをロードデータとして後段のオンメモリ検索装置２００に出力する。

ここで、このロードデータ生成装置１００で最終的に生成されるロードデータについて以下詳述する。

ロードデータは、カラム（実際には、カラム内に格納された属性データのバイナリ化値）を連続させた構造を備えており、各カラムの先頭には、カラムタイプ（格納されている属性データの種類）を特定するデータマーカが記載（格納）されている。

カラムタイプとは、図４に示すように、カラムに格納する属性データの種類（例えば、日付型、数値型、文字列型、正規化文字列型、バイナリ型、リンク型等）や、その格納方法（例えば、リスト型等）を示すものである。

ロードデータ内でのカラムの格納イメージを図５〜図１４に示す。後述するリンク型以外の型の場合、図５〜図１１に示すように、属性データの種類を示すデータマーカの後に直接属性データのバイナリ化値が格納される。ただし、属性データが数値である場合は、数値として扱う必要があるため、１６進数に変換した後に、バイナリ化して格納する。

例えば、図５に示すように、カラム内の属性データが日付時間の場合には、エポックタイム（１９７０／０１／０１ ００:００:００ ＵＴＣからの経過秒）に一端変換し、更に１６進数に変換した後に、バイナリ化して、その先頭に日付型のデータマーカ（０ｘ１１）を設定する。

同様に、例えば、図６に示すように、カラム内の属性データが何らかの数値の場合には、１６進数に変換した後に、バイナリ化して、その先頭に数値型のデータマーカ（０ｘ１２）を設定する。

また、例えば、図７に示すように、カラム内の属性データが何らかの文字列の場合には、１６進数に変換することなくバイナリ化して、その先頭に文字列型のデータマーカ（０ｘ１３）を設定すると共に、その後尾に終端を示す区切り文字のバイナリ値（例えば、０ｘ００）を設定する。

また、例えば、図８に示すように、カラム内の属性データが何らかのバイナリ値の場合には、先頭にバイナリ型のデータマーカ（０ｘ１４）を設定して、その直後にバイナリ長（当該バイナリ値のデータ長）と当該バイナリ値を設定する。

一方、リスト型の場合、リスト型とは複数のデータを繰り返して格納する方法であることから、図９〜図１１に示すように、連続する複数の属性データのバイナリ化値の前に、リスト型であることを示すデータマーカを記載する。

例えば、図９に示すように、カラム内の属性データが２つの数値（同図の（１）と（２））を含むリストの場合には、各数値をそれぞれ１６進数に変換した後に、それぞれをバイナリ化して、その先頭にリスト型のデータマーカ（０ｘ１５）を設定し、その直後に数値型を表すデータマーカ（０ｘ１２）を設定し、その直後にリスト内での属性データの繰り返し数（（１）と（２）の２つ）を設定し、各バイナリ化値を連続して設定する。

また、例えば、図１０に示すように、カラム内の属性データが３つの文字列を含むリストの場合には、各文字列をそれぞれバイナリ化して、その先頭にリスト型のデータマーカ（０ｘ１５）を設定し、その直後に文字列型を表すデータマーカ（０ｘ１３）を設定し、各バイナリ値を連続して設定し、後尾に終端を示す区切り文字のバイナリ値（０ｘ００）を設定する。各バイナリ化値を区別するため、各バイナリ化値の間にも、各バイナリ化値の終端を示す区切り文字のバイナリ値（０ｘ００）を設定する。

また、例えば、図１１に示すように、カラム内の属性データが２つのバイナリを含むリストの場合には、先頭にリスト型のデータマーカ（０ｘ１５）を設定し、その直後にバイナリ型を表すデータマーカ（０ｘ１４）を設定し、各バイナリ値のバイナリ長とそのバイナリ値とを繰り返し設定して、後尾に終端を示す区切り文字（例えば、「ＦＦ，ＦＦ，ＦＦ，ＦＦ」）を設定する。

以上より、構造化文書データをテーブル構造に変換し、そのテーブル構造に変換された属性データをバイナリ化するので、データ検索時に利用されるロードデータのデータサイズを小さくすることができる。

一方、先述したように、属性分解定義ファイルが複数の場合には複数のテーブルが生成され、それにより複数のロードデータが生成されることから、それらロードデータ間で、同じ属性データをバイナリ化した同じバイナリ化値を持つ場合がある。

つまり、その場合には、２つ以上のロードデータ間で属性データが同一のカラムが存在し、それぞれのロードデータで同じ属性データをそれぞれが保持するため、その同じ属性データにおいて冗長構造を有することになる。

そこで、そのように同じ属性データのバイナリ値を有するカラムについては、それら複数のロードデータのうち、原本として取り扱われるロードデータ（例えば、先述したマスターテーブルから生成されるマスターロードデータ）にはバイナリ化値を格納し、それ以外のロードデータには当該バイナリ化値にリンクするリンク型のデータを生成してカラム内に格納し、実データに相当するバイナリ化値は格納しないようにする。

例えば、２つのロードデータが、それぞれ、ｘｍｌｓ（０）とｘｍｌ（１）の２つのバイナリ化値を格納したリスト型カラムを有する場合、図１２に示すように、上のロードデータのリスト型カラムにはバイナリ化値を格納するが、下のロードデータのカラムは、上のロードデータのリスト型カラムにリンクするためのリンク型カラムを設定して、そのリンク型カラムの位置に関するインデックス値を格納する。

具体的には、図１３に示すように、先頭にリンク型のデータマーカ（０ｘ１６）を設定し、その直後にリンク先のカラム位置（上のロードデータ内でのカラム位置）を示すインデックス値（以下、第１インデックス値）を設定し、その次に、間にデリミタ（例えば“｜”）を挟んで、そのリンク先のリスト型カラム内の各要素へのリンク先を示すインデックス値（以下、第２インデックス値）を設定する。

例えば、図１２に示したような場合、同じ属性データのバイナリ値を有するリスト型カラムは、上のロードデータにおいて左から３列目にあるため、インデックス値を０から開始する場合、第１インデックス値は２となる。

一方、そのリスト型カラム内において、ｘｍｌｓ（０）は左から１つ目にあるため、同様にインデックス値を０から開始する場合、第２インデックス値は０となる。また、そのリスト型カラム内において、ｘｍｌｓ（１）は左から２つ目にあるため、第２インデックス値は１となる。

これにより、図１２の下のロードデータの１行目や２行目に示すようなリンク型のデータ（リンク型カラムに格納されたリンク先情報）が当該ロードデータに格納される。

以上より、ロードデータ間で同じ属性データのバイナリ値を有するカラムがある場合、一方のロードデータにバイナリ化値を格納し、他方のロードデータに当該バイナリ値にリンクするリンク型のデータを生成して格納するので、リンク型カラム内のデータのサイズはバイナリ化値よりも小さいことから、カラムデータの冗長性を排除でき、実体としてのカラム数を削減できる。

また、当該他方のロードデータ参照時には、リンク先である当該一方のロードデータ内のバイナリ化値を利用できるので、全ロードデータのカラム全てにバイナリ値を格納するよりも、全体としてのロードデータのデータサイズをより小さくすることができる。

また、リンク先が他のデータ型の場合でも上記リンク型カラムを利用できる。例えば、図１２に示したように、リンク先が文字列型カラムの場合、下のロードデータにおいて第１インデックス値は３となる。

文字列型カラムであり、リスト構造を有していないため、第２インデックス値は不要になることから、当該第２インデックス値には、確保されている４バイト内にデフォルト値として例えば０を格納する（図１４（ａ）参照）。図１４（ｂ）に示すように第１インデックス値のみを利用するようにしてもよい。

以上より、リンク先がリスト型カラム以外の場合には、第１インデックス値のみを利用するため、ロードデータのデータサイズを更に小さくし、メモリ領域を効率よく利用することができる。

なお、図１２では、理解を容易にするため、カラム内のデータを、バイナリ化値ではなく、バイナリ化前の属性データをそのまま記載している。後述する図１５、図１６、図１８、図２０、図２１、図２３についても同様である。

その後、ロードデータ生成部１２により、図５〜図１１、図１３、図１４に示したようなバイナリ化後のカラムを連続させたロードデータが、オンメモリ検索装置２００に送られる。

＜オンメモリ検索装置の機能及び動作について＞
次に、オンメモリ検索装置２００の機能及び動作について、データ検索要求を受ける前と受けた後とに分けて以下説明する。

（データ検索要求を受ける前までの処理について）
オンメモリ検索装置２００は、ロードデータ処理部２１により、ロードデータ生成装置１００から送られたロードデータを受信して、メモリ２２に格納する。

ここで、メモリ２２に格納する際、各ロードデータにそれぞれ対応するカラムポインタリスト（ロードデータ内の各カラムにそれぞれ対応する複数の領域を有するカラムポインタリスト）を生成する。このカラムポインタリストには、ロードデータ内の各カラムの先頭アドレスが記載され、クライアント端末４からのデータ検索要求時に該当するデータを参照・取得するために利用される。

リンク型カラム以外の場合、ロードデータ内の全てのカラムにバイナリ化値が格納されていることから、図１５に示すように、全てのカラムの先頭アドレスがカラムポインタリストに記載される。なお、図１５の矢印は、先頭アドレスの参照関係を示している。後述する図１６についても同様である。

一方、リンク型カラムの場合には、図１６に示すように、当該リンク先のカラムの先頭アドレスをカラムポインタリスト内に直接記載する。先述したように、ロードデータの各カラムにそれぞれ対応する領域を有し、特にリンク型カラムに対応する領域にはリンク先のカラムの先頭アドレスが記載されることから、カラムポインタリストは、当該リンク型カラムをリンク先のカラムにリンク付ける機能を有している。

リンク型カラム内の第１，第２インデックス値は、リンク先情報を記載しているため、カラムポインタリストにリンク先カラムの先頭アドレスが記載された後は、オンメモリ検索部２３により当該カラムポインタリストを利用してデータ検索されることから、そのデータ検索時において使用されないカラムになる。

以上より、全カラムに実体としてのバイナリ化値がある場合に比べて、リンク型カラムを用いる場合には、メモリ上の全カラムに実体がある場合と同じでありながら、使用するメモリサイズを小さくすることができる。

（メモリの切り替え機能について）
ここで、図１７を参照しながら、メモリ２２の有する切り替え機能について説明する。オンメモリ検索装置２００は、メモリ２２を、論理的に、フロントエンドメモリとバックエンドメモリとの２つに分けて利用する機能を備えている。

オンメモリ検索装置２００のメモリ２２にロードデータを格納する際、ロードデータは、まず、バックエンドメモリ２２ａに格納される。

バックエンドメモリ２２ａとフロントエンドメモリ２２ｂの違いは、オンメモリ検索装置２００においてデータ検索対象になっているか否かであり、バックエンドメモリ２２ａにロードデータを格納しただけでは、データ検索対象にはならない。

バックエンドメモリ２２ａに正常にロードデータが展開された後に、ロードデータへの参照メモリのアドレスを現在のフロントエンドメモリ２２ｂからバックエンドメモリ２２ａに切り替える（ロードデータの更新）ことにより、当該バックエンドメモリ２２ａに新たに格納されたロードデータが検索対象となる。

なお、これまでフロントエンドメモリ２２ｂ上に格納され、データ検索対象となっていたロードデータは、参照アドレスの切り替えと共に消去され、当該フロントエンドメモリ２２ｂは初期化される。

以上より、メモリ２２をフロントエンドメモリ２２ｂとバックエンドメモリ２２ａに分け、格納するロードデータ全体を丸ごと切り替える（データの総更新）ので、追加削除が頻発したとしても、インデックスを毎回生成し、ロードデータを毎回総取替えすることから、不要なインデックスや空のインデックスが増えることによるデータ検索システム１の遅延や、メモリ２２でのフラグメントの発生を防止できる。

また、参照メモリのアドレスを切り替えるのみであるため、高速で実行でき、データ検索サービスの分断を防止できる。

（データ検索要求を受けた後の処理について）
引き続き、データ検索要求を受けた場合の処理について説明する。オンメモリ検索装置２００は、オンメモリ検索部２３により、クライアント端末４から送信されたデータ検索要求を受け付けて、カラムポインタリストを利用して、ロードデータから当該データ検索要求に該当するデータを検索し、返信する。

例えば、図１８に示すように、データ検索要求内の検索クエリに返却範囲（ｒａｎｇｅ（Ｘ，Ｙ））（但し、Ｘ：開始行位置、Ｙ：返却行数）が指定されている場合、メモリ２２からロードデータを読み出して、その返却範囲に指定されている開始行位置Ｘから返却行数Ｙまでのデータをカラムポインタリストを利用してロードデータから検索・取得し、検索結果として返却する。

なお、ロードデータにおいてリンク型カラムがある場合、先述したように、カラムポインタリストにおいてリンク先のカラムの先頭アドレスがカラムポインタリストに格納されていることから（図１６参照）、当該データ検索・取得時には、そのリンク先のロードデータからデータを検索・取得する。

〔第２の実施の形態〕
ロードデータ生成装置１００で生成されるロードデータのサイズが、オンメモリ検索装置２００のメモリ２２の容量の例えば半分未満であって、そのメモリ２２の空き容量に余裕があれば、第１の実施の形態で説明したように、オンメモリ検索装置２００が１台の構成でデータ検索サービスを提供することができる。

しかし、ロードデータのサイズがメモリ２２の容量の半分以上となるような場合、当該サービスの実行時に必要とされるプログラムのデータ展開等によるメモリの使用等により検索処理速度の低下等が発生することから、１台のオンメモリ検索装置２００で当該サービスを提供することは難しい場合がある。

そこで、第２の実施の形態では、図１９に示すように、オンメモリ検索装置２００を複数備え、それら複数のオンメモリ検索装置２００のクライアント端末側に、各オンメモリ検索装置２００の各検索結果をデータ検索要求に合うように整えるコンセントレータ装置３００を更に設置することにより、ロードデータのサイズが大きい場合であってもデータ検索サービスを確実に実現するようにしている。

すなわち、ロードデータ生成装置１００のロードデータ生成部１２は、生成したロードデータのサイズがある一定以上（例えば、メモリ２２の容量の半分以上）であるか否かを判定し、一定以上の場合に、そのロードデータをオンメモリ検索装置２００の数に分割して、各オンメモリ検索装置２００にそれぞれ送信する。

各オンメモリ検索装置２００は、送信されたロードデータを受け取り、各装置内のメモリ２２にそれぞれ格納する。

一方、クライアント端末４からデータ検索要求が送信された場合、その要求をコンセントレータ装置３００が受信し、そのデータ検索要求に含まれる検索クエリの構文を解析し、このクエリ構文の解析をもとに以下の処理を実施する。

コンセントレータ装置３００は、検索クエリに返却範囲が指定されていた場合、又は、並び替えが指定（ソート指定）されていた場合、検索クエリを書き換え、書き換えた後の検索クエリをオンメモリ検索装置２００に送信する。また、複数のオンメモリ検索装置２００から返却される検索結果をクライアント端末４からの検索クエリに応じた検索結果に成型して送出する。以下、詳述する。

（検索クエリに返却範囲が指定されている場合のクエリ書き換え処理）
検索クエリに返却範囲が指定されている場合、オンメモリ検索装置２００が１台の構成であれば、第１の実施の形態で説明したように、その返却範囲に指定されている開始行位置Ｘから返却行数Ｙまでを単に検索・取得をすることで、期待される検索結果を返却できる。全てのロードデータが１つのメモリ２２に格納されているので、検索する前に検索クエリを書き換える必要はない。

しかし、本実施の形態のように、複数のオンメモリ検索装置２００をコンセントレータ装置３００で管理している場合、複数の異なるロードデータが各オンメモリ検索装置２００に分散して格納されているため、検索クエリの返却範囲を全く書き換えないで検索した場合、各オンメモリ検索装置２００のロードデータをそれぞれ検索することから、図２０に示すように、期待する検索結果を得ることができない。図１８と比較すると、同じ検索クエリであるにもかかわらず、同一の検索結果を得ることができない。

そのため、検索クエリに返却範囲が指定されていた場合、コンセントレータ装置３００は、検索クエリの返却範囲の指定を次のように書き換えた後に、各オンメモリ検索装置２００に対してデータ検索を行う。

具体的には、図２１に示すように、返却範囲がｒａｎｇｅ（Ｘ，Ｙ）と指定されている場合、返却開始行をＸから「１」（図２０では５を１）に書き換え、返却行数をＹから「Ｘ＋Ｙ−１」（図２０では１０を「５＋１０−１」）に書き換える。

この書き換え処理により、返却範囲が元の検索クエリよりも広がった広範な範囲となる。これは、複数のオンメモリ検索装置２００を具備する構成でありながら、１つのオンメモリ検索装置２００からの検索結果に返却範囲の全てが含まれるような場合に対応するためである。

コンセントレータ装置３００は、このようにして得られた各オンメモリ検索装置２００からの検索結果を結合した後に、本来の返却範囲指定を適用する。これにより、検索結果に不整合が発生するのを防止できる。

（検索クエリに並べ替えが指定されている場合のクエリ書き換え処理）
オンメモリ検索装置２００が複数で構成されている場合、各オンメモリ検索装置２００からのそれぞれの検索結果が並び替えられていても、コンセントレータ装置３００で検索結果を結合したときに並び替え順序が崩れてしまう。そのため、コンセントレータ装置３００でも、並び替えカラムを基に並び替え処理を実行しなければならない。

並び替えカラム名に指定されたカラムが返却カラム名に指定されていないクエリをそのまま各オンメモリ検索装置２００に送信した場合、並び替える際に参照するカラムが無いため並び替えることができない。

そこで、並び替えカラム名に指定されたカラムが返却カラム名に指定されていないクエリの場合、並び替えカラム名を返却カラム名の先頭に追加して検索クエリを書き換える。

（並び替えや返却範囲指定がなされた場合の検索結果返却処理）
以下、図２２、図２３を参照しながら、並び替えや返却範囲指定がなされた場合の検索結果返却処理について説明する。なお、返却処理開始時に、並べ替え指定の有無に応じて、事前に設けたソート用キューを初期化しておく。並び替え指定がある場合は、ソート用キューへの登録時に並び替え条件に従った順序で登録するように設定するものとする。並び替え指定がない場合は、ソート用キューに登録した順にそのままに並べるように設定するものとする。図２３では「Ａｘｘｘｘ」（但し、ｘは数字）のカラムが並び替えカラムになっている。

最初に、ステップＳ１において、コンセントレータ装置３００は、そのソート用キューを初期化し、ステップＳ２において、事前に用意したカウントデータを１で初期化する。

次に、ステップＳ３において、各オンメモリ検索装置２００でそれぞれ検索された各検索結果から先頭の１件分を受信して、ソート用キューに登録する（図２３の（１）〜（３））。これ以降は、そのソート用キューが空になるまで以下の処理を繰り返す。

次に、ステップＳ４において、現在のソート用キューが空か否かを判定し、空でない場合には、ステップＳ５において、そのソート用キューの先頭１件の検索データを取り出して、指定された返却範囲内か否かを判定する。一方、ステップＳ４において、現在のソート用キューが空の場合には、本処理を終了する。

次に、ステップＳ６において、ステップＳ５の判定で検索データが返却範囲内の場合には、その検索データをクライアント端末４に送出する（図２３の（４）、（５））。返却範囲の指定に対処するため、検索データ送出時には、その送出件数をカウントしておく。また、検索クエリを書き換え、並び替えカラム名をコンセントレータ装置３００で返却カラムに追加した場合には、追加したカラムに該当する箇所を削除して送出する。

一方、ステップＳ７において、ステップＳ５の判定で検索データが返却範囲外の場合には、その検索データを破棄する。

その後、ステップＳ８において、ステップＳ３でソート用キューの先頭にあった検索データを検索結果として返却したオンメモリ検索装置２００から次の１件分の検索データを受信してソート用キューに登録し、ステップＳ４に戻る（図２３の（６）、（７））。

例えば、図２３の（６）において、ソート用キューには「Ａ０００２」と「Ａ０００３」が登録されており、新たに追加する「Ａ０００４」は「Ａ０００２」や「Ａ０００３」よりも大きいので、「Ａ０００３」の次に登録する。

また、図２３の（７）では、「Ａ０００３」と「Ａ０００４」が登録されており、新たに追加する「Ａ０００５」は「Ａ０００３」や「Ａ０００４」よりも大きいので、上記（６）と同様にソート用キューの末尾に登録する。

その他、例えば、「Ａ０００５」と「Ａ０００７」がすでに登録されている場合において、新たに追加する検索データが「Ａ０００４」の場合は、ソート用キューの先頭に登録し、新たに追加する検索データが「Ａ０００６」の場合は、「Ａ０００５」と「Ａ０００７」の間に登録する。

以上より、ロードデータが大きく、オンメモリ検索装置１台のメモリ上に展開できない場合、複数のオンメモリ検索装置２００にロードデータを分割して格納し、各オンメモリ検索装置２００の各検索結果をデータ検索要求に合うように整えるので、分割されたロードデータを意識せずにデータ検索を行うことができる。

なお、各実施の形態では、データ検索システム１を複数の装置で構成する場合について説明したが、１つの装置で構成することも可能である。また、コンセントレータ装置３００を１つの機能部としてロードデータ生成装置１００に具備させることも可能である。

各実施の形態で説明したデータ検索システム１、当該システム１を構成しているロードデータ生成装置１００、オンメモリ検索装置２００、コンセントレータ装置３００は、ＣＰＵ等の制御手段やメモリ等の記憶手段を具備する情報処理装置で実現できる。それら各装置を構成している各機能部の処理は、当該処理を実行可能なプログラムにより実現できる。

最後に、各実施の形態によれば、構造化文書データに含まれる属性データをバイナリ化するので、ロードデータを軽量化することができる。更に、２つのロードデータにおいて同じバイナリ化された属性データが格納される場合、一方のロードデータのカラムに当該属性データのバイナリ化値を格納し、他方のロードデータのカラムに当該一方のロードデータのカラムの当該一方のロードデータ内での位置を示すインデックス値を格納するので、同一である属性データの冗長性を排除してロードデータを軽量化することができる。これらより、オンメモリ化に適した軽量のロードデータを生成できることから、オンメモリ検索装置数の拡張が容易となり、結果として、データ（構造化文書データ）を高速に検索することが可能となる。

１…データ検索システム
１００…ロードデータ生成装置
１１…構造化文書データ取得部
１２…ロードデータ生成部
２００…オンメモリ検索装置
２１…ロードデータ処理部
２２…メモリ
２２ａ…バックエンドメモリ
２２ｂ…フロントエンドメモリ
２３…オンメモリ検索部
３００…コンセントレータ装置
３…通信ネットワーク
４…クライアント端末
Ｓ１〜Ｓ８…処理ステップ

Claims (9)

1. ロードデータを生成するロードデータ生成装置と、前記ロードデータを用いてデータを検索するオンメモリ検索装置と、を備えたデータ検索システムにおいて、
   前記ロードデータ生成装置は、
   構造化文書記憶手段から構造化文書データを取得する構造化文書データ取得手段と、
   前記構造化文書データに含まれる複数の属性データをバイナリ化して複数のカラムにそれぞれ格納して連続させたロードデータを生成し、前記生成する際に、少なくとも２つのロードデータにおいて同じバイナリ化された属性データが格納される場合、一方のロードデータのカラムに当該属性データのバイナリ化値を格納し、他方のロードデータのカラムに前記一方のロードデータのカラムの前記一方のロードデータ内での位置を示すインデックス値を格納するロードデータ生成手段と、を有し、
   前記オンメモリ検索装置は、
   前記他方のロードデータのカラムを前記一方のロードデータのカラムにリンク付けたカラムポインタリストを生成して非稼働中の記憶手段へ格納するロードデータ処理手段と、
   参照先の記憶手段を稼働中の記憶手段から前記非稼働中の記憶手段に切り替え、切り替え先の記憶手段のカラムポインタリストから所望のデータを検索するオンメモリ検索手段と、を有し、
   前記ロードデータ生成手段は、
   前記一方のロードデータのカラムがリスト型カラムの場合、前記一方のロードデータ内での当該カラムの位置を示す第１のインデックス値と、前記リスト型カラム内の要素への位置を示す第２のインデックス値とを前記他方のロードデータのカラムに格納し、前記一方のロードデータのカラムがリスト型カラム以外の場合、前記第１のインデックス値のみを前記他方のロードデータのカラムに格納することを特徴とするデータ検索システム。
2. 前記ロードデータ生成装置は、前記生成したロードデータを分割して複数の前記オンメモリ検索装置に送信し、
   前記複数のオンメモリ検索装置の各検索結果をデータ検索要求に合うように整えるコンセントレータ装置を更に有し、
   前記コンセントレータ装置は、
   前記データ検索要求に返却範囲が含まれている場合、前記データ検索要求を書き換えることを特徴とする請求項１に記載のデータ検索システム。
3. 前記ロードデータ生成装置は、前記生成したロードデータを分割して複数の前記オンメモリ検索装置に送信し、
   前記複数のオンメモリ検索装置の各検索結果をデータ検索要求に合うように整えるコンセントレータ装置を更に有し、
   当該コンセントレータ装置は、
   前記データ検索要求に並び替え要求が含まれている場合、前記データ検索要求を書き換えることを特徴とする請求項１又は２に記載のデータ検索システム。
4. 前記コンセントレータ装置は、
   前記複数のオンメモリ検索装置の各検索結果に含まれる検索結果データを並び替え要求順にキューに格納する手段と、
   前記キューの先頭から順番に返却範囲内の検索結果データをデータ検索要求元へ順次送信する手段と、
   を有することを特徴とする請求項２に従属する請求項３に記載のデータ検索システム。
5. ロードデータを生成するロードデータ生成装置と、前記ロードデータを用いてデータを検索するオンメモリ検索装置と、で行うデータ検索方法において、
   前記ロードデータ生成装置は、
   構造化文書記憶手段から構造化文書データを取得する構造化文書データ取得ステップと、
   前記構造化文書データに含まれる複数の属性データをバイナリ化して複数のカラムにそれぞれ格納して連続させたロードデータを生成し、前記生成する際に、少なくとも２つのロードデータにおいて同じバイナリ化された属性データが格納される場合、一方のロードデータのカラムに当該属性データのバイナリ化値を格納し、他方のロードデータのカラムに前記一方のロードデータのカラムの前記一方のロードデータ内での位置を示すインデックス値を格納するロードデータ生成ステップと、を有し、
   前記オンメモリ検索装置は、
   前記他方のロードデータのカラムを前記一方のロードデータのカラムにリンク付けたカラムポインタリストを生成して非稼働中の記憶手段へ格納するロードデータ処理ステップと、
   参照先の記憶手段を稼働中の記憶手段から前記非稼働中の記憶手段に切り替え、切り替え先の記憶手段のカラムポインタリストから所望のデータを検索するオンメモリ検索ステップと、を有し、
   前記ロードデータ生成ステップでは、
   前記一方のロードデータのカラムがリスト型カラムの場合、前記一方のロードデータ内での当該カラムの位置を示す第１のインデックス値と、前記リスト型カラム内の要素への位置を示す第２のインデックス値とを前記他方のロードデータのカラムに格納し、前記一方のロードデータのカラムがリスト型カラム以外の場合、前記第１のインデックス値のみを前記他方のロードデータのカラムに格納することを特徴とするデータ検索方法。
6. 前記ロードデータ生成装置は、前記生成したロードデータを分割して複数の前記オンメモリ検索装置に送信し、
   コンセントレータ装置は、
   前記オンメモリ検索装置へのデータ検索要求に返却範囲が含まれている場合、前記データ検索要求を書き換えるステップと、
   前記複数のオンメモリ検索装置の各検索結果を前記データ検索要求に合うように整えるステップと、
   を有することを特徴とする請求項５に記載のデータ検索方法。
7. 前記ロードデータ生成装置は、前記生成したロードデータを分割して複数の前記オンメモリ検索装置に送信し、
   コンセントレータ装置は、
   前記オンメモリ検索装置へのデータ検索要求に並び替え要求が含まれている場合、前記データ検索要求を書き換えるステップと、
   前記複数のオンメモリ検索装置の各検索結果を前記データ検索要求に合うように整えるステップと、
   を有することを特徴とする請求項５又は６に記載のデータ検索方法。
8. 前記コンセントレータ装置は、
   前記複数のオンメモリ検索装置の各検索結果に含まれる検索結果データを並び替え要求順にキューに格納するステップと、
   前記キューの先頭から順番に返却範囲内の検索結果データをデータ検索要求元へ順次送信するステップと、
   を有することを特徴とする請求項６に従属する請求項７に記載のデータ検索方法。
9. 請求項５乃至８のいずれかに記載のデータ検索方法をコンピュータに実行させることを特徴とするデータ検索プログラム。

Images