まず、データベースのボトルネック

かどうかIOボトルネック、またはCPUのボトルネック、最終的にはデータベースへのアクティブな接続の数の増加につながる、データベースは、アクティブな接続数のしきい値を運ぶためにも、近づくことができます。サービスは、ビジネスの観点である、ほとんど、あるいはまったく接続可能なデータベース接続が可能です。次に、（並行性、スループット、崩壊）、それを想像することができます。

1、IOボトルネック

最初：ディスクは、熱すぎるデータをIOボトルネックを読んで、データベースキャッシュは、それぞれがIOクエリの多くを生成します、フィットクエリの速度を低下させない- > サブライブラリーと垂直サブテーブル。

第二：ネットワークIOのボトルネックは、あまり要求されたデータは、ネットワーク帯域幅が十分ではありません- > サブライブラリー。

2、CPUのボトルネック

最初：SQL SQLに含まれているなどの問題、参加、グループ非インデックスフィールドのクエリ条件によるため、によって、CPU操作の動作を増やす - > SQLの最適化、適切なインデックス計算を確立するには、ビジネスサービス層サービスで行いました。

第二： - >単一のテーブルのデータが大きすぎる、あまりにも多くのラインスキャンクエリで、SQLは、CPUのボトルネックがつながる、低効率である 水平方向のパーティションテーブルを。

第二に、サブライブラリーのサブテーブル

図1に示すように、サブライブラリーのレベル

概念：でフィールド基づいて、特定のポリシー（ハッシュ、範囲、等）に記載のライブラリデータを複数に分割ライブラリです。
結果：
- 各ライブラリーの構造は同じです。
- 各ライブラリのデータが同じではありません、ない交差点はありません。
- すべてのライブラリの労働組合は、データの全体量です。
シーン：同時アップの絶対量のシステムは、サブテーブルには、根本的な問題を解決することは困難である、と垂直サブライブラリーには明確なビジネスの所有権がありません。
分析：自然のライブラリより、IOとCPU緩和圧力を掛けすることができます。

図2に示すように、水平サブテーブル

概念：でフィールド基づいて、特定のポリシー（ハッシュ、範囲、等）に記載のテーブルデータを複数に分割表です。
結果：
- 各テーブルの構造は同じです。
- 各テーブルのデータは、交差部分が存在しない、同じではありません。
- すべてのテーブルの労働組合は、データの総量です。
シーン：並行システムの絶対量がアップしませんが、データが多すぎる量は、単一のテーブルには、SQLの効率に影響を与え、ボトルネックとなり、CPUの負担を増加させました。
分析：自然CPUの負担を軽減データ・テーブル少なく、かつ高い単一のSQL実行効率、。

図3に示すように、垂直サブライブラリー

コンセプト：テーブルは異なる、異なるの権利確定に基づいて、ベースとテーブルの異なるに分割ライブラリインチ
結果：
- 各ライブラリの構造が異なっています。
- 各ライブラリのデータが同じではありません、ない交差点はありません。
- すべてのライブラリの労働組合は、データの全体量です。
シーン：絶対システムまで同時実行、および5月抽象的な別のサービスモジュール。
分析：この時点で、あなたは基本的にサービスのことができます。例えば、より多くのビジネスの発展いくつかの一般的な構成テーブル、ディクショナリ表などで、その後のテーブルが別のライブラリに分割することができ、あるいはサービスなど。さらに、インキュベーターのビジネスモデルのセットの開発と、それは、あるいはサービスとしてライブラリに関連する別のテーブルに分割することができます。

図4に示すように、垂直サブテーブル

概念：でフィールド基礎活動分野に応じて、テーブルは、異なるフィールドに分割されているテーブル（プライマリ・テーブルと拡張テーブル）。
結果：
- 各テーブルの構造は同じではありません。
- 各表のデータは同じではない、一般的に、各テーブルのフィールドは、一般的には、関連するデータの主キーであり、少なくとも一つの交差点を有します。
- すべてのテーブルの労働組合は、データの総量です。
シーン：並行システムの絶対量は、最大記録シートではなく、一緒に単一の行に必要な大きな収納スペースはるかにではなく、マルチフィールド、非ホットスポット及びホットスポットデータ及びデータ。データベースキャッシュラインのデータ削減するように、IO、IOボトルネック農産物を読み取るために、ランダムなクエリの多くを生成するために、ディスクのデータを読み込みます。
分析：あなたが理解するためにページと詳細ページのリストを使用することができます。垂直解像度原理は、拡張テーブルとして一緒に、一緒に主テーブルとして（冗長データが頻繁に一緒に照会することができる）は、非ホットスポットデータホットテーブルデータです。このような追加のデータは、それによってランダム読み取りIOの削減、ホットキャッシュすることができます。解体した後、すべてのデータを取得するためには、データをフェッチするために2つのテーブルを関連付ける必要があります。しかし、一緒に結合された2つのテーブルを唯一のCPUの負担を増加させない参加と話すので、使用は（データベース・インスタンスである必要があります）、参加していない、覚えています。リンクされたデータサービス層は、それぞれ一次及び拡張テーブルデータを取得し、関連するフィールドに関連付けられたすべてのデータを取得、ビジネスで問題なければなりません。

第三に、サブライブラリーサブテーブルツール

シャーディング球：瓶、以前はシャーディング-JDBCとして知られています。
TDDL：瓶、淘宝網は、データレイヤーを配布します。
Mycat：ミドルウェア。

注：ツール、独自の研究、公式サイトやコミュニティの優先順位の長所と短所。

第四に、サブライブラリーサブテーブルのステップ

容量（電流容量と増加量）評価点データベーステーブルまたは点の数 - >グループ鍵（偶数）から選択される - >サブ規則テーブル（ハッシュ範囲等） - >（典型的には二重書き込み）が行わ - >膨張の問題（最小）データを移動します。

5つのサブライブラリーのサブテーブルの問題

1、非パーティション・キーの発行クエリ

サブライブラリーサブテーブルのレベルに基づいて、分割された戦略は、一般的にハッシュ法を使用します。

エンドのみ非基準クエリとしてパーティション・キーパーティションキーに加え、
- マッピング方法
- 遺伝子
  注：執筆、図に示すように、user_idの遺伝子アプローチを生成します。xbit遺伝子、例えばサブテーブル8に、8 = 23、従ってX 3を取る、すなわち3ビット遺伝子に関する。対応するモジュロサブライブラリーまたはサブテーブルにルーティングされたとき、クエリが直接user_idをすることができます。クエリ生成機能は、その対応するモジュロサブライブラリーまたはサブテーブルにルーティングuser_name_codeによってuser_name_codeを生成USER_NAME。IDは、共通の生成スノーフレークアルゴリズムを。
年末非クエリの条件として、複数のパーティションキーパーティションキーの追加
- マッピング方法
- 冗余法
  注：db_o_seller合わせのseller_idクエリにルーティングされたときにORDER_IDに応じてクエリまたはがdb_o_buyerライブラリ、ライブラリにルーティングbuyer_id。私は馬の前にビットカートを感じます！他の良いの方法がありますか？技術はそれをスタック変更？
背景に加えて非パーティション・キーパーティションキー条件の組み合わせ問い合わせの様々ながあります
- NoSQLの法律
- 冗余法

2、非クロス表パーティションキークロスデータベースクエリページング問題

サブライブラリーサブテーブルのレベルに基づいて、分割された戦略は、一般的にハッシュ法を使用します。

注：使用のNoSQL法（ESなど）を解決します。

3、問題を拡大

サブライブラリーサブテーブルのレベルに基づいて、分割された戦略は、一般的にハッシュ法を使用します。

ライブラリの水平方向の拡大（クーファからのアップグレード）
注：拡張が2倍になります。
水平方向の拡張テーブル（ダブル移行法）

最初のステップ:(同期デュアル書き込み）アプリケーションの構成とコード、プラスダブル書き込み、デプロイ、変更、
新しい、古いライブラリの古いデータをコピーするために、第2のステップ:(同期デュアルライト）ライブラリー;
ステップ:(同期デュアル書き込み）古いライブラリの新しい、古いデータリポジトリを校正することを条件とする
第四工程:(同期デュアル書き込み）の書き込みは、ダブル取り出し、コードやアプリケーションの設定を変更するには、展開。

注：デュアル書く一般的なプログラムを。

6つのサブライブラリーのサブテーブルの概要

サブライブラリーのサブテーブルには、最初にすべての（数では？またはサブライブラリーサブテーブル？水平または垂直？）あなたが合理的に分割することができます前に、どこボトルネックを知っている必要があります。サブライブラリーのためのサブテーブルに解決することはできません。
選択されたキーは、それも考慮に非パーティション・キーのクエリを取って、均等に考慮にスプリットを取る必要があり、非常に重要です。
長い間、できるだけ簡単なようデマンド、分割ルールを満たしていたよう。