メタデータの末尾にスキップ
メタデータの先頭に移動

 

はじめに

ClustrixDBは read-write の混合の仕事をサポートするために、複数バージョンの並行制御 (MVCC) と 2フェーズのロック(2PL) の組み合わせを使用します。私たちのシステムでは、writerが衝突を管理するために2PLを使っている間、readerはロック無しのスナップショット隔離を楽しみます。並行処理制御の組み合わせはreaderがwriterを邪魔しないことを意味し(あるいは逆も同じ)、writerはupdateの命令には明示的なロックを利用します。

複数バージョンの並行処理制御

ClustrixDB iは読み込みが確実のロックしないように分散MVCCスキーマを実装しており、readerとwriterは決してお互いに邪魔をしません。システム内でwriterが行を修正すると、ClustrixDBはそれぞれの行のバージョン履歴を保持します。トランザクション内のそれぞれのステートメントは行の関連バージョンを扱うためにデータへのロック無しアクセスを使用します。 

可視性規則

ClustrixDBの可視性規則は、それぞれのトランザクションとステートメントに関連したids(identifiers)のセットによって管理されます。トランザクションによって修正された行は、その修正のトランザクションが実行された後でのみ他のトランザクションに見えるようになります。一旦トランザクションが実行されると、その修正が見えるようになるcommit id (cid)を生成します。

以下の図はトランザクションの一生を表しています。 

トランザクションの一生
xidトランザクションの開始id。トランザクションの論理的な開始をマークします。
iid呼び出しid。トランザクション内のステートメントの開始をマークします。
cid

コミットid。他のトランザクションにトランザクションの変更が見えるようになるidをマークします。

以下の表は異なる隔離レベルでのMVCC 可視性規則を表しています。ClustrixDBは read uncommitted レベルをサポートしていない事に注意してください。 

隔離レベル

それぞれの隔離レベルには異なる可視性規則のセットがあります。以下の表はトランザクション間の行の可視性の基本的な規則を説明しています。  

隔離レベルスナップショットのアンカーコメント
Read committedステートメント

ANSIで定義されているread committedよりも厳密。ステートメントごとの一貫性スナップショットreadが可能。

トランザクション内の後続の各ステートメントは新しいiidを取得し、ステートメントが実行される前(実行中では決して無い)に全ての新しいステートメントはcommitされた行を見ることができます。

Oracleの一貫性read隔離に最も似ています。

ステートメント(invocation) id > 変更中のトランザクションのcommit id の場合に、行が見えます。

Repeatable read

(デフォルト)

トランザクション

ANSIで定義されている repeatable read よりも厳密。トランザクションごとの一貫性スナップショットreadが可能。

トランザクション内の各後続ステートメントはトランザクションの開始時のデータベースを見ます。

トランザクションは、トランザクション内で行われたデータベースへの変更も見るかも知れません。

トランザクションid > 修正中のトランザクションのcommit id の場合に、行が見えます。

直列化可能トランザクション

厳密なANSI隔離レベルクラスタ内でデータの移動を行うためにシステムによって使用されます。

トランザクション id > 修正中のトランザクションのcommit id の場合に、行が見えます。

MVCCスケジューラがトランザクションの直列化可能を保証できない場合に、データベースはエラーを返します。

注意: 直列化可能隔離は現在のところエンドユーザのトランザクションには仕えません。

以下の例では、異なる隔離レベルでトランザクションの可視性がどのように動作するかを示しています。. 

ID ジェネレータ

ClustrixDBは行の可視性を制御するために、ステートメントの呼び出しID (iid) と一緒にグローバルにユニークな順番のトランザクション id (xid) を使用します。xidとiidのジェネレータの両方とも、グローバルにユニークな順番の識別子を生成するために、システム全体の時計とノードidの組み合わせを使用します。 

バージョン履歴とガベージコレクション 

ClustrixDB はundoログを通じて、バージョン履歴を管理します。undoログが既にトランザクションのロールバックのために行の以前のバージョンについての情報を維持しなければならないので、MVCCのために行の以前のバージョンにアクセスするためにこの情報の利用を頼ることができます。この技術により、ClustrixDBは大規模なヒープスペースを管理する代わりにプライマリキーを使ってクラスタ化されたテーブルを管理することができます。insertとupdateについては、undoログを削除する時にガベージコレクションが発生します。しかしながら、ClustrixDBは現在実行しているトランザクションを提供するために純分なundoログ履歴を保持します。. In addition to limiting undo log trim to local checkpoint rules, we also limit trimming based on the id of the oldest transaction within the system. 

上の図はシステムがどうやってundoログ内の複数のバージョンの行を保持するかを示しています。各行は行の以前のバージョンを示すログシーケンス番号(LSN)を含んでいます。以前のLSNポインタがtrim LSNに先行すると、履歴チェインの最後に来たことを知ります。 

書き込みのための2フェーズロック

楽観的な一貫性の制御は、衝突の前ではうまく動作しません(二つのトランザクションが同じ行を同時にupdateしようとする)そのような場合、純粋なMVCCシステムは衝突しているトランザクションの一方あるいは両方をロールバックし、操作を再開するでしょう。ClustrixDBは所定のトランザクションの使用を要求しないため(例えば、ストアドプロセジャー内の全てのロジック)、そのようなエラーはアプリケーションに渡されます。更に、定常的な衝突にってトランザクションが進展しない場合にlive-lockシナリオを作成することができます。

これらの問題を克服するために、ClustrixDBはwriter-writer 衝突解決のためのロックを使用します。writerは常に最新のcommitされた情報を読み込み、なんらかの変更がされる前にロックを獲得します。.

分散ロックマネージャ

ClustrixDBはwriteアクセスをホットテーブルにスケールするために分散ロックマネージャを実装しています。クラスタ内では、各ノードはロックドメインの一部を管理します。単一のノードがクラスタの全てのロック情報を保持することはしません。

行レベルとテーブルレベルのロック

ClustrixDBは一度に少数の行を触るトランザクションのための行レベルのロックを実装しています(実行時設定可能な変数)。テーブルの重要な部分に影響するステートメントについては、query optimizer が行レベルロックをテーブルロックに昇格させるでしょう。 

TOP
inserted by FC2 system