2

私は、ユーザーとオブジェクトという 2 つの基本エンティティを使用するレコメンダー システムに取り組んでいます。ユーザーの類似性指標は、既存のユーザー データに基づいて事前に計算されます。次に、さまざまなユーザーがオブジェクトに「フラグを立てる」と、オブジェクトが各ユーザーに推奨されます (同様のユーザーによってフラグが付けられたものに基づいて)。

私は NoSQL を初めて使用し、a) ユーザー フラグ イベント、および b) ユーザー固有の推奨事項をモデル化する最良の方法がわからない。私には2つのオプションが明白に思えます:

1) 「ヘビーウェイト」オプション: すべての関連データをプライマリ オブジェクトに保存します。例えば：

UserA
    FlaggedItems
        FlaggedItemA
        FlaggedItemB
        FlaggedItemC
    RecommendedItems
        RecommendedItemA
        RecommendedItemB
        RecommendedItemC

また：

ItemA
    FlaggedBy
        UserA
        UserC
        UserR
    RecommendedTo
        UserB
        UserD
        UserX

2) 「ライトウェイト」オプション: 「フラグ」および「レコメンデーション」データを粒状オブジェクトに格納します。例えば：

FlagEvent
    FlaggedBy
        UserA
    FlaggedItem
        ItemA
    DateTime

RecommendationEvent
    RecommendationTo
        UserC
    RecommendedItem
        ItemB
    DateTime

User/Item オブジェクトが常に変更されることはなく、クライアント同期にはユーザー固有の FlagEvents と RecommendationEvents を取得する必要があり、複数のユーザーが同じものを変更しようとする可能性がないため、軽量メソッドの方がスケーラブルであると思います。オブジェクトを同時に。しかし、私は CouchDB/noSQL を初めて使用するので、経験豊富なユーザーからの意見を歓迎します。何を提案しますか？

4

1 に答える 1

2

一般に、FlagEventandRecommendationEventシステムは典型的な CouchDB モデルに最も似ています。

レコメンデーションでは、「イベント」ごとにドキュメントを用意するのが適切です。ユーザーの全体像のレコメンデーションの要約は、おそらくそれらのイベントの削減になるからです。「これがあなたの一番のおすすめです。そして、あなたが好きかもしれない他のいくつかはここにあります。」そんな感じ。

個々の「アトミック」レコメンデーション アイテムを追加、変更、または削除することで、最終的な出力に影響を与えます。

同様に、フラグイベントも同じように機能します。通常、フラグ (または「いいね」、「+1」など) は、ユーザーとアイテムに対して一意です。したがって、 を使用してペアの_idようなものを保存できます。username eventidその場合、すべてのユーザー/アイテムの組み合わせには、そのフラグを表すドキュメントが 1 つしかないため、何かに 2 回フラグを付けることができなくなります。ドキュメントを作成または削除して、ユーザーのフラグを設定/解除します。

明らかに、自分のデータを一番よく知っているのは自分です。しかし、それらは私の最初のアイデアです。もちろん、誰かが「レコメンデーション エンジン」と言うと、すぐに「ドキュメント データベース」ではなく「グラフ データベース」を連想しますが、私はオープン ソースのグラフ データベース上に構築された有名なレコメンデーション エンジンを (まだ) 知りません。

于 2011-04-04T05:05:16.217 に答える