まず、データベースのボトルネック
それがIOボトルネックであろうとCPUボトルネックであろうと、最終的にはデータベース内のアクティブな接続数の増加につながり、データベースが運ぶことができるアクティブな接続数のしきい値に近づいたり、しきい値に達したりします。ビジネスサービスの観点からは、利用可能なデータベース接続はほとんどないか、まったくありません。次に、それを想像できます（同時実行、スループット、クラッシュ）。
1. IOボトルネック
1つ目は、ディスクの読み取りIOボトルネック、ホットデータが多すぎる、データベースキャッシュを配置できない、各クエリで大量のIOが生成され、クエリ速度が低下する->データベースと垂直テーブルです。
2番目の種類：ネットワークIOボトルネック、要求されたデータが多すぎる、ネットワーク帯域幅が不足している->サブライブラリ。
2. CPUボトルネック
最初のタイプ：SQLなどのSQLの問題には、結合、グループ化、順序付け、非インデックスフィールド条件クエリなどが含まれ、CPU操作の操作を増やします-> SQL最適化、適切なインデックスを確立し、ビジネスサービス層でビジネス計算を実行します。
2番目のタイプ：単一のテーブルのデータ量が多すぎる、クエリ中にスキャンされる行が多すぎる、SQLの効率が低い、CPUがボトルネック->水平テーブル分割を最初に持つ。
2.サブライブラリとサブテーブル
1.水平サブライブラリ
概念：フィールドに基づいて、特定の戦略（ハッシュ、範囲など）に従って、1つのライブラリーのデータを複数のライブラリーに分割します。
結果：
-
各ライブラリの構造は同じです。
-
各ライブラリのデータは異なり、交差はありません。
-
すべてのライブラリの結合は完全なデータです。
シナリオ：システムの絶対的な同時実行性が高まり、問題を根本的に解決することは困難であり、ライブラリを垂直に分割する明確なビジネス属性はありません。
分析：より多くのライブラリーを使用すると、ioとcpuの圧力を自然に複数で緩和できます。
2.レベルテーブル
概念：フィールドに基づいて、特定の戦略（ハッシュ、範囲など）に従って、1つのテーブルのデータを複数のテーブルに分割します。
結果：
-
各テーブルの構造は同じです。
-
各テーブルのデータは異なり、交差はありません。
-
すべてのテーブルの結合は完全なデータです。
シナリオ：システムの絶対並行ボリュームは上がっていませんが、単一のテーブル内のデータ量が多すぎるため、SQLの効率に影響を与え、CPUの負荷が増大し、ボトルネックになります。推奨：SQLクエリの最適化原理の分析
分析：テーブル内のデータ量が削減され、単一のSQL実行の効率が高くなり、CPUの負担が自然に軽減されます。
3.垂直サブライブラリ
コンセプト：テーブルに基づいて、さまざまなビジネス属性に従って、さまざまなテーブルをさまざまなライブラリに分割します
結果：
-
各ライブラリの構造は異なります。
-
各ライブラリのデータも異なり、交差はありません。
-
すべてのライブラリの結合は完全なデータです。
シナリオ：システムの絶対並行ボリュームがアップし、別個のビジネスモジュールを抽象化できます。
分析：この段階では、基本的にサービスを提供できます。たとえば、ビジネスの発展に伴い、一般的な構成テーブル、ディクショナリテーブルなどがますます増えています。現時点では、これらのテーブルを個別のライブラリに分割したり、サービスを提供したりすることもできます。さらに、ビジネスの発展に伴い、一連のビジネスモデルが孵化しましたが、現時点では、関連するテーブルを別のライブラリに分解し、サービスを提供することもできます。
4.縦型テーブル
概念：フィールドに基づいて、フィールドのアクティビティに応じて、テーブルのフィールドは異なるテーブル（メインテーブルと拡張テーブル）に分割されます。
結果：
-
各テーブルの構造は異なります。
-
各テーブルのデータも異なります一般的に、各テーブルのフィールドには少なくとも1つの列の交差があります。
-
すべてのテーブルの結合は完全なデータです。
シナリオ：システムの絶対的な同時実行性が実現していません。テーブルにレコードは多くありませんが、フィールドは多く、ホットデータと非ホットデータが一緒になっています。データの単一行に必要なストレージスペースが大きいです。その結果、データベースによってキャッシュされるデータ行の数が減り、クエリ中にディスクデータを読み取るときに大量のランダム読み取りIOが生成され、IOボトルネックが発生します。
分析：リストページと詳細ページを使用して、理解を深めることができます。垂直テーブル分割の原則は、ホットスポットデータ（頻繁に一緒に照会される可能性があるデータ）をメインテーブルとして配置し、非ホットスポットデータを拡張テーブルとして配置することです。このようにして、より多くのホットスポットデータをキャッシュできるため、ランダム読み取りIOが削減されます。解体後、すべてのデータを取得するには、2つのテーブルを関連付けてデータをフェッチする必要があります。
ただし、結合はCPUの負荷を増大させるだけでなく、結合された2つのテーブルについて話し合うため（データベースインスタンス上にある必要がある）、結合を使用しないでください。関連データ：ビジネスサービスレイヤーで記事を作成し、メインテーブルと拡張テーブルのデータを個別に取得してから、関連フィールドを使用してすべてのデータを取得する必要があります。
3.サブデータベースとサブテーブルツール
-
sharding-sphere：jar、以前はsharding-jdbc。
-
TDDL：jar、Taobaoデータレイヤーを配布します。
-
Mycat：ミドルウェア。
注：このツールの長所と短所は、独自の調査、公式Webサイト、コミュニティの優先順位を参考にしてください。
4.サブライブラリとテーブルステップ
容量（現在の容量と増加）に応じて、サブライブラリまたはサブテーブルの数を評価します->キーを選択（偶数）->テーブルルール（ハッシュまたは範囲など）->実行（通常は二重書き込み）->拡張の問題（削減データ移動）。
拡張：MySQL：サブデータベースのサブテーブルとパーティションの違いと考え方
第5に、サブライブラリとテーブルの問題
1.非パーティションキークエリの問題
水平サブライブラリとサブテーブルに基づいて、分割戦略は一般的に使用されるハッシュ法です。
パーティションキーに加えて、条件付きクエリとして非パーティションキーが1つだけあります。
マッピング方法
遺伝的方法
注：書き込み時には、図に示すように、遺伝的メソッドがuser_idを生成します。たとえば、xbit遺伝子に関しては、23 = 8の8つのテーブルがあるので、xは3ビット遺伝子である3をとります。user_idクエリによると、対応するサブライブラリまたはサブテーブルへのモジュールルートを直接取得できます。
user_nameに基づいてクエリを実行する場合、最初にuser_name_code生成関数を介してuser_name_codeを生成し、次に対応するサブライブラリまたはサブテーブルへのモジュロルートを取得します。id生成で一般的に使用されるスノーフレークアルゴリズム。
パーティションキーに加えて、条件付きクエリとして複数の非パーティションキーがあります
マッピング方法
冗余法
注：order_idまたはbuyer_idでクエリする場合はdb_o_buyerライブラリにルーティングし、seller_idでクエリする場合はdb_o_sellerライブラリにルーティングします。それは少し逆さまに感じます！他に良い方法はありますか？テクノロジースタックの変更についてはどうですか？
パーティションキーに加えて、さまざまな非パーティションキーの組み合わせ条件クエリがバックグラウンドで実行されます。
NoSQLメソッド
冗余法
2.非パーティションキーデータベース間クロステーブルページングクエリの問題
水平サブライブラリとサブテーブルに基づいて、分割戦略は一般的に使用されるハッシュ法です。
注：NoSQLメソッド（ESなど）。
3.容量拡張
水平サブライブラリとサブテーブルに基づいて、分割戦略は一般的に使用されるハッシュ法です。
水平拡張ライブラリ（ライブラリメソッドからのアップグレード）
注：拡張は2倍になります。
横展開表（二重書きマイグレーション方式）
-
最初のステップ：（同期二重書き込み）アプリケーションの構成とコードを変更し、さらに二重書き込み、デプロイメントを行います。
-
2番目のステップ：（同期二重書き込み）古いライブラリの古いデータを新しいライブラリにコピーします。
-
3番目のステップ：（同期二重書き込み）古いライブラリに基づいて、新しいライブラリの古いデータを校正します。
-
4番目のステップ：（同期二重書き込み）アプリケーションの構成とコードを変更し、二重書き込みを削除してデプロイします。
注：二重書き込みは一般的なスキームです。
6、サブライブラリとサブテーブルの概要
-
ライブラリをテーブルに分割するには、まずボトルネックがどこにあるかを知っておく必要があり、それからそれを合理的に分割できます（サブライブラリまたはテーブル？水平または垂直？いくつ？ライブラリとテーブルを分割するために分割することはできません。
-
キーを選択することは、分割を均等に考慮するだけでなく、非パーティションキークエリも考慮するために非常に重要です。
-
要件を満たすことができる限り、分割ルールは単純であるほど優れています。
