Utilisation de CouchDB pour modéliser les préférences/recommandations de l'utilisateur

Question

Je travaille sur un système de recommandation utilisant deux entités de base: les utilisateurs et les objets. Les mesures de similarité utilisateur seront pré-calculées en fonction des données utilisateur existantes. Ensuite, comme divers utilisateurs "marqueront" les objets, les objets seront recommandés à chaque utilisateur (en fonction de ce qui a été signalé par des utilisateurs similaires).

Je suis novice en NoSQL et je ne sais pas quelle est la meilleure façon de modéliser a) les événements d'indicateur utilisateur, et b) les recommandations spécifiques à l'utilisateur. Deux options me semblent évidentes:

1) Option "poids lourd": stocker toutes les données pertinentes dans les objets primaires. .: par exemple

UserA 
    FlaggedItems 
     FlaggedItemA 
     FlaggedItemB 
     FlaggedItemC 
    RecommendedItems 
     RecommendedItemA 
     RecommendedItemB 
     RecommendedItemC 

ou:

ItemA 
    FlaggedBy 
     UserA 
     UserC 
     UserR 
    RecommendedTo 
     UserB 
     UserD 
     UserX 

2) option "légère": les données magasin "Drapeau" et "Recommandation" dans les objets granulaires. Par exemple:

FlagEvent 
    FlaggedBy 
     UserA 
    FlaggedItem 
     ItemA 
    DateTime 

RecommendationEvent 
    RecommendationTo 
     UserC 
    RecommendedItem 
     ItemB 
    DateTime 

Mon hypothèse est que la méthode légère serait plus échelonnable que les objets utilisateur/article ne seront pas modifiés en permanence, la synchronisation client impliquerait l'accaparement des FlagEvents spécifiques à l'utilisateur et RecommendationEvents, et il n'y aurait pas chance de plusieurs utilisateurs essayant de modifier le même objet simultanément. Mais je suis nouveau à CouchDB/noSQL et accueille les pensées des utilisateurs plus expérimentés. Que suggérerais-tu?

Answer 1

En général, les systèmes FlagEvent et RecommendationEvent ressemblent le plus à des modèles CouchDB typiques. Avec des recommandations, avoir un document par "événement" est net parce que le résumé de la recommandation d'une grande image de l'utilisateur est probablement une réduction de ces événements. "Voici votre première recommandation et voici quelques autres que vous pourriez aimer." Quelque chose comme ca. En ajoutant, en modifiant ou en supprimant des éléments de recommandation "atomiques" individuels, vous influencez la sortie finale.

De même, avoir un événement de drapeau fonctionne de la même manière. En règle générale, un indicateur (ou "like", ou "+1" ou autre) est unique pour un utilisateur et un élément. Par conséquent, vous pouvez utiliser le _id pour stocker quelque chose comme username eventid paires. Ensuite, il sera impossible de marquer deux fois un objet car chaque combinaison utilisateur/élément a 1 et 1 seul document pour représenter ce drapeau. Créez ou supprimez des documents pour marquer/unflag pour un utilisateur.

De toute évidence, vous connaissez le mieux vos données. Mais ce sont mes premières idées. Bien sûr, quand quelqu'un dit «moteur de recommandation», les gens pensent souvent immédiatement «base de données graphique» et non «base de données de documents». Cependant, je ne connais pas encore de moteurs de recommandation de haut niveau.