Как лучше всего реализовать «Количество просмотров»?

Question

На любом веб-сайте, например, в StackOverflow, каждый вопрос имеет количество просмотров, и пользователь, прочитавший вопрос, но прочитавший ранее, не будет считать дважды.

У меня есть некоторые идеи о том, как это реализовано и какие таблицы используются для этого.

Как вы думаете, как лучше всего это реализовать?

Answer 1

На моем веб-сайте я занимаюсь подсчетом просмотров гостей и «массой данных», которая получается путем деления количества просмотров с использованием случайного числа.

Допустим, у меня есть генератор случайных чисел с хорошим распределением между 0 и 1, и я получаю 100 000 просмотров в день на определенной странице. Если я вызываю функцию 'logView ()' при каждом просмотре, но при этом генерирую новое случайное число и действительно записываю представление в БД только тогда, когда случайное число <0,001, то для 100 000 просмотров я попаду только в БД 100 000 * 0,001 = 1000 раз. </p>

Если я хочу вернуть количество просмотров, то я просто делю номер своей БД на то же значение, например. 1000 / 0,001 = 100 000. Это приблизительно с точностью до 1000 просмотров.

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

Кроме того, страница с количеством просмотров только 1000 может даже не получить 1 в числе просмотров, но если у вас страница с 100 000 просмотров, то страница с 1000 является довольно незначительной.

Answer 2

У меня есть несколько вариантов, как я вижу.

печенье

Вы можете сохранять куки в браузере пользователей для каждой страницы, на которой вы просматриваете просмотры. Проверьте наличие файлов cookie и не регистрируйте просмотр, если файл cookie уже существует.

Недостатком является то, что он не будет работать, если куки отключены или кто-то пытается играть в систему.

С положительной стороны вам не нужно беспокоиться о хранении потенциально миллионов / миллиардов строк табличных данных.

База данных

У вас есть запись для каждого просмотра. Связать эту запись с пользователем, например, MemberID, IP-адрес; то, что должно быть уникальным для пользователя. IP не идеален, но достаточно хорош, если вы не требуете от пользователей входа в систему.

Таким образом, у вас будет, например, таблица со следующими столбцами,

• ArticleID (внешний ключ)
• UserID (внешний ключ)
• Дата

Дата будет полезна по нескольким причинам,

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

Если ваше приложение станет популярным в этой ситуации, вам придется разобраться с последствиями для хранилища. Я запускаю популярное приложение Facebook, в результате которого каждый день добавляется более 100 000 просмотров. Реально, хотя, если ваше приложение становится настолько популярным, что становится проблемой, у вас будет гораздо больше проблем, с которыми вам придется иметь дело.

Answer 3

Краткий ответ: зависит!

• Это действительно зависит от того, насколько точным является количество просмотров, допустимо ли, чтобы один человек был зарегистрирован два или три раза?
• Это зависит от того, для чего вы собираетесь использовать данные. Если вы хотите сделать другие аккуратные вещи с данными (статистика, список последних просмотров и т. Д.), Вы можете рассмотреть возможность сохранения всех отдельных представлений в базе данных. Это может привести к появлению огромной таблицы, так что вы должны разобраться с этим перед ее реализацией.

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

Answer 4

Похоже, что stackoverflow не учитывает гостевых (незарегистрированных) пользователей, просматривающих тему. Проблема с подсчетом просмотров анонимного пользователя заключается в том, что ваш счетчик может быть запущен. Кто-то всегда может удалить cookie и просмотреть снова. Регистрация представлений является самым безопасным решением для точности, но, конечно, у вас есть две основные проблемы: размер таблицы и отсутствие гостевых / анонимных пользователей. Меня удивляет, что stackoverflow не регистрирует гостевых (незарегистрированных) пользователей. Я думаю, что большинство просмотров будут получены от этих пользователей, выполняющих поиск в Google.

Answer 5

Когда большинство посетителей вашего сайта зарегистрированы, относительно легко убедиться, что ни один из них не засчитан дважды.

Я не уверен, считает ли SO количество просмотров гостей. Я полагаю, что могу проверить, но уже поздно.

Answer 6

Я постараюсь дать ответ с функциональной точки зрения.

количество просмотров на пользователя - для зарегистрированных пользователей. для анонимных пользователей - за сеанс.

счетчик приращений при первом просмотре и при любом просмотре после значительного обновления кем-либо, кроме человека, который просматривает элемент

вид плаката на момент создания не должен учитываться

Вы можете представить, что делаете это тоже проще, но я пытался придумать идеальное решение.