JP4815459B2 - 負荷分散制御サーバ、負荷分散制御方法及びコンピュータプログラム - Google Patents

負荷分散制御サーバ、負荷分散制御方法及びコンピュータプログラム Download PDF

Info

Publication number
JP4815459B2
JP4815459B2 JP2008057058A JP2008057058A JP4815459B2 JP 4815459 B2 JP4815459 B2 JP 4815459B2 JP 2008057058 A JP2008057058 A JP 2008057058A JP 2008057058 A JP2008057058 A JP 2008057058A JP 4815459 B2 JP4815459 B2 JP 4815459B2
Authority
JP
Japan
Prior art keywords
query
server
execution
server computer
computer
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.)
Expired - Fee Related
Application number
JP2008057058A
Other languages
English (en)
Other versions
JP2009217300A (ja
Inventor
毅 安西
真一 川本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2008057058A priority Critical patent/JP4815459B2/ja
Priority to US12/218,360 priority patent/US20090228446A1/en
Publication of JP2009217300A publication Critical patent/JP2009217300A/ja
Application granted granted Critical
Publication of JP4815459B2 publication Critical patent/JP4815459B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2453Query optimisation
    • G06F16/24534Query rewriting; Transformation
    • G06F16/24539Query rewriting; Transformation using cached or materialised query results
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • G06F16/24552Database cache management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/284Relational databases

Description

本発明は、ヘテロジーニアスな計算機システムでの負荷分散制御の技術に関する。
例えば、クライアントからのリクエストに応じた処理を実行するアプリケーションサーバ(APサーバ)と、APサーバから出力されるデータベースクエリ(DBクエリ)を実行するデータベースサーバ(DBサーバ)とに機能を分離し、APサーバ及びDBサーバをそれぞれ独立した計算機で動作させる、つまりヘテロジーニアス(異機種混在)な計算機システムを構築することで、システムパフォーマンスを向上する技術が知られている。APサーバが動作する計算機(以下、「APサーバ計算機」と呼ぶ)とDBサーバが動作する計算機(以下、「DBサーバ計算機」と呼ぶ)で構成されるシステムにおいては、一般的に、DBサーバ計算機が性能ボトルネックになる傾向がある。
これに対して、クライアントからのリクエストに指定されたSQL(Structured Query Language)をDBサーバに代わってAPサーバで実行する技術(以下、「代理実行技術」と呼ぶ)も知られている。特許文献1に記載の技術では、SQLプロシージャの一部をAPサーバが代理実行する。このように、DBクエリをAPサーバで代理実行することにより、DBサーバ計算機が性能ボトルネックになる度合いを軽減することができる。この種の技術では、APサーバで代理実行する処理は固定的であり、DBサーバ計算機の負荷は下がるが、アクセスの量的変化に伴い、APサーバ計算機が過負荷になることがある。
特許文献2には、所定の計算機から複数のサーバ計算機が等距離に位置する計算機システム(以下、「ホモジーニアスな計算機システム」と呼ぶ)における負荷分散技術が開示されている。具体的には、特許文献2では、複数のサーバ計算機に所定の計算機(データ処理システム)が接続されており、所定の計算機が、各サーバ計算機の負荷状態を測定し、最も負荷の低いサーバ計算機を、リクエストを処理するサーバ計算機と動的に決定し、決定したサーバ計算機にリクエストを転送する。
しかし、全てのリクエストについて、リクエストの実行に要するリクエスト時間長が同じであるとは限らないことがある。
特許文献3には、ホモジーニアスな計算機システムにおいて、リクエストの実行時間長を予測する技術が開示されている。
特開平10−240591公報 特開平07−093238公報 特開2003−58518公報
APサーバがDBサーバに代わってDBクエリを実行する(以下、「代理実行する」と呼ぶ)計算機システムは、ホモジーニアスな計算機システムではなく、ヘテロジーニアスな計算機システムである。
このようなヘテロジーニアスな計算機システムに、ホモジーニアスな計算機システムに有用な技術を単純に適用することはできず、仮に適用できたとしても、DBクエリの負荷分散を適切に行うことはできない。その一つの理由として、ホモジーニアスな計算機システムでは、所定の計算機システムから複数のサーバ計算機のうちのいずれかに必ずリクエストの転送が発生するのに対し、ヘテロジーニアスな計算機システムでは、APサーバ計算機からDBサーバ計算機へのDBクエリの転送が必ずしも発生しない点にある。
従って、本発明の目的は、APサーバ計算機とDBサーバ計算機とを含むヘテロジーニアスな計算機システムにおいて適切に負荷分散を行うことにある。
本発明の他の目的は、後の説明から明らかになるであろう。
APサーバ計算機とDBサーバ計算機とを含んだヘテロジーニアスな計算機システムに、DBクエリを代理実行する機能を備えた負荷分散制御サーバを備える。負荷分散制御サーバは、APサーバからDBクエリを受け付け、DBクエリの実行による計算機リソースの消費度合いに関わる要素である計算機リソース消費関連要素に基づいて、そのDBクエリを代理実行するかDBサーバ計算機に転送しDBサーバで実行するかを判定する。代理実行すると判定したならば、DBクエリを代理実行し、DBクエリをDBサーバ計算機に転送しDBサーバで実行すると判定したならば、DBクエリをDBサーバ計算機に転送する。
以下、本発明の一実施形態に係る負荷分散制御サーバが適用されたデータ処理代理実行サーバを備える計算機システムの幾つかの実施例として、実施例1乃至実施例3を説明する。その際、負荷分散制御サーバの全ての構成要素が、APサーバ計算機に存在するものとする。しかし、それは一例であり、負荷分散制御サーバの少なくとも一部分が、APサーバ計算機及びDBサーバ計算機以外の計算機に存在しても良い。
実施例1乃至実施例3を説明する前に、DBクエリを代理実行するかDBサーバ計算機に転送してDBサーバで実行するかの判定(以下、「クエリ実行サーバ判定」と呼ぶ)の方法について、以下の第一の方法乃至第三の方法を例に採り、詳細に説明する。その際、クエリサーバ実行判定の対象とされるDBクエリを「対象DBクエリ」と呼ぶ。
第一及び第二の方法は、クエリ実行サーバ判定を、対象DBクエリをAPサーバ計算機で代理実行することに要するコスト(以下、「APサーバでのクエリ実行コスト」と呼ぶ)と、対象DBクエリをDBサーバ計算機に転送してDBサーバで実行することに要するクエリ実行コスト(以下、「DBサーバでのクエリ実行コスト」と呼ぶ)とをそれぞれ算出し、算出されたクエリ実行コスト同士を比較し、比較の結果に基づいて、クエリ実行サーバ判定を行う方法である(本明細書において、「コスト」とは、金額のことではなく、計算機リスソースをどのぐらい消費するかの度合いを意味する)。第三の方法は、対象DBクエリの形式に基づいてクエリ実行サーバ判定を行う方法である。APサーバでのクエリ実行コスト、DBサーバでのクエリ実行コスト、及び対象DBクエリの形式のいずれも、前述した計算機リソース消費関連要素の一例である。
第一及び第二の方法に関して、APサーバ計算機でのクエリ実行コストと、DBサーバ計算機に転送して実行するクエリ実行コストの比較は、(式1)の不等式、
(APサーバ計算機でのクエリ実行コスト)>(DBサーバ計算機でのクエリ実行コスト)+(クエリ通信コスト)
・・(式1)
で表現される。クエリ実行サーバ判定において算出された「APサーバ計算機でのクエリ実行コスト」、「DBサーバのクエリ実行コスト」及び「クエリ通信コスト」を用いて(式1)の不等式が成立すれば、対象DBクエリをDBサーバ計算機に転送しDBサーバで実行すると判定され、(式1)の不等式が成立しなければ、対象DBクエリを代理実行すると判定される。
ここで、「APサーバ計算機でのクエリ実行コスト」は、APサーバ計算機で対象DBクエリを実行するのに要する時間長(以下、「AP実行時間長」と呼ぶ)を意味する。「DBサーバのクエリ実行コスト」は、DBサーバ計算機で対象DBクエリを実行するのに要する時間長(以下、「DB実行時間長」と呼ぶ)を意味する。「クエリ通信コスト」は、DBサーバ計算機に対象DBクエリを転送して実行する際に発生する通信時間を意味する。
(式1)における各クエリ実行コストを算出する(見積もる)際には、性能と精度のトレードオフを考慮することが望ましい。クエリ実行コストを高い精度で算出するには、クエリ実行コスト算出のための高度な演算、及びその算出に必要な情報を採取する処理が発生する。演算や情報採取を含んだコスト算出処理が影響して、システムパフォーマンスが低下するおそれがある。そのため、クエリ実行コストの算出には、性能への影響に配慮した上で、妥当な精度を算出できる方法を採用することが望ましい。
第一の方法は、クエリ実行コストの算出(見積り)の精度を優先した方法である。第一の方法では、「APサーバ計算機でのクエリ実行コスト」が、APサーバ計算機での対象DBクエリの実行プランに基づいて算出され、「DBサーバ計算機でのクエリ実行コスト」が、DBサーバ計算機での対象DBクエリの実行プランに基づいて算出される。実行プランには、対象DBクエリに対する処理手続きが記述されており、対象DBクエリを実行した際の、ユーザデータに対するシーケンシャルアクセス、インデクススキャンといったプリミティブな操作の回数(以下、「実行ステップ数」と呼ぶ)を知ることができる。この実行ステップ数に、プリミティブな操作に必要な実行時間長を乗算することで、精度の高いコスト算出ができることが期待できる。それにより、「APサーバ計算機でのクエリ実行コスト」を、APサーバ計算機で対象DBクエリを実行する場合の実行プランが表す実行ステップ数に対して、プリミティブな操作に要する実行時間長を乗算することで算出することができる。また、「DBサーバ計算機でのクエリ実行コスト」は、DBサーバ計算機で対象DBクエリを実行する場合の実行プランにおける実行ステップ数に対して、プリミティブな操作に要する実行時間長を乗算することで算出することができる。
「クエリ通信コスト」は、APサーバ計算機からDBサーバ計算機に対象DBクエリを転送する通信コストと、DBサーバ計算機からAPサーバ計算機に対象DBクエリの実行結果を転送する通信コストとの総和によって算出される。具体的には、例えば、「クエリ通信コスト」は、対象DBクエリのサイズ(以下、「クエリサイズ」と呼ぶ)、及び対象DBクエリの実行結果のサイズ(以下、「クエリ結果サイズ」と呼ぶ)との総和を、APサーバ計算機とDBサーバ計算機との間の転送の速度で除算することで、算出される。
以上のことから、第一の方法では、(式1)を、以下の(式2)、
(APサーバ計算機でのクエリ実行ステップ数)×(APサーバ計算機での1実行ステップ数あたりの実行時間長)>(DBサーバ計算機でのクエリ実行ステップ数)×(DBサーバ計算機での1実行ステップ数あたりの実行時間長)+((クエリサイズ)+(クエリ結果サイズ))/(転送速度)・・(式2)
として定義することができる。
第二の方法は、第一の方法における、「DBサーバ計算機でのクエリ実行コスト」の算出を簡易化した方法である。「DBサーバ計算機でのクエリ実行コスト」を算出するためには、例えば、以下の(1)乃至(3)、
(1)DBサーバが管理する実行プラン生成用情報(実行プランを生成するため必要な情報、例えばディクショナリ表)の収集、
(2)実行ステップに対する実行時間長の収集、
(3)収集された実行プラン生成用情報、及び実行ステップに対する実行時間長を用いて、対象DBクエリの実行時間長を算出すること、
が必要である。そのため、計算機への負荷が発生する。第二の方法では、第一の方法よりも計算機への負荷を軽減することができる。
APサーバが、DBサーバと同じディクショナリ表及びユーザデータをキャッシュしていると仮定すると、対象DBクエリに対するDBサーバ計算機とAPサーバ計算機の実行ステップ数は等しくなる。なぜなら、実行ステップ数が、ディクショナリ表及びユーザデータに基づいて算出されるためである。故に、結果として、両者のクエリ実行コストの違いを、DBサーバのAPサーバに対する処理性能の比率(以下、「DBサーバ性能比率」と呼ぶ)を導入して近似することができる。具体的には、「DBサーバ計算機でのクエリ実行コスト」を、「APサーバ計算機でのクエリ実行コスト」に「DBサーバ性能比率」を乗算することで、「DBサーバ計算機のクエリ実行コスト」を近似することができる。
以上のことから、(式2)は、以下の(式3)、
(APサーバ計算機でのクエリ実行ステップ数)×(APサーバ計算機での1実行ステップ数あたりの実行時間長)>(APサーバ計算機でのクエリ実行コスト)×(DBサーバ性能比率)+((クエリサイズ)+(クエリ結果サイズ))/(転送速度)・・(式3)
として定義することができる。
「DBサーバ性能比率」の具体的な算出方法の一例として、DBサーバのAPサーバに対する1DBクエリあたりの平均実行時間長(以下、「平均クエリ実行時間長」と呼ぶ)の比率を求める方法が考えられる。この場合の「DBサーバ性能比率」の計算機を以下の(式4)、
(DBサーバ性能比率)=(DBサーバ計算機での平均クエリ実行時間長)/(APサーバ計算機での平均クエリ実行時間長)
・・(式4)
に定義する。
「DBサーバ性能比率」の算出に平均クエリ実行時間長を利用することの理由は、次のとおりである。すなわち、DBクエリを受け付けて、その実行結果を応答する処理は、待ち行列として捉えることができ、待ち行列理論の平均待ち時間に対応する平均クエリ実行時間長を、性能比率として採用することが妥当と考えられるからである。具体的には、待ち行列理論のM/M/1モデルでは、単位時間に到着する呼の数の平均値をλ、単位時間に交換機でサービス可能な呼の数の平均値をμとした場合に、平均サービス時間をts(=1/μ)、交換機が実際に使われている時間の割合である利用率λ/μをρとおくと、平均待ち時間はρ/(1−ρ)×tsである、といった知見が得られている。ここで、平均待ち時間を、平均クエリ実行時間長に置き換えると、平均クエリ実行時間長は、利用率が1に近づくにつれて急激に増えることになり、これは一般的なデータベースにおける平均クエリ実行時間長の変化に類似している。
なお、「DBサーバ性能比率」の算出には、平均クエリ実行時間長に代えて又は加えて、CPU使用率などの各種処理能力を用いることもできる。
第三の方法は、第一及び第二の方法よりも簡易的なクエリ実行サーバ判定方法である。第三の方法は、クエリの形式と計算機リソースの消費度合いとが関連しているという観点に基づき、計算機リソース消費関連要素の一例としてクエリ形式を選定した方法である。具体的には、例えば、第三の方法は、対象DBクエリが特定のクエリ形式に合致した場合に(式1)を満たすという仮定に基づく。つまり、対象DBクエリが特定のクエリ形式に合致した場合に、対象DBクエリをDBサーバ計算機に転送すると判定される。(式1)の不等式が成立するDBクエリの傾向として、CPUインテンシブであり且つクエリ結果サイズが小さいことが挙げられる。これに合致するDBクエリの一例として、Group By句が挙げられる。Group By句は、行データをグループ化して、同一グループに対して、合計や平均といった集計を行う際に活用される。これに対する実行プランは、Group By句で指定されたカラムのデータ集合に対して、ソート処理を行い、ソートされたデータ集合に対して、集計を行うため、CPUインテンシブになる傾向がある。また、グループ化により、DBクエリに対するクエリ結果件数は少なくなり、結果として、クエリ結果サイズが小さくなる傾向にある。そこで、Group By句を含む対象DBクエリが検出された場合には、(式1)の不等式を満たすとの仮定の基で、対象DBクエリをDBサーバ計算機に転送するとの判定になる。CPUインテンシブであり且つクエリ結果サイズが小さくなる傾向にあるクエリ形式のDBクエリとしては、Group By句の他に、ソート処理や、行データのシーケンシャル操作を行うDBクエリが考えられる。例えば、JOINが指定された内部結合においても、その結合方式によっては、結合対象となる表における行データのソート処理や、行データ同士の突き合せ処理などがCPUインテンシブになる。なおかつ、結合元の表が小さい場合、結合結果が小さくなり、クエリ結果サイズも小さくなる。
特定のクエリ形式としては、データベースクエリを代理実行した場合のそのデータベースクエリの実行時間長が、そのデータベースクエリをDBサーバで実行する場合のクエリの実行時間長と、そのデータベースクエリをDBサーバで転送することによって行われる通信時間長(APサーバ計算機とDBサーバ計算機との間の通信に要する通信時間長)との和よりも多くなるようなクエリ形式である。好ましくは、特定のクエリ形式のデータベースクエリは、計算機リソースの消費量が他のクエリ形式のデータベースクエリよりも高く、クエリ結果サイズが他のクエリ形式のデータベースクエリよりも小さいクエリである。
以上のように、第三の方法では、DBクエリのクエリ形式に基づいてクエリ実行サーバ判定が行われる。
以下、図面を参照しながら、本発明の幾つかの実施例について詳細に説明する。その際、CPUがコンピュータプログラムを読み込んで実行することにより行われる処理の主体を、説明を分かりやすくするために、CPUではなくコンピュータプログラムとする場合がある。
図1は、本発明の実施例1に係る計算機システムの構成を示すブロック図である。
クライアント計算機100、1台以上のAPサーバ計算機110及びDBサーバ計算機120が、LAN(Local Area Network)やWAN(Wide Area Network)などの通信ネットワーク114に接続されている。これにより、計算機100、110及び120が相互に通信することができる。
クライアント計算機100は、ユーザから指定されたリクエストをAPサーバ計算機110とやりとりして処理するユーザインタフェースである。
APサーバ計算機110は、CPU(Central
Processing Unit)111等のプロセッサ、主記憶装置(メモリ)112、通信インタフェース113、及びこれらを接続するバス115などから構成される。APサーバ計算機110は、通信インタフェース113を介して通信ネットワーク114に接続される。CPU111は、主記憶装置112に格納される各種プログラムを実行する。主記憶装置112は、プログラムが処理を実行するための各種データを保持する。
DBサーバ計算機120は、CPU121等のプロセッサ、主記憶装置(メモリ)122、通信インタフェース123、ディスクインタフェース124、記憶装置125、及びこれらを接続するバス126などから構成される。DBサーバ計算機120は、通信インタフェース123を介して通信ネットワーク114に接続される。CPU121は、主記憶装置122に格納される各種プログラムを実行する。主記憶装置122は、プログラムが処理を実行するための各種データを保持する。記憶装置125は、例えば、ハードディスク等のディスク型の記憶メディアのドライブであり、それ故、記憶装置125に対するインタフェース装置がディスクインタフェース124となっている。しかし、記憶装置125は、そのようなドライブに限らず、他種の記憶装置を採用することも可能である。
図2は、APサーバ計算機110及びDBサーバ計算機120の構成を示す。
APサーバ計算機110におけるAPサーバ200は、クライアント計算機100からのリクエストに応じて、アプリケーションプログラム201を実行するサーバプログラムである。アプリケーションプログラム201は、クライアント計算機100に対してサービスを提供するための業務ロジックや、データアクセスプロセスから構成される。
APサーバ計算機110には、APサーバ200の他に、データ処理代理実行サーバ202が備えられる。データ処理代理実行サーバ202は、DBサーバ計算機120が管理するユーザデータを含む原本データ290のキャッシュ機能を持たせたプロキシサーバを意味し、アプリケーションプログラム201がアクセスするデータを、キャッシュデータ272から返すことができる。キャッシュデータ272は、原本データ290の全部又は一部である。これにより、DBサーバ計算機120にアクセスする必要がなくなるため、通信ネットワーク114のトラフィックの軽減、DBサーバ計算機120の負荷の軽減、及び、クライアント計算機100から見た応答時間の短縮が期待できる。
データ処理代理実行サーバ202は、クエリ実行部210、サーバ負荷判定部220、クエリ実行サーバ判定部230、クエリ転送部240、及びサーバ情報収集部250を有する。
クエリ実行部210は、APサーバ200からのDBクエリを代理実行することができる。DBクエリは、例えばSQL(Structured Query Language)の場合、参照系クエリであるSELECT文、更新系クエリであるINSERT文、UPDATE文、DELETE文がある。SQLは、リレーショナルデータベースマネージメントシステム(RDBMS)において、データの操作や定義を行うためのデータベースアクセス言語である。データベースアクセス言語には、XPathなどのXMLパス言語、XQuery(静的型付け機能を持つXMLデータ問合せのための関数型言語)などもある。さらに、実施例1では、SQLプロシージャといった、データアクセス要求を含む一連の処理をまとめた手続きプログラムもDBクエリに含まれる。実施例1では、データベースアクセス言語としてSQLを扱う。
クエリ実行部210は、クエリ受付モジュール214、クエリ解析モジュール211、クエリ制御モジュール212、及びクエリ実行モジュール213で構成される。クエリ受付モジュール214は、APサーバ200からDBクエリを受け付ける。クエリ解析モジュール211は、クエリ実行結果テーブル270(図3参照)、及びディクショナリ表テーブル271(図4参照)を用いて、APサーバ200から受付けたDBクエリを解析する。クエリ制御モジュール212は、サーバ負荷判定部220、クエリ実行サーバ判定部230を用いて、受け付けたDBクエリ(対象DBクエリ)をDBサーバで実行することになった場合、クエリ転送部240を起動してDBサーバ203に対象DBクエリを転送して実行させる。データ代理処理実行サーバ202でDBクエリを代理実行することになった場合、クエリ実行モジュール213は、クエリ実行結果テーブル270(図3参照)、及びキャッシュデータテーブル272(図5、図6参照)を用いて、そのDBクエリを代理実行する。クエリ実行部210は、DBクエリの代理実行の結果を、APサーバ200に返す。
サーバ負荷判定部220は、クエリ実行部210から起動され、サーバ負荷状況判定モジュール221で構成される。サーバ負荷状況判定モジュール221は、サーバ負荷判定基準テーブル273(図7参照)、及びサーバ計算機統計情報テーブル280(図8参照)を用いて、APサーバ計算機110が過負荷であり且つDBサーバ計算機120が低負荷であるか否かを判定する。なお、「APサーバ計算機110が過負荷」であるとは、例えば、APサーバ計算機110の所定種類の負荷(例えばCPU使用率)が第一の基準値よりも高い、又は、APサーバ計算機110の所定種類の負荷がDBサーバ計算機120よりも高いことである。「DBサーバ計算機120が低負荷である」とは、例えば、DBサーバ計算機120の所定種類の負荷(例えばCPU使用率)が第二の基準値よりも低い、又は、DBサーバ計算機120の所定種類の負荷がAPサーバ計算機110よりも低いことである。第一の基準値及び第二の基準値は、同一の基準値であっても良いし、異なる基準値であっても良い。その場合、第一の基準値は、第二の基準値よりも高くても小さくても良い。
クエリ実行サーバ判定部230は、クエリ実行部210から起動され、APサーバ計算機実行コスト見積モジュール231、DBサーバ計算機実行コスト見積モジュール232、ネットワーク処理コスト見積モジュール233、及びクエリ実行サーバ判定モジュール234で構成される。APサーバ計算機実行コスト見積モジュール231は、データ処理代理実行サーバ202が管理するクエリ実行結果テーブル270(図3参照)、ディクショナリ表テーブル271(図4参照)、及びサーバ計算機統計情報テーブル280(図8参照)を用いて、APサーバ計算機110でのクエリ実行コストを見積る。DBサーバ計算機実行コスト見積モジュール232は、クエリ実行結果テーブル270(図3参照)、DBサーバ203が管理するディクショナリ表テーブル281(図4参照)、及びサーバ計算機統計情報テーブル280(図8参照)を用いて、DBサーバ計算機120でのクエリ実行コストを見積る。ネットワーク処理コスト見積モジュール233は、ネットワーク負荷情報テーブル282(図9参照)を用いて、クエリ通信コストを見積る。クエリ実行サーバ判定モジュール234は、APサーバ計算機実行コスト見積モジュール231、DBサーバ計算機実行コスト見積モジュール232、及びネットワーク処理コスト見積233の見積り値(APサーバ計算機110でのクエリ実行コスト、DBサーバ計算機120でのクエリ実行コスト、及びクエリ通信コスト)から、対象DBクエリをAPサーバ計算機110で代理実行するかDBサーバ計算機120に転送してDBサーバ203で実行するかを判定する。
クエリ転送部240は、クエリ実行部210から起動され、クエリ転送モジュール241、及びネットワーク負荷収集モジュール242で構成される。クエリ転送モジュール241は、DBサーバ203に対象DBクエリを実行させ、実行結果をDBサーバ203から受けてAPサーバ202に返す。ネットワーク負荷収集モジュール242は、APサーバとDBサーバ間のネットワーク負荷を表す情報を収集し、収集されたネットワーク負荷情報をネットワーク負荷情報テーブル282(図9参照)に書き込む。
サーバ情報収集部250は、APサーバ計算機統計情報収集モジュール251、DBサーバ計算機統計情報収集モジュール252、及びDBサーバディクショナリ表収集モジュール253で構成される。APサーバ計算機統計情報収集モジュール251は、APサーバ計算機110のCPU使用率や平均クエリ実行時間長といった各種統計情報を収集し、収集された各種統計情報をサーバ計算機統計情報テーブル280(図8参照)に書き込む。DBサーバ計算機統計情報収集モジュール252は、DBサーバ203からDBサーバ計算機120のCPU使用率や平均クエリ実行時間長といった各種統計情報を収集し、収集された各種統計情報を、サーバ計算機統計情報テーブル280(図8参照)に書き込む。DBサーバディクショナリ表収集モジュール253は、DBサーバ203が管理するDBサーバのディクショナリ表テーブル292を取得して、DBサーバのディクショナリ表テーブル281(図4参照)として主記憶装置112に保存する。
DBサーバ計算機120におけるDBサーバ203は、データ処理代理実行サーバ202からのリクエストに応じて、DBクエリを実行するサーバプログラムである。DBサーバ203は、記憶装置125に、原本データ290(図5、図6参照)、DBサーバ計算機統計情報テーブル291(図8参照)、及びDBサーバディクショナリ表テーブル292(図5参照)を保持する。DBサーバ203は、クエリ実行部260を有する。クエリ実行部260は、データ処理代理実行サーバ202からのリクエストに応じて、DBクエリを実行する。
図3は、クエリ実行結果テーブル270の一例を示す。
クエリ実行結果テーブル270は、過去のクエリ実行結果が記録されるテーブルである。テーブル270の各行は、過去に実行された各クエリに対応し、クエリ310、実行プラン320、及び実行結果サイズ330からなる。クエリ310は、このクエリ310に対応するDBクエリの文字列である。実行プラン320は、この実行プラン320に対応するDBクエリを解析し最適化された処理手続きを示す実行プランである。実行結果サイズ330は、この実行結果サイズ330に対応するDBクエリの実行結果のサイズを示す数値である。本テーブル270の管理方法の一例として、あらかじめ指定された上限件数や上限サイズに収まるように、FIFO(First In First Out)などのアルゴリズムに従って管理することが考えられる。
図4は、ディクショナリ表テーブル292の一例を示す。
この図に示すテーブル292の構成は、APサーバ計算機110内の主記憶装置112にキャッシュされているディクショナリ表テーブル271、DBサーバ計算機120内の主記憶装置122にキャッシュされている203のディクショナリ表テーブル281にも適用される。ディクショナリ表テーブル292は、種々のテーブル(例えば、ユーザデータを保持するテーブルt1、t2(図5及び図6参照))を管理するためのテーブルである。テーブル292の各行は、テーブル名410、カラム名420、カラムデータ型430、及びデータサイズ440からなる。テーブル名410は、このテーブル名410に対応するテーブルの名称を示す文字列である。カラム名420は、このカラム名420に対応するテーブルに属するカラムの名称を示す文字列である。カラムデータ型430は、このカラムデータ型430に対応するテーブルにおけるカラムのデータ型(例えばint型やvarchar型)を示す文字列である。データサイズ440は、このデータサイズ440に対応するテーブルにおけるカラムのデータサイズを示す数値である。本テーブル292は、テーブル生成(CREATE TABLE)、テーブル破棄(DROP TABLE)、テーブル更新(ALTER TABLE)といったテーブル定義系クエリに対して、ユーザデータに対するテーブルの状態が管理される。
図5は、ユーザデータを保持するテーブルt1の一例を示す。
テーブルt1は、原本データ290に含まれるテーブルであり、キャッシュデータ272に含まれることもある。テーブルt1の各行は、id510、productID520、date530、quantity540、及びprice550からなる。DBクエリに従って、該当する行あるいは列に対して、参照及び更新がなされる。
図6は、ユーザデータを保持するテーブルt2の一例を示す。
テーブルt2は、原本データ290に含まれるテーブルであり、キャッシュデータ272に含まれることもある。テーブルt2の各行は、productID610、name620、category630、及びunitprice640からなる。DBクエリに従って、該当する行あるいは列に対して、参照及び更新がなされる。
図7は、サーバ負荷判定基準テーブル273の一例を示す。
サーバ負荷判定基準テーブル273は、サーバ負荷を判定する基準情報を保持するテーブルである。テーブル273の各行は、サーバ識別情報710、性能指標720、及び負荷判定基準730からなる。サーバ識別情報710は、サーバ識別情報710に対応するサーバ計算機(負荷を判定する対象となるAPサーバ計算機110あるいはDBサーバ計算機120)を識別するための識別情報であり、ホスト名、あるいはIPアドレスとなる。性能指標720は、負荷判定における指標であり、CPU使用率、スループットなどの文字列である。負荷判定基準730は、APサーバ計算機110が過負荷であるか否か及びDBサーバ計算機120が低負荷であるか否かの基準を表す。図7の例によれば、APサーバ計算機110は、CPU使用率が80%以上であるならば過負荷であり、DBサーバ計算機120は、CPU使用率が30%以下であるならば低負荷である。負荷判定基準730は、システムのパフォーマンス設計に基づいてあらかじめ設定しておくことができる。また、サーバ負荷を適切に判定するために、システムのパフォーマンス状況からフィードバックをかけ、負荷判定基準730が動的に自動で変更されても良い。
図8は、サーバ計算機統計情報テーブル280の一例を示す。
サーバ計算機統計情報テーブル280は、サーバ計算機に関する統計情報を保持するテーブルである。テーブル280の各行は、サーバ識別情報810、CPU使用率820、1実行ステップあたりの実行時間長830、及び平均クエリ実行時間長840からなる。サーバ識別情報710は、このサーバ識別情報710に対応するサーバ計算機(負荷を判定する対象となるAPサーバ計算機110あるいはDBサーバ計算機120)を識別するための識別情報であり、ホスト名、あるいはIPアドレスとなる。CPU使用率820は、このCPU使用率820に対応するサーバ計算機のCPU使用率を示す数値である。1実行ステップあたりの実行時間長830は、この実行時間長830に対応するサーバ計算機のDBクエリの実行プランにおける1実行ステップを処理するに要する時間を示す数値である。平均クエリ実行時間長840は、この平均クエリ実行時間長840に対応するサーバ計算機で1つのDBクエリを実行するのに要する時間を示す数値である。これらの統計情報の収集に伴う計算機リソースの消費を抑えるため、あらかじめ指定された時間間隔で定期的に収集することが望ましい。
DBサーバ計算機統計情報テーブル291も、サーバ計算機統計情報テーブル280と同様の構成を採ることができる。但し、テーブル280のようなサーバ識別情報810は無くても良い。
図9は、ネットワーク負荷情報テーブル282の一例を示す。
ネットワーク負荷情報テーブル282は、ネットワークの負荷情報を保持するテーブルである。テーブル282の各行は、転送速度910、及び平均応答時間920からなる。転送速度910は、APサーバ計算機110とDBサーバ計算機120間でデータ送受信を行う際の実効速度を示す数値である。平均応答時間920は、APサーバ計算機110がDBサーバ計算機120に対象DBクエリを転送した際に応答結果を取得するまでに要する時間を示す数値である。これらの値を、あらかじめ静的に設定しておくことも可能であるが、実際のクエリ転送に対する平均値を設定するなど実測に基づいて算出することで、性能状況を考慮したより精度の高い通信コストを算出することが期待できる。
次に、データ処理代理実行サーバ202における各部の処理について、図10〜図14のフローチャートを参照しつつ、適宜、図1〜図9を参照して説明する。
図10は、クエリ実行部210の動作のフローチャートである。
クエリ実行部210は、APサーバ200からのDBクエリを受付けて、そのDBクエリの解析を行う。本実施例1では、DBクエリの一例としてSQLを扱うため、SQL文の解析を行い、実行プランを生成する(ステップ1000)。DBクエリがSQLでない場合、クエリ実行部210は、エラーコードやエラーメッセージなどをAPサーバ200に応答する。
クエリ実行部210は、受け付けたDBクエリを解析した結果を基に、受け付けたDBクエリ(SQL)が参照系クエリであるSELECT文か否かを判定する(ステップ1001)。受け付けたDBクエリが参照系クエリの場合、クエリ実行部210は、ステップ1002を実行し、サーバ負荷判定部220を起動する。ステップ1002の詳細は、図11を参照して後に説明する。
クエリ実行部210は、ステップ1002におけるサーバ負荷判定部220の処理結果から、APサーバ計算機110が過負荷で、なおかつDBサーバ計算機120が低負荷か否かを判定する(ステップ1003)。ステップ1003において、APサーバ計算機110が過負荷ではない、及び/又は、DBサーバ計算機120が低負荷でないと判定した場合には、クエリ実行部210は、受け付けたDBクエリを代理実行する(ステップ1004)。APサーバ計算機110が過負荷で、なおかつDBサーバ計算機120が低負荷であると判定した場合、クエリ実行部210は、ステップ1005を実行する(クエリ実行サーバ判定部230を起動する)。ステップ1005の詳細は、図12を参照して後に説明する。
クエリ実行部210は、ステップ1005におけるクエリ実行サーバ判定部230の処理結果から、受け付けたDBクエリ(対象DBクエリ)を代理実行するか否かを判定する(ステップ1006)。ステップ1006において、対象DBクエリを代理実行すると判定した場合には、ステップ1004が行われ、そうでない場合は、DBサーバ203に対象DBクエリを転送すると判定されているため、ステップ100が行われる(クエリ転送部240が起動される)。ステップ1008の詳細は、図13を参照して後に説明する。
クエリ実行部210は、ステップ1001において、受け付けたDBクエリが参照系クエリでないと判定した場合、つまりSQLが更新系クエリであるINSERT文、UPDATE文、DELETE文のいずれかの場合、受け付けたDBクエリを実行し、ユーザデータの更新をキャッシュデータ272に反映する(ステップ1007)。続いて、クエリ実行部210は、ステップ1008を実行する(クエリ転送部240を起動する)。結果として、データ処理代理実行サーバ202が管理するキャッシュデータ272、及びDBサーバ203が管理する原本データ290の両方に、そのDBクエリの更新が反映される。これにより、データ処理代理実行サーバ202あるいはDBサーバ203のいずれのサーバに参照を要求しても、最新のユーザデータ(更新内容)を参照することができる。また、2台以上のAPサーバ計算機110が存在する場合には、DBサーバ203が管理する原本データ290に対する更新を、すべてのAPサーバ計算機110が管理するキャッシュデータ272に反映するために、更新ログを活用した非同期反映といった制御を行うことで、原本データ290とキャッシュデータ272のデータ整合性を担保することができる。
クエリ実行部210は、受け付けたDBクエリの実行結果に基づいて、クエリ実行結果テーブル270を更新する(ステップ1009)。クエリ実行結果テーブル270のクエリ310に、該DBクエリと同じDBクエリが存在する場合には、該DBクエリの実行結果サイズ330として、該DBクエリと同じDBクエリの実行結果サイズ330と、該DBクエリの実行結果サイズとの平均値を、テーブル270に書き込む。これにより、ユーザデータの変化に伴い生じる実行結果サイズの変化を考慮したより精度の高いクエリ通信コストを算出することができる。該DBクエリと同じDBクエリが存在しない場合には、クエリ実行部210は、該DBクエリに対するクエリ310、実行プラン320、及び実行結果サイズ330を追加する。
クエリ実行部210は、該DBクエリの実行結果をAPサーバ200に応答して処理を終了する(ステップ1010)。
図11は、サーバ負荷判定部220の動作のフローチャートである。
サーバ負荷判定部220は、クエリ実行部210から起動され、サーバ負荷判定処理を開始する。サーバ負荷判定部220は、サーバ計算機統計情報280から、例えばCPU使用率820をAPサーバ計算機110の負荷情報として取得する(ステップ1100)。続いて、サーバ負荷判定部220は、サーバ負荷判定基準273に基づいて、APサーバ計算機110が負荷判定基準を満たすか否かを判定する(ステップ1101)。
サーバ負荷判定部220は、ステップ1101において、APサーバ計算機110が負荷判定基準を満たす場合には、APサーバ計算機110が過負荷であると判定し、サーバ計算機統計情報280から、例えばCPU使用率820をDBサーバ計算機120の負荷情報として取得する(ステップ1102)。続いて、サーバ負荷判定部220は、サーバ負荷判定基準273に基づいて、DBサーバ計算機120が負荷判定基準を満たすか否かを判定する(ステップ1103)。
サーバ負荷判定部220は、ステップ1103において、DBサーバ計算機120が負荷判定基準を満たす場合には、DBサーバ計算機120が低負荷であると判定し、APサーバが過負荷であり、なおかつDBサーバが低負荷であると判定して、処理を終了する(ステップ1104)。
サーバ負荷判定部220は、ステップ1101において、APサーバが過負荷基準を満たさない場合、あるいは、ステップ1103において、DBサーバが低負荷基準を満たさない場合、APサーバが過負荷ではない、及び/又は、DBサーバが低負荷でないと判定して、処理を終了する(ステップ1105)。
図12は、クエリ実行サーバ判定部230の動作のフローチャートである。
クエリ実行サーバ判定部230は、クエリ実行部210から起動され、クエリ実行サーバ判定処理を開始する。クエリ実行サーバ判定部230は、APサーバ計算機110でのクエリ実行コストを算出する(ステップ1200)。APサーバ計算機110でのクエリ実行コストは、前述の(式2)に示したように、(APサーバでのクエリ実行ステップ数)×(APサーバでの1実行ステップ数あたりの実行時間長)で表すことができる。「APサーバでのクエリ実行ステップ数」として、例えば、クエリオプティマイザのコストベースの見積り値を採用することができる。クエリオプティマイザは、対象DBクエリに対する最適な実行プランを生成するために、対象DBクエリの実行プランの候補を選出し、ディクショナリ表テーブル271などを用いてコストを見積り、最もコストが低い実行プランを決定する。「APサーバでのクエリ実行ステップ数」は、コストベースの見積りにおいて算出される、対象DBクエリの実行ステップ数とすることができる。「APサーバでの1実行ステップ数あたりの実行時間長」は、例えば、サーバ計算機統計情報テーブル280に記録されている、1実行ステップあたりの実行時間長830(APサーバ計算機に対応した、1実行ステップあたりの実行時間長830)とすることができる。
クエリ実行サーバ判定部230は、DBサーバ計算機120でのクエリ実行コストを算出する(ステップ1201)。DBサーバ計算機120でのクエリ実行コストは、前述の(式2)に示したように、(DBサーバでのクエリ実行ステップ数)×(DBサーバでの1実行ステップ数あたりの実行時間長)で表すことができる。「DBサーバでのクエリ実行ステップ数」は、例えば、APサーバ計算機110でのクエリ実行コストを算出する手順と同様に算出することができる。その際、クエリ実行サーバ判定部230は、DBサーバ203のディクショナリ表テーブル281を用いて実行プランを生成することで、DBサーバ計算機120での対象DBクエリの実行ステップ数を近似することができる。
クエリ実行サーバ判定部230は、APサーバ計算機110とDBサーバ計算機120間の通信コスト(クエリ通信コスト)を算出する(ステップ1202)。クエリ通信コストは、前述の(式2)に示したように、((クエリサイズ)+(クエリ結果サイズ))/(転送速度)で表すことができる。「クエリサイズ」は、転送する対象DBクエリのサイズの値である。この値は、対象DBクエリの文字列長に一致し、クエリ結果サイズに対して十分に小さく、無視することもできる。「クエリ結果サイズ」は、対象DBクエリの実行結果のサイズの値である。実際に対象DBクエリを実行するまで、実行結果のサイズを取得することはできないため、そのサイズの値を予測する。予測する方法の一例として、クエリ実行結果テーブル270における、対象DBクエリに対する実行結果サイズ330の値、で予測することができる。「転送速度」は、APサーバ計算機110とDBサーバ計算機120間でのテータ転送における通信速度である。「転送速度」は、例えば、ネットワーク負荷情報テーブル282における転送速度910の値である。
クエリ実行サーバ判定部230は、ステップ1200〜ステップ1202で算出した見積り値を、(式2)に代入して、不等式を満たすか否かを判定する(ステップ1203)。
クエリ実行サーバ判定部230は、ステップ1203において、(式2)の不等式を満たす場合には、DBサーバ計算機120に対象DBクエリを転送すると判定して、処理を終了する(ステップ1205)。そうでない場合には、クエリ実行サーバ判定部230は、APサーバ計算機110で対象クエリを代理実行すると判定して、処理を終了する(ステップ1206)。
図13は、クエリ転送部240の動作のフローチャートである。
クエリ転送部240は、クエリ実行部210から起動され、クエリ転送処理を開始する。クエリ転送部240は、ネットワーク負荷情報テーブル282における転送速度910及び平均応答時間920を更新するために、対象DBクエリのDBサーバ計算機120への通信コストの計測を開始する(ステップ1300)。本計測処理に対する、計算機リソースの消費を抑えるため、あらかじめ指定された時間間隔で定期的に計測することもできる。
クエリ転送部240は、対象DBクエリをDBサーバ203に転送する(ステップ1301)。その際に、対象DBクエリに限らず、対象DBクエリに代替してDBサーバ203で実行可能な形式で表現されたデータ(例えば実行プラン)を転送することもできる。
クエリ転送部240は、DBサーバ203から対象DBクエリの実行結果を取得する(ステップ1302)。
クエリ転送部240は、対象DBクエリに対する計測を行っていた場合、計測を終了して、その計測結果である転送速度910及び平均応答時間920を、ネットワーク負荷情報テーブル282に書き込む(ステップ1303)。
クエリ転送部240は、DBサーバ203から取得した、対象DBクエリの実行結果を、APサーバ200に返す(ステップ1304)。
図14は、サーバ情報収集部250の動作のフローチャートである。
サーバ情報収集部250は、クエリ実行部210から起動され、各種情報収集処理を開始する。サーバ情報収集部250は、APサーバ計算機110の統計情報を収集して、サーバ計算機統計情報テーブル280を更新する(APサーバ計算機110を表すサーバ識別情報810を含んだ行を更新する)(ステップ1400)。CPU使用率820を収集する具体例の1つに、オペレーティングシステム(OS)が提供するシステムコールを用いて収集する方法が考えられる。1実行ステップあたりの実行時間長830を収集する具体例の1つに、1実行ステップの処理を複数回計測し、それらの平均値を算出する方法が考えられる。平均クエリ実行時間長840を収集する具体例の1つに、DBクエリの処理を複数回計測し、それらの平均値を算出する方法が考えられる。
サーバ情報収集部250は、DBサーバ計算機120の統計情報を収集して、サーバ計算機統計情報280を更新する(DBサーバ計算機120を表すサーバ識別情報810を含んだ行を更新する)(ステップ1401)。CPU使用率820、1実行ステップあたりの実行時間長830、及び平均クエリ実行時間長840を、DBサーバ203が管理するDBサーバ計算機統計情報テーブル291から取得する。他の方法として、APサーバ計算機110と同じ要領で、DBサーバ計算機120で収集した値を転送することもできる。
サーバ情報収集部250は、DBサーバのディクショナリ表テーブル292を収集して、DBサーバのディクショナリ表テーブル281を更新する(ステップ1402)。ディクショナリ表は、ユーザテーブルと同様に管理されており、SQLで参照して収集することができる。
サーバ情報収集部250のステップ1400〜ステップ1402において、各種データの収集に伴い、APサーバ計算機110のCPUやメモリ容量といった計算機リソースの消費、APサーバ計算機110とDBサーバ計算機120間で通信などが発生する。そのため、DBクエリの実行処理とは非同期にデータの収集を行うなど、リソース消費を抑えながら、DBクエリの実行処理に影響を与えないための配慮をすることが望ましい。各種データの収集の非同期実行に加えて、リソースに余裕に応じて、収集頻度を調整できるなどの制御が効果的である。また、収集対象のCPU使用率820、1実行ステップあたりの実行時間長830、DBサーバのディクショナリ表テーブル292といったデータは、すべて同じタイミングで収集する必要はなく、各収集処理は独立して動作できる。
実施例1によれば、データ処理代理実行サーバ202による負荷分散により、APサーバ計算機110とDBサーバ計算機120との間で負荷バランスを調整し、両者の計算機リソースを有効に活用することで、安定的なシステムパフォーマンスを実現することができる。
以下、本発明の実施例2を説明する。その際、実施例1との相違点を主に説明し、実施例1との共通点については説明を省略或いは簡略する。
実施例1では、前述した第一乃至第三の方法のうち第一の方法が採用されているが、実施例2では、第二の方法が採用される。第二の方法は、「DBサーバでのクエリ実行コスト」の算出を簡易化した方法であり、前述した(式3)により定義される。これにより、「DBサーバでのクエリ実行コスト」の算出するための計算機リソースの消費を抑え、アプリケーションプログラムに対する性能インパクトを軽減できることが期待できる。
図15は、本発明の実施例2におけるAPサーバ計算機及びDBサーバ計算機の構成を示す。図15では、クエリ受付モジュール214の図示を省略している。
クエリ実行サーバ判定部230には、DBサーバ計算機実行コスト見積232に代わって、DBサーバ実行コスト簡易見積1500が備えられる。
DBサーバ実行コスト簡易見積1500は、「DBサーバでのクエリ実行コスト」を見積るためのモジュールであり、DBサーバのディクショナリ表281を利用しない。従って、実施例1のDBサーバのディクショナリ表281、及びそれに関連するモジュールは不要となる。
図16は、クエリ実行サーバ判定部230の動作のフローチャートである。
クエリ実行サーバ判定部230は、図12のステップ1201に代わって、DBサーバ計算機120でのクエリ実行コストを簡易的に見積る(ステップ1600)。DBサーバ計算機でのクエリ実行コストは、前述の(式3)に示したように(APサーバ計算機でのクエリ実行コスト)×(DBサーバ性能比率)で表すことができる。「APサーバ計算機でのクエリ実行コスト」は、ステップ1200において算出された値とすることができる。一方、(DBサーバ性能比率)は、(式4)から、(DBサーバ計算機での平均クエリ実行時間長)/(APサーバ計算機での平均クエリ実行時間長)で表すことができる。この値を算出する一例として、DBサーバ計算機120及びAPサーバ計算機110での平均クエリ実行時間長を、それぞれ図8の1実行ステップあたりの処理実行時間長830から取得し除算した値とすることができる。以降、ステップ1202以降の処理は、図12と同様である。
以下、本発明の実施例3を説明する。その際、実施例1(及び/又は実施例2)との相違点を主に説明し、実施例1(及び/又は実施例2)との共通点については説明を省略或いは簡略する。
実施例1及び実施例2では、APサーバ計算機110及びDBサーバ計算機120でDBクエリを実行した場合のコストを見積り、その見積り値に基づいて、クエリ実行サーバ判定が行われる。それに対し、実施例3では、DBクエリが特定のクエリ形式に合致した場合には、(式1)を満たすことになると仮定される。すなわち、実施例3では、第一乃至第三の方法のうち、最も簡易的なクエリ実行サーバ判定方法である第三の方法が採用される。これにより、実施例1及び実施例2におけるコストを見積るための処理を行わないため、アプリケーションプログラムに対する性能インパクトを軽減できることが期待できる。
本発明の実施例3におけるAPサーバ計算機及びDBサーバ計算機の構成を示す。
クエリ実行サーバ判定部230に、APサーバ計算機実行コスト見積モジュール231、DBサーバ計算機実行コスト見積232(又はDBサーバ実行コスト簡易見積1500)、ネットワーク処理コスト見積モジュール233及びクエリ実行サーバ判定モジュール234に代えて、クエリ実行サーバ転送判定モジュール1700が備えられる。クエリ実行サーバ転送判定モジュール1700は、クエリ転送定義テーブル1701(図18参照)を用いて、DBクエリを転送するか否かを判定する。
図18は、クエリ転送定義テーブル1701の一例を示す。
クエリ転送定義テーブル1701は、DBクエリの転送に関する定義情報を保持するテーブルである。テーブル1701の各行は、転送するか否かを指定するDBクエリのクエリパターン1810、及び実行サーバ1820からなる。クエリパターン1810は、対象となるDBクエリのパターンを示す文字列である。パターンを指定する具体例の1つとして、DBクエリをそのまま文字列で指定する、正規表現を用いてDBクエリのパターンを指定する、などが挙げられる。実行サーバ1820は、DBクエリのパターンに合致したDBクエリを実行するサーバの識別情報であり、ホスト名、あるいはIPアドレスとなる。これらの定義情報は、コマンドライン、定義ファイルといったインタフェースにより、外部から必要に応じて設定できる。
図19は、クエリ実行サーバ判定部230の動作のフローチャートである。
クエリ実行サーバ判定部230は、クエリ転送定義テーブル1701に基づいて、受付けた対象DBクエリがクエリパターン1810を満たすか否かを判定する(ステップ1900)。ステップ1900において、該DBクエリがクエリパターン1810を満たすと判定した場合には、実行サーバ1820に基づいて、対象DBクエリをいずれのサーバで実行するかを判定する(ステップ1902)。そうでない場合は、ステップ1206に進み、以降の処理は、図12と同様である。
対象DBクエリが特定のクエリ形式であるが故に、ステップ1902において、対象DBクエリをDBサーバ計算機120で実行すると判定した場合には、ステップ1205に進み、以降の処理は、図12と同様である。そうでない場合(例えば、対象DBクエリが別の特定のクエリ形式であるが故に、ステップ1902において、対象DBクエリをAPサーバ計算機110で代理実行すると判定した場合)には、ステップ1206に進み、以降の処理は、図12と同様である。
上述した本発明の幾つかの実施例は、本発明の説明のための例示であり、本発明の範囲をその実施例にのみ限定する趣旨ではない。本発明は、その要旨を逸脱することなく、その他の様々な態様でも実施することができる。
例えば、一つのデータ処理代理実行サーバ202に、DBサーバ計算機実行コスト見積モジュール232、DBサーバ実行コスト簡易見積モジュール1500、クエリ実行サーバ転送判定モジュール1700が設けられていて、前述した第一乃至第三の方法のうちのいずれの方法を採用するかによって、起動されるモジュールが決められても良い。例えば、精度を優先するモードが自動で或いは手動で選択された場合には、モジュール232、1500及び1700のうち、DBサーバ計算機実行コスト見積モジュール232が起動し、バランスを優先するモードが自動で或いは手動で選択された場合には、モジュール232、1500及び1700のうち、DBサーバ実行コスト簡易見積モジュール1500が起動し、性能を優先するモードが自動或いは手動で選択された場合には、モジュール232、1500及び1700のうち、クエリ実行サーバ転送判定モジュール1700が起動しても良い。
また、クエリ実行部210、クエリ解析モジュール211、クエリ制御モジュール212、クエリ実行モジュール213、クエリ受付モジュール214、サーバ負荷判定部220、サーバ負荷状況判定モジュール211、クエリ実行サーバ判定部230、APサーバ計算機実行コスト見積モジュール231、DBサーバ計算機実行コスト見積モジュール232、ネットワーク処理コスト見積モジュール233、クエリ実行サーバ判定モジュール234、クエリ転送部240、クエリ転送モジュール241、ネットワーク負荷収集モジュール242、サーバ情報収集部250、APサーバ計算機統計情報収集モジュール251、DBサーバ計算機統計情報収集モジュール252、DBサーバディクショナリ表収集モジュール253、クエリ実行部260、DBサーバ実行コスト簡易見積モジュール1500及びクエリ実行サーバ転送判定モジュール1700のうちの少なくとも一つは、コンピュータプログラムに代えて又は加えて、各処理を行う処理部として集積回路化するなどしてハードウェアで実現することもできる。各処理部をハードウェアで実現した場合にはその各処理部が主体となって各処理を行うことができる。
本発明の実施例1に係る計算機システムの構成を示すブロック図である。 本発明の実施例1におけるAPサーバ計算機及びDBサーバ計算機の構成を示す。 本発明の実施例1におけるクエリ実行結果テーブルの一例を示す。 本発明の実施例1におけるディクショナリ表テーブルの一例を示す。 本発明の実施例1におけるユーザデータを保持するテーブルt1の一例を示す。 本発明の実施例1におけるユーザデータを保持するテーブルt2の一例を示す。 本発明の実施例1におけるサーバ負荷判定基準テーブルの一例を示す。 本発明の実施例1におけるサーバ計算機統計情報テーブルの一例を示す。 本発明の実施例1におけるネットワーク負荷情報テーブルの一例を示す。 本発明の実施例1におけるクエリ実行部の動作のフローチャートである。 本発明の実施例1におけるサーバ負荷判定部の動作のフローチャートである。 本発明の実施例1におけるクエリ実行サーバ判定部の動作のフローチャートである。 本発明の実施例1におけるクエリ転送部の動作のフローチャートである。 本発明の実施例1におけるサーバ情報収集部の動作のフローチャートである。 本発明の実施例2におけるAPサーバ計算機及びDBサーバ計算機の構成を示す。 本発明の実施例2におけるクエリ実行サーバ判定部の動作のフローチャートである。 本発明の実施例3におけるAPサーバ計算機及びDBサーバ計算機の構成を示す。 本発明の実施例3におけるクエリ転送定義テーブルの一例を示す。 本発明の実施例3におけるクエリ実行サーバ判定部の動作のフローチャートである。
符号の説明
100…クライアント計算機 110…APサーバ計算機 111…CPU 112…主記憶装置 113…通信インタフェース 114…通信ネットワーク 120…DBサーバ計算機 121…CPU 122…主記憶装置 123…通信インタフェース 124…ディスクインタフェース 125…記憶装置 200…APサーバ 201…アプリケーションプログラム 202…データ処理代理実行サーバ 203…DBサーバ 210…クエリ実行部 211…クエリ解析モジュール 212…クエリ制御モジュール 213…クエリ実行モジュール 214…クエリ受付モジュール 220…サーバ負荷判定部 221…サーバ負荷状況判定モジュール 230…クエリ実行サーバ判定部 231…APサーバ計算機実行コスト見積モジュール 232…DBサーバ計算機実行コスト見積モジュール 233…ネットワーク処理コスト見積モジュール 234…クエリ実行サーバ判定モジュール 240…クエリ転送部 241…クエリ転送モジュール 242…ネットワーク負荷収集モジュール 250…サーバ情報収集部 251…APサーバ計算機統計情報収集モジュール 252…DBサーバ計算機統計情報収集モジュール 253…DBサーバディクショナリ表収集モジュール 260…クエリ実行部 270…クエリ実行結果テーブル 271…ディクショナリ表テーブル 272…キャッシュデータテーブル 273…サーバ負荷判定基準テーブル 280…サーバ計算機統計情報テーブル 281…DBサーバのディクショナリ表テーブル 282…ネットワーク負荷情報テーブル 290…原本データ 291…DBサーバ計算機統計情報テーブル 292…DBサーバのディクショナリ表テーブル 1500…DBサーバ実行コスト簡易見積モジュール 1700…クエリ実行サーバ転送判定モジュール 1701…クエリ転送定義テーブル

Claims (12)

  1. クライアントからのリクエストに応じた処理を行うアプリケーションプログラムを実行するアプリケーションサーバ(APサーバ)が動作するAPサーバ計算機と、データベースクエリを実行するデータベースサーバ(DBサーバ)が動作するDBサーバ計算機とを含んだ計算機システムにおいて前記APサーバ計算機の中に配置される負荷分散制御サーバであって、
    前記APサーバからデータベースクエリを受け付けるクエリ受付部と、
    前記データベースクエリを前記DBサーバに代わって実行するクエリ代理実行部と、
    前記データベースクエリを前記DBサーバ計算機に転送するクエリ転送部と、
    前記APサーバ計算機及び前記DBサーバ計算機の計算機負荷を管理し、前記管理された計算機負荷が所定の条件を満たすか否かを判定するサーバ負荷判定部と、
    前記サーバ負荷判定部が、所定の条件を満たすと判定したとき、前記クエリ代理実行部で実行する場合のクエリを実行するための時間を示す第一のクエリ実行時間長を、
    前記APサーバ計算機での前記データベースクエリのクエリ実行ステップ数と、
    前記APサーバ計算機でのクエリ1実行ステップ数あたりの実行時間長と
    によって算出し
    前記データベースクエリを前記DBサーバで実行する場合のクエリを実行するための時間を示す第二のクエリ実行時間長を、
    前記DBサーバ計算機での前記データベースクエリのクエリ実行ステップ数と、
    前記DBサーバ計算機でのクエリ1実行ステップ数あたりの実行時間長と、
    前記データベースクエリを前記DBサーバで転送することによって行われる前記APサーバ計算機と前記DBサーバ計算機との間の通信に要する通信時間長に基づく値と
    によって算出し、
    前記第一のクエリ実行時間長と前記第二のクエリ実行時間長とを基に、前記受け付けたデータベースクエリを前記クエリ代理実行部で実行するか前記DBサーバ計算機に転送し前記DBサーバで実行するかを判定するクエリ実行サーバ判定部と
    を備え、
    前記クエリ実行サーバ判定部が、前記データベースクエリを前記クエリ代理実行部で実行すると判定したならば、前記クエリ代理実行部が、前記データベースクエリを実行し、
    前記クエリ実行サーバ判定部が、前記データベースクエリを前記DBサーバ計算機に転送し前記DBサーバで実行すると判定したならば、前記クエリ転送部が、前記データベースクエリを前記DBサーバ計算機に転送する、
    負荷分散制御サーバ。
  2. クライアントからのリクエストに応じた処理を行うアプリケーションプログラムを実行するアプリケーションサーバ(APサーバ)が動作するAPサーバ計算機と、データベースクエリを実行するデータベースサーバ(DBサーバ)が動作するDBサーバ計算機とを含んだ計算機システムにおいて前記APサーバ計算機の中に配置される負荷分散制御サーバであって、
    前記APサーバからデータベースクエリを受け付けるクエリ受付部と、
    前記データベースクエリを前記DBサーバに代わって実行するクエリ代理実行部と、
    前記データベースクエリを前記DBサーバ計算機に転送するクエリ転送部と、
    前記APサーバ計算機及び前記DBサーバ計算機の計算機負荷を管理し、前記管理された計算機負荷が所定の条件を満たすか否かを判定するサーバ負荷判定部と、
    前記サーバ負荷判定部が、所定の条件を満たすと判定したとき、前記クエリ代理実行部で実行する場合のクエリを実行するための時間を示す第一のクエリ実行時間長を、
    前記APサーバ計算機での前記データベースクエリのクエリ実行ステップ数と、
    前記APサーバ計算機でのクエリ1実行ステップ数あたりの実行時間長と
    によって算出し、
    前記データベースクエリを前記DBサーバで実行する場合のクエリを実行するための時間を示す第二のクエリ実行時間長を、
    前記クエリ代理実行部で前記データベースクエリを前記DBに代わって実行することに要するコストであるAPサーバ計算機でのクエリ実行コストと、
    前記DBサーバ計算機の前記APサーバ計算機に対する処理性能比率と、
    前記データベースクエリを前記DBサーバで転送することによって行われる前記APサーバ計算機と前記DBサーバ計算機との間の通信に要する通信時間長に基づく値と
    によって算出し、
    前記第一のクエリ実行時間長と前記第二のクエリ実行時間長とを基に、前記受け付けたデータベースクエリを前記クエリ代理実行部で実行するか前記DBサーバ計算機に転送し前記DBサーバで実行するかを判定するクエリ実行サーバ判定部と
    を備え、
    前記クエリ実行サーバ判定部が、前記データベースクエリを前記クエリ代理実行部で実行すると判定したならば、前記クエリ代理実行部が、前記データベースクエリを実行し、
    前記クエリ実行サーバ判定部が、前記データベースクエリを前記DBサーバ計算機に転送し前記DBサーバで実行すると判定したならば、前記クエリ転送部が、前記データベースクエリを前記DBサーバ計算機に転送する、
    負荷分散制御サーバ。
  3. 前記所定の条件が、
    前記AP計算機サーバが第一の基準値よりも高い過負荷であり且つ前記DB計算機サーバが第二の基準値よりも低い低負荷である、
    請求項1又は2記載の負荷分散制御サーバ。
  4. 前記所定の条件を満たさないと判定した場合には、前記受け付けたデータベースクエリを前記クエリ代理実行部で実行するか前記DBサーバ計算機に転送し前記DBサーバで実行するかを判定することなく、前記受け付けたデータベースクエリを前記クエリ代理実行部で実行すると決定する、
    請求項記載の負荷分散制御サーバ。
  5. 前記通信時間長が、前記APサーバ計算機から前記DBサーバ計算機に転送される前記データベースクエリのサイズと、前記DBサーバ計算機から前記APサーバ計算機に応答されるクエリ結果のサイズと、前記APサーバ計算機と前記DBサーバ計算機との間の通信の速度とに基づいて算出される、
    請求項1乃至4のうちのいずれか1項に記載の負荷分散制御サーバ。
  6. 前記クエリ実行サーバ判定部は、前記第一のクエリ実行時間長が、前記第二のクエリ実行時間長よりも大きい場合に、前記受け付けたデータベースクエリを前記DBサーバ計算機に転送し前記DBサーバで実行すると判定する、
    請求項記載の負荷分散制御サーバ。
  7. 前記クエリ転送部が、前記データベースクエリを前記DBサーバ計算機に転送する場合、前記受け付けたデータベースクエリに代替して前記DBサーバで実行可能な形式で表現されたデータを転送する、
    請求項1乃至6のうちのいずれか1項に記載の負荷分散制御サーバ。
  8. 前記クエリ代理実行部が、前記データベースクエリとして、データベースアクセス言語、あるいはSQLプロシージャの一部に対して処理する、
    請求項1乃至7のうちのいずれか1項に記載の負荷分散制御サーバ。
  9. クライアントからのリクエストに応じた処理を行うアプリケーションプログラムを実行するアプリケーションサーバ(APサーバ)が動作するAPサーバ計算機と、データベースクエリを実行するデータベースサーバ(DBサーバ)が動作するDBサーバ計算機とを含んだ計算機システムにおいて前記APサーバ計算機の中に配置される負荷分散制御サーバによる負荷分散制御方法であって、
    前記負荷分散制御サーバ内のクエリ受付部が、前記APサーバからデータベースクエリを受け付け、
    前記負荷分散制御サーバ内のクエリ代理実行部が、前記データベースクエリを前記DBサーバに代わって実行し、
    前記負荷分散制御サーバ内のサーバ負荷判定部が、前記APサーバ計算機及び前記DBサーバ計算機の計算機負荷を管理し、前記管理された計算機負荷が所定の条件を満たすか否かを判定し、
    前記所定の条件を満たすと判定したとき、
    前記負荷分散制御サーバ内のクエリ実行サーバ判定部が、前記クエリ代理実行部で実行する場合のクエリを実行するための時間を示す第一のクエリ実行時間長を、
    前記APサーバ計算機での前記データベースクエリのクエリ実行ステップ数と、
    前記APサーバ計算機でのクエリ1実行ステップ数あたりの実行時間長と
    によって算出し、
    前記データベースクエリを前記DBサーバで実行する場合のクエリを実行するための時間を示す第二のクエリ実行時間長を、
    前記DBサーバ計算機での前記データベースクエリのクエリ実行ステップ数と、
    前記DBサーバ計算機でのクエリ1実行ステップ数あたりの実行時間長と、
    前記データベースクエリを前記DBサーバで転送することによって行われる前記APサーバ計算機と前記DBサーバ計算機との間の通信に要する通信時間長に基づく値と
    によって算出し、
    前記第一のクエリ実行時間長と前記第二のクエリ実行時間長とを基に、前記受け付けたデータベースクエリを前記クエリ代理実行部で実行するか前記DBサーバ計算機に転送し前記DBサーバで実行するかを判定し、
    前記クエリ実行サーバ判定部が、前記データベースクエリを前記クエリ代理実行部で実行すると判定したならば、前記クエリ代理実行部が、前記データベースクエリを実行し、
    前記クエリ実行サーバ判定部が、前記データベースクエリを前記DBサーバ計算機に転送し前記DBサーバで実行すると判定したならば、前記クエリ転送部が、前記データベースクエリを前記DBサーバ計算機に転送する、
    負荷分散制御方法。
  10. クライアントからのリクエストに応じた処理を行うアプリケーションプログラムを実行するアプリケーションサーバ(APサーバ)が動作するAPサーバ計算機と、データベースクエリを実行するデータベースサーバ(DBサーバ)が動作するDBサーバ計算機とを含んだ計算機システムにおいて前記APサーバ計算機の中に配置される負荷分散制御サーバによる負荷分散制御方法であって、
    前記負荷分散制御サーバ内のクエリ受付部が、前記APサーバからデータベースクエリを受け付け、
    前記負荷分散制御サーバ内のクエリ代理実行部が、前記データベースクエリを前記DBサーバに代わって実行し、
    前記負荷分散制御サーバ内のサーバ負荷判定部が、前記APサーバ計算機及び前記DBサーバ計算機の計算機負荷を管理し、前記管理された計算機負荷が所定の条件を満たすか否かを判定し、
    前記所定の条件を満たすと判定したとき、
    前記負荷分散制御サーバ内のクエリ実行サーバ判定部が、前記クエリ代理実行部で実行する場合のクエリを実行するための時間を示す第一のクエリ実行時間長を、
    前記APサーバ計算機での前記データベースクエリのクエリ実行ステップ数と、
    前記APサーバ計算機でのクエリ1実行ステップ数あたりの実行時間長と
    によって算出し、
    前記データベースクエリを前記DBサーバで実行する場合のクエリを実行するための時間を示す第二のクエリ実行時間長を、
    前記クエリ代理実行部で前記データベースクエリを前記DBに代わって実行することに要するコストであるAPサーバ計算機でのクエリ実行コストと、
    前記DBサーバ計算機の前記APサーバ計算機に対する処理性能比率と、
    前記データベースクエリを前記DBサーバで転送することによって行われる前記APサーバ計算機と前記DBサーバ計算機との間の通信に要する通信時間長に基づく値と
    によって算出し、
    前記第一のクエリ実行時間長と前記第二のクエリ実行時間長とを基に、前記受け付けたデータベースクエリを前記クエリ代理実行部で実行するか前記DBサーバ計算機に転送し前記DBサーバで実行するかを判定し、
    前記クエリ実行サーバ判定部が、前記データベースクエリを前記クエリ代理実行部で実行すると判定したならば、前記クエリ代理実行部が、前記データベースクエリを実行し、
    前記クエリ実行サーバ判定部が、前記データベースクエリを前記DBサーバ計算機に転送し前記DBサーバで実行すると判定したならば、前記クエリ転送部が、前記データベースクエリを前記DBサーバ計算機に転送する、
    負荷分散制御方法。
  11. クライアントからのリクエストに応じた処理を行うアプリケーションプログラムを実行するアプリケーションサーバ(APサーバ)が動作するAPサーバ計算機と、データベースクエリを実行するデータベースサーバ(DBサーバ)が動作するDBサーバ計算機とを含んだ計算機システムにおいて前記APサーバ計算機の中に配置される負荷分散制御サーバで実行されるコンピュータプログラムであって、
    前記負荷分散制御サーバ内のクエリ受付部が、前記APサーバからデータベースクエリを受け付け、
    前記負荷分散制御サーバ内のクエリ代理実行部が、前記データベースクエリを前記DBサーバに代わって実行し、
    前記負荷分散制御サーバ内のサーバ負荷判定部が、前記APサーバ計算機及び前記DBサーバ計算機の計算機負荷を管理し、前記管理された計算機負荷が所定の条件を満たすか否かを判定し、
    前記所定の条件を満たすと判定したとき、
    前記負荷分散制御サーバ内のクエリ実行サーバ判定部が、前記クエリ代理実行部で実行する場合のクエリを実行するための時間を示す第一のクエリ実行時間長
    前記APサーバ計算機での前記データベースクエリのクエリ実行ステップ数と、
    前記APサーバ計算機でのクエリ1実行ステップ数あたりの実行時間長と
    によって算出し
    前記データベースクエリを前記DBサーバで実行する場合のクエリを実行するための時間を示す第二のクエリ実行時間長
    前記DBサーバ計算機での前記データベースクエリのクエリ実行ステップ数と、
    前記DBサーバ計算機でのクエリ1実行ステップ数あたりの実行時間長と、
    前記データベースクエリを前記DBサーバで転送することによって行われる前記APサーバ計算機と前記DBサーバ計算機との間の通信に要する通信時間長に基づく値と
    によって算出し、
    前記第一のクエリ実行時間長と前記第二のクエリ実行時間長とを基に、前記受け付けたデータベースクエリを前記クエリ代理実行部で実行するか前記DBサーバ計算機に転送し前記DBサーバで実行するかを判定し、
    前記クエリ実行サーバ判定部が、前記データベースクエリを前記クエリ代理実行部で実行すると判定したならば、前記クエリ代理実行部が、前記データベースクエリを実行し、
    前記クエリ実行サーバ判定部が、前記データベースクエリを前記DBサーバ計算機に転送し前記DBサーバで実行すると判定したならば、前記クエリ転送部が、前記データベースクエリを前記DBサーバ計算機に転送する、
    コンピュータプログラム。
  12. クライアントからのリクエストに応じた処理を行うアプリケーションプログラムを実行するアプリケーションサーバ(APサーバ)が動作するAPサーバ計算機と、データベースクエリを実行するデータベースサーバ(DBサーバ)が動作するDBサーバ計算機とを含んだ計算機システムにおいて前記APサーバ計算機の中に配置される負荷分散制御サーバで実行されるコンピュータプログラムであって、
    前記負荷分散制御サーバ内のクエリ受付部が、前記APサーバからデータベースクエリを受け付け、
    前記負荷分散制御サーバ内のクエリ代理実行部が、前記データベースクエリを前記DBサーバに代わって実行し、
    前記負荷分散制御サーバ内のサーバ負荷判定部が、前記APサーバ計算機及び前記DBサーバ計算機の計算機負荷を管理し、前記管理された計算機負荷が所定の条件を満たすか否かを判定し、
    前記所定の条件を満たすと判定したとき、
    前記負荷分散制御サーバ内のクエリ実行サーバ判定部が、前記クエリ代理実行部で実行する場合のクエリを実行するための時間を示す第一のクエリ実行時間長を、
    前記APサーバ計算機での前記データベースクエリのクエリ実行ステップ数と、
    前記APサーバ計算機でのクエリ1実行ステップ数あたりの実行時間長と
    によって算出し、
    前記データベースクエリを前記DBサーバで実行する場合のクエリを実行するための時間を示す第二のクエリ実行時間長を、
    前記クエリ代理実行部で前記データベースクエリを前記DBに代わって実行することに要するコストであるAPサーバ計算機でのクエリ実行コストと、
    前記DBサーバ計算機の前記APサーバ計算機に対する処理性能比率と、
    前記データベースクエリを前記DBサーバで転送することによって行われる前記APサーバ計算機と前記DBサーバ計算機との間の通信に要する通信時間長に基づく値と
    によって算出し、
    前記第一のクエリ実行時間長と前記第二のクエリ実行時間長とを基に、前記受け付けたデータベースクエリを前記クエリ代理実行部で実行するか前記DBサーバ計算機に転送し前記DBサーバで実行するかを判定し、
    前記クエリ実行サーバ判定部が、前記データベースクエリを前記クエリ代理実行部で実行すると判定したならば、前記クエリ代理実行部が、前記データベースクエリを実行し、
    前記クエリ実行サーバ判定部が、前記データベースクエリを前記DBサーバ計算機に転送し前記DBサーバで実行すると判定したならば、前記クエリ転送部が、前記データベースクエリを前記DBサーバ計算機に転送する、
    コンピュータプログラム。
JP2008057058A 2008-03-06 2008-03-06 負荷分散制御サーバ、負荷分散制御方法及びコンピュータプログラム Expired - Fee Related JP4815459B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008057058A JP4815459B2 (ja) 2008-03-06 2008-03-06 負荷分散制御サーバ、負荷分散制御方法及びコンピュータプログラム
US12/218,360 US20090228446A1 (en) 2008-03-06 2008-07-11 Method for controlling load balancing in heterogeneous computer system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008057058A JP4815459B2 (ja) 2008-03-06 2008-03-06 負荷分散制御サーバ、負荷分散制御方法及びコンピュータプログラム

Publications (2)

Publication Number Publication Date
JP2009217300A JP2009217300A (ja) 2009-09-24
JP4815459B2 true JP4815459B2 (ja) 2011-11-16

Family

ID=41054664

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008057058A Expired - Fee Related JP4815459B2 (ja) 2008-03-06 2008-03-06 負荷分散制御サーバ、負荷分散制御方法及びコンピュータプログラム

Country Status (2)

Country Link
US (1) US20090228446A1 (ja)
JP (1) JP4815459B2 (ja)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7840537B2 (en) 2006-12-22 2010-11-23 Commvault Systems, Inc. System and method for storing redundant information
US8578120B2 (en) 2009-05-22 2013-11-05 Commvault Systems, Inc. Block-level single instancing
US8176037B2 (en) * 2009-11-16 2012-05-08 Dell Products L.P. System and method for SQL query load balancing
US9183255B1 (en) * 2009-12-30 2015-11-10 Teradata Us, Inc. Spool management and checkpointing in a multi-database system
JP5534885B2 (ja) * 2010-03-23 2014-07-02 株式会社東芝 分散データ処理最適化装置および分散データ処理最適化方法
US9032017B1 (en) * 2010-08-10 2015-05-12 Scalarc Inc Method and system for transparent read-write query routing when load balancing databases
US8543554B1 (en) 2010-08-10 2013-09-24 ScalArc Inc. Method and system for transparent database query caching
US8484242B1 (en) 2010-08-24 2013-07-09 ScalArc, Inc. Method and system for transparent database connection pooling and query queuing
US20120317249A1 (en) * 2011-06-13 2012-12-13 Salsburg Michael A Methods and systems for extreme capacity management
US8763091B1 (en) 2010-08-24 2014-06-24 ScalArc Inc. Method and system for user authentication offload in a transparent database load balancer
US8935492B2 (en) 2010-09-30 2015-01-13 Commvault Systems, Inc. Archiving data objects using secondary copies
US9020890B2 (en) 2012-03-30 2015-04-28 Commvault Systems, Inc. Smart archiving and data previewing for mobile devices
US9633022B2 (en) 2012-12-28 2017-04-25 Commvault Systems, Inc. Backup and restoration for a deduplicated file system
JP5768119B2 (ja) * 2013-12-19 2015-08-26 エヌ・ティ・ティ・コムウェア株式会社 負荷分散装置、負荷分散方法及び負荷分散プログラム
US10324897B2 (en) 2014-01-27 2019-06-18 Commvault Systems, Inc. Techniques for serving archived electronic mail
US20160335321A1 (en) * 2014-03-28 2016-11-17 Hitachi, Ltd. Database management system, computer, and database management method
JP6337741B2 (ja) * 2014-10-31 2018-06-06 富士通株式会社 制御プログラム、制御装置、制御方法及びデータベースシステム
US10324914B2 (en) * 2015-05-20 2019-06-18 Commvalut Systems, Inc. Handling user queries against production and archive storage systems, such as for enterprise customers having large and/or numerous files
US10489413B2 (en) 2015-08-03 2019-11-26 Amadeus S.A.S. Handling data requests
EP3392788A1 (en) * 2015-08-03 2018-10-24 Amadeus S.A.S. Handling data requests
US9979656B2 (en) 2015-12-07 2018-05-22 Oracle International Corporation Methods, systems, and computer readable media for implementing load balancer traffic policies
US10838980B2 (en) * 2018-07-23 2020-11-17 Sap Se Asynchronous collector objects
CN109117275A (zh) * 2018-08-31 2019-01-01 平安科技(深圳)有限公司 基于数据分片的对账方法、装置、计算机设备及存储介质
US10798609B2 (en) 2018-10-16 2020-10-06 Oracle International Corporation Methods, systems, and computer readable media for lock-free communications processing at a network node
US11500755B1 (en) * 2019-05-01 2022-11-15 Amazon Technologies, Inc. Database performance degradation detection and prevention
CN110519250B (zh) * 2019-08-20 2022-04-15 南京尚网网络科技有限公司 一种提供信息流的方法与设备
US11593367B1 (en) * 2021-09-29 2023-02-28 Amazon Technologies, Inc. Selecting between hydration-based scanning and stateless scale-out scanning to improve query performance

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2281793A (en) * 1993-09-11 1995-03-15 Ibm A data processing system for providing user load levelling in a network
JPH07152699A (ja) * 1993-11-29 1995-06-16 Canon Inc 情報処理方法及び装置及びシステム
JPH10240591A (ja) * 1997-02-28 1998-09-11 Hitachi Ltd Sqlプロシジャ実行時の計算機負荷分散方法
JP2002099521A (ja) * 2000-09-21 2002-04-05 Hitachi Information Systems Ltd ネットワークコンピューティングシステムとプログラム実行処理方法および負荷分散処理プログラム
US6763347B1 (en) * 2001-10-19 2004-07-13 Nick Zhang Indexing management for hierarchical main memory
JP2003208414A (ja) * 2002-01-11 2003-07-25 Hitachi Ltd 負荷分散機能付きサーバおよびクライアント
JP4579501B2 (ja) * 2003-03-27 2010-11-10 富士通株式会社 アプリケーションサーバおよびアプリケーションプログラム
JP2006113827A (ja) * 2004-10-15 2006-04-27 Hitachi Ltd Cpu余裕管理とトランザクション優先度による負荷分散方法
JP2006285601A (ja) * 2005-03-31 2006-10-19 Fujitsu Ltd ファイル配信方法とそれを実現するクライアント端末
JP2006338264A (ja) * 2005-06-01 2006-12-14 Toyota Infotechnology Center Co Ltd タスク割当装置およびタスク割当方法
US7623463B2 (en) * 2005-09-09 2009-11-24 International Business Machines Corporation Performance evaluation of a network-based application
US20070162425A1 (en) * 2006-01-06 2007-07-12 International Business Machines Corporation System and method for performing advanced cost/benefit analysis of asynchronous operations
US20080209009A1 (en) * 2007-01-18 2008-08-28 Niraj Katwala Methods and systems for synchronizing cached search results
US8155880B2 (en) * 2008-05-09 2012-04-10 Locomatix Inc. Location tracking optimizations

Also Published As

Publication number Publication date
JP2009217300A (ja) 2009-09-24
US20090228446A1 (en) 2009-09-10

Similar Documents

Publication Publication Date Title
JP4815459B2 (ja) 負荷分散制御サーバ、負荷分散制御方法及びコンピュータプログラム
US7987200B2 (en) Method and apparatus for predicting selectivity of database query join conditions using hypothetical query predicates having skewed value constants
US8504556B1 (en) System and method for diminishing workload imbalance across multiple database systems
US9189523B2 (en) Predicting performance of multiple queries executing in a database
US10826980B2 (en) Command process load balancing system
US20070016558A1 (en) Method and apparatus for dynamically associating different query execution strategies with selective portions of a database table
US20100082599A1 (en) Characterizing Queries To Predict Execution In A Database
US20100082507A1 (en) Predicting Performance Of Executing A Query In Isolation In A Database
US20090077235A1 (en) Mechanism for profiling and estimating the runtime needed to execute a job
US8171228B2 (en) Garbage collection in a cache with reduced complexity
US20080065588A1 (en) Selectively Logging Query Data Based On Cost
WO2007068667A1 (en) Method and apparatus for analyzing the effect of different execution parameters on the performance of a database query
Duggan et al. Contender: A Resource Modeling Approach for Concurrent Query Performance Prediction.
JP5385912B2 (ja) 算出装置、システム管理装置、算出方法およびプログラム
US11176092B2 (en) Database management system and anonymization processing method
US20220067046A1 (en) Systems and methods for artificial intelligence-based data system optimization
US20160179891A1 (en) Methods and systems for load balancing databases in a cloud environment
JP7192645B2 (ja) 情報処理装置、分散処理システム及び分散処理プログラム
CN109154933A (zh) 分布式数据库系统以及分布和访问数据的方法
US7281106B1 (en) Method and apparatus for selective volume swapping in a data storage device based on merging multiple sets of candidate storage devices
Paton et al. Autonomic query parallelization using non-dedicated computers: an evaluation of adaptivity options
US20110093688A1 (en) Configuration management apparatus, configuration management program, and configuration management method
US20220229697A1 (en) Management computer, management system, and recording medium
JP2018136681A (ja) 性能管理プログラム、性能管理方法、および管理装置
CN113791904B (zh) 用于处理查询输入的方法、装置、设备和可读存储介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100219

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100624

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100713

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100913

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110405

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110602

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110802

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110829

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140902

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees