2

Solr ドキュメントに対する個々のユーザーの評価を提示する戦略を探しています。すなわち。ユーザーはドキュメントに 1 ~ 5 の評価を付けることができます。私は、ユーザーが検索するときにそれを提示したいと考えています。

2 つの一般的なアプローチを考えることができます。

  1. 評価を RDBMS に保存し、solr の結果を取得してクエリを実行し、データをビジネス ロジックにマージします。

  2. どういうわけか、この評価情報も solr に保存して、特定のユーザーのデータを返すようにします。私が考えることができるのは、ユーザー ID と評価の値を持つ属性名だけです。

大規模なユーザーベースを想定すると、アプローチ 2 が手に負えなくなるのではないかと心配しています。solrドキュメントをどのくらい「広く」使用できますか? ドキュメントに何万もの属性を配置できますか? パフォーマンスへの影響は、SQL db での 2 回目のヒット (アプローチ 1) よりもアプローチ 2 の方が優れていますか?

私が考えていない他のアプローチはありますか?

4

3 に答える 3

0

3 番目のオプションは、ドキュメント ID、ユーザー ID、およびユーザーがそのドキュメントに関連付けたスコアのみを含む追加の Solr インデックスを追加することです。ドキュメントとユーザーごとにスコアを照会するのは非常に簡単で迅速です。

于 2010-08-09T13:08:15.883 に答える
0

アプローチ番号 1 を使用しました。ユーザーごとの評価の数が少ない (おそらく 1000 未満) ため、ログイン時にすべての評価をキャッシュし、メモリに保存します。次に、SOLR の結果を表示するときに、必要に応じて評価を適用するだけで非常に迅速です。

これにより、結果ごとにデータベースを呼び出す必要がなくなり、サーバーのパフォーマンスが大幅に低下することもありません。さらに、ユーザーが評価を更新すると、DB を更新してキャッシュを無効にするだけです。SOLR ドキュメントに対して UPDATE 呼び出しを行う必要はありません。

于 2010-08-09T18:42:58.247 に答える
0

私は 2 番を選び、定期的にのみ評価を更新します。そうすれば、Solr によって計算された関連性スコアに評価を組み込むことができます。

あなたが Digg/Reddit のように上/下の投票が表示される内容に大きな影響を与えるか、ドキュメントの新しさなどスコアリングの別の要因に過ぎないかによると思います。それが別の要因である場合は、ドキュメントを 1 日、1 週間、または 1 か月に 1 回、静かな時間に更新してください....

于 2010-08-10T20:05:14.187 に答える