JP4733458B2 - 検索システム及び検索方法 - Google Patents

Description

本発明は、検索システム及び検索方法に関する。

検索システムは、データベースに登録された多量のデータ群の中から、検索条件に合致するデータを抽出する。通常の場合、検索要求は先着順で処理されるため、複数の検索要求が競合する場合、検索システムの応答性は低下する。そこで、複数のデータベースを用意し、各データベースに検索を分散させることにより、応答性を改善することも行われている（特許文献１）。
特開平６−１１９３８３号公報

上記文献に記載のように、一般的な検索システムでは、検索待ち時間の短縮や応答時間の改善を目的とする。しかし、応答性の速さよりも、より確実に検索結果を入手できることの方が要求される場合もある。検索時間が多少長くても、その検索結果をほぼ確実に得られるのであれば、ユーザは、要求した検索結果が出るまでの間に、別の作業を行うことができる。

そこで、本発明の目的は、検索の成功率を向上できるようにした検索システム及び検索方法を提供することにある。本発明の他の目的は、検索結果の入手可能性を高めると共に、使い勝手を改善した検索システム及び検索方法を提供することにある。本発明のさらなる目的は、後述する実施形態の記載から明らかになるであろう。

上記課題を解決すべく、本発明の一つの観点に従う検索システムは、クライアントコンピュータからの検索要求に基づいて、検索対象データベースを検索して検索結果を出力する検索システムであって、クライアントコンピュータから受信した第１検索要求を、所定の複数個の第２検索要求に分割して管理用データベースにそれぞれ登録させる検索登録手段と、管理用データベースに登録された各第２検索要求を、複数回に分けて全て選択し、各回毎にそれぞれ検索実行を指示する検索スケジュール管理手段と、検索スケジュール管理手段からの指示に基づいて、検索対象データベースを検索し、その検索結果を出力する検索実行手段と、検索実行手段から出力された検索結果を記憶する検索結果記憶手段と、を備える。

クライアントコンピュータからは、一つまたは複数の検索条件及び検索範囲が指定された第１検索要求が入力される。検索登録手段は、第１検索要求を所定の複数個の第２検索要求に分割し、これら各第２検索要求を管理用データベースにそれぞれ登録する。検索スケジュール管理手段は、管理用データベースに登録された各第２検索要求を、複数回に分けて全て選択する。例えば、第２検索要求の数が９個である場合、検索スケジュール管理手段は、一回に３個ずつの第２検索要求を選択して検索実行を指示する。検索実行手段は、検索スケジュール管理手段からの指示に基づき、選択された第２検索要求について検索対象データベースを検索し、その検索結果を出力する。出力された検索結果は、検索結果記憶手段に登録される。

一つの実施形態では、検索実行が指示されたにも拘わらず、検索実行手段による検索結果が得られなかった第２検索要求がある場合、この未処理の第２検索要求は、検索登録手段によって再度分割され、管理用データベースに登録される。検索結果が得られなかった場合としては、例えば、タイムアウトやエラーの発生を挙げることができる。

ここで、例えば、タイムアウトによる検索失敗のように、検索に要する負荷が大きいために検索が失敗したような場合に、第２検索要求をさらに分割して再検索を試みる。検索範囲をさらに小さくして一つ一つの検索の負荷を少なくすることにより、検索の成功率を高めることができるためである。これに対し、例えば、検索の負荷との関連が乏しいエラーによって検索結果を得られなかった場合、第２検索要求のさらなる分割を行わず、そのまま検索を中止または中断させることができる。つまり、検索の負荷と検索の成功との間に関連性のある場合は、検索の失敗した検索要求を再分割して管理用データベースに登録することができる。

さらに分割された第２検索要求は、検索スケジュール管理手段によって選択され、その検索実行が指示される。なお、分割された第２検索要求のいずれか一つがタイムアウト等によって検索した場合、この分割された第２検索要求をさらに分割して管理用データベースに登録することもできる。

一つの実施形態では、検索実行手段は、検索スケジュール管理手段から指示された各第２検索要求の検索をそれぞれ個別に実行する検索手段を複数個備えており、検索スケジュール管理手段により各回毎に選択される第２検索要求の数は、検索手段の数以下に設定されている。即ち、複数の検索手段をそれぞれ用いて、複数の第２検索要求を並列的に処理することができる。

一つの実施形態では、各第２検索要求の検索範囲が略等しくなるように予め定義された分割定義ファイルを備え、検索登録手段は、分割定義ファイルを参照することにより、第１検索要求を各第２検索要求に分割して管理用データベースにそれぞれ登録させる。

一つの実施形態では、第１検索要求には、検索実行時期を予め指定する実行時期情報が含まれており、検索スケジュール管理手段は、実行時期情報に示された時期が到来した場合に、第１検索要求を分割してなる各第２検索要求を、所定の複数回に分けて全て選択し、各回毎にそれぞれ検索実行を指示する。

一つの実施形態では、第１検索要求には、検索が途中で中止された場合に続行を希望するか否かを示す続行指定情報が含まれており、検索スケジュール管理手段は、続行指定情報によって続行が指定されている第１検索要求を分割してなる各第２検索要求を、他の第２検索要求よりも優先して、所定の複数回に分けて全て選択し、各回毎にそれぞれ検索実行を指示する。

一つの実施形態では、検索実行手段によって検索が行われている直近の第２検索要求の検索開始時刻と、予め設定される第２検索要求の処理基準時間と、検索スケジュール管理手段が未処理の第２検索要求について検索実行の指示を発行する回数とに基づいて、第１検索要求の検索終了時刻を予測する終了時刻予測手段を備え、処理基準時間は、各第２検索要求のうち検索の終了した第２検索要求の処理時間に基づいて修正される。

一つの実施形態では、検索スケジュール管理手段は、各回毎に、各第２検索要求のうち未処理の第２検索要求を１〜ｎ（ｎは２以上の自然数）個選択して検索実行を指示するようになっており、終了時刻予測手段は、（１）各未処理の第２検索要求について検索スケジュール管理手段から発行される検索実行指示の回数をBN、検索スケジュール管理手段から検索実行の指示が新たに発行される次検索開始時刻をTN、処理基準時間をtsとしたときに、（２）各未処理の第２検索要求の総数をｎで除算した値を切り上げてBNを求め、（３）検索が行われている直近の第２検索要求の検索開始時刻TLに処理基準時間tsを加算して次検索開始時刻TNを求め、（４）検索終了時刻TEを、TE＝TN＋（BN×ts）として算出する。

一つの実施形態では、検索実行手段から出力された検索結果を記憶する検索結果記憶手段を備え、検索実行手段は、各第２検索要求の検索を終了した場合に、その旨を管理用データベースに登録し、クライアントコンピュータは、管理用データベースに基づいて、検索結果記憶手段から検索結果を取得する。

本発明の他の観点に従う検索方法は、クライアントコンピュータからの検索要求に基づいて、検索対象データベースを検索して検索結果を出力する検索方法であって、クライアントコンピュータから第１検索要求を受信する受信ステップと、受信された第１検索要求をｎ×ｍ（ｎ，ｍはいずれも２以上の自然数）個の第２検索要求に分割し、管理用データベースにそれぞれ登録させる分割登録ステップと、管理用データベースに登録された各第２検索要求を、各回毎に、それぞれ１〜ｎ個の範囲内で選択して検索実行を指示する指示ステップと、検索実行が指示された各第２検索要求について、それぞれ検索対象データベースの所定範囲を検索することにより並列処理で検索を行う検索ステップと、検索が正常に終了した場合に、その検索結果を記憶させる記憶ステップと、を含む。さらに、検索ステップの次に、検索が正常に終了しなかった場合に、その第２検索要求を分割して管理用データベースに再登録させる再登録ステップと、を含ませることもできる。

本発明の機能、手段、ステップの全部または一部は、例えば、マイクロコンピュータにより実行されるコンピュータプログラムとして構成可能な場合がある。そして、このコンピュータプログラムは、例えば、ハードディスク、光ディスク、半導体メモリ等の記憶媒体に固定して配布することができる。または、コンピュータプログラムをインターネット等の通信ネットワークを介して、配信することもできる。

以下、図面に基づいて、本発明の実施形態を説明する。図１は、本実施形態に係る検索システムの全体構成を示すブロック図である。詳細はさらに後述するが、本実施形態では、検索クライアント１０から入力された検索要求をｎ×ｍ個の検索要求に分割し、ｎ個ずつの検索をｍ回に分けて行う。即ち、本実施形態では、検索要求を分割して多段階で並列処理する。そして、例えばタイムアウト等によって、いずれか一つまたは複数の検索が行われなかった場合、その未検索部分をさらに分割して、多段階で並列処理する。

これにより、本実施形態では、一つ一つの検索を小さくして検索負荷を減少させることができるため、検索の成功率を高めることができる。また、検索が行われなかった部分は、再度分割して多段階の並列処理を行うため、最終的な検索の成功率を向上させることができ、検索システムの信頼性が改善される。

図１を参照して検索システムの全体構成を説明する。この検索システムは、例えば、検索クライアント１０と、検索サーバ２０とを含んで構成可能である。先に図２を参照すると、例えば、各店舗、各事業所、各部署等の組織単位１（以下、総称して「部店」と呼ぶ）には、それぞれ一つまたは複数の検索クライアント１０が設けられている。

これら各検索クライアント１０は、例えば、LAN（Local Area Network）２を介して、通信ネットワーク３にそれぞれ接続されており、通信ネットワーク３を介して検索サーバ２０に接続される。通信ネットワーク３としては、例えば、インターネットや専用回線等を使用することができる。なお、LAN３を介さずに、通信ネットワーク３を介して直接検索サーバ２０に接続させる構成でもよい。

図１に戻る。検索クライアント１０は、例えば、パーソナルコンピュータ、ワークステーション、携帯情報端末、携帯電話等のコンピュータ装置から構成可能である。その構成は後述するが、検索クライアント１０は、検索サーバ２０に検索要求を発行し、その検索結果を検索サーバ２０から取得するようになっている。

検索サーバ２０は、検索クライアント１０からの検索要求に応じて検索対象データベース２５０を検索し、その検索結果を出力するコンピュータ装置である。検索サーバ２０は、例えば、検索登録部２１０と、検索スケジューラ２２０と、検索実行部２３０と、終了時刻予測部２４０と、検索対象データベース２５０と、検索状況管理データベース２６０と、検索結果記憶部２７０と、分割定義記憶部２８０と、再分割定義記憶部２９０と、を備えて構成することができる。

検索クライアント１０は、検索条件及び検索範囲等を指定して、検索サーバ２０に検索要求を発行する（Ｓ１）。検索登録部２１０は、検索クライアント１０から入力された検索要求を検索状況管理データベース２６０に登録するものである。検索登録部２１０は、分割定義記憶部２８０の記憶内容を参照することにより（Ｓ２）、検索クライアント１０から入力された検索要求を所定数の検索要求に分割して、検索状況管理データベース２６０に登録させる（Ｓ３）。また、検索登録部２１０は、タイムアウト等によって検索が行われなかった場合、その実行されなかった検索要求をさらに分割して、検索状況管理データベース２６０に再登録させる。再分割に際しては、再分割定義記憶部２９０の記憶内容が参照される。なお、説明の便宜上、分割前の検索要求を「親検索要求」、分割された検索要求を「子検索要求」、子検索要求をさらに分割したものを「孫検索要求」と、それぞれ呼ぶ場合がある。

検索スケジューラ２２０は、検索処理のスケジューリングを制御するものである。検索スケジューラ２２０は、検索登録部２１０とは非同期で作動し、定期的にまたは不定期に、検索状況管理データベース２６０を確認する（Ｓ４）。検索スケジューラ２２０は、検索状況管理データベース２６０に未実行の検索要求（実行待ち状態の検索要求）を発見すると、これらの分割された検索要求を１つまたは複数選択する。検索スケジューラ２２０は、選択した検索要求について検索実行を指示する（Ｓ５）。

検索実行部２３０は、検索対象データベース２５０への検索を実行するものであり、複数の検索部２３１を備えている。検索実行部２３０は、検索スケジューラ２２０から検索実行を指示されると、要求された検索に必要な検索部２３１を所定数確保する。各検索部２３１は、それぞれ個別に検索を行う。即ち、分割された一つの検索要求（一つの子分割要求）は一つの検索部２３１によって実行され、その結果が出力される。検索スケジューラ２２０は、空いている検索部２３１の数を把握しており、この使用可能な検索部２３１の数に基づいて、検索実行を指示する。

検索実行部２３０による検索結果は、検索結果記憶部２７０に記憶される（Ｓ７）。各検索要求の処理結果は、各検索要求毎の検索結果ファイル２７１として、検索結果記憶部２７０にそれぞれ記憶される。検索実行部２３０は、検索状況管理データベース２６０にアクセスし、検索が終了した検索要求のステータスを「実行待ち」から「実行中」を経て「実行完了」に変更させる。

検索クライアント１０は、検索状況管理データベース２６０を定期的にまたは不定期に参照しており、要求した検索が完了したか否かを監視している（Ｓ８）。そして、検索の終了を発見すると、検索結果記憶部２７０から各検索結果ファイル２７１をそれぞれ取得する（Ｓ９）。検索クライアント１０は、各検索結果ファイル２７１を一つのファイルに結合させて、端末画面に表示させることができる。

終了時刻予測部２４０は、検索クライアント１０から入力された検索要求の終了時刻を予測するものである。予測された終了時刻は、検索状況管理データベース２６０に記憶される。従って、検索クライアント１０は、検索状況管理データベース２６０を参照することにより、検索の予定終了時刻を知ることができる。本実施例では、後述のように、所定数に分割された各検索要求を多段階で並列的に処理するため、各段階毎に、予定終了時刻を修正可能である。

図３は、検索システムのハードウェア構成の概要を示す構成説明図である。上述したように、検索クライアント１０及び検索サーバ２０は、それぞれコンピュータ装置として構成される。

検索クライアント１０は、例えば、CPU（Central Processing Unit）等からなる情報処理部１１と、半導体メモリやハードディスクドライブ等からなる記憶部１２と、通信インターフェース（以下「I／F」）１３とを備えることができる。情報処理部１１は、例えば、検索要求プログラム１１１と、検索結果表示プログラム１１２とをそれぞれ実行する。各プログラム１１１，１１２は、記憶部１２からシステムメモリにロードされて、それぞれ実行される。

検索要求プログラム１１１は、ユーザから指定された検索条件及び検索範囲と幾つかのオプション指定とに基づいて、検索要求を生成する。生成された検索要求は、I／F１３から通信ネットワーク３等を介して、検索サーバ２０に送信される。

検索結果表示プログラム１１２は、定期的または不定期に検索状況管理データベース２６０にアクセスして検索の状況を確認し、検索結果記憶部２７０から検索結果ファイル２７１をそれぞれ取得する。検索結果表示プログラム１１２は、取得した検索結果ファイル２７１をそのままで、あるいは複数の検索結果ファイル２７１を連結させて、検索クライアント１０の端末画面に表示させる。

検索サーバ２０も検索クライアント１０と同様に、情報処理部２１と、記憶部２２とを備えて構成することができる。情報処理部２１は、例えば、検索登録プログラム２１０Ｐと、検索スケジューラプログラム２２０Ｐと、検索プログラム２３０Ｐと、終了時刻予測プログラム２４０Ｐとを、それぞれ実行する。これら各プログラム２１０Ｐ〜２４０Ｐは、図１中の各機能２１０〜２４０にそれぞれ対応する。

記憶部２２には、例えば、分割定義ファイル２８１と、再分割定義ファイル２９１と、検索状況管理データベース２６０と、検索結果ファイル２７１と、検索対象データベース２５０とが、それぞれ記憶されている。

ここで、分割定義ファイル２８１は、検索要求を分割するための条件を規定するファイルである。また、再分割定義ファイル２９１は、タイムアウト等の所定の原因で検索が実行されなかった検索要求（子検索要求）を、再度分割するための条件を規定するファイルである。なお、図２中では、一つの記憶部２２内に各定義ファイル２８１，２９１やデータベース２５０，２６０等を一緒に格納するかのように示しているが、物理的または論理的に異なる複数の記憶領域に各ファイル２８１，２９１やデータベース２５０，２６０等を分散させて記憶させることもできる。

図４は、検索クライアント１０から発行された検索要求が、検索サーバ２０によって受け付けられる様子を模式的に示す説明図である。検索クライアント１０の端末画面には、検索条件や検索範囲を指定するためのユーザインターフェース画面が表示される。ユーザが、この画面上で所望の条件を指定して検索要求の発行を指示すると、検索要求Ｄ１０が検索サーバ２０に送信される。

検索要求Ｄ１０は、例えば、検索条件Ｄ１１と、検索範囲Ｄ１２と、続行指定情報Ｄ１３と、実行予定日Ｄ１４と、優先度Ｄ１５とを含むことができる。また、検索要求Ｄ１０には、所定のヘッダが付加されており、このヘッダには、例えば、送信元アドレス、受信先アドレス、データ長等が格納されている。

検索条件Ｄ１１は、例えば、「３０代男性顧客による過去３ヶ月間の取引額」等のように、一つまたは複数の条件を含んで構成される。検索範囲Ｄ１２は、検索対象データベース２５０のうち検索する範囲を示す。検索範囲としては、例えば、「全範囲」、「エリアコード」、「部店コード」を挙げることができる。「全範囲」とは、検索対象データベース２５０の全体を検索させるものである。「エリアコード」とは、検索対象データベース２５０に記憶されている内容のうち、エリアコードで特定されたエリアに属するデータ群のみを検索させるものである。例えば、北海道地区、東北地区、関東地区、近畿地区、中国四国地区、九州・沖縄地区等のように広範囲のエリアを指定するためのコードや、例えば、札幌地区、東京地区、名古屋地区、千代田地区等のように、行政区画レベルで指定するコードを予め用意しておくことができる。「部店コード」とは、全国に散在する各店舗、事業所、部署を個別に指定するためのコードである。

続行指定情報Ｄ１３とは、検索サーバ２０による検索サービスの提供時間内に検索が完了しなかった場合、翌日（または後日）にその続行を希望するか否かを指定するための情報である。続行指定情報Ｄ１３に「有り」が設定されている場合、中断された検索は、その後に到来する最新の検索可能日に実行される。例えば、検索サービスの提供時間帯が平日の午前９時〜午後９時である場合、金曜日の午後９時直前に発行された検索要求は、サービス時間の終了によって中断される。この中断された検索要求は、週明けの月曜日の午前９時頃に自動的に実行される。

実行予定日Ｄ１４は、その検索要求を処理すべき日時を指定する情報である。実行予定日Ｄ１４は、例えば、「2005/07/01 09:00」のように、西暦年月日時分秒の形式で指定することができる。

優先度Ｄ１５は、その検索要求の優先度を示す情報である。優先度のランクとしては、例えば、「通常」及び「緊急」を挙げることができる。通常の優先度の場合は、先入れ先出し方式（先着順）で順番に処理される。「緊急」の優先度の場合は、その発行順序を問わず、他の通常の検索要求に優先して処理される。なお、緊急の優先度を有する検索要求が競合した場合、先に発行されたものから処理される。

検索サーバ２０は、検索クライアント１０から入力された検索要求Ｄ１０を受信して受け付け（Ｓ１１）、発行元の端末を確認する（Ｓ１２）。検索サーバ２０は、検索要求Ｄ１０のヘッダに含まれる発行元アドレスを参照することにより、その検索要求がいずれの部店１から発行されたものであるかを確認することができる。また、検索サーバ２０は、検索要求Ｄ１０を受信した日時を確認する（Ｓ１３）。

そして、検索サーバ２０は、検索識別コード（ＩＤ）を発行する（Ｓ１４）。検索識別コードＤ２０は、例えば、発行元部店コードＤ２１と、検索要求日時（検索要求受信日時）Ｄ２２と、連続番号Ｄ２３とを含んで構成することができる。発行元部店コードＤ２１は、その検索要求Ｄ１０が発行された部店１を特定するためのコードである。検索システム内において、発行元部店コードＤ２１は一意に設定される。検索要求日時Ｄ２２とは、その検索要求Ｄ１０を検索サーバ２０が受信した日時を示す情報である。受信日時は、検索サーバ２０内のタイマや外部の時計サーバから取得することができる。連続番号Ｄ２３とは、各検索要求毎に連続して付与される番号を示す。検索クライアント１０は、検索サーバ２０から返信された検索識別コードＤ２０を記憶部１２に記憶させる。以後、検索クライアント１０は、検索識別コードＤ２０を検索キーに使用して、検索状況管理データベース２６０や検索結果記憶部２７０内を検索することができる。

検索サーバ２０は、検索識別コードＤ２０を発行した後、検索要求をｎ×ｍ個の検索要求（子検索要求）に分割し、各子検索要求にそれぞれ枝番を設定する（Ｓ１５）。分割された検索要求は、検索状況管理データベース２６０に記憶される。

図５は、検索対象データベース２５０の記憶内容を模式的に示す説明図である。ここで、検索対象データベース２５０とは、検索の対象となるデータ群を記憶したデータベースを意味する。検索対象データベース２５０には、一つまたは複数種類のデータベースを含めることができる。

図５に示す例では、顧客属性データベース２５１と、顧客取引データベース２５２との２種類のデータベースが含まれている。顧客属性データベース２５１は、例えば、部店コードと、口座ＩＤと、氏名と、住所と、その他の属性情報等とをそれぞれ対応づけることにより構成される。その他の属性情報としては、例えば、性別、年齢、連絡先電話番号、連絡先電子メールアドレス、職業、勤務先住所等を挙げることができる。顧客取引データベース２５２は、例えば、部店コードと、口座ＩＤと、約定日と、銘柄と、その他の取引情報とをそれぞれ対応づけることにより構成される。

各データベース２５１，２５２は、共通の情報である部店コード及び口座ＩＤによって関連づけられる。従って、特定の顧客の取引内容を検索する場合は、顧客属性データベース２５１を最初に検索して、その顧客の部店コード及び口座ＩＤを取得し、部店コード及び口座ＩＤに基づいて顧客取引データベース２５２を検索することにより、その顧客の取引内容を調べることができる。また、例えば、特定のファンドを購入した顧客の属性を検索する場合は、顧客取引データベース２５２を最初に検索し、特定のファンドに関わる部店コード及び口座ＩＤを取得し、次に、顧客属性データベース２５１を検索することにより、そのファンドを購入した各顧客の情報を得ることができる。

データベース２５１，２５２の構成からもわかるように、検索対象データベース２５０は、多数のデータ群を含んで構成され得る。例えば、一人の顧客は、複数の取引を行うことができ、また、各支店毎にそれぞれ別々の取引を行うこともできる。従って、数百万〜数千万程度の取引情報が検索対象データベース２５０に記憶され得る。

このような大規模データベース２５０を、その全範囲にわたって検索しようとする場合は、比較的長い時間を必要とする。検索時間を短縮するために、データベース２５０の複製を複数用意しておき、並列的に検索させることも考えられる。しかし、この場合は、各データベース２５０間の記憶内容を同期させる必要があり、システム導入コスト及び維持コストもそれぞれ大幅に増大する。また、このような大規模データベース２５０の全範囲を対象として検索する場合は、その検索範囲が広すぎて検索時間が長くなるために、タイムアウトが発生し易くなる。タイムアウトとは、予め設定された所定時間内に検索が完了しなかった状態を意味する。この所定時間は、ある検索のためにデータベース２５０が長時間にわたって専有されるのを防止するために設定される。タイムアウトとなった検索は、その処理が停止され、データベース２５０はその検索から解放される。

本実施例は、このような大規模データベース２５０に対するより確実な検索を可能とするための構成を開示する。本実施例では、後述するように、検索時間の短縮よりも、検索結果の入手可能性の向上を目的として、独特の構成を採用している。

図６は、検索状況管理データベース２６０の構成例を示す説明図である。検索状況管理データベース２６０は、例えば、検索ＩＤと、検索条件と、検索範囲と、ステータスと、続行指定と、実行予定日と、優先度と、開始時刻と、終了時刻と、終了予定時刻とを、それぞれ対応づけることにより構成することができる。

図６には、３つの親検索要求（ID01，ID02，ID03）がそれぞれ９個ずつに分割されて登録されている様子が示されている。同一の親検索要求から分割された各子検索要求には、それぞれ01から09までの連続した枝番が設定されている。

検索ＩＤとは、検索クライアント１０から受信した検索要求を分割してなる各子検索要求をそれぞれ特定するための識別コードである。この検索ＩＤは、図４に示す検索識別コードＤ２０に連続した枝番を付加することにより構成される。即ち、親検索要求と子検索要求とは、それぞれ共通の検索識別コードＤ２０を備えており、枝番によって各子検索要求が識別される。

検索条件には、例えば、「男性アンド為替」等のような検索式がセットされる。検索範囲には、部店コードによって、検索すべき範囲が指定される。各子検索要求の検索範囲は、予め分割定義ファイル２８１に定義されている。

ステータスとは、その子検索要求の置かれている状態を示す情報である。ステータスとしては、例えば「実行待ち」、「実行中」、「実行完了」、「中断」、「タイムアウト」、「エラー」等を挙げることができる。「実行待ち」とは、検索実行の開始を待っている状態を意味する。「実行中」とは、現在検索されている状態であることを意味する。「実行完了」とは、検索が終了して検索結果ファイル２７１が生成された状態を意味する。「中断」とは、その検索がユーザの指示によって中断された状態を意味する。「タイムアウト」とは、予め設定された所定時間内に検索が終了しなかった状態を意味する。「エラー」とは、タイムアウト以外の不具合によって検索できなかった状態を意味する。検索の進捗状況に応じて、そのステータスは変化する。通常の場合、「実行待ち」→「実行中」→「実行完了」の順番でステータスは遷移する。タイムアウト等が生じる場合は、「実行待ち」→「実行中」→「タイムアウト」（または「エラー」）の順序で遷移する。

続行指定とは、検索サービス提供時間の終了によって中断された検索要求を次の稼働日に続行させるか否かを指定する情報である。実行予定日とは、その子検索要求を実行すべき日時を示す。優先度とは、その子検索要求の優先度を示す。開始時刻とは、その子検索要求の処理が開始された日時を示す。終了時刻とは、その子検索要求の処理が終了した日時を示す。終了予定時刻とは、その子検索要求の全体が終了する予定時刻を示す。ここで、開始時刻、終了時刻及び終了予定時刻等の各種時刻情報は、西暦年月日時分秒の形式で示すこともできる。

終了予定時刻は、子検索要求の各組（後述）のうち、最終回に実行される検索が終了すると見込まれる予定時刻である。終了予定時刻は、子検索要求の進捗状況に応じて、定期的または不定期に、再計算される。

一つの親検索要求から分割された各子検索要求は、共通の属性を備えている。共通の属性としては、検索識別コード（枝番を除く部分）、検索条件、続行指定、実行予定日、優先度を挙げることができる。これらの各項目は、親検索要求に設定された値がそのまま使用される。これに対し、検索範囲、ステータス、開始時刻、終了時刻は、各子検索要求毎にそれぞれ異なる。但し、同一の組に属する子検索要求は、それぞれ略同一時刻に検索が開始され、ステータスが変化するため、開始時刻及びステータスは、各組内で共通することが多い。終了時刻は、それぞれ異なる場合がある。

図７は、検索結果記憶部２７０の記憶構成を模式的に示す説明図である。検索結果記憶部２７０には、複数の検索結果ファイル２７１をそれぞれ記憶させることができる。各検索結果ファイル２７１には、子検索要求を特定するための検索識別コードがそれぞれ関連づけられている。上述のように、子検索要求を特定するための検索識別コードは、親検索要求に設定された検索識別コードＤ２０に枝番を付加した構成となっている。従って、検索クライアント１０は、検索サーバ２０から受領した検索識別コードＤ２０に基づいて、検索結果記憶部２７０を検索することにより、自分の要求した検索結果に関連するファイル２７１を全て発見し、読み出すことができる。

図８は、分割定義ファイル２８１及び再分割定義ファイル２９１の構成等を模式的に示す説明図である。図８（ａ）に示すように、分割定義ファイル２８１には、各子検索要求の検索範囲が、部店コードによって予めそれぞれ定義されている。例えば、第１の子検索要求は部店コード「0000」〜「0027」を有するレコードのみを検索し、第２の子検索要求は部店コード「0028」〜「0056」を有するレコードのみを検索する。分割定義ファイル２８１には、各子検索要求の検索範囲が略等しくなるように、検索対象の部店コードが定義されている。

なお、分割定義ファイル２８１は、親検索要求の指定する検索範囲が「全範囲」である場合の分割方法を示す。もしも、親検索要求が特定のエリアを指定する場合、エリア分割定義ファイル２８１Ａが使用される。エリア分割定義ファイル２８１Ａは、各子検索要求の検索範囲が略等しくなるように、そのエリアに属する各部店コードを、各子検索要求に割り当てている。従って、本実施例では、親検索要求で指定されている検索範囲に応じて、データベース２５０の全範囲を分割するための第１の分割定義ファイル２８１と、データベース２５０の一部を分割するための第２の分割定義ファイル２８１Ａとを切り替えることができる。
なお、エリア検索の場合は、親検索要求を必ずしも分割する必要はなく、そのまま検索状況管理データベース２６０に登録させることもできる。あるいは、エリア分割定義ファイル２８１Ａを用いずに、単に分割数だけを定めておき、この分割数に基づいて、検索要求を分割する構成でもよい。

再分割定義ファイル２９１には、タイムアウトによって検索されなかった範囲をさらに分割して登録させるための再分割数が予め定義されている。検索登録部２１０は、タイムアウトによって検索されなかった範囲を、再分割数で指定された数に分割し、これらの再分割された各検索要求（孫検索要求）を検索状況管理データベース２６０にそれぞれ登録させる。

図８（ｂ）には、検索要求を分割する様子が示されている。上述のように、分割元である親検索要求で指定された検索範囲は、９個の検索範囲にそれぞれ分割される。これら各検索範囲は、それぞれ一つずつの子検索要求によって検索されることになる。もしも、検索範囲８の検索にタイムアウトが発生した場合、この検索範囲８は、8-1〜8-9の９個の検索範囲に再分割される。これら各検索範囲は、それぞれ一つずつの孫検索要求によって検索されることになる。

検索スケジューラ２２０は、検索状況管理データベース２６０に登録された検索要求が親検索要求であるか子検索要求であるか、あるいは孫検索要求であるかを意識することなく、一つまたは複数の検索要求を選択して検索実行を指示できる。

図９は、分割された検索要求の処理方法を模式的に示す説明図である。図９（ａ）に示すように、検索クライアント１０から入力された検索要求は、ｎ×ｍ個の検索要求に分割される。検索スケジューラ２２０は、毎回ｎ個（ｎ未満の自然数の場合もある）の検索要求を選択して、検索実行部２３０に検索実行を指示する。この検索実行を指示する回数は、合計ｍ回である。従って、ユーザによる中断指示等が出されない限り、ｎ×ｍ個に分割された各子検索要求の全てについて検索が行われる。

ここで、ｎ，ｍは、ともに２以上の自然数である。本実施例では、説明の便宜上、ｎ，ｍをそれぞれ「３」に設定しているが、本発明はこれに限られない。本実施例では、検索クライアント１０から入力された検索要求を９個（＝３×３）に分割して検索状況管理データベース２６０に登録するが、９個未満または１０個以上に分割して登録する構成でもよい。ｎ，ｍは互いに等しい値である必要はない。

ここで、合計ｍ回の検索実行指示のうち、各回において選択されるｎ個の検索要求を「組」または「ブロック」として捉えることができる。あるいは、各回において選択される最大ｎ個の検索要求を「グループ」として捉えることもできる。

図９（ｂ）に示すように、分割された各検索要求毎に、それぞれの検索結果ファイル２７１が生成され、検索結果記憶部２７０に登録される。図７と共に述べた通り、これら各検索結果ファイル２７１には、その生成の契機となった検索要求を特定するための検索識別コードが対応づけられる。

図１０は、検索クライアント１０から発行された検索要求を分割して登録するまでの処理を示すフローチャートである。なお、以下に述べる各フローチャートは、いずれも処理の概略を示しており、実際のプログラムとは相違する場合がある。

ユーザは、検索クライアント１０の端末画面を介して、所望のデータ群を得るための検索条件及び検索範囲を指定する（Ｓ２１）。ここで、ユーザは、続行指定の有無や実行予定日を指定することもできる。

検索クライアント１０は、ユーザによって指定された情報に基づいて、検索要求を生成し、これを検索サーバ２０に送信する（Ｓ２２）。検索登録部２１０は、検索クライアント１０から発行された検索要求を受信して受け付け（Ｓ２３）、検索ＩＤを発行して検索クライアント１０に通知する（Ｓ２４）。検索クライアント１０は、この検索ＩＤを記憶する（Ｓ２５）。

検索登録部２１０は、分割定義ファイル２８１を参照して（Ｓ２６）、検索要求を所定数の子検索要求に分割し（Ｓ２７）、これら各子検索要求を検索状況管理データベース２６０にそれぞれ登録させる（Ｓ２８）。

図１１は、検索スケジューラ２２０によるスケジュール管理処理を示すフローチャートである。検索スケジューラ２２０は、例えば、比較的短い周期で、検索状況管理データベース２６０を参照する（Ｓ３１）。

検索スケジューラ２２０は、検索状況管理データベース２６０に登録されている検索要求を上から順番に検査し、予め設定されている選択基準に基づいて、検索要求を選択する（Ｓ３２〜Ｓ３４）。例えば、「緊急」の優先度に設定されている「実行待ち」状態の検索要求が最優先に選択され（Ｓ３２）、次に前日分の「実行待ち」状態にある検索要求（即ち、続行指定された未処理の検索要求）が選択され（Ｓ３３）、最後に当日受付分の検索要求が選択されるように（Ｓ３４）、選択基準を設定することができる。

なお、例えば、上記の選択基準に基づいて、検索状況管理データベース２６０の登録内容を適宜並び替えることにより、より優先度の高い検索要求をデータベースの先頭側に配置させることもできる。この場合は、データベース２６０に登録された検索要求を上から順番に読み出して検索実行を指示すればよい。選択基準の優先順位については、図１２と共にさらに後述する。

次に、検索スケジューラ２２０は、検索リソース（検索部２３１）に空きがあるか否かを判定する（Ｓ３５）。検索リソースに空きがない場合、検索スケジューラ２２０は、使用可能な検索部２３１が生じるまで待機する。検索部２３１に空きが生じると（S35:YES）、検索スケジューラ２２０は、その使用可能な検索部２３１の数だけ、検索状況管理データベース２６０から子検索要求を取得する（Ｓ３６）。そして、検索スケジューラ２２０は、取得した子検索要求について検索実行を指示する（Ｓ３７）。

後述のように、検索実行部２３０は、子検索要求の処理を開始すると、検索状況管理データベース２６０にアクセスし、その子検索要求のステータスを「実行待ち」から「実行中」に更新させる。また、検索実行部２３０は、子検索要求の処理を終了すると、その子検索要求のステータスを「実行中」から「実行完了」に更新させる。検索リソース、即ち、検索部２３１の数は、検索スケジューラ２２０にとって既知である。従って、検索スケジューラ２２０は、検索状況管理データベース２６０を参照して、「実行中」のステータスを有する子検索要求の数を検出することにより、使用可能な検索部２３１の数を算出できる（使用可能な検索部の数＝検索部の総数−「実行中」ステータスの数）。

上述の通り、本実施例では、基本的に、ｎ個１組の子検索要求について略同時に検索を実行させ、この並列処理を合計ｍ回繰り返すことにより、ｎ×ｍに分割された子検索要求を全て処理する。しかし、個々の検索に要する時間はそれぞれ異なるため、同一の組に属する子検索要求同士であっても、実際の検索開始時刻はそれぞれ異なる場合もある。検索スケジューラ２２０は、使用可能な検索部２３１を発見次第、直ちに次の子検索要求について検索実行を指示するためである。これにより、検索部２３１の休止時間を短くして稼働率を高めることができる。

図１２は、検索スケジューラ２２０による子検索要求の選択基準（検索処理の実行順序）を模式的に示す説明図である。図１２の上側には、ある日（例えば、７月１日）に検索サーバ２０に受け付けられた親検索要求が受付順に示されている。

１番目に示されている親検索要求は、当日（７月１日）の午前９時に受け付けられ、当日の実行が指定されたものである（ID11）。２番目に受け付けられた親検索要求（ID12）は、翌日（７月２日）の実行が指定されたものである。３番目に受け付けられた親検索要求（ID13）は、当日の実行が指定されたものである。４番目に受け付けられた親検索要求（ID14）は、当日の実行が指定されており、続行指定もされている。５番目に受け付けられた親検索要求（ID15）は、当日の実行が指定されており、続行指定はされていないものである。なお、ID11，ID12，ID13もそれぞれ続行指定されていないが、ここで挙げる例では問題とならないため、図示を省略している。

４番目の親検索要求（ID14）を処理中に、即ち、この親検索要求（ID14）を分割してなる子検索要求の全てを検索するよりも前に、検索サービスの提供時間が終了したと仮定する。例えば、検索対象データベース２５０の記憶内容を最新のものに更新させたり、検索対象データベース２５０のバックアップを生成したりするメンテナンス時間が必要となるため、検索サービスは定期的または不定期に停止される。

検索中にサービス時間外となった親検索要求（ID14）には、後日続行すべき旨が事前に指定されている。従って、図１２の下側に示すように、翌日の実行順序では、第１位を獲得する。５番目の親検索要求（ID15）は、続行指定がされていないため、その親検索要求はキャンセルされ、検索状況管理データベース２６０から削除される。

翌日の実行が予約されていた親検索要求（ID12）は、第２位の順位を獲得する。そして、７月２日当日に最初に受け付けられた親検索要求（ID16）は、第３位の順位を獲得する。なお、「緊急」の優先度に設定された親検索要求が７月２日に受け付けられた場合、この緊急の親検索要求は、他の全ての親検索要求に優先して処理される。

このように、本実施例では、基本的に先着順で検索を処理するが、途中で処理が中断され、かつ、事前に続行指定がされた親検索要求や事前に実行予定日が指定された親検索要求は、通常の親検索要求よりも高い順位で実行される。

図１３（ａ）にも示すように、第１回目のｎ個の子検索要求については検索が終了したが、第２回目のｎ個の子検索要求を検索中に、サービス時間が終了となった場合を考える。この場合は、第２回目及び第３回目に検索されるはずだった合計６個の子検索要求について、未処理となる。図１３（ｂ）に示すように、翌日の検索サービスが開始されると、これら未処理の子検索要求について、複数段階に分けてそれぞれ処理される。

図１４は、検索実行部２３０による検索処理を示すフローチャートである。検索実行部２３０は、検索スケジューラ２２０から検索実行の指示を受領すると（S41:YES）、各検索部２３１に検索条件及び検索範囲を入力して検索を開始させる（Ｓ４２）。

検索実行部２３０は、検索が開始されると、検索状況管理データベース２６０にアクセスし、検索が開始された子検索要求のステータスを「実行待ち」から「実行中」に変化させる（Ｓ４３）。また、検索実行部２３０は、検索が開始された子検索要求の検索開始時刻を、検索状況管理データベース２６０に登録させる（Ｓ４４）。

検索実行部２３０は、検索が正常に終了したか否かを判定する（Ｓ４５）。検索が正常に終了した場合（S45:YES）、検索結果ファイル２７１が検索結果記憶部２７０に記憶される（Ｓ４６）。検索実行部２３０は、検索状況管理データベース２６０にアクセスし、検索が正常に終了した子検索要求のステータスを「実行中」から「実行完了」に変化させる（Ｓ４７）。また、検索実行部２３０は、検索が正常に終了した子検索要求の検索終了時刻を、検索状況管理データベース２６０に登録させる（Ｓ４８）。

一方、検索が正常に終了していない場合（S45:NO）、検索実行部２３０は、タイムアウトが発生したか否かを判定する（Ｓ４９）。タイムアウトが発生した場合（S49:YES）、検索実行部２３０は、タイムアウトとなった子検索要求のステータスを「実行中」から「タイムアウト」に変化させる（Ｓ５０）。「タイムアウト」のステータスを有する子検索要求は、後述のように、さらに分割されて再び検索が試みられる。

タイムアウトが発生していない場合（S49:NO）、検索実行部２３０は、タイムアウト以外のエラーが発生したか否かを判定する（Ｓ５１）。エラーが生じた場合（S51:YES）、検索実行部２３０は、そのエラーに応じた所定の処理を行った後（Ｓ５２）、検索状況管理データベース２６０にアクセスして、エラーの生じた子検索要求のステータスを「実行中」から「エラー」に変化させる（Ｓ５３）。

エラーが発生していない場合（S51:NO）、Ｓ４５に戻る。検索を開始しても直ちに処理が終了するわけではないため、Ｓ４５→Ｓ４９→Ｓ５１→Ｓ４５のステップが繰り返して実行される。

図１５は、タイムアウトとなった子検索要求を再分割して登録するための処理を示すフローチャートである。検索登録部２１０は、検索状況管理データベース２６０を参照して（Ｓ６１）、「タイムアウト」のステータスを有する子検索要求が存在するか否かを判定する（Ｓ６２）。

タイムアウトになった子検索要求が発見されると（S62:YES）、検索登録部２１０は、再分割定義ファイル２９１を参照して（Ｓ６３）、このタイムアウトとなった子検索要求を所定数の孫検索要求に分割する（Ｓ６４）。そして、検索登録部２１０は、これら分割された孫検索要求を検索状況管理データベース２６０に登録させる（Ｓ６５）。
ここで、親検索要求から子検索要求を分割する場合と同様に、各孫検索要求の検索範囲がそれぞれ略等しくなるように、孫検索要求を生成することができる。なお、これに限らず、子検索要求の検索範囲のみを略等しく設定し、孫検索要求の検索範囲は互いに異なるように設定することもできる。

孫検索要求と子検索要求とは、検索処理の実行に際して特に区別されない。検索スケジューラ２２０は、子検索要求の処理について述べたと同様に、所定の選択基準に従って孫検索要求を選択し、その検索実行を指示する。

図１６は、検索の途中で、ユーザが検索を中断させる場合の処理を示すフローチャートである。例えば、ユーザは、検索条件や検索範囲を誤って指定したことに後から気づく場合がある。このような場合、ユーザは、既に発行された検索要求を取り消して、別の検索要求の発行を希望する（S71:YES）。

検索クライアント１０は、ユーザからの中断指示を受領すると、中断要求を検索サーバ２０に発行する（Ｓ７２）。この中断要求には、例えば、中断すべき旨のコマンド及び中断させる検索要求の検索識別コードとが含まれている。

検索登録部２１０は、検索クライアント１０から中断要求を受領すると（Ｓ７３）、検索状況管理データベース２６０にアクセスし、中断を要求された親検索要求に関わる子検索要求のステータスを、「中断」に変更させる（Ｓ７４）。なお、既に「実行完了」となった子検索要求のステータスを「中断」に変更させる必要はない。通常の場合、「実行待ち」の検索要求のステータスが「中断」に変更される。

検索スケジューラ２２０は、検索状況管理データベース２６０を参照して（Ｓ７５）、ステータスが「中断」に変更された検索要求を発見すると（S76:YES）、その検索要求が既に検索中であるか否かを判定する（Ｓ７７）。

中断を要求された親検索要求の一部について既に検索が開始されている場合（S77:YES）、検索スケジューラ２２０は、現在実行中の子検索要求の処理が終了するまで、待機する（Ｓ７８）。現在実行中の子検索要求の処理が終了した場合（S78:YES）、検索スケジューラ２２０は、次の組の子検索要求について検索実行を指示することなく、「実行待ち」から「中断」にステータスが変更された子検索要求を検索状況管理データベース２６０から削除させる（Ｓ７９）。

上述のように、本実施例では、親検索要求をｎ×ｍ個の子検索要求に分割し、毎回ｎ個の子検索要求を選択して検索し、この並列検索処理を合計ｍ回繰り返す。中断が要求された親検索要求について全く検索が開始されていない場合（S77:NO）、各子検索要求は検索状況管理データベース２６０からそれぞれ削除される（Ｓ７８）。これに対し、中断が要求された親検索要求について検索が開始されている場合（S77:YES）、実行中の子検索要求について処理が終了するまで待機し（Ｓ７８）、区切りのいいところで残りの子検索要求を削除する（Ｓ７９）。

図１７は、終了時刻を予測する処理を示すフローチャートである。終了時刻予測部２４０（以下「予測部２４０」とも呼ぶ）は、予測対象の親検索要求を選択し（Ｓ９１）、検索状況管理データベース２６０を参照して（Ｓ９２）、予測対象の親検索要求について検索が開始されているか否かを判定する（Ｓ９３）。

その親検索要求を分割してなる子検索要求の処理が開始されている場合（S893:YES）、予測部２４０は、最新の検索開始時刻TLを取得する（Ｓ９４）。ここで、最新の検索開始時刻TLとは、その親検索要求について最後に検索が開始された子検索要求の検索開始時刻である。

次に、予測部２４０は、その親検索要求について、既に検索が正常に終了した子検索要求が存在するか否かを判定する（Ｓ９５）。検索実行済の子検索要求が存在する場合（S95:YES）、予測部２４０は、その実行済の子検索要求の検索に要した検索時間ｔｓを算出する（Ｓ９６）。実行済の子検索要求が複数存在する場合、各検索所要時間の平均値が算出される。

これに対し、例えば、親検索要求の検索開始直後で、未だ実行済の子検索要求が一つも存在しない場合（S95:NO）、予測部２４０は、検索時間ｔｓとして初期値ｔ０を採用する（Ｓ９７）。この初期値ｔ０は、タイムアウト検出用の閾値と等しい値に設定することができる。一例として、ｔ０＝タイムアウト検出用閾値＝６０分程度に設定する。

次に、予測部２４０は、次のブロック（子検索要求の組）の検索開始時刻TNを算出する（Ｓ９８）。次ブロックの検索開始時刻TNとは、次の回の検索が開始される時刻であり、TN＝TL＋ｔｓとして求めることができる。

次に、予測部２４０は、「実行待ち」状態にある子検索要求の総数及び各回で選択される子検索要求の数ｎとに基づいて、実行待ちのブロック数（検索指示回数）BNを算出する（Ｓ９９）。合計ｍ回行われる検索実行の指示段階では、各回毎にそれぞれｎ個ずつの子検索要求が選択されることは既に述べた。このｎ個の子検索要求は、それぞれの検索開始時刻は多少異なるが、並列的に処理される。従って、このｎを並列処理数または基準数等と呼ぶことができる。

実行待ちブロック数BNは、実行待ちの子検索要求の総数をｎで除算して得られた値を切り上げることにより求めることができる。例えば、終了時刻の予測時点において、実行待ちの子検索要求の総数が８個であったとすると、８÷３＝２．６６を切り上げて、BNは「３」となる。また、例えば、実行待ちの子検索要求の総数が１である場合、それをｎで除算して得られる値を切り上げ、BNの値として「１」を得る。

予測部２４０は、親検索要求の終了予定時刻TEを、次ブロックの検索開始時刻TNと、実行待ちブロック数BNと、検索時間ｔｓとに基づいて算出する（Ｓ１００）。この算出には、TE＝TN＋（BN×ｔｓ）の式を使用することができる。予測部２４０は、算出された終了予定時刻TEを検索状況管理データベース２６０に登録させる（Ｓ１０１）。

図１８は、検索クライアント１０による検索終了予定時刻の表示処理を示すフローチャートである。検索クライアント１０は、ユーザからの要求に応じて随時に、あるいは、定期的に、検索終了予定時刻を参照するか否か判定する（Ｓ１１０）。

検索終了予定時刻の参照を行う場合（S110:YES）、検索クライアント１０は、検索状況管理データベース２６０にアクセスし（Ｓ１１１）、そこに登録されている検索終了予定時刻TEを取得する（Ｓ１１２）。そして、検索クライアント１０は、その取得した検索終了予定時刻TEを、端末画面に表示させる（Ｓ１１３）。これにより、ユーザは、自分の要求した検索がいつ頃終了する予定であるかを事前に知ることができる。

図１９〜図２１は、検索終了時刻を予測する一例を模式的に示す説明図である。図１９に示すように、第１回目の検索実行において、一つの子検索要求だけが先行して09:00に実行されているものとする。終了時刻を予測する判断時刻を09:10とする。

既に開始された子検索要求の検索開始時刻TLは09:00である。また、実行済の子検索要求が存在しないため、検索時間ｔｓには初期値（６０分）が使用される。実行待ちの子検索要求の総数は、８（＝９−１）個であり、一回あたりに選択される基準数ｎは３であるから、実行待ちブロックの数BNは「３」となる。次ブロックの検索開始時刻TNは、TL（09:00）に検索時間ｔｓ（６０分）を加えることにより、10:00となる。従って、図１９に示す例では、検索終了予定時刻TEは、13:00となる（TE＝10:00＋60分×３）。

図２０に示す例は、終了時刻の予測時期を09:20に進めた場合である。この判断時点では、最初の組に属する全ての子検索要求について検索が開始されているものとする。その組の中で最後に検索が開始された時刻TLを09:12とする。この時点では、実行済の子検索要求が存在しないため、検索時間ｔｓには初期値が使用される。次ブロックの検索開始時刻TNは、10:12となる。実行待ちの子検索要求の総数は６であるから、実行待ちブロック数BNは「２」となる。従って、検索終了予定時刻TEは、12:12となり（TE＝10:12＋60分×２）、前回の予測時よりも１時間程度短縮される。

図２１に示す例は、終了時刻の予測時期を10:25に進めた場合である。この判断時点では、第２の組の検索も開始されており、第１の組の検索は終了している。第３の組に属する一つの子検索要求の検索も開始されている。最後に開始された検索の開始時刻TLは10:20、第１の組の検索に要した時間ｔｓの平均値は３９分であるとする。実行待ちの子検索要求の総数は２であるから、実行待ちブロック数BNは「１」となる。次ブロックの検索開始予定時刻TNは、10:59（10:20＋39）となる。従って、検索終了予定時刻TEは、11:38となり（TE＝10:59＋39×１）、前回の予測時よりも約３０分程度短縮される。

このように本実施例では、分割された各子検索要求の検索状況に基づいて、親検索要求の終了予定時刻TEを随時算出することができる。また、予測式に用いるパラメータの少なくとも一部（次ブロック検索開始時刻TL、検索時間ｔｓ）を、検索の進捗状況に応じて修正させるため、子検索要求の検索が進むにつれて、予測精度も向上する。

図２２は、検索状況管理データベース２６０に登録された子検索要求のステータスが変化する様子を模式的に示す説明図である。図２２では、検索状況管理データベース２６０の構成を簡略化して示してある。

図２２（ａ）に示すように、検索開始前の初期状態では、各子検索要求のステータスは「実行待ち」になっている。第１の組の検索が開始されると、第１の組に属する各子検索要求のステータスは「実行待ち」から「実行中」にそれぞれ変化する。

図２２（ｂ）に示すように、第１の組の検索が終了して、第２の組の検索が開始されると、第１の組に属する各子検索要求のステータスは「実行中」から「実行完了」にそれぞれ変化し、第２の組に属する各子検索要求のステータスは「実行待ち」から「実行中」にそれぞれ変化する。なお、例えば、図２２（ｂ）に示す状態と図２２（ｃ）に示す状態との間で、検索終了予定時刻TE１を算出し、検索状況管理データベース２６０に記憶させることができる。

図２２（ｄ）に示すように、第２の組の子検索要求を検索している最中に、ユーザが中断を指示した場合、第３の組に属する各子検索要求のステータスは「実行待ち」から「中断」にそれぞれ変化する。なお、図２２（ｃ）に示す状態から図２２（ｄ）に示す状態に遷移する間に、検索終了予定時刻TE２を算出することもできる。

図２３は、検索クライアント１０により実行される検索結果の表示処理を示すフローチャートである。検索クライアント１０は、例えば、数分程度の所定時間毎に検索状況管理データベース２６０にアクセスする（Ｓ１２０，Ｓ１２１）。検索クライアント１０は、自分の要求した親検索要求の処理が完了しているか否かを確認する。

検索クライアント１０は、検索が完了している場合、検索結果記憶部２７０にアクセスし、要求した検索に関する各検索結果ファイル２７１を全て取得する（Ｓ１２２）。そして、検索クライアント１０は、取得した各検索結果ファイル２７１を統合し、一つの検索結果として端末画面に表示させる（Ｓ１２３）。なお、クライアント１０は、各検索結果ファイル２７１をそれぞれ個別に表示させることもできる。

本実施例は上述の構成を備えるため、以下の効果を奏する。本実施例では、検索クライアント１０から発行された検索要求をｎ×ｍ個の子検索要求に分割し、毎回ｎ個の子検索要求を並列的に検索する処理を合計ｍ回実行させる構成とした。従って、例えば、検索対象データベース２５０の全範囲を検索する場合でも、検索範囲を分割して一つ一つの検索に要する負荷を小さくすることができる。

この結果、データベース２５０の全体を検索する一つの検索要求を実行する場合に比べて、検索が正常に終了する可能性を高めることができ、使い勝手を改善できる。検索結果を得るまでの時間が多少長くても、その結果を得られる可能性が高ければ、ユーザは、検索結果が出力されるまでの待ち時間内に、安心して別の作業を行うことができる。

本実施例では、検索の応答性改善よりも検索の成功率向上を目的とし、親検索要求を分割して多段階で並列処理する構成とした。従って、例えば、データベース２５０の複製を多数用意する必要がなく、システムコストの増加を抑制しながら、使い勝手を向上させることができる。

本実施例では、タイムアウトとなった子検索要求については、さらに分割して多段階で並列検索を行う構成とした。従って、例えば、データベース２５０の過負荷によって一部の検索が失敗した場合でも、自動的に検索負荷をより小さくして再度の検索を行うことができ、検索の成功率を高めることができる。

本実施例では、検索登録部２１０の処理と検索スケジューラ２２０の処理とを切り離し、両者をそれぞれ個別に動作させる構成とした。従って、検索実行の予定日を予め指定して登録させ、予定の日時に実行させることができる。即ち、検索要求を発行する時点での検索システムの待ち状態を考慮することなく、所望の日時を指定して検索要求を登録することができ、使い勝手が向上する。

本実施例では、検索登録部２１０による登録処理と検索スケジューラ２２０による検索実行の指示処理と検索実行部２３０による検索処理とをそれぞれ切り離し、これら各処理を検索状況管理データベース２６０を介して非同期でそれぞれ実行させる構成とした。従って、比較的簡易な制御構造でありながら、使い勝手を改善することができる。

本実施例では、ユーザが事前に希望する場合、検索中にサービス時間の終了によって中断された検索要求は、その次の最初の稼働日に優先して処理する構成とした。従って、ユーザは、検索サービスの提供時間や検索待ちの状況等を何ら気にすることなく、所望の時刻に検索要求を発行することができ、使い勝手が向上する。また、続行指定された検索要求は、次の稼働日の最初に優先して処理されるため、その稼働日における最初の検索要求が受け付けられるまで待たずに、検索システムを稼働させることができ、検索システムの稼働率を高めることができる。

本実施例では、分割された各検索要求の処理状況に基づいて、全部の検索要求の処理が終了する予定時刻を予測する構成とした。従って、ユーザは、検索予定時刻を適宜参照することにより、検索結果が得られるまでの待ち時間を知ることができ、その待ち時間を別の作業にあてて有効に利用することができる。

本実施例では、検索要求をｎ×ｍ個に分割して、毎回ｎ個ずつの並列的な検索を合計ｍ回行う構成とするため、検索の途中でユーザが中断を指示した場合、比較的速やかに実行中の検索を中断させることができる。これにより、使い勝手が向上する。

本実施例では、分割された各検索要求の検索結果ファイル２７１を検索結果記憶部２７０にそれぞれ記憶させておき、検索クライアント１０が検索結果記憶部２７０にアクセスして、各検索結果ファイル２７１を取得する構成とした。従って、比較的簡易な構成で、検索クライアント１０は、検索結果を得ることができる。

なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、図２４に示す変形例のように、一回に８個の検索を同時に行う処理を３回繰り返す構成でもよい。

また、図２４（ａ）に示すように、検索リソースを複数の検索リソース群に分割し、一方の検索リソース群を一方の親検索要求ＳＡに割り当て、他方の検索リソース群を他方の親検索要求ＳＢに割り当てる構成でもよい。さらに、図２４（ｂ）に示すように、検索要求の検索範囲や優先度等に応じて、各親検索要求ＳＡ，ＳＢに割り当てる検索リソースの数を調節する構成でもよい。

また、前記実施形態では、分割定義ファイルに基づいて、検索要求を分割する場合を例示した。しかし、本発明はこれに限らず、分割定義ファイルを用いずに、検索要求を自動的に、または、手動で、分割することもできる。例えば、検索範囲を所定値で除算する等のような所定の演算式を用いて、検索要求を分割することができる。あるいは、検索サーバの管理者または検索要求を出すユーザのいずれかまたは両方が、手動操作で、検索要求を分割することも可能である。

本発明の実施形態に係る検索システムの構成を示すブロック図である。 検索システムの接続構成を示す説明図である。 検索システムのハードウェア構成及びソフトウェア構成を示す説明図である。 検索クライアントから発行される検索要求及び検索サーバから発行される検索識別コードの構成を示す説明図である。 検索対象データベースの構成を示す説明図である。 検索状況管理データベースの構成を示す説明図である。 検索結果記憶部の構成を示す説明図である。 検索クライアントから発行された検索要求を所定数の検索要求に分割する様子を示す説明図であって、（ａ）は分割定義ファイル及び再分割定義ファイルに基づいて検索要求を分割する様子を、（ｂ）は検索範囲が略均等となるように検索要求が分割される様子をそれぞれ示す。 並列的な検索処理が多段階に行われる様子を示す説明図であって、（ａ）は分割された検索要求の並列処理が多段階で実行される様子を、（ｂ）は分割された各検索要求毎にそれぞれ検索結果ファイルが生成される様子を示す。 検索要求を受け付けて登録する処理を示すフローチャートである。 登録された検索要求の検索実行を指示する処理を示すフローチャートである。 検索要求の受付順序と実行順序との違いを示す説明図である。 検索中に検索サービスが終了して中断された場合の検索再開を示す説明図である。 検索処理を示すフローチャートである。 タイムアウトになった検索要求を再分割して検索状況管理データベースに登録し直す処理を示すフローチャートである。 発行済の検索要求を中断させる処理を示すフローチャートである。 終了時刻を予測する処理を示すフローチャートである。 検索予定終了時刻を端末画面に表示させる処理を示すフローチャートである。 検索初期に検索終了予定時刻を予測する様子を示す説明図である。 検索中期に検索終了予定時刻を予測する様子を示す説明図である。 検索終期に検索終了予定時刻を予測する様子を示す説明図である。 検索状況管理データベースに登録された各検索要求のステータス変化を模式的に示す説明図である。 検索結果ファイルを取得して表示させる処理を示すフローチャートである。 本発明の変形例を示す説明図であり、（ａ）は複数の検索要求にそれぞれ同数の検索リソースを割り当てる場合を、（ｂ）は複数の検索要求にそれぞれ異なる検索リソースを割り当てる場合を示す。

符号の説明

１…組織単位（部店）、２…LAN、３…通信ネットワーク、１０…検索クライアント、１１…情報処理部、１２…記憶部、２０…検索サーバ、２１…情報処理部、２２…記憶部、１１１…検索要求プログラム、１１２…検索結果表示プログラム、２１０…検索登録部、２１０Ｐ…検索登録プログラム、２２０…検索スケジューラ、２２０Ｐ…検索スケジューラプログラム、２３０…検索実行部、２３０Ｐ…検索プログラム、２３１…検索部、２４０…終了時刻予測部、２４０Ｐ…終了時刻予測プログラム、２５０…検索対象データベース、２５１…顧客属性データベース、２５２…顧客取引データベース、２６０…検索状況管理データベース、２７０…検索結果記憶部、２７１…検索結果ファイル、２８０…分割定義記憶部、２８１…分割定義ファイル、２８１Ａ…エリア分割定義ファイル、２９０…再分割定義記憶部、２９１…再分割定義ファイル、Ｄ１０…検索要求、Ｄ２０…検索識別コード

Claims (7)

1. クライアントコンピュータからの検索要求に基づいて、一つの検索対象データベースを検索して検索結果を出力する検索システムであって、
   前記クライアントコンピュータから受信した第１検索要求を、所定の複数個の第２検索要求に分割して管理用データベースにそれぞれ登録させる検索登録手段と、
   前記管理用データベースに登録された前記各第２検索要求を、複数回に分けて全て選択し、各回毎にそれぞれ検索実行を指示する検索スケジュール管理手段と、
   前記検索スケジュール管理手段からの指示に基づいて、部店コードに対応付けられるデータを記憶する前記一つの検索対象データベースを検索し、その検索結果を出力する検索実行手段と、
   前記各第２検索要求の検索範囲が部店コード数で略等しくなるように、前記部店コードによって前記各第２検索要求の検索範囲が予め定義された分割定義ファイルを備え、
   前記検索登録手段は、
   前記分割定義ファイルを参照することにより、前記第１検索要求を前記各第２検索要求に分割して前記管理用データベースにそれぞれ登録させるようになっており、
   さらに、前記管理用データベースに登録された前記各第２検索要求のうち、タイムアウトによる検索失敗によって前記検索実行手段による検索結果が得られなかった第２検索要求を、検索されなかった範囲を指定された数で再分割して前記管理用テーブルに登録させる、
   検索システム。
2. 前記検索実行手段は、前記検索スケジュール管理手段から指示された前記各第２検索要求の検索をそれぞれ個別に実行する検索手段を複数個備えており、
   前記検索スケジュール管理手段により前記各回毎に選択される前記第２検索要求の数は、前記検索手段の数以下に設定されている請求項１に記載の検索システム。
3. 前記第１検索要求には、検索実行時期を予め指定する実行時期情報が含まれており、
   前記検索スケジュール管理手段は、前記実行時期情報に示された時期が到来した場合に、前記第１検索要求を分割してなる前記各第２検索要求を、前記所定の複数回に分けて全て選択し、各回毎にそれぞれ検索実行を指示する請求項１に記載の検索システム。
4. 前記第１検索要求には、検索が途中で中止された場合に続行を希望するか否かを示す続行指定情報が含まれており、
   前記検索スケジュール管理手段は、前記続行指定情報によって続行が指定されている前記第１検索要求を分割してなる前記各第２検索要求を、他の第２検索要求よりも優先して、前記所定の複数回に分けて全て選択し、各回毎にそれぞれ検索実行を指示する請求項１に記載の検索システム。
5. 前記検索実行手段によって検索が行われている直近の第２検索要求の検索開始時刻と、予め設定される第２検索要求の処理基準時間と、前記検索スケジュール管理手段が未処理の第２検索要求について検索実行の指示を発行する回数とに基づいて、前記第１検索要求の検索終了時刻を予測する終了時刻予測手段を備え、
   前記処理基準時間は、前記各第２検索要求のうち検索の終了した第２検索要求の処理時間に基づいて修正される請求項１に記載の検索システム。
6. 前記検索スケジュール管理手段は、前記各回毎に、前記各第２検索要求のうち未処理の第２検索要求を１〜ｎ（ｎは２以上の自然数）個選択して検索実行を指示するようになっており、
   前記終了時刻予測手段は、
   （１）前記各未処理の第２検索要求について前記検索スケジュール管理手段から発行される検索実行指示の回数をBN、前記検索スケジュール管理手段から前記検索実行の指示が新たに発行される次検索開始時刻をTN、処理基準時間をtsとしたときに、
   （２）前記各未処理の第２検索要求の総数を前記ｎで除算した値を切り上げて前記BNを求め、
   （３）検索が行われている直近の第２検索要求の検索開始時刻TLに前記処理基準時間tsを加算して前記次検索開始時刻TNを求め、
   （４）前記検索終了時刻TEを、TE＝TN＋（BN×ts）として算出する請求項５に記載の検索システム。
7. 前記検索実行手段から出力された検索結果を記憶する検索結果記憶手段を備え、
   前記検索実行手段は、前記各第２検索要求の検索を終了した場合に、その旨を前記管理用データベースに登録し、
   前記クライアントコンピュータは、前記管理用データベースに基づいて、前記検索結果記憶手段から前記検索結果を取得する請求項１に記載の検索システム。

Images