JP5425448B2 - データベース・システム、サーバ、更新方法およびプログラム - Google Patents

Description

本発明は、データベース技術に関し、より詳細には、データベースに対する複数の更新要求を効率的に実行するためのデータベース・システム、サーバ、更新方法およびプログラムに関する。

近年、データベース・システムの大規模化に伴い、膨大な量のトランザクションを効率的かつ高速に処理し、高い信頼性、可用性および耐障害性にてデータ管理することに対する要望が高まっている。

トランザクションの効率化に関連して、データベースに対する更新時に、要求された更新の内容を一旦保存し、複数の更新をまとめて一度にデータベースに送信することで、スループットを改善する手法が知られている。これは、バッチ更新として参照され、ネットワーク・トラフィックを軽減し、類似の更新要求の処理の効率化、およびデータベースにおけるディスクの書き込みの最適化を図ることができる。

上記バッチ更新は、通常は、トランザクション内のリクエストをまとめて送信する際に利用される。複数の更新要求をまとめて送信することによって、ボトルネックとなるデータベース処理速度を改善し、トランザクション全体のスループットを向上させることができる。しかしながら、バッチ更新では、一定数の更新要求をコミットできる状態となるまでの待機時間が生じ、レスポンスタイムが低下する。

同様にトランザクションの効率化に関連して、メインメモリ上にレプリカを生成する技術が知られている。例えば、非特許文献１は、送信側のローカルディスクおよびレプリケーション先のリモートマシンのメインメモリにトランザクション・ログを書き込む技術を開示している。非特許文献１では、同期的なディスク書き込みを回避して、リモートマシンへの同期的なネットワーク・データ転送により置き換え、上記ローカルディスクおよびリモートマシンのメインメモリ上にログの複製を保持する。これにより、非同期に実施される実際のデータベースの磁気ディスクへの書き込みまでのデータの信頼性を保証している。非特許文献１では、メインメモリ上でのレプリケーションによって、実測で１００倍近くトランザクションのスループットを向上できることが報告されている。同様の技術として、非特許文献２でも、１００倍以上の性能向上が得られることが報告されている。

その他、非特許文献３は、ライトスルーが可能なシステム・エリア・ネットワーク（ＳＡＮ）で接続されたサーバからなるクラスタを用いたプライマリ・バックアップ構成において、データをレプリケーションすることによって、性能、信頼性および可用性を向上させたシステムを開示している。

S. Ioannidis, E. P. Markatos, J. Sevaslidou, "On Using Network Memory to Improve the Performance of Transaction Based System", Proceedings of International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA'98), (July 1998). D. E. Lowell, P. M. Chen, "Free Transactions with Rio Vista", 16th ACM Symposium on Operating Systems Principles, Pages 92 - 101, (October 1997). C. Amza, A. L. Cox, W. Zwaenepoel, "Data replication strategies for fault tolerance and availability on commodity clusters "In Proceedings of the International Conference on Dependable Systems and Networks, pp. 459-467, (2000).

３層アーキテクチャのデータベースにおいて、データベースの大規模化により、スケールアップによる対応が困難である場合、例えばインスタンスに閉じた処理の実行であれば、アプリケーション・サーバ上にパーティショニングしたキャッシュ（またはオブジェクト・ストア）を導入して、スケールアウトする手法が採用される。このようなパーティショニングされたシステムにおいては、パーティション毎に要求される更新を集積して、トランザクションとは非同期にバッチ更新することが効率的であると考えられる。しかしながら、各パーティション毎に入力負荷が異なる場合に、以下説明するバッチサイズ・アンバランスによる問題が発生してしまう。

システムにおける最長のバッチ更新の間隔、ＬＵＩ（Longest Update Interval；最長更新インターバル）は、障害状態（プライマリと全レプリカとが利用不可能となった状態）までのＭＴＴＦ（Mean Time to Failure；平均連続稼働時間）よりも短くなければならない。またバッチ更新は、実行のオーバヘッドが大きいため、バッチサイズが充分に大きくなければ、逆にスループットの低下を招く可能性がある。

図１２は、バッチサイズ・アンバランスを概略的に示す図である。従来では、バッチサイズを固定したバッチ更新において、各パーティション毎に入力負荷が異なる場合、図１２（Ａ）に示すように、ＬＵＩが負荷の小さいパーティションによって決定され、ゆえに短いＭＴＴＦに対応することができなくなる。

一方、バッチサイズではなく更新インターバルを固定したバッチ更新の場合、図１２（Ｂ）に示すように、高い負荷のパーティションと低いものとでバッチサイズが相違してしまい、多くが理想的なバッチサイズでバッチ更新されなくなってしまう。特に、負荷の小さな方のパーティションがほとんど更新を含んでいないにも関わらず、バッチ更新が実施されてしまう場合など、上述したオーバヘッドのため、最悪の場合、スループットの最高値がパーティションの個数に反比例してしまう。

上記パーティショニングは、パーティション間の負荷バランスを考慮して実施される、しかしながら、それにも限界があり、何らかの要因によって、パーティション間の更新要求の負荷バランスが崩れてしまった場合、設定された更新インターバルでのログの集積量にバラツキが生じてしまう可能性があった。あるいは、固定されたバッチサイズでは、負荷の小さなパーティションによるＬＵＩがＭＴＴＦを越えてしまう可能性があった。さらに、このようなシステムにレプリケーションを適用した場合、レプリケーションによる負荷も、更新負荷量に比例するためバラツキが生じてしまう。すなわち、パーティショニングされた分散システムにおいて、バッチ更新によるスループット向上の恩恵を最大化するためには、パーティション間のバッチサイズ・アンバランスの問題を解消する必要があった。

本発明は、上記問題点に鑑みてなされたものであり、本発明は、パーティショニングされた分散システムにおいて、パーティション間のバッチサイズ・アンバランスによる問題を解消して、もってバッチ更新によるスループット向上を最大化することが可能なデータベース・システム、サーバ、更新方法およびプログラムを提供することを目的とする。

本発明者らは、鋭意検討の結果、複数のサーバによるトランザクション・ログの相互レプリケーションをバッチ更新処理に適用することによって、従来問題となっていたパーティション間のバッチサイズ・アンバランスによる問題を回避することができ、もってバッチ更新によるスループット向上を最大化することができることを見出し、本発明に至ったのである。

本発明では、上記課題を解決するために、データベースと複数のサーバとを含むデータベース・システムにおいて、それぞれのサーバ上に、データベースの分割された少なくとも一部分のデータを格納しておき、アプリケーションからの更新要求に備える。そして、アプリケーションから上記データに関連する更新要求を受領して、その更新ログを格納するとともに、該更新ログを複製してシステム内の他のサーバに送信する。一方、他のサーバから受信した複製による更新ログのレプリカを、バッチ更新および多重化のために格納しておく。そして、上記更新ログおよび上記レプリカの合計に対応して、これら格納された更新ログおよび受信したレプリカを含ませたバッチ更新をまとめてデータベースに対し実行する。

上記構成では、更新要求をデータベースに対し実行する前に、障害に対して独立な１以上のサーバ上に更新ログが多重化され、高い永続性が担保される。多重化の成功をもってコミットとされ、データベースに対する実際の更新要求の実行は、上記バッチ更新として、トランザクションとは非同期に実施される。さらに上記バッチ更新は、他のサーバから受信した更新ログのレプリカも含み、すなわち複数のサーバ間で集約されたものであるため、バッチ更新のサイズは、複数のサーバでの合計となり、理想的なバッチサイズが容易に実現され得る。そして、相互に複製し合うもののうち、より高い更新負荷のものの更新負荷量に依存して最長更新インターバル（ＬＵＩ）が決まり、もって平均連続稼働時間（ＭＴＴＦ）以下のＬＵＩが達成し易くなる。

本発明では、さらに、複数のサーバから通知される更新負荷量に対応して、バッチ更新の実行主体を割り当てて通知するコーディネート・サーバをシステムに含めることができる。上記サーバは、複数のサーバ間でバッチ更新の実行主体を割り当てるために、受信した更新要求による更新負荷量を計量して通知することができ、サーバは、この割り当てに対応して、バッチ更新の実行主体となることができる。上記構成では、各サーバの更新負荷量に対応して、効率的に実行可能な主体（例えば、低い更新負荷のもの）にバッチ更新を実行させることが可能となる。

本発明では、上記サーバは、それぞれ上記データベースの分割されたデータに対応する1以上のパーティションを備えることができる。さらに本発明では、上記分割されたデータを格納するデータ格納部、上記更新ログを格納するログ格納部、上記レプリカを送信する送信部、上記レプリカを格納するレプリカ格納部および上記バッチ更新を実行する実行部を上記パーティション毎に構成することができる。本発明では、上記コーディネート・サーバは、パーティション更新負荷量のグループ内合計のグループ間での差異を最小化する組み合わせを求めて、更新ログを相互に複製し合うパーティションからなる相互複製グループ（レプリケーション・グループ）を編成することができる。

上記構成では、相互複製グループ内の総更新負荷量がグループ間で均一化されるように制御されるため、総更新負荷量が最も小さなグループによりＬＵＩが決定され、もって、パーティション毎の入力負荷の均一化が困難な場合であっても、より容易なグループの総入力負荷の調整によってＬＵＩを制御することが可能となる。また、バッチ更新のスループットは、グループへの総入力負荷が均一にバランスされ、入力負荷が充分あれる場合に、最大のスループットが期待できる。つまり、上記構成によれば、ＬＵＩの容易な制御に加え、スループットのチューニングも可能となる。

また本発明では、上記コーディネート・サーバは、実行主体のパーティションの障害に応答して、相互複製グループ内の障害のないパーティションの中から直近で最も低負荷なものを実行主体として割り当てて通知することができる。上記構成では、例え実行主体として割り当てられていたパーティションが動作するサーバが障害に陥ったとしても、更新ログがグループ内で相互複製されているため、他のパーティションに実行主体を切り替えて、バッチ更新を直ちに実施することが可能となる。したがって、耐障害性が向上される。

また本発明では、相互複製グループに属する他のパーティションの障害に応答して、または更新インターバルの経過に応答して、上記合計によらずバッチ更新を実行することができる。上記構成では、ＬＵＩがＭＴＴＦ以下となることを担保することができ、また、障害により永続性レベルが低下した状態から、データの安全性を迅速に確保することが可能となる。

また本発明では、バッチ更新の実行権限は、上記相互複製グループ内での該実行権限の貸し出しを管理するリースサーバから、または相互複製グループのすべてのパーティションによる相互合意によって取得されるよう構成することができる。また、相互複製グループ内のすべてのパーティションからのレプリカの受信確認の受領に対応して、更新要求に応答して前記アプリケーションへ処理を戻すことができる。さらに本発明では、上記データ格納部、上記ログ格納部および上記レプリカ格納部は、サーバのメインメモリにより提供することができる。

以下、本発明について実施形態をもって説明するが、本発明は、後述する実施形態に限定されるものではない。

以下の実施形態では、データベースと、該データベースにアクセスするアプリケーションが動作する複数のアプリケーション・サーバからなるクラスタとを含んで構成される３層クライアント・サーバ構成のデータベース・システム１０を例として説明する。

図１は、本発明の実施形態におけるデータベース・システム１０の概略図を示す。図１に示すデータベース・システム１０は、ネットワーク１２に接続するデータベース・サーバ１４を含んで構成される。ネットワーク１２は、例えば、ギガビット・イーサネット（登録商標）を含んで構成される。データベース・サーバ１４は、概ねパーソナル・コンピュータ、ワークステーション、ミッドレンジまたはメインフレームなどの汎用コンピュータ装置として構成されている。

データベース・サーバ１２は、より具体的には、シングルコア・プロセッサまたはマルチコア・プロセッサなどの中央処理装置（ＣＰＵ）、キャッシュ・メモリ、ＲＡＭ、ネットワーク・インタフェース・カード（ＮＩＣ）などを備える。データベース・サーバ１２は、さらにＳＡＳ（Serial Attached SCSI）、ＰＡＴＡ（Parallel ATA）、ＳＡＴＡ（Serial ATA）、ファイバ・チャネルなどのストレージ・インタフェースを介してディスク・ストレージ装置に接続されている。これによりデータベースの記憶領域が提供される。

本実施形態のデータベース・サーバ１４は、ＷＩＮＤＯＷＳ（登録商標）２００Ｘ、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）、ｚ／ＯＳ（登録商標）などのオペレーティング・システム（以下、ＯＳとして参照する。）により制御され、例えばＤＢ２（登録商標）、Ｏｒａｃｌｅ（登録商標）Ｄａｔａｂａｓｅ、Ｍｉｃｒｏｓｏｆｔ（登録商標）ＳＱＬ Ｓｅｒｖｅｒ（登録商標）などのリレーショナル・データベースを管理するデータベース管理システム（ＲＤＢＭＳ；Relational Database Management System）を実装している。データベースのデータモデルは、特に限定されるものではない。他の実施形態では、データベース・サーバ１４は、オブジェクト・リレーショナル・データベース、オブジェクト・データベース、階層型データベース、ネットワーク型データベース、ＸＭＬ（eXtensible Markup Language）データベースなど、他のデータモデルのデータベースを管理するＤＢＭＳを実装することもできる。

図１に示すデータベース・システム１０は、ネットワーク１２を介してデータベース・サーバ１４にアクセスするアプリケーション・サーバ（以下、ＡＰサーバとして参照する。」）２０をさらに含んで構成される。ＡＰサーバ２０も、データベース・サーバ１４と同様のハードウェア構成を備える汎用コンピュータ装置として構成することができる。ＡＰサーバ２０は、Ｊａｖａ（登録商標）ＥＥ（Java（登録商標）Platform, Enterprise Edition）などにより、ビジネスロジックなどを実装したアプリケーションを実装し、ネットワーク１２を介して受信する図示しないクライアントからの要求を処理している。例えば、ＡＰサーバ２０は、WebSphere（登録商標）Application Server、JBoss（登録商標）、Oracle（登録商標）Application Server、BEA WebLogic Server（登録商標）などにより構成することができる。

複数のＡＰサーバ２０ａ〜ｃは、ＡＰサーバ・クラスタ２２（以下、単位クラスタとして参照する。）を形成する。ＡＰサーバ２０ａ〜ｃは、それぞれ、データベース・サーバ１４が管理するデータベースがパーティショニングされて配置されたデータ格納部（Data Store）を保持し、クライアントからの要求を負荷分散しつつ処理している。データ格納部は、ＡＰサーバ２０の物理メインメモリの記憶空間により提供され、データベース・サーバ１４が管理するデータベースのキャッシュとして動作し、トランザクションの高速化を実現している。

ＡＰサーバ２０ａ〜ｃは、アプリケーション動作に対応して発生する、挿入（Insert）、変更（Update）、削除（Delete）などのデータベース更新要求に対し、データ格納部内のデータを読み出して、更新要求に対応し、更新ログを生成するとともに、応答する。また、更新要求による更新ログを蓄積し、まとまった更新ログをデータベース・サーバ１４へ一括送信（フラッシュ）して、トランザクションとは非同期的にデータベースに更新を反映する処理、所謂、バッチ更新を実施する。

さらに本実施形態のＡＰサーバ２０ａ〜ｃは、相互に更新ログを同期的にレプリケーションすることにより、バッチ更新が実施されるまでの間の永続性を担保し、レプリケーションによる更新ログの多重化の成功をもってコミットとし、レスポンスタイムを向上させている。また、上記バッチ更新の際には、相互に交換した更新ログのレプリカも対象とする。

図１に示すデータベース・システム１０は、さらに、ネットワーク１２に接続されるコーディネート・サーバ１６およびリースサーバ１８を含んで構成される。コーディネート・サーバ１６およびリースサーバ１８も同様に、ＡＰサーバ２０と同様のハードウェアおよびソフトウェア構成を備える汎用コンピュータ装置として構成することができる。コーディネート・サーバ１６およびリースサーバ１８の機能については、詳細を後述する。

図２は、本発明の実施形態によるデータベース・システム１０において、各サーバ上に実現される機能ブロック図を示す。図２に示すデータベース・システム１０に含まれる機能部（詳細は後述する。）は、それぞれ、対応するサーバにおいて、コンピュータ可読な記録媒体からプログラムを読み出し、メモリ上にプログラムを展開し、プログラムを実行することより各ハードウェア資源を動作制御することによって実現される。各サーバに配置される機能部は、例えばＥＪＢ（Enterprise Java（登録商標）Beans）のような分散オブジェクト技術のフレームワークにより相互に通信している。

各ＡＰサーバ２０上には、１以上のアプリケーション・モジュール（以下、単にモジュールとして参照する。）３０が動作している。また各ＡＰサーバ２０上には、それぞれデータ格納部５０を含む１以上のパーティション４０が動作している。

データ格納部５０は、データベース・サーバ１４が管理するデータベース９０をアプリケーション側の規則によってパーティショニングして配置されるデータをキャッシュし、保持するデータを用いてモジュール３０からの要求に応えている。データ格納部５０は、それぞれのＡＰサーバ２０の物理メインメモリ上に割り当てられた記憶空間により提供され、データベース９０のテーブルからパーティニングされた子テーブルの全体または一部分のデータを保持されている。データ格納部５０は、いわゆる実体化ビューを保持することができる。データ格納部５０は、好適には、インメモリ型のリレーショナル・データベースとして構成することができる。

パーティション４０は、それぞれ、データ格納部５０に加え、さらにバッチ処理部６０と、レプリカ処理部８０とを含んで構成される。バッチ処理部６０は、モジュール３０からのデータベース９０に対する更新要求による更新ログを一時的に格納している。レプリカ処理部８０は、上記データベース９０に対する更新要求による更新ログのレプリカを、後述する同一グループに所属する他のＡＰサーバ上で動作するパーティションのレプリカ処理部に送信する。送信先の他のすべてのパーティションのレプリカ処理部からレプリカの受領確認を受信して、更新ログの多重化の成功とされる。またレプリカ処理部８０は、同一グループに所属する他のパーティションのレプリカ処理部から更新ログのレプリカを受信して一時的に格納し、その受領確認を応答する。

バッチ処理部６０による更新ログの格納、およびレプリカ処理部８０のレプリカ送信による更新ログの多重化の成功をもってコミットとし、モジュール３０に対し更新要求の応答がなされる。上記更新ログおよびレプリカは、データ格納部５０と同様に、ＡＰサーバ２０の物理メインメモリの記憶空間により提供される。更新ログのレプリカは、プライマリ障害時に取り出せる形式にて保持していれば良いため、ディスクＩＯを回避することで、データベースへのアクセスと比較してレスポンスタイムを向上させることができる。

一方、上記バッチ処理部６０は、自身が一時的に格納する更新ログ、およびレプリカ処理部８０が格納する受信した更新ログのレプリカの合計量に対応して、これらの更新ログを読み出す。そして、バッチ処理部６０は、これら蓄積された更新内容をデータベース９０に反映させるべくバッチ更新を実施する。バッチ更新を受信したデータベース・サーバ１４は、バッチ更新に対応する更新処理を効率化してデータベース９０に反映させ、更新内容を永続化させる。なお、上記更新ログは、データベースを更新する前と更新した後のデータ、操作の内容などを保持するトランザクション・ログとして構成することができ、ＡＰサーバ２０側で蓄積する更新内容をデータベース９０に反映し永続化するための履歴情報である。

本実施形態のデータベース・システム１０においては、互いに独立したＡＰサーバ上で動作するパーティションから構成され、更新ログを相互にレプリケーションし合うものとして予め定められたグループ（以下、レプリケーション・グループとして参照する。）が構成される。上記バッチ更新は、すべてのパーティションがそれぞれに実施するのではなく、レプリケーション・グループに属するパーティションの内、いずれか１つのパーティションが実行主体として割り当てられて、実行される。負荷を分散させる観点から、好ましくは、上記レプリケーション・グループ内で直近の更新負荷量が最も小さいパーティションが実行主体として割り当てられる。

コーディネート・サーバ１６上には、グループ調整部９２が動作している。グループ調整部９２は、上記レプリケーション・グループを編成し、管理している。図３（Ａ）は、本発明の実施形態においてコーディネート・サーバ１６が保持するパーティション管理テーブル１２０のデータ構造を示す。図３（Ａ）に示すパーティション管理テーブル１２０は、パーティションを識別するパーティションＩＤが入力されるフィールド１２０ａと、そのパーティションが動作するサーバを識別するサーバＩＤが入力されるフィールド１２０ｂと、そのパーティションが現在所属しているレプリケーション・グループを識別するグループＩＤが入力されるフィールド１２０ｃとを含んで構成される。

パーティション管理テーブル１２０は、さらにパーティションの直近の更新負荷量を示す値を保持するフィールド１２０ｄを含んで構成される。グループ調整部９２は、定期的に各パーティション４０から更新負荷量の報告を受けて、フィールド１２０ｄの値を更新する。更新負荷量を示す値としては、特に限定されるものではないが、例えば単位時間あたりの更新数を採用することができ、図３に示す例では、１時間あたりの更新数が入力されている。

さらにグループ調整部９２は、フィールド１２０ｄの内容を定期的に参照し、グループ内で直近の更新負荷量が最小であるパーティションを実行主体（以下、実行パーティションとして参照する。）として割り当てて、通知する。パーティション管理テーブル１２０は、さらに、実行パーティションであるか否かを示す値が入力されるフィールド１２０ｅを含んで構成される。グループ調整部９２は、上記実行主体の割り当てに応じて、対応するフィールド１２０ｅの値を書き換える。また、グループ調整部９２は、実行主体に変更がある場合には、実行パーティションの割り当てから外れたパーティションに対してその旨を通知する。

さらに、パーティション管理テーブル１２０は、稼働状況を示す値が入力されるフィールド１２０ｆを含む。グループ調整部９２は、各ＡＰサーバ２０からのハートビートが途絶えたことに応答して、その障害を検知し、稼働状況に対応させてフィールド１２０ｆの値を更新する。なお、障害の検出方法は、例えば、ハートビートに限定されるものではなく、他の実施形態では、グループ調整部９２がポーリングを行って、応答の有無によりサーバの障害を検知することもできる。

実行パーティションが動作するＡＰサーバ２０の障害を検知した場合には、グループ調整部９２は、該実行パーティションがレプリケーション・グループから外れたものとして、実行パーティションの変更を実施する。ここで、実行主体ではないパーティションは、非実行パーティションとする。グループ調整部９２は、一方、障害が検知されたＡＰサーバ２０上の非実行パーティションが属するグループの実行パーティションに対しては、バッチ更新の即時実行を指示する。

さらにグループ調整部９２は、データベース・システム１０のスタートアップ時、またはメンテナンス時などにオペレータからの指示を受けて、クラスタ２２上で動作する各パーティション毎の直近の更新負荷量から、各グループ内の更新負荷量の総和がグループ間で均一化するようにパーティションをグループ分けする。これにより、グループ調整部９２は、レプリケーション・グループを編成することができる。レプリケーション・グループが決定されると、グループ調整部９２は、パーティション管理テーブル１２０のフィールド１２０ｃの値を書き換える。

図４は、本発明の実施形態によるコーディネート・サーバが実行するレプリケーション・グループの編成処理のフローチャートを示す。図４に示す処理は、データベース・システム１０のスタートアップや、オペレータからの指示を受けてステップＳ１００から開始される。ステップＳ１０１では、グループ調整部９２は、パーティション管理テーブル１２０にアクセスして、フィールド１２０ｂ，１２０ｄから、各パーティションが動作するサーバのサーバＩＤと、各パーティションの更新負荷量の最新情報とを取得する。

ステップＳ１０２では、グループ調整部９２は、各パーティションのグループ分けの可能な組合せを生成する。このとき、対応するサーバＩＤが重複して同一グループに含まれる組合せが排除される。また、１つのパーティションのみからなるグループを含むグループ分けの組合せも排除される。

ステップＳ１０３では、生成されたグループ分けの可能な組合せから、各グループ内の更新負荷量の総和のグループ間での差異を最小化するグループ分けの組合せを求め、レプリケーション・グループを編成する。例えば、グループ間の総更新負荷量の差の絶対値の総和が最小化される組合せを求める。

ステップＳ１０４では、編成されたレプリケーション・グループの各パーティションに対して、その所属グループ、および同一グループに所属する他パーティションを通知し、ステップＳ１０５で処理を終了させる。なお、ステップＳ１０４では、各レプリケーション・グループにつき、グループ内で最小の更新負荷量のパーティションに対し、実行パーティションに割り当てられた旨の通知を同時に実施することもできる。

また、レプリケーション・グループを編成する方法は、上述の例に限定されるものではない。例えば、他の実施形態では、各パーティションにつき、報告された更新負荷の時系列を記録しておき、各グループ内の一定期間の平均更新負荷の総和のグループ間での差異を最小化するグループ分けの組合せを求めて、レプリケーション・グループを編成することもできる。図４に示すようなレプリケーション・グループの編成処理により、各パーティションの更新負荷量が相違する場合であっても、後述するように、バッチ更新のバッチサイズをグループ間で均一化することが可能となる。

再び図２を参照すると、リースサーバ１８上には、リース管理部９４が動作している。実際のバッチ更新の際には、実行パーティションのバッチ処理部６０は、リース管理部９４に問い合わせて、バッチ更新の実行権限を確認する。リース管理部９４は、各レプリケーション・グループ内の実行パーティションのバッチ処理部６０から、バッチ更新の実行権限の問い合わせを受けて、期限付きで実行権限をリースする。リース管理部９４は、グループ内で唯一のパーティション４０のバッチ処理部６０に排他的にバッチ更新の実行権限を与えている。

例えば実行パーティションのＡＰサーバ２０がネットワーク障害等により、クラスタ２２から切り離された場合、ＡＰサーバの２０障害を検知したグループ調整部９２が実行パーティションを変更することで、同一グループ内に複数の実行パーティションが存在する可能性がある。このような場合、クラスタ２２から切り離されたＡＰサーバ２０上の実行パーティションが、他のネットワークを介してデータベース９０にバッチ更新してしまう蓋然性がある。しかしながら、上記の実行権限の管理により、ある時点で唯一の実行パーティションにバッチ更新の実行権限が与えられているため、少なくとも同時にバッチ更新してしまうことを回避することができる。

図３（Ｂ）は、本発明の実施形態においてリースサーバ１８が保持するリース管理テーブル１３０のデータ構造を示す。図３（Ｂ）に示すリース管理テーブル１３０は、グループＩＤが入力されるフィールド１３０ａと、そのグループの現在のバッチ更新の実行権限の割り当て状態を示す値が入力されるフィールド１３０ｂと、実行権限のリース期限が入力されるフィールド１３０ｃと、実行権限を付与したパーティションのＩＤが入力されるフィールド１３０ｄとを含んで構成される。

リース管理部９４は、各パーティションからバッチ更新の実行権限の問い合わせを受けて、そのグループの対応するフィールド１３０ｂの値を読み取る。その値が「ｌｏｃｋ」であり、かつ問い合わせのパーティションが権限を付与しているパーティションと相違すれば、リース管理部９４は、権限の取得失敗を通知する。リース管理部９４は、問い合わせを受けて、そのグループの対応するフィールド１３０ｂの値が「ｌｏｃｋ」であり、かつ問い合わせのパーティションが権限を付与しているパーティションであれば、更新期限を延長し、フィールド１３０ｃを書き換え、問い合わせ元に延長された期限を通知する。リース管理部９４は、問い合わせを受けて、フィールド１３０ｂの値が「ｕｎｌｏｃｋ」であれば、「ｌｏｃｋ」に書き換えて、問い合わせ元に権限の取得成功を通知し、フィールド１３０ｃ，ｄの値を書き換える。さらにリース管理部９４は、リース期限が切れた場合、フィールド１３０ｂの値を「ｕｎｌｏｃｋ」に書き換える。

なお、本実施形態では、リースサーバ１８を別途設けてバッチ更新の実行権限を管理しているが、他の実施形態では、同一グループに属するパーティションのバッチ処理部６０間でのメッセージ交換による相互合意よって、実行パーティションに期限付きで実行権限を認める構成としてもよい。その場合には、処理効率の観点から好適には、上記レプリカ処理部８０間の更新ログのレプリカの送受信の際にピギーバックさせることができる。

以下、図５〜図１２を参照して、本発明の実施形態による更新ログのレプリケーション処理およびバッチ更新処理の詳細について説明する。図５は、本発明の実施形態による、更新ログのレプリケーションおよびバッチ更新に関連するデータフロー図である。図５に示す図は、バッチ処理部６０およびレプリカ処理部８０について、より詳細な機能ブロックを示している。

バッチ処理部６０は、ログ格納部６２、更新実行部６４、更新タイマ６６、閾値比較部６８、更新カウンタ７０、および実行権限取得部７２を含んで構成される。レプリカ処理部８０は、レプリカ格納部８２、更新カウンタ８４、レプリカ受信部８６、およびレプリカ送信部８８を含んで構成される。

データ格納部５０は、モジュール３０からのデータベース９０に対する更新要求を受領して、この更新要求をバッチ処理部６０に渡す。バッチ処理部６０は、データ格納部５０から更新要求を受領して、その更新ログ１００をログ格納部６２に一時的に格納し、更新カウンタ７０をインクリメントし、データ格納部５０に処理を戻す。

データ格納部５０は、さらに更新要求をレプリカ処理部８０に渡す。レプリカ処理部８０は、データ格納部５０から更新要求を受領して、レプリカ送信部８８を呼び出し、その更新要求による更新ログのレプリカを、同一グループに所属する他のＡＰサーバ上で動作するパーティション４１のレプリカ処理部８１のレプリカ受信部（図示せず。）に送信する。レプリカ処理部８０は、レプリカ送信部８８が送信先のすべてのパーティションからの受領確認を受信したことに応答して、データ格納部５０へ処理を戻す。データ格納部５０は、ログ格納部６２による更新ログの格納、およびレプリカ送信部８８のレプリカ送信に対する受信確認の応答をもってコミットとし、モジュール３０に対し更新要求の応答する。

またレプリカ処理部８０のレプリカ受信部８６は、同一グループに所属する他のパーティションのレプリカ処理部８１のレプリカ送信部から更新ログのレプリカを受信して、更新ログのレプリカ（以下、更新ログ・レプリカとして参照する。）一時的にレプリカ格納部８２に格納し、更新カウンタ８４をインクリメントする。さらにレプリカ受信部８６は、更新ログ・レプリカの格納の後、その成功を受領確認として、送信元のレプリカ処理部８１のレプリカ送信部へ送信する。

実行パーティション４０の閾値比較部６８は、バッチ処理部６０の更新カウンタ７０およびレプリカ処理部８０の更新カウンタ８４の値をモニタし、その合計値とバッチサイズとして予め設定した閾値とを比較している。つまり、レプリケーション・グループ全体が受領した更新数が計数され、閾値と比較されることとなる。実行パーティション４０の閾値比較部６８により上記の合計値が閾値を超えたと判定される場合には、更新実行部６４が呼び出される。更新実行部６４は、呼び出されて、バッチ更新の実行権限を有する場合には、ログ格納部６２から更新ログ１００を読み出し、レプリカ格納部８２から更新ログ・レプリカ１１０を読み出して、例えばＳＱＬ文を作成し、データベース９０に対しバッチ更新を実行する。バッチ更新の実行権限が無い場合には、実行権限取得部７２が呼び出され、バッチ更新の実行権限を取得した後にバッチ更新を実行する。

更新実行部６４は、更新カウンタ７０および更新カウンタ８４の合計値によらず、バッチ更新を実施することができる。バッチ処理部６０の更新タイマ６６は、所属するグループにおける最後のバッチ更新からの経過時間を計時する。更新タイマ６６の所与の時間が経過したことに応答して、更新実行部６４が呼び出される。この所与の時間は、データベース・システム１０のＭＴＴＦ以下の値とすることが好ましい。更新実行部６４は、更新タイマ６６の満了に応答して、実行権限の取得を適宜行い、更新ログ１００および更新ログ・レプリカ１１０を読み出して、データベース９０に対しバッチ更新を実行する。

コーディネート・サーバ１６のグループ調整部９２は、ＡＰサーバ２０の障害を検知して、そのＡＰサーバ２０上で動作する非実行パーティションのグループ内の実行パーティションのバッチ処理部６０にバッチ更新の即時実行を指示する。バッチ処理部６０は、バッチ更新の即時実行の指示を受けて、実行権限の取得を適宜行い、更新実行部６４を呼び出して、データベース９０に対しバッチ更新を実行させる。

更新実行部６４は、バッチ更新が成功した場合、その対応する更新ログおよび更新ログ・レプリカを更新実行済みであるとして、ログ格納部６２およびレプリカ格納部８２から破棄するか、あるいは更新実行済みを示すフラグを立てる。そして更新実行部６４は、実行済みの更新要求を他の非実行パーティションに報告するために、更新実行済みの更新要求を報告する報告リストとしてリストアップして備える。レプリカ送信部８８は、次のレプリカ送信の際に報告リストをピギーバックして、グループ内の他のパーティションに報告する。

レプリカ受信部８６は、他のパーティションから報告リストを取得して、更新実行済みの更新ログ１００または更新ログ・レプリカ１１０をログ格納部６２およびレプリカ格納部８２から破棄するか、あるいは更新実行済みを示すフラグを立てる。フラグの立てられた更新要求は、後に、適宜破棄されることとなる。

更新カウンタ７０は、コーディネート・サーバ１６のグループ調整部９２に、自身の単位時間あたりの更新数を定期的に報告している。バッチ処理部６０は、実行パーティションとして割り当てられて、実行権限取得部７２を呼び出す。実行権限取得部７２は、実行パーティションである間、定期的にリースサーバ１８上のリース管理部９４に問い合わせて、実行権限を取得し、また維持する。

図６は、本発明の実施形態によるＡＰサーバ２０が実行するアプリケーション側からの更新要求に対する処理動作のフローチャートを示す。図６に示す処理は、アプリケーション側からのデータベースに対する更新要求に対応して、ステップＳ２００から開始される。ステップＳ２０１では、データ格納部５０は、モジュール３０からデータベースに対する更新要求を受領し、この更新要求をバッチ処理部６０へ渡す。ステップＳ２０２では、バッチ処理部６０は、更新要求による更新ログをログ格納部６２に格納し、ステップＳ２０３で、更新カウンタ７０をインクリメントし、データ格納部５０へ処理を戻す。

ステップＳ２０４では、更新要求がデータ格納部５０からレプリカ処理部８０へ渡され、レプリカ処理部８０は、更新要求による更新ログのレプリカを複製する。ステップＳ２０５では、報告リストにリストアップされた未報告の更新実行済みの更新要求があるか否かを判定する。ステップＳ２０５で、未報告の更新実行済みの更新要求が有ると判定された場合（ＹＥＳ）には、ステップＳ２０６へ処理を進める。ステップＳ２０６では、レプリカ処理部８０は、更新実行済みの更新要求を含む報告リストを、ステップＳ２０４で複製したレプリカに添付し、ステップＳ２０７へ処理を進める。

一方、ステップＳ２０５で、未報告の更新実行済みの更新要求が無いと判定された場合（ＮＯ）には、ステップＳ２０７へ直接処理を進める。ステップＳ２０７では、レプリカ処理部８０は、レプリカ送信部８８を呼び出し、同一グループに所属する他のすべてのパーティション４０のレプリカ受信部８６に対し、適宜報告リストをピギーバックさせて、レプリカを送信させる。ステップＳ２０８では、同一グループに所属する他のすべてのパーティション４０から受領確認を受信するまでの間（ＮＯの間）、ステップＳ２０８をループさせ、待ち受ける。

ステップＳ２０８で、他のすべてのパーティションから受領確認を受信したと判定された場合（ＹＥＳ）には、レプリカ処理部８０は、処理をデータ格納部５０へ戻し、ステップＳ２０９へ処理を進める。ステップＳ２０９では、データ格納部５０は、更新ログの多重化をもって当該更新要求をコミットとし、モジュール３０へ更新要求に対する応答をし、モジュール３０に処理を戻して、ステップＳ２１０で本処理動作を終了させる。

なお、ステップＳ２０８の待ち受けの際に、もし何らかの原因で所定の時間内にすべてのパーティションからの受領確認を受信できなかった場合などには、適宜エラー・ハンドリングを行うことができる。ここでのエラー・ハンドリングは、特に限定されるものではないが、例えば、データベース・システム１０の運用ポリシーに応じて、１以上のレプリカの多重化の成功をもってコミットとし、後にレプリカの受領確認を受け取っていないパーティションにレプリカを再送するように構成することができる。

図７は、本発明の実施形態によるＡＰサーバ２０が実行する他サーバから送信されたレプリカの受信時の処理動作のフローチャートを示す。図７に示す処理は、他サーバのレプリカ送信部８８からのレプリカ送信に対応して、ステップＳ３００から開始される。ステップＳ３０１では、レプリカ受信部８６は、他サーバ上の同一グループのレプリカ送信部８８から更新ログ・レプリカを受信する。レプリカ処理部８０は、ステップＳ３０２で受信した更新ログ・レプリカをレプリカ格納部８２に格納し、ステップＳ３０３で更新カウンタ８４をインクリメントし、ステップＳ３０４で送信元のレプリカ送信部８８へ受領確認を応答する。

ステップＳ３０５では、受信したレプリカに報告リストが添付されているか否か、つまり、更新実行済み更新要求が報告されたか否かを判定する。ステップＳ３０５で、更新実行済み更新要求が報告されていると判定された場合（ＹＥＳ）には、ステップＳ３０６へ処理を進める。ステップＳ３０６では、報告リスト中の更新実行済みの更新要求に対応する更新ログおよび更新ログ・レプリカを、それぞれ、ログ格納部６２およびレプリカ格納部８２から破棄、あるいは更新実行済みを示すフラグを立てて、ステップＳ３０７で本処理動作を終了させる。一方、ステップＳ３０５で、更新実行済み更新要求が報告されていないと判定された場合（ＮＯ）には、ステップＳ３０７へ直接進めて、本処理動作を終了させる。

図８は、本発明の実施形態によるＡＰサーバ２０が実行するバッチ更新処理動作のフローチャートを示す。図８に示す処理は、実行パーティションとして割り当てられた旨の通知に対応してステップＳ４００から開始される。ステップＳ４０１では、バッチ処理部６０は、グループ調整部９２からの実行パーティションとして割り当てられた旨の通知メッセージを受信する。ステップＳ４０２では、バッチ処理部６０は、実行権限取得部７２を呼び出して、リースサーバ１８のリース管理部９４に対し、バッチ更新の実行権限を問い合わせる。

ステップＳ４０３では、バッチ処理部６０は、現在まだ実行パーティションであるか否かを判定する。ステップＳ４０３で、例えば、実行権限の問い合わせ中、問い合わせの再試行中、またはバッチ更新の契機となるイベントの待ち受け中に実行パーティションが変更された場合など、既に実行パーティションではないと判定された場合（ＮＯ）には、ステップＳ４１７へ処理を進め、本処理動作を終了させる。一方、ステップＳ４０３で、現在まだ実行パーティションであると判定された場合（ＹＥＳ）には、ステップＳ４０４へ処理を進める。

ステップＳ４０４では、バッチ処理部６０は、ステップＳ４０２での問い合わせの結果実行権限を取得し、また実行権限のリース期限前の有効な権限を有しているか否かを判定する。ステップＳ４０４で、権限の取得に失敗したり、またはバッチ更新の契機となるイベントの待ち受け中にリース期限を超過したりしており、有効な権限を有さないと判定された場合（ＮＯ）には、ステップＳ４０５へ処理を進める。ステップＳ４０５では、一定時間待機し、再びステップＳ４０２へループさせ、実行権限の問い合わせを再試行する。

ステップＳ４０４で、有効な権限を有していると判定された場合（ＹＥＳ）には、ステップＳ４０６へ処理を進める。ステップＳ４０６では、バッチ処理部６０は、グループ調整部９２から非実行パーティション障害時におけるバッチ更新の即時実行が指示されているか否かを判定する。ステップＳ４０６で、バッチ更新の即時実行が指示されていないと判定された場合（ＮＯ）には、ステップＳ４０７へ処理を進める。ステップＳ４０７では、バッチ処理部６０は、更新タイマ６６が満了しているか否かを判定する。ステップＳ４０７で、更新タイマ６６が未だ満了していないと判定された場合（ＮＯ）には、ステップＳ４０８へ処理を進める。

バッチ処理部６０は、ステップＳ４０８では、閾値比較部６８を呼び出し、バッチ処理部６０の更新カウンタ７０およびレプリカ処理部８０の更新カウンタ８４の合計値を取得させ、ステップＳ４０９で、合計値が所定の閾値を越えているか否かを判定させる。ステップＳ４０９で、合計値が閾値を超えていないと判定された場合（ＮＯ）には、再びステップＳ４０３へ処理をループさせ、少なくとも実行パーティションである間、障害時の即時実行が指示されるか、更新タイマが満了するか、更新カウンタ７０および更新カウンタ８４の合計値が閾値を超えるまで、ステップＳ４０２〜Ｓ４０９の処理を繰り返させ、バッチ更新の契機となるイベントの発生を待ち受ける。

上記ステップＳ４０６で即時実行が指示されていると判定された場合（Ｓ４０６：ＹＥＳ）、上記ステップＳ４０７で更新タイマ６６が満了していると判定された場合（Ｓ４０７：ＹＥＳ）、またはステップＳ４０９で更新カウンタ７０および更新カウンタ８４の合計値が閾値を越えていると判定された場合（Ｓ４０９：ＹＥＳ）には、ステップＳ４１０へ処理を分岐させる。

ステップＳ４１０では、バッチ処理部６０は、更新実行部６４を呼び出し、ログ格納部６２およびレプリカ格納部８２に格納されている更新未実行の更新ログおよび更新ログ・レプリカを取得させる。ステップＳ４１１では、更新実行部６４は、データベース９０に問い合わせて、後述のバッチ更新時に付されるタイムスタンプなどの更新の版管理を可能とするバージョンＩＤの有効性を確認する。ステップＳ４１１で、バージョンＩＤが有効であると判定された場合（ＹＥＳ）には、ステップＳ４１２へ処理を進める。

ステップＳ４１２では、更新実行部６４は、データベース９０に対しバッチ更新による永続化を要求するためのＳＱＬ文を作成し、バッチ更新を実行する。このとき、更新実行部６４は、後にバージョンの有効性を判定するために、同一トランザクション内でデータベース９０上のマスタに付したタイムスタンプなどのバージョンＩＤの更新も要求する。バッチ更新を受信したデータベース９０では、バッチ更新が含む複数の更新要求が最適化されて処理され、更新内容が永続化されることとなる。

ステップＳ４１３では、ステップＳ４１２のバッチ更新が成功裡に完了したか否かを判定する。ステップＳ４１３で、データベース９０からバッチ更新の完了応答を受信して、バッチ更新が成功したと判定される場合（ＹＥＳ）には、ステップＳ４１４へ処理を進める。ステップＳ４１４では、更新実行部６４は、当該バッチ更新の実行により更新実行済みとなった更新要求を上記報告リストに追加する。なお、障害時の即時実行が指示される場合などには、次のレプリカ送信を待たずに、報告リストを直ちに送信することもできる。

報告リストには、バッチ更新の実行時刻のタイムスタンプなどをバージョンＩＤとして含めることができる。ステップＳ４１１のバージョンＩＤの有効性の判定処理では、通知リストに含められた前回のバッチ更新の実行時刻を示すバージョンＩＤと、データベース９０から取得したバージョンＩＤとを比較し、データベース９０から取得したバージョンＩＤが前回のバッチ更新のものと一致することをもって有効とし、前後関係からバージョンＩＤの有効性を判定することができる。

ステップＳ４１５では、バッチ処理部６０は、更新タイマ６６、更新カウンタ７０および更新カウンタ８４をリセットして、ステップＳ４０３へ処理をループさせ、次のバッチ更新に備える。一方、ステップＳ４１１で、バージョンが有効ではないと判定された場合（Ｓ４１１：ＮＯ）またはステップＳ４１３で、バッチ更新が成功裡に完了しなかったと判定された場合（Ｓ４１３：ＮＯ）には、ステップＳ４１６へ処理を分岐させる。

ステップＳ４１６では、エラー処理を実行し、ステップＳ４０３へ処理をループさせ、次のバッチ更新に備える。ステップＳ４１６のエラー処理では、例えば、エラー警告などを管理者に通知するためにエラー出力して、パーティショニング・コーディネータに失敗を通知するなどのエラー・ハンドリングを行うことができる。この場合、例えば、グループ調整部９２は、別のパーティションを実行パーティションとして割り当てるなどをして対応することとなる。

また、バージョンＩＤの無効エラーは、当該実行パーティション以外のパーティションにより既にバッチ更新が実施されている場合に発生することが想定される。より具体的には、バージョンＩＤの無効エラーは、実行パーティションが動作するＡＰサーバ２０のハートビートが何らかの理由でコーディネート・サーバに伝達されず、グループ調整部９２が他のパーティションを実行パーティションとして割り当てた場合であって、（ｉ）その新しい実行パーティションが先にバッチ更新を実施してしまった場合、あるいは、（ｉｉ）新しい実行パーティションが割り当てられた後に、障害が検知された古い実行パーティションによって先にバッチ更新が実施されてしまった場合が想定される。ステップＳ４１６の処理では、バージョンＩＤの無効エラーの場合に、データベース９０に問い合わせて該データベース９０との整合性を維持するように、バッチ更新済みの更新要求を削除あるいは更新済みを示すフラグを立て、対応する更新数を更新カウンタ７０，８４をデクリメントするなどのエラー・ハンドリングを行うこともできる。

図９は、本発明の実施形態による実行パーティションの障害時のデータベース・システム１０の処理動作を示すシーケンス図を示す。図９では、第１パーティション４０−１が実行パーティションであり、第４パーティション４０−４が同一グループの非実行パーティションである場合を例として説明する。

第１パーティション４０−１および第４パーティション４０−４は、ステップＳ５００およびステップＳ５０１で示すように、それぞれ、パートビートとして定期的に稼働通知をグループ調整部９２に対して行っている。例えば、グループ調整部９２が、ステップＳ５０２で第４パーティション４０−４から稼働通知を受信するも、実行パーティションである第１パーティション４０−１からの稼働通知を一定時間受信しない場合、ステップＳ５０３で、第１パーティション４０−１の障害を検知する。

ステップＳ５０４では、グループ調整部９２は、障害を検知した第１パーティション４０−１と同一グループに所属する第４パーティション４０−４を新たな実行パーティションとして割り当て、その旨を通知する。実行パーティションとして新たに割り当てられた第４パーティション４０−４は、ステップＳ５０５で、直ちにバッチ更新の実行権限をリース管理部９４に問い合わせる。リース管理部９４は、ステップＳ５０６で第１パーティション４０−１に与えていた実行権限のリース期限の途過を待ち、満了を確認する。リース管理部９４は、ステップＳ５０７で、第４パーティション４０−４に実行権限を与える。

この場合、更新ログまたは１以上のレプリカのいずれかが１以上のＡＰサーバ２０上に存在する一方で、更新ログの多重化による永続性レベルが低下している状態となる。そのため、ステップＳ５０８では、新たな実行パーティションである第４パーティション４０−４は、データベース９０に対し速やかにバッチ更新を実行し、データベース９０上に永続化する。バッチ更新が成功裡に完了したことに応答して、ステップＳ５０９で、第４パーティション４０−４は、他の同一グループの第１パーティション４０−１に対し、直ちにバッチ更新実行済み更新要求の報告を試みることができる。

なお、障害後、バッチ更新を成功裡に完了させた後は、データベース・システム１０における運用上のポリシーに従った動作を行うことができ、特に限定されるものではない。例えば、障害サーバの復帰を待たずに低い永続性レベルにてサービスを再開してもよい。その他、障害サーバが復帰するのを待って所期の家属性レベルにてサービスを再開してもよい。あるいは、予備のＡＰサーバにパーティションを再配分して、所期の永続性レベルにてサービスを再開してもよい。低い永続性レベルでのサービス継続をしない運用では、ステップＳ５０４で、実行パーティションを割り当て直した際に、全てのパーティションに対しサービス停止を指示することができる。この場合、そのグループ内の各パーティション４０は、モジュール３０からの新たな更新要求を受領せず、全ての更新がデータベース９０に反映され、永続性レベルの回復を待って、再びサービスが再開されることとなる。

図１０は、本発明の実施形態による非実行パーティションの障害時のデータベース・システム１０の処理動作を示すシーケンス図を示す。図１０では、図９と同様に、第１パーティション４０−１が初期の実行パーティションであり、第４パーティション４０−４が初期の同一グループの非実行パーティションである場合を例として説明する。

第１パーティション４０−１および第４パーティション４０−４は、ステップＳ６００およびステップＳ６０１で示すように、それぞれ、パートビートとして定期的に稼働通知をグループ調整部９２に対して行っている。例えば、グループ調整部９２が、ステップＳ６０２で、実行パーティションである第１パーティション４０−１から稼働通知を受信するも、第４パーティション４０−４からの稼働通知を一定時間受信しない場合、ステップＳ６０３で、非実行パーティションである第４パーティション４０−４の障害を検知する。

ステップＳ６０４では、グループ調整部９２は、障害を検知した第４パーティション４０−４と同一グループに所属する実行パーティションである第１パーティション４０−１に、バッチ更新の即時実行を指示する。実行パーティションである第１パーティション４０−１は、ステップＳ６０５で、データベース９０に対し速やかにバッチ更新を実行し、データベース９０上に永続化する。バッチ更新が成功裡に完了したことに応答して、ステップＳ６０６で、第１パーティション４０−１は、他の同一グループの第４パーティション４０−４に対し、直ちにバッチ更新実行済み更新要求の報告を試みることができる。ステップＳ６０５の際に実行権限を有さなければ、実行権限をリース管理部９４に問い合わせる。

なお、障害後、バッチ更新を成功裡に完了させた後は、データベース・システム１０における運用上のポリシーに従った動作を行うことができ、実行パーティションについて上述したように、特に限定されるものではない。

図１１は、本発明の実施形態による実行パーティションでのバッチ更新のバッチサイズと、ＬＵＩ（最長更新インターバル）との関係を示す。上述したように、従来技術では、何らかの要因によって、パーティション間の更新要求の負荷バランスが崩れてしまった場合、固定された更新インターバルでのログの集積量がバラツキが生じてしまうか、あるいは固定されたバッチサイズでは、負荷の小さなパーティションによるＬＵＩが、ＭＴＴＦを越えてしまう可能性があった。

一方、本発明の実施形態によるバッチ更新では、各パーティションが受領した更新要求による更新ログが、所属のレプリケーション・グループ内で共有され、集積される。そして、好適には、グループ内の直近負荷の最も小さなパーティションがバッチ更新の実行主体として割り当てられ、上記集積した更新要求が一括してデータベース９０に送信および反映される。

更新要求の蓄積量は、個々のパーティションの更新負荷量によらず、編成されたグループ内の更新負荷の総量によって増大してゆく。したがって、バッチサイズ固定では、グループ内のＬＵＩは、最悪の場合でもグループ内の最大の更新負荷を有するパーティションに依存して定まる。そして、全体のＬＵＩは、最小の更新負荷の総量のレプリケーション・グループによって定まる。

したがって、本発明の実施形態によるバッチ更新では、パーティション間の更新の入力負荷のバランスが困難であっても、より容易なレプリケーション・グループ編成による総入力負荷の制御によって、ＭＴＴＦ以下の所望の値にＬＵＩを制御することが可能となる。さらに、レプリケーション・グループを各パーティションの更新負荷量に対応させて再構成することもできるので、グループ間の総更新負荷の均一化を図ることができる。

また、従来技術では、入力負荷のバラツキが大きいとき、ＭＴＴＦに従ってＬＵＩを制限すると、図１２（Ｂ）に示すように、入力負荷の小さなパーティションでは、殆ど更新要求を含まないバッチ更新が実施されてしまうことがあった。バッチ更新は、効率化に大きく寄与する一方、実行のオーバヘッド自体は大きいため、この従来のバッチ更新では、バッチサイズ・アンバランスに起因して、レプリケーション・グループのメンバがｎ台の場合、最悪時には、最大スループットが最高時の約１／ｎに見積もられる。

一方、本発明の実施形態では、上述したようにレプリケーション・グループ全体の更新要求を一括でバッチ更新するため、堪えずＬＵＩ内で最も集約した状態でバッチ更新を実施することができ、バッチサイズを増大させることが可能となる。特にレプリケーション・グループ間の入力負荷が均一に分散され、入力負荷が充分に大きいとき、最高のスループットを得ることが可能となる。

以上説明したように、本発明の実施形態によれば、パーティショニングされた分散システムにおいて、パーティション間のバッチサイズ・アンバランスによる問題を解消して、もってバッチ更新によるスループット向上を最大化することが可能なデータベース・システム、サーバ、更新方法およびプログラムを提供することができる。

なお、本発明につき、発明の理解を容易にするために各機能部および各機能部の処理を記述したが、本発明は、上述した特定の機能部が特定の処理を実行する外、処理効率や実装上のプログラミングなどの効率を考慮して、いかなる機能部に、上述した処理を実行するための機能を割当てることができる。

本発明の上記機能は、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなどのオブジェクト指向プログラミング言語、ＳＱＬなどのデータベース言語などで記述された装置実行可能なプログラムにより実現でき、装置可読な記録媒体に格納して頒布または伝送して頒布することができる。

これまで本発明を、特定の実施形態をもって説明してきたが、本発明は、実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

本発明の実施形態におけるデータベース・システムの概略図。 本発明の実施形態によるデータベース・システムにおいて、各サーバ上に実現される機能ブロック図。 本発明の実施形態において（Ａ）コーディネート・サーバが保持するパーティション管理テーブル、（Ｂ）リースサーバが保持するリース管理テーブルのデータ構造を示す図。 本発明の実施形態によるコーディネート・サーバが実行するレプリケーション・グループの編成処理のフローチャート。 本発明の実施形態による、更新ログのレプリケーションおよびバッチ更新に関連するデータフロー図。 本発明の実施形態によるＡＰサーバが実行するアプリケーション側からの更新要求に対する処理動作のフローチャート。 本発明の実施形態によるＡＰサーバが実行する他サーバから送信されたレプリカの受信時の処理動作のフローチャート。 本発明の実施形態によるＡＰサーバが実行するバッチ更新処理動作のフローチャート。 本発明の実施形態による実行パーティションの障害時のデータベース・システム１０の処理動作を示すシーケンス図。 本発明の実施形態による非実行パーティションの障害時のデータベース・システムの処理動作を示すシーケンス図 本発明の実施形態による実行パーティションでのバッチ更新のバッチサイズとＬＵＩとの関係を示す図。 従来技術によるバッチサイズ・アンバランスを概略的に示す図。

符号の説明

１０…データベース・システム、１２…ネットワーク、１４…データベース・サーバ、１６…コーディネート・サーバ、１８…リースサーバ、２０…ＡＰサーバ、２２…クラスタ、３０…モジュール、４０，４１…パーティション、５０…データ格納部、６０…バッチ処理部、６２…ログ格納部、６４…更新実行部、６６…更新タイマ、６８…閾値比較部、７０…更新カウンタ、７２…実行権限取得部、８０，８１…レプリカ処理部、８２…レプリカ格納部、８４…更新カウンタ、８６…レプリカ受信部、８８…レプリカ送信部、９０…データベース、９２…グループ調整部、９４…リース管理部、１００…更新ログ、１１０…更新ログ・レプリカ、１２０…パーティション管理テーブル、１３０…リース管理テーブル

Claims (20)

1. データベースと複数のサーバとを含むデータベース・システムであって、前記サーバ各々は、
   前記データベースの分割された、当該サーバ上で動作するパーティションのデータを格納するデータ格納部と、
   アプリケーションから受領した、前記パーティションに関連する更新要求に応答して、該更新要求による更新ログを格納するログ格納部と、
   前記更新要求に応答して、前記更新ログの複製を、当該サーバ上で動作するパーティションと同一のグループに属する他のパーティションが動作する他のサーバに送信する送信部と、
   前記同一のグループに属する他のパーティションが動作する他のサーバから受信した複製による更新ログのレプリカを格納するレプリカ格納部と、
   前記同一のグループに属する複数のパーティションの中から実行主体として割り当てられた場合に、前記ログ格納部に格納された前記更新ログおよび前記レプリカ格納部に格納された前記更新ログのレプリカの合計に基づいて、前記データベースに対しバッチ更新を実行する実行部と
   を含む、データベース・システム。
2. 複数のサーバから通知されるパーティションの更新負荷量に対応して、前記同一のグループの複数のパーティションの中から前記バッチ更新の実行主体を割り当てて、前記実行部に通知するコーディネート・サーバをさらに含む、請求項１に記載のデータベース・システム。
3. 前記サーバは、それぞれ前記データベースの分割された１以上のパーティションを備え、前記データ格納部、前記ログ格納部、前記送信部、前記レプリカ格納部および前記実行部は、前記パーティション毎に構成される、請求項２に記載のデータベース・システム。
4. 前記コーディネート・サーバは、パーティションの更新負荷量のグループ内合計のグループ間での差異を最小化する組み合わせを求めて、前記複数のサーバのうちの互いに独立したサーバ上で動作するパーティションから構成され、前記更新ログを相互に複製し合うものとして定められるグループを編成する、請求項３に記載のデータベース・システム。
5. 前記実行部は、前記バッチ更新の実行権限を、前記グループ内での該実行権限の貸し出しを管理するリースサーバから、または前記同一のグループに属するすべてのパーティションによる相互合意によって、取得する、請求項４に記載のデータベース・システム。
6. 前記コーディネート・サーバは、実行主体のパーティションの障害に応答して、前記グループ内の障害の無いパーティションの中から直近で最も低負荷なものを実行主体として割り当てて通知する、請求項５に記載のデータベース・システム。
7. 前記実行部は、前記同一のグループに属する他のパーティションの障害に応答して、または更新インターバルの経過に応答して、前記合計によらず前記バッチ更新を実行する、請求項６に記載のデータベース・システム。
8. 前記同一のグループ内のすべてのパーティションからのレプリカの受信確認の受領に対応して、前記更新要求に応答して前記アプリケーションへ処理が戻される、請求項７に記載のデータベース・システム。
9. データベースと、それぞれ該データベースの分割された他のパーティションが動作する１以上の他のサーバとに接続するサーバであって、前記サーバは、
   前記データベースの分割された、当該サーバ上で動作するパーティションのデータを格納するデータ格納部と、
   アプリケーションから受領した当該サーバ上で動作するパーティションに関連する更新要求に応答して、該更新要求による更新ログを格納するログ格納部と、
   前記更新要求に応答して、前記更新ログの複製を、当該サーバ上で動作するパーティションと同一のグループに属する他のパーティションが動作する他のサーバに送信する送信部と、
   前記同一のグループに属する他のパーティションが動作する他のサーバから受信した複製による更新ログのレプリカを格納するレプリカ格納部と、
   前記同一のグループに属する複数のパーティションの中から実行主体として割り当てられた場合に、前記ログ格納部に格納された前記更新ログおよび前記レプリカ格納部に格納された前記更新ログのレプリカの合計に基づいて、前記データベースに対しバッチ更新を実行する実行部と
   を含む、サーバ。
10. 前記サーバは、前記同一のグループの複数のパーティションの中から前記バッチ更新の実行主体を割り当てるために、受信した前記更新要求によるパーティションの更新負荷量を計量する負荷計量部をさらに含み、前記実行部は、前記パーティションの更新負荷量に基づいた割り当てに対応して、前記バッチ更新の実行主体となる、請求項９に記載のサーバ。
11. 前記サーバは、それぞれ前記データベースの分割された、前記更新ログを相互に複製し合ういずれかのグループに属する１以上のパーティションを備え、前記データ格納部、前記ログ格納部、前記送信部、前記レプリカ格納部および前記実行部は、前記パーティション毎に構成される、請求項９または１０に記載のサーバ。
12. 前記実行部は、前記同一のグループに属する他のパーティションの障害に応答して、または更新インターバルの経過に応答して、前記合計によらず前記バッチ更新を実行する、請求項１１に記載のサーバ。
13. データベースを更新する方法であって、前記方法は、該データベースと、それぞれ該データベースの分割された他のパーティションが動作する１以上の他のサーバとに接続するサーバが、
    アプリケーションから、前記データベースの分割された、当該サーバ上で動作するパーティションに関連する更新要求を受領するステップと、
    前記更新要求に応答して、受領した前記更新要求による更新ログを格納するとともに、前記更新ログの複製を、当該サーバ上で動作するパーティションと同一のグループに属する他のパーティションが動作する他のサーバに送信するステップと、
    送信先の前記他のサーバからのレプリカの受信確認を受領して、前記アプリケーションに前記更新要求に対応して応答するステップと
    を実行し、さらに前記方法は、前記サーバが、
    前記同一のグループに属する他のパーティションが動作する他のサーバから複製による更新ログのレプリカを受信して格納するステップと、
    前記同一のグループに属する複数のパーティションの中から実行主体として割り当てられた場合に、格納された前記更新ログおよび前記更新ログのレプリカの合計に基づいて、前記データベースに対しバッチ更新を実行するステップと
    を実行する、更新方法。
14. 前記サーバが、さらに、前記同一のグループの複数のパーティションの中から前記バッチ更新の実行主体を割り当てるために、受領した前記更新要求によるパーティションの更新負荷量を計量するステップと、前記パーティションの更新負荷量に基づいた割り当てに対応して、前記バッチ更新の実行主体となるステップとを実行する、請求項１３に記載の更新方法。
15. 前記サーバが、それぞれ、前記データベースの分割された、更新ログを相互に複製し合ういずれかのグループに属する１以上のパーティションを実現するステップをさらに実行する、請求項１３または１４に記載の更新方法。
16. 前記サーバが、前記同一のグループに属する他のパーティションの障害の通知に応答して、または、更新インターバルの経過に応答して、前記合計によらず前記バッチ更新を実行するステップをさらに実行する、請求項１５に記載の更新方法。
17. コンピュータを、データベースと、それぞれ該データベースの分割された他のパーティションが動作する１以上の他のサーバとに接続するサーバとして機能させるためのコンピュータ実行可能なプログラムであって、前記プログラムは、前記コンピュータを
    前記データベースの分割された、当該サーバ上で動作するパーティションのデータを格納するデータ格納部、
    アプリケーションから受領した、当該サーバ上で動作するパーティションに関連する更新要求に応答して、該更新要求による更新ログを格納するログ格納部、
    前記更新要求に応答して、前記更新ログの複製を、当該サーバ上で動作するパーティションと同一のグループに属する他のパーティションが動作する他のサーバに送信する送信部、
    前記同一のグループに属する他のパーティションが動作する他のサーバから受信した複製による更新ログのレプリカを格納するレプリカ格納部、および
    前記同一のグループに属する複数のパーティションの中から実行主体として割り当てられた場合に、前記ログ格納部に格納された前記更新ログおよび前記レプリカ格納部に格納された前記更新ログのレプリカの合計に基づいて、前記データベースに対しバッチ更新を実行する実行部
    として機能させる、コンピュータ実行可能なプログラム。
18. 前記サーバを、さらに、前記同一のグループの複数のパーティションの中から前記バッチ更新の実行主体を割り当てるために、受信した前記更新要求によるパーティションの更新負荷量を計量する負荷計量部として機能させ、前記実行部は、前記パーティションの更新負荷量に基づき割り当てに対応して、前記バッチ更新の実行主体として機能させる、請求項１７に記載のプログラム。
19. 前記サーバに前記データベースの分割された、更新ログを相互に複製し合ういずれかのグループに属する１以上のパーティションを生成させ、前記データ格納部、前記ログ格納部、前記送信部、前記レプリカ格納部および前記実行部は、前記パーティション毎に構成される、請求項１８に記載のプログラム。
20. データベースと、コーディネート・サーバと、複数のサーバとを含むデータベース・システムであって、前記サーバ各々は、
    前記データベースの分割された、当該サーバ上で動作するパーティションのデータを格納するデータ格納部と、
    アプリケーションから受領した、前記パーティションに関連する更新要求に応答して、該更新要求による更新ログを格納するログ格納部と、
    前記更新要求に応答して、前記更新ログの複製を、当該サーバ上で動作するパーティションと同一のグループに属する他のパーティションが動作する他のサーバに送信する送信部と、
    前記同一のグループに属するパーティションが動作する他のサーバから受信した複製による更新ログのレプリカを格納するレプリカ格納部と、
    前記同一のグループに属する複数のパーティションの中から実行主体として割り当てられた場合に、前記ログ格納部に格納された前記更新ログおよび前記レプリカ格納部に格納された前記更新ログのレプリカの合計に基づいて、前記データベースに対しバッチ更新を実行する実行部と
    を含み、
    前記コーディネート・サーバは、複数のサーバから通知されるパーティションの更新負荷量に対応して、バッチ更新の実行主体を割り当てて、実行部に通知し、
    前記サーバは、それぞれ前記データベースの分割された１以上のパーティションを備え、前記データ格納部、前記ログ格納部、前記送信部、前記レプリカ格納部および前記実行部は、前記パーティション毎に構成され、
    前記コーディネート・サーバは、前記パーティションの更新負荷量のグループ内合計のグループ間での差異を最小化する組み合わせを求めて、更新ログを相互に複製し合うパーティションからなるグループを編成し、
    前記実行部は、前記バッチ更新の実行権限を、前記グループ内での該実行権限の貸し出しを管理するリースサーバから、または前記同一のグループに属するすべてのパーティションによる相互合意によって、取得し、
    前記コーディネート・サーバは、実行主体のパーティションの障害に応答して、前記グループ内の障害の無いパーティションの中から直近で最も低負荷なものを実行主体として割り当てて通知し、
    前記実行部は、前記同一のグループに属する他のパーティションの障害に応答して、または更新インターバルの経過に応答して、前記合計によらず前記バッチ更新を実行し、
    前記同一のグループ内のすべてのパーティションからのレプリカの受信確認の受領に対応して、前記更新要求に応答して前記アプリケーションへ処理が戻される、
    データベース・システム。

Images