要件の説明:
周辺プラットフォームはインターフェイスを呼び出し、攜帯電話番號(hào)に基づいてユーザーの曲リストの推奨情報(bào)をクエリします。各ユーザーは約 1,000 個(gè)の推奨情報(bào)を持ちます。各推奨情報(bào)には、曲 ID、曲が含まれます名前、著作権ID、オーディションアドレスフィールド。
複數(shù)のテーブルをクエリする必要があります。各クエリには約 4 秒かかります。クエリが完了したら、インターフェイスに戻る前にデータを組み立てる必要があります。
戻り値の形式は json です。この場(chǎng)合、インターフェイスの戻りは遅くなります。
事前にredisクラスターにデータを入れておこうかとも考えましたが、ユーザー數(shù)が約500萬人、ユーザーごとの推奨情報(bào)のサイズが200kb程度あり、redisを保存すると大量のデータを消費(fèi)してしまうため斷念しました。記憶があるので拒否しました。しかし、他に良い解決策が思いつきません。そのような要求に対処する方法について、何か良い提案があれば教えていただけませんか。ありがたい！
4
0
0
ボトルネックは、多くのテーブルをクエリするのに 4 秒かかることです。このロジックに最適化できる點(diǎn)はありますか?そうでない場(chǎng)合は、この 4 秒を費(fèi)やさなければなりません。他のデータ送信形式では、ネットワーク通信時(shí)間をどれだけ最適化しても 4 秒未満にすることはできません。
クライアントがユーザーに気づかれずにレコメンデーションリクエストを送信したか、クエリロジックが最適化されています。
リンク リスト クエリの場(chǎng)合は、SQL を個(gè)別に投稿してみてはいかがでしょうか。 SQで多くの時(shí)間を過ごしているようですね
1. 一度に 1,000 個(gè)の商品を返品しますか?一度に 50 項(xiàng)目を?qū)g行したほうが早いでしょうか?複數(shù)のページングリクエストについてはどうすればよいでしょうか?
2. キャッシュ ソリューションを直接無効にするのは不適切だと思いますが、500 W を超えるすべてのユーザーがアクティブ ユーザーであるとは限りません。アクティブ ユーザー數(shù)の推定には Redis を使用できますか?
3
[推奨情報(bào)]にID屬性を追加してredisに保存します。この量は大きくないはずです。
各ユーザーのおすすめ情報(bào)もredisに保存されますが、【おすすめ情報(bào)】は1,000IDのみ保存されます。
この場(chǎng)合、各ユーザーのおすすめ情報(bào)は200kbに??はなりません。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
