タイトルの質問がすべてを物語っており、一般的なものだと思います。
具体的な例を挙げることもできます：
similar記事にタグを付けており、タグが関連付けられた記事を検索したいと考えています。
スコア関数は 2 つの記事を見て、共通するタグの数を数えます。
スコアはどこにも保存されないため、ある記事から類似の記事を見つける必要があるたびに、スコアを計算する必要があります。
But this is too expensive.
- 一般的に、この種の問題に対する一般的な回避策は何ですか?
- 私の特定の
tag問題に対するより良いアプローチはありますか？(例: solr の moreLikeThis )
編集
それが重要な場合、私はpostgresを使用しています。
など、人々が成功裏に使用した一般的なソリューションを探していyou should batch calculate the score and save it somewhereます...
通常、このような状況を処理する方法は、結果を事前に計算することです。いくつかの方法でそれを行うことができます:
を。行が追加、更新、またはソース テーブルから削除されると、カウントを更新するトリガー (SQL 99 標準で追加) のようなものを使用できます。このソリューションでは、情報の取得を大幅に向上させるために、ソース テーブルの挿入、更新、および削除に (おそらく) 小さな犠牲を払っています。
b. ライブ データからレポート データまでのある程度のレイテンシを許容できるデータ ウェアハウスを使用できます。つまり、データ ウェアハウスからクエリされたデータが、許容される分数、時間数、日数、または週数だけ古くなることを受け入れるということです。データ ウェアハウスは、ライブ OLTP (オンライン トランザクション処理) データを定期的にクエリすることによって機能し、事前計算された結果を含む OLAP (オンライン分析処理) データベースを更新します。次に、OLAP データまたは OLTP と OLAP データの組み合わせからレポートを実行します。同等の結果を得るために正式なデータベース ウェアハウスは必要ありません。更新された結果でテーブルを定期的に更新するタイマーで実行されるプロシージャを作成できます。