Отслеживание журнала активности пользователя - SQL против NoSQL? - PullRequest
7 голосов
/ 23 мая 2011

У меня есть база данных mysql, содержащая таблицы типа Пользователь, плейлист, видео, теги .

Исходя из этого, я хотел бы собрать активность пользователя в приложении. Примеры использования могут быть:

a.) (user) joined (app) on (date)  
b.) (user) created playlist (playlist) on (date)  
c.) (user) added (video(s)) to playlist (playlist)  
d.) (user) added tags (tag(s)) to video in playlist (playlist)  

Учитывая такие данные, что было бы лучшей альтернативой для разработки схемы действий пользователя? relational(I am using MySQL) or NoSQL(non-relational, like MongoDB)

Любимый NoSQL
a.) Другое дело, что освещенная активность будет огромной, извлечение данных должно быть быстрым, я прочитал, что Ориентированная на документы база данных хорошо работает в таких сценариях, поскольку объединение таблиц не требуется
б.) Поскольку журнал активности может содержать не одну, а много переменных в зависимости от происходящего действия, реляционная схема может быть не лучшим решением.

Я хотел бы узнать больше об этом, пожалуйста, поделитесь знаниями :)
Спасибо

Ответы [ 2 ]

5 голосов
/ 23 мая 2011

Вы правы, основная проблема в любой реляционной базе данных - это объединение.

Итак, вы можете создать систему отслеживания в mongodb или в mysql, просто избегайте объединений:

Итак, структура будет такой:

id 
activity_type - int
user_id
date
field1
field2
filed3

где Activity_type (Регистрация = 1, CreatedPlaylist = 2, ...)

Чтобы избежать объединения с пользовательской таблицей, вы должны добавить некоторые связанные с пользователем данные (данные, которые вам нужно отобразить, например, first_name, last_name) в каждую строку действия.

С предоставленным выше решением вы можете остаться с MySQL, и скорость будет такой же. Mongodb будет быстрее, когда вы встраиваете в документ много вещей, которые вам нужно объединить в реляционную базу данных.

1 голос
/ 23 мая 2011

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

Однако, когда вам не нужно балансировать книги, или убедитесь, что вы случайно не продали больше виджетов, чем у вас, используйте то, что вам удобно. Монго, Диван, что угодно.

...