データベースのパフォーマンスのボトルネックのためにまず、主な理由
図1に示すように、データベース接続
MySQLデータベースのデフォルトの接続は、我々は100などINITIALSIZE、minIdle、MAXACTIVEを構成することによって調整されますが、ハードウェアリソースの制限のため、データベース接続を増加させることが無制限であることができない、大規模な単一インスタンス・データベースに接続されている最大の単一のアプリケーションがあるかもしれないことができています例数は実際の需要を満たすことができない場合、システムは、交通渋滞になります。
図2に示すように、データテーブルの量（収納スペースの問題）
一般的にデータベースがパフォーマンスのボトルネックに千万を超える単一のテーブルのデータ量を読み込むと考えられています。インデックスがヒットしなかった場合は、インデックスの観点からは、データベース・システムは、テーブル全体をスキャンし、データ量も大きく、全表スキャン時間が長くなります。インデックスがヒットした場合でも、B + TREEインデックスがハードディスクに位置しているので、 、IOの数、データB + TREEより深いレベルの量よりも大きいです。
3、ハードウェアリソースの制約
ハードウェアリソースは、直接毎秒QPS QPS / TPSの取引に影響を与えます。
第二に、パフォーマンスデータの最適化
共通データのパフォーマンスの最適化：SQLの最適化、キャッシング、インデックスを作成し、個別の読み取りと書き込み、サブライブラリーサブリスト。
パフォーマンスの最適化を解決するために、大量のデータ、真に効果的な解決策は、すなわち別リード上に、分散ファイルシステムを使用し、サブライブラリーとサブテーブルを作成することです。
1、読み取りと書き込みの分離
分離は、データを格納およびロードの複数のデータソースの方法の読み書きの間の差を用いて、リーダからのマスタコピーに基づきます。（CRUD）は、データのクエリを読み、書くためにデータソースを指定するデータを格納することは読み出されたデータソースを指定します。
データを読み書きすることで、接続ハードウェアリソースの制約やボトルネックに解決することができるように、同じデータ・ソース（複数のマスタ）のマスタコピーを分離し、複数のデータソースは、異なるホストにデプロイすることができます。
2、サブライブラリーのサブテーブル
ライブラリのテーブルデータの分割、管理データスライス方式。
垂直分割単一データベースリポジトリデータベース分割フィールド、各フィールドよりよいポータビリティデータベースは、より明確に分割機能します。しかし、また、データベース接続、ハードウェアリソースの制約を解決します。任意の計画は、同時に問題を解決するために新たな問題をもたらす、サブライブラリーのサブテーブルも例外ではありません、リレーショナルクエリが複雑で、分散トランザクションの問題になりますよう。
スプリットレベルが大きなテーブルは、シングルユーザー表3小さなテーブルUSER01、USER02、USER03の分割3000万データ量などの特定の規則に従っていくつかの小さなテーブルに分割されます。主にメモリ空間に起因するデータベースのパフォーマンスのボトルネックを解決するだろうデータの問題、単一のテーブルを大量に、解決します。
ポイントテーブルに焦点を当てる次回の記事では、より詳細なサブライブラリーサブテーブル実装のサブライブラリーの面でそのアプリケーションをMyCat。