0

g私は、次の構造を持つ Web アプリケーションに取り組んでいます。「顧客」がいて、これらの顧客のそれぞれに独自の「ユーザー」がいます。各顧客 (ユーザーおよびその他のデータを含む) は、他の顧客から完全に分離されており、顧客間でデータが共有されることはありません。
さらに、各「顧客」には異なるサブ Web サイトがあり、そこからのすべてのクエリ (顧客またはユーザーによるもの) は常に単一の customer.id を参照します。

データベースは次の方法で構築されます。

CREATE TABLE `customer` ( 
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT 
) ENGINE=InnoDB; 

CREATE TABLE `user` ( 
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
  `customerID` int(11) unsigned 
) ENGINE=InnoDB; 

CREATE TABLE `blogPost` ( 
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
  `userID` int(11) unsigned 
) ENGINE=InnoDB;

ユーザーを介して顧客に接続されている「blogPost」のようなテーブルがたくさんあります。

一般的なクエリは次のようなものです。

SELECT *  
FROM `blogPost` bp 
INNER JOIN `user` u 
ON bp.userID=u.id 
WHERE u.customerID = 324

これらの結合は高価であり、実際には不要であることは注目に値します。2 番目にサブ Web サイトに入ると、特定の顧客に関連付けられているデータにのみ関心があるためです。

問題は、データベースをどのように改善できるかということです。このテーマについて読めば読むほど、私
は混乱していきます。
顧客ごとに 1 つずつ、多数の異なるデータベースを作成することをお勧めしますか? に冗長customerIDフィールドを追加するかもしれませblogPostんか？他のアイデア？モンゴDB?!

4

2 に答える 2

0

最初にNDBエンジンをクリアしましょう。MySQL Cluster / NDBはここに行く方法ではありません.状況に役立つものを提供しないだけでなく、実際にはより複雑になります. JOINS などの NDB を実行するために大量のリソースと最低 3 台のデータベース サーバーが必要になるだけでなく、NDB 内ではまだ優れていません。

テーブルの結合に問題はありません。RDBMS はこれを効率的に行うように設計されています。外部キーのインデックスに参加している場合、これは高速かつ効率的です。あなたがここでやろうとしているのは、Web データベースの大多数が毎日扱っているものであり、それらの大多数が情報を結合するものです。

顧客ごとに 1 つの DB を使用することもできますが、信頼してください。これにより、データベース管理作業が大幅に増加します。ビジネス上の理由などでこの道をたどる必要がない場合は、そうしないでください。スキーマの変更が発生し、顧客 x にパフォーマンスの問題があり、顧客 y には問題がない場合、それは悪夢です。多くの作業が発生することになります。

于 2013-03-21T08:54:23.597 に答える
0

問題は、データベースをどのように改善できるかということです。

はい、結合は高価です。特に（ create table ステートメントで暗示されているように）インデックスがない場合。これが本当に当てはまる場合は、少なくとも主キーと外部キーにインデックスを追加する必要があります。(また、あなたの設計によれば、ブログ投稿のコンテンツを保存していないことに注意してください。本当に?

一般的なクエリは何か...

本当に？クエリが何らかのフィルタリングを実装していない場合、アプリケーションに重大な問題があります。フィルタリングがページングとして実装され、データがめったに削除/更新されない場合、外部キーごとのシーケンス番号は、グローバル自動インクリメント ID よりも効率的です。

多くの異なるデータベースを作成することが望ましいですか

絶対違う。

確かに、異なるディスクに I/O を分散する物理デバイスがある場合は、I/O パフォーマンスが向上します (DBMS が適切に構成されており、ホット データ セットが大きすぎてメモリに収まらない場合)。異なるディスク間でインデックスとデータ ファイルをインターリーブするか、MySQL のビルトイン サポートを使用してファイル システム間でシャーディングします。

冗長な customerID フィールドを blogPost に追加するかもしれません

多分。

クラスタリングは、可用性とパフォーマンスの点で非常に優れたアイデアですが、セットアップして実行し続けるために必要なスキルと時間の点でオーバーヘッドが伴います。確かに、今は NDB に目を向けるべきではありません。単一インスタンスのチューニングの範囲を使い果たした後は、同期レプリケーションと非同期レプリケーションを見てください。

インデックスを追加することから始め、DBMS 構成を調整し、customerID をブログ投稿に追加してみて、ファイルがストレージ全体にどのように分散されているかを確認します (これは SSD の優れた使用例のようです)。

于 2013-03-21T09:11:55.727 に答える