NoSQLからNewSQLへ、トランザクション分散データベース構築のポイント

前回の記事「アーキテクチャの特徴から機能上の欠陥まで、分析的分散データベースの再理解」では、さまざまな「分散データベース」の横断的な分析を完了しました。この記事では、分解の後半部分について説明します。 NoSQL と NewSQL の違いを組み合わせて、垂直的な観点から OLTP シナリオにおける「分散データベース」実装ソリューションの主要な技術的ポイントについて説明します。このような考え方は前回の記事の延長であり、分散データベースに関する特集記事の概要でもあります。重要なポイントについては、後ほど別の記事で詳しく説明します。

1. NewSQL と NoSQL

NewSQL はこのトピックの焦点であり、前の記事で具体的に言及した「分散データベース」でもあります。 OLTP シナリオに適しており、高い同時実行性と低レイテンシという特徴を備えています。その特性は、Oracle/DB2 などの従来のデータベースに近いです。一般的な X86 サーバーを利用して水平方向のパフォーマンス拡張を実現し、大規模なトランザクションのパフォーマンス圧力に耐えることができます。

現在、最もよく知られている NewSQL には、Google の Spanner/F1、Alibaba の OceanBase、CockroachDB、TiDB などがあります。後者の 2 つは成長中のオープンソース プロジェクトであり、2.0 バージョンは 2018 年にリリースされました。

NewSQL と NoSQL は深いつながりがあるため、以下の NewSQL の紹介では、対応する NoSQL 実装テクノロジのいくつかについても説明します。

1. ストレージエンジン

B+ ツリー

B+ ツリーは、リレーショナル データベースでよく使用されるインデックス ストレージ モデルです。効率的な範囲スキャンをサポートできます。リーフ ノードは主キーによって関連付けられ、リンクされ、順序付けられるため、スキャン中に時間のかかるツリー トラバーサル操作が回避されます。 B+ ツリーの制限は、大規模なランダム書き込みシナリオには適しておらず、「書き込み増幅」と「ストレージの断片化」を引き起こすことです。

B+ツリーの動作を説明するために、Jiang Chengyao教授の著書[1]からの次の例が使用されています。

高さ 2 の B+ ツリーが 5 つのページ テーブルに格納され、各ページには 4 つのレコードを格納でき、ファンアウトは 5 です。次の図は、リーフ ノード内のデータへのポインターとリーフ ノード間のシーケンス ポインターを省略した B+ ツリーの構造を示しています。

B+ ツリーは、内部ノード (InterNode) とリーフ ノード (LeafNode) の 2 種類のノードで構成されます。後者はデータへのポインターを保持しますが、前者にはインデックス情報のみが含まれます。

インデックス値が 70 のレコードを挿入する場合、対応するページ テーブルがいっぱいであるため、B+ ツリーを再配置し、その親ノードが配置されているページ テーブルのレコードを変更し、隣接するページ テーブルのレコードを調整する必要があります。再配布後の効果は以下のとおりです。

変更プロセスには 2 つの問題があります。

• 書き込み増幅

この例では、論理的には 1 つの書き込みレコードのみが必要です (黄色でマークされています) が、実際には 3 つのページ テーブル内の 7 つのインデックス レコードが変更されます。追加の 6 つのレコード (緑色でマーク) は、B+ ツリー構造によって生成された書き込み増幅を維持するためのものです。

注: 書き込み増幅: 書き込み増幅とは、アプリケーションが書き込んだデータ量と比較したストレージに書き込まれたデータ量、つまり、ディスクに書き込まれた実際のデータサイズと、アプリケーションが書き込むために必要なデータサイズの比率です。

• 保管は連続的ではない

新しく追加されたリーフ ノードは、元のリーフ ノードで構成される順序付きリンク リストに追加され、全体が論理的に連続します。しかし、ディスク ストレージでは、新しく追加されたページ テーブルによって要求されるストレージ領域は、元のページ テーブルに隣接しない可能性があります。このように、新しく追加されたリーフ ノードを含む後続のクエリでは、複数の連続した読み取りが発生し、ディスクのアドレス指定時間が長くなります。さらに、B+ツリー上で大量のランダム書き込みを実行すると、ストレージの断片化が発生します。

実際に B+Tree を使用するデータベース製品 (MySQL など) では、通常、ターゲットを絞った最適化のためにフィル ファクターが提供されます。フィルファクタの設定が小さすぎると、ページテーブルの数が拡大し、ディスクのスキャン範囲が拡大してクエリのパフォーマンスが低下します。設定値が大きすぎると、データの挿入時に書き込み拡張が発生し、大量のページングが発生し、挿入パフォーマンスが低下します。同時に、不連続なデータ保存によりクエリのパフォーマンスも低下します。

LSMツリー

LSM-Tree（Log Structured-Merge Tree）はPatrick O'Neilによって初めて提案され、彼は論文[2]でLSM-TreeとB+ Treeの違いを体系的に説明しました。 Google は、次に示すように、このモデルを Bigtable に導入しました。

LSM-Tree の主なアイデアは、メモリを利用してランダム書き込みをシーケンシャル書き込みに変換し、書き込みパフォーマンスを向上させることです。同時に、書き込み操作のディスク占有量が大幅に削減されるため、読み取り操作によるディスク制御が向上し、読み取り操作のパフォーマンスにそれほど影響が及ばなくなります。

書き込み操作は次のように簡略化されます。

• 書き込み要求が到着すると、まずメモリ内の Memtable に書き込まれ、増分データの変更が処理され、WAL 先行書き込みログが記録されます。
• メモリ内の増分データが特定のしきい値に達すると、現在の Memtable は凍結され、新しい Memtable が作成されます。凍結された Memtable 内のデータは順番にディスクに書き込まれ、順序付けられたファイル SSTable (Sorted String Table) が形成されます。この操作はマイナー コンパクションと呼ばれます (HBase では、この操作はフラッシュ操作と呼ばれ、マイナー コンパクションには他の意味もあります)。
• これらの SSTable は、特定のルールを満たした後にマージされます。これをメジャー コンパクションと呼びます。各列ファミリーのすべての SSTable が 1 つの大きな SSTable にマージされます。

このモデルは、ランダム書き込みの IO 効率の問題を回避し、B ツリー インデックスの書き込み増幅の問題を効果的に軽減し、書き込み効率を大幅に向上させます。

LSM ツリー モデルは、HBase、Cassandra、LevelDB、RocksDB、その他の K/V ストレージを含む NoSQL で広く使用されています。

もちろん、LSM-Tree にも欠点はあります。

• まず、メジャー コンパクション操作は、オンラインでの読み取りと書き込みに大きな影響を与え、書き込み増幅も引き起こします。このため、HBase では通常、システムによるメジャー コンパクションの自動実行が禁止されます。

注:

メジャー コンパクション操作の目的は、読み取り操作の時間の複雑さを軽減することです。システムに合計 N 個のデータを含む複数の SSTable ファイルが含まれており、SSTable には平均して m 個のデータが含まれているとします。

読み取り操作を実行する場合、単一の SSTable ファイルに対してバイナリ検索方式を使用する場合の時間計算量は O(log2m) であり、全体の時間計算量は O(N/m*log2m) です。 1つのSSTableに統合すると、時間計算量はO(log2N)に削減できる。

• 第二に、読み取り効率への影響があります。 SSTable ファイルはすべて同じレベルにあり、バッチ書き込みの実行順序に従って複数のファイルが形成されるため、異なるファイル内のキー (レコードの主キー) は重複します。この方法では、読み取り操作を実行するときに各ファイルを検索する必要があり、不要な I/O オーバーヘッドが発生します。
• 最後に、空間増幅があります。最悪の場合、LSM ツリーでは、圧縮アクションを完了するためにデータのサイズに等しい空き領域が必要になり、つまり、領域が 100% 増幅されますが、B+ ツリーの領域増幅は約 1/3 です。

レベル別 LSM ツリー

Leveled LSM Tree の変更点は、SSTable がさらに階層化され、書き込み増幅が削減され、読み取るファイルの範囲が狭まることです。これは最初にLevelDBで使用され、その後Cassandra 1.0でもこの戦略が導入されました[3]。

SSTable の階層設計戦略は次のとおりです。

• 単一の SSTable ファイルのサイズは固定されており、Cassandra ではデフォルトで 5 MB に設定されています。
• レベルはレベル 0 から増加し、レベルの増加に伴って保存されるデータの量も増加します。レベル間では一貫した成長係数があります。 Cassandra では、成長係数が 10 に設定され、レベル 1 ファイルが 1 ～ 10M、レベル 2 ファイルが 10 ～ 100M の場合、10TB のデータがレベル 7 に到達します。
• レベル 0 SSTable は特別です。 4 つのファイルに固定されており、ファイル間でキーの重複があります。レベル 1 以降、SSTable にはキーの重複がなくなります。
• レベル 0 の SSTable が容量を超えると、レベル 1 への圧縮が実行されます。キーの交差があるため、レベル 0 のすべての SSTable を読み取る必要があります。レベル 1 のファイル サイズがしきい値を超えると、レベル 2 の SSTable が作成され、レベル 1 の元の SSTable は削除されます。レベル 1 のキー範囲がレベル 2 の複数の SSTable に対応する場合、複数の SSTable を書き換える必要があります。ただし、SSTable のサイズは固定されているため、通常は少数の SSTable のみが関係します。

レベル間のコンパクトな操作

複数の順序付けられた SSTable は、メジャー コンパクションなどの大量のファイルの書き換えを回避し、毎回コンテンツの一部のみを更新するため、書き込み増幅が軽減されます。

関連する SSTable をロックするためにメタデータを読み取ることは、すべての SSTable に対してバイナリ検索や Bloom Filter を使用するよりも明らかに効率的です。その結果、読書効率が大幅に向上します。ある評価方法[3]によれば、データの各行のサイズが基本的に同じ場合、読み取り操作の90%は1つのSSTableにのみアクセスします。

この戦略では、圧縮操作がより頻繁に行われ、I/O オーバーヘッドが増加します。書き込み集中型の操作の場合、最終結果で十分な効率改善が達成できるかどうかは不確実であり、アプリケーションでこれを考慮する必要があります。

新しいSQL戦略

NewSQL データベースのストレージ層では一般的に K/V ストレージが使用されるため、基本的に LSM ツリー モデルが採用されます。 CockroachDB と TiDB はどちらも KV レイヤーで RocksDB を使用します。 OceanBase は、Major Compaction の影響を回避するためにさまざまな方法を使用します。一般的に、読み取り操作のブロックを回避するために、アイドル レプリカ (フォロワー) を使用して圧縮操作を実行します。圧縮が完了すると、レプリカの役割が置き換えられます。

同時に、K/V ストレージ エンジンはまだ開発中です。フラクタル ツリーなどのその他の改善点については、スペースの制限によりここでは説明しません。

2. シャーディング

シャーディングの概念は、RDBMS パーティショニングに似ています。これは、分散データベースや分散ストレージシステムの最も重要な機能であり、水平拡張の基盤であり、NoSQL システムでも広く使用されています。

シャーディングの目的は、複数のノード間でデータを可能な限り均等に分散し、複数のノードのデータ ストレージと処理機能を使用して、データベースの全体的なパフォーマンスを向上させることです。

レンジ＆ハッシュ

さまざまなシステムでシャーディング戦略はさまざまな細分化が行われますが、大まかに言えば、範囲とハッシュの 2 つの方法にまとめることができます。

範囲シャーディングは範囲クエリに有益ですが、ハッシュシャーディングを使用するとバランスの取れたデータ分散を実現しやすくなります。実際のアプリケーションでは、Range シャーディングがより頻繁に使用されているようですが、2 つのシャーディング方法を混在させるアプリケーションも多数あります。

HBase は、Rowkey に従ってデータを辞書順に並べる Range メソッドを使用します。 1 つのリージョンの上限を超えると、2 つの新しいリージョンに分割されます。 Range の利点は、データが近接しているため、データにアクセスするときに範囲検索のコストが低くなることです。デメリットも明らかで、ホットスポットの集中が発生しやすくなります。

たとえば、継続的に増加するシリアル番号がほとんどの場合同じ RegionServer に割り当てられ、同時アクセスによって RegionServer リソースが競合する可能性があるため、HBase でビジネス シリアル番号を RowKey として使用することは一般的に推奨されません。この問題を回避するには、RowKey をエンコードするか、シーケンス番号を逆にするか、ソルトを追加することをお勧めします。この方法は、基本的にアプリケーション層の設計戦略を使用して、範囲シャーディングをハッシュシャーディングに似た方法に変換します。

Spanner の基盤となるストレージは BigTable の設計アイデアの多くを採用していますが、シャーディングにいくつかの調整が加えられています。範囲シャーディングと操作ホットスポット間の不一致の問題を回避するために、ディレクトリの動的割り当てがタブレットに追加されました。これについては、後ほどトランザクション管理のセクションで詳しく説明します。

静的シャーディングと動的シャーディング

断片化生成戦略に応じて、断片化は静的断片化と動的断片化の 2 つのカテゴリに分類できます。

静的シャーディングでは、システム構築の開始時にシャードの数を決定するため、後で変更するには非常にコストがかかります。動的シャーディングとは、データの状況に基づいて指定されるシャーディング戦略のことであり、変更コストが低く、必要に応じて調整できます。

従来の DB + プロキシ ソリューションでは、水平シャーディングは一般的な静的シャーディングです。いくつかの有名なインターネット大手は、大規模なトランザクション システムで同様の設計を行っており、デフォルトでデータを 100、255、1024 などの固定数のシャードに分割しています。シャードの数は、システムの期待される目標の全体的なサービス機能、データの量、および単一ノードの容量に基づいて評価できます。もちろん、100 個のシャードと 1024 個のシャードのどちらが適切であるかは、ある程度推測の問題です。

NoSQL では、Redis クラスターも同じ静的シャーディング方式を使用し、デフォルトでは 16384 個のハッシュ スロット (シャーディングと同等) が使用されます。

静的シャーディングの欠点は、シャードの数が決まっており、単一ポイントの処理能力に基づいて容量の上限が形成されることです。柔軟性が低く、後でシャード数を調整すると、データの移行が難しくなり、実装が複雑になります。利点も明らかです。静的シャーディング戦略はほぼ固定されているため、パーティション キーやパーティション戦略などのメタデータ管理への依存度は非常に低くなります。ただし、これらのメタデータは分散データベース内で単一のポイントを形成することが多く、信頼性と可用性の向上の障害となります。

対照的に、動的シャーディングはより柔軟で、より幅広いアプリケーション シナリオに適しているため、NewSQL でも主に動的シャーディングを採用していますが、メタデータ管理の複雑さが増すというデメリットがあります。

シャーディングに関して言えば、NoSQL と NewSQL が直面する問題は非常に似ています。

3. コピー

まず、汎用デバイス単体の信頼性が低いため、複数のコピーが必要になります。この記事では、レプリカの一貫性という 2 つの問題に焦点を当てます。もう 1 つは、レプリカの信頼性とレプリカの可用性の違いです。

データコピーの一貫性

複数のコピーを作成すると、必然的にコピーのデータ一貫性の問題が発生します。以前にも有名な CAP 理論があり、皆さんもよくご存知だと思いますが、ここでもう一度述べなければなりません。 CAP の一貫性とトランザクション管理の一貫性は同じではありません。私は、誤解している学生に多く会ってきましたが、彼らは CAP を基礎として、分散アーキテクチャではトランザクションの強い一貫性は実現できず、結果的な一貫性しか実現できないことを証明しようとしています。

トランザクションの一貫性とは、異なるデータ エンティティが同じトランザクションで一緒に変更され、すべてが成功するか、すべてが失敗するという事実を指します。 CAP における一貫性とは、原子粒度のデータ コピーによって一貫性が確保される方法を指し、複数のコピーは論理的に同じデータ エンティティです。

レプリカ同期は、大まかに次の 3 つのモードにまとめることができます。

• 強力な同期: データを正常に更新するには、複数のレプリカを更新する必要があります。このモデルの問題は、レイテンシが高く、可用性が低いことです。 1 つの操作ですべてのレプリカが更新されるのを待つ必要があるため、ネットワーク通信のオーバーヘッドが大幅に増加し、待ち時間が増加します。複数のレプリカノードが正常に動作している場合にのみ、システム全体が利用可能になります。 1 つのポイントが利用不可になると、システム全体が利用不可になります。単一ポイントの可用性が 95% であると仮定すると、3 つのノードで構成される複数のレプリカの信頼性は 95% * 95% * 95% = 85.7% になります。そのため、Oracle/MySQL などの主流のデータベースは強力な同期方法を提供していますが、実際の企業の運用環境ではほとんど使用されていません。
• 半同期: MySQL は、複数のスレーブ ノードがマスター ノードからのデータを同期する半同期モードを提供します。いずれかのスレーブ ノードが正常に同期すると、マスター ノードは成功したと見なされます。この論理モデルは、強力な同期の問題を効果的に回避し、マルチノードの可用性の影響を「および」から「または」に変更して、全体的な可用性を確保します。しかし残念なことに、技術的な実装に欠陥があり、非同期状態に退化する問題が発生する可能性があります。
• Paxos/Raft: この方法では、参加ノードをリーダー/フォロワーなどの役割に分割します。マスターノードは複数のバックアップノードにデータを書き込みます。半数以上のノードが書き込みに成功すると、クライアントに書き込み成功が返されます。この方法により、ネットワーク ジッタやスタンバイ ノードのサービス異常がクラスター全体に与える影響を回避できます。 Zookeeper の ZAB プロトコルや Kafka の ISR メカニズムなどは、Paxos/Raft とは異なりますが、ほぼ同じ方向にあります。

レプリカの信頼性とレプリカの可用性

データのコピーはデータの永続性のみを保証するものであり、データが失われることはありません。また、レプリカの可用性、つまりデータが継続的に提供できるかどうかという問題にも直面しています。この問題を説明するために、HBASE-10070 を例に挙げます。

HBase は、分散ファイル システム HDFS を通じてデータの複数のコピーの保存を実装します。ただし、サービスを提供する場合、クライアントは RegionServer に接続して HDFS 上のデータにアクセスします。リージョンは固有の RegionServer によって管理されるため、RegionServer は依然として単一のポイントです。

RegionServer がダウンすると、HMaster がそれを検出するのに一定の時間がかかり、HMaster は新しい RegionServer をスケジュールして、対応するリージョンをロードします。全体のプロセスには数十秒かかる場合があります。大規模クラスターでは、単一点障害が頻繁に発生します。各ポイントごとに数十秒間のローカル サービスの中断が発生し、HBase の可用性が大幅に低下します。

この問題を解決するために、HBase ではスレーブ RegionServer ノードの概念が導入されています。マスターノードに障害が発生した場合、スレーブノードが引き続きサービスを提供します。ただし、RegionServer はステートレス サービスではありません。データはメモリに保存されるため、マスターとスレーブの RegionServer 間でデータ同期の問題が発生します。

HBase はデータの信頼性を実現しますが、データの可用性を完全に実現することはできません。 CockroachDB と TiDB のアイデアは、単一ノード上のメモリ データとディスク データの違いを完全に無視し、データの可用性を保証する Raft をサポートする分散 KV ストレージを実装することです。

4. トランザクション管理

分散トランザクション処理は、その複雑さのために NoSQL の開発で最初に放棄された機能です。しかし、大規模なインターネットアプリケーションの普及により、その実用的意義が徐々に顕著になり、再び NewSQL が避けることのできない課題となってきました。 NewSQL のトランザクション処理の改善により、過去 10 年間のデータベース テクノロジの進化は、ついにほぼ完全な上昇スパイラルを達成しました。

分散トランザクション管理の複雑さを考慮して、この記事では簡単な説明のみを行い、以降の記事で詳しく説明します。

NewSQL トランザクション管理は、制御方法に基づいて、ロックベースとロックフリーの 2 つのタイプに分けられます。ロックフリー モードでは、通常、タイムスタンプに基づいてトランザクションの競合を調整します。リソース占有方法の観点から、楽観的プロトコルと悲観的プロトコルに分けられます。両者の違いは、リソース競合に対する期待の相違にあります。悲観的なプロトコルは、競合が頻繁に発生すると考え、トランザクションがスムーズに完了するように、できるだけ早くリソースを押収します。楽観的なプロトコルは、紛争は時々起こるものと考え、許容できる最も遅い時期にのみリソースを奪取します。

以下では、最も古典的な「2 フェーズ コミット プロトコル」による実装方法と、2 つの具体的なアプリケーション プラクティスについて説明します。

2 フェーズ コミット プロトコル (2PC)

2 フェーズ コミット プロトコル (2PC) は、古典的な分散トランザクション処理モデルです。処理プロセスは 2 つの段階に分かれています。

リクエストフェーズ:

• ビジネスに関するお問い合わせ。コーディネーターは、トランザクションの内容をすべての参加者に送信し、トランザクションをコミットできるかどうかを尋ね、すべての参加者からの応答を待ち始めます。
• トランザクションを実行します。各参加ノードはトランザクション操作を実行し、元に戻すおよびやり直しの情報をトランザクション ログに記録します。
• 各参加者は、トランザクション クエリに対する応答をコーディネータにフィードバックします。参加者がトランザクション操作を正常に実行した場合、コーディネータに Yes をフィードバックし、トランザクションが実行可能であることを示します。参加者がトランザクションを正常に実行しなかった場合は、トランザクションを実行できないことを示す「No」というフィードバックが返されます。

提出フェーズ:

• トランザクションをコミットします。提出リクエストを送信します。コーディネーターはすべての参加ノードにコミット要求を送信します。
• トランザクションのコミット。コミットを受け取った後、参加者は正式にトランザクションのコミット操作を実行し、コミットの完了後にトランザクションの実行全体中に占有されていたトランザクション リソースを解放します。
• トランザクション送信結果をフィードバックします。トランザクションの送信が完了すると、参加者はコーディネーターに Ack メッセージを送信します。
• 取引を完了します。コーディネーターがすべての参加者から Ack メッセージを受信すると、トランザクションが完了します。
• トランザクションを中断します。ロールバック要求を送信します。コーディネーターはすべての参加者にロールバック要求を送信します。
• トランザクションはロールバックされます。ロールバック要求を受信した後、参加者は第 1 フェーズで記録された元に戻す情報を使用してトランザクションのロールバック操作を実行し、ロールバックが完了した後にトランザクション実行全体中に占有されていたトランザクション リソースを解放します。
• トランザクションのロールバック結果をフィードバックします。トランザクションのロールバックが完了すると、参加者はコーディネータに Ack メッセージを送信します。
• トランザクションを中断します。コーディネータがすべての参加者から Ack メッセージを受信すると、トランザクションは中断されます。

このモデルの主な利点は、そのシンプルな原理と簡単な実装です。

欠点も明らかです。 1 つ目は同期ブロッキングです。トランザクション プロセス全体を通じてすべての参加者がロックされるため、同時実行パフォーマンスに必然的に大きな影響が生じます。 2番目は単一点問題です。コーディネーターは1点です。第2段階でダウンした場合、参加者は常時ロックされます。

スパナ

Spannerの論文[4]によれば、分散トランザクション管理では依然として2PC方式が使用されているが、革新的な設計によりタブレットのデータ分散戦略が変更されている。タブレットは単一の連続したキー データ構造ではなくなり、スケジュール可能な最小のデータ編成単位として新しいディレクトリが追加されました。

動的割り当てにより、トランザクション内のノード間でデータが分散される可能性が低減されます。

このトランザクション処理の設計思想は、「分散トランザクションを処理する最善の方法は、分散トランザクション処理を実行することではなく、ローカルトランザクションにすること」であると理解しています。 OceanBase の初期バージョンでは、同様の概念で、トランザクション操作を集中的に処理するために独立したサーバー UpdateServer も使用されていました。

パーコレーター

Percolator[5]はGoogleが開発した増分ウェブインデックスシステムです。 Google は設立前、MapReduce を使用して完全な Web インデックス作成を実行していました。このような処理に必要な時間は、既存の Web ページの数によって異なり、非常に時間がかかります。さらに、ある日に少数の Web ページしか変更されなかった場合でも、完全なインデックス処理を実行する必要があり、多くのリソースと時間が浪費されます。 Percolator の増分処理方式を使用した後、処理時間が大幅に短縮されました。

この論文では、「2 フェーズ コミット プロトコル」のバリエーションである分散トランザクション モデルについて説明します。第2フェーズの作業を極限まで簡素化し、処理効率を大幅に向上します。

具体的な実装としては、Percolator は BigTable をベースにした分散トランザクション管理を実装します。 MVCC とロックの 2 つのメカニズムを組み合わせることで、トランザクションで操作されるすべてのレコードは、既存のバージョンを更新することなく新しいバージョンになります。これの利点は、トランザクション全体にわたって読み取り操作がブロックされないことです。

• トランザクション内のロックは、プライマリ ロックとセカンダリ ロックに分けられます。プライマリ ロックはトランザクションで操作される最初のレコードに追加され、その後、操作が進むにつれて、セカンダリ ロックがトランザクション内の他のレコードに徐々に追加され、プライマリ ロック レコードを指すようになります。ロックの競合が発生すると、優先順位の低いトランザクションがロックを解除し、トランザクションはロールバックされます。
• トランザクション内のすべてのレコードが更新されると、トランザクションは第 2 段階に入ります。このとき、マスター ロックのステータスのみを更新すればよく、トランザクションは終了します。
• スレーブ ロックのステータスは、非同期プロセスと、完了を支援する関連する読み取り操作によって異なります。スレーブ ロック レコードはマスター ロック レコードへのポインターを保持しているため、非同期プロセスと読み取り操作ではスレーブ ロックの正しいステータスを簡単に判断して更新できます。

ロックフリーのトランザクション制御、グローバル クロックの必要性など、分散トランザクション管理のその他の側面については、以降の記事で説明します。

II.結論

この記事とその前身の本来の目的は、典型的な技術的背景を持つ学生に「分散データベース」の異なる解釈を提供し、いくつかの重要な技術的ポイントを詳しく説明することで、さまざまな技術分野の学生が関連技術をある程度理解し、詳細な研究に関心を持つ学生のための基礎を築くことです。

分析が深まるにつれ、論文の枠組みが大きすぎて扱いにくく、そのためキーテクノロジーの解釈が深度によって異なると感じました。この記事で展開されていない部分については、次回以降の記事でできるだけ補足していきたいと思います。私のレベルが限られているため、記事には間違いや抜けがある可能性があります。誰でも議論し、修正することができます。

参考文献:

[1] 江成瑶、MySQLテクノロジーインサイダー：InnoDBストレージエンジン、中国機械出版、2011年

[2] パトリック・オニール ログ構造マージツリー

[3] Apache Cassandraのレベル圧縮

https://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra

[4] ジェームズ・C・コーベット、ジェフリー・ディーン、マイケル・エプスタイン他Spanner: Google のグローバル分散データベース

[5] ダニエル・ペンとフランク・ダベック、分散トランザクションと通知を使用した大規模増分処理