私が現在取り組んでいるプロジェクトには、約 200,000 人のユーザーがいます。これらのユーザーごとに、他のユーザーとの類似度を定義しました。これにより、200000x200000 の類似度マトリックスが生成されます。ちょっと大きい。各エントリを計算する単純な (Ruby の) アプローチでは、数日かかります。
行列フィールドの計算を実行可能にするために、どのような戦略を採用できますか? この獣をどのデータ ストアに配置する必要がありますか?
2051 次
4 に答える
3
ここに回答の一部を示します。適切な回答を許可するには、あなたが私たちに言ったことにはまだギャップが多すぎますが、それらを自分で埋めることができます. あなたが私たちに言ったことすべてから、あなたの仕事の主要な部分は大きな類似性マトリックスを効率的に計算することではないと思います.主要な部分はそのようなマトリックスから効率的に値を取得し、マトリックスを効率的に更新することだと思います.
既に決定したように、マトリックスは疎で対称的です。どれだけまばらかを知ることは役に立ちます。これにより、必要なストレージが大幅に削減されますが、どの程度かはわかりません。
ユーザー プロファイルの更新について少しお話しいただきましたが、類似性マトリックスを頻繁に更新する必要はありますか? 私の予想 (別の仮定) は、ユーザーが自分のプロファイルを変更しても、類似度の測定値が急速または急激に変化しないことです。このことから、数分 (場合によっては数時間) 遅れた類似性尺度を使用しても深刻な害はないと仮定します。
これはすべて、データベースのドメインに私たちを連れて行くと思います。データベースは、あなたが示したボリュームの保存された類似性測定への高速アクセスをサポートするはずです。メジャーのバッチ更新を行い、プロファイルが変更されたユーザーのメジャーのみを、要求とコンピューターの能力の可用性に合わせて間隔を置いて更新することを検討しています。
類似度マトリックスの最初のバージョンの最初の作成に関しては、バックグラウンドで 1 週間かかるとしたら、1 回だけで済みます。
于 2012-08-24T11:33:47.463 に答える
0
メジャーはおそらく対称であるため、データベースに格納する必要があるのはマトリックスの半分だけです。しかし、これはあまり役に立ちません。多数のペアがある場合は、すべてのペアをメジャー ゼロで保存することを避けることもできます。
各ユーザーの上位 10 人の最も近いユーザーなど、実際に表示されるデータのみを保存します。
そして、他のすべてのユーザーペアの類似度をオンザフライで計算します。
何も保存しないかもしれません。
于 2012-08-24T09:11:04.737 に答える
0
マトリックスを保存し、特にそれに基づいて何かを計算することは悪夢です。おそらく、類似度測定では浮動小数点数 (4 バイト) が使用されます。つまり、圧縮されていないストレージ サイズは 200000**2 * 4 バイト = 160 GB です。
この問題には、4 つの概念的な解決策があります。
データ圧縮:
- 最も簡単: データ型として char を使用します (情報の損失、サイズが 4 分の 1 に縮小されます。データを新しい範囲にスケーリングすることを忘れないでください!)
- 対称性を使用: 行列の半分のみを保存します。しかし、それを操作するのは悪夢になります
- 圧縮アルゴリズムを使用します。長所: いつでも適用できます。短所: 操作が遅くなります。
データ削減: ユーザーをクラスター化してから、クラスターの類似性マトリックスを構築できます。クラスターのサイズがそれぞれ 200 の場合、1000x1000 のマトリックスしかないため、それを格納するのに 4MB しか必要ありません。速度や堅牢性など、他の利点もあるかもしれません。
Horizontal Scaling : 大きなマシンを使用します。Amazon には、わずか 3,970 米ドルで 2 TB のメモリを搭載したものがあります ;-)
垂直方向のスケーリング: すぐに処理できる大きなマトリックスのチャンクであるブロック マトリックスを構築します。
于 2019-04-25T05:53:16.780 に答える