2011-01-02 5 views
0

Мне нужен трек, который пользователь читает на веб-сайте.Отслеживание просмотров страниц и отображение связанных данных

Затем с этими данными, иметь возможность знать:

1) - топ-N статьи прочитали в последний час/день/неделю/месяц

2) - показать рекомендации ("пользователи, которые читали эту , также читал, что ")

3) - так же, как (1), но для конкретного раздела на сайте

поскольку сайт имеет высокий трафик (> 1M просмотров/день) я не могу использовать СУРБД для этого.

Я начал смотреть на NoSQL (специально для кассандры), и поскольку он для меня все новый, я не уверен, что это то, что мне нужно или нет.

Я уверен, что я не первый, кому что-то нужно, но не смог найти ссылки/статьи, дающие мне указания о том, как это сделать. Является ли NoSQL лучшим aproach? Любые советы по модели данных?

Спасибо.

ответ

0

SQL сделает это вполне счастливо. Миллион просмотров в день - всего десять в секунду; большинство баз данных будут делать несколько сотен легко.

У вас уже есть таблица статей и таблица для пользователей; вам нужно будет создать таблицу Read, которая является отношением «многие ко многим» между пользователями и статьями и, возможно, временной меткой. Каждый раз, когда вы подаете статью, вы добавляете запись в таблицу «Чтение», в сущности говоря «Пользователь x просто читает статью y».

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

Для скорости вам также может быть полезно предварительно обработать часть этой информации и выполнить выборочную денормализацию, например, сохранение количества статей для каждой статьи как часто это было прочитано

Edit:.

У меня возникает соблазн обратиться к http://nosql.mypopescu.com/post/1016320617/mongodb-is-web-scale - «NoSQL» не уменьшает объем требуемой работы или волшебным образом заставляет его работать быстрее (хотя часто бывает проще бросить на него больше аппаратных средств, , если вы можете использовать фразу проблема в форме, которая ему нравится).

«Пользователи, которые читают это также читают:»

SELECT 
    Article.id, OtherArticle.id as oid, COUNT(*) AS cnt 
FROM 
    Article 
    JOIN Read AS R1 ON Article.id=R1.article_id 
    JOIN Read AS R2 ON R1.user_id=R2.user_id AND NOT R1.article_id=R2.article_id 
    JOIN Article AS OtherArticle on R2.article_id=OtherArticle.id 
GROUP BY 
    OtherArticle.id, OtherArticle.title 
ORDER BY 
    cnt DESC, OtherArticle.title ASC 

Непременно посмотреть, как долго это берет, чтобы бежать; Я бы, вероятно, сохранил результат в качестве справочной таблицы для немедленного использования и обновил его фоновым процессом каждые пару часов.

+0

да, но это масштаб? через месяц у меня есть записи 40M, когда пользователь посещает статью, я должен показать им «пользователи, которые видели это, также видели это». это объединение и группировка большого количества записей. Поскольку новый контент постоянно добавляется, я не могу «предварительно вычислить эти вещи», – Zake80

0

Хмм easyrec имеет точно функциональность вам нужно будет и может управлять действиями 1M (он использует MySQL) проверить тему на форуме о максимальных действий: forum topic