マルチサイト スクリプトがあるとします。たとえば、同じこと (フォーラム ホスティングなど) に対して複数のインスタンスがあるとします。MySQL を使用している場合、サイトごとに新しいテーブル セットを作成するのと、site_id 列を含む 1 つの大きなテーブルを作成するのとではどちらがよいでしょうか?
もちろん、1 つのテーブルの方が保守が容易ですが、パフォーマンスはどうなるでしょうか。また、Redis を使用した場合、答えは異なるでしょうか?
2 に答える
0
ジョンが言うように、複数のテーブルを使用してもパフォーマンスに大きな違いは見られません。インデックスの方が優れています。
ただし、テーブル ロックは、すべてのサイトに対して単一のフォーラム テーブルをロックするのではなく、そのサイトのフォーラム テーブルに固有であるため、パフォーマンスが向上したように見える場合があります。しかし、優れたクエリとアーキテクチャは、これらのロックがパフォーマンスに影響を与えないようにするためのより良い方法です。
サイトごとに 1 つずつ、同じ DB サーバーに複数のデータベースを配置できます。これは、各サイトに独立したユーザー テーブルとフォーラム テーブルがあり、それぞれに独自のリソース プールがあることを意味するため、理にかなっています。ただし、1 人のユーザーが複数のフォーラムを使用し、複数のユーザー レコード (およびフォーラムの投稿に固有ではないその他のデータ) を保持する必要がある場合、この重複データが発生します。
それらを使用しているアプリケーション サーバーの近くに (ネットワークの意味で) 完全に異なる DB サーバーを配置することで、遅延を減らすことができます。しかし、実際には、現在、全国のサーバーが ping に応答するのにかかる時間は 10 分の 1 秒未満であり、これはホーム ユーザー向けであり、ホスティング プロバイダーにあるサーバーにとってはおそらく少し優れています.
単一のデータベース内の単一のテーブルが処理できる範囲を超えた使用法が実際に見られない限り、これはすべて意味がありません。そして、ボトルネックがどこにあるかについて実際の統計が得られるまでは、壊れるかどうかさえわからないものを修正しようとして、自分をノックアウトしないでください.
于 2013-05-08T18:18:35.650 に答える
0
DBMS の裏をかこうとするのはやめましょう。その戦いには勝てません。パフォーマンス上の理由からではなく、データを論理的にテーブルに分割する必要があります。
あなたが説明しているのは、事実上、インデックスを再発明しようとする弱い試みです。
于 2013-05-08T14:52:36.030 に答える