さまざまな顧客向けにさまざまな MySQL shemas を使用する製品と、顧客ごとに 1 つの異なる永続ユニットを使用する単一の Java アプリケーションがあります。これにより、アプリケーションを再デプロイせずに顧客を追加することが困難になります。
すべての顧客を保持する単一の MySQL データベース スキーマを使用する予定です。各テーブルには 1 人の顧客を象徴する KEY であるフィールドがあり、新しい顧客を追加することは SQL の更新や挿入がほとんど必要ありません。
MySQLでこの種のデータを処理するための最良のアプローチは何ですか...MySQLはキーなどによるパーティション分割テーブルを提供しますか? そして、そのアプローチのパフォーマンスの問題は何でしょうか?
ここでいくつか質問があります。
スキーマ設計に関する質問
パーティショニングの質問
MySQL は HASH MAP クエリ O(1) を処理できますか
スキーマ設計の質問: はい、これは、顧客ごとに新しいアプリを起動するよりもはるかに優れています。
mySQL は HASH MAP クエリを処理できますか O(1) はい、データがメモリに残り、十分な CPU サイクルがあれば、mySQL は 1 秒間に 300K の選択を簡単に行うことができます。それ以外の場合、データが I/O バウンドであり、ディスク サブシステムが飽和していない場合、トラフィック パターン、同時実行性、およびデータベース ディスク サブシステムが実行できる IOPS の数に応じて、mySQL は 1 秒あたり 20 ～ 30K の選択を簡単に実行できます。
パーティショニング パーティ ショニングは、mySQL について話すコンテキストでは異なることを意味します。パーティショニングは、特定のテーブルにデータを割り当てるために mySQL の別のストレージ エンジンの上にあるストレージ エンジンですが、パーティション テーブルのグループを単一のテーブルとして呼び出し側アプリケーションに公開します。パーティショニングは、特定のデータベースがすべてのテーブルのサブセットを実行することを意味する場合もあります。あなたの文脈では、パフォーマンスへの影響は何か、顧客ごとに連携するかどうかを尋ねていると思います。つまり、必要に応じて同じスキーマで顧客ごとにデータベースを割り当てることができます。この概念は、シャーディングの理想に沿っており、データを全体として取り、顧客などのデータの単位ごとにリソースを割り当てます。
あなたへの私の提案 は、スキーマを顧客ごとに同じにします。顧客が行う関連するすべてのクエリをベンチマークします。クエリ パターンです。EXPLAIN を使用した各クエリが、ファイルソートまたは一時テーブルを生成せず、一度に 100K 行をスキャンせず、問題なくスケーリングできることを確認します。1 つまたは一連のボックスが IOP の上限に近づいているという問題に遭遇したら、データを分割することを検討してください。