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

序文

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

非同期の長所と短所

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

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

データ複製モデル

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

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

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

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

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

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

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

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

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

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 つのモデルです。マルチリーダーレプリケーションは、その名前が示すように、複数のプライマリノードが書き込みを処理し、レプリケーションのために書き込みを他のプライマリノードとセカンダリノードに送信します。

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

対立

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

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

紛争を避ける

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

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

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

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

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

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

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

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

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

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

結語

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

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

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

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

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

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

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

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

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