JP2010152435A - 情報処理装置及び情報処理方法及びプログラム - Google Patents
情報処理装置及び情報処理方法及びプログラム Download PDFInfo
- Publication number
- JP2010152435A JP2010152435A JP2008326829A JP2008326829A JP2010152435A JP 2010152435 A JP2010152435 A JP 2010152435A JP 2008326829 A JP2008326829 A JP 2008326829A JP 2008326829 A JP2008326829 A JP 2008326829A JP 2010152435 A JP2010152435 A JP 2010152435A
- Authority
- JP
- Japan
- Prior art keywords
- processing
- data processing
- multiplicity
- data
- processing time
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】サービスシステム全体として検索要求に対する処理効率を向上させる。
【解決手段】各データ管理装置４に多重度が設定され、高い多重度では同時に処理できる検索要求数は多いが単一の検索要求に要する処理時間は長く、低い多重度では同時に処理できる検索要求数は少ないが単一の検索要求に要する処理時間は短い。サービスサーバ装置３は、ユーザ端末１からの検索要求ごとに処理時間を予想し、長い処理時間の検索要求は低い多重度のデータ管理装置４に、短い処理時間の検索要求は高い多重度のデータ管理装置４に割り当て、検索要求処理の効率を向上させる。短い処理時間の検索要求は、高い多重度のデータ管理装置４において処理が短時間で完了し、同時に実行する検索処理の数が多すぎても、検索要求を同時実行しない時と比べて処理時間があまり長くならず、全体として同時実行できる検索処理の数が増える。
【選択図】図１
【解決手段】各データ管理装置４に多重度が設定され、高い多重度では同時に処理できる検索要求数は多いが単一の検索要求に要する処理時間は長く、低い多重度では同時に処理できる検索要求数は少ないが単一の検索要求に要する処理時間は短い。サービスサーバ装置３は、ユーザ端末１からの検索要求ごとに処理時間を予想し、長い処理時間の検索要求は低い多重度のデータ管理装置４に、短い処理時間の検索要求は高い多重度のデータ管理装置４に割り当て、検索要求処理の効率を向上させる。短い処理時間の検索要求は、高い多重度のデータ管理装置４において処理が短時間で完了し、同時に実行する検索処理の数が多すぎても、検索要求を同時実行しない時と比べて処理時間があまり長くならず、全体として同時実行できる検索処理の数が増える。
【選択図】図１
Description
本発明は、各々がデータ処理を並行して実行できる複数のデータ処理装置を管理し、所定の基準に基づいて、ユーザから要求のあったデータ処理を実行させるデータ処理装置を選択する技術に関する。
ブロードバンド通信インフラの発達に伴い、ネットワーク経由で業務ソフトウェアの機能を提供するサービスが普及してきている。
複数ユーザが同時に検索を要求することが可能なデータ管理サービスを構築する場合、図１５に示すように、複数のデータ管理装置に対する検索要求を処理するサービスサーバを配置する。
図１５において、１００は、サービスシステムを利用するユーザのユーザ端末である。２００は、サービスシステムである。
サービスシステム２００の構成要素のうち、３００はサービスシステムを構成するサービスサーバである。
また、４００はサービスシステムを構成するデータ管理装置である。
ユーザ端末１００とサービスサーバ３００はインターネットやＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）等のネットワーク１０１で接続されている。
また、サービスサーバ３００と各データ管理装置４００はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）２０１で接続されている。
複数ユーザが同時に検索を要求することが可能なデータ管理サービスを構築する場合、図１５に示すように、複数のデータ管理装置に対する検索要求を処理するサービスサーバを配置する。
図１５において、１００は、サービスシステムを利用するユーザのユーザ端末である。２００は、サービスシステムである。
サービスシステム２００の構成要素のうち、３００はサービスシステムを構成するサービスサーバである。
また、４００はサービスシステムを構成するデータ管理装置である。
ユーザ端末１００とサービスサーバ３００はインターネットやＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）等のネットワーク１０１で接続されている。
また、サービスサーバ３００と各データ管理装置４００はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）２０１で接続されている。
サービスシステム２００においては、同時に発生する検索要求を同時に処理することによりサービスシステム全体としての応答性能を向上させるため、同じデータの複製を管理する複数のデータ管理装置４００を備える。
なお、図１５においては、データ管理装置４００は別々のコンピュータとして実現されているが、実施の都合によっては、同一コンピュータ上で複数のオペレーティングシステムを動作させる仮想マシン技術などを利用し、同一コンピュータ上で複数のデータ管理装置４００を稼働させてもよい。
同様に、仮想マシン技術などを利用し、サービスサーバ３００とデータ管理装置４００を同一コンピュータ上で稼働させてもよい。また、データ管理装置４００においては複数の物理的な記憶領域を備えていてもよい。
なお、図１５においては、データ管理装置４００は別々のコンピュータとして実現されているが、実施の都合によっては、同一コンピュータ上で複数のオペレーティングシステムを動作させる仮想マシン技術などを利用し、同一コンピュータ上で複数のデータ管理装置４００を稼働させてもよい。
同様に、仮想マシン技術などを利用し、サービスサーバ３００とデータ管理装置４００を同一コンピュータ上で稼働させてもよい。また、データ管理装置４００においては複数の物理的な記憶領域を備えていてもよい。
サービスサーバ３００は、検索要求受付部５００によりユーザ端末１００から検索要求を受け取り、個々のデータ管理装置４００に検索要求を割り当てる。
データ管理装置４００においては、サービスサーバ３００を介して送られてくるユーザの検索要求を、検索要求処理部６００が受け取り、データ８００の検索を実行する。
データ管理装置４００においては、サービスサーバ３００を介して送られてくるユーザの検索要求を、検索要求処理部６００が受け取り、データ８００の検索を実行する。
図１５に示すようなサービスシステムにおいては、以下に示す課題がある。
図１５において、個々のデータ管理装置４００は、複数ユーザによる検索要求の処理を同時実行（多重処理）することができるが、それぞれの処理は、同時に実行する検索処理の数が多すぎると、検索要求を同時実行しない時と比べて性能が低下することがある。
このため、データ管理装置４００は多重度制御部７００を持っており、同時実行できる処理の上限数（多重度）を設定している。
また、個々のデータ管理装置４００の多重度の設定を変更する場合、データ管理装置４００のハードウェア再起動など変更の反映に時間を要する場合がある。
特許文献１には、このような、多重度（特許文献１中では並列度と呼ばれる）を調整して、データ管理装置の検索処理を効率化する技術が示されている。
特開平９−３０５６３１号公報
図１５において、個々のデータ管理装置４００は、複数ユーザによる検索要求の処理を同時実行（多重処理）することができるが、それぞれの処理は、同時に実行する検索処理の数が多すぎると、検索要求を同時実行しない時と比べて性能が低下することがある。
このため、データ管理装置４００は多重度制御部７００を持っており、同時実行できる処理の上限数（多重度）を設定している。
また、個々のデータ管理装置４００の多重度の設定を変更する場合、データ管理装置４００のハードウェア再起動など変更の反映に時間を要する場合がある。
特許文献１には、このような、多重度（特許文献１中では並列度と呼ばれる）を調整して、データ管理装置の検索処理を効率化する技術が示されている。
特許文献１に記載の技術は、検索要求が同時に多発する際のシステム全体としての応答性能を改善するものではない。
つまり、検索要求の内容によって検索のためのデータ処理に要する時間は異なるが、特許文献１に記載の技術は、データ処理時間とデータ管理装置の多重度とを対応付けて管理していなため、個々の検索要求に対するデータ処理時間に応じて適切な多重度のデータ管理装置を選択することができず、このため、システム全体としての処理効率を向上させることができず、検索要求が同時に多発する状況において、検索要求に効率的に対処することができないという課題がある。
つまり、検索要求の内容によって検索のためのデータ処理に要する時間は異なるが、特許文献１に記載の技術は、データ処理時間とデータ管理装置の多重度とを対応付けて管理していなため、個々の検索要求に対するデータ処理時間に応じて適切な多重度のデータ管理装置を選択することができず、このため、システム全体としての処理効率を向上させることができず、検索要求が同時に多発する状況において、検索要求に効率的に対処することができないという課題がある。
本発明は、このような課題を解決することを主な目的とし、データ処理の処理時間に応じて最適な多重度のデータ処理装置にデータ処理を実行させ、システム全体としての処理効率を向上させて要求が同時に多発する状況においても適切に要求に対処することが可能な仕組みを実現する。
本発明に係る情報処理装置は、
各々が１つ以上のデータ処理を並行して実行できる複数のデータ処理装置を管理する情報処理装置であって、
データ処理装置ごとに、各データ処理装置が並行して実行できるデータ処理数と１つのデータ処理に要する処理時間との関係が多重度として示される多重度情報を記憶する情報記憶部と、
データ処理を要求するデータ処理要求を受信する受信部と、
前記受信部により受信されたデータ処理要求において要求されている要求データ処理に要する処理時間を予想する処理時間予想部と、
前記処理時間予想部により予想された前記要求データ処理の予想処理時間と前記多重度情報に示されている各データ処理装置の多重度とに基づき、前記要求データ処理を実行させるデータ処理装置を選択する選択部とを有することを特徴とする。
各々が１つ以上のデータ処理を並行して実行できる複数のデータ処理装置を管理する情報処理装置であって、
データ処理装置ごとに、各データ処理装置が並行して実行できるデータ処理数と１つのデータ処理に要する処理時間との関係が多重度として示される多重度情報を記憶する情報記憶部と、
データ処理を要求するデータ処理要求を受信する受信部と、
前記受信部により受信されたデータ処理要求において要求されている要求データ処理に要する処理時間を予想する処理時間予想部と、
前記処理時間予想部により予想された前記要求データ処理の予想処理時間と前記多重度情報に示されている各データ処理装置の多重度とに基づき、前記要求データ処理を実行させるデータ処理装置を選択する選択部とを有することを特徴とする。
本発明によれば、要求データ処理に要する処理時間を予想し、予想処理時間に応じて最適な多重度のデータ処理装置を選択することができ、このため、予想処理時間の短いデータ処理は多重度の高いデータ処理装置に割り当て、予想処理時間の長いデータ処理は多重度の低いデータ処理装置に割り当てることができ、システム全体としての処理効率を向上させて要求が同時に多発する状況においても適切に要求に対処することができる。
実施の形態１．
図１は、本実施の形態に係るシステム構成例を示す。
図１は、本実施の形態に係るシステム構成例を示す。
図１において、１は、サービスシステムを利用するユーザのユーザ端末である。２は、サービスシステムである。
サービスシステム２の構成要素のうち、３はサービスシステムを構成するサービスサーバ装置（以下、サービスサーバともいう）である。
また、４はサービスシステムを構成するデータ管理装置である。
ユーザ端末１とサービスサーバ装置３はインターネットやＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）等のネットワーク１０１で接続されている。
また、サービスサーバ装置３と各データ管理装置４はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）２０１で接続されている。
サービスシステム２の構成要素のうち、３はサービスシステムを構成するサービスサーバ装置（以下、サービスサーバともいう）である。
また、４はサービスシステムを構成するデータ管理装置である。
ユーザ端末１とサービスサーバ装置３はインターネットやＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）等のネットワーク１０１で接続されている。
また、サービスサーバ装置３と各データ管理装置４はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）２０１で接続されている。
サービスシステム２においては、同時に発生する検索要求を同時に処理することによりサービスシステム全体としての応答性能を向上させるため、同じデータの複製を管理する複数のデータ管理装置４を備える。
データ管理装置４は、各々、１つ以上の検索処理（データ処理）を並行して実行でき、並行して実行できる検索処理の数が多重度として表わされる。
各データ管理装置４は、多重度について、高い多重度と低い多重度という異なる設定を施している。
多重度は、各データ管理装置４が並行して実行できる検索処理数（データ処理数）と１つ検索処理に要する処理時間との関係を表す。高い多重度では、同時に（並行して）処理できる検索要求の数は多いが、単一の検索要求に要する処理時間は長くなり、低い多重度では、同時に（並行して）処理できる検索要求の数は少ないが、単一の検索要求に要する処理時間は短くなる。
データ管理装置４は、各々、１つ以上の検索処理（データ処理）を並行して実行でき、並行して実行できる検索処理の数が多重度として表わされる。
各データ管理装置４は、多重度について、高い多重度と低い多重度という異なる設定を施している。
多重度は、各データ管理装置４が並行して実行できる検索処理数（データ処理数）と１つ検索処理に要する処理時間との関係を表す。高い多重度では、同時に（並行して）処理できる検索要求の数は多いが、単一の検索要求に要する処理時間は長くなり、低い多重度では、同時に（並行して）処理できる検索要求の数は少ないが、単一の検索要求に要する処理時間は短くなる。
データ管理装置４においては、サービスサーバ装置３を介して送られてくるユーザの検索要求を、検索要求処理部６が受け取り、データ８の検索を実行する。
多重度制御部７は、実施の形態２において説明する。
データ管理装置４は、データ処理装置の例である。
多重度制御部７は、実施の形態２において説明する。
データ管理装置４は、データ処理装置の例である。
なお、図１においては、データ管理装置４は別々のコンピュータとして実現されているが、実施の都合によっては、同一コンピュータ上で複数のオペレーティングシステムを動作させる仮想マシン技術などを利用し、同一コンピュータ上で複数のデータ管理装置４を稼働させてもよい。
同様に、仮想マシン技術などを利用し、サービスサーバ装置３とデータ管理装置４を同一コンピュータ上で稼働させてもよい。
また、データ管理装置４においては複数の物理的な記憶領域を備えていてもよい。
同様に、仮想マシン技術などを利用し、サービスサーバ装置３とデータ管理装置４を同一コンピュータ上で稼働させてもよい。
また、データ管理装置４においては複数の物理的な記憶領域を備えていてもよい。
サービスサーバ装置３は、個々の検索要求について処理時間を予想し、長い処理時間を要すると予想する検索要求は低い多重度に設定したデータ管理装置４に、短い処理時間を要すると予想する検索要求は高い多重度に設定したデータ管理装置４に、それぞれ割り当てることにより、検索要求処理のスループットを向上させる。
これは、短い処理時間を要する検索要求であれば、高い多重度を設定したデータ管理装置４においても、個々の処理が短時間で完了し、同時に実行する検索処理の数が多すぎても、検索要求を同時実行しない時と比べて処理時間が著しく長くなることが少ないため、全体として同時実行できる検索処理の数が増えるためである。
サービスサーバ装置３は、情報処理装置の例である。
これは、短い処理時間を要する検索要求であれば、高い多重度を設定したデータ管理装置４においても、個々の処理が短時間で完了し、同時に実行する検索処理の数が多すぎても、検索要求を同時実行しない時と比べて処理時間が著しく長くなることが少ないため、全体として同時実行できる検索処理の数が増えるためである。
サービスサーバ装置３は、情報処理装置の例である。
サービスサーバ装置３において、検索要求受付部５は、ユーザ端末１から送信された検索要求（データ処理要求）を受信するとともに、後述する処理時間予想部９により予想された検索処理の予想処理時間と各データ管理装置４の多重度とに基づき、検索要求で要求されている検索処理を実行させるデータ管理装置を選択する。
前述したように、検索要求受付部５は、予想処理時間が短い検索処理ほど、並行して実行できる検索処理数が多く１つの検索処理に要する処理時間が長い多重度、すなわち高多重度のデータ管理装置を優先して選択する。
検索要求受付部５は、受信部及び選択部の例である。
前述したように、検索要求受付部５は、予想処理時間が短い検索処理ほど、並行して実行できる検索処理数が多く１つの検索処理に要する処理時間が長い多重度、すなわち高多重度のデータ管理装置を優先して選択する。
検索要求受付部５は、受信部及び選択部の例である。
処理時間予想部９は、検索要求受付部５により受信された検索要求において要求されている検索処理（要求データ処理）に要する処理時間を予想する。
情報記憶部１５は、データ管理装置４ごとに、各データ管理装置４が並行して実行できる検索処理数と１つの検索処理に要する処理時間との関係を多重度として示す多重度情報を記憶している。
図２に、本実施の形態に係るサービスサーバ３を用いて実現したサービスシステム２の機能間の処理シーケンスを示す。図２について説明する。
ステップ（１）：
ユーザが、ユーザ端末１からサービスサーバ３に検索要求を送る。
ユーザが、ユーザ端末１からサービスサーバ３に検索要求を送る。
ステップ（２）：
サービスサーバ３の検索要求受付部５は、ユーザ端末１からの検索要求を受信し、ステップ（１）の検索要求毎にスレッドを生成する（受信ステップ）。
サービスサーバ３の検索要求受付部５は、ユーザ端末１からの検索要求を受信し、ステップ（１）の検索要求毎にスレッドを生成する（受信ステップ）。
ステップ（３）：
検索要求受付部５がステップ（２）で生成したスレッドは、処理時間予想部９を呼び出し、ステップ（１）の検索要求の処理に要する時間の予想の実行を処理時間予想部９に要求する。
検索要求受付部５がステップ（２）で生成したスレッドは、処理時間予想部９を呼び出し、ステップ（１）の検索要求の処理に要する時間の予想の実行を処理時間予想部９に要求する。
ステップ（４）：
処理時間予想部９は、検索処理の予想処理時間を導出し、検索要求受付部５がステップ（２）で生成したスレッドに、導出結果を返す（処理時間予想ステップ）。
処理時間予想部９は、検索処理の予想処理時間を導出し、検索要求受付部５がステップ（２）で生成したスレッドに、導出結果を返す（処理時間予想ステップ）。
ステップ（５）：
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（４）で受け取った予想処理時間をもとに、新たな検索要求を割り当てることができるデータ管理装置４の有無を確認する。なお、この処理の流れについては後述する。
そして、新たな検索要求を割り当てることができるデータ管理装置４がなければ、いずれかのデータ管理装置４がこのような状態になるまで待機する。
この処理を行うために、情報記憶部１５は、図３に示すデータ管理装置管理テーブル１０を備え、検索要求受付部５はデータ管理装置管理テーブル１０を読み出し（情報読み出しステップ）、読み出したデータ管理装置管理テーブル１０を参照して、新たな検索要求を割り当てることができるデータ管理装置４の有無を確認する。
なお、データ管理装置管理テーブル１０は、情報記憶部１５の代わりに検索要求受付部５が保持するようにしてもよい。
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（４）で受け取った予想処理時間をもとに、新たな検索要求を割り当てることができるデータ管理装置４の有無を確認する。なお、この処理の流れについては後述する。
そして、新たな検索要求を割り当てることができるデータ管理装置４がなければ、いずれかのデータ管理装置４がこのような状態になるまで待機する。
この処理を行うために、情報記憶部１５は、図３に示すデータ管理装置管理テーブル１０を備え、検索要求受付部５はデータ管理装置管理テーブル１０を読み出し（情報読み出しステップ）、読み出したデータ管理装置管理テーブル１０を参照して、新たな検索要求を割り当てることができるデータ管理装置４の有無を確認する。
なお、データ管理装置管理テーブル１０は、情報記憶部１５の代わりに検索要求受付部５が保持するようにしてもよい。
データ管理装置管理テーブル１０は、データ管理装置４を特定する情報（図３では装置番号）、それぞれのデータ管理装置４の複数段階の多重度の設定（図３では多重度）、各データ管理装置４に新たな検索要求が割り当て可能かどうかを識別する情報（図３では処理中の検索要求）を保持する。
前述のとおり、原則として、高い多重度には短い処理時間の検索処理が割り当てられ、低い多重度には長い処理時間の検索処理が割り当てられる。
なお、図３では、図示を省略しているが、データ管理装置管理テーブル１０において、各多重度に対して処理時間の対象範囲を管理しておいてもよい。高い多重度には短い処理時間の検索処理が割り当てられ、低い多重度には長い処理時間の検索処理が割り当てられるので、高い多重度は短い処理時間が対象範囲となり、低い多重度は長い処理時間が対象範囲となる。また、多重度ごとの処理時間の対象範囲は検索要求受付部５が記憶していてもよい。
また、図３では処理中の検索要求は各データ管理装置４に対して１つずつ割り当てられている様子を示しているが、データ管理装置４の多重度の設定によっては複数の検索要求を同時に処理できる。
前述のとおり、原則として、高い多重度には短い処理時間の検索処理が割り当てられ、低い多重度には長い処理時間の検索処理が割り当てられる。
なお、図３では、図示を省略しているが、データ管理装置管理テーブル１０において、各多重度に対して処理時間の対象範囲を管理しておいてもよい。高い多重度には短い処理時間の検索処理が割り当てられ、低い多重度には長い処理時間の検索処理が割り当てられるので、高い多重度は短い処理時間が対象範囲となり、低い多重度は長い処理時間が対象範囲となる。また、多重度ごとの処理時間の対象範囲は検索要求受付部５が記憶していてもよい。
また、図３では処理中の検索要求は各データ管理装置４に対して１つずつ割り当てられている様子を示しているが、データ管理装置４の多重度の設定によっては複数の検索要求を同時に処理できる。
また、検索要求受付部５は、検索要求受付部５が生成するスレッドのうち待機中のものを管理する待ち行列を持つ。
ステップ（６）：
検索要求受付部５がステップ（２）で生成したスレッドは、新たな検索要求を割り当てることができるデータ管理装置４を発見すると、ステップ（５）の待機状態を解除する。
検索要求受付部５がステップ（２）で生成したスレッドは、新たな検索要求を割り当てることができるデータ管理装置４を発見すると、ステップ（５）の待機状態を解除する。
ステップ（７）：
検索要求受付部５がステップ（２）で生成したスレッドは、図３のデータ管理装置管理テーブルを更新し、ステップ（６）で発見したデータ管理装置４に新たな検索要求を割り当てることを示す情報をデータ管理装置管理テーブルに書き込む（選択ステップ）。
検索要求受付部５がステップ（２）で生成したスレッドは、図３のデータ管理装置管理テーブルを更新し、ステップ（６）で発見したデータ管理装置４に新たな検索要求を割り当てることを示す情報をデータ管理装置管理テーブルに書き込む（選択ステップ）。
ステップ（８）：
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（７）の書き込みを完了する。
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（７）の書き込みを完了する。
ステップ（９）：
検索要求受付部５がステップ（２）で生成したスレッドは、当該検索要求を、ステップ（６）で発見したデータ管理装置４に割り当てる。
検索要求受付部５がステップ（２）で生成したスレッドは、当該検索要求を、ステップ（６）で発見したデータ管理装置４に割り当てる。
ステップ（１０）：
ステップ（９）で検索要求を割り当てられたデータ管理装置４の検索要求処理部６は、当該検索要求の処理を実行し、結果をサービスサーバ３の検索要求受付部５に返す。
ステップ（９）で検索要求を割り当てられたデータ管理装置４の検索要求処理部６は、当該検索要求の処理を実行し、結果をサービスサーバ３の検索要求受付部５に返す。
ステップ（１１）：
検索要求受付部５がステップ（２）で生成したスレッドは、図３のデータ管理装置管理テーブルを更新し、ステップ（７）で書き込んだ検索要求の処理を当該データ管理装置４が完了したことを示す情報をデータ管理装置管理テーブルに書き込む。
検索要求受付部５がステップ（２）で生成したスレッドは、図３のデータ管理装置管理テーブルを更新し、ステップ（７）で書き込んだ検索要求の処理を当該データ管理装置４が完了したことを示す情報をデータ管理装置管理テーブルに書き込む。
ステップ（１２）：
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（１１）の書き込みを完了する。
ここで、検索要求受付部５は、待機中のスレッドを管理する待ち行列を確認し、待ち行列中に待機状態のスレッドがある場合、当該スレッドの待機状態を解除する。当該スレッドは、ステップ（５）以下の処理を実行する。
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（１１）の書き込みを完了する。
ここで、検索要求受付部５は、待機中のスレッドを管理する待ち行列を確認し、待ち行列中に待機状態のスレッドがある場合、当該スレッドの待機状態を解除する。当該スレッドは、ステップ（５）以下の処理を実行する。
ステップ（１３）：
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（１０）で受け取った検索要求の処理の結果をユーザ端末１に返し、処理を終了する。
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（１０）で受け取った検索要求の処理の結果をユーザ端末１に返し、処理を終了する。
ここで、図２のステップ（３）及び（４）において、サービスサーバ３の処理時間予想部９は、当該検索要求の内容の解析を行うように構成する。
ここで解析対象となる検索要求は、データ管理装置４の実現方法に依存するが、たとえばデータ管理装置に対する検索要求のインタフェースとして標準化されているＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）を用いて行うことができる。
そして、検索要求の解析を行った結果、選択条件（検索条件）が一定の個数以上の場合は長時間の処理を要し、それ以外の場合は短時間で処理可能であると予想するように構成することができる。
また、処理時間予想部９は、選択条件の個数ごとに標準的な処理時間の情報を予め保有しておき、ユーザ端末１からの検索要求に含まれる選択条件の個数に応じて予想処理時間を求めるようにしてもよい。
たとえば、前述のようにＳＱＬを用いて検索要求を行った場合、選択条件はＳＱＬのＷｈｅｒｅ句として記述される。
そして、選択条件の個数はＷｈｅｒｅ句の中に指定されているキーの数として決定することができる。
ここで解析対象となる検索要求は、データ管理装置４の実現方法に依存するが、たとえばデータ管理装置に対する検索要求のインタフェースとして標準化されているＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）を用いて行うことができる。
そして、検索要求の解析を行った結果、選択条件（検索条件）が一定の個数以上の場合は長時間の処理を要し、それ以外の場合は短時間で処理可能であると予想するように構成することができる。
また、処理時間予想部９は、選択条件の個数ごとに標準的な処理時間の情報を予め保有しておき、ユーザ端末１からの検索要求に含まれる選択条件の個数に応じて予想処理時間を求めるようにしてもよい。
たとえば、前述のようにＳＱＬを用いて検索要求を行った場合、選択条件はＳＱＬのＷｈｅｒｅ句として記述される。
そして、選択条件の個数はＷｈｅｒｅ句の中に指定されているキーの数として決定することができる。
あるいは、図２のステップ（４）において、データ管理装置４が保管するデータ８がＲＤＢ（Ｒｅｌａｔｉｏｎａｌ Ｄａｔａｂａｓｅ）で実現されているような表形式であり、データ管理装置４が当該データ８における表のカラムごとのアクセス時間の統計情報を保管している場合、サービスサーバ３の処理時間予想部９は、この統計情報を当該検索要求の処理時間の予想値として用いるように構成することができる。
この場合、サービスサーバ３の検索要求受付部５は、検索のキーとなるカラム（検索対象カラム）が示される検索要求を受信し、処理時間予想部９は、検索要求の選択条件に指定したキーに対応するカラム（検索対象カラム）の過去のアクセス時間の平均値が一定の値以上の場合は、当該検索要求は長い処理時間を要すると予想し、それ以外の場合は短い処理時間を要すると予想するように構成することができる。
また、検索要求の選択条件に指定したキーに対応するカラムごとのアクセス時間の平均値を足し合わせて予想処理時間を算出するようにしてもよい。
この場合、サービスサーバ３の検索要求受付部５は、検索のキーとなるカラム（検索対象カラム）が示される検索要求を受信し、処理時間予想部９は、検索要求の選択条件に指定したキーに対応するカラム（検索対象カラム）の過去のアクセス時間の平均値が一定の値以上の場合は、当該検索要求は長い処理時間を要すると予想し、それ以外の場合は短い処理時間を要すると予想するように構成することができる。
また、検索要求の選択条件に指定したキーに対応するカラムごとのアクセス時間の平均値を足し合わせて予想処理時間を算出するようにしてもよい。
図４に、データ８における表のカラムごとのアクセス時間の統計情報を保管するカラム統計情報管理テーブル１１（カラム統計情報）の構造の例を示す。
カラム統計情報管理テーブル１１は、例えば、サービスサーバ３の情報記憶部１５が保持していている。
図４において、表名はデータ８における表の名称、カラム名は、当該表中のカラムの名称、平均アクセス時間は、当該カラムへのアクセスに要する平均の時間を秒単位で測定した結果を、それぞれ示す。
また、カラム統計情報管理テーブル１１は、情報記憶部１５の代わりに処理時間予想部９が保持するようにしてもよい。
また、カラム統計情報管理テーブル１１を、たとえば情報記憶部１５又は処理時間予想部９でなく検索要求受付部５が保持するように構成し、処理時間予想部９は予想処理時間の導出を行うに当たって検索要求受付部５に検索のキーとなるカラムの平均アクセス時間を問い合わせるように構成してもよい。
カラム統計情報管理テーブル１１は、例えば、サービスサーバ３の情報記憶部１５が保持していている。
図４において、表名はデータ８における表の名称、カラム名は、当該表中のカラムの名称、平均アクセス時間は、当該カラムへのアクセスに要する平均の時間を秒単位で測定した結果を、それぞれ示す。
また、カラム統計情報管理テーブル１１は、情報記憶部１５の代わりに処理時間予想部９が保持するようにしてもよい。
また、カラム統計情報管理テーブル１１を、たとえば情報記憶部１５又は処理時間予想部９でなく検索要求受付部５が保持するように構成し、処理時間予想部９は予想処理時間の導出を行うに当たって検索要求受付部５に検索のキーとなるカラムの平均アクセス時間を問い合わせるように構成してもよい。
また、あるいは、図２のステップ（４）において、情報記憶部１５が、検索処理の処理時間に対するユーザの要求レベルが示される要求レベル情報を記憶しており、処理時間予想部９は、要求レベル情報に基づいて予想処理時間を導出してもよい。
例えば、要求レベル情報として、ユーザとのサービス契約を示す情報を用いることができる。
つまり、サービスサーバ３の処理時間予想部９は、短時間の処理を中心とする検索を行う契約をしているユーザからの検索要求は短い処理時間を要すると予想し、それ以外は長い処理時間を要すると予想する。
例えば、要求レベル情報として、ユーザとのサービス契約を示す情報を用いることができる。
つまり、サービスサーバ３の処理時間予想部９は、短時間の処理を中心とする検索を行う契約をしているユーザからの検索要求は短い処理時間を要すると予想し、それ以外は長い処理時間を要すると予想する。
このとき、情報記憶部１５は、図５に示すユーザ（契約者）の契約情報管理テーブル１２、および図６に示す契約情報マスタテーブル１３を持つように構成することができる。
図５において、契約者ａａａは、契約種類（１）の契約をしており、この契約種類（１）は図６に示す契約情報マスタテーブル１３での定義にもとづき短時間の処理を中心とする検索を行う契約をしていることを示している。
また、契約者ｂｂｂは、契約種類（２）の契約をしており、この契約種類（２）は図６に示す契約情報マスタテーブル１３での定義にもとづき長時間の処理を中心とする検索を行う契約をしていることを示している。
契約情報管理テーブル１２および契約情報マスタテーブル１３は、情報記憶部１５の代わりに処理時間予想部９が保持するようにしてもよい。
また、契約情報管理テーブル１２および契約情報マスタテーブル１３を、たとえば情報記憶部１５又は処理時間予想部９でなく検索要求受付部５が保持するように構成し、処理時間予想部９は予想処理時間の導出を行うに当たって検索要求受付部５に当該検索要求を行ったユーザ（契約者）の契約情報を問い合わせるように構成してもよい。
図５において、契約者ａａａは、契約種類（１）の契約をしており、この契約種類（１）は図６に示す契約情報マスタテーブル１３での定義にもとづき短時間の処理を中心とする検索を行う契約をしていることを示している。
また、契約者ｂｂｂは、契約種類（２）の契約をしており、この契約種類（２）は図６に示す契約情報マスタテーブル１３での定義にもとづき長時間の処理を中心とする検索を行う契約をしていることを示している。
契約情報管理テーブル１２および契約情報マスタテーブル１３は、情報記憶部１５の代わりに処理時間予想部９が保持するようにしてもよい。
また、契約情報管理テーブル１２および契約情報マスタテーブル１３を、たとえば情報記憶部１５又は処理時間予想部９でなく検索要求受付部５が保持するように構成し、処理時間予想部９は予想処理時間の導出を行うに当たって検索要求受付部５に当該検索要求を行ったユーザ（契約者）の契約情報を問い合わせるように構成してもよい。
また、あるいは、図２のステップ（４）において、サービスサーバ３の処理時間予想部９は、過去の検索要求の到着時刻の時間帯毎の平均処理時間（処理時間の実績値の平均値）を記録しておき、この値をもとに当該検索要求の処理時間の予想値を算出するよう構成することができる。
このとき、サービスサーバ３の情報記憶部１５は、図７に示す平均処理時間記録テーブル１４（時間帯別処理時間情報）を備える。
この平均処理時間記録テーブル１４は、過去の検索要求の到着時刻の時間帯、および当該時間帯に到着し、検索処理が行われた検索要求の平均処理時間を、それぞれ記録している。
図７の平均処理時間記録テーブル１４において、１行目のレコードは１３時００分から１３時４分５９秒までの間に到着した検索要求に要した処理時間の平均値を示し、２行目のレコードは１３時０５分から１３時９分５９秒までの間に到着した検索要求に要した処理時間の平均値を示している。
この場合の予想値の算出は、たとえば、ある時刻において到着した検索要求の処理時間の予想値として、過去の同一時刻において到着した検索要求の処理時間の平均値をそのまま用いることができる。
あるいはたとえば、過去の同一時刻において到着した検索要求の処理時間の平均値を季節ごとに集計した上で、季節ごとの平均処理時間を算出し、同一季節の検索要求の同一時刻の平均処理時間を予想値として用いるよう構成することができる。
この平均処理時間記録テーブル１４は、過去の検索要求の到着時刻の時間帯、および当該時間帯に到着し、検索処理が行われた検索要求の平均処理時間を、それぞれ記録している。
図７の平均処理時間記録テーブル１４において、１行目のレコードは１３時００分から１３時４分５９秒までの間に到着した検索要求に要した処理時間の平均値を示し、２行目のレコードは１３時０５分から１３時９分５９秒までの間に到着した検索要求に要した処理時間の平均値を示している。
この場合の予想値の算出は、たとえば、ある時刻において到着した検索要求の処理時間の予想値として、過去の同一時刻において到着した検索要求の処理時間の平均値をそのまま用いることができる。
あるいはたとえば、過去の同一時刻において到着した検索要求の処理時間の平均値を季節ごとに集計した上で、季節ごとの平均処理時間を算出し、同一季節の検索要求の同一時刻の平均処理時間を予想値として用いるよう構成することができる。
また、ここで、図２のステップ（５）において、検索要求受付部５がステップ（２）で生成したスレッドが、ステップ（４）で受け取った予想処理時間をもとに、新たな検索要求を割り当てることができるデータ管理装置４の有無を確認する処理の流れを図８に示す。
図８について説明する。
図８について説明する。
まず、検索要求受付部５がステップ（２）で生成したスレッドは、当該検索要求の予想処理時間を、処理時間予想部９より受け取る（Ｓ９０１）。
この予想が短い処理時間であることを示しているかどうかを判断する（Ｓ９０２）。
短い処理時間であると予想する場合は、当該検索要求を割り当て可能な多重度が高いデータ管理装置４があるかどうか判断し（Ｓ９０３）、このようなデータ管理装置４がある場合は、当該検索要求を当該データ管理装置４に割り当てる（Ｓ９０４）。
Ｓ９０３で短い処理時間と予想しない場合、またはＳ９０３で当該検索要求を割り当て可能な多重度が高いデータ管理装置４がない場合は、当該検索要求を割り当て可能な多重度が低いデータ管理装置４があるかどうか判断する（Ｓ９０５）。
Ｓ９０５で当該検索要求を割り当て可能な多重度が低いデータ管理装置がある場合は、当該検索要求を当該データ管理装置に割り当てる（Ｓ９０４）。
Ｓ９０５で、当該検索要求を割り当て可能な多重度が低いデータ管理装置がない場合は、当該スレッドは自身を検索要求受付部５が持つスレッドの待ち行列に入れ、待機状態に入る（Ｓ９０６）。
この予想が短い処理時間であることを示しているかどうかを判断する（Ｓ９０２）。
短い処理時間であると予想する場合は、当該検索要求を割り当て可能な多重度が高いデータ管理装置４があるかどうか判断し（Ｓ９０３）、このようなデータ管理装置４がある場合は、当該検索要求を当該データ管理装置４に割り当てる（Ｓ９０４）。
Ｓ９０３で短い処理時間と予想しない場合、またはＳ９０３で当該検索要求を割り当て可能な多重度が高いデータ管理装置４がない場合は、当該検索要求を割り当て可能な多重度が低いデータ管理装置４があるかどうか判断する（Ｓ９０５）。
Ｓ９０５で当該検索要求を割り当て可能な多重度が低いデータ管理装置がある場合は、当該検索要求を当該データ管理装置に割り当てる（Ｓ９０４）。
Ｓ９０５で、当該検索要求を割り当て可能な多重度が低いデータ管理装置がない場合は、当該スレッドは自身を検索要求受付部５が持つスレッドの待ち行列に入れ、待機状態に入る（Ｓ９０６）。
なお、以上の説明では、データ管理装置４に対して行う多重度の設定は、高い多重度と低い多重度の２種類だけであるとして記述したが、多重度の設定はより多段階に行ってもよい。
この場合、検索要求の処理に要する時間の予想には多重度の設定に対応する多段階の処理時間の対象範囲を設け、処理時間の予想値のそれぞれの段階の処理時間の対象範囲を比較し、予想処理時間が対象範囲に合致する多重度を選択するとともに、選択した多重度に対応するデータ管理装置４に対して当該検索要求を割り当てるように構成してもよい。
この場合、図８に示した、新たな検索要求を割り当てることができるデータ管理装置４の有無を確認する処理の流れは、多段階に設定したデータ管理装置４の多重度のそれぞれについて、図８と同様に、処理時間の予想値が、どの段階の多重度と対応するかをそれぞれ確認し、それぞれの段階で割り当て可能なデータ管理装置４があるかどうかを確認するように構成することができる。
この場合、検索要求の処理に要する時間の予想には多重度の設定に対応する多段階の処理時間の対象範囲を設け、処理時間の予想値のそれぞれの段階の処理時間の対象範囲を比較し、予想処理時間が対象範囲に合致する多重度を選択するとともに、選択した多重度に対応するデータ管理装置４に対して当該検索要求を割り当てるように構成してもよい。
この場合、図８に示した、新たな検索要求を割り当てることができるデータ管理装置４の有無を確認する処理の流れは、多段階に設定したデータ管理装置４の多重度のそれぞれについて、図８と同様に、処理時間の予想値が、どの段階の多重度と対応するかをそれぞれ確認し、それぞれの段階で割り当て可能なデータ管理装置４があるかどうかを確認するように構成することができる。
このように、本実施の形態によれば、要求された検索要求の検索処理に要する処理時間を予想し、予想処理時間に応じて最適な多重度のデータ管理装置を選択することができ、このため、予想処理時間の短い検索処理は多重度の高いデータ管理装置に割り当て、予想処理時間の長い検索処理は多重度の低いデータ管理装置に割り当てることができ、システム全体としての処理効率を向上させて要求が同時に多発する状況においても適切に要求に対処することができる。
以上、本実施の形態では、検索サービスシステムを構成するサービスサーバであり、当該サービスサーバは検索要求を受け取りデータ管理装置に割り当てるものであり、当該データ管理装置は同時実行可能な処理数の上限を多重度として保持しており、当該サービスサーバは検索要求の処理に要する時間を予想し、短時間で処理可能と予想する検索要求は高い多重度に設定したデータ管理装置に、長時間の処理を要すると予想する検索要求は低い多重度に設定したデータ管理装置に割り当てるサービスサーバを説明した。
また、本実施の形態では、検索要求の処理に要する時間の予想は、検索要求の内容を解析することにより行い、検索要求に含まれる選択条件句に指定したキーの個数が一定の値以上の場合は長時間の処理を要し、それ以外の場合は短時間で処理可能であると予想するサービスサーバを説明した。
また、本実施の形態では、検索要求の処理に要する時間の予想は、データ管理装置の保管する表形式のデータのカラム統計情報を用いることにより行い、検索要求の選択条件句に指定したキーに対応するカラムの過去の平均アクセス時間が一定の値以上の場合は長時間の処理を要し、それ以外の場合は短時間で処理可能であると予想するサービスサーバを説明した。
また、本実施の形態では、検索要求の処理に要する時間の予想は、ユーザとのサービス契約に基づき行い、主に短時間で処理可能な検索を多用する契約をしているユーザからの検索要求は短時間で処理可能、それ以外は長時間の処理を要すると予想するサービスサーバを説明した。
また、本実施の形態では、検索要求の処理に要する時間の予想は、過去の検索要求の到着時刻毎の平均処理時間を記録しておくことにより行い、この値をもとに予想値を算出するサービスサーバを説明した。
実施の形態２．
実施の形態１においては、検索要求が同時に多発する際のサービスシステム全体としての処理効率を向上させるためのサービスシステムの構成を示したが、更に、短い処理時間を要すると予想される検索要求が同時に多発する予兆の段階で、高い多重度に設定したデータ管理装置４の数を増やすことで、設定変更に時間を要するサービスシステム構成変更を前倒しに実行するよう構成することができる。
実施の形態１においては、検索要求が同時に多発する際のサービスシステム全体としての処理効率を向上させるためのサービスシステムの構成を示したが、更に、短い処理時間を要すると予想される検索要求が同時に多発する予兆の段階で、高い多重度に設定したデータ管理装置４の数を増やすことで、設定変更に時間を要するサービスシステム構成変更を前倒しに実行するよう構成することができる。
従来技術の課題として説明したように、個々のデータ管理装置の設定を変更する場合、データ管理装置のハードウェア再起動など変更の反映に時間を要する場合があるが、本実施の形態では、設定変更に時間を要するサービスシステム構成変更を前倒しに実行するため、実際に短い処理時間を要する検索要求が同時多発するのに先立ち設定変更を実際のサービスシステムの処理に反映させることができるため、サービスシステム全体としての処理効率を向上させることができる。
以下、このようなサービスシステムを実現する方法について説明する。
以下、このようなサービスシステムを実現する方法について説明する。
本実施の形態に係るサービスサーバ３においては、サービスサーバ３の受け取る検索要求の要求元情報および到着時刻を履歴として保管し、これらの情報より算出される、ある時間あたりの検索要求到着数をある規則に従って算出する。
これは、一定時間（５分ごとなど）あたりの検索要求到着数を、たとえば一定時間ごとに算出するように構成できる。
合わせて、それぞれの検索要求の処理に要した時間を記録する。
これは、一定時間（５分ごとなど）あたりの検索要求到着数を、たとえば一定時間ごとに算出するように構成できる。
合わせて、それぞれの検索要求の処理に要した時間を記録する。
また、本実施の形態に係るサービスサーバ３は、最近到着した検索要求のうち検索要求の予想処理時間が一定の値を下回ったもののある時間内での到着数、過去の検索要求到着数およびそれらの実際に要した時間が一定の値を下回った検索要求について、検索要求の最近の到着数と過去の履歴を合わせたものを特異値分解などの統計手法により傾向分析する。
そして、この特異値分解の結果得られた最近の到着数に対応する値が、従来の履歴における到着数を示す値の分布の重心から一定の距離以上離れているなど、従来の履歴における到着数の傾向と異なる特異値を示す場合は、短い処理時間を要する検索要求の集中発生する予兆を検知したと推測し、多重度の低いデータ管理装置の一部を、多重度の高い設定に変更する。
また、本実施の形態に係るデータ管理装置４は、サービスサーバ３からの設定変更の指示に応じて、多重度の設定を動的に変更する。
そして、この特異値分解の結果得られた最近の到着数に対応する値が、従来の履歴における到着数を示す値の分布の重心から一定の距離以上離れているなど、従来の履歴における到着数の傾向と異なる特異値を示す場合は、短い処理時間を要する検索要求の集中発生する予兆を検知したと推測し、多重度の低いデータ管理装置の一部を、多重度の高い設定に変更する。
また、本実施の形態に係るデータ管理装置４は、サービスサーバ３からの設定変更の指示に応じて、多重度の設定を動的に変更する。
図９に、本実施の形態に係るサービスサーバ３及びデータ管理装置４を適用したサービスシステム２の機能構成図を示す。
サービスサーバ装置３において、検索要求受付部５及び処理時間予想部９は、実施の形態１で説明したものと同様である。
情報記憶部１５は、実施の形態１で説明した情報に加えて、検索要求の要求元情報および到着時刻の履歴情報を記憶している。
また、検索要求履歴分析部１６は、複数のデータ管理装置４による過去の検索処理における処理時間の実績値に基づき、今後の検索処理における処理時間の傾向が過去の検索処理における処理時間の傾向から変化するか否か、例えば、高い多重度のデータ管理装置４での検索処理が増加するか否かを予測する。検索要求履歴分析部１６は傾向予測部の例である。
データ管理装置制御部１７は、検索要求履歴分析部１６により今後の検索処理における処理時間の傾向が過去の検索処理における処理時間の傾向から変化すると予測された場合、データ管理装置４の多重度の設定を変更する。例えば、高い多重度のデータ管理装置４での検索処理が増加すると予測された場合に、高い多重度のデータ管理装置４の数を増加させる。データ管理装置制御部１７は多重度管理部の例である。
情報記憶部１５は、実施の形態１で説明した情報に加えて、検索要求の要求元情報および到着時刻の履歴情報を記憶している。
また、検索要求履歴分析部１６は、複数のデータ管理装置４による過去の検索処理における処理時間の実績値に基づき、今後の検索処理における処理時間の傾向が過去の検索処理における処理時間の傾向から変化するか否か、例えば、高い多重度のデータ管理装置４での検索処理が増加するか否かを予測する。検索要求履歴分析部１６は傾向予測部の例である。
データ管理装置制御部１７は、検索要求履歴分析部１６により今後の検索処理における処理時間の傾向が過去の検索処理における処理時間の傾向から変化すると予測された場合、データ管理装置４の多重度の設定を変更する。例えば、高い多重度のデータ管理装置４での検索処理が増加すると予測された場合に、高い多重度のデータ管理装置４の数を増加させる。データ管理装置制御部１７は多重度管理部の例である。
また、データ管理装置４において、多重度制御部７はサービスサーバ３のデータ管理装置制御部１７からの指示を受けて、多重度の設定を動的に変更する。
図１０に、実施の形態２におけるサービスシステム２の機能同士の処理シーケンスを示す。
以下、図１０について説明する。
以下、図１０について説明する。
ステップ（１）：
ユーザは、ユーザ端末１からサービスサーバ３に検索要求を送る。
ユーザは、ユーザ端末１からサービスサーバ３に検索要求を送る。
ステップ（２）：
サービスサーバ３の検索要求受付部５は、ユーザ端末１からの検索要求を受信し、ステップ（１）の検索要求毎にスレッドを生成する。
サービスサーバ３の検索要求受付部５は、ユーザ端末１からの検索要求を受信し、ステップ（１）の検索要求毎にスレッドを生成する。
ステップ（３）：
検索要求受付部５がステップ（２）で生成したスレッドは、処理時間予想部９を呼び出し、ステップ（１）の検索要求の処理に要する時間予想の実行を処理時間予想部９に要求する。
検索要求受付部５がステップ（２）で生成したスレッドは、処理時間予想部９を呼び出し、ステップ（１）の検索要求の処理に要する時間予想の実行を処理時間予想部９に要求する。
ステップ（４）：
処理時間予想部９は、検索処理の予想処理時間を導出し、検索要求受付部５がステップ（２）で生成したスレッドに、導出結果を返す。
このときの処理時間予想は、実施の形態１で述べた方法のうちいずれの方法を用いて実現してもよい。あるいは、他の方法で予想してもよい。
処理時間予想部９は、検索処理の予想処理時間を導出し、検索要求受付部５がステップ（２）で生成したスレッドに、導出結果を返す。
このときの処理時間予想は、実施の形態１で述べた方法のうちいずれの方法を用いて実現してもよい。あるいは、他の方法で予想してもよい。
ステップ（５）：
検索要求受付部５がステップ（２）で生成したスレッドは、情報記憶部１５に対し、検索要求履歴テーブルの更新を指示する。
ここで、情報記憶部１５の保管する、検索要求履歴テーブル１８の例を図１１に示す。
図１１の例においては、検索要求履歴テーブル１８は、検索要求受付部５が受け付けた検索要求毎に、検索要求ＩＤ、割り当てたデータ管理装置４（割り当て未実施のものは空欄）、到着時刻、処理の完了した時刻（処理未完了のものは空欄）を記録する。
検索要求受付部５がステップ（２）で生成したスレッドは、情報記憶部１５に対し、検索要求履歴テーブルの更新を指示する。
ここで、情報記憶部１５の保管する、検索要求履歴テーブル１８の例を図１１に示す。
図１１の例においては、検索要求履歴テーブル１８は、検索要求受付部５が受け付けた検索要求毎に、検索要求ＩＤ、割り当てたデータ管理装置４（割り当て未実施のものは空欄）、到着時刻、処理の完了した時刻（処理未完了のものは空欄）を記録する。
ステップ（６）：
情報記憶部１５は、ステップ（５）の処理が完了したことを検索要求受付部５に通知する。
情報記憶部１５は、ステップ（５）の処理が完了したことを検索要求受付部５に通知する。
ステップ（７）：
検索要求受付部５がステップ（２）で生成したスレッドは、検索要求履歴分析部１６に、分析の実行を指示する。
図１２に、検索要求履歴の分析に使う、履歴分析テーブル１９の例を示す。
図１２の例では、履歴分析テーブル１９は、検索要求履歴テーブル１８をもとに、行方向には、ある時間（図１２では１時間ごと）ごとに到着しかつ処理に要した時間が一定値未満の検索要求到着の数（処理が完了していない検索要求については、処理に要した時間を、処理に要する時間の予想値で代替）を並べ、列方向には、各行の要素を１単位時間（図１２では１分）ずつずらして上述の値を並べ、最も古い要素は取り除き、かつ行の最後尾には新たな要素を加えた行列である。
検索要求受付部５がステップ（２）で生成したスレッドは、検索要求履歴分析部１６に、分析の実行を指示する。
図１２に、検索要求履歴の分析に使う、履歴分析テーブル１９の例を示す。
図１２の例では、履歴分析テーブル１９は、検索要求履歴テーブル１８をもとに、行方向には、ある時間（図１２では１時間ごと）ごとに到着しかつ処理に要した時間が一定値未満の検索要求到着の数（処理が完了していない検索要求については、処理に要した時間を、処理に要する時間の予想値で代替）を並べ、列方向には、各行の要素を１単位時間（図１２では１分）ずつずらして上述の値を並べ、最も古い要素は取り除き、かつ行の最後尾には新たな要素を加えた行列である。
ステップ（８）：
検索要求履歴分析部１６は、情報記憶部１５の管理する検索要求履歴テーブル１８にアクセスし、履歴分析テーブル１９の生成に必要な検索要求履歴情報を問い合わせる。
検索要求履歴分析部１６は、情報記憶部１５の管理する検索要求履歴テーブル１８にアクセスし、履歴分析テーブル１９の生成に必要な検索要求履歴情報を問い合わせる。
ステップ（９）：
情報記憶部１５は、ステップ（９）の問い合わせに対する応答を検索要求履歴分析部１６に返す。
情報記憶部１５は、ステップ（９）の問い合わせに対する応答を検索要求履歴分析部１６に返す。
ステップ（１０）：
検索要求履歴分析部１６は、履歴分析テーブル１９を生成し、特異値分解（Ｓｉｎｇｕｌａｒ Ｖａｌｕｅ Ｄｅｃｏｍｐｏｓｉｔｉｏｎ）などの方法により履歴分析を実行した結果を、検索要求受付部５がステップ（２）で生成したスレッドに渡す。
ここで、履歴分析テーブル１９は、都度生成する必要はなく、たとえば検索要求履歴分析部１６は前回生成した履歴分析テーブル１９を保持しておき、前回との差分をもとに履歴分析を実行するよう構成することができる。
検索要求履歴分析部１６は、履歴分析テーブル１９を生成し、特異値分解（Ｓｉｎｇｕｌａｒ Ｖａｌｕｅ Ｄｅｃｏｍｐｏｓｉｔｉｏｎ）などの方法により履歴分析を実行した結果を、検索要求受付部５がステップ（２）で生成したスレッドに渡す。
ここで、履歴分析テーブル１９は、都度生成する必要はなく、たとえば検索要求履歴分析部１６は前回生成した履歴分析テーブル１９を保持しておき、前回との差分をもとに履歴分析を実行するよう構成することができる。
ステップ（１１）：
ステップ（１０）で検索要求の同時多発の予兆を示すと解釈できる情報（たとえば、図１２の例に示した特異値分析テーブルを特異値分解した結果、最近の検索要求到着件数を含む点が、それ以前の検索要求到着件数のみを含む点のグループの重心から一定の距離以上離れている場合）を受け取ると、検索要求受付部５はステップ（１２）〜（１６）の処理を実行する。
ステップ（１０）で検索要求の同時多発の予兆を示すと解釈できる情報（たとえば、図１２の例に示した特異値分析テーブルを特異値分解した結果、最近の検索要求到着件数を含む点が、それ以前の検索要求到着件数のみを含む点のグループの重心から一定の距離以上離れている場合）を受け取ると、検索要求受付部５はステップ（１２）〜（１６）の処理を実行する。
ステップ（１２）：
検索要求受付部５は、データ管理装置制御部１７に、いずれかのデータ管理装置４の多重度の設定を変更する指示を出す。
検索要求受付部５は、データ管理装置制御部１７に、いずれかのデータ管理装置４の多重度の設定を変更する指示を出す。
ステップ（１３）：
データ管理装置制御部１７は、多重度の設定を変更するデータ管理装置４を選択し、設定変更を指示する。
この選択は、たとえば、図１０には明示していないが、データ管理装置制御部１７が、情報記憶部１５又は検索要求受付部５の保管するデータ管理装置管理テーブル１０を参照し、低い多重度の設定がされているデータ管理装置４をランダムに選ぶことによってもよい。
データ管理装置制御部１７は、多重度の設定を変更するデータ管理装置４を選択し、設定変更を指示する。
この選択は、たとえば、図１０には明示していないが、データ管理装置制御部１７が、情報記憶部１５又は検索要求受付部５の保管するデータ管理装置管理テーブル１０を参照し、低い多重度の設定がされているデータ管理装置４をランダムに選ぶことによってもよい。
ステップ（１４）：
ステップ（１３）の指示を受けたデータ管理装置４の多重度制御部７は、設定を変更し、結果をサービスサーバ３のデータ管理装置制御部１７に戻す。
この多重度の設定変更は、指示を受けて直ちに実行する必要はなく、たとえば現在処理中の検索要求の処理を完了した後に多重度の設定を変更するよう構成してもよい。
ステップ（１３）の指示を受けたデータ管理装置４の多重度制御部７は、設定を変更し、結果をサービスサーバ３のデータ管理装置制御部１７に戻す。
この多重度の設定変更は、指示を受けて直ちに実行する必要はなく、たとえば現在処理中の検索要求の処理を完了した後に多重度の設定を変更するよう構成してもよい。
ステップ（１５）：
データ管理装置制御部１７は、ステップ（１４）の結果を検索要求受付部５がステップ（２）で生成したスレッドに戻す。
データ管理装置制御部１７は、ステップ（１４）の結果を検索要求受付部５がステップ（２）で生成したスレッドに戻す。
ステップ（１６）：
データ管理装置制御部１７は、データ管理装置管理テーブル１０に、ステップ（１２）〜（１６）の処理の結果設定を変更したデータ管理装置４の情報を書き込む。
データ管理装置制御部１７は、データ管理装置管理テーブル１０に、ステップ（１２）〜（１６）の処理の結果設定を変更したデータ管理装置４の情報を書き込む。
ステップ（１７）：
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（４）で受け取った予想処理時間をもとに、新たな検索要求を割り当てることができるデータ管理装置４の有無を確認する。
この確認処理の流れは図８と同様でよい。
そして、新たな検索要求を割り当てることができるデータ管理装置４がなければ、いずれかのデータ管理装置４がこのような状態になるまで待機する。
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（４）で受け取った予想処理時間をもとに、新たな検索要求を割り当てることができるデータ管理装置４の有無を確認する。
この確認処理の流れは図８と同様でよい。
そして、新たな検索要求を割り当てることができるデータ管理装置４がなければ、いずれかのデータ管理装置４がこのような状態になるまで待機する。
ステップ（１８）：
検索要求受付部５がステップ（２）で生成したスレッドは、新たな検索要求を割り当てることができるデータ管理装置４を発見すると、図３のデータ管理装置管理テーブル１０を更新し、ステップ（１７）で発見したデータ管理装置４に新たな検索要求を割り当てることを示す情報をデータ管理装置管理テーブル１０に書き込む。
そして、ステップ（１７）の待機状態を解除し、当該検索要求を当該データ管理装置４に割り当てる。
なお、図１０においては作図の都合上ステップ（１３）及び（１４）の処理とステップ（１８）及び（１９）の処理が同一のデータ管理装置４の上で実行されるように記述しているが、実際にはステップ（１３）及び（１４）の処理とステップ（１８）及び（１９）の処理は同一のデータ管理装置４の上で実行する必要はない。
検索要求受付部５がステップ（２）で生成したスレッドは、新たな検索要求を割り当てることができるデータ管理装置４を発見すると、図３のデータ管理装置管理テーブル１０を更新し、ステップ（１７）で発見したデータ管理装置４に新たな検索要求を割り当てることを示す情報をデータ管理装置管理テーブル１０に書き込む。
そして、ステップ（１７）の待機状態を解除し、当該検索要求を当該データ管理装置４に割り当てる。
なお、図１０においては作図の都合上ステップ（１３）及び（１４）の処理とステップ（１８）及び（１９）の処理が同一のデータ管理装置４の上で実行されるように記述しているが、実際にはステップ（１３）及び（１４）の処理とステップ（１８）及び（１９）の処理は同一のデータ管理装置４の上で実行する必要はない。
ステップ（１９）：
ステップ（１８）で検索要求を割り当てられたデータ管理装置４の検索要求処理部６は、当該検索要求の処理を実行し、結果をサービスサーバ３の検索要求受付部５に返す。
ステップ（１８）で検索要求を割り当てられたデータ管理装置４の検索要求処理部６は、当該検索要求の処理を実行し、結果をサービスサーバ３の検索要求受付部５に返す。
ステップ（２０）：
検索要求受付部５がステップ（２）で生成したスレッドは、図３のデータ管理装置管理テーブル１０を更新し、ステップ（１８）で書き込んだ検索要求の処理を当該データ管理装置４が完了したことを示す情報をデータ管理装置管理テーブル１０に書き込む。
検索要求受付部５がステップ（２）で生成したスレッドは、図３のデータ管理装置管理テーブル１０を更新し、ステップ（１８）で書き込んだ検索要求の処理を当該データ管理装置４が完了したことを示す情報をデータ管理装置管理テーブル１０に書き込む。
ステップ（２１）：
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（２０）の書き込みを完了する。
ここで、検索要求受付部５は、待機中のスレッドを管理する待ち行列を確認し、待ち行列中に待機状態のスレッドがある場合、当該スレッドの待機状態を解除する。
当該スレッドは、ステップ（３）以下の処理を実行する。
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（２０）の書き込みを完了する。
ここで、検索要求受付部５は、待機中のスレッドを管理する待ち行列を確認し、待ち行列中に待機状態のスレッドがある場合、当該スレッドの待機状態を解除する。
当該スレッドは、ステップ（３）以下の処理を実行する。
ステップ（２２）：
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（２１）で受け取った検索要求の処理の結果をユーザに返し、処理を終了する。
検索要求受付部５がステップ（２）で生成したスレッドは、ステップ（２１）で受け取った検索要求の処理の結果をユーザに返し、処理を終了する。
なお、以上の説明では、データ管理装置４に対して行う多重度の設定は、高い多重度と低い多重度の２種類だけであるとして記述したが、実施の形態１でも述べた通り、多重度の設定はより多段階に行ってもよい。
また、検索要求の処理に要する時間の予想には多重度の設定に対応する多段階の処理時間の対象範囲を設け、予想値のそれぞれの段階に対応する設定の多重度を持つデータ管理装置４に対して当該検索要求を割り当てるように構成してもよい。
この場合、図１０におけるステップ（９）及び（１０）の処理においては、多重度の段階ごとに、図１２の履歴分析テーブルを生成し、特異値分解などによる傾向分析を行うように構成することができる。
いずれかの段階の多重度において、当該多重度に対応する予想時間を持つ検索要求が同時に多数発生する予兆を検知したとみなすことができる場合は、当該多重度より１段階高い多重度、または１段階低い多重度の設定を持つデータ管理装置４を選び、検索要求が同時に多数発生する予兆を示している予想処理時間に対応する多重度への設定変更を指示するように構成してもよい。
また、検索要求の処理に要する時間の予想には多重度の設定に対応する多段階の処理時間の対象範囲を設け、予想値のそれぞれの段階に対応する設定の多重度を持つデータ管理装置４に対して当該検索要求を割り当てるように構成してもよい。
この場合、図１０におけるステップ（９）及び（１０）の処理においては、多重度の段階ごとに、図１２の履歴分析テーブルを生成し、特異値分解などによる傾向分析を行うように構成することができる。
いずれかの段階の多重度において、当該多重度に対応する予想時間を持つ検索要求が同時に多数発生する予兆を検知したとみなすことができる場合は、当該多重度より１段階高い多重度、または１段階低い多重度の設定を持つデータ管理装置４を選び、検索要求が同時に多数発生する予兆を示している予想処理時間に対応する多重度への設定変更を指示するように構成してもよい。
また、以上の説明では、多重度の設定変更の判断は、検索要求の履歴の分析結果にのみ基づいていたが、実施の都合によっては、検索要求の履歴の分析結果と、図１０のステップ（２）で生成するスレッドのうち待機状態にあるものの数を合わせて判断するようにしてもよい。
たとえば、履歴分析テーブルに記載する値は、上記の説明で述べた、ある時間における検索要求の到着数に加えて、図１０のステップ（２）で生成するスレッドのうち待機状態にあるものの当該時間における平均の数を用いるよう構成してもよい。
また、実装の都合によっては、たとえば、図１０のステップ（７）に先立ち、図１０のステップ（２）で生成するスレッドのうち待機状態にあるものの数を確認し、この数が一定の値以下のときには、サービスシステム２全体の負荷が低いとみなして、図１０のステップ（７）〜（１６）の処理は省略するように構成してもよい。
たとえば、履歴分析テーブルに記載する値は、上記の説明で述べた、ある時間における検索要求の到着数に加えて、図１０のステップ（２）で生成するスレッドのうち待機状態にあるものの当該時間における平均の数を用いるよう構成してもよい。
また、実装の都合によっては、たとえば、図１０のステップ（７）に先立ち、図１０のステップ（２）で生成するスレッドのうち待機状態にあるものの数を確認し、この数が一定の値以下のときには、サービスシステム２全体の負荷が低いとみなして、図１０のステップ（７）〜（１６）の処理は省略するように構成してもよい。
このように、本実施の形態では、短い処理時間を要する検索要求の集中発生する予兆を検知したときに、多重度の低いデータ管理装置の一部を、多重度の高い設定に変更する。
ハードウェア再起動など変更の反映に時間を要するサービスシステム構成変更を前倒しに実行するため、実際に短い処理時間を要する検索要求が同時多発するのに先立ち設定変更を実際のサービスシステムの処理に反映させることができるため、サービスシステム全体としての処理効率を向上させることができる。
ハードウェア再起動など変更の反映に時間を要するサービスシステム構成変更を前倒しに実行するため、実際に短い処理時間を要する検索要求が同時多発するのに先立ち設定変更を実際のサービスシステムの処理に反映させることができるため、サービスシステム全体としての処理効率を向上させることができる。
以上、本実施の形態では、検索要求履歴分析部および検索履歴分析テーブルを備え、検索要求の処理に要すると予想する時間、および過去の検索要求受付の履歴を分析し、検索要求処理の集中発生の予兆を検知すると、１つ以上のデータ管理装置に対し、同時実行する検索処理の上限値を変更するよう指示するサービスサーバを説明した。
また、本実施の形態では、分析の手法が特異値分解であるサービスサーバを説明した。
また、本実施の形態では、サービスサーバより、同時実行する検索処理の上限値を変更する指示を受け取ると、設定を変更するデータ管理装置を説明した。
また、本実施の形態では、サービスサーバ、およびデータ管理装置よりなり、サービスサーバが検索要求の集中発生の予兆を検知した場合は、同時実行する検索処理の上限値を変更する指示をデータ管理装置に対して行い、当該指示を受けたデータ管理装置においては、指示に基づき設定を変更するサービスシステムを説明した。
実施の形態３．
実施の形態２では、サービスシステム２において実際にサービスに利用されている本番系のデータ管理装置４の多重度を動的に変更する例を示したが、本実施の形態のサービスシステムにおいては、さらに待機系のデータ管理装置を備えるように構成し、サービスサーバが、過去の検索要求受付の履歴をもとに、検索要求処理の集中発生の予兆を検知すると、待機用のデータ管理装置に検索要求を割り当てるよう設定を変更するよう構成したものである。
これにより、本実施の形態に係るサービスシステムにおいては、実施の形態２のサービスシステムよりも、実際に検索要求が同時に多発した場合の応答性能を向上させることができる。
実施の形態２では、サービスシステム２において実際にサービスに利用されている本番系のデータ管理装置４の多重度を動的に変更する例を示したが、本実施の形態のサービスシステムにおいては、さらに待機系のデータ管理装置を備えるように構成し、サービスサーバが、過去の検索要求受付の履歴をもとに、検索要求処理の集中発生の予兆を検知すると、待機用のデータ管理装置に検索要求を割り当てるよう設定を変更するよう構成したものである。
これにより、本実施の形態に係るサービスシステムにおいては、実施の形態２のサービスシステムよりも、実際に検索要求が同時に多発した場合の応答性能を向上させることができる。
図１３は、本実施の形態に係るサービスサーバ３及びデータ管理装置４を適用したサービスシステム２の機能構成図を示す。
図１３において、１−１７は図１及び図９と同様であるが、本実施の形態では、待機系のデータ管理装置２０（待機データ処理装置）を１つ以上備える。
図１３において、１−１７は図１及び図９と同様であるが、本実施の形態では、待機系のデータ管理装置２０（待機データ処理装置）を１つ以上備える。
待機系のデータ管理装置２０は、本番系のデータ管理装置４（稼働データ処理装置）における多重度０の特殊な場合と考えられるため、本実施の形態のサービスシステムを構成する機能間処理シーケンスは図１０と同様である。
つまり、本実施の形態では、データ管理装置制御部１７は、検索要求履歴分析部１６により高い多重度のデータ管理装置４での検索処理が増加すると予測された場合に、待機系のデータ管理装置２０の多重度の設定を変更して（多重度０から高い多重度に変更して）、高い多重度のデータ管理装置４の数を増加させる。
つまり、本実施の形態では、データ管理装置制御部１７は、検索要求履歴分析部１６により高い多重度のデータ管理装置４での検索処理が増加すると予測された場合に、待機系のデータ管理装置２０の多重度の設定を変更して（多重度０から高い多重度に変更して）、高い多重度のデータ管理装置４の数を増加させる。
なお、本番系のデータ管理装置４および待機系のデータ管理装置２０を混在させ、たとえばサービスサーバ３がはじめに検索要求の同時多発の予兆を検知したと見なした段階では本番系のデータ管理装置の多重度の設定を変更し、当該変更後の構成をもってしてもなおある時間における検索要求の到着数と図１０のステップ（２）で生成するスレッドのうち待機状態にあるものの当該時間における平均の数を合わせたものを対象に履歴分析を行った結果、検索要求の同時多発の予兆を検知した場合は、待機系のデータ管理装置２０を本番系の設定に切り替えるように構成してもよい。
また、待機系のデータ管理装置２０は、あらかじめ高い多重度に設定したものと、あらかじめ低い多重度に設定したものを用意する構成をとってもよい。
このとき、図１０のステップ（１０）において、短い処理時間を要すると予想される検索要求の同時多発の予兆を検知した場合は、図１０のステップ（１３）において前者を本番系のデータ管理装置４にする設定変更を行い、また図１０のステップ（１０）において、長い処理時間を要すると予想される検索要求の同時多発の予兆を検知した場合は後者を、本番系のデータ管理装置４にする設定変更を行うように構成してもよい。
また、待機系のデータ管理装置２０は、あらかじめ高い多重度に設定したものと、あらかじめ低い多重度に設定したものを用意する構成をとってもよい。
このとき、図１０のステップ（１０）において、短い処理時間を要すると予想される検索要求の同時多発の予兆を検知した場合は、図１０のステップ（１３）において前者を本番系のデータ管理装置４にする設定変更を行い、また図１０のステップ（１０）において、長い処理時間を要すると予想される検索要求の同時多発の予兆を検知した場合は後者を、本番系のデータ管理装置４にする設定変更を行うように構成してもよい。
以上、本実施の形態では、待機用を含む複数のデータ管理装置および検索要求を受け取るサービスサーバよりなる検索サービスシステムにおいて、検索要求履歴分析部および検索履歴分析テーブルを備え、過去の検索要求受付の履歴をもとに、検索要求処理の集中発生の予兆を検知すると、待機用のデータ管理装置に検索要求を割り当てるよう設定を変更するサービスサーバを説明した。
また、本実施の形態では、サービスサーバより、設定変更の指示を受け取ると、自身の設定を待機系から本番系に変更するデータ管理装置を説明した。
また、本実施の形態では、サービスサーバ、および本番系に利用するデータ管理装置、および待機系に利用するデータ管理装置よりなるサービスシステムを説明した。
実施の形態４．
実施の形態２ないし３においては、サービスサーバ２が、一定の特性を持った検索要求の到着に関する分析を行い、検索要求の同時多発の予兆を検知したと判断した段階で本番系のデータ管理装置４または待機系のデータ管理装置２０のいずれかまたは双方の設定を変更するが、判断に反して検索要求の同時多発が発生しない場合もある。
本実施の形態では、このような場合に、設定を変更前のものに戻す例を説明する。
実施の形態２ないし３においては、サービスサーバ２が、一定の特性を持った検索要求の到着に関する分析を行い、検索要求の同時多発の予兆を検知したと判断した段階で本番系のデータ管理装置４または待機系のデータ管理装置２０のいずれかまたは双方の設定を変更するが、判断に反して検索要求の同時多発が発生しない場合もある。
本実施の形態では、このような場合に、設定を変更前のものに戻す例を説明する。
本実施の形態に係るサービスシステム２の機能構成は、図１３と同様である。
また、このときのサービスシステム２における機能間の処理のシーケンスは図１０と同様である。
ただし、処理の内容は実施の形態２にて説明したものとは以下の点で異なる。
また、このときのサービスシステム２における機能間の処理のシーケンスは図１０と同様である。
ただし、処理の内容は実施の形態２にて説明したものとは以下の点で異なる。
本実施の形態では、図１０のステップ（１０）において、サービスサーバ３の検索要求履歴分析部１６が検索要求の履歴分析をして、検索要求の同時多発が発生する予兆を検知したと判断した場合は、データ管理装置制御部１７による本番系のデータ管理装置４または待機系のデータ管理装置２０の設定変更後に次に検索要求履歴の分析を行い処理時間の傾向予測を行うタイミング（傾向予測タイミング）を一定期間または一定回数の検索要求を処理する間という形で設定する。
そして、データ管理装置制御部１７による設定変更後、一定期間経過後、または一定回数の検索要求を処理した後に、検索要求履歴分析部１６は、図１０のステップ（１０）において検索要求の履歴を再度分析し、処理時間の傾向予測を行い、特異値分解による特異値が発生しないなど、検索要求処理の集中発生が発生していないと判断した場合は、検索要求受付部５の指示に基づき、データ管理装置制御部１７は、図１０のステップ（１４）にて、データ管理装置４の多重度または待機系から本番系への設定変更を元に戻す指示を、データ管理装置に対して行う。
なお、この設定変更を元に戻す指示は、前回の実行時に設定変更を指示したのと同じデータ管理装置に対して行う必要はなく、たとえば、前回の実行時に指示した設定変更を反映した状態と、もともと同じ設定を持っていた任意のデータ管理装置を選択するように構成してよい。
また、実装の都合によっては、履歴分析における特異値をその後の履歴分析において除外するため、いったん本番系のデータ管理装置４または待機系のデータ管理装置２０の設定変更を行った後は、一定期間または一定回数の検索要求を処理する間に到着した検索要求は、履歴分析の対象外としてもよい。
そして、データ管理装置制御部１７による設定変更後、一定期間経過後、または一定回数の検索要求を処理した後に、検索要求履歴分析部１６は、図１０のステップ（１０）において検索要求の履歴を再度分析し、処理時間の傾向予測を行い、特異値分解による特異値が発生しないなど、検索要求処理の集中発生が発生していないと判断した場合は、検索要求受付部５の指示に基づき、データ管理装置制御部１７は、図１０のステップ（１４）にて、データ管理装置４の多重度または待機系から本番系への設定変更を元に戻す指示を、データ管理装置に対して行う。
なお、この設定変更を元に戻す指示は、前回の実行時に設定変更を指示したのと同じデータ管理装置に対して行う必要はなく、たとえば、前回の実行時に指示した設定変更を反映した状態と、もともと同じ設定を持っていた任意のデータ管理装置を選択するように構成してよい。
また、実装の都合によっては、履歴分析における特異値をその後の履歴分析において除外するため、いったん本番系のデータ管理装置４または待機系のデータ管理装置２０の設定変更を行った後は、一定期間または一定回数の検索要求を処理する間に到着した検索要求は、履歴分析の対象外としてもよい。
また、本実施の形態では、サービスサーバ３の検索要求受付部５には、検索要求の到着件数に任意の閾値をあらかじめ設定しておく。
この構成において、ある検索要求を受け付け、図１０のステップ（１０）で検索要求の同時多発の予兆を検知したと判断し、本番系のデータ管理装置４または待機系のデータ管理装置２０のいずれかまたは双方の設定を変更したとする。この設定変更から一定時間後（この時間は定数でもよく、また検索要求を一定回数受け付けることを条件としてもよい）にサービスサーバ３が検索要求を受け付ける際、検索要求受付部５においては、図１０のステップ（１０）において、検索要求履歴分析部１６から履歴分析結果を受け取ると同時に、ある時間内の検索要求の到着件数を算出し、この値と前述の閾値を比較する。
そして、ある時間内の検索要求の到着件数が閾値を下回った場合は、それ以前に行った本番系のデータ管理装置４または待機系のデータ管理装置２０に対する設定変更を元に戻す指示を、データ管理装置制御部１７を介してデータ管理装置に対して行う。
なお、この設定変更を元に戻す指示は、前回の実行時に設定変更を指示したのと同じデータ管理装置に対して行う必要はなく、たとえば、前回の実行時に指示した設定変更を反映した状態と、もともと同じ設定を持っていた任意のデータ管理装置を選択するように構成してもよい。
この構成において、ある検索要求を受け付け、図１０のステップ（１０）で検索要求の同時多発の予兆を検知したと判断し、本番系のデータ管理装置４または待機系のデータ管理装置２０のいずれかまたは双方の設定を変更したとする。この設定変更から一定時間後（この時間は定数でもよく、また検索要求を一定回数受け付けることを条件としてもよい）にサービスサーバ３が検索要求を受け付ける際、検索要求受付部５においては、図１０のステップ（１０）において、検索要求履歴分析部１６から履歴分析結果を受け取ると同時に、ある時間内の検索要求の到着件数を算出し、この値と前述の閾値を比較する。
そして、ある時間内の検索要求の到着件数が閾値を下回った場合は、それ以前に行った本番系のデータ管理装置４または待機系のデータ管理装置２０に対する設定変更を元に戻す指示を、データ管理装置制御部１７を介してデータ管理装置に対して行う。
なお、この設定変更を元に戻す指示は、前回の実行時に設定変更を指示したのと同じデータ管理装置に対して行う必要はなく、たとえば、前回の実行時に指示した設定変更を反映した状態と、もともと同じ設定を持っていた任意のデータ管理装置を選択するように構成してもよい。
以上の説明では、図１０のステップ（１０）において、サービスサーバ３は、ある時間内の検索要求の到着件数の算出、および閾値との比較を行うことにしているが、実際には、図１０のステップ（１）でユーザからの検索要求を受け取った時点でこの算出および比較を行ってもよい。
そして、この比較の結果、ある時間内の検索要求の到着件数が閾値を下回った場合、図１０のステップ（３）〜（１０）の処理を省略し、ステップ（１１）〜（１６）の、以前に行った本番系のデータ管理装置４または待機系のデータ管理装置２０に対する設定変更を元に戻す指示を実行するように構成してもよい。
そして、この比較の結果、ある時間内の検索要求の到着件数が閾値を下回った場合、図１０のステップ（３）〜（１０）の処理を省略し、ステップ（１１）〜（１６）の、以前に行った本番系のデータ管理装置４または待機系のデータ管理装置２０に対する設定変更を元に戻す指示を実行するように構成してもよい。
以上、本実施の形態では、サービスサーバから指示を受けて多重度の設定変更または待機系から本番系への設定変更を実行したデータ管理装置に対し、当該設定変更後、一定期間経過後、または一定回数の検索要求を処理した後に再度検索要求履歴を分析し、検索要求処理の集中発生が発生していないと判断した場合は、データ管理装置に対し、設定を変更前の状態に戻すよう指示するサービスサーバを説明した。
また、本実施の形態では、サービスサーバから指示を受けて多重度の設定変更または待機系から本番系への設定変更を実行したデータ管理装置に対し、あらかじめ検索要求の到着件数に閾値を設定し、ある時間内での実際の検索要求の到着件数が当該閾値を下回った場合は、データ管理装置に対し、設定を変更前の状態に戻すよう指示するサービスサーバを説明した。
また、本実施の形態では、サービスサーバから指示を受けて多重度の設定変更または待機系から本番系への設定変更を実行したデータ管理装置に対し、サービスサーバからの指示を受けて、設定を変更前の状態に戻すデータ管理装置を説明した。
また、本実施の形態では、サービスサーバ、およびデータ管理装置より構成されるサービスシステムであって、サービスサーバがデータ管理装置に対して多重度設定の変更または本番系から待機系への設定変更の指示を送り、当該指示を受け取ったデータ管理装置においては設定の変更を実施するサービスシステムを説明した。
最後に、実施の形態１〜４に示したサービスサーバ装置３のハードウェア構成例について説明する。
図１４は、実施の形態１〜４に示すサービスサーバ装置３のハードウェア資源の一例を示す図である。
なお、図１４の構成は、あくまでもサービスサーバ装置３のハードウェア構成の一例を示すものであり、サービスサーバ装置３のハードウェア構成は図１４に記載の構成に限らず、他の構成であってもよい。
図１４は、実施の形態１〜４に示すサービスサーバ装置３のハードウェア資源の一例を示す図である。
なお、図１４の構成は、あくまでもサービスサーバ装置３のハードウェア構成の一例を示すものであり、サービスサーバ装置３のハードウェア構成は図１４に記載の構成に限らず、他の構成であってもよい。
図１４において、サービスサーバ装置３は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。
通信ボード９１５は、図１に示すように、ネットワークに接続されている。例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）、インターネット、ＮＧＮの他、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）などに接続されていても構わない。
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。
また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。
また、ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
サービスサーバ装置３の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。
サービスサーバ装置３の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。
上記プログラム群９２３には、実施の形態１〜４の説明において「〜部」として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
ファイル群９２４には、実施の形態１〜４の説明において、「〜の判断」、「〜の計算」、「〜の算出」、「〜の導出」、「〜の予想」、「〜の予測」、「〜の比較」、「〜の更新」、「〜の設定」、「〜の登録」、「〜の選択」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１〜４で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１〜４で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
また、実施の形態１〜４の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、実施の形態１〜４の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１〜４の「〜部」の手順や方法をコンピュータに実行させるものである。
このように、実施の形態１〜４に示すサービスサーバ装置３は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
１ ユーザ端末、２ サービスシステム、３ サービスサーバ装置、４ データ管理装置、５ 検索要求受付部、６ 検索要求処理部、７ 多重度制御部、８ データ、９ 処理時間予想部、１０ データ管理装置管理テーブル、１１ カラム統計情報管理テーブル、１２ 契約情報管理テーブル、１３ 契約情報マスタテーブル、１４ 平均処理時間記録テーブル、１５ 情報記憶部、１６ 検索要求履歴分析部、１７ データ管理装置制御部、１８ 検索要求履歴テーブル、１９ 履歴分析テーブル、２０ データ管理装置。
Claims (14)
- 各々が１つ以上のデータ処理を並行して実行できる複数のデータ処理装置を管理する情報処理装置であって、
データ処理装置ごとに、各データ処理装置が並行して実行できるデータ処理数と１つのデータ処理に要する処理時間との関係が多重度として示される多重度情報を記憶する情報記憶部と、
データ処理を要求するデータ処理要求を受信する受信部と、
前記受信部により受信されたデータ処理要求において要求されている要求データ処理に要する処理時間を予想する処理時間予想部と、
前記処理時間予想部により予想された前記要求データ処理の予想処理時間と前記多重度情報に示されている各データ処理装置の多重度とに基づき、前記要求データ処理を実行させるデータ処理装置を選択する選択部とを有することを特徴とする情報処理装置。 - 前記情報記憶部は、
データ処理装置ごとに、並行して実行できるデータ処理数が多いほど１つのデータ処理に要する処理時間が長くなり、並行して実行できるデータ処理数が少ないほど１つのデータ処理に要する処理時間が短くなる関係の多重度が示される多重度情報を記憶しており、
前記選択部は、
予想処理時間が短い要求データ処理ほど、並行して実行できるデータ処理数が多く１つのデータ処理に要する処理時間が長い多重度を優先して選択し、選択した多重度に対応するデータ処理装置を選択することを特徴とする請求項１に記載の情報処理装置。 - 前記情報記憶部は、
複数段階の多重度が示され、並行して実行できるデータ処理数が多い多重度ほど短い処理時間が対象範囲となるように各段階の多重度に対して処理時間の対象範囲が示される多重度情報を記憶しており、
前記選択部は、
前記処理時間予想部により予想された予想処理時間と各段階の多重度の処理時間の対象範囲を比較し、処理時間の対象範囲が予想処理時間に合致している多重度を選択し、選択した多重度に対応するデータ処理装置を選択することを特徴とする請求項２に記載の情報処理装置。 - 前記情報処理装置は、更に、
前記複数のデータ処理装置による過去のデータ処理における処理時間の実績値に基づき、今後のデータ処理における処理時間の傾向が過去のデータ処理における処理時間の傾向から変化するか否かを予測する傾向予測部と、
前記傾向予測部により今後のデータ処理における処理時間の傾向が過去のデータ処理における処理時間の傾向から変化すると予測された場合に、いずれかのデータ処理装置の多重度の設定を変更する多重度管理部とを有することを特徴とする請求項１〜３のいずれかに記載の情報処理装置。 - 前記傾向予測部は、
今後のデータ処理における処理時間の傾向が過去のデータ処理における処理時間の傾向から変化することにより特定の多重度のデータ処理装置でのデータ処理が増加するか否かを予測し、
前記多重度管理部は、
前記傾向予測部により前記特定の多重度のデータ処理装置でのデータ処理が増加すると予測された場合に、いずれかのデータ処理装置の多重度の設定を変更して、前記特定の多重度のデータ処理装置の数を増加させることを特徴とする請求項４に記載の情報処理装置。 - 前記情報処理装置は、
前記複数のデータ処理装置として、稼働している稼働データ処理装置と待機している待機データ処理装置とに接続され、
前記多重度管理部は、
前記傾向予測部により前記特定の多重度のデータ処理装置でのデータ処理が増加すると予測された場合に、待機データ処理装置の多重度の設定を変更して、前記特定の多重度のデータ処理装置の数を増加させることを特徴とする請求項４又は５に記載の情報処理装置。 - 前記傾向予測部は、
前記多重度管理部によりいずれかのデータ処理装置の多重度の設定が変更される場合に、次に処理時間の傾向予測を行う傾向予測タイミングを設定し、設定した傾向予測タイミングが到来した際に、過去のデータ処理における処理時間の実績値に基づき、今後のデータ処理における処理時間の傾向が過去のデータ処理における処理時間の傾向から変化するか否かを予測し、
前記多重度管理部は、
前記傾向予測部による予測結果に基づき、多重度の設定を変更したデータ処理装置の多重度の設定を元の多重度に戻すか否かを判断することを特徴とする請求項４〜６のいずれかに記載の情報処理装置。 - 前記傾向予測部は、
特異値分解により、今後のデータ処理における処理時間の傾向が過去のデータ処理における処理時間の傾向から変化するか否かを予測することを特徴とする請求項４〜７のいずれかに記載の情報処理装置。 - 前記受信部は、
要求データ処理としてデータ検索処理を要求し、データ検索処理における検索条件が１つ以上示されるデータ処理要求を受信し、
前記処理時間予想部は、
前記データ処理要求に示される検索条件の個数に基づき、要求されているデータ検索処理に要する処理時間を予想することを特徴とする請求項１〜８のいずれかに記載の情報処理装置。 - 前記受信部は、
要求データ処理として、複数のカラムが含まれる表形式のデータに対するデータ検索処理を要求し、検索キーとなる検索対象カラムが１つ以上示されるデータ処理要求を受信し、
前記情報記憶部は、
前記表形式のデータのカラムごとに、カラムへのアクセス時間の統計値が示されるカラム統計情報を記憶し、
前記処理時間予想部は、
前記データ処理要求に示される検索対象カラムと前記カラム統計情報とに基づき、要求されているデータ検索処理に要する処理時間を予想することを特徴とする請求項１〜８のいずれかに記載の情報処理装置。 - 前記受信部は、
要求データ処理の要求元のユーザの識別情報が示されるデータ処理要求を受信し、
前記情報記憶部は、
登録されているユーザごとに、データ処理の処理時間に対するユーザの要求レベルが示される要求レベル情報を記憶し、
前記処理時間予想部は、
前記データ処理要求に示される要求元のユーザの識別情報と要求レベル情報とに基づき、要求元のユーザの要求レベルを判断して、要求データ処理に要する処理時間を予想することを特徴とする請求項１〜８のいずれかに記載の情報処理装置。 - 前記情報記憶部は、
前記複数のデータ処理装置による過去のデータ処理における処理時間の実績値をデータ処理を実行した時間帯別に示す時間帯別処理時間情報を記憶し、
前記処理時間予想部は、
前記受信部によるデータ処理要求の受信時刻に対応する時間帯の処理時間の実績値を前記時間帯別処理時間情報から抽出し、抽出した処理時間の実績値に基づき、要求データ処理に要する処理時間を予想することを特徴とする請求項１〜８のいずれかに記載の情報処理装置。 - 各々が１つ以上のデータ処理を並行して実行できる複数のデータ処理装置を管理するコンピュータが行う情報処理方法であって、
前記コンピュータが、データ処理を要求するデータ処理要求を受信する受信ステップと、
前記コンピュータが、前記受信ステップにより受信されたデータ処理要求において要求されている要求データ処理に要する処理時間を予想する処理時間予想ステップと、
データ処理装置ごとに、各データ処理装置が並行して実行できるデータ処理数と１つのデータ処理に要する処理時間との関係が多重度として示される多重度情報を、前記コンピュータが情報記憶領域から読み出す情報読み出しステップと、
前記コンピュータが、前記処理時間予想ステップにより予想された前記要求データ処理の予想処理時間と前記多重度情報に示されている各データ処理装置の多重度とに基づき、前記要求データ処理を実行させるデータ処理装置を選択する選択ステップとを有することを特徴とする情報処理方法。 - 各々が１つ以上のデータ処理を並行して実行できる複数のデータ処理装置を管理するコンピュータに、
データ処理を要求するデータ処理要求を受信する受信処理と、
前記受信処理により受信されたデータ処理要求において要求されている要求データ処理に要する処理時間を予想する処理時間予想処理と、
データ処理装置ごとに、各データ処理装置が並行して実行できるデータ処理数と１つのデータ処理に要する処理時間との関係が多重度として示される多重度情報を、情報記憶領域から読み出す情報読み出し処理と、
前記処理時間予想処理により予想された前記要求データ処理の予想処理時間と前記多重度情報に示されている各データ処理装置の多重度とに基づき、前記要求データ処理を実行させるデータ処理装置を選択する選択処理とを実行させることを特徴とするプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008326829A JP2010152435A (ja) | 2008-12-24 | 2008-12-24 | 情報処理装置及び情報処理方法及びプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008326829A JP2010152435A (ja) | 2008-12-24 | 2008-12-24 | 情報処理装置及び情報処理方法及びプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2010152435A true JP2010152435A (ja) | 2010-07-08 |
Family
ID=42571493
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008326829A Pending JP2010152435A (ja) | 2008-12-24 | 2008-12-24 | 情報処理装置及び情報処理方法及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2010152435A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011039740A (ja) * | 2009-08-10 | 2011-02-24 | Ntt Data Corp | サーバ管理システム、サーバ管理方法、及びプログラム |
| EP2927797A1 (en) | 2014-03-31 | 2015-10-07 | Fujitsu Limited | Information processing device, information processing system, storage medium storing program for controlling information processing device, and method for controlling information processing device |
| WO2017109911A1 (ja) * | 2015-12-24 | 2017-06-29 | 株式会社日立製作所 | ホストにとってデータ転送量が不明な検索リクエストを処理する検索処理システム及び方法 |
| CN113535320A (zh) * | 2020-04-14 | 2021-10-22 | 深信服科技股份有限公司 | 一种数据访问方法、装置、设备及存储介质 |
-
2008
- 2008-12-24 JP JP2008326829A patent/JP2010152435A/ja active Pending
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011039740A (ja) * | 2009-08-10 | 2011-02-24 | Ntt Data Corp | サーバ管理システム、サーバ管理方法、及びプログラム |
| EP2927797A1 (en) | 2014-03-31 | 2015-10-07 | Fujitsu Limited | Information processing device, information processing system, storage medium storing program for controlling information processing device, and method for controlling information processing device |
| US9477618B2 (en) | 2014-03-31 | 2016-10-25 | Fujitsu Limited | Information processing device, information processing system, storage medium storing program for controlling information processing device, and method for controlling information processing device |
| WO2017109911A1 (ja) * | 2015-12-24 | 2017-06-29 | 株式会社日立製作所 | ホストにとってデータ転送量が不明な検索リクエストを処理する検索処理システム及び方法 |
| US10860577B2 (en) | 2015-12-24 | 2020-12-08 | Hitachi, Ltd. | Search processing system and method for processing search requests involving data transfer amount unknown to host |
| CN113535320A (zh) * | 2020-04-14 | 2021-10-22 | 深信服科技股份有限公司 | 一种数据访问方法、装置、设备及存储介质 |
| CN113535320B (zh) * | 2020-04-14 | 2024-02-23 | 深信服科技股份有限公司 | 一种数据访问方法、装置、设备及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5363485B2 (ja) | トランザクション処理スループットを高めるためのトランザクション集約 | |
| US7721288B2 (en) | Organizing transmission of repository data | |
| US8190599B2 (en) | Stream data processing method and system | |
| US10348815B2 (en) | Command process load balancing system | |
| US20180144272A1 (en) | Parallel processing apparatus and method of estimating power consumption of jobs | |
| CN111414389B (zh) | 一种数据处理方法、装置、电子设备及存储介质 | |
| US20100017486A1 (en) | System analyzing program, system analyzing apparatus, and system analyzing method | |
| US20080172668A1 (en) | Profile-based cpu/core affinity | |
| US9456036B2 (en) | Switch-based data tiering | |
| US20140278723A1 (en) | Methods and systems for predicting workflow preferences | |
| JP2008090507A (ja) | ジョブ実行のスケジューリングプログラム、ジョブ実行のスケジューリング方法、ジョブ実行のスケジューリング装置 | |
| US10095737B2 (en) | Information storage system | |
| CN109213691B (zh) | 用于缓存管理的方法和设备 | |
| JP2010152435A (ja) | 情報処理装置及び情報処理方法及びプログラム | |
| US10599472B2 (en) | Information processing apparatus, stage-out processing method and recording medium recording job management program | |
| US20160034491A1 (en) | Methods for accessing big data and systems using the same | |
| JP2018147301A (ja) | 計算機システム及び処理の割当方法 | |
| JP2008158889A (ja) | トラブル要因検出プログラム、トラブル要因検出方法およびトラブル要因検出装置 | |
| US10671636B2 (en) | In-memory DB connection support type scheduling method and system for real-time big data analysis in distributed computing environment | |
| JPWO2008105099A1 (ja) | アプリケーション連携制御プログラム、アプリケーション連携制御方法およびアプリケーション連携制御装置 | |
| US20230132117A1 (en) | Handling system-characteristics drift in machine learning applications | |
| US10621163B2 (en) | Tracking and reusing function results | |
| US10067678B1 (en) | Probabilistic eviction of partial aggregation results from constrained results storage | |
| US8312100B2 (en) | Managing orphaned requests in a multi-server environment | |
| JP2007206913A (ja) | データベースアクセスシステム、アプリケーションサーバノード、データベースアクセス方法及びプログラム |