図面 (/)

技術 検索システム及び検索方法

出願人 株式会社野村総合研究所
発明者 小木曽功一
出願日 2005年7月29日 (14年7ヶ月経過) 出願番号 2005-219988
公開日 2007年2月8日 (13年1ヶ月経過) 公開番号 2007-034874
状態 特許登録済
技術分野 検索装置
主要キーワード 判断時刻 検索終了時刻 予測時期 分割定義 並列処理数 指示段 スケジューラプログラム 検索開始時刻
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2007年2月8日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

検索成功率を高めて使い勝手を向上させる。

解決手段

検索クライアント10は、データベース250の全体を対象とする検索要求Aを発行する(S1)。検索サーバ20の検索登録部210は、分割定義記憶部280に記憶されている分割ポリシに基づいて、検索要求Aを所定数の検索要求A1,A2,...に分割し、検索状況管理データベース260に登録する(S3)。検索スケジューラ220は、検索状況管理データベース260を参照し(S4)、n個の検索要求を選択して検索実行を指示する(S5)。検索実行部230は、各検索部231によってn個の検索を並列的に実行する(S6)。検索の結果は、検索結果記憶部270に記憶される(S7)。検索スケジューラ220は、毎回n個ずつの検索指示を合計m回繰り返すことにより、検索クライアント10から要求された検索を完了させる。

概要

背景

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

概要

検索の成功率を高めて使い勝手を向上させる。検索クライアント10は、データベース250の全体を対象とする検索要求Aを発行する(S1)。検索サーバ20の検索登録部210は、分割定義記憶部280に記憶されている分割ポリシに基づいて、検索要求Aを所定数の検索要求A1,A2,...に分割し、検索状況管理データベース260に登録する(S3)。検索スケジューラ220は、検索状況管理データベース260を参照し(S4)、n個の検索要求を選択して検索実行を指示する(S5)。検索実行部230は、各検索部231によってn個の検索を並列的に実行する(S6)。検索の結果は、検索結果記憶部270に記憶される(S7)。検索スケジューラ220は、毎回n個ずつの検索指示を合計m回繰り返すことにより、検索クライアント10から要求された検索を完了させる。

目的

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

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

クライアントコンピュータからの検索要求に基づいて、検索対象データベース検索して検索結果を出力する検索システムであって、前記クライアントコンピュータから受信した第1検索要求を、所定の複数個の第2検索要求に分割して管理用データベースにそれぞれ登録させる検索登録手段と、前記管理用データベースに登録された前記各第2検索要求を、複数回に分けて全て選択し、各回毎にそれぞれ検索実行を指示する検索スケジュール管理手段と、前記検索スケジュール管理手段からの指示に基づいて、前記検索対象データベースを検索し、その検索結果を出力する検索実行手段と、を備えた検索システム。

請求項2

前記検索登録手段は、前記管理用データベースに登録された前記各第2検索要求のうち、前記検索実行手段による検索結果が得られなかった第2検索要求を再分割して前記管理用テーブルに登録させる請求項1に記載の検索システム。

請求項3

前記検索実行手段は、前記検索スケジュール管理手段から指示された前記各第2検索要求の検索をそれぞれ個別に実行する検索手段を複数個備えており、前記検索スケジュール管理手段により前記各回毎に選択される前記第2検索要求の数は、前記検索手段の数以下に設定されている請求項1に記載の検索システム。

請求項4

前記各第2検索要求の検索範囲が略等しくなるように予め定義された分割定義ファイルを備え、前記検索登録手段は、前記分割定義ファイルを参照することにより、前記第1検索要求を前記各第2検索要求に分割して前記管理用データベースにそれぞれ登録させる請求項1に記載の検索システム。

請求項5

前記第1検索要求には、検索実行時期を予め指定する実行時期情報が含まれており、前記検索スケジュール管理手段は、前記実行時期情報に示された時期が到来した場合に、前記第1検索要求を分割してなる前記各第2検索要求を、前記所定の複数回に分けて全て選択し、各回毎にそれぞれ検索実行を指示する請求項1に記載の検索システム。

請求項6

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

請求項7

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

請求項8

前記検索スケジュール管理手段は、前記各回毎に、前記各第2検索要求のうち未処理の第2検索要求を1〜n(nは2以上の自然数)個選択して検索実行を指示するようになっており、前記終了時刻予測手段は、(1)前記各未処理の第2検索要求について前記検索スケジュール管理手段から発行される検索実行指示の回数をBN、前記検索スケジュール管理手段から前記検索実行の指示が新たに発行される次検索開始時刻をTN、処理基準時間をtsとしたときに、(2)前記各未処理の第2検索要求の総数を前記nで除算した値を切り上げて前記BNを求め、(3)検索が行われている直近の第2検索要求の検索開始時刻TLに前記処理基準時間tsを加算して前記次検索開始時刻TNを求め、(4)前記検索終了時刻TEを、TE=TN+(BN×ts)として算出する請求項7に記載の検索システム。

請求項9

前記検索実行手段から出力された検索結果を記憶する検索結果記憶手段を備え、前記検索実行手段は、前記各第2検索要求の検索を終了した場合に、その旨を前記管理用データベースに登録し、前記クライアントコンピュータは、前記管理用データベースに基づいて、前記検索結果記憶手段から前記検索結果を取得する請求項1に記載の検索システム。

請求項10

クライアントコンピュータからの検索要求に基づいて、検索対象データベースを検索して検索結果を出力する検索方法であって、前記クライアントコンピュータから第1検索要求を受信する受信ステップと、前記受信された第1検索要求をn×m(n,mはいずれも2以上の自然数)個の第2検索要求に分割し、管理用データベースにそれぞれ登録させる分割登録ステップと、前記管理用データベースに登録された前記各第2検索要求を、各回毎に、それぞれ1〜n個の範囲内で選択して検索実行を指示する指示ステップと、前記検索実行が指示された前記各第2検索要求について、それぞれ前記検索対象データベースの所定範囲を検索することにより並列処理で検索を行う検索ステップと、前記検索が正常に終了した場合に、その検索結果を記憶させる記憶ステップと、を含む検索方法。

請求項11

前記検索ステップの次に、前記検索が正常に終了しなかった場合、その第2検索要求を分割して前記管理用データベースに再登録させる再登録ステップを備えた検索方法。

技術分野

0001

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

背景技術

0002

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

発明が解決しようとする課題

0003

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

0004

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

課題を解決するための手段

0005

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

0006

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

0007

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

0008

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

0009

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

0010

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

0011

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

0012

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

0013

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

0014

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

0015

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

0016

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

0017

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

0018

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

発明を実施するための最良の形態

0019

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

0020

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

0021

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

0022

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

0023

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

0024

検索サーバ20は、検索クライアント10からの検索要求に応じて検索対象データベース250を検索し、その検索結果を出力するコンピュータ装置である。検索サーバ20は、例えば、検索登録部210と、検索スケジューラ220と、検索実行部230と、終了時刻予測部240と、検索対象データベース250と、検索状況管理データベース260と、検索結果記憶部270と、分割定義記憶部280と、再分割定義記憶部290と、を備えて構成することができる。

0025

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

0026

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

0027

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

0028

検索実行部230による検索結果は、検索結果記憶部270に記憶される(S7)。各検索要求の処理結果は、各検索要求毎の検索結果ファイル271として、検索結果記憶部270にそれぞれ記憶される。検索実行部230は、検索状況管理データベース260にアクセスし、検索が終了した検索要求のステータスを「実行待ち」から「実行中」を経て「実行完了」に変更させる。

0029

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

0030

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

0031

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

0032

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

0033

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

0034

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

0035

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

0036

記憶部22には、例えば、分割定義ファイル281と、再分割定義ファイル291と、検索状況管理データベース260と、検索結果ファイル271と、検索対象データベース250とが、それぞれ記憶されている。

0037

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

0038

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

0039

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

0040

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

0041

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

0042

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

0043

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

0044

検索サーバ20は、検索クライアント10から入力された検索要求D10を受信して受け付け(S11)、発行元端末を確認する(S12)。検索サーバ20は、検索要求D10のヘッダに含まれる発行元アドレスを参照することにより、その検索要求がいずれの部店1から発行されたものであるかを確認することができる。また、検索サーバ20は、検索要求D10を受信した日時を確認する(S13)。

0045

そして、検索サーバ20は、検索識別コード(ID)を発行する(S14)。検索識別コードD20は、例えば、発行元部店コードD21と、検索要求日時(検索要求受信日時)D22と、連続番号D23とを含んで構成することができる。発行元部店コードD21は、その検索要求D10が発行された部店1を特定するためのコードである。検索システム内において、発行元部店コードD21は一意に設定される。検索要求日時D22とは、その検索要求D10を検索サーバ20が受信した日時を示す情報である。受信日時は、検索サーバ20内のタイマや外部の時計サーバから取得することができる。連続番号D23とは、各検索要求毎に連続して付与される番号を示す。検索クライアント10は、検索サーバ20から返信された検索識別コードD20を記憶部12に記憶させる。以後、検索クライアント10は、検索識別コードD20を検索キーに使用して、検索状況管理データベース260や検索結果記憶部270内を検索することができる。

0046

検索サーバ20は、検索識別コードD20を発行した後、検索要求をn×m個の検索要求(子検索要求)に分割し、各子検索要求にそれぞれ枝番を設定する(S15)。分割された検索要求は、検索状況管理データベース260に記憶される。

0047

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

0048

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

0049

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

0050

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

0051

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

0052

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

0053

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

0054

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

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

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

0062

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

0063

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

0064

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

0065

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

0066

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

0067

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

0068

ここで、n,mは、ともに2以上の自然数である。本実施例では、説明の便宜上、n,mをそれぞれ「3」に設定しているが、本発明はこれに限られない。本実施例では、検索クライアント10から入力された検索要求を9個(=3×3)に分割して検索状況管理データベース260に登録するが、9個未満または10個以上に分割して登録する構成でもよい。n,mは互いに等しい値である必要はない。

0069

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

0070

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

0071

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

0072

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

0073

検索クライアント10は、ユーザによって指定された情報に基づいて、検索要求を生成し、これを検索サーバ20に送信する(S22)。検索登録部210は、検索クライアント10から発行された検索要求を受信して受け付け(S23)、検索IDを発行して検索クライアント10に通知する(S24)。検索クライアント10は、この検索IDを記憶する(S25)。

0074

検索登録部210は、分割定義ファイル281を参照して(S26)、検索要求を所定数の子検索要求に分割し(S27)、これら各子検索要求を検索状況管理データベース260にそれぞれ登録させる(S28)。

0075

図11は、検索スケジューラ220によるスケジュール管理処理を示すフローチャートである。検索スケジューラ220は、例えば、比較的短い周期で、検索状況管理データベース260を参照する(S31)。

0076

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

0077

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

0078

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

0079

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

0080

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

0081

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

0082

番目に示されている親検索要求は、当日(7月1日)の午前9時に受け付けられ、当日の実行が指定されたものである(ID11)。2番目に受け付けられた親検索要求(ID12)は、翌日(7月2日)の実行が指定されたものである。3番目に受け付けられた親検索要求(ID13)は、当日の実行が指定されたものである。4番目に受け付けられた親検索要求(ID14)は、当日の実行が指定されており、続行指定もされている。5番目に受け付けられた親検索要求(ID15)は、当日の実行が指定されており、続行指定はされていないものである。なお、ID11,ID12,ID13もそれぞれ続行指定されていないが、ここで挙げる例では問題とならないため、図示を省略している。

0083

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

0084

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

0085

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

0086

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

0087

図13(a)にも示すように、第1回目のn個の子検索要求については検索が終了したが、第2回目のn個の子検索要求を検索中に、サービス時間が終了となった場合を考える。この場合は、第2回目及び第3回目に検索されるはずだった合計6個の子検索要求について、未処理となる。図13(b)に示すように、翌日の検索サービスが開始されると、これら未処理の子検索要求について、複数段階に分けてそれぞれ処理される。

0088

図14は、検索実行部230による検索処理を示すフローチャートである。検索実行部230は、検索スケジューラ220から検索実行の指示を受領すると(S41:YES)、各検索部231に検索条件及び検索範囲を入力して検索を開始させる(S42)。

0089

検索実行部230は、検索が開始されると、検索状況管理データベース260にアクセスし、検索が開始された子検索要求のステータスを「実行待ち」から「実行中」に変化させる(S43)。また、検索実行部230は、検索が開始された子検索要求の検索開始時刻を、検索状況管理データベース260に登録させる(S44)。

0090

検索実行部230は、検索が正常に終了したか否かを判定する(S45)。検索が正常に終了した場合(S45:YES)、検索結果ファイル271が検索結果記憶部270に記憶される(S46)。検索実行部230は、検索状況管理データベース260にアクセスし、検索が正常に終了した子検索要求のステータスを「実行中」から「実行完了」に変化させる(S47)。また、検索実行部230は、検索が正常に終了した子検索要求の検索終了時刻を、検索状況管理データベース260に登録させる(S48)。

0091

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

0092

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

0093

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

0094

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

0095

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

0096

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

0097

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

0098

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

0099

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

0100

検索スケジューラ220は、検索状況管理データベース260を参照して(S75)、ステータスが「中断」に変更された検索要求を発見すると(S76:YES)、その検索要求が既に検索中であるか否かを判定する(S77)。

0101

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

0102

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

0103

図17は、終了時刻を予測する処理を示すフローチャートである。終了時刻予測部240(以下「予測部240」とも呼ぶ)は、予測対象の親検索要求を選択し(S91)、検索状況管理データベース260を参照して(S92)、予測対象の親検索要求について検索が開始されているか否かを判定する(S93)。

0104

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

0105

次に、予測部240は、その親検索要求について、既に検索が正常に終了した子検索要求が存在するか否かを判定する(S95)。検索実行済の子検索要求が存在する場合(S95:YES)、予測部240は、その実行済の子検索要求の検索に要した検索時間tsを算出する(S96)。実行済の子検索要求が複数存在する場合、各検索所要時間の平均値が算出される。

0106

これに対し、例えば、親検索要求の検索開始直後で、未だ実行済の子検索要求が一つも存在しない場合(S95:NO)、予測部240は、検索時間tsとして初期値t0を採用する(S97)。この初期値t0は、タイムアウト検出用の閾値と等しい値に設定することができる。一例として、t0=タイムアウト検出用閾値=60分程度に設定する。

0107

次に、予測部240は、次のブロック(子検索要求の組)の検索開始時刻TNを算出する(S98)。次ブロックの検索開始時刻TNとは、次の回の検索が開始される時刻であり、TN=TL+tsとして求めることができる。

0108

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

0109

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

0110

予測部240は、親検索要求の終了予定時刻TEを、次ブロックの検索開始時刻TNと、実行待ちブロック数BNと、検索時間tsとに基づいて算出する(S100)。この算出には、TE=TN+(BN×ts)の式を使用することができる。予測部240は、算出された終了予定時刻TEを検索状況管理データベース260に登録させる(S101)。

0111

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

0112

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

0113

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

0114

既に開始された子検索要求の検索開始時刻TLは09:00である。また、実行済の子検索要求が存在しないため、検索時間tsには初期値(60分)が使用される。実行待ちの子検索要求の総数は、8(=9−1)個であり、一回あたりに選択される基準数nは3であるから、実行待ちブロックの数BNは「3」となる。次ブロックの検索開始時刻TNは、TL(09:00)に検索時間ts(60分)を加えることにより、10:00となる。従って、図19に示す例では、検索終了予定時刻TEは、13:00となる(TE=10:00+60分×3)。

0115

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

0116

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

0117

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

0118

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

0119

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

0120

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

0121

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

0122

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

0123

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

0124

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

0125

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

0126

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

0127

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

0128

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

0129

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

0130

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

0131

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

0132

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

0133

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

0134

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

0135

また、図24(a)に示すように、検索リソースを複数の検索リソース群に分割し、一方の検索リソース群を一方の親検索要求SAに割り当て、他方の検索リソース群を他方の親検索要求SBに割り当てる構成でもよい。さらに、図24(b)に示すように、検索要求の検索範囲や優先度等に応じて、各親検索要求SA,SBに割り当てる検索リソースの数を調節する構成でもよい。

0136

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

図面の簡単な説明

0137

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

符号の説明

0138

1…組織単位(部店)、2…LAN、3…通信ネットワーク、10…検索クライアント、11…情報処理部、12…記憶部、20…検索サーバ、21…情報処理部、22…記憶部、111…検索要求プログラム、112…検索結果表示プログラム、210…検索登録部、210P…検索登録プログラム、220…検索スケジューラ、220P…検索スケジューラプログラム、230…検索実行部、230P…検索プログラム、231…検索部、240…終了時刻予測部、240P…終了時刻予測プログラム、250…検索対象データベース、251…顧客属性データベース、252…顧客取引データベース、260…検索状況管理データベース、270…検索結果記憶部、271…検索結果ファイル、280…分割定義記憶部、281…分割定義ファイル、281A…エリア分割定義ファイル、290…再分割定義記憶部、291…再分割定義ファイル、D10…検索要求、D20…検索識別コード

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ