JP4129353B2 - 分散データ管理システム、分散データ管理方法及び分散データ管理プログラム - Google Patents
分散データ管理システム、分散データ管理方法及び分散データ管理プログラム Download PDFInfo
- Publication number
- JP4129353B2 JP4129353B2 JP2001097581A JP2001097581A JP4129353B2 JP 4129353 B2 JP4129353 B2 JP 4129353B2 JP 2001097581 A JP2001097581 A JP 2001097581A JP 2001097581 A JP2001097581 A JP 2001097581A JP 4129353 B2 JP4129353 B2 JP 4129353B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- site
- transaction
- original
- update
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99943—Generating database or data structure, e.g. via user interface
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
- Y10S707/99945—Object-oriented database structure processing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99955—Archiving or backup
Description
【発明の属する技術分野】
本発明は、ネットワークに接続された複数のマシン間における共有データを、適切且つ効率良く管理することができる分散データ管理システム及び分散データ管理方法に関するものである。
【0002】
【従来の技術】
ネットワークに分散したマシン間における共有データをリアルタイムに監視・制御するシステムでは、大量のデータを高速に処理(検索・更新)する必要があるため、それらのデータへのアクセス手段を提供するデータ管理手段(データベース、ファイルシステム等)の性能がシステムの性能を決定する。このようなデータ管理性能の向上を図るためには、通常ハードディスク等の外部記憶装置に格納されているデータのすべてを主記憶上に配置して管理することが考えられる。特に、昨今の主記憶容量の増加により、現在のハードウェア環境でも全データを主記憶上に常駐させることは可能となってきている。
【0003】
【発明が解決しようとする課題】
しかしながら、従来のディスクを前提にしたデータ管理を単に主記憶でキャッシングするだけでは、リアルタイムアプリケーションが必要とする性能を達成することはできない。その理由としては、(1)アプリケーションとデータ管理手段との間で大量のデータ転送操作が必須となる、(2)ディスクを前提として設計されたアルゴリズムを各マシンの主記憶上で実行してもそれほど性能が向上しないという2点が挙げられる。さらに、ディスクを前提として設計されたアルゴリズムでは、データ管理手段が提供できる検索機能が限られているため、多少高速化されてもアプリケーションの開発負荷は軽減されない。
【0004】
また、従来のデータ管理システムにおいては、ネットワークに分散したマシン間で一貫して等価な共有データを維持することが困難であったため、クライアント/サーバ方式の様な構成を採用して、オリジナルデータを一つのサーバに集中管理させていた。
しかし、このように一つのサーバ上にデータを集中させた場合には、多数のマシンからの処理要求に伴うサーバの負担も大きく、処理効率も悪かった。
【0005】
また、従来のデータ管理システムにおいては、トランザクション処理が単にデータの参照を目的とするだけで、データの更新を伴わない場合であっても、すべてのマシンがオリジナルデータを集中管理しているサーバにアクセスしていたため、ネットワークを介する分だけアクセス速度が低下すると共に、ネットワークのトラフィックも混雑する等、トランザクション処理の効率が悪かった。
【0006】
さらに、従来のデータ管理システムにおいては、各マシンで実行されるアプリケーションプログラムは、オリジナルデータがどのサーバにあるかをチェックする必要があったため、必要とするデータに直ちにアクセスすることができないといった欠点があった。
【0007】
また、従来のデータ管理システムにおいては、あるマシンのアプリケーションプログラムからあるデータに対して1つの更新処理が実行されている間は、同じデータに対しては他のマシンのアプリケーションプログラムが要求する処理を中断しなければならなかったため、高いトランザクション処理のスループットを実現することができなかった。
【0008】
本発明は、上記のような従来技術の問題点を解決するために提案されたものであり、その目的は、ネットワークで結合された複数のマシン上で協調動作することにより、各マシンの主記憶上に共有データを常駐させて一貫して維持・更新することができる分散データ管理システム及び分散データ管理方法を提供することにある。
【0009】
【課題を解決するための手段】
上記の目的を達成するため、請求項1記載の発明は、ネットワークを介して接続された複数のコンピュータの主記憶領域上にそれぞれデータベースを配置し、前記データベースに格納されたデータのそれぞれについて、そのオリジナルデータを、前記複数のコンピュータの内のある特定のコンピュータに格納し、このオリジナルデータを保有するコンピュータをオリジナルサイトとすると共に、前記オリジナルサイトとは異なる他のコンピュータには、前記オリジナルデータと同一のレプリカデータを格納し、このレプリカデータを保有するコンピュータをレプリカサイトとし、前記各コンピュータにおいては、前記データベースにアクセスする処理をトランザクションとして実行する分散データ管理システムにおいて、次のような構成を採用したことを特徴とする。
(1)前記オリジナルサイトとレプリカサイトを構成する各コンピュータにはそれぞれ、前記トランザクションの実行依頼を受け付けるトランザクション受付部と、トランザクションの実行を制御するトランザクション実行制御部と、トランザクションを実行するトランザクション実行部と、オリジナルサイトから送られた更新データを自サイトのレプリカデータに反映させるレプリケーション処理部と、オリジナルデータあるいはレプリカデータを格納するデータ格納部と、トランザクション名、そのトランザクションの処理対象となるデータ名、そのデータのオリジナルサイト名、そのトランザクションの属性、そのトランザクションに対応するトランザクション関数名を対応づけて示したトランザクション登録表と、データ受信部及びデータ送信部を備える。
(2)前記データベースに格納された各データの更新処理は、前記オリジナルサイトのトランザクション実行部でのみ実行し、前記レプリカサイトにおいては、前記オリジナルサイトで実行された更新結果を前記データ受信部で受信し、前記レプリケーション処理部によって自己のレプリカデータに反映する。
(3)前記各サイトにおけるアプリケーションの実行時には、そのサイトに設けられたトランザクション受付部において受け付けられたアプリケーションの依頼に基づき、トランザクション実行制御部がトランザクション登録表を検索して、自サイトがオリジナルサイトであるか否かを判定すると共に、トランザクション登録表を検索して実行に必要なトランザクション関数を決定し、このトランザクション実行制御部の指示に従い、トランザクション実行部においてトランザクション関数の呼び出しを行う。
【0010】
請求項7の発明は、前記請求項1の発明を方法の観点から捉えたものであって、前記オリジナルサイトとレプリカサイトを構成する各コンピュータにはそれぞれ、前記トランザクションの実行依頼を受け付けるトランザクション受付部と、トランザクションの実行を制御するトランザクション実行制御部と、トランザクションを実行するトランザクション実行部と、オリジナルサイトから送られた更新データを自サイトのレプリカデータに反映させるレプリケーション処理部と、オリジナルデータあるいはレプリカデータを格納するデータ格納部と、トランザクション名、そのトランザクションの処理対象となるデータ名、そのデータのオリジナルサイト名、そのトランザクションの属性、そのトランザクションに対応するトランザクション関数名を対応づけて示したトランザクション登録表とを設け、前記データベースに格納された各データの更新処理は、前記オリジナルサイトのトランザクション実行部でのみ実行し、前記レプリカサイトにおいては、前記オリジナルサイトで実行された更新結果を前記データ受信部で受信し、前記レプリケーション処理部によって自己のレプリカデータに反映することにより、データの同一性を保持し、前記各サイトにおけるアプリケーションの実行時には、そのサイトに設けられたトランザクション受付部において受け付けられたアプリケーションの依頼に基づき、トランザクション実行制御部がトランザクション登録表を検索して、自サイトがオリジナルサイトであるか否かを判定すると共に、トランザクション登録表を検索して実行に必要なトランザクション関数を決定し、このトランザクション実行制御部の指示に従い、トランザクション実行部においてトランザクション関数の呼び出しを行うことを特徴とする。
【0011】
このような構成を有する請求項1、請求項7の発明によれば、ネットワーク上の複数のコンピュータに配置されたデータベースに格納された各データの更新処理を、ネットワーク上で唯一のオリジナルサイトでのみ実行し、他のレプリカサイトにおいては、オリジナルサイトで実行された更新結果を受信して、自己が保有するレプリカデータに反映することにより、ネットワーク上の複数のコンピュータが利用するデータの同一性を保持することができる。
【0012】
請求項2の発明は、請求項1に記載の分散データ管理システムにおいて、時々刻々と変化するデータのスナップショットを出力するスナップショット出力部と、前記スナップショットをネットワーク経由で取得する間に発生したデータの更新情報を保存するバッファ部とをさらに備え、
前記データ送信部より、他のサイトへスナップショットの送信要求を出し、他のサイトからスナップショットを取得する間に発生したデータの更新情報を前記バッファ部に保存し、前記スナップショットの取得と同時に、バッファ部に保存した更新情報を自己のデータに反映することを特徴とする。
【0013】
請求項8の発明は、請求項2の発明を方法の観点から捉えたものであって、請求項7に記載の分散データ管理方法において、自サイトのデータベースに最新のオリジナルデータを取得する場合に、ネットワーク上の他のサイトへスナップショットの送信要求を出し、他のサイトからスナップショットを受信すると共に、その受信中に発生したデータの更新情報を保存し、前記スナップショットの取得と同時に、保存した更新情報を自己のデータに反映することにより、時々刻々と変化するデータにキャッチアップすることを特徴とする。
【0014】
このような構成を有する請求項2、請求項8の発明によれば、システムの起動時等に、自サイトのデータベースに最新のオリジナルデータを取得する場合に、最新のデータをもつマシンにリトリーブ要求を出して、ある時点における最新のデータを受信すると共に、その受信中に発生したデータの更新情報も受信・保存し、これら双方を自己のデータに反映することにより、最新のデータを取得することができる。
【0015】
請求項3の発明は、請求項1又は請求項2に記載の分散データ管理システムにおいて、前記トランザクション受付部は、トランザクションの実行依頼を受け付ける毎に、受け付けたトランザクションをすべてのサイトを通じて一意に識別することができる「受付ID」を発行することを特徴とする。
このような構成を有する請求項3の発明によれば、「受付ID」により、例えば、「そのトランザクションは、どのサイトで、何番目に受け付けたトランザクションであるか」を一意に識別することができるので、ネットワークを介して実行されるレプリケーションとトランザクションとを正確に照合することができる。
【0016】
請求項4の発明は、請求項1乃至請求項3のいずれか一に記載の分散データ管理システムにおいて、前記トランザクション実行部は、データの更新処理がなされるたびに「更新シリアル番号」を発行することを特徴とする。
このような構成を有する請求項4の発明によれば、オリジナルサイトでデータの更新処理がなされるたびにシリアルに発行される「更新シリアル番号」によって、レプリカサイトは、この番号順にレプリケーションを処理することで、そのデータ内容をオリジナルデータと同一のものとすることができる。
【0017】
請求項5の発明は、請求項1乃至請求項4のいずれか一に記載の分散データ管理システムにおいて、前記オリジナルサイトが、ネットワーク上のいずれのサイトであるかを識別するための手段が設けられていることを特徴とする。
このような構成を有する請求項5の発明によれば、ネットワーク上の各サイトにおいて、自サイトがデータの更新処理を実行し得るオリジナルサイトであるか否かを容易に判断することができる。
【0018】
請求項6の発明は、請求項1乃至請求項5のいずれか一に記載の分散データ管理システムにおいて、自サイトがオリジナルサイトに対してデータ更新処理の実行を依頼したサイトであるか否かを識別するための手段が設けられていることを特徴とする。
このような構成を有する請求項6の発明によれば、自サイトがオリジナルサイトに対してデータ更新処理の実行を依頼したサイトであるか否かを判断でき、実行依頼元である場合には、レプリケーションされた更新データを自己のレプリカデータに反映すると共に、その実行結果をデータ更新を依頼したアプリケーションに通知する。また、実行依頼元でない場合には、レプリケーションされた更新データを自己のレプリカデータに反映する処理を行うだけでよい。
【0019】
請求項9の発明は、請求項7又は請求項8に記載の分散データ管理方法において、前記トランザクションがデータを参照するものである場合には、自サイトがオリジナルサイトであるか、レプリカサイトであるかにかかわらず、自己の保有するデータに対して参照処理を行うことを特徴とする。
このような構成を有する請求項9の発明によれば、データ参照処理を高速化することができると共に、負荷分散を実現することができる。
【0020】
請求項10の発明は、請求項7又は請求項8に記載の分散データ管理方法において、前記トランザクションが処理対象とするデータのオリジナルが、そのトランザクションの実行依頼を受けたコンピュータに保有され、そのトランザクションによりオリジナルデータが更新された場合に、その更新結果を他のすべてのレプリカサイトに送信することを特徴とする。
このような構成を有する請求項10の発明によれば、トランザクションの実行依頼を受けたサイトがオリジナルサイトであるので、自らデータ更新処理を実行し、その更新結果を他のすべてのレプリカサイトに送信することにより、ネットワーク上の複数のコンピュータが利用するデータの同一性を保持することができる。
【0021】
請求項11の発明は、請求項7又は請求項8に記載の分散データ管理方法において、前記トランザクションが処理対象とするデータのオリジナルサイトが、そのトランザクションの実行依頼を受けたコンピュータ以外のサイトであり、そのトランザクションによる処理がデータの更新である場合に、そのトランザクションの実行依頼を受けたコンピュータ(レプリカサイト)は、データの更新処理をオリジナルサイトに依頼し、オリジナルサイトで更新処理を実行した後、オリジナルサイトから更新結果を受信し、その更新結果を自己が保有するレプリカデータに反映すると同時に、そのトランザクションの実行依頼元に実行完了を通知することを特徴とする。
【0022】
このような構成を有する請求項11の発明によれば、トランザクションの実行依頼を受けたサイトがレプリカサイトであるので、オリジナルサイトにデータ更新処理の実行を依頼し、オリジナルサイトから更新結果を受信して、その更新結果を自己が保有するレプリカデータに反映することにより、ネットワーク上の複数のコンピュータが利用するデータの同一性を保持することができる。
【0023】
請求項12の発明は、請求項7又は請求項8に記載の分散データ管理方法において、前記トランザクションが処理対象とするデータのオリジナルサイトが、そのトランザクションの実行依頼を受けたコンピュータ以外のサイトであり、そのトランザクションによる処理がデータの更新である場合に、データの更新依頼を受けたオリジナルサイトにおいては、更新処理を実行した後、その更新結果を他のすべてのレプリカサイトに送信することを特徴とする。
このような構成を有する請求項12の発明によれば、トランザクションの実行依頼を受けたサイトがレプリカサイトであるため、そのレプリカサイトからデータの更新依頼を受けたオリジナルサイトでは、更新処理を実行した後、その更新結果を他のすべてのレプリカサイトに送信することにより、ネットワーク上の複数のコンピュータが利用するデータの同一性を保持することができる。
【0024】
請求項13の発明は、請求項7又は請求項8に記載の分散データ管理方法において、前記トランザクションが処理対象とするデータのオリジナルサイトが、そのトランザクションの実行依頼を受けたコンピュータ以外のサイトであり、そのトランザクションによる処理がデータの更新である場合に、自サイトがそのトランザクションの実行依頼を受けたコンピュータでも、オリジナルサイトでもない時は、オリジナルサイトから更新結果を受信し、その更新結果を自己が保有するレプリカデータに反映することを特徴とする。
【0025】
このような構成を有する請求項13の発明によれば、自サイトがトランザクションの実行依頼元サイトでも、オリジナルサイトでもない時は、オリジナルサイトから更新結果を受信し、その更新結果を自己が保有するレプリカデータに反映することにより、ネットワーク上の複数のコンピュータが利用するデータの同一性を保持することができる。
【0026】
請求項14の発明は、請求項1に記載の発明をコンピュータプログラムの観点でとらえたものであって、特に、あるデータのオリジナルサイトがネットワーク上のいずれのサイトであるかと、そのデータに対する処理が「参照」か「更新」のいずれであるかを検索するステップと、前記検索の結果、その処理が「更新」であり、且つ、自サイトがそのデータのオリジナルサイトである場合には、そのトランザクションを実行するステップと、その更新結果を他のレプリカサイトに送信するステップを有することを特徴とする。
【0027】
請求項15の発明は、前記請求項14の発明と同様に、請求項1の発明をコンピュータプログラムの観点でとらえたものであって、特に、あるデータのオリジナルサイトがネットワーク上のいずれのサイトであるかと、そのデータに対する処理が「参照」か「更新」のいずれであるかを検索するステップと、前記検索の結果、その処理が「更新」であり、且つ、自サイトがそのデータのレプリカサイトである場合には、その処理の実行をオリジナルサイトに転送するステップと、オリジナルサイトにおける更新結果を受信して、自己のレプリカデータに反映するステップを有することを特徴とする。
【0028】
このような構成を有する請求項14及び請求項15の発明によれば、ネットワーク上の複数のコンピュータに配置されたデータベースに格納された各データの更新処理を、ネットワーク上で唯一のオリジナルサイトでのみ実行し、他のレプリカサイトにおいては、オリジナルサイトで実行された更新結果を受信して、自己が保有するレプリカデータに反映することにより、ネットワーク上の複数のコンピュータが利用するデータの同一性を保持することができる。
【0029】
請求項16の発明は、請求項8に記載の発明をコンピュータプログラムの観点で捉えたものであって、請求項14又は請求項15に記載の分散データ管理プログラムにおいて、自サイトのデータベースに最新のデータを取得する場合に、ネットワーク上の他のサイトへスナップショットの送信要求を出すステップと、他のサイトからスナップショットを受信するステップと、その受信中に発生したデータの更新情報を保存するステップと、前記スナップショットの取得と同時に、保存した更新情報を自己のデータに反映するステップをさらに有することを特徴とする。
【0030】
このような構成を有する請求項16の発明によれば、システムの起動時等に、自サイトのデータベースに最新のデータを取得する場合に、最新のデータをもつマシンにリトリーブ要求を出して、ある時点における最新のデータを受信すると共に、その受信中に発生したデータの更新情報も受信・保存し、これら双方を自己のデータに反映することにより、最新のデータを取得することができる。
【0031】
請求項17の発明は、請求項1に記載の分散データ管理システムにおいて、前記データベースに格納されるデータを、ネットワーク上の複数のコンピュータで同一性を保持すべきデータと、各コンピュータに固有のデータとに区別し、前記同一性を保持すべきデータについては、その更新処理は、前記オリジナルサイトのトランザクション実行部でのみ実行し、前記レプリカサイトにおいては、前記オリジナルサイトで実行された更新結果を前記データ受信部で受信し、前記レプリケーション処理部によって自己のレプリカデータに反映し、一方、各コンピュータに固有なデータについては、各コンピュータ毎にデータの更新を実行し、他のコンピュータにその更新結果を反映させないことを特徴とする。
【0032】
請求項18の発明は、請求項17の発明を方法の観点で捉えたものであって、請求項7に記載の分散データ管理方法において、前記データベースに格納されるデータを、ネットワーク上の複数のコンピュータで同一性を保持すべきデータと、各コンピュータに固有のデータとに区別し、前記同一性を保持すべきデータについては、その更新処理は、前記オリジナルサイトでのみ実行可能とし、前記レプリカサイトにおいては、前記オリジナルサイトで実行された更新結果を自己が保有するレプリカデータに反映することにより、データの同一性を保持し、一方、各コンピュータに固有なデータについては、各コンピュータ毎にデータの更新を実行し、他のコンピュータにその更新結果を反映させないことを特徴とする。
【0033】
このような構成を有する請求項17、請求項18の発明によれば、データベースの特定の部分に関しては、そのデータが更新されてもレプリケーションデータを生成・伝達しないとすることによって、同一トランザクションで、システム全体で同一であるべきデータとサイト毎に扱いが異なるデータを同時に更新することができる。また、すべてのデータにレプリケーションを義務づけた場合に生じる無駄なレプリケーションを回避することができる。
【0034】
【発明の実施の形態】
[1.分散データ管理システムの全体像]
本発明は、ネットワークで接続された複数のマシンに備えられたデータベースを、適切且つ効率良く管理するための分散データ管理システムに関するものである。
本発明の詳細については後述するが、ここでは本発明の分散データ管理システム(以下、本システムという)について概説する。すなわち、本システムは、データベース(レキシコンセット)とトランザクションを扱うものであって、アプリケーション(=ユーザ)からデータベースの内容の参照・検索・更新の一群の操作依頼をトランザクションとして受け付け、そのトランザクションを適切に実行し、必要(要求)に応じて実行完了通知および実行結果をアプリケーションに通知するものである。
【0035】
図1は、本発明に係る分散データ管理システムの構成を示す図である。すなわち、本システムは、図1に示すように、複数のコンピュータA,B,C……(各ホストと呼ぶ)を通信ネットワークで接続することによって構成されている。また、各ホストA,B,Cの主記憶領域には、それぞれデータベース1a、1b、1cとこのデータベースにアクセスするためのトランザクション関数2a、2b、2cが配置されている。
【0036】
また、各ホストでは1または複数個のアプリケーションが実行されるが、本システムが複数のホストから構成される場合、異なるホストでは異なるアプリケーションが実行されることが多い。すなわち、アプリケーションX,Y,Zは本システムの外部にあって、各ホストごとにそのデータベースにアクセスして必要な処理を行う。この場合、各アプリケーションX,Y,Zは、各ホストに設けられた処理部3a、3b、3cを介して、本システムに予め登録されているトランザクション関数2a、2b、2cに参照・更新などの処理を依頼し、その結果を受けてデータベースへのアクセス以外にプログラムの実行に必要となる処理を行う。通常、アプリケーションでは画面への表示や印刷などのフロントエンド処理を行う。
【0037】
(データベース)
また、本システムのデータベース1a、1b、1cは、1つ以上の部分(レキシコン)から構成されている。このレキシコンは、レキシコンセットのデータの部分に選択的にアクセスしたり、属性を付与するための単位であって、名称(レキシコン名)等でユニークに識別される。本システムの実行環境においては、図2に示すように、ユニスペースが複数のレキシコンセットを含むことができるので、レキシコンセットもまた名称(レキシコンセット名)等で識別する。さらに、同一の物理的マシン上に共通のネットワークを使用して複数のユニスペース、すなわち異なるレキシコンセットの組を管理する複数のシステムとして本システムを実施することもあり得るので、ユニスペースもまた名称(ユニスペース名)等で区別する。
【0038】
そして、各ホストのデータベースに格納されているレキシコンセットは、いずれかのホスト上にそのオリジナルデータが保有され、他のホストにはそのコピーであるレプリカデータが保有されている。例えば、図1においては、ホストA(コンピュータA)には、データBのオリジナルデータが保有され、ホストC(コンピュータC)には、データAのオリジナルデータが保有されている。また、ホストB(コンピュータB)には、データA及びデータBのレプリカデータが保有されている。また、本システムにおいては、データの更新処理は、オリジナルデータに対してのみ実行でき、レプリカデータでは、データの更新処理を行うことはできない。
【0039】
(トランザクション)
アプリケーションからの一度の依頼によって実施されるデータ参照及び更新の処理単位を「トランザクション」と呼ぶ。各々のトランザクションには、具体的な処理内容を記述した「トランザクション関数」が対応する。すなわち、図1に示したトランザクション関数(TR関数)A,Bは、各マシンのデータベースにアクセスして、アプリケーション共通で必要となる処理を実現する関数である。すなわち、本システムにおいては、各アプリケーションX,Y,Zは、直接データベースにアクセスして処理を行うわけではなく、トランザクション関数を介してデータベースにアクセスするように構成されている。
【0040】
また、トランザクションには、各種の属性を付与するため識別子(トランザクション名等)が含まれている。この識別子に対して、例えば実行すべきトランザクション関数を対応付けたりする。この識別子は、付与すべき属性の種類に応じて必要な数を設定すればよい。
【0041】
また、トランザクションが操作の対象とするのは、1つのレキシコンセットとする。本システムでは、ユニスペースが複数のレキシコンセットを含むことができるので、トランザクションには、操作対象のレキシコンセットを明記する。このレキシコンセット名を上記識別子の1つと考えても良い。もちろん、他の識別子から操作対象レキシコンセットを判別する手段を設けることもでき、レキシコンセット名の明記は必須ではない。
【0042】
そして、本システムにおいては、アプリケーションからのデータ操作の依頼をトランザクションを単位として処理する。従って、オリジナルデータに対する更新処理も更新TRを単位として実行され、レプリカサイトにおける更新内容(レプリケーションデータ)のレプリカデータに対する反映処理も、原因となった更新TRを単位として行われる。
【0043】
(本システムの主たる目的)
本システムの主たる目的は、データベース(レキシコンセット)を複数のマシン上で同一内容に保つことを意図している。すなわち、各マシンは同一内容のデータベースのコピーを保持しており、1つのマシンでそのデータベースに対して更新が加えられた場合には、通信ネットワークを経由して各マシンに更新情報(内容)を伝達し、各マシンのデータベースに更新内容を速やかに反映させることによってこの目的を達成しようとするものである。本明細書においては、この機能を「レプリケーション」と称する。
【0044】
なお、本明細書においては、データベースを更新する権利を持つマシンをそのデータベースのオリジナルサイト、そのデータをオリジナルデータと呼ぶ。また、それ以外のマシンでそのデータベースのコピーを保有するものをレプリカサイト、そのデータをレプリカデータと呼ぶ。
【0045】
また、本システムは、データベースを更新するトランザクション(更新TR)を上記オリジナルサイトで実行する機能を備え、前記レプリケーションと併せて、複数のコピーからなるデータベースを、各マシンのアプリケーションからは論理的に1つのデータベースに見えるように運用する。すなわち、各マシンのアプリケーションはオリジナルサイトがどのマシンかを気にする必要がない。本明細書においては、このようなシステム構成を「リモート/ローカル構造」と呼ぶ。
【0046】
さらに、本システムにおいては、トランザクションの実行及びレプリケーションデータの反映が一単位完了するまでは、そのデータベース(レキンコンセット)を操作対象とする他のトランザクションの処理を行わない(もちろん他のレプリケーションデータの反映も行なわない)。それらの実行及び反映、また、そのデータベース(レキンコンセット)を操作対象とする他のトランザクションの実行またはレプリケーションデータの反映が進行中の場合は、それらの完了を待って開始される。すなわち、(1つのマシンの)1つのデータベース(レキンコンセント)に関するトランザクションの実行及びレプリケーションデータの反映は、トランザクション単位でシリアルに処理される。それゆえ、トランザクション及びその実行を依頼したアプリケーションが他のトランザクションの実行途中のデータベースの内容にアクセスすることはない。
【0047】
なお、更新操作を行なわず、データの検索・参照のみを行なうトランザクションを、更新トランザクションに対して参照トランザクションと呼ぶ。本システムでは、レプリケーション機能によって、オリジナルデータとレプリカデータの一致がトランザクション単位で速やかに図られるので、参照トランザクションは、そのトランザクションを依頼されたマシン(ローカルマシン)のレプリカデータを操作対象としても何ら不都合を生じない。
【0048】
また、通信ネットワークはオリジナルサイトがレプリケーションをレプリカサイトに伝達してレプリケーション機能を実現するための媒体であると同時に、レプリカサイトで発行(依頼)された更新トランザクションをオリジナルサイトに転送するための媒体でもある。この更新トランザクションをオリジナルサイトのみで実行する機能は、具体的には通信ネットワークを経由してレプリカサイトで発行された更新トランザクションをオリジナルサイトに転送することによって実現される。
【0049】
[2.用語の説明]
各実施形態について説明する前に、本明細書中で用いられる種々の用語について説明する。
ユニスペースとは、図2に示すように、本システムが対象とするデータベース(レキシコンセット)を複数含む形態をいう。また、ユニスペースは、データ及びデータアクセス(参照・更新)のサービスを区別するための識別子となるので、ユニスペース名が付与される。
【0050】
レキシコンセットとは、ユニスペースを構成する共有データに定められた部分集合のことである。このレキシコンセット毎に各マシンにそのデータを配置するか否かを指定することができる。本システムにおける種々の処理は、このレキシコンセット単位でなされる。
【0051】
トランザクションとは、アプリケーションプログラムの要求に応じて、共有データを参照したり、更新する操作をいう。トランザクションが一度に操作対象とすることができるデータの集合は、ひとつのレキシコンセットのみである。
【0052】
ローカルサイト:アプリケーションから見た自サイトのこと
リモートサイト:アプリケーションから見た他のサイトのこと
オリジナルサイト:オリジナルデータを持っているサイトのこと
レプリカサイト:レプリカデータ(コピー)を持っているサイトのこと
【0053】
ローカル参照:トランザクション操作が、共有データの「参照」だけの場合で、完全にローカルな主記憶データへのアクセスとして処理され、ネットワークのトラフィックは一切発生しない処理をいう。
ローカル更新:トランザクションを発行したアプリケーションプログラムが存在するサイトがオリジナルサイトの場合の更新処理をいう。つまり、自サイトでデータ更新をすることができ、更新後、他のサイトにその更新データをマルチキャスト送信することにより、常に各ホストで同一のデータを利用できるようにする機能をいう。
【0054】
リモート更新:トランザクションを発行したアプリケーションプログラムが存在するサイトがレプリカサイトの場合の更新処理をいう。つまり、自サイトのデータはレプリカデータなので、データ更新をすることができず、そのトランザクションをオリジナルサイトに転送し、オリジナルサイトでデータ更新後、その更新データをレプリケーション受信することにより、常に各ホストで同一のデータを利用できるようにする機能をいう。
なお、自サイトがレプリカサイトであり、且つ、トランザクションを発行したアプリケーションプログラムが存在しない場合には、オリジナルサイトからレプリケーションされた更新データを、自サイトに反映させることにより、常に各ホストで同一のデータを利用できるように構成されている。
【0055】
レプリケーションとは、更新トランザクションによるデータの変更を他のマシンへマルチキャストで送信する機能である。
リトリーブとは、ネットワーク経由で、すでに運用中の他のマシンからレキシコンセットのデータを取り寄せて、自サイトで運用を開始するまでの処理をいう。
【0056】
[3.各実施形態とコンピュータ]
本発明の各実施形態はコンピュータ上に実現され、実施形態の各機能は、所定の手順(プログラム)がこのコンピュータを制御することで実現される。
本明細書における各「手段」は、実施形態の各機能に対応する概念的なもので、必ずしも特定のハードウェアやソフトウェア・ルーチンに1対1には対応しない。同一のハードウェア要素が、場合によって異なった手段を構成する。例えば、コンピュータは、ある命令を実行するときにある手段となり、別の命令を実行するときは別の手段となりうる。また、一つの手段が、わずか1命令によって実現さる場合もあれば、多数の命令によって実現される場合もある。したがって、本明細書では、以下、実施形態の各機能を有する仮想的回路ブロック(手段)を想定して実施形態を説明する。また、本実施形態における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、また、実行ごとに異なった順序で実行してもよい。このような順序の変更は、例えば、ユーザが実行可能な処理を選択するなどメニュー形式のインターフェース手法によって実現することができる。
【0057】
[4.第1実施形態]
本実施形態は、本発明に係る分散データ管理システム(以下、本システムという)の特徴的な機能である「レプリケーション」に関するものである。ここで、レプリケーション機能とは、更新トランザクションによるデータの変更を他のマシンへマルチキャストで送信する機能である。すなわち、オリジナルサイトで更新トランザクションを実行し、更新分のみをマルチキャストでレプリカサイトへ送信し、レプリカサイトではそれを受信し、レプリカデータへ反映することにより、ネットワーク上のすべてのマシンにおけるデータの同一性を保持するものである。
【0058】
[4−1.第1実施形態の構成]
図3は、本システムが適用されるネットワーク構成の一例を示したものである。すなわち、図3は、2つのLANがルーターRを介してWANにより接続された状態を示す概念的なネットワーク構成図であり、各LANには複数のパーソナルコンピュータ(PC)が接続されている。なお、本システムを適用する具体的なネットワーク構成は自由であり、WANは必須ではなく、各LANに各種サーバーを設けることも自由である。
【0059】
図4は、本システムの第1実施形態であるレプリケーションを実現するために、各マシンに備えられた分散データ管理装置の構成を示す機能ブロック図である。なお、この分散データ管理装置は、上記「全体像の説明」で示した図1における処理部に対応するものである。
【0060】
すなわち、本実施形態の分散データ管理装置10は、アプリケーションからのトランザクションの実行依頼を受け付けるトランザクション受付部101と、自サイトにおけるトランザクションの実行を制御するトランザクション実行制御部102と、トランザクションを実行するためのトランザクション関数を呼び出してトランザクションを実行するトランザクション実行部105と、後述するレプリケーションデータを自サイトのデータに反映させるレプリケーション処理部106と、データ受信部107及びデータ送信部108を備えている。
【0061】
なお、上記トランザクション受付部101においては、トランザクションの実行依頼を受け付ける毎に「受付ID」が発行される。この受付IDは、(受付マシン、受付シリアル番号)の組からなり、あらゆるトランザクションはこの受付IDによって、「そのトランザクションは、どのサイトで、何番目に受け付けたトランザクションであるか」を一意的に識別することができるようになっている。
【0062】
また、前記データ送信部108は、後述するオリジナルサイトへのリモートTRの送信、他のサイトへのレプリケーションの送信を行う部分であり、データ受信部107は、レプリカサイトからのリモートTRの受信、他のサイトからのレプリケーションの受信を行う部分である。
【0063】
また、本実施形態の分散データ管理装置10には、オリジナルデータあるいはレプリカデータであるレキシコンセットを格納するデータ格納部109と、トランザクション名/そのトランザクションの処理対象となるレキシコンセット名/そのレキシコンセットのオリジナルサイト名/そのトランザクションの属性(参照・更新)/そのトランザクションに対応するトランザクション関数名を対応づけて示したトランザクション登録表110(図5)と、自サイトがレプリカサイトである場合に用いられるレプリケーション待ちTR表111(図6)が備えられている。
そして、上記のような構成を有する分散データ管理装置10を備えた各ホストにおいて、アプリケーション112によりトランザクションの実行が依頼されると、以下に述べるような処理がなされる。
【0064】
[4−2.第1実施形態の作用]
まず、本システムで実行されるトランザクションには、データを参照するだけの「参照」と、データが変更される「更新」の2種類の処理がある。また、そのトランザクションを実行するホストにも「ローカルサイト…自サイトのこと」と「リモートサイト…他のサイトのこと」の2種類がある。本システムにおいては、すべてのホストがその主記憶上に同じデータを持っているが、オリジナルデータを持っているサイト(オリジナルサイト)と、そのレプリカ(コピー)を持っているサイト(レプリカサイト)とがある。データの更新はオリジナルデータを持っているオリジナルサイトでしかできない。そして、その変更部分をネットワーク上のすべてのレプリカサイトにレプリケーションして、常に各ホストで同一のデータを利用できるように構成されている。
【0065】
一方、「参照」処理は、データを参照するだけでその書き換えを行うことがないので、そのホストにあるデータがオリジナルデータであるか、レプリカデータであるかを問わず、各サイトで実行できる。
以下、これらの各トランザクションについて、図7から図12に示すフローチャートに従って具体的に説明する。
【0066】
(1)ローカル参照処理
ローカル参照処理は、図7に示したような手順で実行される。まず、トランザクション受付部101がアプリケーションよりデータ参照TRを実行すべきとの依頼を受け付けると(S701)、受付IDを発行する。そして、この依頼に従い、トランザクション実行制御部102は図5に示すようなトランザクション登録表110を検索し(S702)、トランザクションを実行するサイトと、実行に当たって必要なトランザクション関数を決定する(S703)。次いで、トランザクション実行制御部102の指示に従い、トランザクション実行部105において、トランザクション関数の呼び出しが行われ(S704)、このトランザクション関数を利用してトランザクションの実行、すなわちデータ参照処理が実行される(S705)。このようにしてトランザクション実行部105によってデータ参照処理が実行された後は、トランザクション実行制御部102はその実行結果をアプリケーション112に通知する(S706)。
【0067】
(2)ローカル更新処理
本システムにおいては、すべてのホストがその主記憶上に同じデータを保有しているが、各サイトにはオリジナルデータを持っている、ネットワーク上で唯一のオリジナルサイトと、その他のレプリカ(コピー)を持っているレプリカサイトがある。そして、データの更新処理はオリジナルデータを持っているオリジナルサイトでしか行わない。ここで説明するローカル更新処理は、トランザクションの実行依頼を受けた自サイト(ローカルサイト)がオリジナルサイトの場合に行われる処理である。
【0068】
図8に示したように、まず、オリジナルサイトにおいて、トランザクション受付部101が更新TRを実行すべきとのアプリケーションからの依頼を受け付けると(S801)、受付IDを発行する。そして、この依頼に従い、トランザクション実行制御部102は図5に示したトランザクション登録表110を検索し(S802)、自サイトが更新TRを実行し得るオリジナルサイトであるか否かを判定すると共に、自サイトがオリジナルデータの更新処理を実行するに当たって必要なトランザクション関数を決定する(S803)。次いで、トランザクション実行制御部102の指示に従い、トランザクション実行部105において、トランザクション関数の呼び出しが行われ(S804)、このトランザクション関数を利用してオリジナルサイトにおけるデータ更新処理が実行される(S805)。
【0069】
このようにしてトランザクション実行部105によって自サイトにおけるデータ更新処理が実行された後、データ送信部108を介して更新データ(レプリケーション対象データ)を各レプリカサイトに対してマルチキャスト送信する(S807)。また、トランザクション実行制御部102は、そのデータ更新の実行結果をトランザクション受付部101を介して依頼元であるアプリケーション112に通知する(S808)。
【0070】
なお、更新データをデータ受信部107に受信したレプリカサイトがあれば、そのレプリカサイトでは、これをトランザクション実行制御部102に伝達し、トランザクション実行制御部102はレプリケーション処理部106に指示してこれをレプリカデータに反映させ、レプリカデータをオリジナルデータに一致させることにことにより、すべてのホストが主記憶上に同じデータを保有しているという状態を速やかに回復する。
【0071】
(3)リモート更新処理
更新TRの実行依頼を受けた自サイトがレプリカサイトの場合、すなわち、自サイトのデータはレプリカデータであるためデータ更新をすることができない場合は、そのトランザクションをオリジナルサイトに転送し、オリジナルサイトでデータの更新を行った後、その更新データを自サイトにレプリケーションしてもらうことになる。
【0072】
このリモート更新処理においては、各ホストによって処理が異なる。すなわち、レプリカサイトである自サイトにアプリケーションプログラムが存在し、このアプリケーションプログラムからのデータ更新TRを受け付け・実行する場合(リモート更新…その1)、自サイトがオリジナルサイトであり、トランザクションの実行依頼を受けた他のレプリカサイトからオリジナルデータの更新を依頼された場合(リモート更新…その2)、自サイトはレプリカサイトであり、且つデータ更新処理(トランザクションの実行)を依頼されていない場合(リモート更新…その3)の3種類の状況でそれぞれ異なる処理がなされる。
【0073】
(3−1)リモート更新(その1)
まず、レプリカサイトである自サイトにアプリケーションプログラムが存在し、このアプリケーションプログラムからのデータ更新TRを受け付けた場合は、自サイトが保有するデータはレプリカデータであるので、これを直接更新することはできない。そこで、オリジナルサイトに対してそのオリジナルデータの更新処理を依頼し、その後、その更新データを自サイトに反映させるためのレプリケーションを実行する。
【0074】
すなわち、図9に示したように、本レプリカサイトにおいて、トランザクション受付部101がアプリケーションプログラムよりデータ更新TRの実行依頼を受け付けると(S901)、受付IDを発行する。そして、この依頼に従い、トランザクション実行制御部102は図5に示すトランザクション登録表110を検索し(S902)、トランザクションを実行することのできるオリジナルサイトと、実行に当たって必要なトランザクション関数を決定する(S903)。次に、トランザクション実行制御部102は、このトランザクションを図6に示すレプリケーション待ちTR表111に登録し(S904)、さらにこのデータ更新TRの指令をデータ送信部108を介してトランザクション登録表110から検索したオリジナルサイトに転送する(S905)。
【0075】
オリジナルサイトにおいて、上記(2)ローカル更新処理において述べた場合と同様にしてデータ更新TRが実行され、更新後のデータが各レプリカサイトに送信される(S906)。このとき、本レプリカサイトにおいては、オリジナルサイトからのレプリケーションを受信し(S907)、図6に示すレプリケーション待ちTR表111を受付IDをもとに検索して(S908)、このレプリケーション待ちTR表に登録されているトランザクションについて、受信したレプリケーションの内容を反映したデータ更新を行う(S909)。このデータ更新処理は、データ受信部107が受信した更新データに基づいて、レプリケーション処理部106がレプリカデータの一部(差分)あるいは全部を書き換えることにより行われる。
このようにしてレプリケーション処理部106によってデータ更新処理が実行された後は、トランザクション実行制御部102はその実行結果をデータ更新を依頼されたアプリケーション112に通知する(S910)。
【0076】
(3−2)リモート更新(その2)
自サイトがオリジナルサイトであり、トランザクションの実行依頼を受けた他のサイトからオリジナルデータの更新を依頼された場合は、オリジナルデータの更新をした後、更新データを他のすべてのサイトにレプリケーションする。
【0077】
すなわち、図10に示したように、更新対象となるオリジナルデータを所有するオリジナルサイトにおいては、データ受信部107がレプリカサイトから転送されたデータ更新TRを受信すると(S1001)、トランザクション実行制御部102は図5に示すトランザクション登録表110を検索して(S1002)、自サイトがオリジナルデータを所有するサイトであるか否か、すなわちそのトランザクションの実行サイトであるか否かを判定すると共に、自サイトがオリジナルサイトであった場合には、そのトランザクションの実行に必要なトランザクション関数を決定する(S1003)。
【0078】
次いで、トランザクション実行部105は、トランザクション登録表110に基づいて決定されたトランザクション関数を呼び出し(S1004)、この関数を利用してオリジナルデータに対してデータ更新TRを実行する(S1005)。このようにしてオリジナルデータの更新処理がなされた後は、更新されたレプリケーション対象データをすべてのレプリカサイトに反映すべく、データ送信部108から各レプリカサイトに対してマルチキャスト送信する(S1006)。
【0079】
(3−3)リモート更新(その3)
アプリケーションプログラムが存在しないレプリカサイトでのデータ更新処理、すなわち、自サイトはレプリカサイトであり、且つ、トランザクションの実行依頼もされていない場合の処理は、前記リモート更新(その1)において実行されたオリジナルサイトでのデータ更新処理を、オリジナルサイトからレプリケーションして自サイトが所有するレプリカデータに反映させるだけである。
【0080】
すなわち、図11に示したように、データ受信部107がオリジナルサイトからのレプリケーションを受信すると(S1101)、トランザクション実行制御部102は、自サイトのレプリケーション待ちTR表を、レプリケーションに記載された受付IDをもとに検索する(S1102)。この場合、このレプリカサイトでは、アプリケーションからのデータ更新処理の実行依頼を受け付けていないため、レプリケーション待ちTR表には登録されているトランザクションがないので(S1103)、トランザクション実行制御部102は、レプリケーション処理部106により、受信したレプリケーションの内容を反映させるように自己の所有するレプリカデータを更新する(S1104)。この結果、すべてのレプリカサイトのデータがオリジナルサイトのデータと等価になる。
【0081】
(3−4)全体のフローチャート
上記データ参照TR及び各サイトにおけるデータ更新TRの個々の処理内容は上述した通りであるが、次に、各トランザクションが、各サイトにおいてどのように判別され、処理されるかについて、その全体像を図12によって説明する。
【0082】
まず、オリジナルサイトかレプリカサイトかを問わず、あるサイトがアプリケーションプログラムからトランザクションの実行を依頼されると(S1201)、トランザクション受付部101が、トランザクションの実行依頼を受付ける(S1202)と共に、受付IDを発行する。トランザクション実行制御部102は、このトランザクションが更新TRか否かを判定し(S1203)、更新TRでない場合、すなわち依頼されたトランザクションが参照TRである場合には(S1203の“NO”)、トランザクション登録表110を検索して(S1204)、自サイトで実行できるトランザクションであるか否か、また、そのトランザクションを実行するためにどのような関数が必要であるかを検索する。
その結果得られた情報に従い、参照TRを実行するために必要なトランザクション関数の呼び出しを行い(S1205)、この関数を利用してデータ参照TRを実行する(S1206)。その後、データ参照TRの実行結果を、アプリケーションプログラム112に通知する(S1207)。
【0083】
次に、前記ステップS1203において、受け付けられたトランザクションがデータの更新TRであると判定された場合には(S1203の“YES”)、データ更新を受け付けた自サイトがオリジナルサイトか否かを判定する(S1208)。自サイトがオリジナルサイトである場合には(S1208の“YES”)、トランザクション登録表110を参照してオリジナルサイトにおけるデータ更新のために必要な関数を検索し(S1209)、この検索結果に基づいてデータ更新TRに必要なトランザクション関数の呼び出しを行う(S1210)。
【0084】
その後、これらの関数を利用して、オリジナルデータの更新処理を行い(S1211)、さらにその更新結果を各レプリカサイトに反映すべく、レプリケーションの送信を行う(S1212)。また、データ更新の結果を、依頼元である自サイトのアプリケーションプログラムに通知する(S1207)。
【0085】
一方、ステップS1203において、データ更新TRを受け付けたサイトがオリジナルサイトでない場合、すなわち、自サイトがレプリカサイトである場合には、受け付けたトランザクションをレプリケーション待ちTR表に登録し(S1213)、オリジナルサイトである他サイトにそこが保有するオリジナルデータの更新処理を転送する(S1214)。オリジナルサイトにおいては、自己のアプリケーションプログラムからデータ更新TRを受け付けた場合と同様にして、データ更新TRを実行する(S1215)。
【0086】
このオリジナルサイトにおけるデータ更新TRが終了すると、更新データが各レプリカサイトに送信されるので、データ更新TRを受付けたレプリカサイトでもオリジナルサイトからのレプリケーションデータが受信される(S1216)。そこで、このレプリカサイトにおいては、前記レプリケーション待ちTR表に基づいて、この受信データがアプリケーションプログラムから要求されているレプリカデータの更新データであることが判るので、この更新データに従いレプリカデータの更新処理を行うと共に(S1217)、その更新結果をトランザクションを受け付けたアプリケーションプログラムに通知する(S1207)。
【0087】
(3−5)具体例
ここで、サイトAからサイトBにリモート更新TRを出した場合について、より具体的に説明する。
(1)サイトAでトランザクションを受け付け、例えば、受付ID(A、10)を発行する。この例ではリモートTRなので、受付ID(A、10)のトランザクションを「レプリケーション待ちTR表」に登録する。
(2)リモートTRをオリジナルサイトに転送する。
(3)サイトBがリモートTR(A、10)を受信する。このトランザクションによる更新は、オリジナルのレキシコンセットに対する例えば99回目の更新であった場合、レプリケーションログに対して更新ID(A、10、99)を発行する。このレプリケーションログをマルチキャスト送信する。
(4)サイトAがレプリケーションログ(A、10、99)を受信すると、先頭の(A、10)をもとに「レプリケーション待ちTR表」を検索して、登録されているトランザクションを見つけ出し、そのレプリケーションデータを反映した後、アプリケーションに終了を通知する。
【0088】
[4−3.第1実施形態の効果]
本実施形態によれば、以下のような効果が得られる。
(1)等価な共有データを保有するサイトを、オリジナル/レプリカに区別することでデータ更新の一貫性を保証することができる。
(2)トランザクションの事前登録時に参照/更新を宣言させることで、参照時にはネットワークI/Oが一切生じない高速な共有データへのアクセスを実現することができる。また、トランザクション処理がオリジナルサイトに集中することを避け、負荷の分散を図ることが可能である。
DBMSに格納するデータは「変更頻度の少ない多量のデータ」と「頻繁に変化する少量のデータ」とに分離できる場合が多いので、前者に対して「参照TR」を利用することで、効果的にシステムを高速化すると共に負荷分散を実現することができる。
【0089】
(3)アプリケーションに対しては、データのオリジナル/レプリカの違いを隠蔽しつつ共有データへのトランザクション処理(データ参照・更新)のサービスを提供することができる。
すなわち、共有データのオリジナル/レプリカ属性をシステムが自動判別して処理することにより、クライアント/サーバ相当の処理(オリジナルデータの集中管理)をアプリケーションに対して隠蔽することができる。すなわち、本実施形態の分散データ管理装置10が稼働しているサイトにおいては、アプリケーションは、更新TRを実行すべき(オリジナル)サイトを自ら決定する手間、及びそのサイトと自ら通信する手間を省くことができる。さらに重要な効果は、オリジナルサイトが変更された場合でも、分散データ管理装置10のトランザクション登録表を変更するだけで、アプリケーションの動作はなんら変更する必要がない。
【0090】
(4)リモート更新時はネットワークI/O(リモートサイトの返事)を待たずに、複数のトランザクションをパラレルに処理することができる。
すなわち、1つのリモートTRの終了を待って、他のアプリケーションが要求するトランザクション処理を中断することがないので、トランザクション処理効率が大幅に向上する上に、特定のリモートTRの終了を待つアプリケーションにとっては、レプリカデータが更新されたタイミングでトランザクションが終了するので、ローカルTRの場合と全く違いがない。
【0091】
これに対して、アプリケーションが更新の場合のみ、従来技術のRPC(Remote Procedure Call)のような手段で、直接オリジナルサイトにトランザクションの実行を依頼すると、アプリケーションがトランザクションの実行完了通知を受け取るタイミングと、自サイトのレプリカデータにそのトランザクションの更新データが反映されるタイミングとは、必ずしも一致しない。そのため、自サイトのデータの内容とアプリケーションが認識する(自らが依頼した)トランザクションの実行(完了)状況との整合が、ローカル更新処理の場合とは異なってしまう。すなわち、本実施形態によれば、高いトランザクション処理のスループットを実現しつつ、アプリケーションに対してシステムの非一様性を隠蔽することができる。
【0092】
(5)レプリケーションデータの反映は、更新TRのレプリカサイトにおける再実行とは異なり、レプリカサイトにおいて更新TRの管理(プログラムの保有及び実行)を省略する余地を生む。また、レプリケーションデータの反映の方が更新TRの実行より計算量が少ないので、レプリカサイトにおけるデータベース更新(維持)の負荷が大幅に緩和される。
(6)更新TRの受付レプリカサイトにおいて、レプリケーションデータの反映に同期してトランザクションの完了を通知することにより、サイトに依存しない一貫したデータアクセス手段を提供することができる。
【0093】
[5.第2実施形態]
本実施形態は、上記第1実施形態の変形例である。すなわち、ネットワークで接続された複数のマシンにおいて、それぞれのマシン(ホスト)で独自に用いるデータ(レキシコン)をデータ格納部に格納する場合がある。このような各ホストに特有なデータは、たとえそのデータが更新されたとしても、その更新データを他のホストへレプリケーションする必要はない。
【0094】
そこで、このような各ホストに特有なデータを、レキシコンを定義する際に「Multi ORG Lexicon(マルチオリジナルデータ)」として定義し、一方、ネットワークを介したレプリケーションによりオリジナルデータとレプリカデータの同一性を保持するデータを、「Single ORG Lexicon(シングルオリジナルデータ)」として定義することにより、予め両者を区別しておく。ただし、この場合、自サイトがその「Multi ORG Lexicon」のオリジナルサイトであるかレプリカサイトであるかを問わず、各マシン毎に自由に更新処理を行うことができ、更新データが他のサイトへレプリケーションされないようになっている。
【0095】
すなわち、本実施形態においては、図13に示したように、あるマシンにおいて、アプリケーションプログラムからトランザクション(更新TR)の実行が依頼されると、図4に示したトランザクション実行制御部102において、そのトランザクションが処理対象とするレキシコンが「Multi ORG Lexicon」であるか「Single ORG Lexicon」であるかが判断され、「Single ORG Lexicon」であると判断された場合には、上記第1実施形態で説明したと同様の処理が行われる(図13の上段参照)。一方、「Multi ORG Lexicon」であると判断された場合には、自サイトがオリジナルサイトであるかレプリカサイトであるかを問わず、そのトランザクション処理が実行され、その更新結果は他のサイトにレプリケーションされず、自サイトに留まる(図13の下段参照)。
【0096】
上述したように、本実施形態によれば、データベースの特定の部分(Multi ORG Lexicon)に関しては、そのデータが更新されてもレプリケーションデータを生成・伝達しないという扱いを加味することによって、同一トランザクションで、システム全体で同一であるべきデータとサイト毎に扱いが異なるデータを同時に更新することができる。
【0097】
また、マルチオリジナルデータのみを更新するトランザクションを、参照TRと同様にローカルサイト(自サイト)で実行することで、特定のデータの扱いを各サイトの裁量に委ねることができる。さらに、すべてのデータにレプリケーションを義務づけた場合に生じる無駄なレプリケーションを回避することができる。
【0098】
[6.第3実施形態]
[6−1.リトリーブ機能の概要]
リトリーブ機能とは、システムの起動時に、オリジナルデータやレプリカデータを設定された通りに利用可能な状態にする機能である。本実施形態の分散データ管理システムにおいては、最新のデータをもつマシン(オリジナルサイトでも、レプリカサイトでもよい)から最新データのスナップショットをネットワーク経由で受け取る。
【0099】
この場合、最新のデータを受け取る相手先の順序を指定することができ、順位の高いマシンへ送信要求を出す。このとき何らかの障害でそのマシンから最新データが得られない場合、次の順位のマシンへデータ送信を要求する。どのマシンからもデータを受け取れない場合、オリジナルのあるマシンを最終のリトリーブ先とする。オリジナルやレプリカの配置、ネットワークの帯域幅、マシンのスペックなどによってこの順位を決定することで、システム構成に適した設定をとることができる。
【0100】
このように、最新データのスナップショットをネットワーク経由で受け取ることでデータ構築する処理を「ネットワークリトリーブ」という。すなわち、「ネットワークリトリーブ」とは、ネットワーク経由で、すでに運用中の他のマシンからレキシコンセットのデータを取り寄せて、自サイトで運用を開始するまでの処理の名称である。以下、サイトAがサイトBからレキシコンセットのデータをコピーして運用を開始することを「サイトAがサイトBからリトリーブする」と呼ぶこととする。
【0101】
[6−2.第3実施形態の構成]
図14は、本システムの第3実施形態であるリトリーブを実現するために、各マシンに備えられた分散データ管理装置の構成を示す機能ブロック図である。なお、この分散データ管理装置は、上記「全体像の説明」で示した図1における処理部に対応するものである。また、本実施形態の分散データ管理装置20は、図4に示した第1実施形態の分散データ管理装置に以下に述べるモジュールを追加したものであるので、第1実施形態の分散データ管理装置との相違点についてのみ説明する。
【0102】
すなわち、本実施形態の分散データ管理装置20は、図4に示した第1実施形態の分散データ管理装置10に、スナップショット出力部120と、リトリーブ対象となるレキシコンセットのID番号/そのレキシコンセットの運用状況/そのレキシコンセットの更新番号を対応づけて示したレキシコンセット・ステータス表(図15)とバッファを備えたレキシコンセット・ステータス表+バッファ121を備えている。
【0103】
なお、本実施形態においては、データ送信部108は、後述するスナップショットの送信、オリジナルサイトへのスナップショット送信要求(リトリーブ要求)の送信、他のサイトへのレプリケーションの送信を行い、データ受信部107は、オリジナルサイトからのスナップショットの受信、他のサイトからのレプリケーションの受信を行う。
【0104】
そして、上記のような構成を有する分散データ管理装置20を備えた各ホストにおいて、アプリケーション112によりネットワークリトリーブの実行が依頼されると、以下に述べるような処理がなされる。
【0105】
ここで、上記「スナップショット」とは、ある瞬間のレキシコンセットを構築するために必要なデータの名称をいう。また、「レキシコンセットの更新番号」とは、トランザクション実行部105において、更新TRが実行されレキシコンセットが更新されるたびに発行されるものであって、レキシコンセットに加えられた変更回数をカウントした番号をいう。従って、オリジナルサイトでは更新トランザクションの処理毎に更新番号が増加し、レプリカサイトではレプリケーション反映処理毎に、更新番号が増加する。そして、更新番号#Nのスナップショットからは、更新番号#Nのレキシコンセットを構築することができる。また、「更新番号#Nのレプリケーションログ」とは、更新番号#N−1のレキシコンセットから更新番号#Nのレキシコンセットを得るための差分情報(更新記録)をいう。
【0106】
[6−3.第3実施形態の作用]
続いて、「ネットワークリトリーブ」について、図16および図17のフローチャートを参照して説明する。なお、図16は、ネットワークリトリーブを実行するサイトA(レプリカサイト)における処理手順を示したものであり、図17は、オリジナルサイトであるサイトBにおける処理手順を示したものである。
【0107】
(6−3−1)サイトAにおける処理
まず、サイトAの初期立ち上げにおいて、図15に示すようなレキシコンセット・ステータス表に、あるレキシコンセットのリトリーブの実行に着手する旨のエントリを作成して、そのレキシコンセットを「リトリーブ中」とする(S1601)。次に、スナップショットの送信をオリジナルサイトであるサイトBへ要求する(S1602)。この送信要求に伴いサイトBがスナップショットの送信を開始すると、サイトAにおいてはそのスナップショットの受信を開始する(S1603)。
【0108】
サイトBから受信したスナップショットに対応するレキシコンセットについて、レプリケーションがあるか否かを検証し(S1604)、レプリケーションがない場合には(S1604が“NO”)、スナップショットの受信が完了したか否かを検証する(S1605)。スナップショットの受信が完了していない場合には(S1605が“NO”)、スナップショットの受信を継続し、再度ステップS1604に戻って受信したスナップショットについてのレプリケーションの有無を検証する。
【0109】
ステップS1604において、受信したスナップショットに対応するレキシコンセットについて、レプリケーションがある場合には(S1604が“YES”)、そのレプリケーションについてその更新番号がスナップショットの更新番号より大きいか否かを検証する(S1606)。そして、レプリケーションの更新番号がスナップショットの更新番号よりも小さい場合、すなわち、そのレプリケーションが、今受信したスナップショットよりも古いデータである場合には(S1606が“NO”)、そのレプリケーションデータを破棄する(S1607)。一方、レプリケーションの更新番号がスナップショットの更新番号よりも大きい場合には(S1606が“YES”)、現在リトリーブ中のデータは更新する必要があるので、レプリケーションデータのバッファリングを行なう(S1608)。
【0110】
すなわち、リトリーブしているデータよりバージョンの古いデータ(更新番号が小さいデータ)がレプリケーションされた場合には、そのデータは不要なので破棄し、リトリーブしているデータよりバージョンの新しいデータ(更新番号が大きいデータ)がレプリケーションされた場合には、それらをバッファリングして蓄積しておく。
【0111】
これらレプリケーションデータの破棄、あるいはバッファリングが終了した後、ステップS1605に戻り、スナップショットの受信が完了したか否かの検証を行う(S1605)。スナップショットの受信が完了した後は(S1605の“YES”)、受信したスナップショットを利用してデータ構築、すなわちレキシコンセットの構築を行う(S1609)。
【0112】
次に、前記ステップS1608においてバッファリングしておいたレプリケーションデータをバッファから読み出し(S1610)、これに基づいてレプリケーションデータを処理する(S1611)。このようにして、データ構築が完了した後は、レキシコンセット・ステータス表を「リトリーブ完了」にして(S1612)、処理を終了する。
【0113】
(6−3−2)スナップショットを受信したサイトBにおける処理
サイトAからのリトリーブ要求を受信した(S1701)オリジナルサイトであるサイトBにおいては、まず、要求されたスナップショットがすでに存在するか否かを検証する(S1702)。すなわち、サイトA以外の他のサイトからすでにリトリーブ要求を受信して、その際に主記憶データのスナップショットを作成しており、そのスナップショットがまだ主記憶領域に存在する場合には、サイトAからのリトリーブ要求時にすでに存在するスナップショットを利用することが可能である。
【0114】
そこで、スナップショットが存在するか否かを検証し、スナップショットが存在しない場合には(S1702の“NO”)、主記憶データのスナップショットを新規に作成し(S1703)、作成したスナップショットを送信キューへ追加する(S1704)。一方、前記ステップS1702において、要求されたスナップショットがすでに存在する場合には(S1702の“YES”)、すでに送信済みの部分に限り再度送信キューへ追加する(S1705)。このようにして、送信キューに追加されたスナップショットは、所定の送信タイミングにより、リトリーブの要求元であるサイトAに送信される。
【0115】
(6−3−3)具体例
サイトAがサイトBからリトリーブする処理を、より具体的に説明する。
(1)サイトAがサイトBにスナップショット送信要求を出す。
(2)サイトBはスナップショットを作成して、サイトAへ送信を開始する。このときのスナップショット番号を“#47”とする。
(3)サイトAがスナップショット受信を開始する。スナップショット受信には長時間を要するので、この間もレキシコンセットの更新が発生して、レプリケーションを受信することがある。この場合、サイトAが、スナップショットの番号“#47”より大きな番号のレプリケーションを受信した場合は、そのデータをバッファリングして保存しておく。
(4)サイトAにおいてスナップショットの受信が完了した時点で、レプリケーションバッファには、“#48”、“#49”……といったレプリケーションログが溜まっている。
“#47”のスナップショットを元に、“#47”のレキシコンセットを構築した後、バッファリングした“#48”、“#49”……のレプリケーションを一気に処理することにより、最新のレキシコンセットにキャッチアップすることができる。
【0116】
[6−4.第3実施形態の効果]
本実施形態によれば、システム全体を停止させることなく、言い換えれば、レプリケーションが行われている状況下で、新たなサイトにデータベースをコピーすることができる。また、最新のオリジナルデータとの一致を図ることで、システムの動的な拡張が可能となる。
すなわち、スナップショット転送中もトランザクション処理を中断することなく、リトリーブするサイトは最小の時間で時々刻々と変化するレキシコンセットにキャッチアップして運用を開始することができる。
【0117】
[7.他の実施形態]
本発明は上述した実施形態に限定されるものではなく、以下に述べるように適宜変更して適用することができる。
すなわち、上記の実施形態においては、「複数のマシン」を物理的に異なるマシンと、通信ネットワークをそれらの間の物理的媒体を含む通信手段として想定したが、これを論理的に異なるマシン、例えば同一マシン内の異なるプロセスを対象として実施しても構わない。その場合には、各(論理)マシンの識別に、異なる手段(例えば、プロセスID等)を使用すればよい。
【0118】
また、上記の実施形態においては、トランザクションの実行をすべてトランザクション関数の呼出しとして説明したが、トランザクションの実行の形態はこれに限られるものではない。例えば、個々のトランザクションには具体的なデータ操作手続の記述が含まれており、本システムが一定の手順に従ってそれを解釈実行するという形態でも構わない。
【0119】
さらに、レプリケーションデータを伝達する手段としての通信ネットワークと、トランザクションを転送する手段としての通信ネットワークは、物理的/論理的に同一のものを用いても、異なるものを用いてもよい。多数のレプリカサイトに伝送するには、マルチキャスト/ブロードキャストのネットワークを使用するのが効率的な場合が多いが、本発明を適用する場合、それに限定されるものではない。一方、トランザクションの転送は通常1対1通信で足りるが、実行すべきでないサイトが受信した場合は、そのサイトの判断で実行しない、あるいは破棄する等の処理を行なうという条件で、マルチキャスト/ブロードキャストのネットワ−クを採用することも可能である。
【0120】
【発明の効果】
以上述べた様に、本発明によれば、ネットワークで結合された複数のマシン上で協調動作することにより、各マシンの主記憶上の共有データを一貫して維持・更新することができる分散データ管理システム及び分散データ管理方法を提供することができる。
【図面の簡単な説明】
【図1】本発明に係る分散データ管理システムの全体構成を示す図
【図2】ユニスペースの構成を示す模式図
【図3】本発明に係る分散データ管理システムが適用されるネットワーク構成の一例を示す図
【図4】本発明に係る分散データ管理システムの第1実施形態の構成を示すブロック図
【図5】トランザクション登録表の一例を示す図
【図6】レプリケーション待ちTR表の一例を示す図
【図7】ローカル参照処理の手順を示すフローチャート
【図8】ローカル更新処理の手順を示すフローチャート
【図9】リモート更新処理の一態様である、アプリケーションプログラムが存在するレプリカサイトでの処理の手順を示すフローチャート
【図10】リモート更新処理の一態様である、リモート更新トランザクションの依頼を受けたオリジナルサイトでの処理の手順を示すフローチャート
【図11】リモート更新処理の一態様である、アプリケーションプログラムが存在しないレプリカサイトでの処理の手順を示すフローチャート
【図12】トランザクションの実行処理の全体像を示すフローチャート
【図13】本発明に係る分散データ管理システムの第2実施形態の動作状況を示す模式図
【図14】本発明に係る分散データ管理システムの第3実施形態の構成を示すブロック図
【図15】レキシコンセット・ステータス表の一例を示す図
【図16】ネットワークリトリーブを実行するサイトA(レプリカサイト)における処理手順を示すフローチャート
【図17】ネットワークリトリーブを実行するサイトB(オリジナルサイト)における処理手順を示すフローチャート
【符号の説明】
1…データベース
2…TR関数
3…処理部
10…分散データ管理装置
101…トランザクション受付部
102…トランザクション実行制御部
105…トランザクション実行部
106…レプリケーション処理部
107…データ受信部
108…データ送信部
109…データ格納部
110…トランザクション登録表
111…レプリケーション待ちTR表
112…アプリケーション
20…分散データ管理装置
120…スナップショット出力部
121…レキシコンセット・ステータス表+バッファ
Claims (18)
- ネットワークを介して接続された複数のコンピュータの主記憶領域上にそれぞれデータベースを配置し、前記データベースに格納されたデータのそれぞれについて、そのオリジナルデータを、前記複数のコンピュータの内のある特定のコンピュータに格納し、このオリジナルデータを保有するコンピュータをオリジナルサイトとすると共に、前記オリジナルサイトとは異なる他のコンピュータには、前記オリジナルデータと同一のレプリカデータを格納し、このレプリカデータを保有するコンピュータをレプリカサイトとし、前記各コンピュータにおいては、前記データベースにアクセスする処理をトランザクションとして実行する分散データ管理システムにおいて、
前記オリジナルサイトとレプリカサイトを構成する各コンピュータにはそれぞれ、
前記トランザクションの実行依頼を受け付けるトランザクション受付部と、
トランザクションの実行を制御するトランザクション実行制御部と、
トランザクションを実行するトランザクション実行部と、
オリジナルサイトから送られた更新データを自サイトのレプリカデータに反映させるレプリケーション処理部と、
オリジナルデータあるいはレプリカデータを格納するデータ格納部と、トランザクション名、そのトランザクションの処理対象となるデータ名、そのデータのオリジナルサイト名、そのトランザクションの属性、そのトランザクションに対応するトランザクション関数名を対応づけて示したトランザクション登録表と、
データ受信部及びデータ送信部を備え、
前記データベースに格納された各データの更新処理は、前記オリジナルサイトのトランザクション実行部でのみ実行し、前記レプリカサイトにおいては、前記オリジナルサイトで実行された更新結果を前記データ受信部で受信し、前記レプリケーション処理部によって自己のレプリカデータに反映し、
前記各サイトにおけるアプリケーションの実行時には、そのサイトに設けられたトランザクション受付部において受け付けられたアプリケーションの依頼に基づき、トランザクション実行制御部がトランザクション登録表を検索して、自サイトがオリジナルサイトであるか否かを判定すると共に、トランザクション登録表を検索して実行に必要なトランザクション関数を決定し、このトランザクション実行制御部の指示に従い、トランザクション実行部においてトランザクション関数の呼び出しを行うことを特徴とする分散データ管理システム。 - 時々刻々と変化するデータのスナップショットを出力するスナップショット出力部と、
前記スナップショットをネットワーク経由で取得する間に発生したデータの更新情報を保存するバッファ部とをさらに備え、
前記データ送信部より、他のサイトへスナップショットの送信要求を出し、他のサイトからスナップショットを取得する間に発生したデータの更新情報を前記バッファ部に保存し、前記スナップショットの取得と同時に、バッファ部に保存した更新情報を自己のデータに反映することを特徴とする請求項1に記載の分散データ管理システム。 - 前記トランザクション受付部は、トランザクションの実行依頼を受け付ける毎に、受け付けたトランザクションをすべてのサイトを通じて一意に識別することができる「受付ID」を発行することを特徴とする請求項1又は請求項2に記載の分散データ管理システム。
- 前記トランザクション実行部は、データの更新処理がなされるたびに「更新シリアル番号」を発行することを特徴とする請求項1乃至請求項3のいずれか一に記載の分散データ管理システム。
- 前記オリジナルサイトが、ネットワーク上のいずれのサイトであるかを識別するための手段が設けられていることを特徴とする請求項1乃至請求項4のいずれか一に記載の分散データ管理システム。
- 自サイトがオリジナルサイトに対してデータ更新処理の実行を依頼したサイトであるか否かを識別するための手段が設けられていることを特徴とする請求項1乃至請求項5のいずれか一に記載の分散データ管理システム。
- ネットワークを介して接続された複数のコンピュータの主記憶領域上にそれぞれデータベースを配置し、前記データベースに格納されたデータのそれぞれについて、そのオリジナルデータを、前記複数のコンピュータの内のある特定のコンピュータに格納し、このオリジナルデータを保有するコンピュータをオリジナルサイトとすると共に、前記オリジナルサイトとは異なる他のコンピュータには、前記オリジナルデータと同一のレプリカデータを格納し、このレプリカデータを保有するコンピュータをレプリカサイトとし、前記各コンピュータにおいては、前記データベースにアクセスする処理をトランザクションとして実行する分散データ管理方法において、
前記オリジナルサイトとレプリカサイトを構成する各コンピュータにはそれぞれ、前記トランザクションの実行依頼を受け付けるトランザクション受付部と、トランザクションの実行を制御するトランザクション実行制御部と、トランザクションを実行するトランザクション実行部と、オリジナルサイトから送られた更新データを自サイトのレプリカデータに反映させるレプリケーション処理部と、オリジナルデータあるいはレプリカデータを格納するデータ格納部と、トランザクション名、そのトランザクションの処理対象となるデータ名、そのデータのオリジナルサイト名、そのトランザクションの属性、そのトランザクションに対応するトランザクション関数名を対応づけて示したトランザクション登録表とを設け、
前記データベースに格納された各データの更新処理は、前記オリジナルサイトのトランザクション実行部でのみ実行し、前記レプリカサイトにおいては、前記オリジナルサイトで実行された更新結果を前記データ受信部で受信し、前記レプリケーション処理部によって自己のレプリカデータに反映することにより、データの同一性を保持し、
前記各サイトにおけるアプリケーションの実行時には、そのサイトに設けられたトランザクション受付部において受け付けられたアプリケーションの依頼に基づき、トランザクション実行制御部がトランザクション登録表を検索して、自サイトがオリジナルサイトであるか否かを判定すると共に、トランザクション登録表を検索して実行に必要なトランザクション関数を決定し、このトランザクション実行制御部の指示に従い、トランザクション実行部においてトランザクション関数の呼び出しを行うことを特徴とする分散データ管理方法。 - 自サイトのデータベースに最新のオリジナルデータを取得する場合に、ネットワーク上の他のサイトへスナップショットの送信要求を出し、他のサイトからスナップショットを受信すると共に、その受信中に発生したデータの更新情報を保存し、前記スナップショットの取得と同時に、保存した更新情報を自己のデータに反映することにより、時々刻々と変化するデータにキャッチアップすることを特徴とする請求項7に記載の分散データ管理方法。
- 前記トランザクションがデータを参照するものである場合には、自サイトがオリジナルサイトであるか、レプリカサイトであるかにかかわらず、自己の保有するデータに対して参照処理を行うことを特徴とする請求項7又は請求項8に記載の分散データ管理方法。
- 前記トランザクションが処理対象とするデータのオリジナルが、そのトランザクションの実行依頼を受けたコンピュータに保有され、そのトランザクションによりオリジナルデータが更新された場合に、その更新結果を他のすべてのレプリカサイトに送信することを特徴とする請求項7又は請求項8に記載の分散データ管理方法。
- 前記トランザクションが処理対象とするデータのオリジナルサイトが、そのトランザクションの実行依頼を受けたコンピュータ以外のサイトであり、そのトランザクションによる処理がデータの更新である場合に、そのトランザクションの実行依頼を受けたコンピュータ(レプリカサイト)は、データの更新処理をオリジナルサイトに依頼し、オリジナルサイトで更新処理を実行した後、オリジナルサイトから更新結果を受信し、その更新結果を自己が保有するレプリカデータに反映すると同時に、そのトランザクションの実行依頼元に実行完了を通知することを特徴とする請求項7又は請求項8に記載の分散データ管理方法。
- 前記トランザクションが処理対象とするデータのオリジナルサイトが、そのトランザクションの実行依頼を受けたコンピュータ以外のサイトであり、そのトランザクションによる処理がデータの更新である場合に、データの更新依頼を受けたオリジナルサイトにおいては、更新処理を実行した後、その更新結果を他のすべてのレプリカサイトに送信することを特徴とする請求項7又は請求項8に記載の分散データ管理方法。
- 前記トランザクションが処理対象とするデータのオリジナルサイトが、そのトランザクションの実行依頼を受けたコンピュータ以外のサイトであり、そのトランザクションによる処理がデータの更新である場合に、自サイトがそのトランザクションの実行依頼を受けたコンピュータでも、オリジナルサイトでもない時は、オリジナルサイトから更新結果を受信し、その更新結果を自己が保有するレプリカデータに反映することを特徴とする請求項7又は請求項8に記載の分散データ管理方法。
- ネットワークを介して接続された複数のコンピュータの主記憶領域上にそれぞれデータベースを配置し、前記データベースに格納されたデータのそれぞれについて、そのオリジナルデータを、前記複数のコンピュータの内のある特定のコンピュータに格納し、このオリジナルデータを保有するコンピュータをオリジナルサイトとすると共に、前記オリジナルサイトとは異なる他のコンピュータには、前記オリジナルデータと同一のレプリカデータを格納し、このレプリカデータを保有するコンピュータをレプリカサイトとし、前記オリジナルサイトで実行された更新結果を、ネットワーク上のすべてのレプリカデータに反映することにより、データの同一性を保持することを可能とした分散データ管理プログラムであって、
前記オリジナルサイトとレプリカサイトを構成する各コンピュータにはそれぞれ、前記トランザクションの実行依頼を受け付けるトランザクション受付部と、トランザクションの実行を制御するトランザクション実行制御部と、トランザクションを実行するトランザクション実行部と、オリジナルサイトから送られた更新データを自サイトのレプリカデータに反映させるレプリケーション処理部と、オリジナルデータあるいはレプリカデータを格納するデータ格納部と、トランザクション名、そのトランザクションの処理対象となるデータ名、そのデータのオリジナルサイト名、そのトランザクションの属性、そのトランザクションに対応するトランザクション関数名を対応づけて示したトランザクション登録表とを設け、
前記データベースに格納された各データの更新処理は、前記オリジナルサイトのトランザクション実行部でのみ実行し、前記レプリカサイトにおいては、前記オリジナルサイトで実行された更新結果を前記データ受信部で受信し、前記レプリケーション処理部によって自己のレプリカデータに反映することにより、データの同一性を保持するステップと、 前記各サイトにおけるアプリケーションの実行時には、そのサイトに設けられたトランザクション受付部において受け付けられたアプリケーションの依頼に基づき、トランザクション実行制御部がトランザクション登録表を検索して、自サイトがオリジナルサイトであるか否かを判定すると共に、トランザクション登録表を検索して実行に必要なトランザクション関数を決定し、このトランザクション実行制御部の指示に従い、トランザクション実行部においてトランザクション関数の呼び出しを行うステップと、
あるデータのオリジナルサイトがネットワーク上のいずれのサイトであるかと、そのデータに対する処理が「参照」か「更新」のいずれであるかを検索するステップと、前記検索の結果、その処理が「更新」であり、且つ、自サイトがそのデータのオリジナルサイトである場合には、そのトランザクションを実行するステップと、その更新結果を他のレプリカサイトに送信するステップを有することを特徴とする分散データ管理プログラム。 - ネットワークを介して接続された複数のコンピュータの主記憶領域上にそれぞれデータベースを配置し、前記データベースに格納されたデータのそれぞれについて、そのオリジナルデータを、前記複数のコンピュータの内のある特定のコンピュータに格納し、このオリジナルデータを保有するコンピュータをオリジナルサイトとすると共に、前記オリジナルサイトとは異なる他のコンピュータには、前記オリジナルデータと同一のレプリカデータを格納し、このレプリカデータを保有するコンピュータをレプリカサイトとし、前記オリジナルサイトで実行された更新結果を、ネットワーク上のすべてのレプリカデータに反映することにより、データの同一性を保持することを可能とした分散データ管理プログラムであって、
前記オリジナルサイトとレプリカサイトを構成する各コンピュータにはそれぞれ、前記トランザクションの実行依頼を受け付けるトランザクション受付部と、トランザクションの実行を制御するトランザクション実行制御部と、トランザクションを実行するトランザクション実行部と、オリジナルサイトから送られた更新データを自サイトのレプリカデータに反映させるレプリケーション処理部と、オリジナルデータあるいはレプリカデータを格納するデータ格納部と、トランザクション名、そのトランザクションの処理対象となるデータ名、そのデータのオリジナルサイト名、そのトランザクションの属性、そのトランザクションに対応するトランザクション関数名を対応づけて示したトランザクション登録表とを設け、
前記データベースに格納された各データの更新処理は、前記オリジナルサイトのトランザクション実行部でのみ実行し、前記レプリカサイトにおいては、前記オリジナルサイトで実行された更新結果を前記データ受信部で受信し、前記レプリケーション処理部によって自己のレプリカデータに反映することにより、データの同一性を保持するステップと、 前記各サイトにおけるアプリケーションの実行時には、そのサイトに設けられたトランザクション受付部において受け付けられたアプリケーションの依頼に基づき、トランザクション実行制御部がトランザクション登録表を検索して、自サイトがオリジナルサイトであるか否かを判定すると共に、トランザクション登録表を検索して実行に必要なトランザクション関数を決定し、このトランザクション実行制御部の指示に従い、トランザクション実行部においてトランザクション関数の呼び出しを行うステップと、
あるデータのオリジナルサイトがネットワーク上のいずれのサイトであるかと、そのデータに対する処理が「参照」か「更新」のいずれであるかを検索するステップと、前記検索の結果、その処理が「更新」であり、且つ、自サイトがそのデータのレプリカサイトである場合には、その処理の実行をオリジナルサイトに転送するステップと、オリジナルサイトにおける更新結果を受信して、自己のレプリカデータに反映するステップを有することを特徴とする分散データ管理プログラム。 - 自サイトのデータベースに最新のデータを取得する場合に、ネットワーク上の他のサイトへスナップショットの送信要求を出すステップと、
他のサイトからスナップショットを受信するステップと、
その受信中に発生したデータの更新情報を保存するステップと、
前記スナップショットの取得と同時に、保存した更新情報を自己のデータに反映するステップをさらに有することを特徴とする請求項14又は請求項15に記載の分散データ管理プログラム。 - 前記データベースに格納されるデータを、ネットワーク上の複数のコンピュータで同一性を保持すべきデータと、各コンピュータに固有のデータとに区別し、
前記同一性を保持すべきデータについては、その更新処理は、前記オリジナルサイトのトランザクション実行部でのみ実行し、前記レプリカサイトにおいては、前記オリジナルサイトで実行された更新結果を前記データ受信部で受信し、前記レプリケーション処理部によって自己のレプリカデータに反映し、
一方、各コンピュータに固有なデータについては、各コンピュータ毎にデータの更新を実行し、他のコンピュータにその更新結果を反映させないことを特徴とする請求項1に記載の分散データ管理システム。 - 前記データベースに格納されるデータを、ネットワーク上の複数のコンピュータで同一性を保持すべきデータと、各コンピュータに固有のデータとに区別し、
前記同一性を保持すべきデータについては、その更新処理は、前記オリジナルサイトでのみ実行可能とし、
前記レプリカサイトにおいては、前記オリジナルサイトで実行された更新結果を自己が保有するレプリカデータに反映することにより、データの同一性を保持し、
一方、各コンピュータに固有なデータについては、各コンピュータ毎にデータの更新を実行し、他のコンピュータにその更新結果を反映させないことを特徴とする請求項7に記載の分散データ管理方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001097581A JP4129353B2 (ja) | 2001-03-29 | 2001-03-29 | 分散データ管理システム、分散データ管理方法及び分散データ管理プログラム |
US10/105,419 US6976040B2 (en) | 2001-03-29 | 2002-03-26 | System and method of data-management and data-management program |
EP02252291A EP1265141A3 (en) | 2001-03-29 | 2002-03-28 | System, method and computer program for data-management |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001097581A JP4129353B2 (ja) | 2001-03-29 | 2001-03-29 | 分散データ管理システム、分散データ管理方法及び分散データ管理プログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2002297428A JP2002297428A (ja) | 2002-10-11 |
JP4129353B2 true JP4129353B2 (ja) | 2008-08-06 |
Family
ID=18951342
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001097581A Expired - Fee Related JP4129353B2 (ja) | 2001-03-29 | 2001-03-29 | 分散データ管理システム、分散データ管理方法及び分散データ管理プログラム |
Country Status (3)
Country | Link |
---|---|
US (1) | US6976040B2 (ja) |
EP (1) | EP1265141A3 (ja) |
JP (1) | JP4129353B2 (ja) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2005103901A1 (ja) * | 2004-04-19 | 2005-11-03 | Annex Systems Incorporated | コンピューター・システム |
US8862979B2 (en) * | 2008-01-15 | 2014-10-14 | Microsoft Corporation | Multi-client collaboration to access and update structured data elements |
JP5964950B2 (ja) | 2012-04-12 | 2016-08-03 | 株式会社日立製作所 | 計算機システム、データ配置管理方法及びプログラム |
CN103853719B (zh) * | 2012-11-28 | 2018-05-22 | 勤智数码科技股份有限公司 | 易扩展海量数据采集系统 |
CN103853713B (zh) * | 2012-11-28 | 2018-04-24 | 勤智数码科技股份有限公司 | 海量数据高效入库方法 |
US11809451B2 (en) * | 2014-02-19 | 2023-11-07 | Snowflake Inc. | Caching systems and methods |
WO2016157358A1 (ja) * | 2015-03-30 | 2016-10-06 | 株式会社野村総合研究所 | データ処理システム |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6012059A (en) * | 1997-08-21 | 2000-01-04 | Dataxel Corporation | Method and apparatus for replicated transaction consistency |
AU4547099A (en) * | 1998-06-05 | 1999-12-20 | Mylex Corporation | Snapshot backup strategy |
US6460054B1 (en) * | 1999-12-16 | 2002-10-01 | Adaptec, Inc. | System and method for data storage archive bit update after snapshot backup |
-
2001
- 2001-03-29 JP JP2001097581A patent/JP4129353B2/ja not_active Expired - Fee Related
-
2002
- 2002-03-26 US US10/105,419 patent/US6976040B2/en not_active Expired - Fee Related
- 2002-03-28 EP EP02252291A patent/EP1265141A3/en not_active Withdrawn
Also Published As
Publication number | Publication date |
---|---|
EP1265141A2 (en) | 2002-12-11 |
EP1265141A3 (en) | 2004-09-08 |
US20020143740A1 (en) | 2002-10-03 |
US6976040B2 (en) | 2005-12-13 |
JP2002297428A (ja) | 2002-10-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9317372B1 (en) | Dynamic membership management in a distributed system | |
US6898609B2 (en) | Database scattering system | |
US7293194B2 (en) | Method and device for switching database access part from for-standby to currently in use | |
CN107787490A (zh) | 分布式数据库网格中的直接连接功能 | |
US11442897B2 (en) | Optimizing content storage through stubbing | |
JP2002202953A (ja) | プロセス障害またはシステム障害後の回復 | |
CN102640108A (zh) | 已复制数据的监控 | |
JP3592016B2 (ja) | リモートプロシジャコール処理方法 | |
JP2005025432A (ja) | トランザクション処理方法,トランザクション制御装置およびトランザクション制御プログラム | |
JP4129353B2 (ja) | 分散データ管理システム、分散データ管理方法及び分散データ管理プログラム | |
JP4131780B2 (ja) | 分散トランザクション処理システム、分散トランザクション処理方法及び分散トランザクション処理プログラム | |
US20080133609A1 (en) | Object-based storage system for defferring elimination of shared file and method thereof | |
JP4131781B2 (ja) | 分散処理型データベース管理システム | |
JP2000222268A (ja) | 複数のコンピュータ間におけるファイルの同期方法 | |
WO2020153053A1 (ja) | データベース管理サービス提供システム | |
JP4434838B2 (ja) | 分散データ等価方法とシステム、およびプログラム | |
JPH0962602A (ja) | サーバ情報管理方法および管理システム | |
JPH1074178A (ja) | 情報提供システム | |
JP2001273269A (ja) | 複数プロセッサの構成情報更新方式 | |
JP2776747B2 (ja) | ファイル転送装置 | |
JP2002297593A (ja) | ベースホスト切替型データベース管理システム | |
JP2000215179A (ja) | オブジェクト名前管理方式 | |
JP3374320B2 (ja) | ステートレスプロトコルによるデータベースアクセス方法及びシステム | |
JP2613228B2 (ja) | 論理セツシヨンの動的切替え制御方式 | |
JP2002351830A (ja) | サービスシステムとサービス方法およびその処理プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20030930 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070904 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071105 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080513 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080519 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130523 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130523 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140523 Year of fee payment: 6 |
|
LAPS | Cancellation because of no payment of annual fees |