Использование CouchDB для моделирования пользовательских предпочтений / рекомендаций

Question

Я работаю над системой рекомендаций, использующей две основные сущности: пользователей и объекты. Показатели сходства пользователей будут предварительно рассчитаны на основе существующих пользовательских данных. Затем, поскольку различные пользователи «помечают» объекты, объекты будут рекомендованы каждому пользователю (в зависимости от того, что было помечено аналогичными пользователями).

Я новичок в NoSQL и не знаю, как лучше всего моделировать а) события пользовательских флагов и б) рекомендации для конкретных пользователей. Два варианта кажутся мне очевидными:

1) Опция «Heavyweight»: хранить все соответствующие данные в первичных объектах. E.g.:

UserA
    FlaggedItems
        FlaggedItemA
        FlaggedItemB
        FlaggedItemC
    RecommendedItems
        RecommendedItemA
        RecommendedItemB
        RecommendedItemC

или

ItemA
    FlaggedBy
        UserA
        UserC
        UserR
    RecommendedTo
        UserB
        UserD
        UserX

2) Опция «Lightweight»: хранить данные «Flag» и «Рекомендации» в гранулированных объектах. E.g.:

FlagEvent
    FlaggedBy
        UserA
    FlaggedItem
        ItemA
    DateTime

RecommendationEvent
    RecommendationTo
        UserC
    RecommendedItem
        ItemB
    DateTime

Я предполагаю, что облегченный метод будет более масштабируемым, так как объекты User / Item не будут постоянно изменяться, синхронизация клиента будет включать захват пользовательских пользовательских флагов FlagEvents и Рекомендации, и не будет шансов, что несколько пользователей попытаются изменить один и тот же объект одновременно. Но я новичок в CouchDB / noSQL и приветствую мысли более опытных пользователей. Что бы вы предложили?

Answer 1

В целом, системы FlagEvent и RecommendationEvent больше всего похожи на типичные модели CouchDB.

С рекомендациями иметь документ на «событие» аккуратно, потому что сводная рекомендация пользователя, скорее всего, сводная.сокращение тех событий.«Вот ваша главная рекомендация. А вот и другие, которые вам могут понравиться».Примерно так.

Добавляя, изменяя или удаляя отдельные «атомарные» элементы рекомендаций, вы влияете на конечный результат.

Аналогично, наличие события флага работает так же.Как правило, флаг (или «нравится», или «+1», или любой другой) является уникальным для пользователя и элемента.Поэтому вы можете использовать _id для хранения чего-то вроде username eventid пар.Тогда будет невозможно пометить что-либо дважды, потому что у каждого пользователя / элемента есть 1 и только 1 документ для представления этого флага.Создайте или удалите документы, чтобы пометить / отменить пометку для пользователя.

Очевидно, вы знаете свои данные лучше всего.Но это мои первые идеи.Конечно, когда кто-то говорит «механизм рекомендаций», люди часто сразу думают «база данных графиков», а не «база данных документов» - однако я не знаю ни одного высококлассного механизма рекомендаций, построенного на графических базах данных с открытым исходным кодом (пока).