この種の問題では、一部のアルゴリズムは他のアルゴリズムよりも優れており、アルゴリズムのパフォーマンスはデータの「形状」とサイズに依存することを理解する必要があります。
すべてのユーザーのアイテム セットを他のすべてのユーザーと比較することは、小規模なドメイン データセット (たとえば、1000 人またはユーザー、場合によっては 10,000 人で、アイテム数が類似している) には適しているかもしれませんが、「n 乗」の問題 (または順序) です。そのあたりで、私の Big O は控えめに言っても錆びています!):
Users Comparisons
----- -----------
2 1
3 3
4 6
5 10
6 15
n (n^2 - n)/2
したがって、ユーザー ドメインが 100,000 の場合、4,999,950,000 セットの比較が行われます。
この問題に対するもう 1 つのアプローチは、関係を逆にすることです。そのため、Map Reduce ジョブを実行して、アイテムのマップをユーザーに生成します。
'a' : [ 'u1', 'u2', 'u3' ],
'b' : [ 'u2' ],
'c' : [ 'u1' ],
'f' : [ 'u2', 'u3' ],
'h' : [ 'u1' ],
そこから、アイテムごとにユーザーを反復処理し、ユーザー ペアを出力できます (カウントは 1 です)。
'a' would produce: [ 'u1_u2' : 1, 'u1_u3' : 1, 'u2_u3' : 1 ]
'f' would produce: [ 'u2_u3' : 1 ]
最後に、各ユーザーのペアリングの合計を作成します。
[ 'u1_u2' : 1, 'u1_u3' : 1, 'u2_u3' : 2 ]
これは、あなたが興味を持っている動作 (u1 と u3 の両方の項目セットの二重の a) を生成しませんが、初期実装について詳しく説明します。
通常、ドメイン セットに共通のアイテムを持たないユーザー、ユーザーごとのアイテムの数が少ない、または多数の異なる値を持つアイテム ドメインが含まれていることがわかっている場合、このアルゴリズムはより効率的です (以前は比較していました)。 2 つのセットが交差する可能性は低い)。私は数学者があなたのためにこれを証明できると確信していますが、私はそうではありません!
これには、以前と同じ潜在的なスケーリングの問題もあります。つまり、100,000 人のユーザー全員が共通に持っているアイテムがある場合でも、40 億のユーザー ペアを生成する必要があります。これが、やみくもにアルゴリズムを適用する前に、データを理解することが重要である理由です。