2

2MM 行と 8 列を超えるユーザー統計を格納する MySQL テーブルと、userID のインデックスがあります。ユーザーが自分のプロファイルにアクセスすると、これらの情報の多くがデータベースから取得され、最悪の場合、数十のSELECTクエリが他のテーブルと結合されることがあります。これは、多くのデータを取得する必要がある SO のプロファイルに似ています。

ユーザー スコアを取得するような一部のクエリでは、COUNTMySQL 関数やその他のパフォーマンスを消費する関数が必要です。そのため、プロファイル ページのクエリだけでも、最大 10 ～ 20 秒かかることがあります。

今私の質問：

  1. SO のような Web サイトは、どのようにしてこれほど多くの情報をすばやく取得できるのでしょうか?
  2. キャッシュ層は必要ですか?
  3. MySQL のパフォーマンスを消費するスコアなどのカウントを事前に計算する必要がありますか?
  4. 書き込み用に最適化されたテーブルと読み取り用に最適化されたテーブルを 1 つずつ使用する必要がありますか? もしそうなら、どうすればSOのようなライブデータを取得できますか?
  5. MySQL から離れるべきですか?
4

1 に答える 1

2

SO のような Web サイトは、どのようにしてこれほど多くの情報をすばやく取得できるのでしょうか?

それらは「非常に多くの」データをプルしているように錯覚させますが、実際には一度に 1 つのチャンクを取得します。基本的に、結果の COUNT を取得するクエリと、その結果セット内の任意のページのデータを取得する別のクエリが必要です。結果セットはキャッシュされません。クエリへのパラメータはキャッシュされる場合があります。ただし、ページ要求ごとにクエリ パラメータが提供されるように実装することをお勧めします。

キャッシュ層は必要ですか?

多分。ただし、これを実装する必要はありません。キャッシュは、以前に取得したページを保存するのに役立つ場合があり、同じページが 1 人のユーザーではなくコミュニティ全体で使用されます。

MySQL のパフォーマンスを消費するスコアなどのカウントを事前に計算する必要がありますか?

このユースケースには関係ありません。

書き込み用に最適化されたテーブルと読み取り用に最適化されたテーブルを 1 つずつ使用する必要がありますか? もしそうなら、どうすればSOのようなライブデータを取得できますか?

必要ありません。

MySQL から離れるべきですか?

必要ありません。

この概念の詳細については、ページ分割された Ajax グリッドを参照してください。

于 2012-07-17T21:37:52.143 に答える