Как наиболее эффективно отследить количество просмотров?

Question

У меня есть эта блогоподобная система (LAMP), и я хотел бы отслеживать количество просмотров каждой статьи. Теперь лучше обновлять столбец views статьи при каждом просмотре статьи или использовать временную таблицу, где я буду хранить только идентификатор статьи, а затем (скажем, каждый час) выполнять запрос что бы взять данные из временной таблицы и обновить строки в таблице Articles ? Я открыт для совершенно разных решений.

Обратите внимание, что я не могу использовать какие-либо аналитические инструменты, так как мне нужно работать с этими числами (самые популярные и т. Д.).

Answer 1

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

Кроме того, ваша проблема - конфликт блокировки записи, записывая в другую таблицу, вы просто перенесли этот конфликт в эту таблицу, и у вас будет такая же блокировка.

Я бы предложил:

1. делать ваши чтения без блокировок (NOLOCK), и только ваши записи с блокировками. Таким образом, вы блокируете только одновременное обновление количества просмотров, а не чтение данных статьи.
2. Если этого недостаточно, и вы можете справиться с некоторой потерей количества просмотров, то обновите счетчик асинхронно и не ждите, пока он вернется, чтобы показать страницу.

(Под потерей количества представлений в крайнем случае я имею в виду случаи, когда асинхронная запись завершается неудачно после того, как вы доставили страницу, потому что ваша БД вышла из строя сразу после чтения данных статьи, но до обновления счетчика просмотров)

Answer 2

Обновление таблицы статей при каждом прочтении статьи будет означать дополнительную блокировку этой таблицы (или строк, в зависимости от используемого вами механизма) .

Использование временной таблицыможет быть лучшим решением, на мой взгляд:

• либо делать необработанную вставку каждый раз при просмотре статьи без обновления
• , либо обновлять счетчик для статьи, в этом случаеtable
• или (если вы используете механизм, такой как InnoDB, который поддерживает блокировки строк и не использует блокировки таблиц) используйте что-то вроде 100 строк в статье и обновляйте одну из них случайным образомкаждый раз, когда статья просматривается
  • , таким образом у вас будет меньше одновременного доступа к блокировкам (если у вас есть 5 пользователей, читающих одну и ту же статью в одно и то же время, нет большого риска, что они попробуютобновить одну и ту же строку из 100!)
  • просто помните, что вам нужно будет суммировать значения по 100 строк на статью, чтобы получить «общую сумму», когда вы хотите посчитать, сколько раз статьябыло просмотрено.

Последнее решение, вероятно, лучшее с точки зрения параллелизма - еще раз, если вы используете движок, который поддерживает блокировки строк (т. Е. Не MyISAM) .

И время от времени запускайте задание cron, которое будет отсчитываться от этой временной таблицы, и обновляйте таблицу article.

Answer 3

«Самый эффективный способ» довольно субъективен; вам придется рассказать нам о вашей конкретной проблеме производительности.

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

Сумматор будет подсчитывать количество просмотров каждой статьи в файле журнала за период (скажем, запускать каждую минуту или две), а затем делать в одной транзакции столько необходимых обновлений, по одному для каждой статьи. Это, вероятно, не вызовет особых проблем, поскольку вы будете рассматривать только один процесс на веб-сервере, выполняющий одну транзакцию в минуту (или 2, или 5, или столько же), а не одну на веб-запрос. Загрузка базы данных будет намного меньше.