データ レプリケーションはデータベースをどのように最適化しますか? - システム設計09

システム設計-システム設計 09-データ レプリケーション-データ レプリケーション-データベースの基礎-ホーガンテック-ホーガンブラブ

序文

データ量が増加し、データベースの読み取りおよび書き込みトラフィックが増加すると、従来のデータベースに共通するボトルネックが現れ始めます。データ レプリケーションは、複数のノードにデータを複製することでボトルネックを解決し、データベースのパフォーマンス、スケーラビリティ、可用性を向上させる効果的な方法です。この記事では、マスター/スレーブ レプリケーション (シングル リーダー レプリケーション)、マルチ リーダー レプリケーション (マルチ リーダー レプリケーション)、およびポイントツーポイント レプリケーション (リーダーレス レプリケーション) というデータ レプリケーションの 3 つの主要なモデルを紹介し、それぞれの利点と分析を説明します。デメリット。

データベースの基本知識に詳しくない読者は、この記事を参照してください。 データベースの基礎入門 – システム設計 08。スケーラビリティと使いやすさに詳しくない読者は、この記事も参照してください。 ソフトウェア設計の非機能的特徴 – システム設計 03

データコピー(データ レプリケーション)

データ レプリケーションは、主に次の目的を達成するために、データのコピーを複数のノードに保持するテクノロジーです。

  • パフォーマンスの向上: データを複数のノードに分散することで、データベースの読み取りおよび書き込みのパフォーマンスを向上させることができます。
  •  スケーラビリティの向上: データ量が増加した場合、ノードを追加することでデータベースを拡張できます。
  • 可用性の向上: 1 つのノードに障害が発生しても、他のノードは引き続きデータ サービスを提供できます。

データ レプリケーションは、次のような多くのアプリケーションで使用されます。

  • オンライン トランザクション処理 (OLTP): OLTP システムでは、データ レプリケーションを使用してデータベースのパフォーマンスと可用性を向上させ、高同時実行 (高同時実行) 読み取りおよび書き込みのニーズを満たすことができます。
  • 災害復旧: 警告のない災害が発生した場合、データ レプリケーションを使用してデータをオフサイト バックアップにコピーし、データ損失を防ぐことができます。

クローン(レプリケーション)

レプリケーションとは、各ノード、できれば地理的に異なるノード (異なる国のデータベースのバックアップなど) に複数のデータ バックアップを保持することを指します。これらのデータは、可用性、拡張性、パフォーマンスを実現するために複製されます。

読者は、単一のデータベースの場合、データベースが損傷するとシステム全体が影響を受けるというシナリオを考えることができます。逆に、異なるデータベースにコピーされたデータが複数存在する場合は、1 つのデータベースが破損してもシステム全体には影響しません。

ただし、上記はすべてデータ レプリケーションの利点ですが、データ レプリケーションには複雑さも伴います。以下に、複雑さの簡単な例を示します。

  1. 複数のデータを相互に一貫性を保つにはどうすればよいでしょうか?
  2. 同期レプリケーションと非同期レプリケーションのどちらを使用するべきですか?
  3. 同時書き込みをどのように処理するか?

この記事では、同期レプリケーションと非同期レプリケーションの説明から始めて、データ レプリケーションについて詳しく説明します。

同期レプリケーションと非同期レプリケーション

レプリケーションを実装する場合、同期レプリケーションと非同期レプリケーションの2種類に分けられます。

2 つの主な違いは何ですか?

同期レプリケーションでは、プライマリ ノード (リーダー ノード) は、セカンダリ ノード (フォロワー ノード) からのデータ更新の確認要求を待ちます。マスター ノードはすべてのセカンダリ ノードから確認を受信すると、クライアント (クライアント側) に確認成功を報告します。非同期レプリケーションでは、プライマリ ノードはセカンダリ ノードからの確認を待たずに、データを直接更新し、成功をクライアントに報告します。

同期の長所と短所 同期の長所と短所

同期レプリケーションの利点は、すべてのセカンダリ ノード (フォロワー ノード) がプライマリ ノード (リーダー ノード) と完全に同期されることです。ただし、利点には欠点も伴います。障害などの理由でセカンダリ ノード (フォロワー ノード) が確認を行わなかった場合、マスター ノードは成功した確認を受信するまでユーザーに応答できません。したがって、このような欠点により、マスター ノードからクライアントへの応答の遅延 (High Latency) が長くなります。

非同期の長所と短所

非同期レプリケーションの利点は、すべてのセカンダリ ノード (フォロワー ノード) がダウンした場合でも、プライマリ ノード (リーダー ノード) が動作し続けられることです。逆の欠点は、プライマリ ノードに障害が発生した場合、セカンダリ ノードに複製されなかった書き込みが失われることです。

これは、データベースのバイブルである「データ集約型アプリケーションの設計」からの図です。リーダーがプライマリ ノードであり、フォロワーが補助ノードです。

システム設計-システム設計09-データレプリケーション-データレプリケーション-データベースの基礎-hogantech-hoganblab01

データ複製モデル

次に、次のデータベースからコピーしたモデルの長所と短所を比較します。

シングルリーダー / プライマリ-セカンダリレプリケーション

マスター/スレーブ レプリケーションでは、1 つのノードがマスター ノードとして指定されます。プライマリ ノードは書き込みを処理し、すべての書き込みをセカンダリ ノードに送信して同期を保ちます。

マスター/スレーブ レプリケーションは、読み取り負荷が大きい場合に非常に適しています。たとえば、Youtube には常にビデオを視聴する必要がある人が何千人もいますが、ビデオの視聴に比べて、アップロードされたビデオの量はそれほど多くないため、マスター-スレーブ レプリケーションは非常に適しています。スレーブ レプリケーション このモデルは、このような状況に適しています。このモデルを使用して、ユーザー数の増加に応じてデータベースを拡張し、システムのスケーラビリティを向上させることもできます。もちろん、データが多数のセカンダリ ノードにレプリケートされる場合にもボトルネックが発生する可能性があります。最後に、書き込み負荷が大きい場合、マスター/スレーブ レプリケーションは適切ではありません。

マスター/スレーブ レプリケーションのもう 1 つの利点は、読み取り復元力が高いことです。たとえば、プライマリ ノードに障害が発生した場合でも、セカンダリ ノードは引き続き読み取りリクエストを処理できるため、読み取りボリュームが大量のシステムに適しています。データベース モデルの優れたソリューション。

さらに、非同期レプリケーションを使用すると、データ レプリケーションの一貫性が失われるという問題が発生します。プライマリ ノードに障害が発生し、更新されたデータをセカンダリ ノードに配信できない場合、異なるデータベースから読み取られたデータに一貫性のないデータが表示される可能性がある状況を想像できます。したがって、プライマリ ノードに障害が発生した場合、セカンダリ ノードがまだデータ レプリケーションの更新を受信して応答していない場合は、データ レプリケーションの更新が失われる可能性があります。

システム設計-システム設計09-データレプリケーション-データレプリケーション-データベースの基礎-hogantech-hoganblab02

プライマリ-セカンダリのレプリケーション方法

マスター/スレーブ レプリケーションはさまざまな方法で実装できます。

ステートメントベースのレプリケーション

SBR は MySQL データベースで使用される方式であり、繁体字中国語への翻訳が実際に見つからないため、今後はステートメントベースのレプリケーションを (SBR) と呼びます。この実装では、マスター ノードは INSERT、UPDATE、DELETE などの SQL 構文を実行し、これらの構文をログ ファイルに書き込むことができます。次に、ログ ファイルは実行のためにセカンダリ ノードに送信されます。

SBR はプライマリ ノードからセカンダリ ノードへのデータのコピーの問題を解決できますが、実際には欠点があります。たとえば、非決定的関数を使用すると、プライマリ ノードとセカンダリ ノードでの書き込みが異なる可能性があります。

非決定性関数とは何ですか?たとえば、NOW() は現在時刻を取得し、RAND() は乱数を取得します。これらはすべて不確実な関数であり、関数が実行されるたびに異なる結果が得られます。

先行書き込みログ (先行書き込みログ)

以下では、先行書き込みログを (WAL) と呼びます。 WAL は、PostgreSQL および Oracle で使用されるデータ レプリケーション テクノロジです。 WAL では、トランザクションが発生すると、最初にトランザクション ログ ファイルに記録され、その後データベースに書き込まれます。次に、ログ操作がプライマリ データベースで実行され、実行のためにセカンダリ ノードに転送されます。

SBR とは異なり、WAL は SQL 構文の代わりにトランザクション ログを処理します。これには、非決定的関数が発生した場合に一貫性を確保できるという利点があります。さらに、WAL は、障害発生時の回復を容易にするために、データをディスクに直接書き込みます。

例: PostgreSQL で UPDATE などの操作を実行する場合、データベースを処理する前に、まずトランザクション ログ ファイルとディスクが書き込まれます。トランザクション ログにはトランザクション ID、データ型、影響を受ける表が含まれており、変更は補助ノードにコピーされます。

もちろん、長所と短所があります。WAL の短所は、プライマリ ノードとセカンダリ ノードのソフトウェアをアップグレードする必要がある場合に、データベースの内部構造が複雑になることです。

論理コピー(論理レプリケーション)

論理コピー(論理レプリケーション) これを行ベース (行ベース) レプリケーションと呼ぶ人もいます。この方法は、PostgreSQL や MySQL などのさまざまなリレーショナル データベースで使用されます。この方法では、データベースに対して行われた操作と変更が記録され、セカンダリ ノードにコピーされます。

たとえば、INSERT や UPDATE などの操作が実行されると、影響を受ける Row 全体がプライマリ ノードで取得されます。これには、指定された Row のすべての列値が含まれます。フェッチされた変更はセカンダリ ノードで実行され、データがプライマリ ノード上のデータと一貫していることが確認されます。

マルチリーダーの複製

以前にマスター/スレーブ レプリケーションを導入した後、非同期レプリケーションを使用したマスター/スレーブ レプリケーションには致命的な欠点があることにも気づくはずです。マスター ノードが 1 つしかない場合、すべての書き込み操作はそのノードを経由する必要があるため、パフォーマンスが大幅に低下します。プライマリ ノードに障害が発生した場合、セカンダリ ノードはデータベースを更新できない可能性があります。

マルチリーダー レプリケーションは、このような同時実行性の高いシステムの問題を解決するために使用できるもう 1 つのモデルです。マルチリーダー レプリケーションは、その名前が示すように、複数のプライマリ ノードが書き込みを処理し、レプリケーションのために書き込みを他のプライマリ ノードとセカンダリ ノードに送信します。

このレプリケーション モデルは、オフラインで動作を継続できるシステムにとって非常に有利です。複数のデータセンターを保守および運用する場合にもこのモデルを使用して、各データセンターにマスター ノードを持たせることができます。

システム設計-システム設計09-データレプリケーション-データレプリケーション-データベースの基礎-hogantech-hoganblab03

対立

マルチリーダー レプリケーションは、シングル リーダー レプリケーションよりも優れたパフォーマンスとスケーラビリティを提供しますが、このモデルには欠点もあります。すべてのマスター ノードが同時に書き込み要求を処理する可能性があるため、同じデータを変更する可能性があります。この状況は競合と呼ばれます。

例: 2 人のユーザーが同じデータ フィールドを同時に編集するとします。この場合、状況をさらに処理することなく、最終データの正確さを知る方法はありません。競合を処理する一般的な方法をいくつか示します。

紛争を避ける

非常に単純な考えですが、紛争に対処するつもりなら、最初から紛争が起こらないようにする必要があります。特定のレコードへのすべての書き込みが同じマスター ノードを経由することをシステムが保証できる場合、競合の問題は発生しません。クライアントのリクエストを同じデータセンターに送信できるため、異なるデータセンターにいる 2 人のユーザーが同じドキュメントを変更することはありません。

ただし、ユーザーが別の場所に移動し、別のデータセンターの近くにいる場合でも、競合は発生します。この問題が発生した場合は、要求されたトラフィックを再処理する必要があります。この場合、競合回避方法は失敗し、同時書き込みが発生します。

最後の書き込みが優先されます

すべてのノードは、ノード独自の現地時間を使用して、各更新にタイムスタンプ (タイムスタンプ) を割り当てます。競合が発生した場合、最新のタイムスタンプが更新用に選択されます。ただし、この方法には盲点もあります。分散システムではノード間の時間が異なる可能性があり、時刻同期を達成することが困難になるためです。また、時刻が異なる可能性があるため、時刻のずれによりデータが失われる可能性があります。

マルチリーダーレプリケーショントポロジ (Topology)

以下は、リング トポロジ、スター トポロジ、全対全トポロジなどのマルチ リーダー レプリケーションのトポロジです。最も一般的なのは、全対全トポロジです。スター型トポロジとサークル型トポロジにも同様の欠点があり、いずれかのノードに障害が発生すると、システム全体に影響を及ぼす可能性があります。これが、all-to-all が最も一般的に使用されるトポロジである理由です。

システム設計-システム設計09-データレプリケーション-データレプリケーション-データベースの基礎-hogantech-hoganblab04

ピアツーピア/リーダーレスレプリケーション

マスター/スレーブ レプリケーションでは、マスター ノードで問題が発生すると、データベース障害が発生します。マルチリーダー レプリケーションに加えて、ピアツーピア レプリケーションという別のモデルもあります。これもシステムとデータベースの読み取りスケーラビリティの実現に役立ちますが、書き込みスケーラビリティは提供できません。つまり、高トラフィック読み取りに対するスケーラビリティを提供できます。

ポイントツーポイント レプリケーション モデルは、非プライマリ ノードを通じてこれらの問題を解決します。すべてのノードは同じ重みを持ち、読み取りおよび書き込みリクエストを受け入れることができます。 Cassandra は、このデータベース レプリケーション モデルを使用します。

マスター/スレーブ レプリケーションと同様、このタイプのレプリケーションでも、複数のノードが書き込みリクエストを受け入れると同時書き込みが発生する可能性があるため、不整合が発生する可能性があります。

システム設計-システム設計09-データレプリケーション-データレプリケーション-データベースの基礎-hogantech-hoganblab05

結語

データベース レプリケーションはデータベースのボトルネックを解決する効果的な方法であり、データベースのパフォーマンス、スケーラビリティ、可用性を向上させることができます。ただし、レプリケーション モデルが異なれば長所と短所も異なるため、レプリケーション モデルを選択する場合は、特定のニーズに基づいてトレードオフを比較検討する必要があります。システム設計コンテンツが好きな読者は、他の関連記事を参照してください。

関連記事

データベースの基礎入門 – システム設計 08

ロードバランサの解説 – システム設計 07

DNSとは何ですか?ドメインネームシステム入門 – システム設計 06

システム設計コンポーネントの構成要素の概要 – システム設計 05

封筒の裏の計算 – システム設計 04

ソフトウェア設計の非機能的特徴 – システム設計 03

システム設計における抽象化の適用 – システム設計 02

最新のシステム設計入門 – システム設計 01

引用

データ集約型アプリケーションの設計

データベースレプリケーションとは何ですか?

 

投稿メッセージ

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

ja日本語