データベースとテーブルに分割された MYSQL データベース データの概要_MySQL

データストレージの進化のアイデア 1: 単一データベースと単一テーブル

単一データベースと単一テーブルは最も一般的なデータベース設計です。たとえば、データベース db にユーザー テーブルがあり、すべてのユーザーは db データベースのユーザー テーブルで見つかります。

データストレージの進化のアイデア 2: 複数のテーブルを持つ単一データベース

ユーザー数が増加すると、ユーザーテーブルのデータ量が増加し、データ量が一定のレベルに達すると、ユーザーテーブルのクエリが徐々に遅くなり、DB全体のパフォーマンスに影響を与えます。 mysql を使用する場合、より深刻な問題は、カラムを追加する必要があるときに、mysql がテーブルをロックし、その間、すべての読み取りおよび書き込み操作が待機することしかできないことです。

ユーザーを何らかの方法で水平に分割して、user_0000、user_0001 など、まったく同じ構造を持つ 2 つのテーブルを生成できます。user_0000 + user_0001 + ... のデータは、完全なデータ セットにすぎません。

データストレージの進化のアイデア 3: 複数のデータベースと複数のテーブル

データ量が増加すると、単一の DB の記憶容量が不足する可能性があり、クエリの量が増加すると、単一のデータベース サーバーではそれをサポートできなくなります。このとき、データベースを水平方向に差別化することができます。

Mysql データベースのシャーディング ルール

テーブルを設計するときは、テーブルをデータベースとテーブルに分割するルールを決定する必要があります。たとえば、新しいユーザーがいる場合、プログラムはユーザー情報をどのテーブルに追加するかを決定する必要があります。同様に、ログイン時には、ユーザーのアカウントを通じてデータベース内の対応するレコードを検索する必要があり、そのすべてが特定の条件に従う必要があります。ルール。
ルーティング

shardingおよびシャードルールを介して対応するテーブルとライブラリを見つけるプロセス。たとえば、データベースとテーブルのシャーディングのルールは user_id mod 4 です。ユーザーがアカウント ID 123 で新しいアカウントを登録する場合、id mod 4 を使用して、このアカウントを User_0003 テーブルに保存する必要があることを決定できます。ユーザー 123 がログインすると、123 mod 4 が渡され、User_0003 に記録されていることがわかります。

サブデータベース、サブテーブルによって発生する問題とその注意点は以下の通りです

1. サブデータベースとサブテーブルのディメンションの問題

ユーザーが商品を購入する場合、取引記録を保存して取得する必要があります。テーブルがユーザーの緯度に応じて分割されている場合、各ユーザーの取引記録は同じテーブルに保存されるため、迅速かつ便利です。ユーザーの購入状況を調べますが、特定の商品の購入状況は複数のテーブルに分散している可能性があり、検索が面倒です。逆に、製品の次元に従ってテーブルを分割すると、この製品の購入状況を簡単に見つけることができますが、購入者の取引記録を見つけるのはさらに面倒になります。

一般的な解決策は次のとおりです:

a. メーターをスキャンすることで解決します。この方法は基本的に不可能であり、効率が低すぎます。

b. 2 つのデータを記録し、1 つはユーザーの寸法に従って表に分割し、もう 1 つは製品の寸法に従って表に分割します。
c. 検索エンジンを通じて解決しますが、リアルタイム要件が非常に高い場合は、リアルタイム検索に関連する必要があります。

2. 共同クエリの問題

関連するテーブルが同じデータベース内にない可能性があるため、ユニオンクエリは基本的に不可能です。

3. クロスデータベーストランザクションを避ける

トランザクション内で db0 のテーブルを変更するときに db1 のテーブルを変更することは避けてください。1 つは、操作が複雑になり、効率がある程度影響を受けます。

4. 同じデータセットを同じ DB サーバーに配置してみます

例えば、販売者Aの商品や取引情報がdb0に置かれている場合、db1がダウンしているときでも、販売者Aの関連するものは正常に利用できます。これは、データベース内のデータが別のデータベースのデータに依存しないようにすることを意味します。

1 つのマスター、多数のバックアップ

実際のアプリケーションでは、ほとんどの場合、読み取りの方が書き込みよりもはるかに優れています。 Mysql は、読み取りと書き込みの分離メカニズムを提供します。読み取り操作はマスター マシンとスレーブ マシンで実行でき、マスターは複数のスレーブを持つことができます。 1 つのスレーブを接続すると、DB クラスターの QPS を効果的に向上させることができます。

すべての書き込み操作は最初にマスターで実行され、その後スレーブに同期されるため、システムが非常にビジー状態になると、遅延の問題がさらに深刻になります。スレーブ マシンの数が増えると、問題がさらに悪化します。

さらに、書き込み操作が多すぎると、マスターがクラスターのボトルネックになっていることがわかります。マスターがハングアップすると、クラスター全体が正常に動作しなくなります。

つまり、 1. 読み取り負荷が非常に高い場合は、問題を解決するためにスレーブ マシンを追加することを検討できますが、スレーブ マシンの数が一定の数に達すると、データベースを分割することを検討する必要があります。 2. 筆圧が非常に高い場合は、データベースのサブ操作を実行する必要があります。

MySQL をデータベースとテーブルに分割する必要があるのはなぜですか?

MySQL を使用する場合、データ量が大きい限り、データベースとテーブルを分割する必要があるという問題がすぐに発生すると言えます。
ここで質問があります: なぜデータベースとテーブルを分割する必要があるのですか? MySQL は大きなテーブルを処理できないのですか?
実際、私が経験したプロジェクトでは、1 つのテーブルの物理ファイル サイズは 80G 以上、1 つのテーブルのレコード数は 5 億以上で、このテーブル
は大規模なテーブルを処理できます。 これは非常に便利なテーブル、友人関係テーブルに属しています。

しかし、Ext3 ファイル システムなどのファイル システムでは、大きなファイルを処理する際に多くの問題があるため、この方法は最良の方法とは言えません。 このレベルはxfsファイルシステムで置き換えることができますが、MySQLの単一テーブルが大きすぎる場合に解決が難しい問題、それがテーブル構造調整に関する運用基盤です
。 これは不可能であるため、主要なプロジェクトは使用中にサブデータベースとサブテーブルのアプリケーションを監視します。
Innodb 自体から見ると、データ ファイルの Btree にはリーフ ノード ロックと子ノード ロックの 2 つのロックしかありません。ページの分割または追加が発生したときのことが想像できます。 新しいリーフにより、テーブルにデータを書き込むことができなくなります。

したがって、サブデータベースとサブテーブルの方が依然として良い選択です。

それでは、サブデータベースとテーブルはいくつが適切なのでしょうか?
単一のテーブルで 1,000 万件のレコードをテストした後、書き込みおよび読み取りのパフォーマンスは比較的良好で、バッファーを残し、単一のテーブル内のすべてのデータ フォントが

に維持されます。 レコード数は 800 万未満で、文字型の単一テーブルは 500 万未満に保たれます。

ユーザービジネスなど、100 のデータベースと 100 のテーブルに従って計画した場合:
500 万 * 100 * 100 = 500,000,000 = 5,000 億レコード。

数字を頭の中に入れたので、ビジネスに応じて計画を立てるのは比較的簡単です。