まず、データベースのボトルネック
IOボトルネック、またはCPUのボトルネックは、最終的にデータベースへのアクティブな接続の数の増加につながるかどうかは、データベースは、アクティブな接続の閾値数を運ぶためにも近づけることができます。サービスは、ビジネスの観点である、ほとんど、あるいはまったく接続可能なデータベース接続が可能です。次に、（並行性、スループット、崩壊）、それを想像することができます。
-
IOがボトルネック
、ディスクは、IOボトルネックを読んで、あまりにもホットデータを、データベースキャッシュクエリの速度を低減し、各IOクエリの多くを生成し、適合しない- >：最初のサブライブラリーと垂直サブテーブル。第二：ネットワークIOのボトルネックは、あまり要求されたデータは、ネットワーク帯域幅が十分ではありません- > サブライブラリー。
-
CPUボトルネック
最初：SQLの問題は、SQLに含まれるように、非インデックスフィールドのクエリ条件、増加CPU演算により順序によって、グループに参加- > SQL最適化、サービス層計算サービスにサービスするための適切な指標を確立します。第二： - >レベルのポイントテーブルを単一のテーブルのデータが大きすぎる、あまりにも多くのラインスキャンクエリ、SQLは、CPUのボトルネックがつながる、低効率です。
第二に、サブライブラリーサブテーブル
1サブライブラリーのレベル
1）コンセプト：フィールド単位で、特定のポリシー（等ハッシュ、範囲）によれば、複数のライブラリのデータベースにデータを分割します。
2）結果：
各ライブラリの構成は同じであり、
各ライブラリーのためのデータが同じではない、何の交点が存在せず、
すべてのライブラリと設定データの全体量;
3）シーン：同時アップのシステム絶対量、サブテーブルは、基本的に解決することは困難です問題、および垂直方向のライブラリを確定する明白な。
分析：自然のライブラリより、IOとCPU緩和圧力を掛けすることができます。
図2に示すように、水平部表
1）コンセプト：フィールド単位で、特定のポリシー（ハッシュ、範囲、等）によれば、複数のテーブルのテーブルにデータを分割します。
2）結果：
各テーブルの構造は同じであり、
各テーブルのデータが異なる、全く交差部分が存在しない、
すべてのテーブルとデータセット全体の量;
3）シナリオ：並行システムの絶対量が来ない、データの単一のテーブルがあまりにも多くのボリュームは、SQLの効率に影響を与え、ボトルネックとなり、CPUの負担を増加させました。
分析：自然CPUの負担を軽減データ・テーブル少なく、かつ高い単一のSQL実行効率、。
図3に示すように、垂直サブライブラリー
1）コンセプト：表の基礎は、それらの種々のサービスに応じて、異なるテーブルは、異なるライブラリに分割しました。
2）結果：
;ライブラリーのそれぞれの構造は同じではありません
。何の交点が存在しない、各ライブラリのデータが同じではない
すべてのライブラリやデータ量の全体のセット;
3）シナリオ：システムまで同時の絶対量は、単独で抽象的でありサービスモジュール。
分析：この時点で、あなたは基本的にサービスのことができます。例えば、より多くのビジネスの発展いくつかの一般的な構成テーブル、ディクショナリ表などで、その後のテーブルが別のライブラリに分割することができ、あるいはサービスなど。さらに、インキュベーターのビジネスモデルのセットの開発と、それは、あるいはサービスとしてライブラリに関連する別のテーブルに分割することができます。
図4に示すように、垂直サブテーブル
1）コンセプト：フィールド単位で活動分野に応じて、異なるテーブルにテーブル内の分割フィールド（プライマリ・テーブルと拡張テーブル）。
2）結果：
各テーブルの構造は同じではない;
、データは、各テーブルに同じではない、一般的に、各テーブルのフィールドは、少なくとも一つの交差点を有し、一般的に関連するデータの主キーであり、
すべてのテーブルとの組;データの総量は、
マルチフィールド、非ホットスポット及びホットスポットデータ及びデータは、一緒になって単一の行に必要な大きな収納スペースあまりないコンカレントシステムの絶対量は、最大記録シートではなく、：3）シナリオ。データベースキャッシュラインのデータ削減するように、IO、IOボトルネック農産物を読み取るために、ランダムなクエリの多くを生成するために、ディスクのデータを読み込みます。
分析：あなたが理解するためにページと詳細ページのリストを使用することができます。垂直解像度原理は、拡張テーブルとして一緒に、一緒に主テーブルとして（冗長データが頻繁に一緒に照会することができる）は、非ホットスポットデータホットテーブルデータです。このような追加のデータは、それによってランダム読み取りIOの削減、ホットキャッシュすることができます。解体した後、すべてのデータを取得するためには、データをフェッチするために2つのテーブルを関連付ける必要があります。しかし、一緒に結合された2つのテーブルを唯一のCPUの負担を増加させない参加と話すので、使用は（データベース・インスタンスである必要があります）、参加していない、覚えています。リンクされたデータサービス層は、それぞれ一次及び拡張テーブルデータを取得し、関連するフィールドに関連付けられたすべてのデータを取得、ビジネスで問題なければなりません。
第三に、サブライブラリーのサブテーブルツール
1.sharding球：瓶、以前はJDBC-シャーディングとして知られている。
2.TDDL：JARは、淘宝網は、データレイヤーを配布;
3.Mycatを：ミドルウェア。
注：ツール、独自の研究、公式サイトやコミュニティの優先順位の長所と短所。
第四に、サブライブラリーサブテーブルのステップ
（電流容量と増加量）評価サブライブラリ容量又はサブテーブルの数に応じて- >グループキー（偶数）から選択される- >サブ規則テーブル（ハッシュ範囲等） - >（典型的には二重書き込み）を行います- >膨張の問題（データの移動を最小化します）。
5つのサブライブラリサブテーブル質問
1、非分割キー問合せの問題（水平サブライブラリーサブテーブル、分割戦略法に使用されるハッシュ）
のみ非クエリ条件としてエンドパーティションキーパーティションキーに加えて、1
- マッピング方法
- 遺伝子
注：執筆、図に示すように、USER_IDを生成することによって遺伝子。xbit遺伝子について、例えば、表8の点に、2 3 = 8、従ってX 3を取る、すなわち3ビット遺伝子。対応するモジュロサブライブラリーまたはサブテーブルにルーティングされたとき、クエリが直接user_idをすることができます。クエリ生成機能は、その対応するモジュロサブライブラリーまたはサブテーブルにルーティングuser_name_codeによってuser_name_codeを生成USER_NAME。IDは、共通の生成スノーフレークアルゴリズムを。
非クエリ条件として複数のパーティションキーパーティション・キーの端部に加えて、2
- マッピング方法
- 冗長法
の背景に加えて3だけでなく、様々な非パーティション・キーパーティションキー条件の組み合わせのお問い合わせ - NoSQLの法律
- 冗余法
2、非クロス表パーティションキークロスデータベースクエリページング問題（レベルのサブライブラリサブテーブル、分割戦略一般的に使用されるハッシュ法）
注：のNoSQL法で（ESなど）を解決します。
3、問題を拡大する（レベルサブライブラリーサブテーブル、分割戦略一般的に使用されるハッシュ法）
- ライブラリの水平方向の拡大（クーファからのアップグレード）
- 水平方向の拡張テーブル（ダブル移行法）
最初のステップ:(同期デュアル書き込み）デュアル書き込みアプリケーションの構成、展開、
第二段階:(同期デュアル書き込み）新しいデータベースに古いライブラリ古いデータをコピーする。
第三のステップ:(旧データの校正新しいライブラリを優先し、古いライブラリへの）デュアル書き込み同時;
）第四段階:(同期デュアル書き込み重書き込みを削除するアプリケーション、デプロイ;
注：二重書き込みが普遍的なプログラムです。
6つのサブライブラリーのサブテーブルの概要
1.サブライブラリーのサブテーブルには、最初にすべてのあなたが合理的にボトルネックを分割することができます前に、どこ知っている必要があります（いくつかのでは？サブテーブル？水平または垂直またはサブライブラリー？）。サブライブラリーのためのサブテーブルに解決することはできません。
2. Optionキーは、も考慮に非パーティション・キーのクエリを取って、均等に考慮にスプリットを取る必要があり、非常に重要です。
3.としては長く、できるだけ簡単なようデマンド、分割ルールを満たしています。
例GitHubの住所：https://github.com/littlecharacter4s/study-sharding
