JP2015149024A - 検索システムおよびその制御方法、並びにプログラム - Google Patents

Abstract

【課題】ステートレスＷｅｂ ＩＦを前提とした際に、複雑な検索条件を含む多様なクエリを許容すると性能要件を満たせない場合がある。【解決手段】検索条件が指定された検索リクエストを受け付ける受付手段と、前記検索条件に従ってデータの検索を実行し、検索結果を当該検索リクエストに対して応答する検索手段と、受け付けた検索リクエストを記録する記録手段と、前記記録された検索リクエストに基づき、以降の検索リクエストを受け付けるタイミングと検索条件とを予測する予測手段と、前記予測手段にて予測した検索リクエストのタイミングと検索条件とに従って、前記以降の検索リクエストを受け付ける前に、前記データの検索を行って検索結果を取得する取得手段とを有し、前記検索手段は、前記予測した検索リクエストに対応する検索リクエストを受け付けた場合、当該受け付けた検索リクエストによるデータの検索を実行する代わりに、前記取得手段にて取得された検索結果を用いて応答する。【選択図】 図１

Description

本発明は、外部システムとのデータ連携を行う検索システムおよびその制御方法、並びにプログラムに関する。

特許文献１はデータベース接続をしてＵＲＬ要求に応答するＷｅｂサーバを開示している。

特開２００２−９１７７１号公報

外部システムから検索リクエストを受け付ける検索システムは外部システムからの複雑な検索条件を含む多様なクエリを許容する必要がある。その結果、定期的に実行されるクエリであっても、複雑なクエリが発行された場合や検索負荷が集中した場合などに、検索結果の応答が遅延してしまう。特許文献１でもデータベースへのクエリが集中し、スループットが低下する可能性がある。

本発明は、定期的なリクエストに対してスループットを低下させずに応答するために、検索リクエストに対して予測検索処理をリクエストに先立って事前実行する手段を提供する。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、検索条件が指定された検索リクエストを受け付ける受付手段と、前記検索条件に従ってデータの検索を実行し、検索結果を当該検索リクエストに対して応答する検索手段と、前記受付手段にて受け付けた検索リクエストを記録する記録手段と、前記記録手段にて記録された検索リクエストに基づき、以降の検索リクエストを受け付けるタイミングと検索条件とを予測する予測手段と、前記予測手段にて予測した検索リクエストのタイミングと検索条件とに従って、前記以降の検索リクエストを受け付ける前に、前記データの検索を行って検索結果を取得する取得手段とを有し、前記検索手段は、前記予測手段にて予測した検索リクエストに対応する検索リクエストを前記受付手段が受け付けた場合、当該受け付けた検索リクエストによるデータの検索を実行する代わりに、前記取得手段にて取得された検索結果を用いて応答する。

本願発明により、検索リクエストに対して検索処理による待ち時間を抑え、検索結果を返すことが出来る。更に、検索性能を維持しつつ、多様なクエリを許容できる。

検索システムのブロック図。 検索リクエスト、検索処理、結果レスポンスのタイミングチャート。 検索リクエストとバッチ検索処理のタイミングチャート。 検索処理のフローチャート。 検索対象のテーブル例を示す図 クエリの例を示す図。 クエリの例を示す図。 クエリ履歴の例を示す図。 クエリ記録処理のフローチャート。 検索リクエストと検索対象期間のタイミングチャート。 バッチ検索処理の登録処理のフローチャート。 タスクスケジュールテーブルの例を示す図。 タスクスケジューラとタスク実行処理のフローチャート。 第二の実施形態に係るバッチ検索処理の登録処理のフローチャート。

以下、本発明を実施するための形態について図面を用いて説明する。

なお、本明細書では検索システムの一例としてマネージド・プリント・サービス（ＭＰＳ）で利用する検索システムを例にとって説明する。ＭＰＳは、企業のオフィス出力環境の現状を分析し、最適な出力環境を提案、構築するアウトソーシングサービスである。ＭＰＳを提供するベンダーは、顧客である企業のオフィス環境から設置された印刷デバイスや利用しているソフトウェア、サービスの情報を収集、蓄積し、分析のために利用する。また、オフィス環境からの情報収集のためのシステムは、クラウドサービス上に移行される傾向にある。このため、印刷デバイスの販売会社は、独自のシステムを組まなくても、クラウドサービスを利用することで顧客企業へＭＰＳを提供することが出来る。

クラウドサービス上のＭＰＳは、複数の（販売会社の）外部システムと連携を行うために、外部システムとのインターフェースを標準化する。これには、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）に準ずるインターフェースを採用することができる。ＲＥＳＴの原則の一つは、ステートレスなクライアント／サーバプロトコルであるという点である。ステートレスなプロトコルにより、クライアントおよびサーバの構成をシンプルに出来るという効果が得られる。

＜第一の実施形態＞
［システム構成］
図１（ａ）は、本実施形態に係るシステム構成の例を示すブロック図である。検索システム１は、Ｗｅｂサーバ３、検索対象データベース４、バッチ検索サーバ５、および検索結果データベース６を含む。Ｗｅｂサーバ３は、ＲＥＳＴの仕様に準拠したプロトコルを実装しているものとする。Ｗｅｂサーバ３は、クライアント２からの検索リクエストを受信し、検索リクエストに含まれるクエリに従って検索対象データベース４から検索した結果データをレスポンスとして返す。また、バッチ検索サーバ５は、内部のタスクスケジューラ（不図示）に登録された検索タスクを実行し、検索タスクに含まれるクエリに従って検索対象データベース４から検索した結果データを検索結果データベース６へ保存する。Ｗｅｂサーバ３は、後述する条件に従い、クライアント２からの検索リクエストの応答として、バッチ検索サーバ５によって検索された検索済みの結果データも返す。Ｗｅｂサーバ３は、受信した検索リクエストをクエリ履歴データベース７に記録しておく。

本実施形態において、クライアント２、Ｗｅｂサーバ３、およびバッチ検索サーバ５はそれぞれ、情報処理装置としての各部位を備える。各装置の構成例を図１（ａ）に示す。ＣＰＵ１１は、ＲＯＭ１３等に格納されたプログラムを読み出して実行することで装置の全体を制御する。ＲＡＭ１２は、一次記憶領域であり、プログラムの実行に伴うワークメモリ等として用いられる。ＲＯＭ１３は、記録部であり、本実施形態に係るプログラムや設定値等のデータを保持する。Ｉ／Ｆ１４は、外部装置とネットワークを介して接続するためのインターフェースである。入出力装置１５は、ディスプレイ装置やキーボード等のユーザとの情報のやり取りを行うためのインターフェースである。ＨＤＤ１６は、記憶領域であり、各種データやプログラム等を格納する。また、各構成要素は、バス１７を介して互いに接続されており、データの送受信が可能である。

なお、図１（ａ）において、Ｗｅｂサーバ３とバッチ検索サーバ５とは異なる装置として示しているがこれに限定するものではなく、物理的に同じ装置であってもよい。また、１の機能を提供するサーバが物理的に複数の装置によって構成されていてもよい。また、各データベースは、サーバが備えるＨＤＤ内に構成されていても良いし、別の装置として設けられていてもよい。また、各装置間の接続形態としては、内部ネットワークもしくはインターネット等の外部ネットワークを介していてもよい。また、有線／無線も問わない。

［処理に係るタイミングの説明］
図２は、本実施形態に係る検索リクエスト、検索処理、および結果レスポンスのタイミングを示すタイミングチャートの例である。図２では、横軸に時間を示し、各処理の処理時間と、各処理に対するリクエスト／レスポンスのタイミングが示されている。なお、検索リクエストには、検索の処理内容を示す検索クエリ（以下、単にクエリと称する）が含まれているものとする。なお、以下において、検索リクエストの受信に応じて即時に行われる検索処理を「即時検索処理」と記載し、予めタスクとしてスケジュール登録されている検索処理を「バッチ検索処理」と記載する。

図２（ａ）は、Ｗｅｂサーバ３が、検索リクエスト１００に対応して、検索対象データベース４に対する即時検索処理１０２を行い、その処理が完了したタイミングで、結果レスポンス１０１を返すことを示している。

図２（ｂ）は、バッチ検索サーバ５のタスクスケジューラ（不図示）においてバッチ検索処理１０８がすでに実行完了している状態で、検索リクエスト１０６を受信した際の例を示している。この時、実行済みのバッチ検索処理１０８に一致する検索リクエスト１０６が受信されると、Ｗｅｂ検索サーバ５は、そのバッチ検索処理１０８の結果を即、結果レスポンス１０７として要求元に返すことを示している。

図２（ｃ）は、バッチ検索処理１１１がすでに開始済みであり、かつ、未完了の状態の際に、その開始済みのバッチ検索処理１１１に一致する検索リクエスト１０９が受信された場合の例を示している。Ｗｅｂサーバ３は、検索リクエスト１０９が受信されると、すでに開始されているバッチ検索処理１１１の完了を待ち、その後、バッチ検索処理１１１の完了のタイミングでその結果を、結果レスポンス１１０として返すことを示している。

図３は、通常の検索リクエストとバッチ検索処理の関係の例を示すタイミングチャートである。図３は、横軸に時間を示し、Ｗｅｂサーバ３は、定期的に同じ内容の検索リクエスト１００、１０３を受信していることを示している。Ｗｅｂサーバ３は、検索リクエスト１００に対応して即時検索処理１０２を行い、その結果を結果レスポンス１０１として返す。また、Ｗｅｂサーバ３は、検索リクエスト１０３に対応して即時検索処理１０５を行い、その結果を結果レスポンス１０４として返す。

また、Ｗｅｂサーバ３は、検索リクエスト１００と検索リクエスト１０３が定期的な検索リクエストであることを判定し、その後のタイミング１１２で更なる検索リクエストが受信されることを予測する。一方、Ｗｅｂサーバ３は、即時検索処理１０２、１０５に基づき、タイミング１１２で要求されることを予測した検索リクエストに対する検索処理に要する検索処理時間が予測時間１１３で示す長さとなることも予測する。これらの予測結果に基づいて、Ｗｅｂサーバ３は、予測した検索リクエストに対応するバッチ検索処理をタイミング１１４で開始するようにバッチ検索サーバ５のタスクスケジューラ（不図示）へ登録する。その後、タスクスケジューラは、予測に基づいて登録したバッチ検索処理を、検索リクエストが受信されると予測したタイミング１１２までに完了できるように実施することで、実際に検索リクエストを受信した際に即時の応答を可能とする。

［処理フロー］
図４は、本実施形態におけるＷｅｂサーバ３が実行する検索処理の流れを示すフローチャートである。図４は、図２および図３に示すタイミングチャートの動きを実現するための処理を示す。本処理は、Ｗｅｂサーバ３のＣＰＵがＲＯＭ等に格納されたプログラムを読み出し、実行することで実現される。

Ｓ１０００にてＷｅｂサーバ３は、クライアント２から検索リクエストを受信することで以降の処理を実行する。Ｓ１００１にて、Ｗｅｂサーバ３は、受信した検索リクエストに含まれるクエリをクエリ履歴データベース７へ記録する。本処理工程の詳細については、図９を用いて後述する。Ｓ１００２にて、Ｗｅｂサーバ３は、バッチ検索サーバ５へ、受信した検索リクエストに含まれるクエリに対応するバッチ検索処理の状態について問い合わせる。ここでの「対応する」とは、受信した検索リクエストに含まれるクエリと、登録されているバッチ検索処理のクエリとが一致することをいうものとする。そして、Ｗｅｂサーバ３は、問い合わせ結果に対する判定（Ｓ１００３〜Ｓ１００６）を行う。

問い合わせの結果、対応するバッチ検索処理が登録されていない場合、すなわち、バッチ検索サーバ５のタスクスケジューラにタスクが予約されていない場合（Ｓ１００３にてＮＯ）、Ｓ１００５に進む。Ｓ１００５にて、Ｗｅｂサーバ３は、受信した検索リクエストに含まれるクエリを用いて即時検索処理を実行する。

問い合わせの結果、対応するバッチ検索処理が登録されているが、当該バッチ検索処理がまだ開始していない場合（Ｓ１００３にてＹＥＳ、かつ、Ｓ１００４にてＮＯ）、Ｓ１００５に進む。この場合、Ｗｅｂサーバ３は、受信した検索リクエストに含まれるクエリを用いて即時検索処理を実行する。

問い合わせの結果、受信した検索リクエストに含まれるクエリに対応するバッチ検索処理が既に終了している場合（Ｓ１００３にてＹＥＳ、かつ、Ｓ１００４にてＹＥＳ、かつ、Ｓ１００６にてＹＥＳ）、Ｓ１００７へ進む。Ｓ１００７にて、Ｗｅｂサーバ３は、すでに処理が完了しているクエリに対応するバッチ検索処理の結果をバッチ検索サーバ５から取得する。

問い合わせの結果、受信した検索リクエストに含まれるクエリに対応するバッチ検索処理が既に開始しているが終了していない場合（Ｓ１００３にてＹＥＳ、かつ、Ｓ１００４にてＹＥＳ、かつ、Ｓ１００６にてＮＯ）、Ｓ１００８へ進む。Ｓ１００８にて、Ｗｅｂサーバ３は、処理中のバッチ検索処理の終了を待つ。その後、Ｗｅｂサーバ３は、バッチ検索処理の完了後に（Ｓ１００６にてＹＥＳ）、Ｓ１００７にて、そのバッチ検索処理の結果をバッチ検索サーバ５から取得する。

即時検索処理（Ｓ１００５）もしくはバッチ検索処理（Ｓ１００７）のいずれかが完了した後、Ｓ１００９にて、Ｗｅｂサーバ３は、取得した検索結果をクライアント２へ返却する。そして、Ｓ１０１０にて、Ｗｅｂサーバ３は、検索処理に要した時間を記録する。最後に、Ｓ１０１１にて、Ｗｅｂサーバ３は、以降に実行されるバッチ検索処理を予測し、その予測したバッチ検索処理をバッチ検索サーバ５のタスクスケジューラ（不図示）へ登録する。本工程における処理の詳細は、図１２を用いて後述する。そして、本処理フローを終了する。

［クエリの記録］
次にＷｅｂサーバ３が受信する検索リクエストに含まれるクエリとそのクエリの記録について説明する。図５は、本実施形態に係る検索対象データベース４に格納されているテーブル３００の構成例を示す。図５のテーブル３００において、横軸方向にテーブルのカラムを示し、縦軸方向にデータの各レコードを示す。図５において、最初の１行目は各カラムに格納されるデータの項目名を示している。本実施形態においては、図５のようにＴｅｎａｎｔＩＤ３０１、ＩｎｃｉｄｅｎｔＮｏ３０２、ＴａｓｋＮｏ３０３、Ｒｅｃｅｉｖｅｄ３０４、Ｒｅｓｐｏｎｄ３０５、ＤｏｗｎＴｉｍｅ３０６、などの項目を持つテーブルを例に挙げて説明を行う。なお、図５に示すテーブルのテーブル名は「ｉｎｃｉｄｅｎｔｌｏｇｓ」であるとする。

図６は、Ｗｅｂサーバ３が受信する検索リクエストに含まれるクエリの例と、そのクエリが記録されるときのデータ構造の例を示すデータ例の図である。例えば、
「受信日時（Ｒｅｃｅｉｖｅｄ）の値が２０１３年２月２５日から２０１３年３月２５日の間でダウンタイム（ＤｏｗｎＴｉｍｅ）が１時間を超えるインシデントログを取得する」
といった検索を行うためのクエリを含む検索リクエストは、図６（ａ）のＵＲＩ３１０にて示されるＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）となる。

ＵＲＩ３１０内のパラメータ３１１は、検索対象のテーブル名（「ｉｎｃｉｄｅｎｔｌｏｇｓ」）を示し、インシデントログを取得することを示す。また、ＵＲＩ３１０内のパラメータ３１２は、本実施形態における検索リクエストのクエリ文字列部分を表している。本実施形態において指定可能なクエリ文字列には、クエリ条件を詳細に指定するための演算子や関数を使用することが出来る。例えば、条件の論理積（ａｎｄ）や論理和（ｏｒ）をとるための論理演算子がサポートされる。また、指定された項目の値の範囲を指定するために「より大きい」（ｇｔ）や「以下」（ｌｅ）、「等しい」（ｅｑ）、等々の関係演算子がサポートされる。パラメータ３１２に示すクエリ文字列を解析すると、図６（ｂ）に示されるような、ノード３２０をルートとする、各ノードから構成される構文木が構成される。

ノード３２３、３２７、３２８から構成される部分木は、Ｒｅｃｅｉｖｅｄ３０４の値が「２０１３年２月２５日１２：００：００」よりも大きい（後の時間）という条件を表している。ノード３２４、３２９、３３０から構成される部分木は、Ｒｅｃｅｉｖｅｄ３０４の値が「２０１３年３月２５日１２：００：００」以下（以前の時間）という条件を表している。更に、ノード３２２、３２５、３２６から構成される部分木は、ＤｏｗｎＴｉｍｅ３０６の値が「３６００」よりも大きいという条件を表している。本実施形態において、ＤｏｗｎＴｉｍｅ３０６は秒単位であるものとし、したがって、ノード３２２、３２５、３２６から構成される部分木は、ダウンタイムが１時間を超える、という条件を表している。これらの論理積をとって上述のような検索条件を表すことになる。なお、検索条件についてはここに挙げたものに限定するものではなく、他の関係演算子や関数を利用可能にしてもよい。

Ｗｅｂサーバ３は、構文木を構成するノードから、日時指定項目の値を指定しているノードを抽出する。例えば、Ｒｅｃｅｉｖｅｄ３０４は日時指定項目であり、ＤｏｗｎＴｉｍｅ３０６は日時指定項目では無い。よって、図６（ｂ）の例において、日時指定項目の値を指定しているノードはノード３２８とノード３３０である。Ｗｅｂサーバ３は、ノード３２０〜３３０から構成される構文木から、図６（ｃ）に示すような記録用のクエリ文字列３４０を生成する。クエリ文字列３４０において、日時指定項目の値を指定しているノードであるノード３２８とノード３３０に対応する部分の記述は、値の置換用文字列である「｛＃１｝」と「｛＃２｝」に置き換えられている。さらに、Ｗｅｂサーバ３は、クエリ文字列３４０に対応する日時指定項目の値として、データ３４１を生成する。データ３４１において、値３４２は、前述の置換用文字列「｛＃１｝」に対応するＲｅｃｅｉｖｅｄ３０４の値「２０１３−０２−２５Ｔ１２：００：００」を示す。値３４３は、前述の置換用文字列「｛＃２｝」に対応するＲｅｃｅｉｖｅｄ３０４の値「２０１３−０３−２５Ｔ１２：００：００」を示す。

図７は、Ｗｅｂサーバ３が受信する別の検索リクエストに含まれるクエリの例と、そのクエリが記録される際のデータ構造の例を示す。図７（ａ）のＵＲＩ４００は、「受信日時（Ｒｅｃｅｉｖｅｄ）の値が２０１３年３月中でダウンタイム（ＤｏｗｎＴｉｍｅ）が１時間を超えるインシデントログを取得する」というクエリを含む例を示している。図７の例において、「２０１３年」、「３月」を判定するために、日時指定関数としてのｙｅａｒ関数（ノード４１７）およびｍｏｎｔｈ関数（ノード４１９）を使用している。

図８は、クエリ履歴データベース７に記録されるクエリデータの例である。図８において、受信日時３５０は、検索リクエストの受信日時を示す。ＵＲＩ３５１は、検索リクエストのＵＲＩのうち、クエリ文字列を除いた文字列を示す。クエリ文字列３５２は、記録用クエリ文字列を示す。日時指定３５３は、日時指定項目の値を示す。処理時間３５４は、検索クエリの処理に要する処理時間を示す。なお、図８における日時指定３５３の値は、図６に示すところの置換位置（置換用文字列）および日時指定項目を省略して図示している。図８において、レコード３５５、３５６、３５７に示す例では、クエリ文字列３５２が同一で、日時指定３５３の値が異なる３つの検索リクエストがなされたことを示している。

［クエリ記録処理］
図９は、Ｗｅｂサーバ３が実行する、図４におけるＳ１００１のクエリ記録処理の詳細を示すフローチャートである。

Ｓ１１０１にて、Ｗｅｂサーバ３は、図２や図３に示した検索リクエスト１００、１０３などを受信した日時を、図８の受信日時３５０に示すデータとして格納する。Ｓ１１０２にて、Ｗｅｂサーバ３は、クエリ文字列を解析し、図６に例示されるような構文木を生成する。Ｗｅｂサーバ３は、Ｓ１１０４〜Ｓ１１０９の繰り返し処理にて、生成した構文木の葉ノード（図６のノード３２５、３２６、３２７、３２８、３２９、３３０に対応する末端のノード）を順に検査する。まず、Ｓ１１０４にて、Ｗｅｂサーバ３は、検査する対象として注目する葉ノードが日時指定項目であるか否かを判定する。Ｗｅｂサーバ３は、検索対象データベース４に格納されている検索対象テーブル（図５）の項目に対する日時指定項目リスト（不図示）を保持しており、構文木のノードと当該リストの値を比較することで日時指定項目を特定する。図６に示す構文木の例では、Ｒｅｃｅｉｖｅｄ３０４が日時指定項目であるため、ノード３２７とノード３２９が日時指定項目のノードに該当する。ＤｏｗｎＴｉｍｅ３０６は日時指定項目では無いため、ノード３２５は日時指定項目のノードに該当しない。ノード３２６、３２８、３３０は値のノードであるため、日時指定項目のノードに該当しない。

注目している葉ノードが日時指定項目のノードの場合（Ｓ１１０４にてＹＥＳ）、Ｗｅｂサーバ３は、葉ノードから構文木を辿り、Ｓ１１０５〜Ｓ１１０９の処理を実施する。まず、Ｓ１１０５にて、Ｗｅｂサーバ３は、着目している葉ノードの親ノードが日時指定関数か否かを判定する。日時指定関数には、例えば、日時型データの項目から年を取り出すｙｅａｒ関数や、月を取り出すｍｏｎｔｈ関数などがある。Ｗｅｂサーバ３は、クエリ文字列において使用可能な関数および関数の種類（日時指定関数か否か）の一覧を保持している。親ノードが日時指定関数の場合（Ｓ１１０５にてＹＥＳ）、Ｓ１１０６にて、Ｗｅｂサーバ３は、注目ノードを親ノードへ移す。その後、Ｓ１１０７へ進む。一方、親ノードが日時指定関数でない場合（Ｓ１１０５にてＮＯ）、Ｓ１１０７へ進む。

更に、注目しているノードの親ノードが関係演算子であり、かつ、兄弟ノードが値である場合（Ｓ１１０７にてＹＥＳ、かつ、Ｓ１１０８にてＹＥＳ）、Ｓ１１０９にてＷｅｂサーバ３は、日時指定項目、数値ノードである兄弟ノードの位置と値を記憶する。その後、Ｓ１１１０へ進む。注目しているノードの親ノードでない場合（Ｓ１１０７）もしくは注目しているノードの兄弟ノードが値でない場合（Ｓ１１０８にてＮＯ）、Ｓ１１１０へ進む。

Ｓ１１１０にて、Ｗｅｂサーバ３は、全ての葉ノードに対するＳ１１０３〜Ｓ１１０９の処理が完了したか否かを判定する。未処理の葉ノードがある場合（Ｓ１１１０にてＮＯ）、Ｓ１１１１にてＷｅｂサーバ３は、次の未処理の葉ノードを注目ノードとしてＳ１１０４へ戻る。一方、全ての葉ノードに対する処理が完了した場合（Ｓ１１１０にてＹＥＳ）、Ｓ１１１２にて、Ｗｅｂサーバ３は、Ｓ１１０９にて記憶した情報を基に、図８に示すようにクエリ文字列と値を記録する。そして、本処理フローを終了する。

［検索リクエストの予測］
次にＷｅｂサーバ３が予測する検索リクエストについて説明する。図１０は、検索リクエストに含まれるクエリが指定するデータの時間範囲の関係を示したタイミングチャートである。図１０（ａ）において、検索対象期間２００は、検索リクエスト１００において指定されたクエリが検索条件として指定している時間指定項目の検索対象期間を表している。つまり、検索リクエスト１００に含まれるクエリは、タイミング２０３以降（矢印２０１）で、かつ、タイミング２０４以前（矢印２０２）の範囲を指定している。具体的には、図６の例に対応させると、検索対象期間２００はＲｅｃｅｉｖｅｄ３０４の指定範囲を示す。タイミング２０３は「２０１３−０２−２５Ｔ１２：００：００」のタイミングを示す。タイミング２０４は、「２０１３−０３−２５Ｔ１２：００：００」のタイミングを示す。

図１０（ｂ）は、さらに、同じ方法で３つの検索リクエストのタイミングを並べて示している。図１０（ｂ）において、検索対象期間の異なる、同じクエリ文字列の検索リクエストが３つ図示されている（検索リクエスト１００ａ、１００ｂ、１００ｃ）。タイミング２０３ａ、２０３ｂ、２０３ｃはそれぞれ、対応する検索リクエストの検索対象開始タイミングを示している。そして、検索対象開始タイミング間の間隔を間隔２１０と間隔２１１で示している。この場合において、間隔２１０と間隔２１１とが等間隔であると言うことは、タイミング２０３ａ、２０３ｂ、２０３ｃの日時指定が定期的であることを示す。本実施形態において、Ｗｅｂサーバ３は、クエリ文字列で指定された日時指定項目の条件指定が全て定期的である場合、定期的に同じ範囲条件の検索リクエストが登録されていると判定する。

［バッチ検索処理の登録処理］
図１１は、Ｗｅｂサーバ３が実行する、図４におけるＳ１０１１のバッチ検索処理の登録処理の詳細を示すフローチャートである。図１１に示す処理の中で、Ｗｅｂサーバ３は、検索リクエストのクエリの周期性判定も合わせて行う。

Ｓ１２０１にて、Ｗｅｂサーバ３は、クエリ履歴データベース７に記録されている過去の記録（図８）から、クエリ文字列３５２が今回のクエリ文字列と一致する過去のクエリを検索する。なお、クエリ文字列が一致するクエリをいくつデータベースから取り出すようにしてもよい。例えば、上限なく、クエリ履歴データベース７に記録されている、クエリ文字列が一致するすべてのクエリ記録を対象としても良い。また、図１０（ｂ）に示すように最近のクエリ記録から固定数（図１０（ｂ）に示す例では３つ）だけを対象としても良い。また、あるいは、上限を決めて、上限数までの全てのクエリを対象としても良い。ここでの固定数や上限数は予め定義され、Ｗｅｂサーバ３のＨＤＤ等に保持されているものとする。

クエリ文字列が一致する過去の検索リクエストがある場合（Ｓ１２０２にてＹＥＳ）、Ｗｅｂサーバ３は、Ｓ１２０３〜Ｓ１２１７の処理を図８の日時指定３５３に列挙される項目単位で順に実施する。Ｗｅｂサーバ３は、各項目について時間指定単位の粒度を順に上げながら、時間指定の周期性を確認する。ここで、時間指定単位の粒度とは、本実施形態において、周期性を判定する単位を指す。具体的には、「秒」→「分」→「時」→「日」→「月」→「年」の順を指す。Ｗｅｂサーバ３は、この順で、Ｓ１２０５〜Ｓ１２０９の処理を繰り返し、周期性が生じる粒度を探す。

Ｓ１２０８にて、Ｗｅｂサーバ３は、一番大きな粒度である「年」単位の比較まで実施したかを判定する。「年」単位までの比較が完了していない場合（Ｓ１２０８にてＮＯ）、Ｓ１２０９にて、Ｗｅｂサーバ３は、次に大きな粒度の比較を実施するように粒度を変更し、Ｓ１２０５へ戻って繰り返し処理を行う。一方、「年」単位までの比較が完了している場合（Ｓ１２０８にてＹＥＳ）、Ｓ１２１３へ進む。

Ｓ１２０５にて、Ｗｅｂサーバ３は、比較対象の複数クエリ間で現在の粒度における比較を行う。Ｗｅｂサーバ３は、周期性を判定するために、クエリ間で指定値を比較する処理を二段階で行う。１段階目は、Ｓ１２０６〜Ｓ１２０７で示される処理である。ここで、複数クエリ間で毎回同じ値が設定されている粒度である場合（Ｓ１２０６にてＹＥＳ）、Ｓ１２０７にて、Ｗｅｂサーバ３は、未来の検索リクエストにおいても同じ値がクライアント２から指定されると想定し、この同じ値を指定する。例えば、図８の例では、「秒」「分」「時」「日」の粒度まで、同じ値（２５日、１２：００：００）が指定されているため、バッチ検索リクエストにおいても「２５日、１２：００：００」が指定される。

２段階目は、Ｓ１２０６、Ｓ１２１０〜Ｓ１２１２で示される処理である。複数クエリ間で同じ値が設定されていない粒度である場合（Ｓ１２０６にてＮＯ）、Ｓ１２１０にて、Ｗｅｂサーバ３は、クエリ間の周期性判定を行う。ここでは、Ｗｅｂサーバ３は、現在判定中の粒度に揃えて、図１０で説明した周期性判定を行う。例えば、図８の例では、＃１、＃２についてそれぞれ、「月」「年」の指定を「月」単位に揃えて比較する。図８の例では、等間隔（毎月）であることが判定できるため、この粒度で等間隔であると判定して（Ｓ１２１１にてＹＥＳ）、Ｓ１２１２にてＷｅｂサーバ３は、以降の検索リクエストにおいても、翌月分が指定されると予測し、その予測に基づく値を生成する。そして、Ｓ１２１３へ進む。全ての間隔が等間隔でない場合（Ｓ１２１１にてＮＯ）、本処理フローを終了する。

一つの指定項目について周期性の判定が終了したら、Ｓ１２１３にてＷｅｂサーバ３は、他に比較すべき項目が残っているかを判定する。未処理の時間指定項目が残っている場合（Ｓ１２１３にてＮＯ）、Ｓ１２１４にて、Ｗｅｂサーバ３は、次の未処理の時間指定項目を対象としてＳ１２０４へ戻り、繰り返し処理を行う。

全ての時間指定項目について処理が完了した後（Ｓ１２１３にてＹＥＳ）、これらに周期性がある場合には、Ｗｅｂサーバ３は、予測したクエリ（以下、単に予測クエリ）をバッチ検索サーバ５のタスクスケジューラへ登録する（Ｓ１２１５〜Ｓ１２１７）。Ｓ１２１５にて、Ｗｅｂサーバ３は、クエリ履歴データベース７に記録されたクエリ受付時間の周期から、次の検索リクエストの受信日時を予測する。受付時間の周期から日時を予測する方法としては、例えば、図１１におけるＳ１２０４〜Ｓ１２１３と同様に時間指定単位の粒度ごとに判定しても良い。

また、Ｓ１２１６にて、Ｗｅｂサーバ３は、クエリ履歴データベース７に記録された各検索リクエストの検索処理時間（図４のＳ１０１０、図８の処理時間３５４）から、次の検索処理時間を予測する。予測方法としては、複数の処理時間の最大値を用いてもよいし、平均値を用いても良い。そして、Ｓ１２１７にて、Ｗｅｂサーバ３は、過去のクエリ文字列３５２と同じ、かつ、判定した周期性より生成した値を指定した予測クエリを、バッチ検索サーバ５のタスクスケジューラ（不図示）へ登録する。例えば、図８における、レコード３５７が今回記録したクエリであり、レコード３５５およびレコード３５６が過去に記録した同じ内容のクエリであるとする。この場合、予測クエリは、＃１が「２０１３−０５−２５Ｔ１２：００：００」、＃２が「２０１３−０６−２５Ｔ１２：００：００」となる。

バッチ検索サーバ５のタスクスケジューラ（不図示）に登録する予測されたクエリの実行時間は、図３のタイミング１１４で示した通り、Ｓ１２１５で予測した日時から、Ｓ１２１６で予測した処理時間を遡った日時とする。これによって予測した検索リクエストを受け付ける前に予めデータの検索を行うことができる。なお、同じクエリが記録から見つからない場合や、周期性が無かった場合には、予測クエリの登録は行わずに、本処理フローが終了する。

［タスクスケジュール］
図１２は、本実施形態におけるバッチ検索サーバ５のタスクスケジューラ（不図示）が管理するタスクスケジュールテーブルの例である。バッチ検索サーバ５は、Ｗｅｂサーバ３からの予測クエリの登録指示（図１１のＳ１２１７）に従って、開始予定時刻３８０、検索対象３８１、クエリ文字列３８２の値をそれぞれタスクスケジュールテーブルに保存する。

Ｗｅｂサーバ３が受信した検索リクエストに含まれるクエリと対応するバッチ検索処理のタスクが登録されていることを確認する場合（図４のＳ１００２、Ｓ１００３）、検索対象３８１とクエリ文字列３８２の値で判定する。

バッチ検索サーバ５は、ステータス３８３の値により、タスクの状態を管理する。例えば、ステータス３８３が「ｗａｉｔｉｎｇ」（待機中）である場合、検索処理は未開始である。ステータス３８３が「ｐｒｏｃｅｓｓｉｎｇ」（処理中）である場合、検索処理中である。ステータス３８３が「ｃｏｍｐｌｅｔｅｄ」（完了）である場合、検索処理は終了している。検索処理が終了している場合には、Ｗｅｂサーバ３は、検索結果データベース６に保持された結果データ３８５の情報から検索結果を取得することが出来る。Ｗｅｂサーバ３が、バッチ検索処理の状態を判定する場合（図４のＳ１００４、Ｓ１００６、Ｓ１００８）には、バッチ検索サーバ５を介して、ステータス３８３を確認する。処理時間３８４は、バッチ検索処理が完了した時に記録するタスクにかかった処理時間である。

［バッチ処理］
図１３は、バッチ検索サーバ５におけるタスクスケジューラ（不図示）と処理部（不図示）によるタスク実行の処理の詳細を示すフローチャートである。本処理フローは、バッチ検索サーバ５のＣＰＵがＲＯＭ等に記録されたプログラムを読み出して実行することにより実現される。

バッチ検索サーバ５は、タスクスケジューラ（不図示）により、図１２に例示するタスクスケジュールテーブルに登録されたタスクを順に処理する（Ｓ１３０１〜Ｓ１３１３）。Ｓ１３０１にて、バッチ検索サーバ５は、タスクスケジュールテーブルを読み込む。そして、バッチ検索サーバ５は、タスク毎にステータス３８３を確認する。タスクのステータスが「ｗａｉｔｉｎｇ」の場合（Ｓ１３０２にてＹＥＳ）、バッチ検索サーバ５は、Ｓ１３０３〜Ｓ１３０５の処理を行う。タスクのステータスが「ｐｒｏｃｅｓｓｉｎｇ」の場合（Ｓ１３０６にてＹＥＳ）、バッチ検索サーバ５は、Ｓ１３０７〜Ｓ１３０９の処理を行う。タスクのステータスが「ｃｏｍｐｌｅｔｅｄ」の場合（Ｓ１３１０にてＹＥＳ）、バッチ検索サーバ５は、Ｓ１３１１〜Ｓ１３１２の処理を行う。

ステータスが「ｗａｉｔｉｎｇ」の時に、タスクの開始予定時刻３８０を過ぎている場合（Ｓ１３０３にてＹＥＳ）、Ｓ１３０４にて、バッチ検索サーバ５は、検索対象３８１とクエリ文字列３８２の内容に従って、タスクの開始を処理部（不図示）へ指示する。この指示を図１３において、破線にて示す。なお、開示予定時刻を過ぎていない場合には（Ｓ１３０３にてＮＯ）、Ｓ１３０６へ進む。各タスクに対応するバッチ検索処理（Ｓ１３２１〜Ｓ１３２３）を並行して進める一方、Ｓ１３０５にて、バッチ検索サーバ５は、実行を開始したタスクのステータス３８３を「ｐｒｏｃｅｓｓｉｎｇ」に更新する。その後、Ｓ１３０６へ進む。なお、本実施形態において、各タスクに対する処理が完了した場合、処理部（不図示）からタスクスケジューラ（不図示）にその旨および処理に要した時間が通知されるものとする。この通知を図１３において、破線にて示す。

タスクのステータスが「ｐｒｏｃｅｓｓｉｎｇ」であり、かつ処理が完了していた場合（Ｓ１３０６にてＹＥＳ、かつ、Ｓ１３０７にてＹＥＳ）、Ｓ１３０８にて、バッチ検索サーバ５は、タスクのステータス３８３を「ｃｏｍｐｌｅｔｅｄ」に更新する。そして、Ｓ１３０９にて、バッチ検索サーバ５は、バッチ検索処理に要した処理時間をタスクスケジュールテーブルの処理時間３８４に記録する。なお、タスクが完了していない場合には（Ｓ１３０７にてＮＯ）、Ｓ１３１０へ進む。

Ｓ１３１１にて、バッチ検索サーバ５は、処理が完了しているタスク（ステータスが「ｃｏｍｐｌｅｔｅｄ」のタスク）について、予め定義された所定時間が経過したか否かを判定する。所定時間が経過している場合（Ｓ１３１１にてＹＥＳ）、Ｓ１３１２にて、バッチ検索サーバ５は、検索結果データベース６の検索結果データ及びタスクスケジュールテーブル（図１２）における当該タスクのデータを削除する。その後、Ｓ１３１３に進む。

Ｓ１３１３にて、バッチ検索サーバ５は、タスクスケジュールテーブルにて登録されている次のタスクに注目し、Ｓ１３０２に戻って処理を繰り返す。

一方、タスクスケジューラからの指示（Ｓ１３０４）に基づいて処理部にて実行されるタスクに対し、バッチ検索処理（Ｓ１３２２）が完了すると、Ｓ１３２３にて、バッチ検索サーバ５は、検索結果データベース６に検索結果を格納する。バッチ検索サーバ５は、ここから完了した検索結果を、検索リクエストに対する応答としてＷｅｂサーバ３へ渡す。

以上述べたように、バッチ検索処理を予め実行し、検索結果を保存しておくことにより、検索リクエストに対して検索処理による待ち時間を抑えつつ、検索結果を返すことが出来る。この結果、検索システムもクライアントシステムも、ステートレスで標準的なインターフェースのまま連携システムの性能を維持することが可能となる。

ＭＰＳにおいて、検索リクエストが求めるデータは、検索リクエストが来るタイミングから見ると時間を遡ったデータを取得することになるため、予めバッチ検索処理を実行しておくことが有効となる。また、検索履歴におけるクエリ条件で指定されている時間指定からクエリ条件の周期性を判定して次のクエリ条件を決定することにより、動的にバッチ検索処理を生成することが出来る。したがって、クライアントのクエリ特性に依存することなく、標準的なインターフェース仕様を維持することが可能となる。

なお、本実施形態では、次の検索リクエストのみを予測した例を示したが、これに限られず、まとめて複数の検索リクエストを予測するようにしても構わない。

＜第二の実施形態＞
第二の実施形態として、直近で受け付けた検索リクエストの日時項目の粒度および処理時間に着目して次回の検索リクエストの予測を可能とする方法について説明する。第二の実施形態については、第一の実施形態と基本的な構成が同じであるため、第一の実施形態との差異についてのみ説明する。第二の実施形態におけるＷｅｂサーバ３は、前述の図７に示すクエリを処理する。

図１４は、第二の実施形態におけるＷｅｂサーバ３が実行する、図４におけるＳ１０１１のバッチ検索処理登録の詳細を示すフローチャートである。図１４に示す処理は、第一の実施形態における図１１に示す処理に相当する。

Ｓ１４０１にて、Ｗｅｂサーバ３は、今回のクエリの指定項目の中で最も時間単位の粒度が細かい単位を選択する。図７の例において、時間単位の指定項目は、パラメータ４３２（「年」）とパラメータ４３３（「月」）であり、最も時間単位の粒度が細かい単位は「月」である。したがって、Ｗｅｂサーバ３は、この単位を記憶する（Ｕ＝「月」とする）。

Ｓ１４０２にて、Ｗｅｂサーバ３は、今回のクエリの中で、Ｕと同じ単位の時間指定パラメータを全てインクリメントする。図７の例において、Ｕと同じ単位の時間指定パラメータはパラメータ４３３だけであるため、「３」を１インクリメントして「４」とする。繰り上がりがある場合には、次に小さい粒度の単位の値も更新する。例えば、「１２月」を１インクリメントすると、「１月」になる。これに伴って、次に小さい粒度の単位である「年」の値も１インクリメントされる。このようにして、Ｗｅｂサーバ３は、予測クエリの指定値を生成する。

Ｓ１４０３にて、Ｗｅｂサーバ３は、今回クエリを受け付けた時間におけるＵの単位の値を１インクリメントし、次回クエリの予測受付時間とする。図７の例では、翌月（「４月」）の同じ日時を予測受付日時とする。Ｓ１４０４にて、Ｗｅｂサーバ３は、次の検索処理にも今回と同じ時間がかかると想定する。そして、Ｓ１４０５にて、Ｗｅｂサーバ３は、Ｓ１４０３にて予測した受付時間から、Ｓ１４０４にて想定した処理時間の分だけ遡った日時に予測クエリの検索処理を登録する。そして本処理フローを終了する。

以上述べたように、検索条件から次回の検索処理を予測して、バッチ検索処理を登録しておけば、２回目以降の検索クエリからバッチ処理による応答時間改善効果が得られる。つまり、第二の実施形態によれば、第一の実施形態のように複数回の検索履歴が記録されるまで待たずに、応答時間改善効果が得られる。仮に周期性の無い（単発の）クエリだった場合には、バッチ検索結果は所定時間の経過後に破棄される（図１３のＳ１３１２）。第一の実施形態の周期性判定と組み合わせて、検索履歴から周期性のある検索履歴が見つからなかった場合には、第二の実施形態に示す方法でバッチ検索処理を登録するようにしてもよい。

＜その他の実施形態＞
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (11)

1. 検索条件が指定された検索リクエストを受け付ける受付手段と、
   前記検索条件に従ってデータの検索を実行し、検索結果を当該検索リクエストに対して応答する検索手段と、
   前記受付手段にて受け付けた検索リクエストを記録する記録手段と、
   前記記録手段にて記録された検索リクエストに基づき、以降の検索リクエストを受け付けるタイミングと検索条件とを予測する予測手段と、
   前記予測手段にて予測した検索リクエストのタイミングと検索条件とに従って、前記以降の検索リクエストを受け付ける前に、前記データの検索を行って検索結果を取得する取得手段と
   を有し、
   前記検索手段は、前記予測手段にて予測した検索リクエストに対応する検索リクエストを前記受付手段が受け付けた場合、当該受け付けた検索リクエストによるデータの検索を実行する代わりに、前記取得手段にて取得された検索結果を用いて応答することを特徴とする検索システム。
2. 前記予測手段は、前記受付手段にて検索リクエストを受信するタイミングの周期性に基づいて以降の検索リクエストを受信するタイミングを予測することを特徴とする請求項１に記載の検索システム。
3. 前記予測手段は、前記受付手段にて受け付けた検索リクエストに含まれる検索条件の周期性に基づいて以降の検索リクエストにおける検索条件を予測することを特徴とする請求項１または２に記載の検索システム。
4. 前記検索条件は、データが記録された日時の指定を含み、
   前記予測手段は、前記検索条件に含まれる日時の指定において、粒度が小さい単位から順に周期性の判定を行うことを特徴とする請求項３に記載の検索システム。
5. 前記取得手段は、前記予測手段にて予測した検索リクエストに対応する検索リクエストを前記受付手段が受け付けるまでに、当該予測した検索リクエストの処理が完了するように検索を開始することを特徴とする請求項１乃至４のいずれか一項に記載の検索システム。
6. 前記記録手段は更に、前記検索手段にて実行した検索リクエストの処理時間を当該検索リクエストに対応づけて記録し、
   前記予測手段は、前記記録手段が記録している処理時間に基づいて、前記予測した検索リクエストの処理時間を予測し、当該予測した処理時間から前記取得手段が前記予測した検索リクエストの実行を開始する時間を決定することを特徴とする請求項５に記載の検索システム。
7. 前記予測手段は、前記記録手段に記録された１または複数の検索リクエストに基づいて、以降の検索リクエストを予測することを特徴とする請求項１乃至６のいずれか一項に記載の検索システム。
8. 前記予測した検索リクエストを前記取得手段が実行している間に当該予測した検索リクエストに対応する検索リクエストを前記受付手段が受信した場合、前記検索手段は、当該実行している処理の完了した後に、当該処理の検索結果を用いて応答することを特徴とする請求項１乃至７のいずれか一項に記載の検索システム。
9. 前記取得手段は、前記予測した検索リクエストの検索結果は所定の時間が経過した後に削除することを特徴とする請求項１乃至８のいずれか一項に記載の検索システム。
10. 検索条件が指定された検索リクエストを受け付ける受付工程と、
    前記検索条件に従ってデータの検索を実行し、検索結果を当該検索リクエストに対して応答する検索工程と、
    前記受付工程にて受け付けた検索リクエストを記録部に記録する記録工程と、
    前記記録部に記録された検索リクエストに基づき、以降の検索リクエストを受け付けるタイミングと検索条件とを予測する予測工程と、
    前記予測工程にて予測した検索リクエストのタイミングと検索条件とに従って、前記以降の検索リクエストを受け付ける前に、前記データの検索を行って検索結果を取得する取得工程と
    を有し、
    前記検索工程において、前記予測工程にて予測した検索リクエストに対応する検索リクエストを前記受付工程が受け付けた場合、当該受け付けた検索リクエストによるデータの検索を実行する代わりに、前記取得工程にて取得された検索結果を用いて応答することを特徴とする検索システムの制御方法。
11. コンピュータを、
    検索条件が指定された検索リクエストを受け付ける受付手段、
    前記検索条件に従ってデータの検索を実行し、検索結果を当該検索リクエストに対して応答する検索手段、
    前記受付手段にて受け付けた検索リクエストを記録する記録手段、
    前記記録手段にて記録された検索リクエストに基づき、以降の検索リクエストを受け付けるタイミングと検索条件とを予測する予測手段、
    前記予測手段にて予測した検索リクエストのタイミングと検索条件とに従って、前記以降の検索リクエストを受け付ける前に、前記データの検索を行って検索結果を取得する取得手段
    として機能させ、
    前記検索手段は、前記予測手段にて予測した検索リクエストに対応する検索リクエストを前記受付手段が受け付けた場合、当該受け付けた検索リクエストによるデータの検索を実行する代わりに、前記取得手段にて取得された検索結果を用いて応答することを特徴とするプログラム。

Images