JP2013142996A - 分散データベースシステム及びデータ更新・配信方法 - Google Patents

Abstract

【課題】分散データベースシステムに格納された原本データと当該原本データの複製を用いるサーバに格納された複製データとの一貫性を保持すること。
【解決手段】サーバ＃１（３ａ）からのデータ更新要求を任意のエレメント１００（例えば、エレメント＃１（１００ａ））で受け付けて、更新要求された原本データを更新した後に、当該原本データの複製を用いるサーバ＃２（３ｂ）に更新後の原本データを配信し、そのデータ更新要求に対する応答を上記受け付けたエレメント＃１（１００ａ）から返信する。
【選択図】図１

Description

本発明は、分散データベースシステムに格納された原本データを更新等する技術に関する。

３ＧＰＰ（3rd Generation Partnership Project）では、ユーザプロファイルの原本データを集中的に管理するデータ保持サーバが定義されており、収容するユーザプロファイル数が膨大である場合には、複数のデータ保持サーバによりＨＳＳ（分散データベースシステム）が構築される。

ＨＳＳ内の原本データが更新された場合、その原本データを用いて呼処理を行う呼処理サーバに何らかの手段をもって通知することが必要となるが、非特許文献１，２によれば、図１３に示すように、呼処理サーバから購読予約を事前に受け付けておき、データ更新サーバによって原本データが更新された場合には当該購読予約先に更新通知を送信し、その後、当該通知を受けた呼処理サーバからＨＳＳにアクセスして更新後の原本データを取得するＰｕｌｌ取得方式が規定されている。

「3rd Generation Partnership Project; Technical Specification Group Core network and Terminals; IP Multimedia (IM) Subsystem Sh interface; Signalling flows and message contents (Release 11)」、3GPP TS 29.328、V11.0.0、2011-06 「3rd Generation Partnership Project; Technical Specification Group Core network and Terminals; Sh Interface based on the Diameter protocol; Protocol details (Release 11)」、3GPP TS 29.329、V11.0.0、2011-06

しかしながら、先のＰｕｌｌ取得方式によれば、ＨＳＳと呼処理サーバの各データ更新が非同期に実施されるため、ＨＳＳ内のデータ保持サーバは、呼処理サーバにおいてデータ更新が成功したか否かを判断できないという課題があった（データの一貫性についての課題）。

一方、ＨＳＳと呼処理サーバの各データの一致性をリアルタイムに保持するには、ＨＳＳと呼処理サーバでの各データ更新を同期的に実施する必要がある。この場合、図１４に示すように、呼処理サーバでのデータ更新が終了するまで更新されないように、ＨＳＳにおいて対象データをロック（更新不可状態）する必要があった。

しかしながら、例えば、１つの更新要求で複数の原本データを同時に更新する場合には、ＨＳＳ内の全ての原本データをロックしなければならず、例えば２層ロック等の処理が必要であることから、処理の多重化やスループットの低下が懸念されるという課題があった（データの整合性についての課題）。

本発明は、上記課題を鑑みてなされたものであり、分散データベースシステムに格納された原本データと当該原本データの複製を用いるサーバに格納された複製データとの一貫性を保持することを第１の課題とし、原本データや複製データの整合性を確保することを第２の課題とする。

請求項１記載の分散データベースシステムは、原本データをいずれかのエレメントに記憶した複数のエレメントで構成される分散データベースシステムにおいて、第１サーバからのデータ更新要求を任意のエレメントで受け付けて、更新要求された原本データを更新した後に、当該原本データの複製データを用いる第２サーバに更新後の原本データを配信し、前記データ更新要求に対する応答を前記受け付けたエレメントから返信することを特徴とする。

本発明によれば、第１サーバからのデータ更新要求を任意のエレメントで受け付けて、そのデータ更新要求に対する応答を当該受け付けたエレメントから返信するため、分散格納における原本データの位置透過性や、原本データへのアクセスの負荷分散を実現できる。

また、本発明によれば、更新要求された原本データを更新した後に、その原本データの複製データを用いる第２サーバに更新後の原本データを配信するため、従来のＰｕｌｌ取得方式（第２サーバからのアクセスによる原本データの取得）に代えてＰｕｓｈ配信方式（分散データベースシステムからの能動的な原本データの提供）が実現可能となることから、分散データベースシステムに格納された原本データと第２サーバに格納された複製データとの一貫性を保持できる。

請求項２記載の分散データベースシステムは、請求項１記載の分散データベースシステムにおいて、前記原本データを更新し、更新後の原本データを配信するエレメントは、前記第２サーバ毎に１つであることを特徴とする。

本発明によれば、原本データを更新し、更新後の原本データを配信するエレメントは、第２サーバ毎に１つであるため、たとえ同一の原本データに対して同時に複数の第１サーバからデータ変更要求された場合であっても他のエレメントにより更新又は配信されないことから、それら各データの整合性を確保できる。

また、本発明によれば、原本データや複製データに対するデータロックやグローバルロックが不要であることから、分散データベースシステムの性能を向上できる。

請求項３記載の分散データベースシステムは、請求項１又は２記載の分散データベースシステムにおいて、前記更新後の原本データの配信と共に前記複製データの更新完了通知を返信する要求を前記第２サーバに送信し、当該第２サーバから当該更新完了通知を受信した後に、前記応答の返信と共に当該第２サーバでの更新完了を前記第１サーバに通知することを特徴とする。

本発明によれば、更新後の原本データの配信と共に複製データの更新完了通知を返信する要求を第２サーバに送信し、その第２サーバから更新完了通知を受信した後に、上記応答の返信と共に当該第２サーバでの更新完了を第１サーバに通知するため、原本データと複製データとの一貫性をより確実に保持できる。

請求項４記載の分散データベースシステムは、請求項１乃至３のいずれかに記載の分散データベースシステムにおいて、前記複数のエレメントは、それぞれ、前記原本データを記憶しておく記憶手段と、前記第１サーバからデータ更新要求を受け付けた場合に、更新要求された原本データを配信する送信手段を有するエレメントに転送し、当該エレメントから応答を受信した後に、前記データ更新要求に対する応答を返信する受信手段と、前記データ更新要求が転送された場合に、更新要求された原本データを記憶している記憶手段を有するエレメントに原本データの更新を要求し、当該原本データが更新された後に、前記第２サーバに更新後の原本データを配信する送信手段と、を有することを特徴とする。

請求項５記載の分散データベースシステムは、請求項１乃至４のいずれかに記載の分散データベースシステムにおいて、前記複数のエレメントは、それぞれ、前記原本データを記憶しておく記憶手段と、サーバからデータ参照要求を受け付けた場合に、参照要求された原本データを記憶している記憶手段を有するエレメントから当該原本データを取得して前記サーバに返信する受信手段と、を有することを特徴とする。

請求項６記載の分散データベースシステムは、請求項１乃至５のいずれかに記載の分散データベースシステムにおいて、前記複数のエレメントは、それぞれ、前記原本データを記憶しておく記憶手段と、所定の原本データを記憶している記憶手段を有するエレメントから当該原本データを取得して、当該原本データの複製データを用いるサーバに前記取得した原本データで当該複製データを更新する更新要求を定期的又は前記原本データが更新されたタイミングで送信する送信手段と、を有することを特徴とする。

請求項７記載の分散データベースシステムは、請求項４乃至６のいずれかに記載の分散データベースシステムにおいて、任意の前記送信手段で１つの送信手段群を構成し、前記第２サーバに対して前記１つの送信手段群を構成する全ての送信手段がコネクションを確立し、当該１つの送信手段群において１つの送信手段を主とし他の送信手段を従として、同じ送信手段群からの配信は主たる送信手段から行うことを特徴とする。

本発明によれば、任意の送信手段で１つの送信手段群を構成し、第２サーバに対して１つの送信手段群を構成する全ての送信手段がコネクションを確立し、その１つの送信手段群において１つの送信手段を主とし他の送信手段を従として、同じ送信手段群からの配信は主たる送信手段から行うため、原本データの更新処理や第２サーバへの配信処理の冗長化によるシステムの信頼性を向上できる。

請求項８記載の分散データベースシステムは、請求項４乃至７のいずれかに記載の分散データベースシステムにおいて、任意の前記記憶手段で１つの記憶手段群を構成し、前記１つの記憶手段群を構成する全ての記憶手段は同じ原本データを記憶し、当該１つの記憶手段群において１つの記憶手段を主とし他の記憶手段を従として、同じ記憶手段群内での原本データの更新は主たる記憶手段のみが行い、当該更新結果を従たる記憶手段に通知することを特徴とする。

本発明によれば、任意の記憶手段で１つの記憶手段群を構成し、その１つの記憶手段群を構成する全ての記憶手段は同じ原本データを記憶し、その１つの記憶手段群において１つの記憶手段を主とし他の記憶手段を従として、同じ記憶手段群内での原本データの更新は主たる記憶手段のみが行い、その更新結果を従たる記憶手段に通知するため、複数の記憶手段での原本データの冗長化によるシステムの信頼性を向上できる。

請求項９記載のデータ更新・配信方法は、原本データをいずれかのエレメントに記憶した複数のエレメントで構成される分散データベースシステムで行うデータ更新・配信方法において、第１サーバからのデータ更新要求を任意のエレメントで受け付けて、更新要求された原本データを更新した後に、当該原本データの複製データを用いる第２サーバに更新後の原本データを配信し、前記データ更新要求に対する応答を前記受け付けたエレメントから返信することを特徴とする。

本発明によれば、第１サーバからのデータ更新要求を任意のエレメントで受け付けて、そのデータ更新要求に対する応答を当該受け付けたエレメントから返信するため、分散格納における原本データの位置透過性や、原本データへのアクセスの負荷分散を実現できる。

また、本発明によれば、更新要求された原本データを更新した後に、その原本データの複製データを用いる第２サーバに更新後の原本データを配信するため、従来のＰｕｌｌ取得方式（第２サーバからのアクセスによる原本データの取得）に代えてＰｕｓｈ配信方式（分散データベースシステムからの能動的な原本データの提供）が実現可能となることから、分散データベースシステムに格納された原本データと第２サーバに格納された複製データとの一貫性を保持できる。

本発明によれば、分散データベースシステムに格納された原本データと当該原本データの複製を用いるサーバに格納された複製データとの一貫性を保持できる。

分散データベースシステムの全体構成を示す図である。 エレメントで保持される全てのデータ例を示す図である。 センダーファミリーの構成例を示す図である。 ストレージファミリーの構成例を示す図である。 原本データの更新処理フローを示す図である。 更新処理フロー説明時における第１参照図である。 更新処理フロー説明時における第２参照図である。 更新処理フロー説明時における第３参照図である。 原本データの参照処理フローを示す図である。 参照処理フロー説明時における参照図である。 原本データの定期的ｐｕｓｈ配信処理フローを示す図である。 定期的ｐｕｓｈ配信処理フロー説明時における参照図である。 従来におけるデータ更新処理フロー（第１例）を示す図である。 従来におけるデータ更新処理フロー（第２例）を示す図である。

以下、本発明を実施する一実施の形態について図面を用いて説明する。但し、本発明は多くの異なる様態で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。

〔分散データベースシステムの全体構成について〕
図１は、本実施の形態に係る分散データベースシステムの全体構成を示す図である。この分散データベースシステムは、分散データベースシステム１と、複数のサーバ３と、分散データベースシステム１と複数のサーバ３とを通信可能に接続する通信ネットワーク５と、で主に構成される。

分散データベースシステム１は、当該システム内の複数のノード（以下、エレメント）に分散配置された原本データをシステム利用主であるサーバ３が単一のデータベースのように利用可能にしたものであり、本実施の形態において、原本データをいずれかのエレメントに記憶した複数のエレメント１００により構成される。

全てのエレメント１００は、自身以外のエレメント１００との間で相互に通信可能となるように通信路３００を介して接続され、各エレメント１００は、それぞれ、レシーバ（受信手段）１１と、センダー（送信手段）１２と、ストレージ（記憶手段）１３と、で主に構成される。

このようなエレメント１００は、ＣＰＵ等の制御手段やメモリ等の記憶手段により構成される情報処理装置で実現可能であり、背景技術で説明したデータ保持サーバに相当する。

具体的には、例えば、レシーバ１１やセンダー１２を制御手段で構成し、ストレージ１３を記憶手段で構成することが可能である。構成態様によっては、レシーバ１１やセンダー１２に記憶手段を具備させ、ＤＢＭＳ（Database Management System）等で実現する場合にはストレージ１３に制御手段を具備させることも可能である。

なお、図１に示したエレメント１００は、エレメント＃１（１００ａ）〜エレメント＃４（１００ｄ）の４つであるが、分散データベースシステム１において原本データの分散を意識する必要のない透過的環境を提供可能であればよいことから、１つ以上であればよい。

サーバ３は、分散データベースシステム１を利用するシステム利用主であり、背景技術で説明したデータ更新サーバや呼処理サーバに相当する。データ更新サーバの場合には、分散データベースシステム１内の原本データの更新を要求する。一方、呼処理サーバの場合には、分散データベースシステム１内の原本データを取得し、その取得した原本データに基づいて自身のキャッシュデータ（原本データの複製データ）を更新した後に、当該更新後の原本データに基づいて呼処理を実行する。

なお、図１に示したサーバ３は、サーバ＃１（３ａ）とサーバ＃２（３ｂ）の２つであるが、一般に、データ更新サーバや呼処理サーバは１つ以上で構成されることから、１つ以上であればよい。

以下、分散データベースシステム１の機能及び処理動作について説明する。なお、分散データベースシステム１内に格納される原本データとしては、３ＧＰＰで規定されるようなユーザプロファイルが例とされるが、本発明は、分散格納された原本データの位置透過性や、その原本データとキャッシュデータとの一貫性を保持すること等を目的とすることから、何らかの原本データであればよく、その種別については何ら限定されない。

〔分散データベースシステム１の機能について〕
次に、図２〜図４を参照しながら、分散データベースシステム１を構成しているエレメント１００のレシーバ１１、センダー１２、ストレージ１３の各機能について説明する。

なお、図２には、理解を容易にするため、エレメント１００が保持する全てのデータを１つの図面内に記載している。ここでいうデータとは、「配信サーバ対応表」、「加入者単位キー対応表」、「データ分散対応表」、「原本データ」、それら各表内の実データである。但し、図２に示された各表内の具体的なデータは、以降説明するための例示である。

（レシーバの機能について）
最初に、レシーバ１１の機能について説明する。レシーバ１１は、主に以下の機能を具備する。

（１）任意のサーバ３から送信された任意のリクエスト（要求）を受け付けて、そのリクエストに対するレスポンス（応答）を、当該リクエストを受け付けたレシーバ１１からサーバ３に送信（返信）する機能を有する。

（２）任意のサーバ３から送信された原本データ参照リクエストに対して、同一エレメント内のストレージ１３と連携して当該原本データを保持するストレージから原本データを取得する機能を有する。

（３）原本データのｐｕｓｈ配信を必要とする配信サーバ（図１に示すサーバ３）と、当該配信サーバに原本データをｐｕｓｈ配信するセンダーを収容するセンダー収容エレメントとの対応関係を示す「配信サーバ対応表」を全てのレシーバ１１で共有する機能を有する。センダー収容エレメントは、配信サーバ毎に１つ設定されている。

（４）任意のサーバ３から送信された原本データ更新リクエストに対して、「配信サーバ対応表」に示される配信サーバに対応したセンダーへ当該リクエストをリレー（転送）する機能を有する。

（センダーの機能について）
次に、センダー１２の機能について説明する。センダー１２は、主に以下の機能を具備する。

（１）レシーバ１１と連携して原本データ更新リクエストを受け付けて、当該リクエストに対するレスポンスを、同一のレシーバ１１に送信する機能を有する。

（２）同一の原本データに対する複数の原本データ更新リクエストは、受け付け順に逐次処理を行う機能を有する。

（３）更新後の原本データの配信サーバへのｐｕｓｈ配信の要否を判定し、必要な場合は当該原本データのｐｕｓｈ配信を行う機能を有する。

（４）原本データのｐｕｓｈ配信の失敗時に、ストレージ１３内の原本データ更新処理のロールバックを行う機能を有する。

（５）任意のサーバ３に対して、定期的又は原本データが更新されたタイミングで原本データをｐｕｓｈ配信し、当該任意のサーバ３のキャッシュデータのリフレッシュを行う機能を有する。

（６）異なるエレメント１００に収容される複数のセンダー１２でセンダーファミリー（送信手段群）を構成し（図３参照）、各センダー１２の配信サーバに対して、センダーファミリーを構成する全てのセンダーがコネクションを確立する機能を有する。

（７）センダーファミリーを構成するセンダーのうち、１つのセンダーをマスターセンダーとし、その他のセンダーをスレーブセンダーとして、同じセンダーファミリーからの配信サーバへのデータ配信は、マスターセンダーのみが行う機能を有する。

（８）「配信サーバ対応表」の「センダー収容エレメント」には、マスターセンダーを収容するエレメントを記載し、マスターセンダーの障害等により変更する必要が生じた場合は、センダーファミリー内のスレーブセンダーの中から新たなマスターセンダーを選択し、「配信サーバ対応表」の「センダー収容エレメント」の変更をすべてのレシーバに通知する機能を有する。

（９）加入者単位にその加入者が保持するデータスキーマのキーを格納した「加入者単位キー対応表」を保持し、各種データスキーマから加入者が逆引き可能であり、現在操作中のスキーマかどうかをスキーマ単位で判定する機能を有する。

（１０）原本データが加入者単位で構成されている場合、上記（３）のｐｕｓｈ配信、上記（４）のロールバック、上記（５）のリフレッシュ要求等を、加入者単位で処理する機能を有する。

（ストレージの機能について）
次に、ストレージ１３の機能について説明する。ストレージ１３は、主に以下の機能を具備する。

（１）「原本データ」を、キー情報に基づいて分散収容し、管理する機能を有する。「原本データ」は、図２に示したように、原本データを一意に識別するデータ識別子と、データの実体である格納データと、原本データのｐｕｓｈ配信先サーバを特定するための配信サーバ特定情報と、から構成される。

（２）原本データを識別するキー情報と、当該キー情報で識別される原本データを保持するストレージを収容するストレージ収容エレメントとの対応関係を示す「データ分散対応表」を全てのストレージで共有する機能を有する。

なお、原本データを識別するキー情報は、１つの原本データを一意に識別するデータ識別子の記載（例えば、「ＡＡＡｘｘｙｙ１」）でもよいし、複数の原本データの範囲を識別する記載（例えば、「ＡＡＡ」）でもよい。

（３）ストレージ１３間で連携して異なるエレメント１００に収容されるストレージ１３が保持する原本データへのアクセスを行うことにより、レシーバ１１又はセンダー１２に対して、原本データの位置透過性を提供する機能を有する。

（４）異なるエレメント１００に収容される複数のストレージ１３でストレージファミリーを構成し（図４参照）、ストレージファミリー内の全てのストレージは、同じ原本データを収容する機能を有する。

（５）ストレージファミリーを構成するストレージのうち、１つのストレージをマスターストレージとし、その他のストレージをスレーブストレージとして、同じストレージファミリー内での原本データ更新は、マスターストレージのみが行い、更新結果をスレーブストレージに通知して、原本データを更新する機能を有する。

（６）ストレージファミリー内での原本データ参照を、マスターストレージ又はスレーブストレージに対して行う機能を有する。原本データ更新とは異なり、マスターストレージ又はスレーブストレージのいずれに対して行ってもよい。

（７）「データ分散対応表」の「ストレージ収容エレメント」には、マスターストレージを収容するエレメントを記載し、マスターストレージの障害等により変更する必要が生じた場合は、ストレージファミリー内のスレーブストレージの中から新たなマスターストレージを選択し、「データ分散対応表」の「ストレージ収容エレメント」の変更をすべてのストレージに通知する機能を有する。

（８）原本データスキーマ種別毎に、ストレージを独立とする機能を有する。例えば、スキーマＡのストレージファミリー、スキーマＢのストレージファミリーなどである。

〔分散データベースシステムの全体動作について〕
（原本データの更新処理について）
引き続き、図５〜図８を参照しながら、サーバ＃１（３ａ）から分散データベースシステム１に対する原本データの更新処理について説明する。

最初に、図５、図６に示すように、ステップＳ１０１において、サーバ＃１（３ａ）から、「ＡＡＡｘｘｙｙ１」で識別される格納データを「ｘｘｙ」に更新するリクエスト電文が、分散データベースシステム１を構成する例えばエレメント＃１（１００ａ）のレシーバ＃１（１１ａ）に通知される。

なお、どのサーバ３からのリクエストをどのレシーバ１１に送信するかについては、サーバ３側に特定のレシーバ１１を送信先として設定してもよい。その他、サーバ３側に分散データベースシステム１を送信先として設定し、分散データベースシステム１がサーバ３からのリクエストを受信すると、分散データベースシステム１内で受信したリクエストをいずれかのレシーバ１１に振り分けることとしてもよい。

次に、ステップＳ１０２において、レシーバ＃１（１１ａ）は、同じエレメント内のストレージ＃１（１３ａ）に対して、通知されたデータ識別子で識別される原本データを蓄積しているストレージを収容するエレメントの特定（ストレージ解決）を要求する。

次に、ステップＳ１０３において、ストレージ＃１（１３ａ）は、保持している「データ分散対応表」により、レシーバ＃１（１１ａ）から通知されたデータ識別子で識別される原本データを蓄積しているストレージを収容するエレメントであるエレメント＃３（１００ｃ）を特定する。

次に、ステップＳ１０４において、ストレージ＃１（１３ａ）は、エレメント＃３（１００ｃ）内のストレージ＃３（１３ｃ）に対して、「ＡＡＡｘｘｙｙ１」で識別される原本データの取得を要求する。

次に、ステップＳ１０５において、ストレージ＃３（１３ｃ）は、ストレージ＃１（１３ａ）から通知されたデータ識別子で識別される原本データを取得する。

次に、ステップＳ１０６において、ストレージ＃３（１３ｃ）は、取得した原本データをストレージ＃１（１３ａ）に通知する。

次に、ステップＳ１０７において、ストレージ＃１（１３ａ）は、通知された原本データをレシーバ＃１（１１ａ）に通知する。

次に、図５、図７に示すように、ステップＳ１０８において、レシーバ＃１（１１ａ）は、通知された原本データに含まれる配信サーバ特定情報からサーバ＃２（３ｂ）を取得し、保持している「配信サーバ対応表」により、サーバ＃２（３ｂ）に対して送信（原本データのｐｕｓｈ配信）を行うセンダーを収容するエレメントであるエレメント＃２（１００ｂ）を特定する（センダー解決）。

ここで、サーバ＃２に対して１つのエレメント（エレメント＃２）が特定されるので、複数のエレメントが特定されないことから、原本データやキャッシュデータの整合性を確保できる。

次に、ステップＳ１０９において、レシーバ＃１（１１ａ）は、エレメント＃２（１００ｂ）内のセンダー＃２（１２ｂ）に対して、ステップＳ１０１でサーバ＃１（３ａ）から通知されたリクエスト電文をリレー（転送）する。

次に、ステップＳ１１０において、センダー＃２（１２ｂ）は、リクエスト電文中の「ＡＡＡｘｘｙｙ１」をキーとして、「加入者単位キー対応表」で当該キーのｓｔａｔｕｓを確認し、未使用であれば更新中に変更し、同じエレメント内のストレージ＃２（１３ｂ）に対して、リレーされたデータ識別子で識別される格納データの更新を要求する。

次に、ステップＳ１１１において、ストレージ＃２（１３ｂ）は、保持している「データ分散対応表」により、レシーバ＃１（１１ａ）からリレーされたデータ識別子を含むキー情報で識別される原本データを蓄積しているストレージを収容するエレメントであるエレメント＃３（１００ｃ）を取得する。

次に、ステップＳ１１２において、ストレージ＃２（１３ｂ）は、エレメント＃３（１００ｃ）内のストレージ＃３（１３ｃ）に対して、「ＡＡＡｘｘｙｙ１」で識別される原本データに含まれる格納データを「ｘｘｙ」に更新する要求を行う。

次に、ステップＳ１１３において、ストレージ＃３（１３ｃ）は、ストレージ＃２（１２ｃ）から通知されたデータ識別子で識別される原本データに含まれる格納データを「ｘｘｘ」から「ｘｘｙ」に更新し、更新後の原本データを取得する。

次に、ステップＳ１１４において、ストレージ＃３（１３ｃ）は、取得した更新後の原本データをストレージ＃２（１２ｃ）に通知する。

次に、ステップＳ１１５において、ストレージ＃２（１２ｃ）は、通知された更新後の原本データをセンダー＃２（１２ｂ）に通知する。

次に、図５、図８に示すように、ステップＳ１１６において、センダー＃２（１２ｂ）は、ステップＳ１０９でレシーバ＃１（１１ａ）からリレーされたリクエスト電文中の操作対象データ、操作種別、送信元情報をもとに、サーバ＃２（３ｂ）が保持するキャッシュデータへの原本データのｐｕｓｈ配信の要否を判定する。

次に、ステップＳ１１７において、ステップＳ１１６でサーバ＃２（３ｂ）が保持するキャッシュデータへの原本データのｐｕｓｈ配信が必要と判定された場合、センダー＃２（１２ｂ）は、更新後の原本データをサーバ＃２（３ｂ）に配信する（ｐｕｓｈ配信）と共に、サーバ＃２（３ｂ）のキャッシュデータの更新終了通知（更新完了通知）を返信する要求を送信する。

このとき、ある加入者の原本データのみ更新されている場合には、当該更新された加入者の原本データのみをｐｕｓｈ配信するようにしても良い（原本データの加入者単位配信）。

次に、ステップＳ１１８において、サーバ＃２（３ｂ）は、通知された更新後の原本データをもとに、保持するキャッシュデータを更新する。

次に、ステップＳ１１９において、サーバ＃２（３ｂ）は、当該キャッシュデータの更新終了通知（更新完了通知）を、センダー＃２（１２ｂ）に通知する。

次に、ステップＳ１２０において、センダー＃２（１２ｂ）は、サーバ＃２（３ｂ）から更新終了通知を受信した後に、「加入者単位キー対応表」で当該キーのｓｔａｔｕｓを更新し、ステップＳ１０９でレシーバ＃１（１１ａ）からリレーされたリクエスト電文に対し、原本データの更新が正常に終了した旨のレスポンスを当該レシーバ＃１（１１ａ）にリレーする。

最後に、ステップＳ１２１において、レシーバ＃１（１１ａ）は、ステップＳ１０１において通知されたリクエスト電文に対して、センダー＃２（１１ｂ）からリレーされたレスポンスをサーバ＃１（３ａ）に通知すると共に、サーバ＃２（３ｂ）でのキャッシュデータの更新が正常に終了（完了）した旨のレスポンスも通知する。

なお、ステップＳ１１６において、サーバ＃２（３ｂ）が保持するキャッシュデータへの原本データのｐｕｓｈ配信が不要と判断した場合は、ステップＳ１１７〜ステップＳ１１９は省略される。

また、ステップＳ１１０〜ステップＳ１２０における原本データの更新中は、同一のデータ識別子で識別される原本データの新たな更新要求は、先の更新が終了するまでステップＳ１１０のセンダー＃２（１２ｂ）にて待ち合わせる。

また、ステップＳ１１３において、ストレージ＃３（１３ｃ）は、更新すべき原本データを仮登録しておき、ステップＳ１１４〜ステップＳ１１９において、サーバ＃２（３ｂ）が保持するキャッシュデータへのｐｕｓｈ配信の正常終了をセンダー＃２（１２ｂ）が通知された後、ステップＳ１１０〜ステップＳ１１３を再度実施し、ストレージ＃３（１３ｃ）は、更新すべき原本データを本登録する形態も可能である。

また、ステップＳ１１０で更新中に他の電文を受信した場合、その電文で処理するスキーマが使用中でなければ処理は続行できるが、処理するスキーマが使用中の場合には電文の処理をセンダー内で待ち合わせることとなる。

（原本データの参照処理について）
次に、図９、図１０を参照しながら、サーバ＃１（３ａ）から分散データベースシステム１に対する原本データの参照処理について説明する。

最初に、ステップＳ２０１において、サーバ＃１（３ａ）から「ＡＡＡｘｘｙｙ１」で識別される原本データを参照するリクエスト電文が、分散データベースシステム１を構成するエレメント＃１（１００ａ）のレシーバ＃１（１１ａ）に通知される。

次に、ステップＳ２０２において、レシーバ＃１（１１ａ）は、同じエレメント内のストレージ＃１（１３ａ）に対して、通知されたデータ識別子で識別される原本データを蓄積しているストレージを収容するエレメントの特定（ストレージ解決）を要求する。

次に、ステップＳ２０３において、ストレージ＃１（１３ａ）は、保持している「データ分散対応表」により、レシーバ＃１（１１ａ）から通知されたデータ識別子を含むキー情報で識別される原本データを蓄積しているストレージを収容するエレメントであるエレメント＃３（１３ｃ）を特定する。

次に、ステップＳ２０４において、ストレージ＃１（１３ａ）は、エレメント＃３（１００ｃ）内のストレージ＃３（１３ｃ）に対して、「ＡＡＡｘｘｙｙ１」で識別される原本データの取得を要求する。

次に、ステップＳ２０５において、ストレージ＃３（１３ｃ）は、ストレージ＃１（１３ａ）から通知されたデータ識別子で識別される原本データを取得する。

次に、ステップＳ２０６において、ストレージ＃３（１３ｃ）は、取得した原本データをストレージ＃１（１３ａ）に通知する。

次に、ステップＳ２０７において、ストレージ＃１（１３ａ）は、通知された原本データをレシーバ＃１（１１ａ）に通知する。

最後に、ステップＳ２０８において、レシーバ＃１（１１ａ）は、ステップＳ２０１において通知されたリクエスト電文に対して、原本データの参照結果を含むレスポンスをサーバ＃１（３ａ）に通知する。

（キャッシュデータのリフレッシュ処理について）
次に、図１１、図１２を参照しながら、任意のエレメント１００が定期的又は原本データが更新されたタイミングで原本データを取得し、当該原本データのキャッシュデータを保持するサーバ３に配信する、キャッシュデータのリフレッシュ処理について説明する。

最初に、ステップＳ３０１において、センダー＃１（１２ａ）は、例えば予め設定された周期で、同じエレメント内のストレージ＃１（１３ａ）に対して、予め設定された「ＡＡＡｘｘｙｙ１」で識別される原本データを蓄積しているストレージを収容するエレメントの特定（ストレージ解決）を要求する。

次に、ステップＳ３０２において、ストレージ＃１（１３ａ）は、保持している「データ分散対応表」により、センダー＃１（１２ａ）から通知されたデータ識別子を含むキー情報で識別される原本データを蓄積しているストレージを収容するエレメントであるエレメント＃３（１３ｃ）を特定する。

次に、ステップＳ３０３において、ストレージ＃１（１３ａ）は、エレメント＃３（１００ｃ）内のストレージ＃３（１３ｃ）に対して、「ＡＡＡｘｘｙｙ１」で識別される原本データの取得を要求する。

次に、ステップＳ３０４において、ストレージ＃３（１３ｃ）は、ストレージ＃１（１３ａ）から通知された「ＡＡＡｘｘｙｙ１」で識別される原本データを取得する。

次に、ステップＳ３０５において、ストレージ＃３（１３ｃ）は、取得した原本データをストレージ＃１（１３ａ）に通知する。

次に、ステップＳ３０６において、ストレージ＃１（１３ａ）は、通知された原本データをセンダー＃１（１２ａ）に通知する。

次に、ステップＳ３０７において、センダー＃１（１２ａ）は、通知された原本データに含まれる配信サーバ特定情報からサーバ＃１（３ａ）を取得し、原本データの参照結果によるキャッシュデータのリフレッシュを要求するリクエスト電文（取得した原文データでキャッシュデータを更新する更新要求）を当該サーバ＃１（３ａ）に通知する。

最後に、ステップＳ３０８において、サーバ＃１（３ａ）は、通知されたリクエスト電文に対して、リフレッシュ完了のレスポンスをセンダー＃１（１２ａ）に通知する。

以上より、本実施の形態によれば、サーバ＃１（３ａ）からの原本データ更新リクエストを任意のエレメントで受け付けて、そのデータ更新リクエストに対するレスポンスを当該受け付けたエレメントから返信するので、分散格納における原本データの位置透過性や、原本データへのアクセスの負荷分散を実現できる。

また、本実施の形態によれば、更新リクエストされた原本データを更新した後に、その原本データのキャッシュデータを用いるサーバ＃２（３ｂ）に更新後の原本データを配信するので、従来のＰｕｌｌ取得方式（サーバ＃２（３ｂ）からのアクセスによる原本データの取得）に代えてＰｕｓｈ配信方式（分散データベースシステム１からの能動的な原本データの提供）が実現可能となることから、分散データベースシステム１に格納された原本データとサーバ＃２（３ｂ）に格納されたキャッシュデータとの一貫性を保持できる。

また、本実施の形態によれば、原本データを更新し、更新後の原本データを配信するエレメント１００をサーバ３毎に１つに限定している（１つのサーバ＃２（３ｂ）に対して１つのエレメント＃３（１００ｃ）（図２の「配信サーバ対応表」参照））ので、たとえ同一の原本データに対して同時に複数のサーバ＃１（３ａ）から原本データ変更リクエストされた場合であっても他のエレメントにより更新又は配信されないことから、原本データやキャッシュデータの整合性を確保できる。

ここで、あるサーバ３が保持するキャッシュデータが１種類であれば原本データを保持するエレメント１００でデータ操作を実施すればよいが、一般的にサーバ毎に複数種類のキャッシュデータが存在し、それぞれのキャッシュデータに対する原本データが異なるエレメント１００で保持されている場合でも、それらのデータを更新するエレメント１００をサーバ３毎に別に定義・限定することにより同様の対応が可能となる。

また、本実施の形態によれば、原本データやキャッシュデータに対するデータロックやグローバルロックが不要であることから、分散データベースシステム１の性能を向上できる。

また、本実施の形態によれば、更新後の原本データの配信と共にキャッシュデータの更新終了通知を返信する要求をサーバ＃２（３ｂ）に送信し、そのサーバ＃２（３ｂ）から更新終了通知を受信した後に、原本データ更新リクエストに対するレスポンスの返信と共に当該サーバ＃２（３ｂ）での更新終了をサーバ＃１（３ａ）に通知するので、原本データとキャッシュデータとの一貫性をより確実に保持できる。

また、本実施の形態によれば、任意のセンダー１２で１つのセンダーファミリーを構成し、サーバ＃２（３ｂ）に対して１つのセンダーファミリーを構成する全てのセンダー１２がコネクションを確立し、その１つのセンダーファミリーにおいて１つのセンダーをマスターセンダーとし、他のセンダーをスレーブセンダーとして、同じセンダーファミリーからの配信はマスターセンダーから行うので、原本データの更新処理やサーバ＃２（３ｂ）への配信処理の冗長化によるシステムの信頼性を向上できる。

また、本実施の形態によれば、任意のストレージ１３で１つのストレージファミリーを構成し、その１つのストレージファミリーを構成する全てのストレージは同じ原本データを記憶し、その１つのストレージファミリーにおいて１つのストレージをマスターストレージとし、他のストレージをスレーブストレージとして、同じストレージファミリー内での原本データの更新はマスターストレージのみが行い、その更新結果をスレーブストレージに通知するので、複数のストレージ１３での原本データの冗長化によるシステムの信頼性を向上できる。

１…分散データベースシステム
３…サーバ
５…通信ネットワーク
１００…エレメント
１１…レシーバ（受信手段）
１２…センダー（送信手段）
１３…ストレージ（記憶手段）
３００…通信路
Ｓ１０１〜Ｓ１２１、Ｓ２０１〜Ｓ２０８、Ｓ３０１〜Ｓ３０８…ステップ

Claims (9)

1. 原本データをいずれかのエレメントに記憶した複数のエレメントで構成される分散データベースシステムにおいて、
   第１サーバからのデータ更新要求を任意のエレメントで受け付けて、更新要求された原本データを更新した後に、当該原本データの複製データを用いる第２サーバに更新後の原本データを配信し、前記データ更新要求に対する応答を前記受け付けたエレメントから返信することを特徴とする分散データベースシステム。
2. 前記原本データを更新し、更新後の原本データを配信するエレメントは、
   前記第２サーバ毎に１つであることを特徴とする請求項１記載の分散データベースシステム。
3. 前記更新後の原本データの配信と共に前記複製データの更新完了通知を返信する要求を前記第２サーバに送信し、当該第２サーバから当該更新完了通知を受信した後に、前記応答の返信と共に当該第２サーバでの更新完了を前記第１サーバに通知することを特徴とする請求項１又は２記載の分散データベースシステム。
4. 前記複数のエレメントは、それぞれ、
   前記原本データを記憶しておく記憶手段と、
   前記第１サーバからデータ更新要求を受け付けた場合に、更新要求された原本データを配信する送信手段を有するエレメントに転送し、当該エレメントから応答を受信した後に、前記データ更新要求に対する応答を返信する受信手段と、
   前記データ更新要求が転送された場合に、更新要求された原本データを記憶している記憶手段を有するエレメントに原本データの更新を要求し、当該原本データが更新された後に、前記第２サーバに更新後の原本データを配信する送信手段と、
   を有することを特徴とする請求項１乃至３のいずれかに記載の分散データベースシステム。
5. 前記複数のエレメントは、それぞれ、
   前記原本データを記憶しておく記憶手段と、
   サーバからデータ参照要求を受け付けた場合に、参照要求された原本データを記憶している記憶手段を有するエレメントから当該原本データを取得して前記サーバに返信する受信手段と、
   を有することを特徴とする請求項１乃至４のいずれかに記載の分散データベースシステム。
6. 前記複数のエレメントは、それぞれ、
   前記原本データを記憶しておく記憶手段と、
   所定の原本データを記憶している記憶手段を有するエレメントから当該原本データを取得して、当該原本データの複製データを用いるサーバに前記取得した原本データで当該複製データを更新する更新要求を定期的又は前記原本データが更新されたタイミングで送信する送信手段と、
   を有することを特徴とする請求項１乃至５のいずれかに記載の分散データベースシステム。
7. 任意の前記送信手段で１つの送信手段群を構成し、
   前記第２サーバに対して前記１つの送信手段群を構成する全ての送信手段がコネクションを確立し、当該１つの送信手段群において１つの送信手段を主とし他の送信手段を従として、同じ送信手段群からの配信は主たる送信手段から行うことを特徴とする請求項４乃至６のいずれかに記載の分散データベースシステム。
8. 任意の前記記憶手段で１つの記憶手段群を構成し、
   前記１つの記憶手段群を構成する全ての記憶手段は同じ原本データを記憶し、当該１つの記憶手段群において１つの記憶手段を主とし他の記憶手段を従として、同じ記憶手段群内での原本データの更新は主たる記憶手段のみが行い、当該更新結果を従たる記憶手段に通知することを特徴とする請求項４乃至７のいずれかに記載の分散データベースシステム。
9. 原本データをいずれかのエレメントに記憶した複数のエレメントで構成される分散データベースシステムで行うデータ更新・配信方法において、
   第１サーバからのデータ更新要求を任意のエレメントで受け付けて、更新要求された原本データを更新した後に、当該原本データの複製データを用いる第２サーバに更新後の原本データを配信し、前記データ更新要求に対する応答を前記受け付けたエレメントから返信することを特徴とするデータ更新・配信方法。

Images