JP2013069213A - 検索要求処理装置 - Google Patents

Abstract

【課題】負荷が高い場合でも検索処理の高いスループットを実現しつつ、レスポンス時間の増加を抑制することのできる検索要求処理装置を提供する。
【解決手段】クライアント端末から検索要求を受信すると、現在実行している一括検索に該検索要求を併合する場合としない場合のレスポンス時間を計算し、一括検索に該検索要求を併合したほうが有利な場合にのみ、一括検索に該検索要求を併合して検索処理を行う。あるいは、検索要求は必ず一括検索に併合するとし、一括検索のレスポンス時間が短くなるように、検索対象のデータのグループへの分割数を変更する。
【選択図】図５

Description

以下の実施形態は、検索要求を処理する検索要求処理装置に関する。

今日、情報のデジタル化が進み、従来紙媒体等で保管されていた文書が電子化され、データベースに格納されるようになってきた。文書を電子化することにより、文書の内容を機械で検索することができるようになり、情報検索の利便性が非常に高くなった。

従来のデータ検索で、多くのユーザがアクセスするデータベース１０においては、処理すべき検索要求が多くなるが、それだけ検索結果を返送するレスポンス時間が多くかかってしまうという問題がある。

また、検索対象のデータを参照して、参照されたデータに対して複数の検索要求に基づく検索処理をまとめて行なう検索技術（一括検索技術）がある。
なお、多重度は、１度に処理が要求される検索要求の件数である。

一括検索を行なう従来の方法として、Aho-Corasick法文字列探索アルゴリズムの一種がある。これは、検索対象のデータのサイズに比例した時間で検索でき、検索キーワード（検索したい文字列）の数に依存しない高速な検索処理手法である。

一括検索のその他の情報については、例えば、以下のウェブサイトを参照されたい。
http://d.hatena.ne.jp/naoya/20090405/aho_corasick
http://ja.wikipedia.org/wiki/エイホ-コラシック法
従来技術には、受信したトランザクションを所定の条件が満たされるまでスタックしておき、この条件が満たされたら、スタックされていたトランザクションを一括して処理するものがある。

特開平３−１０５５４４号公報 特開２００２−２２２１９４号公報

Alfred V. Aho, Margaret J. Corasick "Efficient String Matching: An Aid to Bibliographic Search", Comm. ACM, 1975

一括検索技術は、負荷が高い場合には、検索処理のレスポンス時間を一定値以下に保証しつつ高いスループットを実現する効率が良い技術である。しかし、検索処理のレスポンス時間が、一括検索処理時間の最大2倍と大きくばらつく。

１つの側面では、本発明は、レスポンス時間の増加を抑制することを目的とする。

以下の実施形態の一側面における検索要求処理装置は、検索対象のデータを格納するデータ格納部と接続された検索要求処理装置であって、クライアント端末からの検索要求を受信する要求受信部と、該検索対象のデータに対し一括検索を行う一括検索部と、現在行なっている該一括検索に新たに受信した該検索要求を併合して該一括検索を実行する場合と該検索要求を該一括検索に併合しないで該検索要求を待機させる場合についてレスポンス時間を計算し、併合する場合の方が併合しない場合よりも該レスポンス時間が短くなる場合に、該検索要求を該一括検索に併合する検索制御部とを備える。

以下の実施形態における別の側面の検索要求処理装置は、複数のグループに分割された検索対象のデータを格納するデータ格納部と接続された検索要求処理装置であって、クライアント端末からの検索要求を受信する要求受信部と、該検索対象のデータに対し一括検索を行う一括検索部と、現在行なっている該一括検索に新たに受信した該検索要求を併合して該一括検索を実行する場合についてレスポンス時間を計算し、該レスポンス時間が短くなるように、該複数のグループの分割数を変更する検索制御部とを備える。

１態様によれば、レスポンス時間の増加を抑制することができる。

従来のデータ検索要求の処理方式を説明する図である。 多くのアクセスが集中した場合のレスポンス時間の遅れを解消しようとする従来技術の一例を説明する図である。 一括検索におけるレスポンス時間について説明する図である。 本実施形態に従った検索要求処理装置を含むシステム構成図である。 本実施形態の一構成例に従った全体処理のフローチャートである。 データ構造図である。 要求受付け部の処理のフローチャートである。 検索制御部・一括検索実行部の処理のフローチャートである。 検索制御部・一括検索実行部の処理のフローチャートである。 本実施形態の別の構成例に従った、検索制御部、一括検索実行部の処理のフローチャートである。 本実施形態の別の構成例に従った、検索制御部、一括検索実行部の処理のフローチャートである。 区間数の決定方法を示した図である。 区間数の変化の様子を示した図である。 本実施形態をプログラムで実現する場合の、プログラムを実行するコンピュータのブロック構成図である。

まず、データ検索要求の処理方式について図１を用いて説明する。
データベース１０に検索対象データが格納される。複数のユーザは、クライアント端末１２より、自分の検索したい条件（１）〜（１００）をそれぞれ設定し、検索要求を検索要求処理装置１１に送信する。検索要求処理装置１１は、データベース１０内の検索対象データを検索条件に従って検索し、検索結果をクライアント端末１２に返送する。この場合、検索要求処理装置１１は、検索条件を１つずつ順番にしか処理できないので、検索条件（１）について検索処理している場合には、他のユーザが、検索条件（２）〜（１００）を有する検索要求を送信しても、検索条件（１）の検索処理が終了するまで待たされることになる。したがって、多くのユーザがアクセスするデータベース１０においては、処理すべき検索要求が多くなるが、それだけ検索結果を返送するレスポンス時間が多くかかってしまうという問題がある。

図１の右に示されたグラフは、横に検索要求件数、縦に検索時間をとって、検索時間のバラツキを示したものである。検索要求が１つずつしか処理できない場合には、検索要求が増えるに従い、検索時間が様々な要因で変化し、バラツキが多くなる。なお、多重度は、１度に処理が要求される検索要求の件数である。

図２は、多くのアクセスが集中した場合のレスポンス時間の遅れを解消しようとする一括検索技術の一例を説明する図である。
図２の技術は、アクセスが集中して負荷が高いとき（時間当たりに到着する検索要求の数が多いとき）でも、レスポンスの低下を防ぎ、高いスループットを実現しようとする技術である。

図２においては、検索要求処理装置１１ａは、複数のクライアント端末１２から到着する検索要求を、それぞれ1つずつ順に処理するのではなく、複数の検索要求を併合して処理（検索）する（以降、一括検索と呼ぶ）。

これによって、検索対象データを参照する回数が、併合された検索要求の複数について1度だけとなり、負荷が高い場合でも一定のレスポンス時間で結果を返すことができる。
一括検索を行うため、一括検索中に到着する複数の検索要求の処理は、実行中の一括検索の後になる。一括検索が終了した後、溜まっている検索要求を併合して、次の一括検索処理を行う。

図２右側のグラフは、横に検索要求件数、縦に検索時間をとって、検索時間のバラツキを示したものである。一括検索においては、複数の検索要求をまとめて一括検索を行なうので、１つの検索要求の待ち時間が短く、検索要求が多くなっても、検索時間はそれほど大きく変わることなく処理することができる。

図３は、一括検索におけるレスポンス時間について説明する図である。
図３において、検索要求ｑ１〜ｑ６が順次、一括検索を行なう検索要求処理装置に入力されたとする。最初、検索要求ｑ１が到着したので、検索要求ｑ１の処理を開始する。そして、検索要求ｑ１の処理が終了する前に、検索要求ｑ２、ｑ３が順番に到着する。すると、検索要求ｑ１を処理している間は、他の検索要求は処理できないので、検索要求ｑ２、ｑ３は、検索要求ｑ１の処理の終了まで待たされることになる。検索要求ｑ１の処理が終わると、次に、検索要求ｑ２、ｑ３をまとめて一括検索処理する。この間に、検索要求ｑ４〜ｑ６が到着する。検索要求ｑ２、ｑ３の一括検索処理が終了すると、検索要求ｑ４〜ｑ６までをまとめて一括検索処理する。

今、検索要求ｑ２に注目すると、検索要求ｑ２が到着してから、検索要求ｑ３との一括検索が始まるまでの待ち時間は、最大（ｑ１の到着直後にｑ２が到着）の場合、検索要求ｑ１の処理時間だけかかる。そして、検索要求ｑ２、ｑ３の一括検索が始まってから終了するまでの処理時間がレスポンスを得るまでにかかる。１つの検索要求の処理であろうと、一括検索の処理であろうと、データベースの検索対象データを一通り検索するのにかかる時間はほぼ同じであるので、検索要求ｑ２のレスポンス時間は、最大の待ち時間と検索処理時間を加えて、最大、一括検索処理時間の２倍となる。

検索要求が到着するたびに、一括検索を一時停止し、到着した検索要求を実行中の一括検索処理に加える（全体の検索要求を併合しなおして一括検索する）方法が考えられる。この方法では、負荷が低い場合には、待ち時間の削減による、検索処理のレスポンス時間の減少と、検索処理のレスポンス時間のばらつきを無くすことができる。しかし、検索要求の数が増え、負荷が高くなると、一括検索処理の一時停止による時間が増加していき、負荷が高い場合の検索処理の平均レスポンス時間が増加してしまう。

本実施形態の一構成例においては、新たな検索要求が到着するたびに、一括検索処理へ追加（検索要求の併合）を常に行うのではなく、そのときの負荷に応じて、一括検索処理へ追加するかどうかを決める。

まず、一括検索処理の一時停止にかかる時間を計測する。そして、例えば、過去の一時停止時間から、今回の一時停止時間を予測（計算）する。一時停止時間の予測値として、例えば、過去の複数回の一時停止時間の平均値を用いる。次に、一括検索処理にかかる時間を計測する。そして、例えば、過去の一括検索時間から、実行中の一括検索が終了する時間を予測（計算）する。一括検索が終了する時間の予測値としても、例えば、過去の複数回の一括検索時間の平均値を用いる。

また、新たな検索要求が到着した場合に、一時停止時間の予測値と実行中の一括検索の終了時間の予測値から、この時点で一括検索処理を一時停止して一括検索処理に検索要求を追加したと仮定した場合の、実行中の検索要求のレスポンス時間の増加量を計算する（追加する場合の悪影響・デメリットを計算する）。更に、新たな検索要求が到着した場合に、一時停止時間の予測値と一括検索の終了時間の予測値から、この時点で一括検索処理を一時停止して一括検索処理に検索要求を追加したと仮定した場合の、今回到着した検索要求のレスポンス時間の減少量を計算する（追加する場合の効果・メリットを計算する）。

そして、両者から、この時点で一括検索処理を一時停止して一括検索処理に検索要求を追加した場合の全体のレスポンス時間の変化を計算する。レスポンス時間が減少するならば、実行中の一括検索処理を一時停止させ、到着した検索要求を一括検索処理に加える。レスポンス時間が増加するならば、到着した検索要求は一括検索処理に加えずに、実行を保留する（待たせる）。

以上のような本実施形態によって、検索処理の高いスループットと個々の検索処理の短いレスポンス時間のどちらを優先するかを、そのときの負荷に応じて自動的に計算して実現する。

これによれば、検索システムの利用者にとっては、検索レスポンス時間が削減され、検索レスポンスのばらつきが減少する。また、検索システムの運用側にとっては、検索レスポンス時間の削減にもかかわらず、負荷が高い場合の高いスループットが維持される。そして、検索システムを含む業務システムの設計者にとっては、検索システム自身が、そのときの負荷に応じて自動的に振舞いを変えることで、設計時の見積もりや検証のコストが減る。

あるいは、本実施形態の他の構成例としては、新たに到着した検索要求は必ず一括検索に併合するとし、一括検索を行なうデータの処理単位を、レスポンス時間が短くなるように設定することも可能である。検索対象のデータをグループ分けして、一括検索の処理単位をこのグループ単位とすることが可能であり、このグループへの分割数を、レスポンス時間がより短くなるように可変するというものである。

図４は、本実施形態に従った検索要求処理装置を含むシステム構成図である。
本実施形態の検索要求処理装置は、検索要求を受け付ける要求受付部２０、検索結果をクライアント端末に返却する結果返却部２１、検索処理の仕方の制御を行なう検索制御部２２、一括検索を実行する一括検索実行部２４からなり、これに、検索データを格納するデータ格納部２３（データベース）を備えて、システムが構成される。

要求受付部２０は、クライアント端末からの検索要求を受信し、検索要求キューに格納する。検索要求は、検索要求キューから取り出され、検索制御部２２に送られる。検索制御部２２は、要求受付部２０から送られてきた、検索待機中の検索要求の集合を保持する。また、検索制御部２２は、現在一括検索中の検索要求の集合も保持する。更に、検索制御部２２は、データ格納部２３に格納されている格納データの集合をグループに分割して、グループ単位で検索を実行させるために、各グループを検索区間としてＩＤを付し、検索要求とその検索要求の検索開始区間ＩＤとの対応関係を保持する。

一括検索実行部２４は、複数の検索要求を併合した一括検索用の検索要求を保持する。データ格納部２３は、格納データの集合を保持すると共に、検索区間ＩＤとその区間に含まれるデータの集合との対応関係を保持する。

図５は、本実施形態の一構成例に従った全体処理のフローチャートである。
検索は、いくつかの区間に分割された格納データ集合について1区間ずつ行い、かつ、全体を循環しながら一括検索処理を行う。

ステップＳ１０において、新たな検索要求が到着したか否かを判断する。ステップＳ１０の判断で、到着していないと判断された場合には、ステップＳ１２に進む。ステップＳ１０で、新たな検索要求が到着したと判断された場合、ステップＳ１１で、その検索要求を検索待機中の検索要求集合に加える。

ステップＳ１２において、検索待機中の検索要求を一括検索処理に加えた場合の、平均レスポンス時間の変化を計算する。平均レスポンス時間が減少すると判断された場合、ステップＳ１３に進む。その他の場合には、ステップＳ１５に進む。ステップＳ１３で、検索待機中の検索要求集合内の検索要求を一括検索中の検索要求集合に移動して、ステップＳ１４で、一括検索中の検索要求集合内の全ての検索要求を併合して、併合された検索要求を作成する。

ステップＳ１５で、検索待機中の検索要求集合内の検索要求を移動したかどうかに関わらず、現在の併合された検索要求を用いて一括検索処理を一区間実施する。ステップＳ１６で、検索が終了した検索要求があれば、一括検索中の検索要求集合からその検索要求を取り除き、ステップＳ１０に戻る。

ステップＳ１２で、平均レスポンス時間が減少しないため、待機中の要求を一括処理に加えないと判断された場合、検索待機中の検索要求集合に検索要求が増えていくが、一括検索処理が進むことにより、一括検索中の検索要求は減っていき最終的にはゼロになる。一括検索中の検索要求が減っていけば、検索待機中の検索要求を一括処理に加えることによるデメリットが減少するため、ステップＳ１２で平均レスポンス時間が減少すると判断し、検索待機中の検索要求は、いずれは必ず一括検索処理される。

図６は、データ構造図である。
格納データ集合３０は、データベース等、システムに格納されているデータそのものである。区間ID３６は、格納データ集合３０を複数のレコードごとにグループに分け、各グループを検索区間としてみたときの区間を特定する識別子である。一括検索中の検索要求集合３１は、検索処理実行中の検索要求で、かつ、まだ検索処理が終了していない検索要求の集合を表す。区間IDとデータ集合の対応３２は、格納データ集合３０をグループに分類したそれぞれを示す区間IDと、その区間に分類されたデータの対応関係を表す。次の一括検索実施区間ID３３は、レコードを先頭から順番に巡回しながら一括検索を行っている一括検索処理が、次に検索対象とする区間を表す。検索待機中の検索要求集合３４は、一括検索処理に加えられるのを待っている検索要求を表す。検索要求と検索開始区間ＩＤの対応３５は、検索要求が一括検索要求に併合され、検索を開始した区間の区間IDとの対応を示す。

図７は、要求受付け部の処理のフローチャートである。
要求受付け部は、ステップＳ２０において、利用者が使用するクライアント端末から検索要求を受信するまで待ち、受信した場合には、この要求を受付け、ステップＳ２１において、検索要求キューに追加する。

図８Ａ、Ｂは、検索制御部・一括検索実行部の処理のフローチャートである。
図８Ａ、Ｂの処理は大きく、検索要求の取出し処理（Ｓ２５〜Ｓ２７）、検索要求の開始処理（Ｓ２８〜Ｓ３１）、一括検索の実行（Ｓ３２〜Ｓ３３）、検索要求の終了処理（Ｓ３４〜Ｓ３６）に分けられる。

ステップＳ２５において、検索要求キューをチェックして、新たな検索要求がある場合は検索要求の取出し処理を実施する。すなわち、ステップＳ２５で、検索要求キューが空であると判断された場合には、ステップＳ２８に進む。ステップＳ２５で、検索要求があると判断された場合には、ステップＳ２６において、検索要求キュー内の検索要求を全て取り出し、ステップＳ２７において、取り出した検索要求を検索待機中の検索要求集合へ加え、ステップＳ２８に進む。

ステップＳ２８において、検索待機中の検索要求集合を一括検索処理に加えるか否かの判定を行なう。加えない場合には、ステップＳ３２に進む。検索待機中の検索要求を一括検索に加える場合は、実質的な検索要求の開始処理を実施する。

検索要求の開始処理では、新たな検索要求に対する情報が検索制御部の保持する情報に追加される。ステップＳ２９において、検索待機中の検索要求集合内の検索要求を一括検索中の検索要求集合に移動する。ステップＳ３０において、移動された検索要求に対しては、検索要求と検索実施区間IDの対応は、要求を受付けた時点での次の一括検索実施区間IDの示す区間に設定される。ステップＳ３１において、一括検索実施中の検索要求集合に含まれる検索要求を、図２で示したような従来技術における検索要求の併合技術を適用して検索要求を併合する。

次に、一括検索処理が一区間実行される。ステップＳ３２において、次の一括検索実施区間IDの示す格納データの区間に対して一括検索処理を実施する。ステップＳ３３において、次の一括検索実施区間を次の区間に変更し、ステップＳ３４に進む。ステップＳ３４〜Ｓ３６で、一括検索実行後、検索処理が終了した検索要求が存在すれば、検索要求の終了処理が行われる。

検索処理が終了したかどうかは、区間IDにより判断する。すなわち、ステップＳ３４において、検索要求と検索開始区間IDの対応を参照し、検索開始区間が次の一括検索実施区間に一致するものがあるか否か判定する。検索処理が開始したときの区間IDは検索要求と検索開始区間IDの対応を参照することで得られる。そのため、この区間IDと次の一括検索実施区間IDが等しくなった場合、その検索要求にとっての一括検索処理が検索データを一巡したことになり、検索処理が終了したと判断できる。

ステップＳ３４で、一致したものが無いと判断された場合には、ステップＳ２５に戻る。ステップＳ３４で、一致したものがある場合には、ステップＳ３５において、一致する検索要求に対する検索結果を結果返却部へ送る。ここでは、検索結果を最後にまとめて結果返却部へ送っているが、一区間ごとの検索結果を結果返却部に送るようにしてもよい。結果の返却が終わったら、ステップＳ３６において、その検索要求に対する情報を一括検索中の検索要求集合、検索要求と検索開始区間IDの対応から取り除き、ステップＳ２５に戻る。

以下に、図８ＡのステップＳ２８の判断手法を説明する。
ステップＳ２８の判断は検索制御部が実行する。
検索制御部で行う、検索待機中の検索要求を一括検索処理に加えるかどうかの判定の一例を示す。

以下の説明で使用する記号の意味は以下の通りである。
M： 格納データ集合の区間の数 [ 個 ]
L： 全区間に対する一括検索処理時間 [ 秒 ]
qs： 「一括検索中の検索要求集合」内の検索要求の数[ 個 ]
qw： 「検索待機中の検索要求集合」内の検索要求の数[ 個 ]

ある区間の検索を開始しようとしているとき、検索待機中の検索要求をこの区間で開始させるのか（一括検索に加えるのか）、次の区間以降で加えるのかどちらが良いかを判定する。

（１）メリットの計算
次の区間以降ではなく、現在の区間で検索要求を一括検索要求の集合に加えるとしたときのメリットは、検索待機中の検索要求の待ち時間が、1区間分の検索処理にかかる時間だけ減少し、それによって検索レスポンス時間が減少することである。

この減少量の総和 B [秒×個] は、1区間分の検索処理にかかる時間をL1 [ 秒 ] とすると、
B = L1 × qw
となる。
1区間分の検索処理にかかる時間は、全区間に対する一括検索処理時間 L から、以下のように計算できる。
L1 = L / M

全区間に対する一括処理時間 Lは、過去の一括検索処理にかかった時間を計測し、平均するなどして求めたり、格納データ集合の量とハードウェアの性能から計算して求めるなどする方法がある。ハードウェアの性能とは、例えば、ＣＰＵのクロックの周波数や、１バイトの検索にかかるクロック数などであり、格納データ集合の量とは、格納データのバイト数などであり、これらから、全区間に対する一括処理時間を見積もることができる。

（２）デメリットの計算
次の区間以降ではなく、現在の区間で検索要求を一括検索要求の集合に加えるとしたときのデメリットは、一括検索処理に検索要求を加える処理に必要な時間だけ、一括検索実行中の検索要求集合内に含まれる検索要求の処理の停止時間が増加し、それによって検索レスポンス時間が増加することである。

一括検索処理に検索要求を加える処理にかかる時間、すなわち停止時間を S [ 秒 ] とすると、検索レスポンス時間の増加量の総和 C [秒×個] は、
C = S × qs
となる。

停止時間Sは、例えば、過去の停止時間（一括検索処理に加える処理に要する時間）を計測するなどして求めたりすることが出来る。
また、例えば、従来技術では、一括検索に加える処理に要する時間は、一括検索を行う検索要求の数に比例するので、この数を基に停止時間を計算することも出来る。

（３）判定
（１）と（２）で計算したメリットとデメリットを比較し、メリットの方が多ければ、検索待機中の検索要求集合を一括検索処理に加えればよい。

検索制御部で行う、検索待機中の検索要求を一括検索処理に加えるかどうかの判定とは別の構成例を以下に示す。
上記の構成例では、格納データ集合をいくつかに分割しておき、その都度、一括検索処理に加えるかどうかを判定していた。

別の構成例では、ある区間の一括検索処理が終了した都度、到着した検索要求を一括検索処理に常に追加するようにする一方で、格納データ集合の分割の方法（分割数）を動的に変える。これによって、区間毎に判断を行わなくても、一括検索処理への追加のタイミングを制御することが出来る。

図９Ａ、Ｂは、本実施形態の別の構成例に従った、検索制御部、一括検索実行部の処理のフローチャートである。
ステップＳ４０において、検索要求キューをチェックし、新たな検索要求がある場合は検索要求の取出し処理を実施する。新たな検索要求が無い場合には、ステップＳ４５に進む。

ステップＳ４１において、検索要求キュー内の検索要求を全て取り出し、取り出した検索要求は、ステップＳ４２において、一括検索中の検索要求集合に加えられる。ステップＳ４３において、取り出した検索要求に対する検索開始区間IDを次の一括検索実施区間IDに対応させて設定する。そして、ステップＳ４４において、現在一括検索中の検索要求集合に含まれる検査要求が併合され、併合された検索要求を生成する。

加えられた検索要求があったかどうかに関わらず、ステップＳ４５において、次の一括検索実施区間IDの示す区間に対して一括検索処理を一区間実行する。一括検索実行後、検索処理が終了した検索要求が存在すれば、検索要求の終了処理が行われる。ステップＳ４６において、次の一括検索実施区間を次の区間に変更し、ステップＳ４７に進む。ステップＳ４７においては、検索要求と検索開始区間IDの対応を参照し、検索開始区間が次の一括検索実施区間に一致する検索要求があるか否かを判定する。

ステップＳ４７で、一致するものが無いと判断された場合には、ステップＳ５０に進む。ステップＳ４７で、一致するものがあると判断された場合には、ステップＳ４８において、一致する検索要求に対する検索結果を結果返却部へ送り、ステップＳ４９において、一致する検索要求を一括検索中の検索要求集合から取り除く。

ステップＳ５０において、一括検索処理が格納データについて一巡したか判定する。ステップＳ５０で、まだ一巡していないと判断された場合には、ステップＳ４０に戻る。ステップＳ５０で、一巡したと判断された場合には、ステップＳ５１において、区間と分割方法を変更し、区間IDと格納データ集合の対応を変更して、ステップＳ４０に戻る。

本構成例が図８Ａ、Ｂの例と異なる点は、定期的なタイミングで、区間の見直しを実施することである。図９Ａ，Ｂのフローチャートは、一括検索処理を一巡するタイミングで区間の分割方法を見直しする例である。このタイミングで必要ならば区間の分割方法を変更する。

以下に、区間の見直し方法の一例を示す。
図１０は、区間数の決定方法を、図１１は、区間数の変化の様子を示した図である。
以下の説明において使用する記号の意味は以下の通りである。
M： 格納データ集合の区間の数 [ 個 ]
L： 全区間に対する一括検索処理時間 [ 秒 ]
Q： 一括検索処理を一巡する間に到着する検索要求の数[ 個 ]

ここでは、適切な区間の数 M を求めるのが目的である。
区間の数 Mの値は、一括検索処理の途中で新たな検索要求を加えることによるメリット（効果）とデメリット（悪影響）を比較することで決まる。

（１）一括検索処理に加えることによるメリット
メリットは、新たに到着する検索要求が、一括検索処理に加えられるまでの待ち時間が減少することである。

待ち時間の平均値は、1区間を一括検索処理する時間の２分の１に等しい。この平均値を ｗ1 [秒] とすると、
w1 = L / ( M × 2 )
となり、区間の数 M に反比例する。Mを増やすほど待ち時間は減少するが、その減少量はだんだんと小さくなっていく。ここで、Ｍが２倍されているのは、待ち時間を２分の１にすることであるが、待ち時間は、全く待たない場合から、１区間を一括検索処理する全時間待つ場合がある。この待ち時間の分布はランダムであると考えられるから、平均として、１区間を一括検索処理する時間の半分を待ち時間とするのが適当と考えたものである。

一巡の一括検索処理（全ての区間に対する一括検索処理)全体におけるこの待ち時間の総和を W [秒×個] とすると、平均して
W = w1 × Q = Q × L / （ M × 2 ）
となる。

（２）デメリット
デメリットは、区間の数 M を増やすことによる、一括検索処理の停止時間の増加である。したがって、一括検索処理の停止時間の総和を式で表す。

区間と区間の間での一回の停止時間を s1[ 秒 ]としたとき、全ての区間に対する一括処理における停止時間の総和 S[秒×個] （のべの停止時間）は
S = s1 × Q × M
となり、区間の数 M に比例して多くなる。

（３）判定
（１）と（２）で計算した待ち時間の総和と停止時間の総和の合計が最も小さくなるときの区間の数 M を求めればよい。図１０は、横軸に区間の数、縦軸に時間をとって、上記メリットの式とデメリットの式と、これらの和の式のグラフを示したものである。図１０において、待ち時間と停止時間の和が最小になる場合の区間の数Mが求めたい値である。Ｍについて、和の式を微分し、微分した式を０とおいて、Ｍについて式を整理する。

これを計算すると、
M = √（ L/ （ 2 × s1） ）
となる。

一括検索処理のアルゴリズムとしては、例えば、aho-corasick法を用いる場合、一括検索処理の途中で新たな検索要求を加える時間、すなわち停止時間s1は、一括検索処理に含まれる検索要求の数に依存して増加する。各検索要求の複雑さが同程度ならば、停止時間は、一括検索処理に含まれる検索要求の数に比例して増加する。

ある区間を一括検索処理しようとする検索要求の数は、平均的には、一括検索処理を一巡する間に到着する検索要求の数 Q に等しい（各検索要求は、どの区間から検索を開始したとしても、全ての区間を検索するまでは処理を終えないため）。よって、停止時間 s1 は、
s1 = Q × α
となる。ここでαは、検索要求1つにつきかかる停止時間を表す定数である。

過去に計測した一括検索処理時間 L と、停止時間 s1 を基にMを計算しなおす場合、過去と比較して負荷の変動（到着する検索要求の数 Q の増減）が見られる場合、一区間あたりの停止時間 s1 が 検索要求の数 Q に比例する性質を利用して、計測した停止時間s1 を補正することが出来る。

計測された停止時間を s1’ 、そのときの検索要求の数を Q’ とし、現在の検索要求の数を Q とすると、補正された後の停止時間 s1 は、
s1 = s1’ × Q / Q’
となる。

この値を基に区間の数 M を計算することで、負荷の変動に追随した区間の数の制御を行うことが出来る。
s1 を停止時間の総和 S の式に代入すると、
S = Q × α × Q × M
= α × Q² × M
となる。

待ち時間の総和 W の式は変わらないため、これらから M を求めると（M の式に代入すると）、
M ＝ √（ L / ( 2 × Q × α) ）
となり、 待ち時間と停止時間の総和が最も小さくなるときの区関の数 M は、Qが増えるほど小さくなる。図１１には、横軸を区間の数、縦軸を各検索要求の処理時間として、負荷（一括検索処理を一巡する間に到着する検索要求の数Ｑ）の増加と共に、Ｍが変化する様子を示している。図１１によれば、負荷が増加するほど、Ｍの値が小さくなっているのが分かる。

図１２は、本実施形態をプログラムで実現する場合の、プログラムを実行するコンピュータのブロック構成図である。
コンピュータ３９は、バス４０で相互に接続された、ＣＰＵ４１、ＲＯＭ４２、ＲＡＭ４３、ネットワークインタフェース４４、記憶装置４７、媒体ドライバ４８、入出力装置５０からなる。

ＲＯＭ４２には、コンピュータ３９を動作させるのに基本的なＢＩＯＳなどのプログラムが格納される。ＣＰＵ４１は、ＲＯＭ４２からＢＩＯＳなどを読み込んで、コンピュータ３９を動作させる。

ＲＡＭ４３には、実行すべきプログラムを、ＣＰＵ４１が実行可能なように展開する。ＲＡＭ４３には、プログラムの処理に必要となる作業領域が確保される。
記憶装置４７は、ハードディスクなどであり、ＯＳなどの基本的なプログラムから、本実施形態の処理を実現するプログラムなど様々なプログラムが格納される。記憶装置４７に格納されたプログラムは、ＲＡＭ４３に展開されて、ＣＰＵ４１により実行される。本実施形態の処理を実行するプログラムは、この記憶装置４７に格納することができる。

媒体ドライバ４８は、ＣＤ−ＲＯＭ，ＤＶＤ、Ｂｌｕ−ｒａｙ，フレキシブルディスク、ＩＣメモリ等の可搬記録媒体４９に格納されるプログラムを読み込む。本実施形態の処理を実行するプログラムは、可搬記録媒体４９に格納されていてもよく、媒体ドライバ４８によって可搬記録媒体４９から読み込まれたプログラムは、ＲＡＭ４３に展開されて、ＣＰＵ４１により実行される。

入出力装置５０は、キーボード、タブレットなどの入力装置と、ディスプレイ、プリンタ等の出力装置からなる。ユーザは、入力装置を使って入力操作を行い、プログラムによる処理結果を出力装置から得る。

ネットワークインタフェース４４は、ネットワーク４５を介して、コンピュータ３９を情報提供者４６の有するコンピュータやデータベース等と接続する。本実施形態のプログラムは、情報提供者４６からネットワーク４５を介してコンピュータ３９に提供されてもよい。この場合、プログラムは、記憶装置４７や可搬記録媒体４９に一旦格納された後、ＲＡＭ４３に展開されてＣＰＵ４１により実行されてもよい。または、情報提供者４６の有するコンピュータ上で実行され、コンピュータ３９からは、入出力装置５０を用いたデータの入出力を行なうだけの実行形態でもよい。

１０ データベース
１１ 検索要求処理装置
２０ 要求受付部
２１ 結果返却部
２２ 検索制御部
２３ データ格納部
２４ 一括検索実行部
３０ 格納データ集合
３１ 一括検索中の検索要求集合
３２ 区間IDとデータ集合の対応
３３ 次の一括検索実施区間ID
３４ 検索待機中の検索要求集合
３５ 検索要求と検索開始区間IDの対応
３６ 区間ID
ことを特徴とするプログラム。

Claims (11)

1. 検索対象のデータを格納するデータ格納部と接続された検索要求処理装置であって、
   クライアント端末からの検索要求を受信する要求受信部と、
   該検索対象のデータに対し一括検索を行う一括検索部と、
   現在行なっている該一括検索に新たに受信した該検索要求を併合して該一括検索を実行する場合と該検索要求を該一括検索に併合しないで該検索要求を待機させる場合についてレスポンス時間を計算し、併合する場合の方が併合しない場合よりも該レスポンス時間が短くなる場合に、該検索要求を該一括検索に併合する検索制御部と、
   を備えることを特徴とする検索処理装置。
2. 前記検索対象のデータはグループに分割され、前記一括検索は、該グループを単位に実行されることを特徴とする請求項１に記載の検索処理装置。
3. 前記一括検索は、前記検索対象のデータについて巡回的に行なうことを特徴とする請求項１に記載の検索処理装置。
4. 前記一括検索に含まれる前記検索要求は、前記検索対象のデータについて検索が一巡した場合に、該一括検索から分離されることを特徴とする請求項３に記載の検索処理装置。
5. 前記一括検索は、前記データ格納部から読み出したデータに対して、複数の検索要求に応じた検索を行なう処理である、
   ことを特徴とする請求項１〜４に記載の検索処理装置。
6. 複数のグループに分割された検索対象のデータを格納するデータ格納部と接続された検索要求処理装置であって、
   クライアント端末からの検索要求を受信する要求受信部と、
   該検索対象のデータに対し一括検索を行う一括検索部と、
   現在行なっている該一括検索に新たに受信した該検索要求を併合して該一括検索を実行する場合についてレスポンス時間を計算し、該レスポンス時間が短くなるように、該複数のグループの分割数を変更する検索制御部と、
   を備えることを特徴とする検索要求処理装置。
7. 前記分割数は、新たに到着する検索要求の数が多いほど、小さくなることを特徴とする請求項６に記載の検索要求処理装置。
8. 検索対象のデータを格納するデータ格納部と接続された検索要求処理装置における処理方法であって、
   該検索要求処理装置は、
   クライアント端末からの検索要求を受信し、
   該検索対象のデータに対し一括検索を行い、
   現在行なっている該一括検索に新たに受信した該検索要求を併合して該一括検索を実行する場合と該検索要求を該一括検索に併合しないで該検索要求を待機させる場合についてレスポンス時間を計算し、
   併合する場合の方が併合しない場合よりも該レスポンス時間が短くなる場合に、該検索要求を該一括検索に併合する、
   ことを特徴とする処理方法。
9. 複数のグループに分割された検索対象のデータを格納するデータ格納部と接続された検索要求処理装置における処理方法であって、
   該検索要求処理装置は、
   クライアント端末からの検索要求を受信し、
   該検索対象のデータに対し一括検索を行い、
   現在行なっている該一括検索に新たに受信した該検索要求を併合して該一括検索を実行する場合についてレスポンス時間を計算し、
   該レスポンス時間が短くなるように、該複数のグループの分割数を変更する、
   ことを特徴とする処理方法。
10. 検索対象のデータを格納するデータ格納部と接続された検索要求処理装置に処理を実行させるプログラムであって、
    該検索要求処理装置に
    クライアント端末からの検索要求を受信させ、
    該検索対象のデータに対し一括検索を行わせ、
    現在行なっている該一括検索に新たに受信した該検索要求を併合して該一括検索を実行する場合と該検索要求を該一括検索に併合しないで該検索要求を待機させる場合についてレスポンス時間を計算させ、
    併合する場合の方が併合しない場合よりも該レスポンス時間が短くなる場合に、該検索要求を該一括検索に併合させる、
    ことを特徴とするプログラム。
11. 複数のグループに分割された検索対象のデータを格納するデータ格納部と接続された検索要求処理装置に処理を実行させるプログラムであって、
    該検索要求処理装置に、
    クライアント端末からの検索要求を受信させ、
    該検索対象のデータに対し一括検索を行わせ、
    現在行なっている該一括検索に新たに受信した該検索要求を併合して該一括検索を実行する場合についてレスポンス時間を計算させ、
    該レスポンス時間が短くなるように、該複数のグループの分割数を変更させる、