分散データベースのデータ一貫性の原則の説明と実装

[[206931]]

序文

分散データベースのデータ一貫性管理は、最も重要なコア技術の 1 つであり、分散データベースがデータベースの最も基本的な ACID 特性である「一貫性」を満たすことを保証するものでもあります。分散技術の発展に伴い、データの一貫性を保つためのソリューションと技術も絶えず進化しています。本稿では、筆者が実際に開発した分散データベースを事例として、分散データベースのデータ一貫性の原理と実際の実装について紹介します。

1. データの一貫性

1.1 データの一貫性とは何ですか?

従来のリレーショナル データベースを使用するほとんどの DBA が「データ整合性」という用語を見ると、最初の反応はクロス テーブル トランザクションにおけるデータ整合性のシナリオであると考えられます。ただし、この記事で紹介する「データの一貫性」とは、「データが複数のコピーで保存されている場合に、データの一貫性をどのように確保するか」というシナリオを指します。

ビッグデータの分野では、データのセキュリティはハードウェアではなく、ソフトウェアによって、つまり複数のコピーに同時にデータを書き込むことによって保証されるようになりました。データベースがレコードを同時に複数のコピーに書き込むときに、各コピーのデータの一貫性を確保する方法を「データ一貫性」と呼びます。

1.2 リレーショナル データベースはどのようにしてデータの一貫性を確保するのでしょうか?

従来のリレーショナル データベースでは、動作環境とハードウェアに対する要件が比較的高くなっています。たとえば、Oracle では、データベースの動作環境としてミニコンピュータ + 共有ストレージを使用することを推奨しています。 DB2 DPF では、データベース運用環境を構築するために、より高性能なサーバーとハイエンドのストレージを使用することも推奨されています。したがって、データ ストレージ セキュリティの技術要件に基づき、従来のリレーショナル データベースは、データ セキュリティを確保するためにハードウェア テクノロジに大きく依存しています。

リレーショナル データベースのデータ セキュリティはハードウェアによって保証されており、複数のコピーを同時に保存してもデータ セキュリティは保証されないため、リレーショナル データベースのユーザーは、データ ストレージがデフォルトで一貫していると想定しています。

1.3 分散ストレージはどのようにしてデータの一貫性を確保するのでしょうか?

分散ストレージについて説明する場合、この記事では主に、SequoiaDB や HDFS などのビッグデータ製品の分散ファイルシステムと分散データベースについて言及します。

ユーザーが分散ストレージのデータ一貫性の原則を理解しようとする場合、まず、データ一貫性が必要な理由と、分散ストレージのデータ ストレージとリレーショナル データベースのデータ ストレージの違いを理解する必要があります。

ビッグデータ テクノロジーの誕生は、システム パフォーマンスに新たなブレークスルーをもたらし、ハードウェアの水平拡張をサポートして、パフォーマンスとストレージの直線的な成長を実現します。これらはすべて、従来のリレーショナル データベースではこれまで提供できなかったものです。さらに、ビッグデータ技術は、動作環境が十分に良好でなければならないという厳格な要件も放棄し、代わりに、安価な X86 サーバー + ローカル ディスクのバッチを通じて大規模なクラスターを構築できるようにし、ハードウェアの垂直拡張に依存することで、以前よりも強力なコンピューティング パワーとより多くのストレージ スペースを獲得します。

ビッグデータ技術の核となる考え方は分散であり、大きなタスクを複数の小さなタスクに分割し、分散同時操作を通じてそれらを完了することで、システム全体のコンピューティング効率やストレージ容量を向上させます。分散環境では、ハードウェア要件が低いため、ビッグデータ製品は、データ セキュリティという別の重要な機能を提供する必要があります。

ビッグデータ製品は、データセキュリティを解決する方法が比較的似ています。簡単に言えば、データのセキュリティを確保するために、データが複数のマシンに非同期または同期で保存されます。

データ セキュリティの技術的な困難は解決されましたが、分散ストレージでは、複数のコピーでデータの一貫性をどのように確保するかという新たな技術的問題が生じています。現在、SequoiaDB は Raft アルゴリズムを使用して、複数のコピーにおけるデータの一貫性を確保しています。

2. ラフトアルゴリズム

2.1 ラフトアルゴリズムの背景

分散環境では、最適なコンセンサス アルゴリズムは Paxos アルゴリズムであるはずですが、あまりにもわかりにくく実装が難しいため、2013 年に Diego Ongaro と John Ousterhout は、理解しやすさを目標としたコンセンサス アルゴリズム Raft を設計しました。 Raft アルゴリズムは理解しやすく、実装も簡単です。

2.2 ラフトアルゴリズムの概要

Paxos とは異なり、Raft は理解しやすさを重視しています。 Paxos と同様に、Raft は n/2+1 個のノードが正常である限りサービスを提供できます。

問題が複雑になると、いくつかの小さな問題に分割できることはよく知られています。 Raft も分割統治の概念を使用します。 Raft アルゴリズムは、リーダー選出、ログ複製、安全性という 3 つのサブ問題の解決に重点を置いています。

Raft アルゴリズムはリーダー ノードの機能を強化します。 Follower ノードのデータは Leader からのみ取得できるため、Follower ノードの実装が簡単になります。リーダーとの通信を維持し、リーダーによってプッシュされたデータを受け入れるだけで済みます。

2.3 ラフトアルゴリズムの原理

2.3.1 ノードの役割

Raft アルゴリズムでは、ノードのステータスはリーダー (***)、フォロワー、候補の 3 つの役割に分かれています。

リーダーは、クライアントからのリクエストの処理、フォロワーへのログの同期、フォロワーとのハートビート接続の確保を担当します。

フォロワー: クラスターが起動したばかりのときは、すべてのノードがフォロワー状態になります。主な仕事は、リーダーのログ同期要求に応答し、候補者の要求に応答し、フォロワーからリーダーへのトランザクション要求を転送することです。

リーダーを選出する際、候補者は投票する責任があります。リーダーが選出されると、ノードは候補状態からリーダー状態に変わります。

2.3.2 用語

分散環境において、「時間同期」は常に難しい技術的問題でした。この問題を解決するために、Raft は時間を Term (「論理時間」として理解できます) に分割し、異なる期間におけるデータの一貫性を処理します。

用語には以下の原則がある

• 各任期には最大1人のリーダーがいる
• ある意味、選挙の失敗によりリーダーが不在となる可能性もある。
• 各ノードは独自のローカルcurrentTermを維持する
• 各項は連続して増加する数字です。
• フォロワーのターム数が他のフォロワーのターム数よりも小さい場合、フォロワーのターム数は他のフォロワーのタームと一致するように更新されます。

2.3.3 選挙

Raft 選挙はタイマーによってトリガーされ、各ノードのトリガー時間は異なります。

最初はすべてのノードがフォロワー状態にあります。タイマーが選挙をトリガーすると、Term 番号が増加し、ノードの状態が Follower から Candidate に変わり、他のノードに対して RequestVote RPC 要求が開始されます。現時点では、選挙には 3 つの状況が考えられます。

RequestVote を開始したノードは、n/2+1 (半分以上) のノードから投票を受け取ります。ノードは候補状態からリーダー状態に変わり、リーダーの通常の状態を維持するために他のノードにハートビートを送信し始めます。

投票要求を受け取った後、ノードが投票を開始したノードの Term が自身の Term よりも大きいと判断した場合、ノードのステータスは候補からフォロワーに変更されます。それ以外の場合は、候補ステータスのままで、投票要求を拒否します。

選出中にタイムアウトが発生した場合、Term 番号が増加し、新しい選出が開始されます。

2.3.4 ログレプリケーション

ログレプリケーションの主な機能は、データの一貫性とノードの高可用性を確保することです。

リーダーが選出されると、すべてのトランザクション操作はリーダーによって処理される必要があります。これらのトランザクション操作が成功すると、順番に LOG に書き込まれます。各 LOG にはインデックス番号が含まれています。

ログが変更されると、リーダーは HeartBeat を通じて新しいログをフォロワーに同期します。 LOG を受信した後、フォロワーはリーダーに ACK メッセージを送信します。リーダーは、過半数 (2/n+1) のフォロワーから ACK 情報を受信すると、ログをコミット済みとして設定し、ログをローカル ディスクに追加します。

同時に、リーダーはすべてのフォロワーに、次のハートビートでログをそれぞれのローカル ディスクに保存するように通知します。

2.3.5 セキュリティ

安全性は、各ノードが同じログ シーケンスに従って実行されることを保証するために使用される安全メカニズムです。

フォロワーがリーダーのログを同期できなかったが、将来リーダーとして選出された場合、以前のリーダーによってコミットされたログが上書きされ、ノードが異なる順序でログを実行する可能性があります。

Raft のセキュリティは、選出されたリーダーが以前にコミットされた LOG を必ず含むようにするためのメカニズムです。従うべき主な原則は次のとおりです。

任期ごとに選出できるリーダーは 1 人だけです。

リーダー ログの整合性: 候補者がリーダーを再選する場合、新しいリーダーは以前にコミットしたログを含める必要があります。

候補者が新しいリーダーを選出する場合、Term を使用して LOG の整合性を確保します。

3. 分散データベースデータ一貫性技術の実装

国内分散データベース SequoiaDB を例にとると、SequoiaDB はマルチコピー展開で Raft アルゴリズムを使用して、マルチコピー環境でデータの一貫性が維持されるようにします。

SequoiaDB クラスターには、コーディネーション ノード、カタログ ノード、データ ノードの 3 種類のノードが含まれています。コーディネータ ノード自体はデータを保存しないため、カタログ ノードとデータ ノードのみがトランザクション操作を実行します。つまり、カタログ パーティション グループとデータ パーティション グループのレプリカ同期では、Raft アルゴリズムを使用してデータの一貫性が確保されます。

3.1 カタログノードとデータノードのトランザクションログの概要

カタログノードとデータノードの両方にデータを保存する必要があり、クラスター展開では、データのセキュリティを確保するために、分散方式で展開することをお勧めします。したがって、データ同期では、Raft アルゴリズムの基本原理をデータ同期に使用する必要があります。

データを保存する場合、カタログ ノードとデータ ノードには 2 つの主要部分が含まれます。1 つは実際のデータ ファイルで、もう 1 つはトランザクション ログ ファイルです。

デフォルトでは、SequoiaDB ノードのトランザクション ログは 64 MB のファイル 20 個 (合計サイズ 1.25 GB) で構成されます。ノードのトランザクション ログには主にインデックス番号とデータ操作内容が含まれており、インデックス番号は永久に増加し続けます。

また、SequoiaDB ノードのトランザクション ログは永続的に保存されません。代わりに、すべてのトランザクション ログがいっぱいになると、最初のファイルから再度上書きされます。

3.2 カタログパーティショングループのデータ一貫性

カタログ パーティション グループには SequoiaDB クラスターのメタデータが格納され、高いデータ同期要件があるため、カタログ パーティション グループのデータ一貫性要件は強力な一貫性です。つまり、カタログ パーティション グループに対してトランザクション操作が実行されるたびに、操作が成功したと見なされる前に、すべてのカタログ ノード操作が成功していることを確認する必要があります。それ以外の場合、トランザクション操作は、カタログ パーティション グループ全体のトランザクション ログをロールバックし、パーティション グループ内のデータの一貫性を確保します。

さらに、カタログ パーティション グループには別の重要な機能があります。カタログ パーティション グループが適切に機能するには、マスター ノードが必要です。古いマスター ノードがダウンし、カタログ パーティション グループに一時的にマスター ノードが存在しない場合、カタログ パーティション グループは外部に対してトランザクション操作やデータ クエリ操作を提供できません。

3.3 データパーティショングループのデータ一貫性

データ パーティション グループのデータ一貫性は、デフォルトでは最終的な一貫性です。つまり、マスター ノードがトランザクションを正常に実行した場合にのみ、操作は成功したと見なされます。将来、マスターノードは ReplicaLOG をスレーブノードに非同期的に同期します。

3.4 マスターノードとスレーブノード間のトランザクションログの同期

SequoiaDB のマスター ノードとスレーブ ノードは、トランザクション ログの同期を通じてデータの一貫性を確保し、マスター ノードとスレーブ ノードのトランザクション ログの同期は 1 つのスレッドで完了します。

マスター ノードとスレーブ ノード間の LSN の差が 1 レコードの場合、マスター ノードは最新のトランザクション ログをスレーブ ノードにアクティブにプッシュします。

マスター ノードとスレーブ ノード間の LSN の差が 1 レコードを超える場合、スレーブ ノードはマスター ノードにトランザクション ログの同期を積極的に要求します。マスターノードは、同期要求を受信すると、スレーブノードの LSN 番号に対応するトランザクションログをマスターノードの最新の LSN 番号にパッケージ化し、一度にスレーブノードに送信します。

3.5 スレーブノードのログを再生する

スレーブ ノードは、マスター ノードによってプッシュされたトランザクション ログを取得すると、自動的にトランザクション ログを解析して再生します。スレーブ ノードがトランザクション ログを再生する場合、デフォルトでは同時実行数 10 でトランザクション ログを再生します。

同時ログ再生を実行する場合、スレーブ ノードには条件付きの制限があります。つまり、コレクション内の一意のインデックスの数が 1 以下の場合、INSERT、DELETE、UPDATE、LOB WRITE、LOBUPDATE、および LOB REMOVE 操作は、トランザクション ログの同時再生をサポートできます。スレーブ ノードが同時再生を実行する場合、記録された OID によって同時実行を分割し、同じレコードに対する操作によって同時再生によるデータの不整合が発生しないようにします。

ただし、スレーブ ノードがトランザクション ログを再生している場合、DROP CL 操作は同時再生をサポートできないことに注意する必要があります。

4. SequoiaDB データ整合性アプリケーション

現在、SequoiaDB データ パーティション グループのデータ一貫性はコレクション レベルで構成されています。 SequoiaDB を使用する場合、ユーザーはいつでもデータ一貫性の強さを調整できます。

4.1 コレクションを作成するときに指定する

マルチレプリカ SequoiaDB クラスターでは、コレクションのデフォルトのデータ整合性レベルは「最終的な整合性」です。コレクションを作成するときに、コレクションの「データ一貫性の強度」を明示的に指定できます。たとえば、SequoiaDB Shell で次のコマンドを実行できます。

db.CSNAME.createCL("CLNAME",{ReplSize:3})

ReplSizeパラメータの入力範囲

4.2 既存のコレクションの変更

コレクションの作成時に「データ整合性」ReplSize パラメータが設定されていない場合、ユーザーは既存のコレクションを変更することもできます。 SequoiaDB Shellの変更コマンドは次のとおりです。

db.CSNAME.CLNAME.alter({ReplSize:3})

ReplSize の値の範囲は、コレクションを作成するときと同じです。

4.3 コレクションのReplSizeパラメータを表示する方法

ユーザーが現在のコレクションの RepliSize パラメータ値を確認したい場合は、データベース スナップショットを通じてそれを表示できます。 SequoiaDB Shellで表示するコマンドは次のとおりです。

 db.snapshot(SDB_SNAP_CATALOG,{}, { "名前" : null 、 "IsMainCL" : null 、 "MainCLName" : null 、 "ReplSize" : null })

印刷情報は以下の通りです

{ 
 
 "MainCLName" : "test.main2" 、 
 
 「名前」 : 「foo.bar2」 、 
 
 "IsMainCL" : null 、 
 
 「ReplSize」 : null   
 
 } 
 
 { 
 
 "IsMainCL" : true 、 
 
 「名前」 : 「test.main2」 、 
 
 "MainCLName" : null 、 
 
 「ReplSize」 : null   
 
 } 
 
 { 
 
 「名前」 : 「foo.tt」 、 
 
 「ReplSize」 : 3, 
 
 "IsMainCL" : null 、 
 
 "MainCLName" : null   
 
 }

5. 結論

分散データベースは、分散状況でのデータの一貫性を確保するために Raft アルゴリズムを使用します。カタログ パーティション グループとデータ パーティション グループでは、データの一貫性に関する要件が異なります。カタログ パーティション グループでは常に複数のコピーで強力なデータ一貫性が求められますが、データ パーティション グループはコレクションの作成時にユーザーが強制できます。強度が高ければ高いほど、データのセキュリティは向上しますが、実行効率は相対的に低下します。逆もまた同様です。

現在、SequoiaDB は、データ一貫性シナリオにおいてユーザーに多くの調整の余地を提供しています。ユーザーは、さまざまなビジネス要件に応じてデータ一貫性の強度を調整し、ビジネスを満たしたり、最適なパフォーマンスや最も安全なデータ技術要件を追求したりすることができます。