0

2つのテーブルがあるとしましょう

posts
 - post_id
 - image

favorites
 - fav_id
 - post_id
 - user_id

ユーザーがサイトに入ると、データベースから 10 件の投稿が取得されて表示されます。私が今行っていることは、これらのテーブルを結合して結果をループすることであり、そこでユーザーが何かをお気に入りに追加したかどうかを確認できます。

このようなもの:

SELECT p.*, f.fav_id
FROM posts p
LEFT JOIN favorites f
ON p.post_id = f.post_id AND user_id = $user_id
LIMIT 10 

これは問題ありませんが、 memcachedを使用して結果をキャッシュしたいのですが、キャッシュが機能しないため、ユーザーごとにクエリを変えることはできません。すべてのユーザーが同じキャッシュ エントリから投稿を読み込めるようにします。

私が最初に考えたのは、ユーザーがログインしたときにすべてのユーザーのお気に入りを取得してキャッシュに保存し、サイトの投稿を閲覧するときにそれを使用できるということでした。私の友人は、ユーザーが多くのお気に入りを持ち、多くのユーザーが同時にログインしている場合、これが重くなる可能性があると示唆しました。

これにどうアプローチしたらいいのかわからないのですが、皆さんはどう思いますか?

ありがとう

4

1 に答える 1

0

クエリ自体は特に負荷がかかるわけではないので、サーバーの負荷に関しては問題ないはずです。

あなたが言及していることについては、明確ではないようです。少なくとも私にとっては。

ユーザーのお気に入りに関するキャッシュを作成する場合は、異なるデータ、特に user_id を使用しているため、常に別のクエリが必要です。あなたが望むのは、それを多くのキャッシュ、ユーザーごとに1つと呼びましょう。ユーザーが何か新しいものをお気に入りとして選択したときの特定のキャッシュ。

クエリを使用して、セッションの開始時に各ユーザーのお気に入りをチェックし、ユーザーが何か新しいものを追加した場合は、セッションが終了するまでそれらを保持します。その後、セッションでそのリストを更新します。

更新
あなたのコメントを考慮して、ユーザーがお気に入りのリストに何かを追加したときにキャッシュを再構築し、ユーザーのダウンタイムを減らします。

また、単純なクエリを使用して、ユーザーがログインしたときにこれらの結果を取得することもできます。単純なクエリはすばやく実行され、すぐに結果が得られます。

ただし、お気に入りをセッションにロードすると、ユーザーが多すぎる、セッションに保存する情報が多すぎる、または常にデータとクエリのフローが多すぎる場合を除き、パフォーマンスに関しては問題ありません。

于 2012-10-21T13:30:38.720 に答える