大規模な Web サイトにおける mysql アプリケーション アーキテクチャの進化

この記事では主に、Web サイトのさまざまな同時アクセス レベルにおける Mysql アーキテクチャの進化について説明します

スケーラビリティ

アーキテクチャのスケーラビリティは、多くの場合、同時実行性と密接に関係しています。同時実行性が向上しない限り、高度にスケーラブルである必要はありません。従来のアーキテクチャに基づいて、スケーラビリティについて簡単に説明します。 スケールアップ: より優れたマシンとリソースに置き換えることにより、スケーリングを実現し、サービス機能を向上させます。 スケールアウト: 水平方向の拡張。 、ノード (マシン) を追加することでスケーリングを実現し、サービス機能を向上させます

インターネット上の同時実行性の高いアプリケーションの場合、ハイエンド マシンを垂直に購入することは間違いなく解決策です。問題は次のとおりです。長期的な解決策ではありません。スケールアウト理論では、スケーラビリティの理想的な状態はどのようなものでしょうか?

スケーラビリティの理想的な状態

サービスがより高い同時実行性に直面した場合、単にマシンを追加するだけでサービスがサポートする同時実行性を向上させることができ、マシンを追加するプロセスはオンラインサービスに影響を与えません（ダウンタイムなし）） 、これがスケーラビリティの理想的な状態です。

アーキテクチャの進化

V1.0 シンプルな Web サイト アーキテクチャ

シンプルな小さな Web サイトやアプリケーションの背後にあるアーキテクチャは、データの読み取りと書き込みのニーズを満たすために、データ ストレージに必要な mysql インスタンスが 1 つだけで非常にシンプルになります (ここでは無視されます)。データ バックアップ インスタンス)、この期間の Web サイトは通常、すべての情報をデータベース インスタンスに保存します。

このアーキテクチャの下で、データ ストレージのボトルネックは何なのかを見てみましょう。

1. データの合計サイズが 1 台のマシンに収まりきらない 2. データのインデックス (B+ Tree) が 1 台のマシンのメモリに収まらない

3. アクセス量 (混合読み取り)および書き込み）は、1 つのインスタンスでは許容できません

上記 3 つの項目のいずれか 1 つ以上が満たされた場合にのみ、次のレベルへの進化を検討する必要があります。 このことから、実際、多くの中小企業や小規模アプリケーションにとって、初期データ量の正確な評価は、過剰設計を防ぐための重要なステップであることがわかります。不可能なことを心配して、経験を無駄にしてください。

これは私の簡単な例です。ユーザー情報などのテーブル（3つのインデックス）の場合、16Gのメモリは約2000万行のデータのインデックスを保持できます。単純な読み取りと書き込みの混合アクセス量は約3000/秒です。問題は、アプリケーションのシナリオです

V2.0の垂直分割

一般に、V1.0がボトルネックに遭遇した場合、最初の最も簡単な分割方法は垂直分割です。ビジネスの観点から見ると、ボトルネックを排除するという目標を達成するために、関連性の低いデータはさまざまなインスタンスに分割されます。図の例では、ユーザー情報データと業務データが 3 つの異なるインスタンスに分割されています。繰り返し読み取りタイプが多数あるシナリオでは、キャッシュ層を追加して DB への負荷を軽減することもできます。

このアーキテクチャの下で、データ ストレージのボトルネックは何なのかを見てみましょう。

1. 単一インスタンスの単一ビジネスには、V1.0 で説明したボトルネックが依然として存在します

ボトルネックが発生した場合は、この記事の上位の V バージョンにアップグレードすることを検討できます。読み取りリクエストがパフォーマンスのボトルネックを引き起こす場合は、V3 へのアップグレードを検討できます。 0. 他のボトルネックを考慮する必要があります V4.0 にアップグレード

V3.0 マスタースレーブアーキテクチャ

このタイプのアーキテクチャは、主に V2.0 アーキテクチャでの読み取りの問題を解決します。Mysql シナリオでは、リアルタイムのデータバックアップをアタッチすることで読み取り圧力を移行します。マスター/スレーブ構造。マスター ライブラリは書き込み圧力に耐え、スレーブ ライブラリを通じて読み取り圧力を共有します。このような状況下では、V3.0 マスター/スレーブ アーキテクチャが完全に機能します。アーキテクチャ、データ ストレージのボトルネックを見てみましょう。それは何ですか?

1. メインライブラリが書き込み量に耐えられない

V4.0 水平分割

V2.0 V3.0 ソリューションがボトルネックに遭遇した場合、水平分割、水平分割、垂直分割によって解決できます。大きな違いは、垂直分割の結果、1 つのインスタンスには全量のデータが含まれることになりますが、水平分割後は、どのインスタンスにも全量のデータが 1/n しか含まれないことになります。次の図は、例として Userinfo の分割を示しています。ユーザー情報を 3 つのクラスターに分割します。各クラスターには、合計データの 1/3 が保持されます。3 つのクラスター データの合計は、完全なデータに相当します (注: これは、単一インスタンスではなく、メイン データを表すクラスターと呼ばれます)。 )。小さな mysql クラスターから)

データはどのようにルーティングされますか?

1.範囲分割

シャーディングキーは、連続間隔セグメントに従ってルーティングされます。通常、Userid など、厳密な自動インクリメント ID 要件を持つシナリオで使用されます。Userid Range の小さな例: ユーザー ID 3000W を範囲番号として使用する分割。 . 1 クラスターのユーザー ID 1-3000W クラスター 2 番のユーザー ID 3001W-6000W

2.リスト分割

リスト分割は範囲分割と同じ考え方で、どちらも異なるシャーディング キーを与えることで異なるクラスターにルーティングされますが、具体的な方法は若干異なります。異なる、リストは主にシャーディングキーが連続したシーケンスではなく、クラスターに分類される状況で使用されます