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

0

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

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

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

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

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

Edit:
Цель - не веб-аналитика. Я знаю, как это сделать, и это уже на месте. Есть две цели:

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

4 ответа

1
Лучший ответ

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

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

Поделиться
0

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

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

Поделиться
  • 0
    Это привело бы к огромному количеству строк, тогда я бы предпочел немного агрегировать данные перед их сохранением.
0

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

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

Поделиться
  • 0
    Я обновил вопрос, чтобы лучше отразить то, что я ищу.
0

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

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

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

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

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

Поделиться
  • 0
    Я уже использую Google Analytics и clicktale, поэтому я хорошо разбираюсь в части веб-аналитики. Я понимаю вашу точку зрения относительно поля DATE , но вычисления относительно того, «сколько просмотров у меня было в ноябре», насколько я знаю, были бы быстрее, если бы у вас просто было 3 целочисленных поля вместо этого. Разбор логов определенно не вариант, который я бы выбрал.
  • 0
    Для ведения журнала я обычно использую отдельные столбцы года, месяца, дня и часа, потому что это значительно упрощает создание статистики. GROUP BY hour, day, month, year для ежечасной статистики, GROUP BY month, year для месячной статистики и т. Д.
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню