JP7098007B2 - データベースのための遠隔データ同期方法及び装置 - Google Patents

Description

本願はデータベース技術に関し、特にデータベースのための遠隔データ同期方法及び装置に関する。

各所に展開されるデータベース間におけるデータの同期には、普通、データベース関連アプリケーションが関与する。データの同期を必要とするツーエンドでのデータベースが比較的互いに遠く離れていると、従来のデータベース同期技術では同期遅延が拡大し、同期効率は低下してしまう。また、ツーエンドで同一のオブジェクトを変更すると、大幅な遅延によってデータベース側でデータ衝突を生じる可能性があり、それによって、正確なデータ修正をデータベースが拒否し、ツーエンドでのデータベースのデータに不整合が生じ、信頼性は低下する。

上記に鑑み、本願は、高速で信頼性の高いデータ同期を実現するために、データベースのための遠隔データ同期方法及び装置を提供する。

具体的に、本発明は以下の技術的解決により実施される。

第１の態様では、データベースのための遠隔データ同期方法が提供され、当該方法はサービスアプリケーションによって実行され、データベースはサービスアプリケーションのデータを記憶するために用いられ、当該方法は：
データ更新イベントで更新されたサービスデータを取得し、データ更新イベントに対応するイベントバージョンを生成し、サービスデータとイベントバージョンとをイベントオブジェクト内にカプセル化するステップと；
ピアエンドのサービスアプリケーションが、イベントバージョンに従って、データ更新イベントが有効であると判定する際に、ピアエンドのデータベースがサービスデータに従って更新されるようにするために、イベントオブジェクトをピアエンドのサービスアプリケーションに伝送するステップと；を備える。

第２の態様では、データベースのための遠隔データ同期方法が提供され、当該方法はサービスアプリケーションによって実行され、データベースは前記サービスアプリケーションのデータを記憶するために用いられ、当該方法は：
ピアエンドのサービスアプリケーションが送信したイベントオブジェクトを受信するステップであって、イベントオブジェクトはデータ更新イベントで更新されたサービスデータと、データ更新イベントに対応するイベントバージョンとを含み；
イベントバージョンに従いピアエンドのデータ更新イベントが有効であると判定する際に、データ更新イベントで更新されたサービスデータに従って、ローカルデータベースを更新するステップ；を備える。

第３の態様では、データベースのための遠隔データ同期装置が提供され、当該装置はサ
ービスアプリケーション内に配設され、データベースはサービスアプリケーションのデータを記憶するために用いられ、当該装置は：
データ更新イベントで更新されたサービスデータを取得し、データ更新イベントに対応するイベントバージョンを生成し、サービスデータとイベントバージョンとをイベントオブジェクト内にカプセル化するように構成されたイベントカプセル化モジュールと；
ピアエンドのサービスアプリケーションが、イベントバージョンに従って、データ更新イベントが有効であると判定した際に、ピアエンドのデータベースがサービスデータに従って更新されるようにするために、イベントオブジェクトをピアエンドのサービスアプリケーションへ伝送するように構成されたイベント送信モジュールと；を備える。

第４の態様では、データベースのための遠隔データ同期装置が提供され、当該装置はサービスアプリケーション内に配設され、データベースはサービスアプリケーションのデータを記憶するために用いられ、当該装置は：
ピアエンドのサービスアプリケーションが送信したイベントオブジェクトを受信するように構成されたイベント受信モジュールであって、イベントオブジェクトは、データ更新イベントにて更新されたサービスデータと、データ更新イベントに対応したイベントバージョンとを備える、イベント受信モジュールと；
イベントバージョンに従いピアエンドのデータ更新イベントが有効であると判定された際に、データ更新イベントにて更新されたサービスデータに従って、ローカルデータベースを更新するように構成されたデータ更新モジュールと；を備える。

本願で提供されるデータベースのための遠隔データ同期方法及び装置によれば、データ更新情報の高速伝送は、サービスアプリケーションが更新済みデータとイベントバージョンとをイベントオブジェクト中へカプセル化した後、このイベントオブジェクトをピアエンドアプリケーションへ伝送することにより実現され、さらに、データ更新イベントの発生順序をイベントバージョンにより特定することにより、高速で信頼性のあるデータ同期が保証される。

一の実施例におけるデータ同期のアプリケーションシナリオを示す。 一の実施例におけるデータ同期のプラットフォーム構造を示す。 一の実施例におけるデータ同期のイベント送信側エンドでの実行フローを示す。 一の実施例におけるサービスアプリケーションの概略構造図である。 一の実施例におけるデータ同期のイベント受信側エンドでの実行フローを示す。 一の実施例における遠隔データ同期装置の構造図である。

ここでは、例示の実施の形態を、図に示すその実施例を用いて詳細に説明する。特に記載のない限り、以下の説明で図を参照する場合、各図を通じ同一の符号は同一又は類似の要素を示す。以下の例示の実施の形態で述べる実施は、本願と一致する全ての実施を表すものではない。むしろ、これらの実施は、添付の特許請求の範囲で詳述され、本発明のいくつかの態様と一致する、装置及び方法の単なる例に過ぎない。

図１はデータ同期のアプリケーションシナリオを示す。図１に示すように、「サービスアプリケーション」とは、ユーザ情報を取得及び記憶すること、例えば、アリペイ（Ａｌｉｐａｙ（商標））ユーザの、アカウント、電話番号、その他のユーザ情報を記憶することを目的としたアプリケーションであると仮定する。このサービスアプリケーションは、場所Ａと場所Ｂの両方で展開され、この２つの場所は、中国とアメリカ、河北省と江蘇省などのように互いに遠く離れている。サービスアプリケーションのユーザ情報はデータベースに記憶される。例えば、サービスアプリケーションが場所Ａで取得したユーザ情報（
例えば、Ａｌｉｐａｙ（商標）のウェブサイト上のユーザ登録から導出したユーザ情報）はデータベースＡに記憶される一方、場所Ｂで取得したユーザ情報はデータベースＢに記憶される。サービス要求に基づき、これら２つの場所におけるデータベースのデータの整合性を取るために、場所Ａで取得したユーザ情報は場所Ｂと同期させる必要があり、同様に、場所Ｂで取得したユーザ情報は場所Ａと同期させる必要があるため、データベースＡとデータベースＢとの間の遠隔データの同期が必要となる。

この実施の形態の遠隔データの同期方法は、データの同期処理がアプリケーション層すなわちサービスアプリケーションにより実行される（図１の実線で示すように、データの同期が２つの場所のサービスアプリケーション間で生じる）という点で、データベース間でのデータの同期モード（図１の点線で示すように、データ同期は、データベースＡとデータベースＢとの間で直接実行される）とは異なる。以下、データベース層による同期とアプリケーション層による同期とを、遅延パフォーマンスと信頼性の視点から比較する。

遅延パフォーマンス：データベースは、標準同期モードをデータベース同期メカニズムとして採用しているのが普通である。例えば、データベースに記憶された情報が更新されたかどうかを一定の間隔でチェックし、更新された場合には、更新されたデータがその時間間隔内にピアエンドへ伝送される。さらに、伝送モードについては、一つのユーザデータ内のユーザ名の変更を例に挙げて示す。このユーザ名をデータベースが変更する場合、複数のデータベース指示（例えば、複数のＳＱＬ文）を実行してデータ更新を実現することができ、また、ピアエンドとの同期時に、これら複数のデータベース指示もピアエンドへ伝送されねばならず、さらに、複数のデータベース指示はその実行順序に従ってピアエンドへ送信されねばならない（例えば、これら指示の一つの受信に成功したピアエンドからのフィードバックを受信してから次の指示を送信する）。これらのすべての要因が原因で、ピアエンドのデータベースへのデータ伝送速度が相対的に遅くなる、特に、このデータ伝送速度は遠隔での（このような長距離の）データ同期では劇的に低下してしまうことになる。

引き続き、この実施の形態のデータ同期方法では、データ更新が発生する度に、サービスアプリケーションは更新済みデータをリアルタイムで即座にピアエンドへ送信する能力がある。そして、伝送モードになった場合、サービスアプリケーションは、このデータ更新に関する情報をサービスレベルで取得することができる。例えば、より具体的でオペレーショナルレベル（operational level）のＳＱＬ文ではなく、このデータ更新の結果の方が注視される。例えば、複数のデータベース指示を実行すると、一つのユーザデータのユーザ名が変更され、その他にも、サービスアプリケーションは、例えば変更されたユーザ名が属する一つのユーザデータなどのより多くの情報をサービスレベルで取得し、このデータ更新イベントの発生時間をマーク付けすることが可能である。すなわち、サービスアプリケーションがこのデータ更新全体を一つのイベントとみなし、ピアエンドへの伝送時に、このイベントのデータ更新結果をピアエンドへ一度に直接伝送することができるので、より簡潔で高速となる。

信頼性：データベース同期の従来のメカニズムには、データ同期を実行するツーエンドがデータベース文書を同時に修正しようとする間際に、ツーエンドでのデータ更新の発生順序をデータベース自体が判定することは非常に難しいという欠陥があり、この事実により、データベースが本来は正確なこれらのデータ更新をデータの衝突と見なして拒否してしまうという状況を引き起こす。この実施の形態では、サービスアプリケーション層は、ローカルエンドにおけるデータ更新のタイムマークを記録でき、さらに、様々なデータ更新の順序をタイムマークに応じて判断し、最新データを選択してこれをデータベースに更新することができる。すなわち、アプリケーション層はより多くの処理を実行する能力があり、データベースのデータ同期をより信頼性の高いものにすることができる。

上の説明に基づき、本願の実施の形態における遠隔データの同期方法はサービスアプリケーションによって実行される。図２は、このデータ同期方法の原理を例証する。ここで、場所ＡのデータベースＡにおいてデータ更新が発生し、次に、データを場所Ａから場所Ｂへ同期させる必要があると仮定する。このとき、場所Ａのサービスアプリケーションがデータ同期の送信側エンドとして機能し、場所Ｂにおけるサービスアプリケーションがデータ同期の受信側エンドとして利用される。図２は、送信側エンドとして機能するサービスアプリケーション及び受信側エンドとして機能するサービスアプリケーションのそれぞれが含む処理モジュールを示す。ここで留意すべきは、データを場所Ｂから場所Ａに同期させる場合、図２に示すように、場所Ｂのサービスアプリケーションは場所Ａのサービスアプリケーションの様々なモジュールを含み、同様に、場所Ａのサービスアプリケーションは場所Ｂのサービスアプリケーションの様々なモジュールを含む、すなわち逆方向への一貫したフローがあるということである。以下の実施の形態では、両方向のうちの一方向でのデータ同期の処理手順についてのみ説明する。

図３は、送信側エンドとして機能する場所Ａのサービスアプリケーションが実行する遠隔データの同期方法のフローを示す。この方法は、図２及び図３に示すように、以下のステップを含んでよい。

３０１．サービスアプリケーションが、サービスデータを変更するデータ更新イベントを実行する。

実施例として、サービスアプリケーションは、ユーザ名をＪｉｍ（ジム）からＴｏｍ（トム）に変更する要求を、アプリケーションサイトを介してユーザから受信すると、サービスアプリケーションはデータベースを修正することができるようになる。例えば、アプリケーションは、データベースインターフェースを介してデータベースを操作することで、上述のユーザ名の変更を終えることができる。このデータ変更は一の「データ更新イベント」と呼ぶことができる。

この実施の形態では、データベースにデータ文書が記憶されており、各データ文書はこれに記憶されたユーザ情報を含む。データベース内の多種多様なユーザ情報はそれぞれ異なる行に記憶でき、また、一つ一つの行情報はデータ記憶ユニットと呼ぶことができる。例えば、第１データ記憶ユニットは、ユーザＹ１の情報、例えばＵｓｅｒ：｛ｉｄ＝１，ｎａｍｅ＝Ｊｉｍ｝を記憶するために用いられる。当然ながら、このユニットはさらに多くの情報、例えばＵｓｅｒ：｛ｉｄ＝１，ｎａｍｅ＝Ｊｉｍ，ｐｈｏｎｅ＝１３２＊＊＊＊１１１２｝を含んでもよい。第２データ記憶ユニットは、ユーザＹ２の情報、例えばＵｓｅｒ：｛ｉｄ＝２，ｎａｍｅ＝Ｍａｒｙ｝を記憶するために用いられる。ここで、ユーザ情報中のｉｄは、異なるサービスデータを区別するために用いられる「サービスメインキー」と呼ぶことができ、この実施の形態では、異なるｉｄを用いて異なるユーザ情報を区別する。１人のユーザの情報しかない場合は、サービスメインキーを用いなくてよい。

このステップでは、データ更新イベントにて実行するサービスデータの変更を、一のユーザ情報中のデータの一部にすることもできる。例えば、ユーザ情報Ｕｓｅｒ：｛ｉｄ＝１，ｎａｍｅ＝Ｊｉｍ，ｐｈｏｎｅ＝１３２＊＊＊＊１１１２｝のうち名前だけを修正できる。しかし、ユーザ情報を記憶するために用いるこの実施の形態のアプリケーションサービスに関し、この実施の形態は、上で述べたユーザ情報の全体を一つのサービスデータとして参照できる。図２に示すように、サービスデータの変更は、サービスアプリケーション内のデータ変更モジュールによって実行できる。

３０２．サービスアプリケーションは、データ更新イベントで更新されたサービスデー
タを取得し、このデータ更新イベントに対応するイベントバージョンを生成し、サービスデータとイベントバージョンをイベントオブジェクト内にカプセル化する。

実施例として、サービスアプリケーションのデータ変更モジュールによってサービスデータの変更を実行した後、例えば、ユーザ名をＪｉｍからＴｏｍに変更した後に、サービスアプリケーションは、この変更に対応するサービスデータすなわちＵｓｅｒ：｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝）も取得する必要がある。これはすなわち、このデータ変更はこのサービスデータの名前の変更ということである。

サービスアプリケーションは、このデータ更新イベントに対応するイベントバージョンも生成する。この実施の形態では、データベースデータのデータ更新、例えば一つの追加、削除、修正は、全て「一つのデータ更新イベント」と呼ぶことができる。また、イベントの経時的順序を表すために、イベントの発生順序に従って「イベントバージョン」を記録する。例えば、１回目に発生するイベントのバージョンは「１」つまりｖｅｒｓｉｏｎ＝１であってよく、２回目に発生するイベントのバージョンは段階１の累増つまりｖｅｒｓｉｏｎ＝２であってよい。当然ながら、イベントバージョンの累増段階は１である必要はなく、例えば２であってもよい。１回目に発生するイベントのバージョンが１で、２回目に発生する第２イベントのバージョンが３であってもよい、あるいはイベントバージョンを数字で表す必要はなく、代わりに、例えばイベント発生のタイムスタンプで表すこともできる。例えば、１回目に発生するイベントのバージョンが２０１４．１２．３１であり、２回目に発生するイベントのバージョンが２０１５．１．２０である場合には、イベント発生の経時的順序をこれらのタイムスタンプで識別することもできる。

このステップでは、図２に示すように、上述のサービスデータを取得する操作とイベントバージョンを生成する操作は、サービスアプリケーションのイベントカプセル化モジュールによって実行でき、さらに、イベントカプセル化モジュールは、サービスデータとイベントバージョンをイベントオブジェクト内にカプセル化することができる。例えば、カプセル化されたイベントオブジェクトは、Ｅｖｅｎｔ：｛ｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝，ｖｅｒｓｉｏｎ＝１｝で表すことができる。サービスアプリケーションに複数のユーザ情報が記憶されている場合には、上述のイベントオブジェクトは、このイベントオブジェクトがどのユーザに対応しているかを示すサービスメインキーを含むことができる。

３０３．サービスアプリケーションは、イベントオブジェクトをピアエンドのサービスアプリケーションへ伝送する。

実施例として、図２に示すように、サービスアプリケーションによってカプセル化されたイベントオブジェクトは、イベント送信モジュールによってピアエンドのサービスアプリケーション（つまり、データ同期を必要とする遠隔ピアエンド）へ送信され、次に、ピアエンドのサービスアプリケーションのイベント受信モジュールによって受信される。この実施の形態では、送信側エンドのイベント送信モジュールと受信側エンドのイベント受信モジュールを総称して「イベント通知プラットフォーム」と呼ぶことができ、このイベント通知プラットフォームは、サービスアプリケーションによってカプセル化されたイベントオブジェクトを伝送するように機能し、伝送はメッセージ形式で完了されてよい。

イベント通知プラットフォームを介してイベントを伝送することにより、リアルタイム伝送を達成できる。例えば、サービスアプリケーションは、データベースのデータの更新後に、リアルタイムでのイベントオブジェクトへのカプセル化を終え、このイベントオブジェクトを、イベント通知プラットフォームを介してピアエンドへ伝送することができ、これにより同期効率は従来の標準的なデータベース同期と比べて著しく向上する。さらに
、一のデータ更新に関して、イベント通知プラットフォームは、一の「イベント」オブジェクトを介して、このデータ更新の情報をピアエンドにその都度伝送することができ、これにより、データベースが一のデータ更新に含まれる複数の指示情報を順次に伝送する従来のモードに対してデータ同期速度が増加する。例えば、国境をまたぐデータ同期において、このプラットフォームは、一のイベントの、ピアエンドへの国境をまたぐ伝送を約数ミリ秒付近でサポートする能力を有する。

この実施の形態では、サービスアプリケーションは、サービスデータとイベントバージョンとをイベントオブジェクト内にカプセル化した後に、イベントオブジェクトを記録することもできる。図４の実施例を参照すると、サービスアプリケーションはイベント記録モジュールをさらに含んでもよく、このモジュールはイベントオブジェクトを記録するように構成でき、またイベントオブジェクトはデータベースに記録でき、さらに各イベントオブジェクトは次のように記録することができる：
Ｅｖｅｎｔ：｛ｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｊｉｍ｝，ｖｅｒｓｉｏｎ＝０｝；
Ｅｖｅｎｔ：｛ｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝，ｖｅｒｓｉｏｎ＝１｝；

一方、イベントオブジェクトを記録することは、ピアエンド（すなわち、受信側エンド）から送信されたイベントオブジェクトを受信すると、イベントの有効性を判定するべく、イベントバージョンに関する情報を、記録されたイベントオブジェクトから抽出するために用いることができ、また、この処理を行うために、受信側エンドで実行される方法の下記説明を参照することができる。他方、全てのイベントオブジェクトを記録することはデータ変更手順のより優れた知見を促し、これにより履歴のトレーサビリティが得られる。

イベント記録モジュールによるイベントオブジェクトの記録は、イベントカプセル化モジュールがイベントオブジェクト内へのカプセル化を終え、このイベントオブジェクトを送信する前、又は、イベント送信モジュールがイベントオブジェクトを送信した後、のいずれかに実行できる。

図５は、受信側エンドとして機能する場所Ｂのサービスアプリケーションによって実行される遠隔データの同期方法のフローを示す。この方法は、図２及び図５に示すように、以下のステップを含んでもよい。

５０１．サービスアプリケーションは、ピアエンドのサービスアプリケーションが送信したイベントオブジェクトを受信し、イベントオブジェクトは、データ更新イベントにて更新されたサービスデータと、データ更新イベントに対応するイベントバージョンとを含む。

実施例として、受信側エンドのサービスアプリケーションは、イベント受信モジュールにより、ピアエンドが送信したイベントオブジェクトを受信することができ、このイベントオブジェクトはサービスデータとイベントバージョンとを含んでよく、例えば、イベントオブジェクトは上の実施例で述べたＥｖｅｎｔ：｛ｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝，ｖｅｒｓｉｏｎ＝１｝であり、また、２人以上のユーザの情報をデータベースに記憶する場合には、イベントオブジェクトのサービスデータは、サービスメインキーと更新対象のデータとを少なくとも含み、このサービスメインキーを用いて異なるユーザ情報を区別する。

５０２．サービスアプリケーションは、イベントオブジェクト内のサービスメインキーに従って、ローカルに記録されている、このサービスメインキーに対応するデータ更新イベントのイベントバージョンを取得する。

実施例として、図２に示すように、サービスアプリケーション内のデータ更新モジュールは、イベントオブジェクトのカプセル化解除を行うことで、イベントオブジェクト内のサービスメインキーとイベントバージョンとを取得することができ、例えば、上述のイベントでは、サービスメインキーはｉｄ＝１、イベントバージョンはｖｅｒｓｉｏｎ＝１である。

イベント記録モジュールを介することで、サービスアプリケーション自体が発生したイベントオブジェクトを記録できることは図３に示す実施例で述べた。このステップでは、受信したピアエンドのイベントオブジェクト内のサービスメインキーｉｄ＝１に従って、データ更新モジュールが、ローカルに記録されている、サービスメインキーに対応するデータ更新イベントのイベントバージョンを取得することができる。例えば、サービスメインキーとイベントバージョンとに関する情報、例えば｛ｉｄ＝１，ｖｅｒｓｉｏｎ＝０｝を、ローカルに記録されているイベント記録から抽出する。同一のｉｄに対応する複数のイベントバージョンがローカルに記録されている場合には、最後に発生したイベントのイベントバージョン、例えば、最新の時間のもの又はバージョン番号が最大のものを取得する。

５０３．サービスアプリケーションは、受信したデータ更新イベントが有効であるか否かをイベントバージョンに従って判断する。

実施例として、サービスアプリケーションのデータ更新モジュールは、ローカルに記録されているイベントバージョンを、同一のｉｄに対応している受信したピアエンドのイベントバージョンと比較する。ピアエンドのイベントの発生時間の方が遅い場合には、ピアエンドのイベントが有効である、つまり、これが最新のデータ更新イベントであることを意味し、また、ピアエンドのイベントの発生時間の方が早い場合には、最新のデータ更新イベントがローカルに記録されており、ピアエンドのイベントは無効であることを意味する。

データ更新イベントが有効であるか否かを具体的に判定する場合、上述の実施例にてイベントバージョンの数を比較することができる。ピアエンドイベントのイベントバージョンｖｅｒｓｉｏｎ＝１がローカルエンドのイベントバージョンｖｅｒｓｉｏｎ＝０よりも大きい場合には、ピアエンドのデータ更新イベントは有効と判定し、５０４を実行するように進み、それ以外の場合は、ピアエンドのイベントバージョンがローカルエンドのイベントバージョンよりも小さいと仮定し、ピアエンドのイベントは無効であると判定して、５０６を実行できる。加えて、イベントバージョンがタイムスタンプで表されている場合、これらのタイムスタンプ同士を同様に比較して、ローカルエンドとピアエンドのイベント発生の経時的順序を判断する。

５０４．サービスアプリケーションは、データ更新イベントで更新されたサービスデータに従って、ローカルデータベースを更新する。

実施例として、サービスアプリケーションは、ピアエンドのデータ更新イベントが有効であると判定した後、データベース内の対応するサービスデータを変更するためにデータベースインターフェースを呼び出す。つまり、ｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝に従って、ローカルサービスデータをｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝に更新する。

５０５．サービスアプリケーションによってイベントオブジェクトを記録する。

実施例として、サービスアプリケーションは、ピアエンドのデータ更新イベントに従ってローカルデータベース内のサービスデータを更新した後に、このイベントに従って、ローカルに記録されているイベントオブジェクトをさらに更新し、また、上の実施例で述べたように、サービスアプリケーションは、最新のイベントオブジェクトＥｖｅｎｔ：｛ｕｓｅｒ＝｛ｉｄ＝１，ｎａｍｅ＝Ｔｏｍ｝，ｖｅｒｓｉｏｎ＝１｝をイベント記録モジュールを介してローカルデータベースに記録し、追跡用に履歴イベント記録を確保する。実際には、イベントオブジェクトは、ピアエンドのイベントが有効と判定された後、又はローカルデータベースを更新した後、のいずれかに記録することができる。

５０６．サービスアプリケーションは、イベントオブジェクトを破棄し、イベントオブジェクトに従ったローカルデータベースの更新をしない。

この実施の形態のサービスアプリケーションは、イベントバージョンを用いて様々なデータ更新イベントの発生順序を識別する。これは最新イベントの正確な識別を支援し、データベースの正確な更新を確実に行えるようにする。例えば、ツーエンドが同じ対象のデータを同時に変更する間際であっても、イベントバージョン同士を比較することにより、最新のデータ更新を正確に識別できるようになる。

この実施の形態の遠隔データの同期方法によれば、このイベントベースのデータ同期は、データ更新に関する情報のリアルタイムの伝送、さらに比較的に高速なイベント伝送を可能にする。さらに、イベントバージョンによって異なるデータ更新の順序を区別することもでき、これにより、データベースのデータ更新の正確性と信頼性が保証される。

上述の説明から分かるように、送信側エンドと受信側エンド両方のサービスアプリケーションは、図２及び図４に示すような遠隔データ同期装置を含み、この遠隔データ同期装置は、各種内蔵モジュールを用いてこの実施の形態の遠隔データ同期方法を実行する。さらに、受信側エンドのサービスアプリケーションに関し、図６に見られるその遠隔データ同期装置の構造はデータ受信モジュール６１とデータ更新モジュール６２とを含み、ここで、データ更新モジュール６２は記録取得ユニット６２１とイベント判断ユニット６２２とを含んでいてもよい。

記録取得ユニット６２１は、イベントオブジェクト内のサービスメインキーに従い、このサービスメインキーに対応した、ローカルに記録されているデータ更新イベントのイベントバージョンを取得するように構成されており、サービスメインキーを用いて異なるサービスデータを区別する。

イベント判断ユニット６２２は、ローカルイベントバージョンをピアエンドのイベントバージョンと比較し、経時上、ローカルに記録されているデータ更新イベントよりも後にピアエンドデータ更新イベントが発生したことを判定するように構成されている。

上記は本願の好ましい実施の形態にすぎず、本願を限定するために用いられるものではない。本願の精神及び原理の範囲内において行われる任意の変形、同等物の置換、及び改良は、本願の範囲内に含まれるものである。

Claims (20)

1. コンピュータに実装される方法であって、
   サービスアプリケーションによって、ローカルデータベースに格納されるサービスデータを更新するデータ更新イベントに対応する１または複数のデータベース操作の実行を前記サービスアプリケーションの前記ローカルデータベースに指示するステップであって、各サービスデータは複数のデータ項目からなるデータ記憶ユニットを含む、前記指示するステップと、
   前記サービスアプリケーションによって、前記１または複数のデータベース操作が完了したかを判定するステップと、
   前記サービスアプリケーションによって、前記データ更新イベントの前記１または複数のデータベース操作によって更新された前記サービスデータを取得するステップと、
   前記サービスアプリケーションによって、前記データ更新イベントに対応するイベントバージョンを生成するステップであって、各イベントバージョンは対応するデータ更新イベント発生の時系列的順序を示す数値またはタイムスタンプである、ステップと、
   前記サービスアプリケーションによって、前記サービスデータと前記イベントバージョンとサービスメインキーとをイベントオブジェクトにカプセル化するステップと、
   前記サービスアプリケーションによって、ピアエンドのサービスアプリケーションのピアエンドデータベース内の対応するサービスデータの同期のために前記ピアエンドのサービスアプリケーションへ前記イベントオブジェクトを伝送するステップと、
   前記サービスアプリケーションによって、前記ピアエンドのサービスアプリケーションから追加イベントオブジェクトを受信するステップであって、前記追加イベントオブジェクトは前記ピアエンドのサービスアプリケーションによりカプセル化されたイベントオブジェクトである、前記受信するステップと、
   前記サービスアプリケーションによって、前記追加イベントオブジェクトのサービスメインキーに関連したローカルに記録されている複数のデータ更新イベントを特定するステップと、
   前記サービスアプリケーションによって、前記ローカルに記録されている複数のデータ更新イベントに関連した複数のイベントバージョンに基づき、前記ローカルに記録されている複数のデータ更新イベントの中からローカルに記録されている特定のデータ更新イベントを特定するステップであって、前記ローカルに記録されている特定のデータ更新イベントは特定のイベントバージョンと関連づけられ、かつ、前記複数のローカルに記録されているデータ更新イベントの発生順中で時系列的に最新である、前記ローカルに記録されている特定のデータ更新イベントを特定するステップと、
   前記サービスアプリケーションによって、前記追加イベントオブジェクトのイベントバージョンと前記特定のイベントバージョンとの比較に基づき、前記追加イベントオブジェクトに関連した追加データ更新イベントが有効か判定するステップと
   を備える、コンピュータに実装される方法。
2. 前記サービスメインキーは、異なるサービスデータを区別するために用いられる、
   請求項１に記載のコンピュータに実装される方法。
3. 前記サービスデータと前記イベントバージョンと前記サービスメインキーをイベントオブジェクトにカプセル化するステップの後、前記イベントオブジェクトを記録するステップ
   をさらに備える、請求項１に記載のコンピュータに実装される方法。
4. コンピュータに実装される方法であって、
   サービスアプリケーションによって、ピアエンドサービスアプリケーションによって送られたイベントオブジェクトを受信するステップであって、前記イベントオブジェクトは、
   ピアエンドのデータ更新イベントで更新されたサービスデータであって、各サービスデータは複数のデータ項目からなるデータ記憶ユニットを含む、前記サービスデータと、
   前記ピアエンドのデータ更新イベントに対応するイベントバージョンであって、各イベントバージョンは、対応するデータ更新イベント発生の時系列的順序を示す数値またはタイムスタンプである、前記イベントバージョンと、
   サービスメインキーと
   を備える、前記受信するステップと、
   前記サービスアプリケーションによって、前記サービスメインキーに関連したローカルに記録されている複数のデータ更新イベントを特定するステップと、
   前記サービスアプリケーションによって、前記ローカルに記録されている複数のデータ更新イベントに関連した複数のイベントバージョンに基づき、前記ローカルに記録されている複数のデータ更新イベントの中からローカルに記録されている特定のデータ更新イベントを特定するステップであって、前記ローカルに記録されている特定のデータ更新イベントは特定のイベントバージョンと関連づけられ、かつ、前記複数のローカルに記録されているデータ更新イベントの発生順中で時系列的に最新である、前記ローカルに記録されている特定のデータ更新イベントを特定するステップと、
   前記サービスアプリケーションによって、前記イベントバージョンと前記特定のイベントバージョンとの比較に基づき、前記ピアエンドのデータ更新イベントが有効か判定するステップと、
   前記サービスアプリケーションによって、前記ピアエンドのデータ更新イベントで更新された前記サービスデータに対応する１または複数のデータベース操作を判定するステップと、
   前記サービスアプリケーションによって、ローカルデータベースに保存されるサービスデータ更新する前記１または複数のデータベース操作を実行するよう前記サービスアプリケーションの前記ローカルデータベースに指示するステップと
   を備える、コンピュータに実装される方法。
5. 前記ピアエンドのデータ更新イベントが有効か判定するステップは、前記イベントバージョンに従って、前記ローカルに記録された特定のデータ更新イベント後に前記ピアエンドのデータ更新イベントが発生順に生じているか判定するステップをさらに備える、請求項４に記載のコンピュータに実装される方法。
6. 前記ローカルに記録された特定のデータ更新イベント後に前記ピアエンドのデータ更新イベントが発生順に生じているか判定するステップは、
   前記イベントオブジェクトに備えられる前記サービスメインキーに応じて、前記特定のイベントバージョンを取得するステップであって、前記サービスメインキーは異なるサービスデータと区別するために用いられる、前記特定のイベントバージョンを取得するステップと、
   前記特定のイベントバージョンと前記イベントバージョンとを比較するステップと、
   前記ローカルに記録される特定のデータ更新イベント後に前記ピアエンドのデータ更新イベントが発生順に生じているか判定するステップと
   をさらに備える、請求項５に記載のコンピュータに実装される方法。
7. 前記ピアエンドのデータ更新イベントが有効と判定した後、前記イベントオブジェクトを記録するステップ
   をさらに備える、請求項４に記載のコンピュータに実装される方法。
8. コンピュータ実装システムであって、
   １または複数のコンピュータと、
   前記１または複数のコンピュータと相互利用可能に接続され命令を記憶する機械読み取り可能な媒体を備えた１または複数のコンピュータ記憶装置を備え、前記命令は前記１または複数のコンピュータに実行された際に、
   サービスアプリケーションによって、ローカルデータベースに格納されるサービスデータを更新するデータ更新イベントに対応する１または複数のデータベース操作の実行を前記サービスアプリケーションの前記ローカルデータベースに指示するステップであって、各サービスデータは複数のデータ項目からなるデータ記憶ユニットを含む、前記指示するステップと、
   前記サービスアプリケーションによって、前記１または複数のデータベース操作が完了したかを判定するステップと、
   前記サービスアプリケーションによって、前記データ更新イベントの前記１または複数のデータベース操作によって更新された前記サービスデータを取得するステップと、
   前記サービスアプリケーションによって、前記データ更新イベントに対応するイベントバージョンを生成するステップであって、各イベントバージョンは対応するデータ更新イベント発生の時系列的順序を示す数値またはタイムスタンプである、ステップと、
   前記サービスアプリケーションによって、前記サービスデータと前記イベントバージョンとサービスメインキーとをイベントオブジェクトにカプセル化するステップと、
   前記サービスアプリケーションによって、ピアエンドのサービスアプリケーションのピアエンドデータベース内の対応するサービスデータの同期のために前記ピアエンドのサービスアプリケーションへ前記イベントオブジェクトを伝送するステップと、
   前記サービスアプリケーションによって、前記ピアエンドのサービスアプリケーションからの追加イベントオブジェクトを受信するステップであって、前記追加イベントオブジェクトは前記ピアエンドのサービスアプリケーションによりカプセル化されたイベントオブジェクトである、前記受信するステップと、
   前記サービスアプリケーションによって、前記追加イベントオブジェクトのサービスメインキーに関連したローカルに記録されている複数のデータ更新イベントを特定するステップと、
   前記サービスアプリケーションによって、前記ローカルに記録されている複数のデータ更新イベントに関連した複数のイベントバージョンに基づき、前記ローカルに記録されている複数のデータ更新イベントの中からローカルに記録されている特定のデータ更新イベントを特定するステップであって、前記ローカルに記録されている特定のデータ更新イベントは特定のイベントバージョンと関連づけられ、かつ、前記複数のローカルに記録されているデータ更新イベントの発生順中で時系列的に最新である、前記ローカルに記録されている特定のデータ更新イベントを特定するステップと、
   前記サービスアプリケーションによって、前記追加イベントオブジェクトのイベントバージョンと前記特定のイベントバージョンとの比較に基づき、前記追加イベントオブジェクトに関連した追加データ更新イベントが有効か判定するステップと
   を備える操作を実行する、コンピュータ実装システム。
9. 前記サービスメインキーは、異なるサービスデータを区別するために用いられる、
   請求項８に記載のコンピュータ実装システム。
10. 前記操作は、前記サービスデータと前記イベントバージョンと前記サービスメインキーをイベントオブジェクトにカプセル化するステップの後、前記イベントオブジェクトを記録するステップ
    をさらに備える、請求項８に記載のコンピュータ実装システム。
11. コンピュータ実装システムであって、
    １または複数のコンピュータと、
    前記１または複数のコンピュータと相互利用可能に接続され命令を記憶する機械読み取り可能な媒体を備えた１または複数のコンピュータ記憶装置を備え、前記命令は前記１または複数のコンピュータに実行された際に、
    サービスアプリケーションによって、ピアエンドサービスアプリケーションによって送られたイベントオブジェクトを受信するステップであって、前記イベントオブジェクトは、
    ピアエンドのデータ更新イベントで更新されたサービスデータであって、各サービスデータは複数のデータ項目からなるデータ記憶ユニットを含む、前記サービスデータと、
    前記ピアエンドのデータ更新イベントに対応するイベントバージョンであって、各イベントバージョンは、対応するデータ更新イベント発生の時系列的順序を示す数値またはタイムスタンプである、前記イベントバージョンと、
    サービスメインキーと
    を備える、前記受信するステップと、
    前記サービスアプリケーションによって、前記サービスメインキーに関連したローカルに記録されている複数のデータ更新イベントを特定するステップと、
    前記サービスアプリケーションによって、前記ローカルに記録されている複数のデータ更新イベントに関連した複数のイベントバージョンに基づき、前記ローカルに記録されている複数のデータ更新イベントの中からローカルに記録されている特定のデータ更新イベントを特定するステップであって、前記ローカルに記録されている特定のデータ更新イベントは特定のイベントバージョンと関連づけられ、かつ、前記複数のローカルに記録されているデータ更新イベントの発生順中で時系列的に最新である、前記ローカルに記録されている特定のデータ更新イベントを特定するステップと、
    前記サービスアプリケーションによって、前記イベントバージョンと前記特定のイベントバージョンとの比較に基づき、前記ピアエンドのデータ更新イベントが有効か判定するステップと、
    前記サービスアプリケーションによって、前記ピアエンドのデータ更新イベントで更新された前記サービスデータに対応する１または複数のデータベース操作を判定するステップと、
    前記サービスアプリケーションによって、ローカルデータベースに保存されるサービスデータ更新する前記１または複数のデータベース操作を実行するよう前記サービスアプリケーションの前記ローカルデータベースに指示するステップと
    を備える操作を実行する、コンピュータ実装システム。
12. 前記ピアエンドのデータ更新イベントが有効か判定するステップは、前記イベントバージョンに従って、前記ローカルに記録された特定のデータ更新イベント後に前記ピアエンドのデータ更新イベントが発生順に生じているか判定するステップをさらに備える、請求項１１に記載のコンピュータ実装システム。
13. 前記ローカルに記録された特定のデータ更新イベント後に前記ピアエンドのデータ更新イベントが発生順に生じているか判定するステップは、
    前記イベントオブジェクトに備えられる前記サービスメインキーに応じて、前記特定のイベントバージョンを取得するステップであって、前記サービスメインキーは異なるサービスデータと区別するために用いられる、前記特定のイベントバージョンを取得するステップと、
    前記特定のイベントバージョンと前記イベントバージョンとを比較するステップと、
    前記ローカルに記録される特定のデータ更新イベント後に前記ピアエンドのデータ更新イベントが発生順に生じているか判定するステップと
    をさらに備える、請求項１２に記載のコンピュータ実装システム。
14. 前記操作は、前記ピアエンドのデータ更新イベントが有効と判定した後、前記イベントオブジェクトを記録するステップ
    をさらに備える、請求項１１に記載のコンピュータ実装システム。
15. コンピュータ実装システムによって実行可能な１または複数の命令を記憶するコンピュータ読み取り可能な記憶媒体であって、前記命令の実行により、
    サービスアプリケーションによって、ローカルデータベースに格納されるサービスデータを更新するデータ更新イベントに対応する１または複数のデータベース操作の実行を前記サービスアプリケーションの前記ローカルデータベースに指示するステップであって、各サービスデータは複数のデータ項目からなるデータ記憶ユニットを含む、前記指示するステップと、
    前記サービスアプリケーションによって、前記１または複数のデータベース操作が完了したかを判定するステップと、
    前記サービスアプリケーションによって、前記データ更新イベントの前記１または複数のデータベース操作によって更新された前記サービスデータを取得するステップと、
    前記サービスアプリケーションによって、前記データ更新イベントに対応するイベントバージョンを生成するステップであって、各イベントバージョンは対応するデータ更新イベント発生の時系列的順序を示す数値またはタイムスタンプである、ステップと、
    前記サービスアプリケーションによって、前記サービスデータと前記イベントバージョンとサービスメインキーとをイベントオブジェクトにカプセル化するステップと、
    前記サービスアプリケーションによって、ピアエンドのサービスアプリケーションのピアエンドデータベース内の対応するサービスデータの同期のために前記ピアエンドのサービスアプリケーションへ前記イベントオブジェクトを伝送するステップと、
    前記サービスアプリケーションによって、前記ピアエンドのサービスアプリケーションからの追加イベントオブジェクトを受信するステップであって、前記追加イベントオブジェクトは前記ピアエンドのサービスアプリケーションによりカプセル化されたイベントオブジェクトである、前記受信するステップと、
    前記サービスアプリケーションによって、前記追加イベントオブジェクトのサービスメインキーに関連したローカルに記録されている複数のデータ更新イベントを特定するステップと、
    前記サービスアプリケーションによって、前記ローカルに記録されている複数のデータ更新イベントに関連した複数のイベントバージョンに基づき、前記ローカルに記録されている複数のデータ更新イベントの中からローカルに記録されている特定のデータ更新イベントを特定するステップであって、前記ローカルに記録されている特定のデータ更新イベントは特定のイベントバージョンと関連づけられ、かつ、前記複数のローカルに記録されているデータ更新イベントの発生順中で時系列的に最新である、前記ローカルに記録されている特定のデータ更新イベントを特定するステップと、
    前記サービスアプリケーションによって、前記追加イベントオブジェクトのイベントバージョンと前記特定のイベントバージョンとの比較に基づき、前記追加イベントオブジェクトに関連した追加データ更新イベントが有効か判定するステップと
    を備える操作を実行する、コンピュータ読み取り可能な記憶媒体。
16. 前記サービスメインキーは、異なるサービスデータを区別するために用いられる、
    請求項１５に記載のコンピュータ読み取り可能な記憶媒体。
17. 前記操作は、前記サービスデータと前記イベントバージョンと前記サービスメインキーをイベントオブジェクトにカプセル化するステップの後、前記イベントオブジェクトを記録するステップ
    をさらに備える、請求項１５に記載のコンピュータ読み取り可能な記憶媒体。
18. コンピュータシステムによって実行可能な１または複数の命令を記憶するコンピュータ読み取り可能な記憶媒体であって、前記命令の実行により、
    サービスアプリケーションによって、ピアエンドサービスアプリケーションによって送られたイベントオブジェクトを受信するステップであって、前記イベントオブジェクトは、
    ピアエンドのデータ更新イベントで更新されたサービスデータであって、各サービスデータは複数のデータ項目からなるデータ記憶ユニットを含む、前記サービスデータと、
    前記ピアエンドのデータ更新イベントに対応するイベントバージョンであって、各イベントバージョンは、対応するデータ更新イベント発生の時系列的順序を示す数値またはタイムスタンプである、前記イベントバージョンと、
    サービスメインキーと
    を備える、前記受信するステップと、
    前記サービスアプリケーションによって、前記サービスメインキーに関連したローカルに記録されている複数のデータ更新イベントを特定するステップと、
    前記サービスアプリケーションによって、前記ローカルに記録されている複数のデータ更新イベントに関連した複数のイベントバージョンに基づき、前記ローカルに記録されている複数のデータ更新イベントの中からローカルに記録されている特定のデータ更新イベントを特定するステップであって、前記ローカルに記録されている特定のデータ更新イベントは特定のイベントバージョンと関連づけられ、かつ、前記複数のローカルに記録されているデータ更新イベントの発生順中で時系列的に最新である、前記ローカルに記録されている特定のデータ更新イベントを特定するステップと、
    前記サービスアプリケーションによって、前記イベントバージョンと前記特定のイベントバージョンとの比較に基づき、前記ピアエンドのデータ更新イベントが有効か判定するステップと、
    前記サービスアプリケーションによって、前記ピアエンドのデータ更新イベントで更新された前記サービスデータに対応する１または複数のデータベース操作を判定するステップと、
    前記サービスアプリケーションによって、ローカルデータベースに保存されるサービスデータ更新する前記１または複数のデータベース操作を実行するよう前記サービスアプリケーションの前記ローカルデータベースに指示するステップと
    を備える操作を実行する、コンピュータ読み取り可能な記憶媒体。
19. 前記ピアエンドのデータ更新イベントが有効か判定するステップは、前記イベントバージョンに従って、前記ローカルに記録された特定のデータ更新イベント後に前記ピアエンドのデータ更新イベントが発生順に生じているか判定するステップをさらに備える、請求項１８に記載のコンピュータ読み取り可能な記憶媒体。
20. 前記ローカルに記録された特定のデータ更新イベント後に前記ピアエンドのデータ更新イベントが発生順に生じているか判定するステップは、
    前記イベントオブジェクトに備えられる前記サービスメインキーに応じて、前記特定のイベントバージョンを取得するステップであって、前記サービスメインキーは異なるサービスデータと区別するために用いられる、前記特定のイベントバージョンを取得するステップと、
    前記特定のイベントバージョンと前記イベントバージョンとを比較するステップと、
    前記ローカルに記録される特定のデータ更新イベント後に前記ピアエンドのデータ更新イベントが発生順に生じているか判定するステップと
    をさらに備える、請求項１９に記載のコンピュータ読み取り可能な記憶媒体。

Images