Tencent and Renmin University of Chinaオープンソース最新の研究結果:3TS Tencentトランザクション処理技術検証システム

著者:Li Haixiang TencentTEGデータベーステクノロジーの専門家

1つは世界をリードするテクノロジー企業であり、もう1つは中国のデータベースに関する基礎的な学術研究の発祥地です。最近、中国人民大学-Tencent Collaborative InnovationLabが正式に除幕式を行いました。両当事者は、データベースのセキュリティと制御を進めながら、将来の大規模なマルチシナリオデジタル時代に向けて最先端のイノベーション研究を実施しながら、長年にわたる最先端の産学連携研修計画のデータベース基礎研究の分野に注力してきたと理解されています。 「フルタイムデータベースシステム」やその他の成果を含む研究所の成果は、VLDBやその他の国際的なトップ会議に含まれ、同時に多くの国内技術特許を申請しました。

研究所の発表と同時に、テンセントと中国人民大学の研究チームは、新しい共同研究結果である3TSテンセントトランザクション処理技術検証システムをオープンソース化しました。

Tencent Transaction Processing Testbed System(3TS)は、Tencentの自社開発の財務グレードの分散データベースTDSQLチームと、中国人民大学教育省のデータエンジニアリングおよび知識エンジニアリングの主要研究所が共同で開発したデータベーストランザクション処理の検証システムです。このシステムは、トランザクション処理(分散トランザクションを含む)の統合フレームワークを設計および構築することを目的としており、フレームワークによって提供されるアクセスインターフェイスを通じて、ユーザーが新しい同時実行制御アルゴリズムをすばやく構築するのに便利です。検証システムによって提供されるテストベッドは、アプリケーションシナリオのニーズに応じて、同じテスト環境で現在の主流の同時実行制御アルゴリズムの公正なパフォーマンス比較を実行し、最適な同時実行制御アルゴリズムを選択します。現在、検証システムには13の主流の同時実行制御アルゴリズムが統合されており、TPC-C、Sysbench、YCSBなどの一般的なベンチマークテストが提供されています。3TSはさらに、この段階での分散データベースシステムの爆発的な開発によって引き起こされるシステム選択の難しさを目的として、一貫性レベルのテストベンチマークを提供し、一貫性レベルの識別とパフォーマンステストの比較を提供します。

3TSシステムは、データベーストランザクション処理の関連する理論と実装テクノロジを深く探求することを目的としています。そのコアコンセプトは、オープン性、深さ、および進化です。オープン性、オープンソースの中心に固執し、知識を共有し、テクノロジーを共有します。深さ、体系的な研究の精神を実践し、トランザクション処理テクノロジーの本質的な問題を研究し、ルーランを壊さず、二度と戻らない。進化は長い道のりです。上下に検索し、前進し続け、前進し続けます。

1.3TS全体のアーキテクチャ

 

トランザクション処理テクノロジーに関連するフレームワークとして、3TSが調査に取り組んでいる重要な問題は主に次のとおりです。

 

  • 世界にはいくつのデータ異常がありますか?異常データの体系的な調査方法を確立するにはどうすればよいですか?

  • なぜ多くの種類の同時アクセス制御アルゴリズムがあるのですか?さまざまな同時アクセス制御アルゴリズム間に本質的な関係はありますか?

  • スタンドアロンのトランザクションデータベースが配布された後、どのような側面(可用性、信頼性、セキュリティ、一貫性、スケーラビリティ、機能、パフォーマンス、アーキテクチャなど)が影響を受けますか?

  • どのような新しいテクノロジーが影響し、それらは分散トランザクションデータベースシステムにどのように影響しますか?

  • 分散トランザクションデータベースシステムの評価および評価システムはどのように確立されるべきですか?

コードレベルでは、上記の各調査質問に対応するサブシステムがあります。たとえば、最初のオープンソースには3TS-DAサブシステムと3TS-Denevaサブシステムが含まれます。

 

2. 3TS-DA、データ異常サブシステム

 

3TS-DAデータ異常サブシステムはsrc / 3ts / daパスの下にあり、そのプロジェクト構造を次の図に示します。

  • 履歴作成者:履歴を生成し、検証のためにアルゴリズムに出力する責任があります。

  • CCAグループ:CCAは、同時アクセス制御アルゴリズムの略で、着信履歴に対して異常検出を実行し、異常検出結果を返すことができます。

  • 出力側:現在の履歴に関する各CCAの検出結果をファイルに出力する役割を果たします。

 

3TS-DAサブシステムの現在の機能:

 

  • テストデータの生成:トラバーサル生成、ランダム生成、テキストからの読み取りの3種類の履歴生成方法をサポートします。

  • アルゴリズムの追加:新しい同時アルゴリズムをより便利に追加できる統合アルゴリズムインターフェイスを提供します。同時に、フレームワーク自体には、シリアル化可能、競合シリアル化可能、SSI、WSI、BOCC、FOCCなどのさまざまなアルゴリズムがあります。

  • テスト指標:フレームワークは、アルゴリズムのロールバック率、真のロールバック率、偽のロールバック率、実行時間など、さまざまなテスト指標を提供します。

  • 異常拡張:フレームワークは、データ異常拡張アルゴリズムを実装します。これを拡張して、アルゴリズムテスト用に無制限の数のデータ異常履歴を生成できます。

3. 3TS-Deneva、同時アルゴリズムフレームワーク

 

Devena [1]は、MITがオープンソース化した分散メモリデータベース同時アクセス制御アルゴリズムの評価フレームワークです。元のコードはhttps://github.com/mitdbg/denevaにあります。制御された環境での同時実行制御プロトコルのパフォーマンス特性を調査できます。このフレームワークはMaat、OCC、TO、Locking(No Wait、Wait Die)、Calvinなどの主流のアルゴリズムを提供します3TS-Denevaは、複数のレベルを含む、Denevaに基づくTencentの元のシステムの改良版です。その中で、アルゴリズムレベルでは、シリアル化可能、競合シリアル化可能、SSI、WSI、BOCC、FOCC、サンダイアル、サイロなど、より多くの同時アクセス制御アルゴリズムが追加されています

3.1インフラストラクチャ


Devenaは、カスタムエンジンとその他の設定を使用しており、このプラットフォームにさまざまな同時実行制御プロトコルを展開および実装して、可能な限り公正な評価を行うことができます。図1に示すように、システムのアーキテクチャには主に2つのモジュールが含まれています。

  • トランザクションのイニシエーターとしてのクライアントインスタンス。クライアントの各スレッドは、トランザクションリクエストを開始し、開始されたトランザクションリクエストをメッセージキューに配置し、特定の実行のためにサーバーに送信する責任があります。クライアントインスタンスとサーバーインスタンスは完全に接続されたトポロジにあり、通常は異なるマシンにデプロイされます。

  • トランザクション内のさまざまな操作を具体的に実行するサーバー側インスタンス。さまざまなサーバーインスタンスにデータがあり、一貫したハッシュによってデータにインデックスが付けられるため、サーバーIPと保存されたデータの間にグローバルパーティションマッピングテーブルが形成されます。テスト中に変更されないパーティションマッピングを制御することにより、マッピングテーブルは次のようになります。すべてのノードを正確に取得できます。クライアントとサーバーインスタンス、サーバーとサーバーインスタンス間の通信は、TCP / IPプロトコルを使用します。各サーバーインスタンスは、次の4つのモジュールに分割できます。

    • メッセージキューに入り、クライアント/他のサーバーから送信されたメッセージを一時的に保存します。

    • 実行エンジンは、1つのコアを1つのスレッドにバインドするリソーススケジューリング方法を使用して、メッセージキュー内のメッセージを解析して実際に実行するために複数のワーカースレッドを割り当てます。

    • 同時実行制御モジュールは、トランザクション操作を実行するプロセスで、ワーカースレッドが特定の同時実行制御プロトコルに必要な情報を維持し、プロトコルで指定されたプロセスを実行して、指定された同時実行制御プロトコルが有効になるようにする必要があります。

    • データストレージモジュールは、このインスタンスのデータを管理し、データをメモリに保存する役割を果たします。

 

図1Denevaシステムアーキテクチャ図

 

3TSでは、Denevaが改善されました。改善されたコードはcontrib / denevaパスの下にあり、その内部プロジェクト構造を図2に示します。

図2Deneva実装フレームワーク図

  • Denevaは、サーバーとクライアントの2種類のノードに分けられます。

  • クライアントは、実行されるロードクエリを生成してサーバーに送信するために使用されます。サーバーは、クライアントから送信されたロードクエリの実行を調整するために使用されます。

  • クライアントとサーバーの共有モジュール:

    • MsgQueue:メッセージキューには、送信するメッセージが格納されます。

    • MsgThread:メッセージ送信スレッド。MsgQueueからメッセージを周期的に取り出して送信します。

    • InputThread:メッセージ受信スレッド、サーバー/クライアントから情報を受信します。

  • クライアントの独自モジュール:

    • ClientQueryQueue:テストの開始前に生成されたクエリリストを格納するクライアントのクエリキュー。

    • ClientThread:クライアントスレッドは、ClientQueryQueueからクエリを周期的に取り出し、MsgThreadおよびMsgQueueを介してサーバーに送信します。

  • サーバー上の独自のモジュール

    • WorkQueue:サーバーの保留中のmsgキュー。InputThreadがmsgを受信すると、WorkQueueに配置されます。

    • WorkThread:サーバーの実行スレッド。WorkQueueからmsgをフェッチして処理を実行します。実行が完了すると、msgが生成されて返されます。このメッセージも、MsgThreadおよびMsgQueueを介して送信されます。

 

3.2トランザクション実行プロセス

 

Denevaでは、図3に示すように、トランザクションの実行フローは次のとおりです。

1)クライアントは最初にトランザクション要求(複数の操作で構成される)を開始し、トランザクションをClientQueryQueueに入れます。ClientThreadは、トランザクション要求をキューから削除し、メッセージキューMsgQueueに格納します。その後、メッセージ送信スレッドは、MsgQueueから特定のトランザクションの操作セットを取り出し、それを要求としてカプセル化し、このトランザクションの調整ノードとして特定のサーバー(最初の操作によってアクセスされたデータによって決定される)に送信します。

2)リクエストがサーバーに到着すると、サーバーは最初にリクエストを解析し、このトランザクションのすべての操作を要素としてワークキュー(WorkQueue)に配置します。クライアントからの新しいトランザクションと、すでに開始されているトランザクションのリモート操作がワークキューに配置されます。後者は、キュー内の前者よりも優先度が高くなります。ワーカースレッドプール内のスレッドは、トランザクション内のワークキューとプロセス操作をポーリングします。ワーカースレッドが現在のトランザクションの操作を処理するとき、最初にトランザクションを初期化し、次に読み取り操作と書き込み操作を順番に実行し、最後にコミットまたはロールバックします。

  • トランザクションの実行プロセスでは、トランザクションが待機状態になる2つの状況があります。1つは特定のリソースの排他ロックが解放されるのを待つこと、もう1つはリモートサーバーのデータにアクセスすることです。他のサーバーのデータへのリモートアクセスで待機が必要な場合、リモートサーバーはWAIT命令を現在の調整ノードに返します。調整ノードは現在のトランザクションの待機状態を一時的に保存し、現在のワーカースレッドが他のトランザクション操作を実行するようにスケジュールします。ワーカースレッドのブロック。待機中のトランザクションが実行を継続できる場合、ワークキューの優先スケジュール戦略に基づいて、最初に使用可能なワーカースレッドによって実行が継続されます。

  • 同時実行制御プロトコルに必要な追加の操作は、読み取りおよび書き込み操作、検証操作、コミット/ロールバック操作など、トランザクション実行プロセスに組み込まれます。

3)調整ノードが特定のトランザクションの操作を完了すると、トランザクションの実行結果がメッセージキューに入れられ、メッセージ送信スレッドがクライアントに現在のトランザクションの実行結果を通知します。

図3Denevaトランザクション実行フローチャート

4.分散トランザクションの概要

 

文献[15]は、分散トランザクションを次のように定義しています。

分散トランザクションは、2つ以上のネットワークホストが関与するデータベーストランザクションです。通常、ホストはトランザクションリソースを提供しますが、トランザクションマネージャーは、そのようなリソースに対するすべての操作を含むグローバルトランザクションの作成と管理を担当します。分散トランザクションは、他のトランザクションと同様に、4つすべてのACID(原子性、一貫性、分離、耐久性)プロパティを備えている必要があります。原子性は、作業単位(操作バンドル)の結果をオールオアナッシングで保証します。

分散トランザクションは、分散システムを物理的な基盤として取り、トランザクション処理のセマンティック要件を実現します。つまり、分散システムではACID特性も満たす必要があります。したがって、分散データベースの分散トランザクション処理は、スタンドアロンデータベースシステムでのトランザクション関連の理論にも従い、各トランザクションがACIDの要件を満たしていることを確認し、分散同時アクセス制御テクノロジを使用して分散システムのデータ異常を処理する必要があります。分散トランザクションACID特性を実現します。

分散トランザクション処理メカニズムの基本テクノロジは、スタンドアロンデータベースシステムのトランザクション処理テクノロジに基づいていますが、分散データの例外を処理する方法、分散アーキテクチャでシリアル化を実現する方法、およびその方法など、いくつかの違いがあります。ノード間のアトミックコミット、ネットワークパーティションまたはより高い遅延を伴うトランザクションに適切に応答する方法など。

3TSフレームワークは分散環境であり、これらのコンテンツは3TSで実装および検証されます。

 

5.3TSが提供する同時アクセス制御アルゴリズム

 

現在、13の同時実行アルゴリズムが3TSに統合されており、主に次のものが含まれます。

 

(1)2段階の封鎖協定(2PL:待機なし、待機-死ぬ)

(2)タイムスタンプシーケンスプロトコル(T / O)

(3)マルチバージョン同時実行制御プロトコル(MVCC)

(4)楽観的同時実行制御プロトコル(OCC、FOCC、BOCC)

(5)最適化された楽観的同時実行制御プロトコル(MaaT、Sundial、Silo)

(6)決定論的同時実行制御プロトコル(Calvin)

(7)スナップショット分離に基づく同時実行制御プロトコル(SSI、WSI)

以下は、これらの同時実行制御プロトコルの簡単な紹介です。

 

5.1 2フェーズロックダウン契約(2PL)

  

2フェーズロック(2PL)は、現在最も広く使用されている同時実行制御プロトコルです。2PLは、読み取りおよび書き込み操作が発生したときに共有ロックまたは排他ロックを取得して、トランザクション間で競合する操作を同期することに依存しています。BernsteinとGoodmanの説明[2]によると、2PLには、ロック取得に関して次の2つのルールがあります。1)同じデータ項目に同時に2つの競合するロックが存在することはできません。2)トランザクションがロックを解放した後、これ以上ロックを取得することはできません。2番目のルールでは、トランザクションのロック操作は、成長フェーズと縮小フェーズの2つのフェーズに分割されると規定されています。成長フェーズでは、トランザクションはアクセスする必要のあるすべてのレコードのロックを取得します。読み取り操作は共有ロックを取得し、書き込み操作はミューテックスロックを取得します。共有ロックは競合せず、ミューテックスロックは共有ロックまたは他のミューテックスロックと競合します。トランザクションがいずれかのロックを解放すると、トランザクションは2PLの第2フェーズに入ります。これは、減衰フェーズと呼ばれます。この段階に入った後、トランザクションは新しいロックを取得できません。

3TSは、トランザクションがコミットまたは終了されるまでロックを解放しないStrict 2PL(Strict 2PL)プロトコルを実装します。デッドロックを回避するさまざまな方法によると、3TSに実装される2PLには、2PL(待機なし)と2PL(待機ダイ)の2つのタイプがあります。実装は[2,3]のこれら2つのプロトコルの説明に従います。

 

5.1.1 2PL(待機なし)

 

契約では、トランザクションがロックしようとしたときにロックの競合が見つかった場合、現在ロックを要求しているトランザクションがロールバックされることが規定されています。ロールバックされたトランザクションによって保持されていたロックが解放され、他のトランザクションがロックを取得できるようになります。No_Waitメカニズムは、トランザクション間の待機がループを形成しないため、デッドロックを回避できます。ただし、すべてのロックの競合によってデッドロックが発生するわけではないため、ロールバック率が高くなる可能性があります。

 

5.1.2 2PL(ウェイトダイ)

 

Rosenkrantz [3]は、トランザクション開始タイムスタンプを優先度として使用して2PL(Wait-Die)を提案し、ロック待機関係がタイムスタンプシーケンスと一致するようにしました。トランザクションのタイムスタンプが現在ロックを保持しているどのトランザクションよりも小さい(古い)限り、現在のトランザクションは待機する必要があります。そうでない場合、現在のトランザクションをロールバックする必要があります。競合する2つのトランザクションTiとTjの場合、プロトコルはタイムスタンプの優先度を使用して、TiにTjを待機させるかどうかを決定します。Tiの優先度が低い(タイムスタンプが小さい)場合、Tiは待機する必要があります。それ以外の場合、Tiはロールバックします。したがって、ロック待機グラフはループを形成せず、この方法でデッドロックの発生を回避できます。このアルゴリズムは、TOとロック技術の融合です。

ただし、2PLの原則によって実装される分散トランザクション処理メカニズムは、デッドロック(高いロールバック率)を回避するか、デッドロックの問題(リソースデッドロックと通信デッドロック)を解決する必要があります。分散システムでデッドロックを解決するコストは非常に高くなります(シングルマシンシステムでデッドロックを解決するコストはすでに高く、マルチプロセスまたはマルチスレッドアーキテクチャに基づく最新のデータベースシステムでは、システムのサービスがほぼ停止する可能性があります。 MySQL 5.6および5.7では、同じデータ項目が同時に更新され、デッドロック検出操作によってシステムのサービスがほぼ停止します)。

デッドロックの検出は膨大なリソースを消費するだけでなく、ロックメカニズム自体の欠点も批判されています。文献[5]は、ブロッキングメカニズムの欠点は次のとおりであると考えています(これらの欠点を明確に理解することで、文献[5]の作成者はOCC、楽観的同時アクセス制御、および楽観的同時アクセス制御を設計するようになりました)。

1.ブロッキングメカニズムは高価です。シリアル化可能性を確保するために、ロックプロトコルでは、データベースの整合性制約を変更しない読み取り専用トランザクションが必要であり、他のユーザーが変更できないように、読み取りロックと相互除外を使用した同時書き込み操作が必要です。デッドロックを引き起こす可能性があるトランザクションの場合。ロックプロトコルは、デッドロック防止/デッドロック検出などのメカニズムによって引き起こされるオーバーヘッドにも耐える必要があります。

2.複雑なブロックメカニズム:デッドロックを回避するには、さまざまな複雑なロックプロトコルをカスタマイズする必要があります(ロックするタイミング、ロックを解除できるタイミング、厳密さを確保する方法など)。

3.システムの同時スループットを減らします。

a)I / O操作を待機しているトランザクションでロックを保持すると、システムの全体的な同時スループットが大幅に低下します。

b)トランザクションのロールバックが完了する前に、ロックされたトランザクションがロールバックするときに、トランザクションのロールバックが終了するまでロックを保持する必要があります。これにより、システムの全体的な同時スループットも低下します。

さらに、相互除外操作にロックメカニズムを使用すると、オペレーティングシステムで時間のかかるカーネルモード操作が発生し、ロックメカニズムが非効率になります。これは、オペレーティングシステムのロックメカニズムに基づくトランザクションセマンティクスを備えた2PLテクノロジがさらに使用できないことを意味します(ただし、ブロッキングプロトコルに基づく同時アクセス制御アルゴリズムを絶えず改善しているテクノロジもあります)。

 

5.2タイムスタンプソートプロトコル(T / O)

   

Timestamp Ordering Protocol(TimestampOrdering、T / O)は、トランザクションの開始時にトランザクションにタイムスタンプを割り当て、タイムスタンプの順序でトランザクションを並べ替えます[2]。操作の実行がトランザクション間で指定された順序に違反した場合、現在の操作が配置されているトランザクションはロールバックされるか、待機状態になります。

3TSでのT / Oアルゴリズムの実装は、[2]のセクション4.1の説明に従います。詳細については、このドキュメントを参照してください。次の図は、基本的なT / Oアルゴリズムの実装を示しています。

図4T / Oアルゴリズム

 

5.3マルチバージョン同時実行制御プロトコル(MVCC)

 

マルチバージョン同時実行制御(MVCC)は、現在のデータベース管理システムで一般的に使用されている同時アクセス制御テクノロジです。1978年にDavid Patrick Reed [4]によって最初に提案されました。主なアイデアは、論理データ項目を結合することです。複数の物理バージョンに拡張すると、データ項目のトランザクション操作がバージョン操作に変換されるため、トランザクション処理の同時実行性が向上し、相互にブロックすることなく読み取りと書き込みの機能を提供できます。

 

マルチバージョン同時アクセス制御、マルチバージョン同時アクセス制御テクノロジ、MVCCテクノロジと呼ばれます。

1970年にMVCC技術が提案され、1978年に[4]「分散型コンピュータシステムの命名と同期」がさらに説明されました。1981年の後半に、文書[16]でMVCC技術が詳細に説明されましたが、説明されたMVCC技術はタイムスタンプに基づいていました。 。

マルチバージョンT / O

:rw sync hronizationの場合、基本的なT / Oschedulerはmultiversiondata項目[REED78]を使用して改善できます。データ項目xごとに、バージョンと呼ばれるR-tsのセットと(W-ts、値)のペアのセットがあります。xのRtsは、実行されたすべてのdm-read(x)操作のタイムスタンプを記録し、バージョンは、実行されたすべてのdm-write(x)操作のタイムスタンプと値を記録します。(実際には、R-tsとバージョンを永久に保存することはできません。古いバージョンとタイムスタンプを削除する手法については、セクション4.5と5.2.2で説明しています。)

その後、MVCCテクノロジーが広く使用され、多くのバージョンが派生しました。

2008年に、文献[13]が公開され、MVCCに基づくシリアル化可能な分離レベルを達成するための「SerializableSnapshotIsolation」テクノロジーが提案されました。これにより、PostgreSQL V9.1はこのテクノロジーを使用して、シリアル化可能な分離レベルを実現します。

2012年に文献[14]が発行され、読み書きの競合を検証することでMVCCに基づくシリアル化可能な分離レベルを実現する「Write-snapshotIsolation」技術を提案しました。書き込みと書き込みの競合を検出する方法と比較して、同時実行性(ある種の書き込みと書き込みの競合)が向上します。競合はシリアル化可能です)。この記事の著者は、HBaseに基づいてシステムを実装しました。

2012年、文献[17]はPostgreSQLにSSIテクノロジーを実装しました。このドキュメントでは、シリアル化されたスナップショットの理論的基礎、PostgreSQLのSSIテクノロジの実装について説明するだけでなく、トランザクションの戻りを引き起こす読み取りと書き込みの競合を回避するため、読み取り専用トランザクションをサポートする「セーフスナップショット」と「遅延可能なトランザクション」も提案します。ロールバックの影響は、ロールバックされるトランザクションに「安全な再試行」戦略を採用することであり、ロールバック読み取り/書き込み競合トランザクションの選択の影響に対する2フェーズコミットの影響です。

文献[19]は、MVCCテクノロジの4つの側面、つまり、同時アクセス制御プロトコル、マルチバージョンストレージ、古いバージョンのガベージコレクション、インデックス管理について体系的に説明し、MVCCの複数のバリアントの原則について説明しました。さまざまなバリアント(MV2PL、MVOCC、MVTOなど)がOLTPワークロードでテストおよび評価されます。[18]古いバージョンのMVCCガベージコレクションについて詳細に説明しました。

 

3TSでは、MVCCは、[2]のセクション4.3の説明に基づいて、T / Oアルゴリズムと組み合わせて実現されます。したがって、トランザクションは引き続きソートに開始タイムスタンプを使用します。従来のT / Oアルゴリズムとは異なり、MVCCは複数のバージョンの機能を使用して、T / Oでの操作待機オーバーヘッドを削減します。MVCCの操作実行メカニズムは次のとおりです(tsを使用して現在のトランザクションのタイムスタンプを表します)。

1.読み取り操作

a)tsがprereqのすべてのトランザクションのタイムスタンプより大きく、writehis(現在のデータ項目のバージョンチェーン)にバージョンがあり、そのwtsがtsより大きくptsより小さい場合、現在のバージョンと現在のトランザクションのタイムスタンプを返すことができます。 readhisに預金します。writehisに対応するタイムスタンプがない場合、現在のトランザクションのタイムスタンプはreadreqに保存されます。主な理由は次のとおりです。

  1. 書き込み前トランザクションと読み取り操作の間にコミットされた書き込みがある場合、現在の読み取り操作によって読み取られたデータが書き込みトランザクションによって書き込まれ、タイムスタンプの順序が満たされ、バージョンを読み取ることができることを意味します。

  2. 読み取り操作のタイムスタンプは、現在の未完了の書き込みトランザクションのタイムスタンプよりも大きくなっています。新しいデータを読み取る必要があるため、待機してください。

b)それ以外の場合、現在の読み取り操作は、タイムスタンプを介して最新の表示バージョンを読み取り、現在のトランザクションのタイムスタンプをreadreqに格納します。

2.書き込み操作

a)tsがreadhisのすべてのトランザクションのタイムスタンプよりも小さく、writehisのrtsとtsの間にタイムスタンプがある場合、データは通常どおり事前に書き込むことができます。writehisに適格なバージョンがない場合、現在のトランザクションはロールバックされます。

b)現在の書き込み操作をprereq_mvccに一時的に保存します。

3.操作を送信します

a)現在のトランザクションタイムスタンプとwritehisに書き込まれた新しいバージョンを挿入します。

b)現在のトランザクションの書き込み操作を前提条件から削除します。

c)readreqのタイムスタンプシーケンスを満たす読み取りトランザクションの実行を継続します。

 

より多くの同時アクセス制御アルゴリズム、継続中...お楽しみに!

 

ありがとう

Tencent TDSQLチームと、中国人民大学教育省のデータエンジニアリングおよび知識エンジニアリングの主要研究所のこの作業へのサポートと支援に感謝します。また、Zhao Zhanhao、Liu Chang、Zhao Hongyao、および他の学生のこの記事への貢献に感謝します。

 

参照

[1] Rachael Harding、Dana Van Aken、Andrew Pavlo、Michael Stonebraker:分散同時実行制御の評価。手順 VLDB寄付。10(5):553-564(2017)

[2] Philip A. Bernstein、NathanGoodman:分散データベースシステムの同時実行制御。ACMComput。Surv.13(2):185-221(1981)

[3] Daniel J. Rosenkrantz、Richard Edwin Stearns、Philip M. Lewis II:分散データベースシステムのシステムレベルの同時実行制御。ACM Trans.DatabaseSyst。3(2):178-198(1978)

[4] DPリード。分散型コンピュータシステムでの命名と同期。博士論文、マサチューセッツ工科大学、ケンブリッジ、マサチューセッツ州、米国、1978年。

[5] HT Kung、John T. Robinson:ConcurrencyControlの楽観的方法について。ACMトランス。データベースシステム。6(2):213-226(1981)

[6]TheoHärder:楽観的同時実行制御スキームに関する観察。Inf。システム。9(2):111-120(1984)

[7] Hatem A. Mahmoud、Vaibhav Arora、Faisal Nawab、Divyakant Agrawal、AmrEl Abbadi:MaaT:クラウド内の分散トランザクションの効果的かつスケーラブルな調整。手順 VLDB寄付。7(5):329-340(2014)

[8] Xiangyao Yu、Yu Xia、Andrew Pavlo、DanielSánchez、Larry Rudolph、Srinivas Devadas:

日時計:分散OLTPデータベース管理システムでの同時実行制御とキャッシングの調和。手順 VLDB寄付。11(10):1289-1302(2018)

[9] Stephen Tu、Wenting Zheng、Eddie Kohler、Barbara Liskov、Samuel Madden:マルチコアインメモリデータベースでの高速トランザクション。SOSP 2013:18-32

[10] Alexander Thomson、Thaddeus Diamond、Shu-Chun Weng、Kun Ren、PhilipShao、Daniel J. Abadi:Calvin:パーティション化されたデータベースシステムの高速分散トランザクション。SIGMOD Conference 2012:1-12

[11] Hal Berenson、Philip A. Bernstein、Jim Gray、Jim Melton、Elizabeth J.O'Neil、Patrick E. O'Neil:ANSISQL分離レベルの批評。SIGMODConference 1995:1-10

[12] Alan D. Fekete、Dimitrios Liarokapis、Elizabeth J. O'Neil、Patrick E.O'Neil、Dennis E. Shasha:スナップショットの分離をシリアル化可能にします。ACM Trans.DatabaseSyst。30(2):492-528(2005)

[13] Michael J. Cahill、UweRöhm、Alan D. Fekete:スナップショットデータベースのシリアル化可能な分離。SIGMOD Conference 2008:729-738

[14] Maysam Yabandeh、DanielGómezFerro:スナップショットアイソレーションの批評。EuroSys 2012:155-168

[15] https://en.wikipedia.org/wiki/Distributed_transaction

[16] P. Bernstein、V。Hadzilacos、およびN.Goodman。データベースシステムにおける同時実行制御と回復。アディソン-ウェスリー、1987年。

[17] DRPortsおよびK.Grittner、「Serializableスナップショットアイソレーションinpostgresql」、PVLDB、vol。5、いいえ。12、pp。1850–1861、2012。

[18]J.Böttcher、et al。、In-Memory MVCC SystemsのScalableGarbageCollection、VLDB、2019年

[19] Yingjun Wu、Joy Arulraj、Jiexi Lin、Ran Xian、Andrew Pavlo:インメモリマルチバージョン同時実行制御の経験的評価。手順 VLDBEndow。10(7):781-792(2017)

[20] D。ロメットとM. F. Mokbel、「バンドルされていないトランザクションサービスによるキー範囲のロック」、VLDB、pp。265〜276、2009年。

[21] Jinwei Guo、PengCai、Jiahao Wang、Weining Qian、Aoying Zhou:異種ワークロードの適応最適同時実行制御。PVLDB12(5):584-596(2019)

[22] X. Yu、A。avlo、D。Sanchez、およびS.Devadas、「Tictoc:Time travelling optimistic concurrency control」、Proceedingsof SIGMOD、vol。2016年8月、209〜220ページ。

[23] Rudolf Bayer、Klaus Elhardt、Johannes Heigert、Angelika Reiser:データベースシステムでのトランザクションの動的タイムスタンプ割り当て。DDB 1982:9-20

Tencent Technology Official Exchange WeChatGroupが開設されました

グループに参加してWeChatを追加します:journeylife1900

(備考:テンセントテクノロジー)

おすすめ

転載: blog.csdn.net/Tencent_TEG/article/details/110251374