 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 | ||||||||||||
|
||||||||||||
| グループコミュニケーション | ||||||||||||
|
マルチマスターでは、3台以上のサーバに同時に通信をする必要があります。実際には2台でもいいのですが、技術的には2台と3台ではかなり難しさが異なってきます。 現在のネットワークプロトコルは、1：1の通信、あるいはn：1の通信が前提です。図7に示すように、サーバクライアント型の通信はできますが、複数のサーバに一斉にデータを送ったりするには、これをたくさん組み合わせなければならなくなります。  図7：現在の通信は1：1かn：1のサーバクライアント型 グループコミュニケーションでは、データを送る際に、あて先を複数のコンピュータに設定することができます。この複数のコンピュータ群には、いろいろなところからデータが送られてきます。重要なことは、すべてのコンピュータで受信するデータは、同じ順序になることが保証されているということです。図8にこの様子を示します。  図8：グループコミュニケーションを使った複数コンピュータ間の通信
参考文献1：
Group Communication Specifications：A Comprehensive Study、GV.Chockler、ACM Computing Surveys、2001、pp.427
|
||||||||||||
|
||||||||||||
| 提案中の方式 | ||||||||||||
|
分散ロックでは、データベースのタプル1つを変更しようとするたびに全部のサーバで同じロックを確保しようとします。この方式では効率を上げるのが難しいので、Slony-IIでは先にあげたライトセットをいくつかまとめて処理しようとしています。具体的には、図9のようになります（少し単純にしてあります）。  図9：Slony-IIの基本処理方式 （画像をクリックすると別ウィンドウに拡大図を表示します）
|
||||||||||||
|
||||||||||||
| かなり複雑で微妙な方式ですが、こうすることでサーバ間のやり取りの回数を少なくして、性能を落ちないようにしながら、すべてのサーバのデータベースが同じに保たれるようにしてあるのです。 この方式で注意していただきたいことは、他のトランザクションの都合で、自分のトランザクションが取り消されてしまう危険があるということです。また、トランザクションの終わりにならないと、他のトランザクションとの矛盾があったかどうかもわからないことがあるということです。 このようなトランザクション制御の方法は、楽観的な方法（optimisitic transaction management）と呼ばれているものの一種で、90年代にオブジェクト指向データベースなどでも用いられた方法です（文献2）。 アプリケーションの設計では、新たな工夫が必要になるかもしれません。この方式は、トランザクション間の衝突が少ない場合は大変効率な方法なのですが、衝突が多く発生しだすと効率の低下も激しいといわれています。
参考文献2：
トランザクション処理−概念と技法（上）（下）、ジム・グレイ、アンドレアス・ロイター、喜連川他（翻訳）、2001、日経BP社、ISBN：4822281027
|
||||||||||||
|
||||||||||||
| Slony-IIの状況とむすび | ||||||||||||
|
現在Slony-IIは、アーキテクチャの検討と平行してプロトタイプの試作も行われております。意欲的なプロジェクトですが、年度内にはきちんと公開できるものが完成するものと期待しています。この実装では、グループコミュニケーション（GCS）の機能に多くを依存しています。GCSがどの程度の品質と性能をもたらしてくれるのか、この検証ができることにも期待したいと思います。 データベースレプリケーションは、データベースのスケールアウトを行い、かつ、データベースの可用性や信頼性を高める重要な方法です。Slony-II以外にもいくつもの試みがなされており、今後の発展が期待される領域です。 |
||||||||||||
|
前のページ 1 2 3 4 |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
