Отслеживание просмотров заданной строки

Question

У меня есть сайт, где пользователи могут просматривать довольно большое количество постов.Каждый раз, когда это делается, я запускаю запрос, подобный UPDATE table SET views=views+1 WHERE id = ?.Однако у такого подхода есть ряд недостатков:

• Нет никакого способа отслеживать, когда происходят просмотры страниц - они просто увеличиваются.
• Обновление таблицы, которое часто, насколько я понимаю, очищает кэш MySQL от строки, тем самым замедляя следующий ВЫБОР этой строки.

Поэтому я рассматриваю возможность использования подхода, при котором я создаю таблицу, скажем:
object_views { object_id, year, month, day, views }, так что каждый объект имеет одну строку pr.день в этой таблице.Затем я бы периодически обновлял столбец views в objects таблицу, чтобы мне не приходилось постоянно выполнять дорогостоящие соединения.

Это самое простое решение, которое я могу придумать, и, похоже, оно также оказывает наименьшее влияние на производительность.Вы согласны?

(Сайт построен на PHP 5.2, symfony 1.4 и Doctrine 1.2 на случай, если вам интересно)

Редактировать:
Цель заключается в том, не веб-аналитика - я знаю, как это сделать, и она уже существует.Есть две цели:

• Позволяет пользователю видеть, сколько раз данный объект был показан, например, сегодня или вчера.
• Разрешить модераторам сайта видеть простой просматривайте статистику, не заходя в Google Analytics, Omniture или любое другое решение.Кроме того, результаты в серверной части должны быть в режиме реального времени, функция, которую GA в настоящее время не может предложить.Я не хочу использовать API Analytics для получения данных об использовании (не в реальном времени, GA требует javascript).

Answer 1

Цитата :Обновление таблицы, которое часто, насколько я понимаю, очищает кэш MySQL от строки, тем самым замедляя следующий ВЫБОР этой строки.

Существует гораздо больше, чем это.Это убийца базы данных.Я предлагаю вам составить таблицу следующим образом :object_views { object_id, временная метка} Таким образом, вы можете агрегировать данные по object_id (функция count()).Таким образом, каждый раз, когда кто-то просматривает страницу, вы будете вставлять запись в таблицу.Время от времени вы должны очищать старые записи в таблице.Инструкция UPDATE - это ЗЛО :) На большинстве платформ она в основном помечает строку как удаленную и вставляет новую, тем самым делая таблицу фрагментированной.Не говоря уже о проблемах с блокировкой .

Надеюсь, это поможет

Answer 2

Аналогично Rage, вы просто не получите тех же результатов, делая это самостоятельно, когда существует миллион сторонних инструментов ведения журнала.Если вы отслеживаете на ежедневной основе, то базовая программа, такая как webtrends, вполне способна отслеживать переходы, особенно если ваш URL содержит идентификаторы элементов, которые вы хотите отслеживать...Я не могу достаточно подчеркнуть это, все дело в URL, когда дело доходит до этих инструментов (Wordpress, например, допускает множество различных конструкций URL)

Теперь, если вы изучаете отслеживание "показов", то это еще одна игра с мячом, потому что вы, вероятно, отслеживаете каждый объект, страницу, пользователя и, возможно, взвешенное значение, основанное на местоположении на странице.Если это так, вы можете повысить свою производительность, разместив отслеживание на другом сервере, где вы можете запустить и забыть.В прошлом я работал с этим, используя SQL-обновление по идентификатору и строковой версии даты...таким образом, когда дата меняется с 20091125 на 20091126, это простой запрос без накладных расходов, скажем, функции datediff.

Answer 3

Сначала просто краткое замечание, почему бы не объединить год, месяц, день в DATETIME, на мой взгляд, это имело бы больше смысла.

Также я не совсем уверен, какова точная причина, по которой вы это делаете, если это для целей маркетинга / веб-статистики, вам лучше использовать инструмент, созданный для этой цели.

Теперь есть два больших семейства инструментов, способных дать вам представление о статистике доступа к вашему веб-сайту на основе журналов (статусы вероятно, самый популярный), основанный на изображении ajax / 1pixel (google analytics был бы самым популярным).

Если вы предпочитаете создавать свою собственную базу данных статистики, вам, вероятно, удастся легко создать анализатор журналов с помощью PHP.Если вы считаете, что разбор журналов apache (или IIS logs) слишком обременителен, вы, вероятно, могли бы заставить свое приложение выводить некоторые пользовательские журналы, отформатированные более простым способом.

Также еще одним возможным решением является использование кэшированный в памяти, демон предоставляет какой - то счетчик , который вы можете приращение.Вы можете просматривать журнал там, и у вас есть скрипт, собирающий результат каждый день.

Answer 4

Если вы собираетесь это сделать, почему бы просто не регистрировать каждый доступ?MySQL может достаточно хорошо кэшировать вставки в непрерывных таблицах, поэтому заметного замедления из-за вставки быть не должно.Ты всегда можешь убежать Показывать профили чтобы увидеть, каково на самом деле снижение производительности.

По вопросу даты и времени вы всегда можете использовать GROUP BY MONTH( accessed_at ) , YEAR( accessed_at) или WHERE MONTH(accessed_at) = 11 AND YEAR(accessed_at) = 2009.