[MySQL]サブデータベースサブテーブル

Sub Database Sub Table

1.一般的な問題

1.データベースとテーブルを分割する必要があるのはなぜですか（設計 高い同時実行性 システム、 データベースレベル 設計方法）？どのサブデータベースとサブテーブルミドルウェアが使用されていますか？さまざまなデータベースおよびテーブルミドルウェアの長所と短所は何ですか？データベースを垂直方向または水平方向にどのように分割しますか。

2.動的に拡張できるサブデータベースとサブメータースキームを設計するにはどうすればよいですか？

3.サブデータベースとテーブルの後、IDの処理方法。

第二に、なぜサブデータベースとサブテーブル

実際、サブデータベースとサブテーブルは同時実行性が高いこととデータ量が多いことの2つの問題をサポートする必要があるため、この領域は同時実行性が高いことに関連している必要があります。そして今、正直に言うと、特にインターネット会社のインタビューでは、これは基本的に当てはまります。サブデータベースとサブテーブルに関する通常の技術的な問題について質問しないと、わからない場合はそれを正当化することは本当に不可能です。

率直に言って、サブライブラリとサブテーブルは2つの異なるものです。混同しないでください。サブライブラリがテーブルを分離していないか、サブライブラリがテーブルを分離していない可能性があります。それはすべて可能です。最初に質問をさせてください。

ユーザー数の増加に伴い、毎日数千万人のアクティブユーザーがいます。すべてのテーブルに500,000を超えるデータが追加されます。現在、1つのテーブルの総容量は2000万から3000万に達しています！データベースのディスク容量は継続的に消費されており、ピーク時には5000〜8000に達します。現在、スタンドアロンシステムのサポートは利用できません。会社の事業開発がうまくいくほど、ユーザーが増え、データの量が増え、リクエストの量が増えます。その単一のデータベースはそれを保持できてはなりません。

MySQLが1台のマシンから3台のマシンに変更されたとします。

①MySQLが1台から3台に変更され、耐えられる同時実行性が3倍になりました。

②元の3000万個のデータを1つのデータベースから3つのデータベースに分割し、それぞれがデータボリュームの1/3を占めるようにして、データベースサーバーのディスク使用量を大幅に削減しました。

③1つのテーブルに3000万のデータがあり、1つのSQLの実行に3秒かかることがわかりました。分割後、各データベースの各テーブルには1,000万個のデータがあり、1つのSQLの実行には1秒かかります。 _

3.どのデータベースおよびテーブルミドルウェアを使用しましたか。また、さまざまなデータベースおよびテーブルミドルウェアの長所と短所は何ですか。

より一般的なものには、sharding-jdbcとmycatが含まれます。

1. sharding-jdbc：Dangdangは、クライアント層に属するオープンソースソリューションです。サブデータベースサブテーブル、読み取り/書き込み分離、分散ID生成、柔軟なトランザクション（ベストエフォート型の配信タイプのトランザクション、TCCトランザクション）をサポートします。

2. mycat：cobar変換に基づいて、プロキシレイヤーソリューションに属します。サポート機能は非常に完全であり、データベースミドルウェアは常に人気があり、コミュニティは非常に活発です。

sharding-jdbcのクライアント層ソリューションの利点は、デプロイする必要がなく、運用と保守のコストが低いことです。しかし、何かをアップグレードする必要が生じた場合、各システムはアップグレードされて再びリリースされます。mycatのプロキシ層ソリューションの欠点は、ミドルウェアのセットをデプロイして操作する必要があることです。運営・維持管理費が高い。ただし、各プロジェクトに対して透過的であるという利点があります。アップグレードが発生した場合は、ミドルウェアを使用するだけで済みます。

Sharding-jdbcは、一般的に中小企業に推奨されます。クライアントレベルのソリューションは軽量でメンテナンスコストが低く、追加の人員は必要なく、中小企業のシステムの複雑さは低くなります。それほど多くのプロジェクトはありません。ただし、大企業は多くのシステムやプロジェクトを持っている可能性があるため、中規模および大規模企業はmycatなどのプロキシレイヤーソリューションを選択するのが最適です。チームは大きく、スタッフは十分です。誰かにmycatを調べて維持してもらうのが最善です。次に、多数のプロジェクトが直接かつ透過的に使用されます。

第4に、データベースを垂直方向または水平方向に具体的にどのように分割しますか？

1.垂直分割：

頻繁に使用するフィールドを1つのテーブルに配置し、使用頻度の低いフィールドを別のテーブルに配置します。

実際、これは非常に一般的です。大きな時計を分解してください。注文フォーム、注文支払いフォーム、注文アイテムフォーム。

2.水平分割：

3つのライブラリに分割され、1つのライブラリには4つのテーブルが含まれています。各テーブルのデータ量は、元の単一テーブルの600万から各テーブルの50万に変更されました。 SQLの実行効率は数倍に向上する可能性があります。 1つのバンクは2000 / sの最大QPSに耐えることができ、3つのバンクは6000 / sの最大QPSに耐えることができます。元の単一ライブラリ600万データを想定します。 600Mのディスク容量を占有します。現在、200万データの単一データベースは200MBのディスクスペースしか使用しません。

一般的に、サブデータベースサブテーブルは実際には水平分割を指します。垂直分割は通常、ビジネスが関与しているときに行われます。通常、残りは特定のキーフィールドに従って取得されます。に

5.動的に拡張できるサブデータベースとサブメータースキームを設計する方法

1.シャットダウンと容量拡張

この計画はダウンタイムの移行と同じであり、手順はほとんど同じです。唯一のポイントは、その派生ツールです。はい、既存のテーブルのデータを確認して新しいテーブルに挿入しますが、信頼性が低いため、遅刻しないことをお勧めします。サブデータベースとサブテーブルは、データ量が多すぎることを示しているためです。それは数億、さらには数十億にもなる可能性があります。このようにプレイすると、問題が発生する可能性があります。

単一のデータベースと単一のテーブルからサブデータベースとサブテーブルに移行する場合、データの量はそれほど多くなく、単一のテーブルの最大量は2,000万から3,000万です。ツールを作成し、さらにいくつかのマシンを並行して実行します。データは1時間でエクスポートされます。

2.最適化された計画

01_サブデータベースとサブテーブルの拡張計画

最初は、32個のライブラリがあり、それぞれに32個のテーブルがあります。 1024テーブル。第一に、この部門は国内のインターネット企業にとって基本的に十分です。第二に、並行性のサポートであろうとデータボリュームのサポートであろうと、問題はありません。

各ライブラリーの通常の並行性容量は1000であるため、32個のライブラリーは32 * 1000 = 32000の書き込み並行性を実行できます。各ライブラリが1500の同時書き込みを実行する場合、32 * 1500 = 48000であり、これは1秒あたり50,000の同時書き込みに近い値です。前に別のMQを追加し、シェービングをピークにし、1秒あたり80,000 MQデータを書き込み、1秒あたり50,000データを消費します。

各テーブルが500万のデータを保持すると仮定すると、1024のテーブルは、50億のデータをMySQLに格納できます。ほとんどの企業にとって、50,000 / sの書き込み同時実行性（合計50億個のデータ）で十分です。

サブライブラリとサブテーブルの拡張について言えば、初めてサブライブラリとサブテーブルが分割されたとき、彼には十分な量が割り当てられています。 32のライブラリ、1024のテーブル。