MySQL テーブルとデータベース シャーディングのアプリケーション シナリオと設計方法

多くの友人がフォーラムやメッセージエリアで、どのような状況で MySQL をシャーディングする必要があるのか​​、またどのような設計方法が最善の選択なのかを尋ねてきました。これらの質問に基づいて、編集者は MySQL シャーディングの最適な設計方法のいくつかのアプリケーションシナリオと例をまとめました。

1. サブテーブル

シナリオ: 大規模なインターネット アプリケーションの場合、単一のデータベース テーブル内のレコード行の数は数千万、あるいは数億に達することがあり、データベースは極めて高い同時アクセスに直面します。マスタースレーブレプリケーションモードを使用したMySQLアーキテクチャ、

データベースの書き込み操作は依然としてマスターに集中しており、データベースの読み取りのみを拡張できます。また、1 つのマスターに無制限の数のスレーブをマウントすることはできません。スレーブの数は、マスターの能力と負荷によって制限されます。

したがって、高い同時アクセスと大量のデータストレージのニーズを満たすには、データベースのスループット容量をさらに拡張する必要があります。

アクセス頻度が高く、データ量が膨大な単一のテーブルの場合、まず最初に行う必要があるのは、データクエリに必要な時間を短縮し、データベースのスループットを向上させるために、単一のテーブル内のレコード数を減らすことです。これがいわゆるテーブルシャーディングです。

テーブルをシャーディングする前に、通常のクエリに影響を与えずにデータが複数のテーブルに均等に分散されるように、適切なシャーディング戦略を選択する必要があります。

インターネット企業の場合、ほとんどのデータはユーザーに関連付けられているため、ユーザー ID が最もよく使用されるサブテーブル フィールドです。ほとんどのクエリではユーザー ID を使用する必要があるため、クエリには影響せず、データのバランスをより良くすることができます。

次の図に示すように、各テーブルに分散されます (もちろん、シナリオによっては、ホット データとコールド データの分散が不均衡になる場合があります)。

ユーザーの購入情報を記録する注文テーブルがあるとします。注文テーブルにはレコードが多すぎるため、256 個のテーブルに分割されます。

分割されたレコードは、user_id%256 に従って対応するテーブルに格納され、フロントエンド アプリケーションは対応する注文格納テーブルを見つけて、対応する user_id%256 に従ってアクセスします。

このように、user_id は必要なクエリ条件になります。そうでない場合、データが格納されているテーブルが見つからないため、データにアクセスできません。

注: 分割後のテーブル数は通常 2 の n 乗です。これが、上記で 256 個のテーブルに分割されている理由です。

注文テーブルの構造が次のようになっていると仮定します。

テーブル order_ を作成します( 
 order_id bigint(20) 主キー auto_increment, 
 ユーザーID ビッグイント(20) 
 ユーザーニックネームvarchar(50), 
 オークションID bigint(20), 
 オークションタイトル bigint(20), 
 価格 ビッグイント(20) 
 オークション_cat varchar(200)、 
 販売者ID bigint(20) 
 seller_nick varchar(50) 
）

テーブルが分割された後、user_id = 257、auction_id = 100 と仮定すると、auction_id に基づいて対応する注文情報を照会する必要があります。対応する SQL ステートメントは次のとおりです。

user_id=257、auction_id=100の場合、order_1から*を選択します。

このうち、order_1は257%256に基づいて計算され、パーティション後の最初の順序テーブルを意味します。

2. データベース部門

シナリオ: テーブル シャーディングは、単一テーブル内のデータ量が多すぎるためにクエリ効率が低下するという問題を解決できますが、データベースの同時処理能力の質的な向上をもたらすことはできません。同時読み取りおよび書き込みアクセスが多い場合、データベースマスターが

サーバーが書き込み操作の負荷に耐えられない場合、スレーブ サーバーをどのように拡張しても意味がありません。

したがって、考え方を変えてデータベースを分割し、データベースの書き込み機能を向上させる必要があります。これがいわゆるデータベース パーティショニングです。

テーブル シャーディング戦略と同様に、データベース シャーディングでは、次の図に示すように、キーワード モジュロ メソッドを使用してデータ アクセスをルーティングできます。

引き続き前の order テーブルを使用し、user_id フィールドの値が 258 であると仮定すると、元の単一のデータベースは 256 個のデータベースに分割され、アプリケーションのデータベースへのアクセス要求は 2 番目のデータベースにルーティングされます (258%256 = 2)。

3. サブライブラリとサブテーブル

シナリオ: データベースは、同時アクセスの負荷が高く、大量のデータを保存する必要に迫られる場合があります。この場合、システムを同時に拡張するには、データベースに対してテーブル シャーディング戦略とライブラリ シャーディング戦略の両方を採用する必要があります。

同時処理機能と単一テーブルのクエリ パフォーマンスの向上、これをシャーディングと呼びます。

シャーディングの戦略は、以前のシャーディングのみの戦略やシャーディングのみの戦略よりも複雑です。シャーディングのルーティング戦略は次のとおりです。

1. 中間変数 = user_id % (サブデータベースの数 * 各データベース内のテーブルの数)

2. ライブラリ = 整数（中間変数 / 各ライブラリ内のテーブル数）

3. テーブル = 中間変数 % 各ライブラリのテーブル数

また、user_idをルーティングフィールドとして使用します。まず、user_idを使用して、ライブラリの数*各ライブラリテーブルの数を法として中間変数を取得します。次に、中間変数を各ライブラリテーブルの数で割り、切り上げて、

対応するライブラリ。中間変数を各ライブラリテーブルの番号で割ったもの、つまり対応するテーブルが取得されます。

データベースとテーブルのシャーディング戦略の詳細なプロセスは次のとおりです。

元の単一データベース単一テーブルの注文が 256 個のライブラリに分割され、各ライブラリに 1024 個のテーブルが含まれていると仮定します。この場合、前述のルーティング戦略に従って、user_id=262145 のアクセスに対するルーティング計算プロセスは次のようになります。

1. 中間変数 = 262145 % (256 * 1024) = 1

2. ライブラリ = 丸め (1/1024) = 0

3. 表 = 1 % 1024 = 1

これは、user_id=262145 の注文レコードのクエリと変更が、0 番目のデータベースの最初の order_1 テーブルにルーティングされて実行されることを意味します。 ！ ！