JP4612715B2 - 情報処理システム、データ更新方法およびデータ更新プログラム - Google Patents

Description

本発明は、マスターＤＢ（Data Base）計算機（以下、単に「マスター」ともいう。）の保持する原本データベースの複製をスレーブＤＢ計算機（以下、単に「スレーブ」ともいう。）において保持するマスター・スレーブ構成のデータベースシステムにおけるデータの整合性確保の技術に関する。

データの参照や更新を行う大規模なシステムでは、データベースが性能のボトルネックとなることが多い。これは、多数のアプリケーションから発生する大量の要求が１台のＤＢ計算機に集中し、全ての要求を処理しきれなくなる（パンクする）ためである。そのため、このような場合には、ＤＢ計算機を追加して元のＤＢ計算機と同一のデータを保持するようにしておき、アプリケーションからの要求を振り分けることで負荷を分散するのが一般的である。

ＤＢ計算機が複数台になると、更新要求を受信したときに全てのＤＢ計算機に更新を反映する方法が必要になる。このような目的のために、一般的なＤＢＭＳ（Data Base Management System：データベース管理システム）はレプリケーションと呼ばれる機能を備えている。レプリケーションとは、あるＤＢＭＳで発生した更新を、更新情報を格納した更新ログなどを送信することによって、他のＤＢＭＳに反映する機能である。

このようなレプリケーションを利用したデータベースシステムのデータ更新方法としては、以下の２つが考えられる。１つ目は、どのＤＢ計算機でも更新要求を受け付けるようにし、ＤＢ計算機同士で更新ログを送信し、更新を反映しあう方法である。２つ目は、更新要求はあらかじめ決められた１台のＤＢ計算機（マスター）のみで受け付け、他のＤＢ計算機（スレーブ）のデータはマスターから送信される更新ログによってのみ更新する方法である。

前記した１つ目の方法は、更新処理の負荷が分散できるため、処理性能の点では優れている。しかし、この方法では、データベースに不整合が発生することがある。
この不整合が発生する状況を、図２５を用いて説明する。２つのＤＢ計算機２５００，２５１０があり、初めは同じ値のデータ「３００」を保持している（符号２５０１，２５１１）。このとき、データに「１００」を加算する更新要求２５０２がＤＢ計算機２５００に送信されると、ＤＢ計算機２５００の保持するデータの値は「４００」になる（符号２５０４）。その直後に、データに「１５０」を加算する更新処理２５１２がＤＢ計算機２５１０に送信されると、ＤＢ計算機２５１０の保持するデータの値は「４５０」になる（符号２５１４）。

その後、ＤＢ計算機２５００は、データの値を「４００」にする更新ログをＤＢ計算機２５１０に送信し（符号２５０５）、ＤＢ計算機２５１０は、データの値を「４５０」にする更新ログをＤＢ計算機２５００に送信する（符号２５１５）。その結果、ＤＢ計算機２５００は受け付けた更新ログを反映してデータの値が「４５０」になり（符号２５０６）、ＤＢ計算機２５１０は受け付けた更新ログを反映してデータの値が「４００」になる（符号２５１６）。このように、２つのＤＢ計算機２５００，２５１０の保持するデータの値が異なってしまう不整合が発生する。

特許文献１には、更新ログにつけたヘッダ情報を利用してどちらの更新を優先するかを決定し、全てのＤＢ計算機が最終的に同じ内容のデータを保持することを保証する技術が開示されている。前述の図２５の例では、２つのＤＢ計算機の保持するデータの値は「４００」もしくは「４５０」のどちらか一方となり、上記の不整合は発生しない。しかし、２つのＤＢ計算機２５００，２５１０で構成されるデータベースシステムの利用者から見た場合、最初「３００」であったデータに２つの更新要求「＋１００」と「＋１５０」を送信したので、その結果は「５５０」となっていなければならない。結果が「４００」もしくは「４５０」の場合、２つの更新要求のうちどちらか一方が失われてしまっている。この問題はロストアップデートと呼ばれ、特許文献１による方法では回避できない。

これに対し、前記した２つ目の方法は、常にマスターで更新を処理するためロストアップデートの問題を回避することができる。この方法は、非特許文献１等で開示されている。しかし、この方法では、スレーブはマスターから更新ログを受信することによって更新を反映するため、更新処理が完了してから全てのスレーブに更新が反映されるまでに時間がかかることがある。また、更新処理の負荷は分散できないため、ＤＢ計算機の台数を増やしても更新処理性能は向上しない。

以上に述べた２つの方法は、データ整合性と処理性能の点でそれぞれ長所と短所があり、条件に応じて適切な方法を選択する必要がある。ＳＮＳ（Social Network Service）やネットショッピングのようなＷｅｂサービスを提供するシステムでは、利用者が増加するとデータベースへ大量の参照要求が発生するため、複数台のＤＢ計算機でデータベースシステムを構築する必要性が高まる。このようなシステムの多くでは、更新競合が発生した場合にロストアップデートが発生することは許されないため、マスターでのみ更新を受け付け、非同期で更新を反映する方法がとられることが多い。
特開平１１−７４０３号公報 Ｃａｌ Ｈｅｎｄｅｒｓｏｎ著、「Ｂｕｉｌｄｉｎｇ Ｓｃａｌａｂｌｅ Ｗｅｂ Ｓｉｔｅｓ」、Ｏ’Ｒｅｉｌｌｙ Ｍｅｄｉａ、 Ｉｎｃ．出版、２００６年５月、ｐ２３２−２３４

しかしながら、前述したように、マスターでのみ更新を受け付け、更新ログをスレーブに送信して非同期で更新反映を行うマスター・スレーブ構成のデータベースシステムでは、更新要求を出してからスレーブへ更新が反映されるまでに時間がかかる。そのため、更新要求が正常に完了したにも関わらず、その直後のスレーブへの参照要求で更新前の古いデータが参照されてしまう問題があった。これは、例えばネットオークションのようなサービスの場合、入札が成功したにも関わらず、直後の表示では入札前のデータが表示される等の不具合が発生することを意味する。

また、マスターへ参照要求を送信するようにすれば、最新の更新結果が参照できるが、このようにすると、更新要求に加えて一部の参照要求もマスターで集中処理することになり、要求を振り分けて処理することによる負荷分散の効果が低くなってしまうという問題が発生する。

そこで、本発明は、前記問題点に鑑みてなされたものであり、マスター・スレーブ構成のデータベースシステムにおいて、スレーブ側でも更新結果をその更新の直後の参照要求で参照できるようにする（つまり、更新前のデータが参照されないようにする）ことを課題とする。

本発明は、データの集合である原本データベースを管理する第１の情報処理装置と、原本データベースの複製である複製データベースを管理する１つ以上の第２の情報処理装置と、を備えて構成され、第１の情報処理装置の原本データベースで発生した更新情報を格納する更新ログを第２の情報処理装置に送信して複製データベースに反映する情報処理システムである。第２の情報処理装置は、外部の計算機から更新要求を受け付けると、該更新要求を第１の情報処理装置に送信して原本データベースを更新させるとともに、該第２の情報処理装置の複製データベースを更新する要求処理部と、受け付けた更新要求と対応する更新ログを第１の情報処理装置から受信したか否かを、複製データベース内のデータごとに管理する更新情報管理部と、第１の情報処理装置から新規な更新ログを受け付けると、該更新ログに格納されている情報と更新情報管理部の管理する情報から、該更新ログを複製データベースに反映するか否かを判断し、反映すると判断した場合は該更新ログの更新内容を複製データベースに反映する更新反映判定部と、を備える。その他の手段については後記する。

本発明によれば、マスター・スレーブ構成のデータベースシステムにおいて、スレーブ側でも更新結果をその更新の直後の参照要求で参照できるようにすることができる。

以下、本発明を実施するための最良の形態（以下、「実施形態」という。）に関し、比較例、第１実施形態〜第４実施形態について、図面を参照（言及図以外も適宜参照）しながら説明する。

＜比較例＞
本発明の第１実施形態〜第４実施形態の理解を容易にするため、まず、比較例について説明する。なお、本発明のデータベースシステムでは、更新要求をマスターで集中処理しつつ、同時にスレーブでも処理するようにする。このとき、全てのスレーブを同時に更新すると更新処理性能が著しく低下するので、更新要求をスレーブに振り分けるようにして、更新要求を受け付けたスレーブだけをマスターと同時に更新するようにする。他のスレーブへの更新の反映は、従来どおり、マスターから更新ログをスレーブに送信することで行う。このようにすることで、更新要求と参照要求を同一のスレーブに送信すれば、更新要求の結果が直後の参照要求で参照できるようになる。

このとき、スレーブにおいて、更新を処理して最新の値になったデータが、遅延して到着した更新ログを反映することによって古い値に戻ってしまう問題がある。この問題について図２６を用いて説明する。図２６に示すように、マスターＤＢ計算機２６１０と２台のスレーブＤＢ計算機２６００，２６２０で構成されるデータベースシステムを考える。

初めは全てのＤＢ計算機で同じ値のデータ「３００」を保持している（符号２６０１，２６１１および２６２１）。このとき、データに「１００」を加算する更新要求２６０２がスレーブＤＢ計算機２６００に送信され（符号２６０３）、さらにそれがマスターＤＢ計算機２６１０に送信される（符号２６０４）。その結果、マスターＤＢ計算機２６１０の保持するデータの値が「４００」に更新され（符号２６１２）、スレーブＤＢ計算機２６００の保持するデータの値も「４００」に更新される（符号２６０５，２６０６）。

次に、データに「１５０」を加算する更新要求２６２２がスレーブＤＢ計算機２６２０に送信され（符号２６２３）、さらにそれがマスターＤＢ計算機２６１０に送信される（符号２６２４）。その結果、マスターＤＢ計算機２６１０の保持するデータの値が「５５０」に更新され（符号２６１５）、スレーブＤＢ計算機２６２０の保持するデータの値も「５５０」に更新される（符号２６２５，２６２６）。これらの更新処理の後で、データの値を「４００」に更新する更新ログが遅延して到達すると（符号２６１３および２６１４）、スレーブＤＢ計算機２６２０のデータの値は最新の値「５５０」であるにも関わらず、古い値「４００」に戻ってしまう（符号２６２７）。

この問題を解決するため、本発明のデータベースシステムでは、更新カウンタ表等によって、該スレーブで受信した更新要求と対応する更新ログをすでにマスターから受信したか否かを管理する。スレーブがある更新ログ（更新ログＡという。）をマスターから受け付けると、更新ログ反映判定部２３５（更新反映判定部：図２参照）は、該スレーブで受信した更新要求と対応する更新ログをすでにマスターから受信したか否かを更新カウンタ表を参照して確認し、もし受信していなければ受け付けた更新ログＡを破棄し、もし受信していれば受け付けた更新ログＡを反映する。これにより、遅延してやってきた古い更新ログを反映することなく破棄し、データが古い値に戻ることを回避することができる（詳細は後記）。

＜第１実施形態＞
まず、図１を用いて本発明の第１実施形態におけるハードウェアの構成を説明する。
本発明の第１実施形態におけるデータベースシステムＤＢＳ（情報処理システム）は、マスターＤＢ計算機１２０（サーバ：第１の情報処理装置：第１のデータベース計算機：データベース計算機）と、１つ以上のスレーブＤＢ計算機１３０（サーバ：第２の情報処理装置：第２のデータベース計算機）とを備えて構成される。１つ以上のクライアント計算機１００（外部の計算機）はデータベースシステムＤＢＳを利用するアプリケーションが動作する計算機である。クライアント計算機１００、マスターＤＢ計算機１２０、スレーブＤＢ計算機１３０は、通信ネットワーク１１０を介して相互に接続されている。

クライアント計算機１００は、バス１０１によって接続されたネットワークインターフェース１０２、ＣＰＵ（Central Processing Unit）１０３、主記憶装置１０４を有し、ネットワークインターフェース１０２によって通信ネットワーク１１０と接続している。主記憶装置１０４は各種プログラムとプログラムが使用するデータを保持するもので、例えばメモリである。ＣＰＵ１０３は主記憶装置１０４に保持された各種プログラムを実行する。

マスターＤＢ計算機１２０は、バス１２１によって接続されたネットワークインターフェース１２２、ＣＰＵ１２３、主記憶装置１２４、ディスクインターフェース１２５を有し、ネットワークインターフェース１２２によって通信ネットワーク１１０と接続し、ディスクインターフェース１２５によって外部記憶装置１２６と接続している。主記憶装置１２４は各種プログラムとプログラムが使用するデータを保持するもので、例えばメモリである。外部記憶装置１２６はプログラムが使用するデータを保持する。ＣＰＵ１２３は主記憶装置１２４に保持された各種プログラムを実行する。

スレーブＤＢ計算機１３０は、バス１３１によって接続されたネットワークインターフェース１３２、ＣＰＵ１３３、主記憶装置１３４、ディスクインターフェース１３５を有し、ネットワークインターフェース１３２によって通信ネットワーク１１０と接続し、ディスクインターフェース１３５によって外部記憶装置１３６と接続している。主記憶装置１３４は各種プログラムとプログラムが使用するデータを保持するもので、例えばメモリである。外部記憶装置１３６はプログラムが使用するデータを保持する。ＣＰＵ１３３は主記憶装置１３４に保持された各種プログラムを実行する。

次に、図２を用いて本発明の第１実施形態におけるモジュール（ソフトウェアの機能単位）の構成を説明する。
クライアント計算機１００は、データベースシステムＤＢＳを利用するアプリケーションが動作する計算機であり、要求送信部２００を備える。要求送信部２００は１つ以上のスレーブＤＢ計算機１３０から１台を選択し、そのスレーブＤＢ計算機１３０に対して要求を送信する。要求は、典型的にはＳＱＬ（Structured Query Language）クエリである。

マスターＤＢ計算機１２０は、レプリケーション機能を持つ一般的なＤＢＭＳであり、マスター要求処理部２２０と更新ログ送信部２２１を備え、その外部記憶装置１２６に更新ログバッファ２２２と原本データベース２２３とを保持する。マスター要求処理部２２０はスレーブＤＢ計算機１３０から送信された要求を受け付け、解析し、処理する。更新ログ送信部２２１は更新ログバッファ２２２を監視し、更新ログが追加されたらそれを全てのスレーブＤＢ計算機１３０へ送信する。更新ログバッファ２２２はマスターＤＢ計算機１２０で行われた更新内容を記した更新ログを格納する。原本データベース２２３は利用者がデータベースシステムＤＢＳを利用して参照および更新するデータ（例えば後記する入札金額テーブル３００、商品情報テーブル３１０）を格納する。原本データベース２２３は、典型的には関連データベースであり、１つ以上のデータの組で行データを構成し、行データを並べたテーブルを１つ以上格納する。サーバ情報テーブル２２４は原本データベース２２３に格納されるテーブルの一つであり、スレーブＤＢ計算機１３０に関する情報を格納する。

スレーブＤＢ計算機１３０は、クライアント計算機１００からの要求を処理するＤＢ計算機であり、要求処理部２３０、サーバ情報付与部２３１、更新カウンタ増加部２３２（更新情報管理部２３２０）、更新カウンタ減少部２３４（更新情報管理部２３２０）、更新ログ反映判定部２３５、更新ログ受信部２３６、サーバ情報判定部２３７を備え、主記憶装置１３４に更新カウンタ表２３３（更新情報管理部２３２０）を保持し、外部記憶装置１３６に更新ログバッファ２２２ａ（２２２）と複製データベース２３８とを保持する。

要求処理部２３０はクライアント計算機１００からの要求を受け付け、解析し、処理する。要求処理部２３０は処理の中でマスターＤＢ計算機１２０へ要求を送信することがある。サーバ情報付与部２３１はサーバ情報テーブル２２４のデータを更新する更新要求をマスターＤＢ計算機１２０へ送信する。更新カウンタ増加部２３２は更新カウンタ表２３３の更新カウンタ（単に「カウンタ」ともいう。）を「１」増加する。更新カウンタ表２３３は複製データベース２３８の行データに対応するカウンタを格納する。

更新カウンタ減少部２３４は更新カウンタ表２３３のカウンタを「１」減少する。更新ログ反映判定部２３５は更新ログを反映するか否かを判定し、反映する場合（カウンタが「０」のとき）は複製データベース２３８を更新する。つまり、スレーブＤＢ計算機１３０において、自身の複製データベース２３８を更新してその更新データ（「更新データＡ」という。）をマスターＤＢ計算機１２０に送信すると更新カウンタ表２３３における該当カウンタを「１」にし、マスターＤＢ計算機１２０からその更新に関する更新ログを受け付けると更新カウンタ表２３３における該当カウンタを「０」にする。マスターＤＢ計算機１２０は各スレーブＤＢ計算機１３０から受け取った更新データをその受け取った順番で反映する。したがって、スレーブＤＢ計算機１３０は、自身の更新カウンタ表２３３における該当カウンタが「１」のときに、マスターＤＢ計算機１２０から受け取ったそのデータに関する更新ログを反映すべきでない。なぜなら、その更新ログは、更新データＡよりも古いデータであり、反映するとデータの不整合が起きえるからである。この詳細については、図９、図１３、図２４等で後記する。

更新ログ受信部２３６は更新ログ送信部２２１から送信された更新ログを受信し、更新ログバッファ２２２ａに追加する。サーバ情報判定部２３７は更新ログバッファ２２２ａを監視し、更新ログが追加されたらそれを取り出して解析し、該更新ログのサーバ情報を管理する（詳細は図１２で後記）。複製データベース２３８は原本データベース２２３のサーバ情報テーブル２２４を除くデータの複製に加えて、各行データごとにカウンタＩＤ（IDentification）を格納する（例えば後記する入札金額テーブル６００、商品情報テーブル６１０）。

以下では、図２のモジュール図で示されたデータ構造について、具体的な例を示した図面を用いて説明する。
原本データベース２２３には、図３に示されるようなアプリケーションが利用するデータを格納したテーブルと、図４に示されるようなサーバ情報テーブルとが格納される。

図３は原本データベース２２３に格納されるテーブルの例の一部を示している。原本データベース２２３には、各テーブル３００，３１０が格納される。各テーブル３００，３１０には、各テーブル名３０１，３１１がつけられ、ヘッダ情報３０２，３１２を有し、行データ３０３，３０４，３１３，３１４などを０個以上格納している。行データはヘッダ情報で指定された形式でデータがならんだものである。図３の例では、入札金額テーブル３００はヘッダ情報３０２に示すように「商品ＩＤ」「値段」がこの順番で並んだ行データを格納するテーブルである。したがって、行データ３０３の「２０８」は商品ＩＤ、「３００」は値段を示すデータである。

図４はサーバ情報テーブル２２４（４０１）の一例を示している。ヘッダ情報４０２に示すようにサーバ情報テーブル２２４は「サーバＩＤ」と「ダミーデータ」を格納するテーブルである。サーバＩＤは各スレーブＤＢ計算機１３０に一意に割り振られた識別子である。ダミーデータは更新処理を発生させるために使用されるデータであり、数値そのものに意味はない。

図５は更新ログバッファ２２２に更新ログが格納された状態の一例を示している。更新ログには、符号５０１，５０５に示すトランザクション開始ログ、符号５０４，５０８に示すコミットログ、符号５０２，５０３，５０６，５０７に示すデータ更新ログがある。トランザクション開始ログとコミットログはそれぞれトランザクションの開始と終了を示す更新ログである。なお、トランザクション開始ログとコミットログはどちらか一方のみを使用してもよい。データ更新ログには、更新されたテーブルのテーブル名、更新前と更新後の行データが格納されている。符号５０１〜５０４や符号５０５〜５０８に示すように、一つのトランザクションにより発生する一連の更新ログを更新トランザクションログと呼ぶ。

図６は複製データベース２３８に格納されるデータの例の一部を示している。複製データベース２３８には、原本データベース２２３に格納されているテーブル３００，３１０（図３参照）の複製として、テーブル６００，６１０が格納されている。ただし、サーバ情報テーブル２２４の複製は格納されない。また、テーブル６００，６１０の各行データには、該スレーブＤＢ計算機１３０の複製データベース２３８内で一意なカウンタＩＤが付加される。なお、カウンタＩＤは、該スレーブＤＢ計算機１３０内でのみ取り扱われる情報である。

図７は更新カウンタ表２３３の一例を示している。更新カウンタ表２３３にはカウンタＩＤと更新カウンタの組のデータが格納される。

以下、図２のモジュール図で示された各モジュールの動作を説明する。図８はマスター要求処理部２２０の動作を示すフローチャートである。
マスター要求処理部２２０は、まずスレーブＤＢ計算機１３０の要求処理部２３０から要求を受信し（ステップ８０１）、その要求を解析し（ステップ８０２）、要求の種類を判別する（ステップ８０３）。

参照要求の場合は（ステップ８０３で「参照」）、さらに、更新のための参照か否（通常の参照）かを判別する（ステップ８０４）。更新のための参照は、参照結果を同じトランザクション内の更新要求で使用する参照であり、データベースの利用者が明示的に指定することができる。更新のための参照の場合は（ステップ８０４で「Ｙｅｓ」）、要求されたデータを原本データベース２２３から検索してそのデータに共有ロックをかけて値を読み取る（ステップ８０５）。通常の参照の場合は（ステップ８０４で「Ｎｏ」）、要求されたデータを原本データベース２２３から検索してその値を読み取る（ステップ８０６）。ステップ８０５とステップ８０６のいずれ場合の後も、読み取ったデータを要求元（スレーブＤＢ計算機１３０の要求処理部２３０）に返す（ステップ８０７）。

更新要求の場合は（ステップ８０３で「更新」）、要求されたデータを原本データベース２２３から検索してそのデータに排他ロックをかけて値を変更（更新）する（ステップ８０８）。

トランザクション開始要求の場合は（ステップ８０３で「トランザクション開始」）、トランザクションを開始する（ステップ８０９）。

コミット要求の場合は（ステップ８０３で「コミット」）、該トランザクションで更新した内容をトランザクションの開始、コミットを含めて更新ログバッファ２２２に追加し（更新ログに書き出し）（ステップ８１０）、トランザクション内でかけた共有ロックおよび排他ロックを解除し（ステップ８１１）、トランザクションを終了する（ステップ８１２）。

図９は要求処理部２３０の動作を示すフローチャートである。要求処理部２３０は、まずクライアント計算機１００の要求送信部２００から要求を受信し（ステップ９０１）、その要求を解析し（ステップ９０２）、要求の種類を判別する（ステップ９０３）。

参照要求の場合は（ステップ９０３で「参照」）、さらに更新のための参照か否（通常の参照）かを判別する（ステップ９０４）。更新のための参照の場合は（ステップ９０４で「Ｙｅｓ」）、マスターＤＢ計算機１２０に同じ要求を送信して（ステップ９０５）その参照結果を受信し、自スレーブＤＢ計算機１３０（自サーバ）の複製データベース２３８でその結果と対応するデータを検索して、その値が前記参照結果と異なっていたら該データを前記参照結果に変更（更新）し（ステップ９０６）、前記参照結果を要求元（クライアント計算機１００の要求送信部２００）に返す（ステップ９０７）。通常の参照の場合は（ステップ９０４で「Ｎｏ」）、要求されたデータを自スレーブＤＢ計算機１３０（自サーバ）の複製データベース２３８から検索してその値を要求元（クライアント計算機１００の要求送信部２００）に返す（ステップ９０８）。

更新要求の場合は（ステップ９０３で「更新」）、その直前にステップ９０５〜９０７の処理を行ったか否かを判断し（ステップ９０８１）、Ｎｏの場合はステップ９０９に進み、Ｙｅｓの場合はステップ９１０に進む。ステップ９０９において、その要求をもとにして更新対象のデータを参照する更新のための参照要求を作成し、その参照要求をマスターＤＢ計算機１２０に送信して更新対象のデータを取得する。ステップ９１０において、該更新要求をマスターＤＢ計算機１２０に送信し、自スレーブＤＢ計算機１３０（自サーバ）の複製データベース２３８のデータを更新する。その後、更新カウンタ増加部２３２の処理を行う。

トランザクション開始要求の場合は（ステップ９０３で「トランザクション開始」）、マスターＤＢ計算機１２０に同じ要求（トランザクション開始要求）を送信し、自スレーブＤＢ計算機１３０（自サーバ）でもトランザクションを開始し（ステップ９１１）、サーバ情報付与部２３１の処理を行う。

コミット要求の場合は（ステップ９０３で「コミット」）、マスターＤＢ計算機１２０に同じ要求（コミット要求）を送信し、自スレーブＤＢ計算機１３０（自サーバ）でも該トランザクションを終了する（ステップ９１２）。

図１０は更新カウンタ増加部２３２の動作（図９のステップ９１０の処理の後）を示すフローチャートである。
更新カウンタ増加部２３２は更新要求を処理するときに要求処理部２３０から呼び出され、各表（入札金額テーブル６００、商品情報テーブル６１０）を参照してカウンタＩＤを特定し（ステップ１００１）、更新カウンタ表２３３の更新対象データが含まれる行データのカウンタＩＤと対応する更新カウンタを「１」増加する（ステップ１００２）。

図１１はサーバ情報付与部２３１の動作（図９のステップ９１１の処理の後）を示すフローチャートである。
サーバ情報付与部２３１はトランザクション開始要求を処理するときに要求処理部２３０から呼び出され、サーバ情報テーブル２２４の自スレーブＤＢ計算機１３０（自サーバ）のサーバＩＤが含まれる行データのダミーデータを「１」増加する更新要求をマスターＤＢ計算機１２０に送信する（ステップ１１０１）。これにより、この後コミット要求でトランザクションが終了したときに、自スレーブＤＢ計算機１３０（自サーバ）のサーバＩＤが含まれる行データを更新するデータ更新ログが更新ログバッファ２２２ａに追加される。なお、ダミーデータに対する更新要求は、自スレーブＤＢ計算機１３０（自サーバ）のサーバＩＤを得るために行うものなので、「１」増加でなくても更新要求であればなんでもよい。

図１２はサーバ情報判定部２３７の動作を示すフローチャートである。
サーバ情報判定部２３７はまず更新ログサーバＩＤという変数を用意し、値をＮＵＬＬに初期化する（ステップ１２０１）。次に、更新ログバッファ２２２ａから更新ログを１行取り出し（読み込み）（ステップ１２０２）、その１行を解析し（ステップ１２０３）、ログの種類を判別する（ステップ１２０４）。

トランザクション開始ログの場合は（ステップ１２０４で「トランザクション開始」）、トランザクションを開始する（ステップ１２０５）。コミットログの場合は（ステップ１２０４で「コミット」）、トランザクションを終了し（ステップ１２０６）、更新ログサーバＩＤにＮＵＬＬを設定する（ステップ１２０７）。サーバ情報テーブルの行データを更新するデータ更新ログの場合は（ステップ１２０４で「サーバ情報テーブルの更新」）、そのデータ更新ログからサーバＩＤを読み出して（例えば図５のデータ更新ログ５０２からサーバＩＤ「４」を読み出して）その値を更新ログサーバＩＤに設定する（ステップ１２０８）。それ以外のデータ更新ログの場合は（ステップ１２０４で「その他の更新」）、更新ログ反映判定部２３５の処理を行う。

図１３は更新ログ反映判定部２３５の動作を示すフローチャートである。
更新ログ反映判定部２３５は、各表（入札金額テーブル６００、商品情報テーブル６１０）を参照してカウンタＩＤを特定する（ステップ１３００）。次に、更新ログの更新内容を反映するか否かを決定するために、更新ログサーバＩＤの値が自スレーブＤＢ計算機１３０（自サーバ）のサーバＩＤと一致するか否かを調べる（ステップ１３０１）。一致する場合は（ステップ１３０１で「Ｙｅｓ」）、更新カウンタ減少部２３４の処理を行う。

一致しない場合は（ステップ１３０１で「Ｎｏ」）、更新カウンタ表２３３から更新対象の行データのカウンタＩＤと対応する更新カウンタを読み出し（参照し）（ステップ１３０２）、その値が「０」より大きいか否かを調べる（ステップ１３０３）。「０」より大きいときは（ステップ１３０３で「Ｙｅｓ」）更新を反映せずに終了する。「０」のときは（ステップ１３０３で「Ｎｏ」）更新を自スレーブＤＢ計算機１３０（自サーバ）の複製データベース２３８に反映する（ステップ１３０４）。

図１４は更新カウンタ減少部２３４の動作を示すフローチャートである。
更新カウンタ減少部２３４は更新ログ反映判定部２３５から呼び出され、更新対象の行データのカウンタＩＤと対応する更新カウンタを「１」減少する（ステップ１４０１）。

以下では、スレーブＤＢ計算機１３０がクライアント計算機１００から更新要求を受け付けてから、他のスレーブＤＢ計算機１３０に更新が反映されるまでの処理の流れを具体的な例をもとに説明する。ここでは、図１５に示すようにマスターＤＢ計算機１２０と２台のスレーブＤＢ計算機１３０Ａ（１３０）および１３０Ｂ（１３０）から構成されるデータベースシステムＤＢＳを考える。なお、図２と同一の構成には、同一の符号で、あるいは、同一の符号に「Ａ」または「Ｂ」の添字を付して、表記している。

図１５は、更新要求がクライアント計算機１００Ａ（１００）からスレーブＤＢ計算機１３０Ａに送信され、その要求による更新が反映されるまでのサーバ間のデータの流れを示したものである。クライアント計算機１００ＡからスレーブＤＢ計算機１３０Ａに要求１５０１が送信されると、それに応じてスレーブＤＢ計算機１３０ＡからマスターＤＢ計算機１２０に要求１５０２が送信される。要求１５０２が参照要求の場合は結果１５０３がマスターＤＢ計算機１２０からスレーブＤＢ計算機１３０Ａに返される。その後、更新要求により発生した更新ログ１５０４がマスターＤＢ計算機１２０からスレーブＤＢ計算機１３０Ａおよび１３０Ｂに送信される。

ここでは、図１６に示すようなトランザクション１６００（要求１５０１に対応）が、クライアント計算機１００ＡからスレーブＤＢ計算機１３０Ａに送信された場合を考える。
このとき、スレーブＤＢ計算機１３０ＡからマスターＤＢ計算機１２０に送信されるトランザクション１７００（要求１５０２に対応）は図１７のようになる。また、マスターＤＢ計算機１２０からスレーブＤＢ計算機１３０Ａおよび１３０Ｂに送信される更新トランザクションログ１８００（更新ログ１５０４に対応）は図１８のようになる。

このときの各ＤＢ計算機の保持するデータの値の変遷を、図１９を用いて説明する（データの変更箇所は太枠で表記）。図１９で、符号１９０１は原本データベース２２３、符号１９０２はサーバ情報テーブル２２４、符号１９１１はスレーブＤＢ計算機１３０Ａの複製データベース２３８、符号１９１２はスレーブＤＢ計算機１３０Ａの更新カウンタ表２３３、符号１９２１はスレーブＤＢ計算機１３０Ｂの複製データベース２３８、符号１９２２はスレーブＤＢ計算機１３０Ｂの更新カウンタ表２３３の、それぞれ一部を表している（最上段以外は符号を省略）。

トランザクション１６００がクライアント計算機１００ＡからスレーブＤＢ計算機１３０Ａに送信されると（ステップ１９３０）、まず、スレーブＤＢ計算機１３０Ａはトランザクション開始要求１７０１と、サーバ情報テーブル２２４の自サーバＩＤ（＝３）と対応するダミーデータを更新する更新要求１７０２をマスターＤＢ計算機１２０に送信し、その結果、サーバ情報テーブル１９０２の該当データが更新（「２５」→「２６」）される（ステップ１９３１）。

次に、スレーブＤＢ計算機１３０Ａは更新要求１６０２から、更新対象を参照する更新のための参照要求１７０３を作成し、マスターＤＢ計算機１２０に送信する（ステップ１９３２）。その結果、原本データベース１９０１の該当行データには共有ロックがかけられ、マスターＤＢ計算機１２０からスレーブＤＢ計算機１３０Ａに該当行データ「２０８，３００」が返されるが、これは複製データベース１９１１のデータと等しいので無視される（ステップ１９３３）。

次に、スレーブＤＢ計算機１３０Ａは更新要求１６０２と同一の更新要求１７０４をマスターＤＢ計算機１２０に送信し、さらに自サーバでも更新を処理し、更新カウンタ表１９１２の該当カウンタを「１」増加する。その結果、原本データベース１９０１と複製データベース１９１１と更新カウンタ表１９１２の該当データが更新される（「３００」→「４００」，「０」→「１」）（ステップ１９３４）。このとき、スレーブＤＢ計算機１３０Ａは更新要求１６０２と同一の更新要求１７０４を送るのではなく、更新のための参照要求１７０３で取得した行データを、自サーバで更新要求を処理した更新結果で上書きする更新要求を作成し、マスターＤＢ計算機１２０に送ってもよい。このようにすると、マスターＤＢ計算機１２０で更新結果を計算する必要がなくなり、マスターＤＢ計算機１２０の負荷が軽減できる。

次に、スレーブＤＢ計算機１３０Ａはコミット要求１７０５をマスターＤＢ計算機１２０に送り、その結果、トランザクションが終了し、マスターＤＢ計算機１２０の更新ログバッファ２２２に更新トランザクションログ１８００が追加される。その後、更新トランザクションログ１８００がマスターＤＢ計算機１２０からスレーブＤＢ計算機１３０Ａおよび１３０Ｂに送信される。

スレーブＤＢ計算機１３０Ａは更新トランザクションログ１８００を受け付けると、更新ログ１８０２に格納されているサーバＩＤが自サーバのサーバＩＤ（＝３）と一致しているため、更新ログ１８０３で更新対象となっているデータと対応する更新カウンタを「１」減少する（「１」→「０」）。また、スレーブＤＢ計算機１３０Ｂは更新トランザクションログ１８００を受け付けると、更新ログ１８０２に格納されているサーバＩＤが自サーバのサーバＩＤ（＝４）と異なり、更新ログ１８０３で更新対象のデータと対応する更新カウンタの値が「０」なので、更新ログ１８０３を自サーバの複製データベース１９２１に反映する（「３００」→「４００」）（ステップ１９３５）。以上のようにして、スレーブＤＢ計算機１３０Ａに送信された更新要求による更新がスレーブＤＢ計算機１３０Ｂに正しく反映される。

次に、第１実施形態のデータベースシステムＤＢＳにおいて、更新要求が競合して更新ログが遅延して到着しても、最新のデータが古い更新ログの更新反映によって古いデータに戻ることを回避できることを示す。

図２０は、図１５と同様のデータベースシステムＤＢＳに関し、更新要求がクライアント計算機１００ＡからスレーブＤＢ計算機１３０Ａに送信された直後に、同一のデータに対する更新要求がクライアント計算機１００ＢからスレーブＤＢ計算機１３０Ｂに送信されたときのサーバ間のデータの流れを示した図である。

クライアント計算機１００ＡからスレーブＤＢ計算機１３０Ａに要求１５０１が送信されると、それに応じてスレーブＤＢ計算機１３０ＡからマスターＤＢ計算機１２０に要求１５０２が送信される。要求１５０２が参照要求の場合は結果１５０３がマスターＤＢ計算機１２０からスレーブＤＢ計算機１３０Ａに返される。同様に、クライアント計算機１００ＢからスレーブＤＢ計算機１３０Ｂに要求２００１が送信されると、それに応じてスレーブＤＢ計算機１３０ＢからマスターＤＢ計算機１２０に要求２００２が送信される。要求２００２が参照要求の場合は結果２００３がマスターＤＢ計算機１２０からスレーブＤＢ計算機１３０Ｂに返される。その後、更新要求により発生した更新ログ１５０４がマスターＤＢ計算機１２０からスレーブＤＢ計算機１３０Ａおよび１３０Ｂに送信される。

ここでは、トランザクション１６００（要求１５０１に対応）がクライアント計算機１００ＡからスレーブＤＢ計算機１３０Ａに送信された直後に、図２１に示すトランザクション２１００（要求２００１に対応）がクライアント計算機１００ＢからスレーブＤＢ計算機１３０Ｂに送信された場合を考える。

このとき、スレーブＤＢ計算機１３０ＡからマスターＤＢ計算機１２０に送信されるトランザクションは図１７のトランザクション１７００（要求１５０２に対応）のようになり、スレーブＤＢ計算機１３０ＢからマスターＤＢ計算機１２０に送信されるトランザクションは図２２のトランザクション２２００（要求２００２に対応）のようになる。また、マスターＤＢ計算機１２０からスレーブＤＢ計算機１３０Ａおよび１３０Ｂに送信される更新トランザクションログは、図１８の更新トランザクションログ１８００（更新ログ１５０４に対応）と、図２３の更新トランザクションログ２３００（更新ログ１５０４に対応）のようになる。

このときの各ＤＢ計算機の保持するデータの値の変遷を、図２４を用いて説明する（データの変更箇所は太枠で表記）。図２４で、符号２４０１は原本データベース２２３、符号２４０２はサーバ情報テーブル２２４、符号２４１１はスレーブＤＢ計算機１３０Ａの複製データベース２３８、符号２４１２はスレーブＤＢ計算機１３０Ａの更新カウンタ表２３３、符号２４２１はスレーブＤＢ計算機１３０Ｂの複製データベース２３８、符号２４２２はスレーブＤＢ計算機１３０Ｂの更新カウンタ表２３３の、それぞれ一部を表している（最上段以外は符号を省略）。

トランザクション１６００がクライアント計算機１００ＡからスレーブＤＢ計算機１３０Ａに送信されて（ステップ２４３０）から、コミット要求１７０５がマスターＤＢ計算機１２０に送信されるまで（ステップ２４３４）は、前述した図１９のステップ１９３０〜１９３４と同じであるので説明を省略する。

次に、トランザクション２１００がクライアント計算機１００ＢからスレーブＤＢ計算機１３０Ｂに送信されると（ステップ２４４０）、まず、スレーブＤＢ計算機１３０Ｂはトランザクション開始要求２２０１と、サーバ情報テーブル２２４の自サーバＩＤ（＝４）と対応するダミーデータを更新する更新要求２２０２をマスターＤＢ計算機１２０に送信し、その結果、サーバ情報テーブル２４０２の該当データが更新される（「１２」→「１３」）（ステップ２４４１）。

次に、スレーブＤＢ計算機１３０Ｂは更新要求２１０２から、更新対象を参照する更新のための参照要求２２０３を作成し、マスターＤＢ計算機１２０に送信する（ステップ２４４２）。その結果、原本データベース２４０１の該当行データには共有ロックがかけられ、マスターＤＢ計算機１２０からスレーブＤＢ計算機１３０Ｂに該当行データ「２０８，４００」）が返されるが、これは複製データベース２４２１のデータと異なるので、複製データベース２４２１の該当データを更新する（「３００」→「４００」）（ステップ２４４３）。

次に、スレーブＤＢ計算機１３０Ｂは更新要求２１０２と同一の更新要求２２０４をマスターＤＢ計算機１２０に送信し、さらに自サーバでも更新を処理し、更新カウンタ表２４２２の該当カウンタを「１」増加する（「０」→「１」）。その結果、原本データベース２４０１と複製データベース２４２１と更新カウンタ表２４２２の該当データが更新される（「４００」→「５５０」，「０」→「１」）（ステップ２４４４）。次に、スレーブＤＢ計算機１３０Ｂはコミット要求２２０５をマスターＤＢ計算機１２０に送り、その結果、トランザクションが終了し、マスターＤＢ計算機１２０の更新ログバッファ２２２に更新トランザクションログ２３００が追加される。

その後、更新トランザクションログ１８００がマスターＤＢ計算機１２０からスレーブＤＢ計算機１３０Ａおよび１３０Ｂに送信される（ステップ２４３５）。スレーブＤＢ計算機１３０Ａは更新トランザクションログ１８００を受け付けると、更新ログ１８０２に格納されているサーバＩＤ（＝３）が自サーバのサーバＩＤ（＝３）と一致しているため、更新ログ１８０３で更新対象となっているデータと対応する更新カウンタを「１」減少する（「１」→「０」）。また、スレーブＤＢ計算機１３０Ｂは更新トランザクションログ１８００を受け付けると、更新ログ１８０２に格納されているサーバＩＤ（＝３）が自サーバのサーバＩＤ（＝４）と異なり、更新ログ１８０３で更新対象のデータと対応する更新カウンタの値が「１」なので、更新ログ１８０３を反映せずに破棄する。

次に、更新トランザクションログ２３００がマスターＤＢ計算機１２０からスレーブＤＢ計算機１３０Ａおよび１３０Ｂに送信される（ステップ２４４５）。スレーブＤＢ計算機１３０Ａは更新トランザクションログ２３００を受け付けると、更新ログ２３０２に格納されているサーバＩＤ（＝４）が自サーバのサーバＩＤ（＝３）と異なり、更新ログ２３０３で更新対象のデータと対応する更新カウンタの値が「０」なので、更新ログ２３０３を複製データベース２４１１に反映する（「４００」→「５５０」）。また、スレーブＤＢ計算機１３０Ｂは更新トランザクションログ２３００を受け付けると、更新ログ２３０２に格納されているサーバＩＤ（＝４）が自サーバのサーバＩＤ（＝４）と一致しているため、更新ログ２３０３で更新対象となっているデータと対応する更新カウンタを「１」減少する（「１」→「０」）。

このように、第１実施形態のデータベースシステムＤＢＳによれば、更新要求の競合が発生した場合も、更新（データ）が失われたり、図２６で示したように古い更新ログの反映によって最新の値が古い値で上書きされたりすることなく、正しく更新反映が完了する。

つまり、マスターから送信される更新ログによってスレーブに更新を反映するマスター・スレーブ構成のデータベースシステムにおいて、更新結果を直後の参照要求で参照できるようになる。これにより、ロストアップデートの発生を回避しつつ更新結果をすぐに参照できる必要のある、ネットオークションなどのアプリケーションに対して、複数台のＤＢ計算機で負荷分散をするデータベースシステムが構成できるようになる。

また、マスターＤＢ計算機１２０およびスレーブＤＢ計算機１３０を構成するコンピュータに実行させるデータ更新プログラム（データ更新方法を実現するためのプログラム）を作成し、各コンピュータにインストールすることにより、コンピュータは、そのデータ更新プログラムに基づいた各機能を実現することができる。

＜第２実施形態＞
以下、本発明の第２実施形態について説明する。その際、第１実施形態との相違点を主に説明し、第１実施形態との共通点については説明を省略あるいは簡略化する。

第１実施形態では更新カウンタを更新カウンタ表２３３というデータ構造で保持していた。これに対し、第２実施形態では更新カウンタを複製データベース２３８の中に直接格納する。
第２実施形態におけるハードウェア構成は第１実施形態と同一（図１参照）である。
また、第２実施形態におけるモジュール構成は、第１実施形態の場合（図２参照）と比べ、更新カウンタ表２３３がなくなり、更新カウンタの更新や参照がすべて外部記憶装置１３６内の複製データベース２３８への更新や参照になる以外は同一であるので図示を省略する。

図２７は、第２実施形態における複製データベース２３８の例の一部を示している。図２７に示すように、テーブル２７００，２７１０において、行データが更新カウンタを保持し、カウンタＩＤ（図６、図７参照）は不要となる。
第２実施形態における各モジュールの動作は、更新カウンタ表２３３への更新や参照が、複製データベース２３８への更新や参照となる以外は第１実施形態と同一である（図１０と図１３のフローチャートにおいては、カウンタＩＤを特定する代わりに更新カウンタを直接特定すればよい）。

複製データベース２３８内に更新カウンタを保持すると、更新カウンタ増加部２３２や更新カウンタ減少部２３４が更新カウンタを増減するたびに外部記憶装置１３６内のデータへの書き込みが発生する。これにより、データベースシステムＤＢＳ全体の処理性能が低下する可能性がある。
しかし、アプリケーション（クライアント計算機１００）からの更新要求の頻度が少ない場合や、外部記憶装置１３６への書き込み速度が十分に速い場合は、この第２実施形態のように更新カウンタを複製データベース２３８内に直接格納してもよい。更新カウンタを複製データベース２３８内に直接格納することで、更新カウンタ表２３３やカウンタＩＤが必要なくなるので、主記憶装置１３４の容量が少なく済むようになり、更新カウンタの増減処理も単純になるという効果がある。

＜第３実施形態＞
以下、本発明の第３実施形態について説明する。その際、第１実施形態および第２実施形態との相違点を主に説明し、第１実施形態および第２実施形態との共通点については説明を省略あるいは簡略化する。

データベースシステムＤＢＳ内のデータの管理方法としてＭＶＣＣ（Multi-Version Concurrency Control）と呼ばれる方法がある。ＭＶＣＣではデータをバージョン管理することで、データにロックをかけずに更新・参照処理を行ってもデータの整合性を保持することができる。これにより、ロックをかけてデータの整合性を保持する方法よりも、多くのトランザクションを同時に実行できるため、データベースシステムＤＢＳのスループットが向上する。第３実施形態ではバージョン管理されたデータを利用することによって、第１実施形態および第２実施形態における更新カウンタと同等の情報を管理する。

第３実施形態のハードウェア構成は第１実施形態と同一である（図１参照）。
第３実施形態のモジュール構成を、図２８を用いて説明する。なお、図２と同一の構成には同一の符号を付し、説明を省略する。要求処理部２８０１はＭＶＣＣの方法で複製データベース２８０４のデータ（例えば後記する入札金額テーブル２９００、更新ログ反映済みポインタ２９１０）を参照および更新する。更新情報管理部２８０２は更新ログ反映判定部２８０３から呼び出され、複製データベース２８０４の更新対象の行データと対応する更新ログ反映済みポインタを、次のバージョンを指すように変更する。更新ログ反映判定部２８０３はサーバ情報と更新ログ反映済みポインタの情報から、更新ログを反映するか否かを判断し、反映する場合は複製データベース２８０４を更新する。

図２９は複製データベース２８０４の例の一部を示したものである。入札金額テーブル２９００に示すように、「商品ＩＤ」、「値段」のほかに、各テーブルの行データに対してＭＶＣＣを実現するためのデータである「行データＩＤ」、バージョン番号（「バージョン」）、次のバージョンへのポインタ（「次」）を追加する。また、各行データＩＤに対して更新ログ反映済みのバージョンを指す、更新ログ反映済みポインタ２９１０を保持する。なお、更新ログ反映済みポインタ２９１０は、複製データベース２８０４内ではなく、自スレーブＤＢ計算機１３０の主記憶装置１３４内に保持しておいてもよい。

図３０は要求処理部２８０１の動作を示したフローチャートである。なお、図９のフローチャートと同一の処理には同一の符号を付し、説明を省略する。要求処理部２８０１はトランザクション開始要求を受け付けると（ステップ９０３で「トランザクション開始」）、マスターＤＢ計算機１２０にその要求を送信し、トランザクションを開始し、そのトランザクションにバージョン番号を割り振る（ステップ３００４）。バージョン番号は各トランザクションで一意であり、開始した時刻が遅いトランザクションほど大きい番号とする。

参照要求の処理で（ステップ９０３で「参照」）、ステップ９０４でＮｏの場合、要求処理部２８０１は、現在のトランザクションのバージョン番号以下で最も大きいバージョン番号をもったデータ（現バージョンのデータと呼ぶ。）のみを参照し、要求元に返す（ステップ３００２）。

一方、更新要求の処理では（ステップ９０３で「更新」）、その直前にステップ９０５，３００１，９０７の処理を行ったか否かを判断し（ステップ３００１１）、Ｎｏの場合はステップ９０９に進み、Ｙｅｓの場合はステップ３００３に進む。ステップ３００３において、行データを上書きするのではなく、元の行データを複製して新しい行データを作成し、そのデータを更新してバージョン番号に現在のトランザクションのバージョン番号を格納する。

更新のための参照要求の処理で（ステップ９０４で「Ｙｅｓ」）、ステップ９０５の後、マスターＤＢ計算機１２０から取得したデータと自サーバの複製データベース２８０４の現バージョンのデータが異なっていたときも、要求処理部２８０１は、自サーバの複製データベース２８０４に対してステップ３００３の更新処理と同様の更新処理を行う（ステップ３００１）。

図３１は更新ログ反映判定部２８０３の動作を示したフローチャートである。なお、図１３のフローチャートと同一の処理には同一の符号を付し、説明を省略あるいは簡略化する。更新ログ反映判定部２８０３は、更新ログのサーバＩＤと自サーバのＩＤが等しいときは（ステップ１３０１で「Ｙｅｓ」）、更新情報管理部２８０２を呼び出して更新対象データの行データＩＤと対応する更新ログ反映済みポインタを次のバージョンを指すように変更する（更新情報管理部２８０２の処理：図３２のステップ３２０１）。

更新ログのサーバＩＤと自サーバのＩＤが等しくないときは（ステップ１３０１で「Ｎｏ」）、更新対象データの行データＩＤと対応する更新ログ反映済みポインタが、その行データＩＤを持つ行データの中で最も大きいバージョン（最新のバージョン）を指しているか否かを調べる（ステップ３１０１）。最新のバージョンでなければ（ステップ３１０２で「Ｎｏ」）、更新ログを反映せずに破棄し、最新のバージョンであれば（ステップ３１０２で「Ｙｅｓ」）、更新ログを自サーバの複製データベース２８０４に反映し、更新された行データの行データＩＤと対応する更新ログ反映済みポインタを最新のバージョンを指すように変更する（ステップ３１０３）。

以下では、具体的な例を使って、参照および更新時の処理の概要を説明する。
複製データベース２８０４の保持するデータが図２９で示した状態のときに、参照のＳＱＬクエリ「ＳＥＬＥＣＴ ＊ ＦＲＯＭ 入札金額 ＷＨＥＲＥ 商品ＩＤ＝２０８」を受信したとする。このとき要求処理部２８０１は、その要求を含むトランザクションのバージョン番号が「１４５６３」〜「１５６３２」であれば、行データ２９０１を結果として返し、バージョン番号が「１５６３３」以上であれば行データ２９０３を結果として返す。

また、複製データベース２８０４の保持するデータが図２９で示した状態のときに、更新のＳＱＬクエリ「ＵＰＤＡＴＥ 入札金額 ＳＥＴ 値段＝値段＋１００ ＷＨＥＲＥ 商品ＩＤ＝２０８」を受信したとする。このときのトランザクションのバージョン番号が「１５８４６」であったとすると、要求処理部２８０１は、行データ２９０３を複製し、そのデータに対して更新処理をし、バージョン番号に「１５８４６」を格納して新しい行データ３３００を作成する。これを示したのが図３３である。このとき、更新ログ反映済みポインタ２９１１は元の行データ２９０３を指しており、まだ自サーバの受信した最新の更新要求と対応する更新ログを受信していないことを示している（第１実施形態における更新カウンタが「１」の場合に対応）。また、この要求を含むトランザクションのバージョン番号が「１５６３２」以下の場合は、更新処理は失敗してエラーが返る。

この後、前記更新ＳＱＬクエリと対応する更新ログを受け付けると、更新ログ反映判定部２８０３は、更新ログのサーバＩＤが自サーバのサーバＩＤと一致するので、更新情報管理部２８０２を呼び出し、更新対象と対応する行データＩＤの更新ログ反映済みポインタを次のバージョンを指すように変更する。これを示したのが図３４である（第１実施形態における更新カウンタが「０」の場合に対応）。図３４では、更新ログ反映済みポインタ２９１１は最新の行データ３３００を指している。
以上のように、ＭＶＣＣで使用するデータを利用して、第１実施形態および第２実施形態で示した更新カウンタと同等の情報を管理することができる。

＜第４実施形態＞
以下、本発明の第４実施形態について説明する。その際、第１実施形態〜第３実施形態との相違点を主に説明し、第１実施形態〜第３実施形態との共通点については説明を省略あるいは簡略化する。

第１実施形態〜第３実施形態ではマスターＤＢ計算機１２０と１つ以上のスレーブＤＢ計算機１３０とでシステムを構成した。第４実施形態では、スレーブＤＢ計算機１３０に代わって、クライアント計算機１００の主記憶装置１０４内に格納され、クライアント計算機１００のＣＰＵ１０３を使って動作するデータキャッシュ（キャッシュメモリシステム）が構成される。

第４実施形態のハードウェア構成を図３５に示す。なお、図１と同一の構成には同一の符号を付し、説明を省略する。図３５に示すように、マスターＤＢ計算機１２０と１つ以上のクライアント計算機１００が通信ネットワーク１１０で接続されている。データキャッシュは、クライアント計算機１００の主記憶装置１０４に格納され、ＣＰＵ１０３を使用して動作する。データベースシステムを利用するアプリケーションはクライアント計算機１００の主記憶装置１０４に格納され、ＣＰＵ１０３を使用して動作し、同じクライアント計算機１００内のデータキャッシュに対して要求を送信する。

第４実施形態のモジュール構成を図３６に示す。なお、図２８と同一の構成には、同一の符号で（所在が同じ場合）、あるいは、同一の符号に「ａ」または「ｂ」の添字を付して（所在が違う場合）、表記している。図３６は第３実施形態を、データキャッシュを使った構成に変更したものである。第３実施形態において通信ネットワーク１１０を通じて外部の計算機（スレーブＤＢ計算機１３０）とデータのやりとりをしていた要求送信部２００は、第４実施形態においては同一計算機内のデータキャッシュ３６００とデータのやりとりをする。データキャッシュ３６００内のモジュールは第３実施形態のスレーブＤＢ計算機１３０内のモジュールとほぼ同一である。

第３実施形態では外部記憶装置１３６内に存在した更新ログバッファ２２２ａと複製データベース２８０４が第４実施形態では主記憶装置１０４内に存在する。なお、データキャッシュ３６００はアプリケーションと独立したプロセスであってもよいし、アプリケーションと同一プロセスであってもよい。データキャッシュ３６００がアプリケーションと独立したプロセスである場合は、要求送信部２００と要求処理部２８０１ａのデータのやりとりはプロセス間通信で行われる。一方、データキャッシュ３６００がアプリケーションと同一プロセスである場合は、要求送信部２００と要求処理部２８０１ａのデータのやりとりは手続き呼び出しで行われる。
また、第１実施形態および第２実施形態においてデータキャッシュを使う場合の構成も、上記と同様にして実現できる。

以上のようにして、マスターＤＢ計算機１２０と１つ以上のクライアント計算機１００内で動作するデータキャッシュでシステムが構成できる。
一般的に、主記憶装置（主記憶装置１０４等）は外部記憶装置（外部記憶装置１３６等）に比べて記憶容量が少なく、大きな容量を必要とすることが多い複製データベース（複製データベース２８０４ａ等）を主記憶装置に格納するのは困難なことがある。しかし、近年は主記憶装置の容量が増加しており（例えば数ギガバイト程度）、大容量のデータを主記憶装置に格納することも可能となってきている。そのような場合には、第４実施形態のシステムの適用も現実的に考えられる。
そして、主記憶装置は外部記憶装置に比べて動作速度が速いので、主記憶装置に複製データベースを格納するデータキャッシュとすることで、データベースのスループットの向上が期待できる。

第４実施形態によれば、スレーブＤＢ計算機１３０を使用する代わりに、複製データベースをクライアント計算機１００の主記憶装置１０４内に保持するデータキャッシュを使用した構成のシステムを実現できる。これにより、要求送信部２００と要求処理部２８０１ａが同一のクライアント計算機１００内に存在するので、それらの間での通信が、通信ネットワーク１１０を経由せずに行われるので、高速化できる。つまり、例えば、Ｗｅｂサービスのようなシステムで同じ利用者による一連の作業（セッションと呼ばれる）が行われる場合などにおいて、特に、処理の高速化を図ることができる。

以上、本発明の実施形態について説明したが、本発明は、これに限定されるものではなく、その趣旨を変えない範囲で実施することができる。ハードウェア、ソフトウェアの具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。

本発明の第１実施形態におけるハードウェア構成図を示す。 本発明の第１実施形態におけるモジュール構成図を示す。 本発明の第１実施形態における原本データベースの例の一部を示す。 本発明の第１実施形態におけるサーバ情報テーブルの例の一部を示す。 本発明の第１実施形態における更新ログバッファの例の一部を示す。 本発明の第１実施形態における複製データベースの例の一部を示す。 本発明の第１実施形態における更新カウンタ表の例の一部を示す。 本発明の第１実施形態におけるマスター要求処理部の動作のフローチャートを示す。 本発明の第１実施形態における要求処理部の動作のフローチャートを示す。 本発明の第１実施形態における更新カウンタ増加部の動作のフローチャートを示す。 本発明の第１実施形態におけるサーバ情報付与部の動作のフローチャートを示す。 本発明の第１実施形態におけるサーバ情報判定部の動作のフローチャートを示す。 本発明の第１実施形態における更新ログ反映判定部の動作のフローチャートを示す。 本発明の第１実施形態における更新カウンタ減少部の動作のフローチャートを示す。 本発明の第１実施形態における更新要求発生時のデータの流れの例を示す。 本発明の第１実施形態におけるクライアント計算機からスレーブＤＢ計算機へ送信されるトランザクションの例を示す。 本発明の第１実施形態におけるスレーブＤＢ計算機からマスターＤＢ計算機へ送信されるトランザクションの例を示す。 本発明の第１実施形態におけるマスターＤＢ計算機からスレーブＤＢ計算機へ送信される更新トランザクションログの例を示す。 本発明の第１実施形態における更新要求発生時の例での各ＤＢ計算機のデータ変遷を示す。 本発明の第１実施形態における更新要求競合発生時のデータの流れの例を示す。 本発明の第１実施形態におけるクライアント計算機からスレーブＤＢ計算機へ送信されるトランザクションの例を示す。 本発明の第１実施形態におけるスレーブＤＢ計算機からマスターＤＢ計算機へ送信されるトランザクションの例を示す。 本発明の第１実施形態におけるマスターＤＢ計算機からスレーブＤＢ計算機へ送信される更新トランザクションログの例を示す。 本発明の第１実施形態における更新要求競合発生時の例での各ＤＢ計算機のデータ変遷を示す。 ２つのＤＢ計算機に続けて更新要求が発生し、お互いに更新ログを送信しあった場合のデータの変遷の例を示す。 ２つのスレーブＤＢ計算機に続けて更新要求が発生し、マスターから送信される更新ログを全て反映した場合のデータの変遷の例を示す。 本発明の第２実施形態における複製データベースの例の一部を示す。 本発明の第３実施形態におけるモジュール構成図を示す。 本発明の第３実施形態における複製データベースの例の一部を示す。 本発明の第３実施形態における要求処理部の動作のフローチャートを示す。 本発明の第３実施形態における更新ログ反映判定部の動作のフローチャートを示す。 本発明の第３実施形態における更新情報管理部の動作のフローチャートを示す。 本発明の第３実施形態における更新要求を処理した直後の複製データベースの例の一部を示す。 本発明の第３実施形態における更新ログを処理した直後の複製データベースの例の一部を示す。 本発明の第４実施形態におけるハードウェア構成図を示す。 本発明の第４実施形態におけるモジュール構成図を示す。

符号の説明

１００ クライアント計算機（外部の計算機）
１２０ マスターＤＢ計算機（第１の情報処理装置）
１３０ スレーブＤＢ計算機（第２の情報処理装置）
２２３ 原本データベース
２２４ サーバ情報テーブル
２３０ 要求処理部
２３１ サーバ情報付与部
２３２ 更新カウンタ増加部（更新情報管理部）
２３３ 更新カウンタ表（更新情報管理部）
２３４ 更新カウンタ減少部（更新情報管理部）
２３５，２８０３ 更新ログ反映判定部（更新反映判定部）
２３７ サーバ情報判定部
２３８，２８０４ 複製データベース
２８０２ 更新情報管理部
２９１０ 更新ログ反映済みポインタ
ＤＢＳ データベースシステム（情報処理システム）

Claims (12)

1. データの集合である原本データベースを管理する第１の情報処理装置と、前記原本データベースの複製である複製データベースを管理する１つ以上の第２の情報処理装置と、を備えて構成され、前記第１の情報処理装置の原本データベースで発生した更新情報を格納する更新ログを前記第２の情報処理装置に送信して前記複製データベースに反映する情報処理システムにおいて、
   前記第２の情報処理装置は、
   外部の計算機から更新要求を受け付けると、該更新要求を前記第１の情報処理装置に送信して前記原本データベースを更新させるとともに、該第２の情報処理装置の複製データベースを更新する要求処理部と、
   前記受け付けた更新要求と対応する更新ログを前記第１の情報処理装置から受信したか否かを、前記複製データベース内のデータごとに管理する更新情報管理部と、
   前記第１の情報処理装置から新規な更新ログを受け付けると、該更新ログに格納されている情報と前記更新情報管理部の管理する情報から、該更新ログが、前記受け付けた更新要求と対応する更新ログよりも新しいか否かを判断し、新しいと判断した場合は、該更新ログの更新内容を前記複製データベースに反映する更新反映判定部と、
   を備えることを特徴とする情報処理システム。
2. 前記第１の情報処理装置は第１のデータベース計算機であり、前記第２の情報処理装置は第２のデータベース計算機であることを特徴とする請求項１に記載の情報処理システム。
3. 前記更新情報管理部は、
   前記複製データベース内のデータごとに対応するカウンタを保持する更新カウンタ表と、
   該第２のデータベース計算機が更新要求の処理時に複製データベースを更新するときに、前記更新カウンタ表の更新対象となるデータと対応する前記カウンタをあらかじめ定められた数だけ増加する更新カウンタ増加部と、
   該第２のデータベース計算機で受信した外部の計算機からの更新要求と対応する更新ログを前記第１のデータベース計算機から受信したときに、前記更新カウンタ表の更新対象となるデータと対応する前記カウンタをあらかじめ定められた数だけ減少する更新カウンタ減少部と、を備え、
   前記更新反映判定部は、
   前記第１のデータベース計算機から新規な更新ログを受け付けた場合、前記更新カウンタ表を参照して、前記更新対象となるデータと対応する前記カウンタの値があらかじめ定められた数値以下であったとき、該更新ログの更新内容を該第２のデータベース計算機の複製データベースに反映する
   ことを特徴とする請求項２に記載の情報処理システム。
4. 前記第２のデータベース計算機の複製データベース内に、前記原本データベースの複製に加えて、データごとに対応するカウンタが保持され、
   前記更新情報管理部は、
   該第２のデータベース計算機が更新要求の処理時に複製データベースを更新するときに、前記複製データベース内の更新対象となるデータと対応する前記カウンタをあらかじめ定められた数だけ増加する更新カウンタ増加部と、
   該第２のデータベース計算機で受信した外部の計算機からの更新要求と対応する更新ログを前記第１のデータベース計算機から受信したときに、該複製データベースの更新対象となるデータと対応する前記カウンタをあらかじめ定められた数だけ減少する更新カウンタ減少部と、を備え、
   前記更新反映判定部は、
   前記第１のデータベース計算機から新規な更新ログを受け付けた場合、前記更新カウンタ表を参照して、前記更新対象となるデータと対応する前記カウンタの値があらかじめ定められた数値以下であったとき、該更新ログの更新内容を該第２のデータベース計算機の複製データベースに反映する
   ことを特徴とする請求項２に記載の情報処理システム。
5. 前記第２のデータベース計算機は、
   前記複製データベース内において、格納するデータの更新をバージョン管理し、
   前記バージョン管理されたデータに対し、更新ログ反映済みのバージョンを示す更新ログ反映済みポインタを前記複製データベース内に保持し、
   前記要求処理部は、
   前記複製データベースを更新する際に、更新対象のデータを複製し、該データの値を更新して次のバージョンのデータを作成し、
   前記更新情報管理部は、
   該第２のデータベース計算機で受信した外部の計算機からの更新要求と対応する更新ログを前記第１のデータベース計算機から受信したときに、該複製データベース内の更新対象となるデータと対応する前記更新ログ反映済みポインタを次のバージョンに変更し、
   前記更新反映判定部は、
   前記第１のデータベース計算機から新規な更新ログを受け付けた場合、前記複製データベースを参照して、前記更新対象となるデータと対応する更新ログ反映済みポインタが最新のバージョンになっていたとき、該更新ログの更新内容を該第２のデータベース計算機の複製データベースに反映する
   ことを特徴とする請求項２に記載の情報処理システム。
6. 前記第１のデータベース計算機の原本データベース内に、前記第２のデータベース計算機の情報を格納するサーバ情報テーブルが保持され、
   前記第２のデータベース計算機は、
   前記サーバ情報テーブルの該第２のデータベース計算機を格納したデータを更新する更新要求を前記第１のデータベース計算機に送信するサーバ情報付与部と、
   前記第１のデータベース計算機から受信した更新ログ中の前記サーバ情報テーブルを更新する更新ログデータから前記第２のデータベース計算機の情報を取得し、更新ログが該第２のデータベース計算機で受信した更新要求と対応する更新ログか否かを判断するサーバ情報判定部と、を備える
   ことを特徴とする請求項２に記載の情報処理システム。
7. データの集合である原本データベースを管理するデータベース計算機と、前記原本データベースの複製である複製データベースを主記憶装置内に保持するデータキャッシュを有する１つ以上のクライアント計算機と、を備えて構成され、前記データベース計算機の原本データベースで発生した更新情報を格納する更新ログを前記クライアント計算機のデータキャッシュに送信して前記複製データベースに反映する情報処理システムにおけるデータ更新方法であって、
   前記データキャッシュは、要求処理部と、更新情報管理部と、更新反映判定部と、を備えており、
   前記要求処理部は、
   データの更新要求を受け付けると、該更新要求を前記データベース計算機に送信して前記原本データベースを更新させるとともに、前記複製データベースを更新し、
   前記更新情報管理部は、
   前記更新要求と対応する更新ログを前記データベース計算機から受信したか否かを、前記複製データベース内のデータごとに管理し、
   前記更新反映判定部は、
   前記データベース計算機から新規な更新ログを受け付けると、該更新ログに格納されている情報と前記更新情報管理部の管理する情報から、該更新ログが、前記受け付けた更新要求と対応する更新ログよりも新しいか否かを判断し、新しいと判断した場合は、該更新ログの更新内容を前記複製データベースに反映する
   ことを特徴とするデータ更新方法。
8. 前記更新情報管理部は、
   前記複製データベース内のデータごとに対応するカウンタを保持する更新カウンタ表と、更新カウンタ増加部と、更新カウンタ減少部と、を備えており、
   前記更新カウンタ増加部は、
   前記更新要求の処理時に前記複製データベースを更新するときに、前記更新カウンタ表の更新対象となるデータと対応する前記カウンタをあらかじめ定められた数だけ増加し、
   前記更新カウンタ減少部は、
   前記更新要求と対応する更新ログを前記データベース計算機から受信したときに、前記更新カウンタ表の更新対象となるデータと対応する前記カウンタをあらかじめ定められた数だけ減少し、
   前記更新反映判定部は、
   前記データベース計算機から新規な更新ログを受け付けた場合、前記更新カウンタ表を参照して、前記更新対象となるデータと対応する前記カウンタの値があらかじめ定められた数値以下であったとき、該更新ログの更新内容を前記複製データベースに反映する
   ことを特徴とする請求項７に記載のデータ更新方法。
9. 前記データキャッシュの複製データベース内に、前記原本データベースの複製に加えて、データごとに対応するカウンタが保持され、
   前記更新情報管理部は、更新カウンタ増加部と、更新カウンタ減少部と、を備えており、
   前記更新カウンタ増加部は、
   前記更新要求の処理時に前記複製データベースを更新するときに、前記複製データベース内の更新対象となるデータと対応する前記カウンタをあらかじめ定められた数だけ増加し、
   前記更新カウンタ減少部は、
   前記更新要求と対応する更新ログを前記データベース計算機から受信したときに、該複製データベースの更新対象となるデータと対応する前記カウンタをあらかじめ定められた数だけ減少し、
   前記更新反映判定部は、
   前記データベース計算機から新規な更新ログを受け付けた場合、前記更新カウンタ表を参照して、前記更新対象となるデータと対応する前記カウンタの値があらかじめ定められた数値以下であったとき、該更新ログの更新内容を前記複製データベースに反映する
   ことを特徴とする請求項７に記載のデータ更新方法。
10. 前記複製データベース内において、格納するデータの更新がバージョン管理され、
    前記バージョン管理されたデータに対し、更新ログ反映済みのバージョンを示す更新ログ反映済みポインタが前記複製データベース内に保持され、
    前記要求処理部は、
    前記複製データベースを更新する際に、更新対象のデータを複製し、該データの値を更新して次のバージョンのデータを作成し、
    前記更新情報管理部は、
    更新要求と対応する更新ログを前記データベース計算機から受信したときに、該複製データベース内の更新対象となるデータと対応する前記更新ログ反映済みポインタを次のバージョンに変更し、
    前記更新反映判定部は、
    前記データベース計算機から新規な更新ログを受け付けた場合、前記複製データベースを参照して、前記更新対象となるデータと対応する更新ログ反映済みポインタが最新のバージョンになっていたとき、該更新ログの更新内容を前記複製データベースに反映する
    ことを特徴とする請求項７に記載のデータ更新方法。
11. 前記原本データベース内に、前記データキャッシュの情報を格納するサーバ情報テーブルが保持されており、
    前記データキャッシュは、サーバ情報付与部と、サーバ情報判定部と、を備えており、
    前記サーバ情報付与部は、
    前記サーバ情報テーブルの該データキャッシュを格納したデータを更新する更新要求を前記データベース計算機に送信し、
    前記サーバ情報判定部は、
    前記データベース計算機から受信した更新ログ中の前記サーバ情報テーブルを更新する更新ログデータから前記データキャッシュの情報を取得し、更新ログが該データキャッシュで受信した更新要求と対応する更新ログか否かを判断する
    ことを特徴とする請求項７に記載のデータ更新方法。
12. 請求項７ないし請求項１１のいずれか１項に記載のデータ更新方法をコンピュータに実行させるためのデータ更新プログラム。
    

Images