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