JP6187598B2 - 送信装置、情報処理システム、マスタサーバ、データベースシステムおよび方法 - Google Patents

Description

本発明は、ネットワークを介して接続された装置間でデータを転送する技術に関する。

ネットワークを介して接続された装置間でデータを転送する情報処理システムでは、信頼性のある通信を行いながら、転送時間をできるだけ短くすることが求められる。このような情報処理システムとしては、例えば、メモリデータベースシステムが挙げられる。一般に、メモリデータベースシステムは、１つ以上用意されたスレーブサーバのメモリ上に、マスタサーバが持つデータの複製を持つ。マスタサーバは、データ更新に伴い更新ログをスレーブサーバに転送する。ディスクベースのデータベースシステムと比べて、メモリ上に全てのデータを格納するメモリデータベースシステムは、高速にデータアクセスできる。その分、データ更新に伴う更新ログのネットワーク転送にかかる時間が、高速なトランザクションを行う上でネックとなる。このように、メモリデータベースシステムでは、ネットワーク転送時間をより短くするデータ転送方法が求められている。

また、一般に、信頼性のある通信を実現するために、ＴＣＰ（Transmission Control Protocol）が用いられる。ＴＣＰでは、スロースタートというアルゴリズムを用いた輻輳制御が行われる。なお、スロースタートについては、ＩＥＴＦ（Internet Engineering Task Force）によるＲＦＣ（Request for Comments）２００１（W. Stevens著、“TCP Slow Start，Congestion Avoidance，Fast Retransmit，and Fast Recovery Algorithms”、Jan 1997）に記載されている。また、輻輳制御については、ＲＦＣ２８６１（M. Handley、J. Padhye、S. Floyd著、“TCP Congestion Window Validation”、June 2000）に記載されている。スロースタートは、輻輳を防ぐために、少量ずつの通信からスタートして徐々に送信できるデータサイズ（輻輳ウィンドウサイズ）を増やしていくアルゴリズムである。この動作は、輻輳ウィンドウサイズが、受信側からアナウンスされたウィンドウサイズに到達するか、輻輳が発生するまで続く。輻輳が発生すると、再度スロースタートが開始する。

具体的には、このアルゴリズムは、輻輳ウィンドウサイズを超えるパケットの送信に対して送信先からＡＣＫが返却されると、輻輳ウィンドウサイズを拡大していく。そして、再送タイムアウト時間（ＲＴＯ：Retransmission Time Out、一般的に数百ミリ秒）の間、通信が発生しないと、輻輳ウィンドウサイズが縮小され、スロースタートが開始する。ここで、上述のメモリデータベースシステム等では、マスタサーバは、データ更新に応じて更新ログを転送するため、転送は断続的に行われる。そのため、転送の間隔がＲＴＯ時間以上になると、一旦拡大された輻輳ウィンドウサイズが縮小され、スロースタートが開始することになる。

しかし、上述のメモリデータベースシステム等では、例えば1ミリ秒未満の応答時間が要求される。このような情報処理システムにおいて更新ログの転送時にスロースタートが開始すると、通信に数十〜数百倍の時間がかかってしまう。その結果、更新ログの転送（レプリケーション）に要求される応答時間が満たされないという問題が発生する。

ここで、上述のようなメモリデータベースにおいて、マスタサーバおよびスレーブサーバは、同一構内（同一ラック内）に設置されることも多い。この場合、マスタサーバおよびスレーブサーバ間のレプリケーション通信の高速性を確保するため、レプリケーション専用にネットワークが用意されることも多い。このような場合、レプリケーション専用のネットワークでは、他の通信により輻輳が発生することを考慮する必要がない。そのため、スロースタートが働いてしまうことで、かえって応答速度が遅くなる場合もある。このように、スロースタートを用いた輻輳制御は、信頼性の高い専用ネットワークを用いる場合、不要であることが多い。

なお、オペレーティングシステム（ＯＳ）によっては、スロースタートを無効化する設定、または、ＲＴＯ時間や遅延ＡＣＫ間隔を任意の値に変更する設定が可能なものもある。そこで、レプリケーションの応答速度を高めるために、ＯＳで一律にスロースタートを無効にする、あるいは、ＲＴＯ時間や遅延ＡＣＫ間隔を変更するなどの設定をすることも考えられる。しかしながら、例えば、データ転送に関わるサーバが、レプリケーション専用のネットワークに加えて、通常のインターネットにも接続される場合がある。このようなサーバにおいて、ＯＳで一律に上述のような設定をすると、インターネット接続側の通信が輻輳により著しく性能劣化する可能性がある。したがって、ＯＳの設定により、特定のネットワーク接続において、断続的な通信によるスロースタートの開始に起因する通信速度の低下問題を解決することは難しい。

このような問題に対応する技術が、特許文献１に記載されている。この関連技術は、ＴＣＰコネクションの最近の使用時刻からの経過時間が、スロースタートモードへ遷移する経過時間となる前に、そのＴＣＰコネクションを通してＲＴＯ回避データを送信する。これにより、この関連技術は、断続的なデータ通信におけるスロースタートを回避している。

特開２００６−１００９１９号公報

しかしながら、特許文献１に記載された関連技術は、アプリケーションから送信要求されるデータのサイズが小さい場合、輻輳ウィンドウサイズの縮小を防ぐことができない場合がある。これは、スロースタートモードへ遷移する経過時間となる前にデータが送信されていても、そのデータが輻輳ウィンドウを満たさなかった場合、輻輳ウィンドウサイズが縮小されることがあるためである（前述のＲＦＣ２８６１参照）。また、特許文献１には、ＲＴＯ回避データのサイズについては記載されていない。したがって、この関連技術は、輻輳ウィンドウサイズが縮小されることを十分に防ぐことができない場合がある。

本発明は、上述の課題を解決するためになされたもので、断続的な通信において輻輳ウィンドウサイズの縮小をより十分に防ぐ技術を提供することを目的とする。

上記目的を達成するために、本発明の送信装置は、アプリケーションから送信を要求される対象データ、または、ダミーデータを受信装置に対して送信するデータ送信手段と、所定期間の間に、所定条件を満たすサイズの前記対象データが前記受信装置に対して送信されていない場合に、前記所定条件を満たすサイズの前記ダミーデータを送信するよう前記データ送信手段を制御するダミーデータ送信制御手段と、を備える。

また、本発明の受信装置は、上述の送信装置から前記対象データを受信すると該対象データに対する所定の処理を行うとともに、前記ダミーデータを受信すると該ダミーデータを破棄するデータ受信手段を備える。

また、本発明の情報処理システムは、上述の送信装置と、上述の受信装置と、を備える。

また、本発明のマスタサーバは、上述の送信装置と、マスタデータを記憶するマスタデータ記憶手段と、前記マスタデータを更新するとともに、前記マスタデータの更新前および更新後の差分を表す情報（更新ログ）を生成し、生成した更新ログを前記対象データとして送信するよう前記データ送信手段に要求するアプリケーション手段と、を備える。

また、本発明のスレーブサーバは、前記マスタデータの複製（複製データ）を記憶する複製データ記憶手段と、上述のマスタサーバから、前記対象データとしての前記更新ログ、または、前記ダミーデータを受信するとともに、受信した更新ログを用いて前記複製データを更新する処理を前記所定の処理として実行する上述の受信装置と、を備える。

また、本発明のデータベースシステムは、上述のマスタサーバと、上述のスレーブサーバと、を備える。

また、本発明のデータ転送方法は、アプリケーションから対象データの送信要求があると前記対象データを受信装置に対して送信し、所定期間の間に、所定条件を満たすサイズの前記対象データが前記受信装置に対して送信されていない場合に、前記所定条件を満たすサイズのダミーデータを前記受信装置に対して送信する。

また、本発明の記憶媒体は、アプリケーションから対象データの送信要求があると前記対象データを受信装置に対して送信する対象データ送信ステップと、所定期間の間に、所定条件を満たすサイズの前記対象データが前記受信装置に対して送信されていない場合に、前記所定条件を満たすサイズのダミーデータを前記受信装置に対して送信するダミーデータ送信ステップと、をコンピュータ装置に実行させるコンピュータ・プログラムを記憶している。

本発明は、断続的な通信における輻輳ウィンドウサイズの縮小をより十分に防ぐ技術を提供することができる。

本発明の第１の実施の形態としての情報処理システムの構成を示すブロック図である。 本発明の第１の実施の形態としての情報処理システムの機能ブロック図である。 本発明の第１の実施の形態としての情報処理システムのハードウェア構成図である。 本発明の第１の実施の形態におけるデータ送信部の動作を説明するフローチャートである。 本発明の第１の実施の形態におけるダミーデータ送信制御部の動作を説明するフローチャートである。 本発明の第１の実施の形態におけるデータ受信部の動作を説明するフローチャートである。 本発明の第２の実施の形態としてのメモリデータベースシステムの構成を示すブロック図である。 本発明の第２の実施の形態としてのメモリデータベースシステムの機能ブロック図である。 本発明の第２の実施の形態におけるアプリケーション部の動作を説明するフローチャートである。 本発明の第２の実施の形態におけるデータ送信部の動作を説明するフローチャートである。 本発明の第２の実施の形態におけるダミーデータ送信制御部の動作を説明するフローチャートである。 本発明の第２の実施の形態におけるデータ受信部の動作を説明するフローチャートである。 本発明の第３の実施の形態としてのメモリデータベースシステムの構成を示すブロック図である。 本発明の第３の実施の形態としてのメモリデータベースシステムの機能ブロック図である。 本発明の第３の実施の形態におけるデータ送信部の動作を説明するフローチャートである。 本発明の第３の実施の形態における所定期間算出部の動作を説明するフローチャートである。 本発明の第３の実施の形態における開始制御部の動作を説明するフローチャートである。 本発明の第３の実施の形態におけるダミーデータ送信制御部の動作を説明するフローチャートである。 本発明の第３の実施の形態の他の態様におけるメモリデータベースシステムの機能ブロック図である。 本発明の第３の実施の形態の他の態様におけるデータ送信部の動作を説明するフローチャートである。 本発明の第３の実施の形態の他の態様におけるダミーデータ送信制御部の動作を説明するフローチャートである。 本発明の第４の実施の形態としてのメモリデータベースシステムの機能ブロック図である。 本発明の第４の実施の形態におけるデータ送信部の動作を説明するフローチャートである。 本発明の第４の実施の形態におけるデータ受信部の動作を説明するフローチャートである。

以下、本発明の実施の形態について、図面を参照して詳細に説明する。

（第１の実施の形態）
本発明の第１の実施の形態としての情報処理システム１の構成を図１に示す。図１において、情報処理システム１は、送信装置１０と、受信装置５０とを含む。送信装置１０および受信装置５０は、ネットワークを介して通信可能に接続されている。

次に、情報処理システム１を構成する各装置の機能ブロックを図２に示す。図２において、送信装置１０は、データ送信部１１と、ダミーデータ送信制御部１２とを備える。また、受信装置５０は、データ受信部５１を備える。

ここで、送信装置１０および受信装置５０のハードウェア構成の一例を図３に示す。図３において、送信装置１０は、ＣＰＵ（Central Processing Unit）１００１と、ＲＡＭ（Random Access Memory）１００２と、ＲＯＭ（Read Only Memory）１００３と、ハードディスク等の記憶装置１００４と、ネットワークインタフェース１００５とを備えたコンピュータ装置によって構成可能である。また、受信装置５０は、ＣＰＵ５００１と、ＲＡＭ５００２と、ＲＯＭ５００３と、ハードディスク等の記憶装置５００４と、ネットワークインタフェース５００５とを備えたコンピュータ装置によって構成可能である。この場合、データ送信部１１は、ネットワークインタフェース１００５と、ＲＯＭ１００３および記憶装置１００４に記憶されたコンピュータ・プログラムおよび各種データをＲＡＭ１００２に読み込んで実行するＣＰＵ１００１とによって構成される。また、ダミーデータ送信制御部１２は、ＲＯＭ１００３および記憶装置１００４に記憶されたコンピュータ・プログラムおよび各種データをＲＡＭ１００２に読み込んで実行するＣＰＵ１００１によって構成される。また、データ受信部５１は、ネットワークインタフェース５００５と、ＲＯＭ５００３および記憶装置５００４に記憶されたコンピュータ・プログラムおよび各種データをＲＡＭ５００２に読み込んで実行するＣＰＵ５００１とによって構成される。なお、送信装置１０および受信装置５０、ならびに、各装置の各機能ブロックのハードウェア構成は、上述の構成に限定されない。

次に、送信装置１０の機能ブロックの詳細について説明する。

データ送信部１１は、対象データまたはダミーデータを受信装置５０に対して送信する。対象データは、受信装置５０に対して送信するよう、外部または自装置上のアプリケーション（図示せず）から要求されたデータである。具体的には、データ送信部１１は、送信要求元から対象データを受信すると、受信装置５０との間に確立された通信コネクションを通して、その対象データを送信する。

また、ダミーデータは、受信装置５０において破棄されるデータである。このため、ダミーデータは、どのような内容であってもよい。具体的には、データ送信部１１は、後述のダミーデータ送信制御部１２からの要求に応じて、受信装置５０に対して所定条件を満たすサイズのダミーデータを送信する。なお、所定条件とは、その時点での輻輳ウィンドウサイズ以上であることであってもよい。

ダミーデータ送信制御部１２は、所定期間の間に、受信装置５０に対して所定条件を満たすサイズの対象データが送信されていない場合に、所定条件を満たすサイズのダミーデータを送信するようデータ送信部１１を制御する。詳細には、ダミーデータ送信制御部１２は、受信装置５０との間に確立された通信コネクションにおいて、所定期間の間に、受信装置５０に対して所定条件を満たすサイズの対象データが送信されているか否かを判断する。そして、ダミーデータ送信制御部１２は、そのような対象データが所定期間に送信されていなければ、その通信コネクションを通して上述のダミーデータ送信制御を行う。

なお、所定条件とは、上述と同様に、その時点での輻輳ウィンドウサイズ以上であることであってもよい。つまり、ダミーデータ送信制御部１２は、所定期間の間に、その時点での輻輳ウィンドウサイズ以上の対象データが送信されなかった場合に、輻輳ウィンドウサイズ以上のダミーデータを送信するようデータ送信部１１に通知してもよい。

また、所定期間とは、輻輳ウィンドウサイズが縮小されることが規定された経過時間に基づく期間であってもよい。ここで、対象データを送信するための通信コネクションでは、送信装置１０から受信装置５０に対する最近の通信からの経過時間がこの規定された経過時間の長さに達すると、輻輳ウィンドウサイズが縮小される。したがって、例えば、ダミーデータ送信制御部１２は、その規定された経過時間の長さの１／２未満の期間を、所定期間として定めてもよい。そして、ダミーデータ送信制御部１２は、所定期間が経過する度に、その時点までの所定期間において所定条件を満たすサイズの対象データが送信されたか否かを判断するようにしてもよい。

次に、受信装置５０の機能ブロックの詳細について説明する。

データ受信部５１は、送信装置１０から対象データまたはダミーデータを受信する。そして、データ受信部５１は、受信した対象データに対する所定の処理を行う。所定の処理とは、例えば、記憶装置５００４へ保存する処理であってもよい。また、データ受信部５１は、受信したダミーデータを破棄する。

以上のように構成された情報処理システム１の動作について説明する。

まず、送信装置１０のデータ送信部１１の動作を図４に示す。

図４では、まず、データ送信部１１は、データの送信要求を受信する（ステップＳ１でＹｅｓ）。

ここで、受信した送信要求が、アプリケーションからの対象データの送信要求である場合（ステップＳ２で「対象データ」）、データ送信部１１は、対象データを受信装置５０に対して送信する（ステップＳ３）。

一方、ステップＳ１で受信した送信要求が、ダミーデータ送信制御部１２からのダミーデータの送信要求である場合（ステップＳ２で「ダミーデータ」）、データ送信部１１は、所定条件を満たすサイズのダミーデータを、受信装置５０に対して送信する（ステップＳ４）。そして、データ送信部１１の動作はステップＳ１に戻る。

以上で、送信装置１０のデータ送信部１１の動作の説明を終了する。

次に、送信装置１０のダミーデータ送信制御部１２の動作を図５に示す。

図５では、まず、ダミーデータ送信制御部１２は、この時点までの所定期間の間に、所定条件を満たすサイズの対象データがデータ送信部１１から送信されたか否かを判断する（ステップＳ１１）。

ここで、所定条件を満たすサイズの対象データが送信されていたと判断した場合、ダミーデータ送信制御部１２の動作はステップＳ１３に進む。

一方、所定条件を満たすサイズの対象データが送信されていなかったと判断した場合、ダミーデータ送信制御部１２は、所定条件を満たすサイズのダミーデータの送信を、データ送信部１１に要求する（ステップＳ１２）。

次に、ダミーデータ送信制御部１２は、所定期間として定められた時間だけ待機する（ステップＳ１３）。

そして、ダミーデータ送信制御部１２の動作はステップＳ１１に戻る。

以上で、送信装置１０のダミーデータ送信制御部１２の動作の説明を終了する。

次に、受信装置５０の動作を図６に示す。

図６では、まず、データ受信部５１は、送信装置１０からデータを受信する（ステップＳ２１でＹｅｓ）。

ここで、受信したデータが対象データである場合（ステップＳ２２で「対象データ」）、データ受信部５１は、この対象データに対する所定の処理を実行する（ステップＳ２３）。

一方、受信したデータがダミーデータである場合（ステップＳ２２で「ダミーデータ」）、データ受信部５１は、このダミーデータを破棄する（ステップＳ２４）。

そして、受信装置５０の動作はステップＳ２１に戻る。

以上で、受信装置５０の動作の説明を終了する。

次に、本発明の第１の実施の形態の効果について述べる。

本発明の第１の実施の形態としての情報処理システムは、断続的な通信における輻輳ウィンドウサイズの縮小をより十分に防ぐことができる。

その理由は、データ送信部が、アプリケーションから要求された対象データ、または、ダミーデータを受信装置に対して送信するからである。また、ダミーデータ送信制御部が、所定期間の間に、所定条件を満たすサイズの対象データが送信されていない場合に、所定条件を満たすサイズのダミーデータを、データ送信部を通して受信装置に送信するよう制御するからである。また、所定期間としては、対象データを送信するために確立された通信コネクションにおいて、輻輳ウィンドウサイズが縮小されることが規定された最近の通信からの経過時間に基づく期間が用いられるからである。

これにより、本実施の形態は、送信装置から受信装置への通信が断続的に発生する情報処理システムにおいて、長くても、所定期間の２倍未満の間隔で、所定条件を満たすサイズの対象データまたはダミーデータを送信することになる。したがって、本実施の形態は、輻輳ウィンドウサイズが所定条件を満たさなくなることを回避することができ、一度に送信することが可能なサイズが所定条件を満たすよう保つことができる。したがって、本実施の形態は、断続的な通信が行われる通信コネクションにおいて、輻輳ウィンドウサイズを所定条件を満たさないほど縮小させることがない。また、例えば、所定条件として、その時点での輻輳ウィンドウサイズ以上であることを適用すれば、本実施の形態は、いったん拡大した輻輳ウィンドウサイズをそれ以上縮小させないことになる。

（第２の実施の形態）
次に、本発明の第２の実施の形態について図面を参照して詳細に説明する。本実施の形態では、本発明の情報処理システムをメモリデータベースシステムに適用した例について説明する。なお、本実施の形態の説明において参照する各図面において、本発明の第１の実施の形態と同一の構成および同様に動作するステップには同一の符号を付して本実施の形態における詳細な説明を省略する。

まず、本発明の第２の実施の形態としてのメモリデータベースシステム２の構成を図７に示す。図７において、メモリデータベースシステム２は、本発明の送信装置を含むマスタサーバ２０と、本発明の受信装置を含むスレーブサーバ６０とを備える。マスタサーバ２０およびスレーブサーバ６０は、ネットワークを介して通信可能に接続されている。

次に、メモリデータベースシステム２を構成する各装置の機能ブロックを図８に示す。図８において、マスタサーバ２０は、データ送信部２１と、ダミーデータ送信制御部２２と、マスタデータ記憶部２３と、アプリケーション部２４とを備える。ここで、マスタサーバ２０は、図３を参照して説明した本発明の第１の実施の形態としての送信装置と同一のハードウェア要素を含むコンピュータ装置によって構成可能である。この場合、マスタデータ記憶部２３は、ＲＡＭ１００２によって構成される。また、アプリケーション部２４は、ＲＯＭ１００３および記憶装置１００４に記憶されたコンピュータ・プログラムおよび各種データをＲＡＭ１００２に読み込んで実行するＣＰＵ１００１によって構成される。

スレーブサーバ６０は、データ受信部６１と、複製データ記憶部６２とを備える。ここで、スレーブサーバ６０は、図３を参照して説明した本発明の第１の実施の形態としての受信装置と同一のハードウェア要素を含むコンピュータ装置によって構成可能である。この場合、複製データ記憶部６２は、ＲＡＭ５００２によって構成される。

次に、マスタサーバ２０の各機能ブロックの詳細について説明する。

マスタデータ記憶部２３は、マスタデータを記憶する。

アプリケーション部２４は、マスタデータを更新する。マスタデータの更新は、例えば、外部からの要求や、自装置における他の機能ブロック（図示せず）からの要求に応じて行われる。そして、アプリケーション部２４は、マスタデータの更新に応じて、その更新前および更新後の差分を表す情報（更新ログ）を生成する。また、アプリケーション部２４は、生成した更新ログを、スレーブサーバ６０に対して送信するよう、データ送信部２１に要求する。例えば、アプリケーション部２４は、コミット要求を発行後、更新ログを生成してその送信を要求するようにしてもよい。

データ送信部２１は、本発明の第１の実施の形態におけるデータ送信部１１と略同様に動作するよう構成される。ただし、本実施の形態では、対象データに、アプリケーション部２４から要求される更新ログを適用する。また、本実施の形態では、更新ログまたはダミーデータの送信先は、スレーブサーバ６０となる。

また、データ送信部２１は、ダミーデータ送信制御部２２による判断処理のために、送信済フラグを保持するようにしてもよい。この場合、データ送信部２１は、アプリケーション部２４から要求されて送信した更新ログが所定条件を満たす場合、送信済フラグをオンに設定して保持する。なお、本実施の形態では、所定条件として、サイズがｓ（ｓは正の数）以上であるという条件を適用するものとする。

ダミーデータ送信制御部２２は、所定期間の間に、サイズがｓ以上の更新ログが送信されたか否かに応じた処理を行う。ここで、所定期間とは、本発明の第１の実施の形態において説明した所定期間と同様の期間を適用するものとする。例えば、データ送信部２１によって送信済フラグが保持されている場合、ダミーデータ送信制御部２２は、次のように動作するよう構成される。

具体的には、ダミーデータ送信制御部２２は、所定期間が経過する毎に送信済フラグをチェックする。そして、ダミーデータ送信制御部２２は、送信済フラグがオフである場合に、サイズｓ以上のダミーデータを送信するようデータ送信部２１を制御する。また、ダミーデータ送信制御部２２は、送信済フラグがオンである場合に、送信済みフラグをオフに設定する。

次に、スレーブサーバ６０の各機能ブロックの詳細について説明する。

複製データ記憶部６２は、複製データを記憶する。複製データは、マスタサーバ２０に記憶されるマスタデータの複製である。

データ受信部６１は、本発明の第１の実施の形態におけるデータ受信部５１と略同様に動作するよう構成される。詳細には、データ受信部６１は、マスタサーバ２０から、対象データとしての更新ログ、または、ダミーデータを受信する。また、データ受信部６１は、更新ログを用いて、複製データ記憶部６２の複製データを更新する。また、データ受信部６１は、ダミーデータを破棄する。

以上のように構成されたメモリデータベースシステム２の動作について、図面を参照して説明する。

まず、マスタサーバ２０におけるアプリケーション部２４の動作を図９に示す。

図９では、まず、アプリケーション部２４は、マスタデータ記憶部２３のマスタデータを更新する（ステップＳ３１）。

次に、アプリケーション部２４は、更新前後のマスタデータの差分情報を更新ログとして生成する（ステップＳ３２）。

次に、アプリケーション部２４は、ステップＳ３２で生成した更新ログの送信を、データ送信部２１に対して要求する（ステップＳ３３）。

以上で、アプリケーション部２４の動作の説明を終了する。

次に、マスタサーバ２０におけるデータ送信部２１の動作を図１０に示す。なお、動作の開始時点では、送信済フラグはオフに設定されているものとする。

図１０では、まず、データ送信部２１は、ステップＳ１〜Ｓ３まで、本発明の第１の実施の形態におけるデータ送信部１１と略同様に動作する。ただし、本実施の形態では、対象データとして、アプリケーション部２４から送信要求された更新ログが適用される。

また、データ送信部２１は、ステップＳ３で更新ログをスレーブサーバ６０に対して送信後、送信した更新ログのサイズが、ｓ以上であるか否かを判断する（ステップＳ１３１）。

ここで、サイズがｓ以上であった場合、データ送信部２１は、送信済フラグをオンに設定して保持する（ステップＳ１３２）。そして、データ送信部２１の動作はステップＳ１に戻る。

一方、サイズがｓ未満であった場合、データ送信部２１の動作はステップＳ１に戻る。

また、ステップＳ１で受信した送信要求が、ダミーデータの送信要求であれば（ステップＳ２で「ダミーデータ」）、データ送信部２１は、サイズがｓ以上のダミーデータを、スレーブサーバ６０に対して送信する（ステップＳ１３３）。そして、データ送信部２１の動作はステップＳ１に戻る。

以上で、マスタサーバ２０のデータ送信部２１の動作の説明を終了する。

次に、マスタサーバ２０におけるダミーデータ送信制御部２２の動作を図１１に示す。

図１１では、まず、ダミーデータ送信制御部２２は、送信済フラグの内容をチェックし、オンであるか否かを判断する（ステップＳ１４１）。

ここで、送信済フラグがオンである場合、ダミーデータ送信制御部２２は、送信済フラグをオフに設定（リセット）する（ステップＳ１４２）。

一方、送信済フラグがオフである場合、ダミーデータ送信制御部２２は、本発明の第１の実施の形態と同様にステップＳ１２を実行し、ダミーデータの送信を、データ送信部２１に要求する（ステップＳ１２）。ただし、本実施の形態では、ダミーデータ送信制御部２２は、サイズがｓ以上のダミーデータの送信を要求する。

次に、ダミーデータ送信制御部２２は、所定期間だけ待機する（ステップＳ１３）。

そして、ダミーデータ送信制御部２２の動作はステップＳ１４１に戻る。

以上で、マスタサーバ２０のダミーデータ送信制御部２２の動作の説明を終了する。

次に、スレーブサーバ６０の動作を図１２に示す。

図１２では、まず、データ受信部６１は、マスタサーバ２０からデータを受信する（ステップＳ４１でＹｅｓ）。

ここで、受信したデータが更新ログである場合（ステップＳ４２で「更新ログ」）、データ受信部６１は、その更新ログを用いて、複製データ記憶部６２の複製データを更新する（ステップＳ４３）。

一方、受信したデータがダミーデータである場合（ステップＳ４２で「ダミーデータ」）、データ受信部６１は、このダミーデータを破棄する（ステップＳ４４）。

そして、データ受信部６１の動作はステップＳ４１に戻る。

以上で、データ受信部６１の動作の説明を終了する。

次に、本発明の第２の実施の形態の効果について述べる。

本発明の第２の実施の形態としてのメモリデータベースシステムは、マスタサーバからスレーブサーバに対して断続的に更新ログの転送が行われる場合であっても、輻輳ウィンドウサイズが所定サイズ以下になることを十分に防ぐことができる。

その理由は、データ送信部が、所定のサイズｓ以上の更新ログをスレーブサーバに送信したときに送信済フラグをオンに設定し、ダミーデータ送信制御部が、所定期間が経過する度に送信済フラグをチェックするからである。そして、ダミーデータ送信制御部が、送信済フラグがオンであればオフにリセットし、送信済フラグがオフであれば、サイズがｓ以上のダミーデータを、データ送信部を通してスレーブサーバに送信するよう制御するからである。また、所定期間として、更新ログを送信する通信コネクションにおいてマスタサーバからスレーブサーバへの最近の通信からの経過時間について、輻輳ウィンドウサイズを縮小するよう定められた長さに基づく期間が用いられるからである。

これにより、本実施の形態は、マスタサーバおよびスレーブサーバ間で更新ログ転送による通信が発生していない間も、長くても、所定期間として定められた時間の２倍未満の間隔で、サイズｓ以上のダミーデータを送信することになる。したがって、本実施の形態は、輻輳ウィンドウサイズがｓ以下になる状態を回避することができる。したがって、本実施の形態は、ある期間マスタサーバからの更新ログの転送がなかった後にスレーブサーバに更新ログを転送する場合であっても、通信速度を極端に低下させない。その結果、本実施の形態は、高可用性および高速なレスポンスが同時に求められるようなオンライントランザクションシステムを構成するメモリデータベースシステムにおいて、常に高速なレプリケーション処理を行うことができる。

（第３の実施の形態）
次に、本発明の第３の実施の形態について図面を参照して詳細に説明する。本実施の形態では、本発明の第２の実施の形態と同様に、本発明の情報処理システムをメモリデータベースシステムに適用した例について説明する。なお、本実施の形態の説明において参照する各図面において、本発明の第１および第２の実施の形態と同一の構成および同様に動作するステップには同一の符号を付して本実施の形態における詳細な説明を省略する。

まず、本発明の第３の実施の形態としてのメモリデータベースシステム３の構成を図１３に示す。図１３において、メモリデータベースシステム３は、マスタサーバ３０と、ｎ（ｎは１以上の整数）個のスレーブサーバ６０（６０＿１〜６０＿ｎ）とを備える。マスタサーバ３０および各スレーブサーバ６０は、それぞれネットワークを介して通信可能に接続されている。

次に、メモリデータベースシステム３を構成する各装置の機能ブロックを図１４に示す。図１４において、マスタサーバ３０は、本発明の第２の実施の形態としてのマスタサーバ２０に対して、データ送信部２１に替えてｎ個のデータ送信部３１（３１＿１〜３１＿ｎ）と、ダミーデータ送信制御部２２に替えてｎ個のダミーデータ送信制御部３２（３２＿１〜３２＿ｎ）と、所定期間算出部３５と、開始制御部３６とを備える点が異なる。なお、所定期間算出部３５および開始制御部３６は、本発明のダミーデータ送信制御部の一部分の一実施形態を構成する。ここで、マスタサーバ３０は、図３を参照して説明した本発明の第１の実施の形態としての送信装置と同一のハードウェア要素を含むコンピュータ装置によって構成可能である。この場合、所定期間算出部３５および開始制御部３６は、ＲＯＭ１００３および記憶装置１００４に記憶されたコンピュータ・プログラムおよび各種データをＲＡＭ１００２に読み込んで実行するＣＰＵ１００１によって構成される。

ｎ個のスレーブサーバ６０のそれぞれは、本発明の第２の実施の形態におけるスレーブサーバ６０と同様に構成される。

次に、マスタサーバ３０の各機能ブロックの詳細について説明する。

データ送信部３１＿ｉ（ｉ＝１〜ｎ）は、スレーブサーバ６０＿ｉに対応付けられる。また、データ送信部３１＿ｉは、対応するスレーブサーバ６０＿ｉに対して、更新ログまたはダミーデータを送信する。具体的には、データ送信部３１＿ｉは、対応するスレーブサーバ６０＿ｉとの間でＴＣＰコネクションを保持して通信を行う。また、データ送信部３１＿ｉは、対応するスレーブサーバ６０＿ｉに関する送信済フラグを保持する。つまり、マスタサーバ３０において、ｎ個の送信済フラグがスレーブサーバ６０＿ｉ毎に保持されることになる。

詳細には、データ送信部３１＿ｉは、更新ログの送信要求をアプリケーション部２４から受信すると、対応するスレーブサーバ６０＿ｉに対して更新ログを、ＴＣＰコネクションを通して送信する。このとき、データ送信部３１＿ｉは、送信した更新ログのサイズがｓ以上であれば、対応するスレーブサーバ６０＿ｉに関する送信済フラグをオンに設定して保持する。

ここで、サイズsは、次式（１）で算出される値であってもよい。

ｓ ＝ ２ × ＭＳＳ・・・（１）
なお、ＭＳＳ（Maximum Segment Size）は、ＴＣＰにおいて１セグメントで転送可能なデータの最大サイズを表し、次式（２）で算出される。

ＭＳＳ ＝ ＭＴＵ − ４０・・・（２）
ここで、ＭＴＵ（Maximum Transmission Unit）とは、１回の転送で送信できるデータの最大サイズを示す。ＭＳＳは、ＭＴＵから、ＩＰ（Internet Protocol）ヘッダ２０バイトおよびＴＣＰヘッダ２０バイトを除いた値として計算される。そこで、データ送信部３１＿ｉは、サイズsを、システムから取得可能なＭＴＵの値を基に式（１）にしたがって算出すればよい。また、データ送信部３１＿ｉは、上述の式（１）を用いてサイズｓの値を算出する代わりに、ユーザによって設定されたｓの値を取得するようにしてもよい。この場合、ｓの値は、式（１）を満たすように設定されることが望ましい。

また、データ送信部３１＿ｉは、後述のダミーデータ送信制御部３２＿ｉからの要求に応じて、スレーブサーバ６０＿ｉに対してサイズｓ以上のダミーデータを送信する。

所定期間算出部３５は、所定期間ｔを、次式（３）を用いて決定し、ダミーデータ送信制御部３２＿１〜３２＿ｎにそれぞれ通知する。通知される所定期間ｔは、各ダミーデータ送信制御部３２＿ｉによって、送信済フラグをチェックする間隔として用いられる。

ｔ ＝ ＲＴＯ × α （０＜α＜０．５）・・・（３）
ここで、ＲＴＯは、ＴＣＰ通信における再送タイムアウト時間を表す。ＴＣＰでは、ＲＴＯ時間以上の間通信が発生していないと、次の通信ではスロースタートが開始する。そこで、所定期間算出部３５は、所定期間ｔを、ＯＳ（Operating System）から取得可能なＲＴＯ時間の値を基に式（３）にしたがって算出すればよい。なお、ＯＳによっては、ＲＴＯ時間の値がネットワークの負荷状況に応じて変化するものがある。このような場合、所定期間算出部３５は、任意のタイミング毎にＲＴＯ時間の値を再取得し、所定期間ｔを再度算出してもよい。また、所定期間算出部３５は、上述の式（３）を用いて所定期間ｔの値を算出する代わりに、ユーザにより設定されたｔの値を取得してもよい。この場合、ｔの値は、式（３）を満たすように設定されることが望ましい。

開始制御部３６は、ダミーデータ送信制御部３２＿１〜３２＿ｎを、それぞれ異なるタイミングで起動する。具体的には、例えば、開始制御部３６は、次式（４）に基づき算出した起動間隔Ｔ毎に、ダミーデータ送信制御部３２＿１〜３２＿ｎを順次起動してもよい。

Ｔ ＝ ｔ ÷ ｎ・・・（４）
これにより、ｎ個のダミーデータ送信制御部３２＿ｉは、開始制御部３６によって順次起動され、互いに異なるタイミングで所定期間ｔ毎に送信済フラグの内容に応じた処理を実行する。具体的には、ダミーデータ送信制御部３２＿ｉは、起動された後、所定期間ｔ毎に、対応するスレーブサーバ６０＿ｉに関する送信済フラグをチェックする。そして、ダミーデータ送信制御部３２＿ｉは、該当する送信済フラグがオフである場合に、サイズｓ以上のダミーデータをスレーブサーバ６０＿ｉに対して送信するよう、データ送信部３１＿ｉを制御する。また、ダミーデータ送信制御部３２＿ｉは、該当する送信済フラグがオンである場合に、その送信済フラグをオフに設定する。

以上のように構成されたメモリデータベースシステム３の動作について、図面を参照して説明する。

まず、マスタサーバ３０におけるアプリケーション部２４の動作について説明する。アプリケーション部２４の動作は、図９を参照して説明した本発明の第２の実施の形態におけるアプリケーション部２４の動作と略同様である。ただし、本実施の形態では、ステップＳ３３において、アプリケーション部２４は、データ送信部３１＿１〜３１＿ｎに対して、それぞれ更新ログの送信を要求する。

次に、マスタサーバ３０におけるデータ送信部３１＿ｉの動作を図１５に示す。なお、動作の開始時点では、それぞれのスレーブサーバ６０＿ｉに関する送信済フラグはオフに設定されているものとする。また、データ送信部３１＿ｉは、上述の式（１）に基づき所定のサイズｓの値を算出済みであるものとする。

図１５では、まず、データ送信部３１＿ｉは、データの送信要求を受信する（ステップＳ５１でＹｅｓ）。

次に、データ送信部３１＿ｉは、受信した送信要求が、アプリケーション部２４からの更新ログの送信要求であれば（ステップＳ５２で「更新ログ」）、更新ログを、スレーブサーバ６０＿ｉに対して送信する（ステップＳ５３）。

次に、データ送信部３１＿ｉは、ステップＳ５３で送信した更新ログのサイズが、ｓ以上であるか否かを判断する（ステップＳ５４）。

ここで、サイズがｓ以上であった場合、データ送信部３１＿ｉは、スレーブサーバ６０＿ｉに関する送信済フラグをオンに設定して保持する（ステップＳ５５）。そして、データ送信部３１＿ｉの動作はステップＳ５１に戻る。

一方、サイズがｓ未満であった場合、データ送信部３１＿ｉの動作はステップＳ５１に戻る。

また、ステップＳ５１で受信した送信要求が、ダミーデータの送信要求であれば（ステップＳ５２で「ダミーデータ」）、データ送信部３１＿ｉは、サイズがｓ以上のダミーデータを、対応するスレーブサーバ６０＿ｉに対して送信する（ステップＳ５６）。そして、データ送信部３１＿ｉの動作はステップＳ５１に戻る。

以上で、データ送信部３１＿ｉの動作の説明を終了する。

次に、マスタサーバ３０における所定期間算出部３５の動作を図１６に示す。例えば、所定期間算出部３５は、この動作を、システム起動時等に行ってもよい。また、前述のように、ＲＴＯ時間がネットワークの負荷状況に応じて変化するシステムの場合、所定期間算出部３５は、この動作を、任意のタイミング毎に繰り返し実行してもよい。

図１６では、所定期間算出部３５は、ＯＳからＲＴＯ時間を取得する（ステップＳ６１）。

次に、所定期間算出部３５は、式（３）を用いて所定期間ｔを算出する（ステップＳ６２）。

次に、所定期間算出部３５は、ステップＳ６２で算出したｔの値を、ｎ個のダミーデータ送信制御部３２＿ｉにそれぞれ通知する（ステップＳ６３）。

以上で、所定期間算出部３５の動作の説明を終了する。

次に、マスタサーバ３０における開始制御部３６の動作を図１７に示す。なお、開始制御部３６は、上述の式（４）を用いて、既に起動間隔Ｔを算出済みであるものとする。

図１７では、まず、開始制御部３６は、スレーブサーバ番号ｉを1に初期化する（ステップＳ７１）。

次に、開始制御部３６は、起動間隔Ｔだけ待機する（ステップＳ７２）。

次に、開始制御部３６は、ｉ番目のダミーデータ送信制御部３２＿ｉを起動する（ステップＳ７３）。

次に、開始制御部３６は、ｉがスレーブサーバ６０の個数ｎより小さければ（ステップＳ７４でＹｅｓ）、ｉに１を加算し（ステップＳ７５）、ステップＳ７２からの動作を繰り返す。

一方、ｉがｎ以上になった場合（ステップＳ７４でＮｏ）、開始制御部３６は、動作を終了する。

以上で、開始制御部３６の動作の説明を終了する。

次に、マスタサーバ３０におけるダミーデータ送信制御部３２＿ｉの動作を図１８に示す。なお、ダミーデータ送信制御部３２＿ｉは、所定期間算出部３５から、所定期間ｔを既に通知されているものとする。また、ダミーデータ送信制御部３２＿ｉは、開始制御部３６によって起動されると、以下の動作を開始するものとする。

図１８では、まず、ダミーデータ送信制御部３２＿ｉは、対応するスレーブサーバ６０＿ｉに関する送信済フラグの内容をチェックする（ステップＳ８１）。

ここで、送信済フラグがオンである場合、ダミーデータ送信制御部３２＿ｉは、送信済フラグをオフに設定（リセット）する（ステップＳ８２）。

一方、送信済フラグがオフである場合、ダミーデータ送信制御部３２＿ｉは、サイズがｓ以上のダミーデータをスレーブサーバ６０＿ｉに送信するよう、データ送信部３１＿ｉに要求する（ステップＳ８３）。

次に、ダミーデータ送信制御部３２＿ｉは、所定期間ｔだけ待機する（ステップＳ８４）。

そして、ダミーデータ送信制御部３２＿ｉの動作はステップＳ８１に戻る。

以上で、ダミーデータ送信制御部３２＿ｉの動作の説明を終了する。

なお、ｎ個のスレーブサーバ６０＿１〜６０＿ｎのそれぞれの動作については、図１２を参照して説明した本発明の第２の実施の形態におけるスレーブサーバ６０の動作と同様であるため、本実施の形態における説明を省略する。

次に、本発明の第３の実施の形態の効果について述べる。

本発明の第３の実施の形態としてのメモリデータベースシステムは、マスタサーバからスレーブサーバに対して断続的に更新ログの転送が行われる場合であっても、輻輳ウィンドウサイズが所定サイズ以下になることをさらに十分に防ぐことができる。

その理由は、データ送信部が、所定のサイズｓ以上の更新ログをスレーブサーバに送信したときに送信済フラグをオンに設定するからである。また、ダミーデータ送信制御部が、ＲＴＯ時間にα（０＜α＜０．５）を乗じて求められる所定期間ｔ毎に送信済フラグをチェックするからである。そして、ダミーデータ送信制御部が、送信済フラグがオンであればオフにリセットし、送信済フラグがオフであれば、サイズがｓ以上のダミーデータを、データ送信部を通してスレーブサーバに送信するよう制御するからである。

これにより、本実施の形態は、更新ログ転送による通信が発生していない間も、サイズｓ以上のダミーデータを、長くてもＲＴＯ時間以内に送信することができる。したがって、本実施の形態は、スロースタートを開始させてしまうことなく、輻輳ウィンドウサイズをｓ以上に保つ。このように、本実施の形態は、一旦拡大した輻輳ウィンドウサイズが所定のサイズｓ以下に縮小することを防ぐことにより、スロースタートを回避することができる。したがって、本実施の形態は、ある期間更新ログの転送がなかった後にスレーブサーバに更新ログを転送する場合であっても、通信遅延を解消することが可能である。このように、本実施の形態は、高可用性および高速なレスポンスが同時に求められるようなオンライントランザクションシステムを構成するメモリデータベースシステムにおいて、常に高速なレプリケーション処理を行うことができる。

さらに、本発明の第３の実施の形態としてのメモリデータベースシステムは、マスタサーバからスレーブサーバに対する更新ログの転送において、遅延ＡＣＫを発生させることがなく、より高速なデータ転送を可能とする。

その理由は、データ送信部が、ダミーデータのサイズをｓ以上とし、ｓの値に、ＴＣＰにおいて１セグメントで転送可能なデータの最大サイズ（ＭＳＳ）の２倍を適用するからである。ここで、ＴＣＰでは、受信側は、サイズがＭＳＳのセグメントを２つ受信すると即座にＡＣＫを返す。したがって、本実施の形態は、輻輳ウィンドウサイズをＭＳＳの２倍以上に保つことにより、遅延ＡＣＫにより発生する通信遅延を抑えることができる。

また、本発明の第３の実施の形態としてのメモリデータベースシステムは、レプリケーション実行中におけるダミーデータの無用な転送による帯域の圧迫を避けることができる。

その理由は、データ転送部が、サイズｓ以上の更新ログを送信した場合には送信済フラグをオンにし、ダミーデータ転送制御部が、送信済フラグがオンであればオフにリセットしてダミーデータの送信を行わないからである。

これにより、本実施の形態は、前回の通信からＲＴＯ時間内に既にサイズｓ以上の更新ログの転送が行われていればダミーデータの送信を省略することができる。したがって、本実施の形態は、レプリケーション実行中に無用なダミーデータを転送することがない。

また、本発明の第３の実施の形態としてのメモリデータベースシステムは、複数のスレーブサーバに対するダミーデータの転送によりＣＰＵの負荷およびネットワーク負荷を一時的に高騰させることがない。

その理由は、データ送信部が、複数のスレーブサーバに対してそれぞれ異なるコネクションを介して更新ログまたはダミーデータを送信し、送信済みフラグをスレーブサーバ毎に保持するからである。また、ダミーデータ送信制御部が、各スレーブサーバに関して送信済フラグの値に応じた処理を、スレーブサーバ毎に異なるタイミングで所定期間ｔ毎に実行するからである。例えば、起動制御部が、所定期間ｔをスレーブサーバ数ｎで除した起動間隔Ｔ毎に、ｎ個のダミーデータ送信制御部を順次起動していくからである。

これにより、本実施の形態は、複数のスレーブサーバに対するダミーデータの送信タイミングを分散させることができ、ＣＰＵの負荷およびネットワークの負荷を平準化する。その結果、本実施の形態は、ダミーデータの送信によるアプリケーション部またはその他重要プロセスの動作への影響を抑えることができる。

（第３の実施の形態の他の態様）
次に、本発明の第３の実施の形態の他の態様について説明する。

メモリデータベースシステム３は、図１９に示すように、マスタサーバ３０において、ｎ個のデータ送信部３１＿ｉの代わりに１つのデータ送信部３１を有し、開始制御部３６を省略するように構成することも可能である。

この場合、データ送信部３１は、図１５に示した動作の代わりに、図２０に示すよう動作する。

図２０では、まず、データ送信部３１は、データの送信要求を受信する（ステップＳ５１でＹｅｓ）。

次に、データ送信部３１は、受信した送信要求が、アプリケーション部２４からの更新ログの送信要求であれば（ステップＳ５２で「更新ログ」）、更新ログを、スレーブサーバ６０＿１〜６０＿ｎに対してそれぞれ送信する（ステップＳ９３）。

次に、データ送信部３１は、ステップＳ９３で送信した更新ログのサイズが、ｓ以上であった場合（ステップＳ５４でＹｅｓ）、スレーブサーバ６０＿１〜６０＿ｎに関するｎ個の送信済フラグをそれぞれオンに設定して保持する（ステップＳ９５）。そして、データ送信部３１の動作はステップＳ５１に戻る。

一方、サイズがｓ未満であった場合、データ送信部３１の動作はステップＳ５１に戻る。

また、ステップＳ５１で受信した送信要求が、いずれかのスレーブサーバ６０に対するダミーデータの送信要求であれば（ステップＳ５２で「ダミーデータ」）、データ送信部３１は、サイズがｓ以上のダミーデータを、対象のスレーブサーバ６０に対して送信する（ステップＳ９６）。そして、データ送信部３１の動作はステップＳ５１に戻る。

また、この場合、ダミーデータ送信制御部３２＿ｉは、図１８に示した動作の代わりに、図２１に示すように動作する。

図２１では、まず、ダミーデータ送信制御部３２＿ｉは、所定期間算出部３５から所定期間tを通知されると、次式（５）で算出される起動待機時間Ｔ１だけ動作開始を待つ（ステップＳ１０１）。

Ｔ１ ＝ ｛（ｉ − １） ÷ ｎ ｝ × ｔ・・・（５）
ここで、ｉは、何番目のダミーデータ送信制御部３２であるかを表す番号である。また、ｎは、スレーブサーバ６０の個数である。また、ｔは、所定期間算出部３５から通知された所定期間である。

以降、ダミーデータ送信制御部３２＿ｉは、ステップＳ８１〜ステップＳ８４まで図１８を用いて説明したように動作し、ステップＳ８１の動作から繰り返す。

これにより、マスタサーバ３０は、開始制御部３６を省略した構成でも、各ダミーデータ送信制御部３２＿ｉによるダミーデータの送信タイミングを分散させることができる。

このように構成することにより、本発明の第３の実施の形態の他の態様は、データ送信部、ダミーデータ送信制御部、開始制御部を各々スレッドで構成することを想定した場合に、スレッドの種類および数を削減でき、ＣＰＵ負荷をより小さくすることができる。

（第４の実施の形態）
次に、本発明の第４の実施の形態について図面を参照して詳細に説明する。本実施の形態では、本発明の第２および第３の実施の形態と同様に、本発明の情報処理システムをメモリデータベースシステムに適用した例について説明する。なお、本実施の形態の説明において参照する各図面において、本発明の第１〜第３の実施の形態と同一の構成および同様に動作するステップには同一の符号を付して本実施の形態における詳細な説明を省略する。

まず、本発明の第４の実施の形態としてのメモリデータベースシステム４の構成を図２２に示す。図２２において、メモリデータベースシステム４は、本発明の第３の実施の形態としてのメモリデータベースシステム３に対して、マスタサーバ３０に替えてマスタサーバ４０と、ｎ個のスレーブサーバ６０に替えてｎ個のスレーブサーバ７０（７０＿１〜７０＿ｎ）とを備える点が異なる。また、マスタサーバ４０は、本発明の第３の実施の形態におけるマスタサーバ３０に対して、ｎ個のデータ送信部３１＿ｉに替えてｎ個のデータ送信部４１＿ｉを備える点が異なる。また、スレーブサーバ７０のそれぞれは、本発明の第２および第３の実施の形態におけるスレーブサーバ６０に対して、データ受信部６１に替えてデータ受信部７１を備える点が異なる。

マスタサーバ４０のデータ送信部４１＿ｉは、本発明の第３の実施の形態におけるデータ送信部３１＿ｉに対して、更新ログの送信要求およびダミーデータの送信要求を略同時に受けた場合の処理が異なる。具体的には、これらの送信要求を略同時に受けた場合、データ送信部４１＿ｉは、更新ログのサイズがｓ以上であれば、この更新ログをスレーブサーバ７０＿ｉに送信し、ダミーデータの送信を省略する。また、これらの送信要求を略同時に受けた場合、データ送信部４１＿ｉは、更新ログのサイズがｓ未満であれば、この更新ログにダミーデータを付加してサイズｓ以上にしてから、スレーブサーバ７０＿ｉに対して送信する。

なお、更新ログの送信要求およびダミーデータの送信要求を略同時に受けるとは、例えば、データ送信部４１＿ｉが、更新ログの送信要求を受けた後、更新ログの送信処理を開始する前に、ダミーデータの送信要求を受けた場合であってもよい。また、更新ログの送信要求およびダミーデータの送信要求を略同時に受けるとは、例えば、データ送信部４１＿ｉが、ダミーデータの送信要求を受けた後、ダミーデータの送信処理を開始する前に、更新ログの送信要求を受けた場合であってもよい。

なお、更新ログの送信要求およびダミーデータの送信要求を異なるタイミングで受けた場合には、データ送信部４１＿ｉは、本発明の第３の実施の形態におけるデータ送信部３１＿ｉと同様に動作するよう構成される。

スレーブサーバ７０のデータ受信部７１は、マスタサーバ４０から、ダミーデータが付加された更新ログを受信すると、ダミーデータの部分を破棄して残りの更新ログを得る。そして、データ受信部７１は、得られた更新ログを用いて、複製データ記憶部６２に記憶された複製データの更新を行う。

なお、ダミーデータが付加されていない更新ログを受信した場合、および、ダミーデータのみを受信した場合には、データ受信部７１は、本発明の第２および第３の実施の形態におけるデータ受信部６１と同様に動作するよう構成される。

以上のように構成されたメモリデータベースシステム４の動作について説明する。メモリデータベースシステム４の動作は、本発明の第３の実施の形態としてのメモリデータベースシステム３の動作と略同様である。ただし、マスタサーバ４０におけるデータ送信部４１＿ｉの動作およびスレーブサーバ７０におけるデータ受信部７１の動作の詳細が異なる。

まず、データ送信部４１＿ｉの動作を図２３に示す。

図２３において、まず、データ送信部４１＿ｉは、データの送信要求を受信する（ステップＳ１１１でＹｅｓ）。

次に、データ送信部４１＿ｉは、ステップＳ１１１で受信した送信要求が、アプリケーション部２４からの更新ログの送信要求であるか、ダミーデータの送信要求であるかを判断する（ステップＳ１１２）。

ここで、更新ログの送信要求であれば（ステップＳ１１２で「更新ログ」）、データ送信部４１＿ｉは、略同時にダミーデータの送信要求を受信しているか否かを判断する（ステップＳ１１３）。例えば、前述のように、データ送信部４１＿ｉは、この時点で、まだ処理を開始していないダミーデータの送信要求を既に受信していれば、略同時にダミーデータの送信要求を受信していると判断してもよい。

一方、ダミーデータの送信要求であれば（ステップＳ１１２で「ダミーデータ」）、データ送信部４１＿ｉは、略同時に更新ログの送信要求を受信しているか否かを判断する（ステップＳ１１４）。例えば、前述のように、データ送信部４１＿ｉは、この時点で、まだ処理を開始していない更新ログの送信要求を既に受信していれば、略同時に更新ログの送信要求を受信していると判断してもよい。

ステップＳ１１３またはステップＳ１１４において、更新ログの送信要求およびダミーデータの送信要求を略同時に受信していると判断した場合、データ送信部４１＿ｉは、更新ログのサイズがｓ以上であるか否かを判断する（ステップＳ１１５）。

ここで、更新ログのサイズがs未満である場合（ステップＳ１１５でＮｏ）、データ送信部４１＿ｉは、全体のサイズがｓ以上になるよう更新ログにダミーデータを付加する（ステップＳ１１６）。

一方、更新ログのサイズがｓ以上であれば（ステップＳ１１５でＹｅｓ）、データ送信部４１＿ｉの動作は、ステップＳ１１７に進む。

次に、データ送信部４１＿ｉは、更新ログをスレーブサーバ７０＿ｉに対して送信する（ステップＳ１１７）。ここで送信される更新ログは、ステップＳ１１６でダミーデータが付加された更新ログ、または、ステップＳ１１５でサイズがｓ以上あると判断された更新ログである。これにより、更新ログの送信要求およびダミーデータの送信要求を略同時に受信した場合に更新ログのサイズがｓ以上であれば、データ送信部４１＿ｉは、ダミーデータの送信を省略することになる。

次に、データ送信部４１＿ｉは、このスレーブサーバ７０＿ｉに関する送信済フラグをオンに設定して保持する（ステップＳ１１８）。

一方、ステップＳ１１２で更新ログの送信要求を受信したと判断され、ステップＳ１１３で略同時にダミーデータの送信要求を受信していないと判断された場合について説明する。この場合、データ送信部４１＿ｉは、ステップＳ５３〜Ｓ５５まで、本発明の第３の実施の形態におけるデータ送信部３１＿ｉと同様に動作する。

また、ステップＳ１１２でダミーデータの送信要求を受信したと判断され、ステップＳ１１４で略同時に更新ログの送信要求を受信していないと判断された場合について説明する。この場合、データ送信部４１＿ｉは、ステップＳ５６を、本発明の第３の実施の形態におけるデータ送信部３１＿ｉと同様に実行する。

そして、データ送信部４１＿ｉの動作はステップＳ１１１に戻る。

以上で、データ送信部４１＿ｉの動作の説明を終了する。

次に、ｎ個のスレーブサーバ７０のそれぞれにおけるデータ受信部７１の動作を図２４に示す。

図２４では、まず、データ受信部７１は、マスタサーバ４０からデータを受信する（ステップＳ４１でＹｅｓ）。

次に、データ受信部７１は、受信したデータが更新ログである場合（ステップＳ４２で「更新ログ」）、その更新ログに、ダミーデータが付加されているか否かを判断する（ステップＳ１２３）。

ここで、ダミーデータが付加されている場合、データ受信部７１は、ダミーデータの部分を分離して破棄する（ステップＳ１２４）。

そして、データ受信部７１は、更新ログを用いて、複製データ記憶部６２の複製データを更新する（ステップＳ４３）。

一方、ステップＳ１２３において、ダミーデータが付加されていないと判断した場合、データ受信部７１は、ステップＳ４１で受信した更新ログを用いて、ステップＳ４３を実行する。

また、受信したデータがダミーデータである場合（ステップＳ４２で「ダミーデータ」）、データ受信部７１は、このダミーデータを破棄する（ステップＳ４４）。

そして、データ受信部７１の動作はステップＳ４１に戻る。

以上で、データ受信部７１の動作の説明を終了する。

次に、本発明の第４の実施の形態の効果について述べる。

本発明の第４の実施の形態としてのメモリデータベースシステムは、マスタサーバからスレーブサーバに対して断続的に更新ログの転送が行われる際に、より効率よく輻輳ウィンドウサイズの縮小を防ぐことができる。

その理由は、マスタサーバのデータ送信部が、更新ログの送信要求およびダミーデータの送信要求を略同時に受けた場合に、次のように動作するからである。すなわち、この場合、データ送信部は、更新ログのサイズがｓ以上であれば、スレーブサーバに対してダミーデータの送信を省略して更新ログを送信する。また、データ送信部は、更新ログのサイズがｓ未満であれば、サイズがｓ以上になるよう更新ログにダミーデータを付加してスレーブサーバに対して送信するからである。これにより、本実施の形態は、本発明の第２または第３の実施の形態に対して、送信するダミーデータの量を減らしながら同様の効果を奏することができる。したがって、本実施の形態は、ＣＰＵ負荷およびネットワーク負荷をより小さくすることができ、より効率的に通信速度の低下を防止する。

なお、上述した本発明の第２から第４の実施の形態において、本発明の情報処理しシステムをメモリデータベースシステムに適用した例を中心に説明した。この他、各実施の形態は、マスタサーバおよびスレーブサーバ間でレプリケーションを行うその他のデータベースシステムにも適用可能である。

また、上述した本発明の第２から第４の実施の形態において、ダミーデータのサイズまたはダミーデータが付加された更新ログのサイズをｓ（ＭＳＳの２倍）以上とする例を中心に記載した。ただし、各実施の形態において、これらのサイズはｓにより近い値（さらには、ｓに等しい値）であることが望ましい。これにより、各実施の形態は、不必要に大きなサイズのダミーデータを送信することによるＣＰＵの負荷およびネットワークの負荷を高くすることがない。

また、上述した本発明の第２から第４の実施の形態において、所定条件として、ｓ（ＭＳＳの２倍）以上であるという条件を適用する例を中心に説明した。なお、ここでいう所定条件は、送信済フラグをオンにするためにチェックする更新ログのサイズに関する所定条件、および、ダミーデータまたはダミーデータが付加された更新ログのサイズが満たすべき所定条件である。この他、各実施の形態において、所定条件は、その時点での輻輳ウィンドウサイズ以上であることであってもよい。その他、各実施の形態において、所定条件は、輻輳ウィンドウサイズの縮小をより十分に防止するためのデータサイズとして算出されるその他の値に基づく条件であってもよい。

また、上述した本発明の各実施の形態において、送信装置、受信装置、マスタサーバおよびスレーブサーバの各機能ブロックが、記憶装置またはＲＯＭに記憶されたコンピュータ・プログラムを実行するＣＰＵによって実現される例を中心に説明した。この他、各装置の各機能ブロックの一部、全部、または、それらの組み合わせは、専用のハードウェアにより実現されていてもよい。

また、上述した本発明の各実施の形態において、送信装置、受信装置、マスタサーバおよびスレーブサーバの各機能ブロックは、複数の装置に分散されて実現されてもよい。

また、上述した本発明の各実施の形態において、各フローチャートを参照して説明した送信装置、受信装置、マスタサーバおよびスレーブサーバの各動作を、本発明のコンピュータ・プログラムとしてコンピュータ装置の記憶装置（記憶媒体）に格納しておいてもよい。そして、係るコンピュータ・プログラムを当該ＣＰＵが読み出して実行するようにしてもよい。そして、このような場合において、本発明は、係るコンピュータ・プログラムのコードあるいは記憶媒体によって構成される。

また、上述した各実施の形態は、適宜組み合わせて実施されることが可能である。

また、本発明は、上述した各実施の形態に限定されず、様々な態様で実施されることが可能である。

以上、上述した各実施の形態を模範的な例として本発明を説明した。しかしながら、本発明は、上述した各実施の形態には限定されない。即ち、本発明は、本発明のスコープ内において、当業者が理解し得る様々な態様を適用することができる。

この出願は、２０１３年１１月５日に出願された日本出願特願２０１３−２２９３１３を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１ 情報処理システム
１０ 送信装置
５０ 受信装置
２、３、４ メモリデータベースシステム
２０、３０、４０ マスタサーバ
６０、７０ スレーブサーバ
１１、２１、３１、４１ データ送信部
１２、２２、３２ ダミーデータ送信制御部
２３ マスタデータ記憶部
２４ アプリケーション部
３５ 所定期間算出部
３６ 開始制御部
５１、６１、７１ データ受信部
６２ 複製データ記憶部
１００１、５００１ ＣＰＵ
１００２、５００２ ＲＡＭ
１００３、５００３ ＲＯＭ
１００４、５００４ 記憶装置
１００５、５００５ ネットワークインタフェース

Claims (10)

1. アプリケーションから送信を要求される対象データ、または、ダミーデータを受信装置に対して送信するデータ送信手段と、
   所定期間が経過する度に、それまでの所定期間の間に、所定条件を満たすサイズの前記対象データが前記受信装置に対して送信されていない場合に、前記所定条件を満たすサイズの前記ダミーデータを送信するよう前記データ送信手段を制御するダミーデータ送信制御手段と、
   を備え、
   前記データ送信手段は、複数の前記受信装置に対してそれぞれ異なるコネクションを介して前記対象データまたは前記ダミーデータを送信し、
   前記ダミーデータ送信制御手段は、前記各受信装置に対して前記所定条件を満たすサイズの前記対象データが前記所定期間の間に送信されたか否かに応じた処理を、前記受信装置毎に異なるタイミングで実行することを特徴とする送信装置。
2. 前記データ送信手段は、前記対象データの送信要求および前記ダミーデータの送信要求を略同時に受けた場合、前記対象データのサイズが前記所定条件を満たしていれば該対象データを送信して前記ダミーデータの送信を省略し、前記対象データのサイズが前記所定条件を満たしていなければ前記所定条件を満たすようダミーデータを付加した対象データを送信することを特徴とする請求項１に記載の送信装置。
3. 前記ダミーデータ送信制御手段は、前記所定期間として、前記対象データを送信するための通信コネクションにおいて送信装置から受信装置に対する最近の通信からの経過時間について定められた長さであって、経過時間がこの長さに達すると輻輳ウィンドウサイズが縮小されることが規定された長さに基づく期間を適用することを特徴とする請求項１に記載の送信装置。
4. 前記データ送信手段がＴＣＰ（Transmission Control Protocol）コネクションを通して前記受信装置との通信を行うとき、前記所定期間は、再送タイムアウト時間に基づく期間であることを特徴とする請求項３に記載の送信装置。
5. 前記ダミーデータ送信制御手段は、輻輳ウィンドウサイズ以上であることを前記所定条件として用いることを特徴とする請求項１に記載の送信装置。
6. 請求項１から請求項５のいずれか１項に記載の送信装置と、
   前記送信装置から前記対象データを受信すると該対象データに対する所定の処理を行うとともに、前記ダミーデータを受信すると該ダミーデータを破棄するデータ受信手段を有する受信装置と、
   を備えた情報処理システム。
7. 請求項１に記載の送信装置と、
   マスタデータを記憶するマスタデータ記憶手段と、
   前記マスタデータを更新するとともに、前記マスタデータの更新前および更新後の差分を表す情報である更新ログを生成し、生成した更新ログを前記対象データとして送信するよう前記データ送信手段に要求するアプリケーション手段と、
   を備えたマスタサーバ。
8. 前記マスタデータの複製である複製データを記憶する複製データ記憶手段と、請求項７に記載のマスタサーバから、前記更新ログまたは前記ダミーデータを受信するとともに、受信した更新ログを用いて前記複製データを更新する受信装置とを有するスレーブサーバと、
   前記マスタサーバと、
   を備えたデータベースシステム。
9. 送信装置が、
   アプリケーションから対象データの送信要求があると前記対象データを受信装置に対して送信し、所定期間が経過する度に、それまでの所定期間の間に、所定条件を満たすサイズの前記対象データが前記受信装置に対して送信されていない場合に、前記所定条件を満たすサイズのダミーデータを前記受信装置に対して送信する処理を、複数の前記受信装置毎に異なるタイミングで実行する方法。
10. 送信装置が、請求項９に記載の方法を実行し、
    前記受信装置が、前記送信装置から送信された前記対象データを受信すると該対象データに対する所定の処理を行い、前記ダミーデータを受信すると該ダミーデータを破棄する方法。

Images