1

mysql データベースに 2 つのテーブルがあります

  1. tbl_comments
  2. tbl_votes

ユーザーがコメントの下の [いいね] または [いいね!] ボタンをクリックすると、comment_id、user_id、vote_type を含む新しい行が tbl_votes に挿入されます。つまり、1 日あたり 100 件のコメントに対して 100 人のユーザーが [いいね] または [いいね!] ボタンをクリックすると、tbl_votes テーブルに 10,000 行が挿入されます。したがって、ユーザー数の増加と投票数の増加に伴い、tbl_votes は急速に増加します。また、tbl_votes に 100,000,000 行あると、パフォーマンスにも影響し、SQL クエリが遅くなるとします。

この解決策または他の解決策にどのように対処できますか。

4

4 に答える 4

2

This is a perfectly fine solution. As long as you have the indexes set correct it's okay.(index on primary key, and post id)

Take forexample stackoverflow, every post, reply comment has it's own voting system, up or down, remembers who voted, and they have about 200million+ messages+replies with each their own votes, and still it responds quickly.

As long as the indexes are set correctly, it should perform just fine. I might suggest using a bigint for the primary key though...

于 2013-03-05T08:18:27.503 に答える
0

SELECTテーブルのサイズがクエリに影響を与えないというのは完全に正しいわけではありません。大きなテーブルの場合は、TokuDB をお勧めします。

どちらの場合も、データが必要なときに問題が発生しますDELETE。その時点で、2 つの選択肢があります。キーをクラスター化するか、別のアーキテクチャを検討し始めるかです (水平シャーディングが良い方法かもしれません)。

于 2015-10-05T07:36:06.283 に答える
0

1 billionインデックスをメモリに保持できるマシン上で行を使用する場合、アプリケーションのパフォーマンスについて心配する必要はありません。

パフォーマンスは以下に依存します。

  1. これらのクエリが行う結合の数
  2. インデックスが適切に設定されているか
  3. マシンのRAMの量
  4. プロセッサの速度と数
  5. ハードドライブのタイプとスピンドル速度
  6. 行のサイズ/クエリで返されるデータの量
于 2013-03-05T08:23:21.867 に答える
0

いくつかの結論:

rdbms を使用する場合: テーブルに挿入する行数は、コメントのいいね! の総数を選択するために正しくインデックス付けされている場合、もちろん結果をキャッシュしておく必要があります。高速なデータ選択のもう 1 つの方法は、いくつかの投票データを集計しておくことです。そのため、ユーザーがコメントに賛成票を投じた場合、テーブルに 1 つの挿入/削除があり、次のように別のテーブルで更新されます。

comment_id
rate

したがって、必要なコメントに対してレートを選択すると、集計テーブルの合計行数がはるかに少なくなります。

別の良い方法は、キー値ストレージを使用することです。あなたのキーがcomment_idで、生データの値が保存されているとします

user_id
vote_type

選択したストレージまたは noSql ストレージに応じて、データは完全にメモリに保存され、すべての選択/更新操作は非常に高速に動作します。

于 2013-03-05T08:23:31.757 に答える