Почему количество просмотров сообщений на большинстве веб-сайтов слишком низкое?

10

Обратите внимание, что количество просмотров видео на YouTube всегда запаздывает? Например, видео содержит около 1000 комментариев и по-прежнему имеет 500 просмотров, а спустя 10000 показов.

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

Кто-нибудь знает причину этого?

Спасибо.

caching Том Такер
источник

Ответы:

20

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

Объединение этого в общее количество просмотров требует чего-то вроде выполнения, SELECT COUNT(*) FROM ...что означает, что вам нужно заблокировать таблицу во время выполнения расчета. В качестве альтернативы UPDATE ... SET num_views = num_views + 1также требуется, чтобы вы блокировали эту конкретную строку каждый раз, когда кто-то просматривает ее.

Таким образом, с точки зрения масштабируемости, гораздо эффективнее добавлять строки каждый раз, когда кто-то просматривает видео, а затем делать это SELECT COUNT(*) FROM ...каждые десять минут или около того.

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

Дин Хардинг
источник
4
Разве он не использует BigTable с остальной частью Google?
TheLQ
@ Декан Хардинг Спасибо, но разве это не означает, что таблица будет иметь миллиарды, если не триллионы, записей для веб-сайта, даже с умеренным трафиком, намного меньше youtube? Я подозреваю, что с такими массивными записями SELECT COUNT (*) будет влиять на производительность базы данных, даже если она будет запускаться только каждые 10 минут. Это также потребует больше дискового пространства для базы данных и резервного копирования. Я не говорю, что блокировка таблицы при каждом обращении к странице лучше, но мне просто трудно понять, как большие веб-сайты будут обрабатывать такие огромные данные.
Том Такер
Это не первый раз, когда я слышу это. Что меня действительно озадачивает, так это то, что увеличение счетчика потокобезопасным способом сложнее или дороже, чем добавление в список. Если вы можете решить последнее, первое должно быть действительно легко.
back2dos
2
@Tom Tucker: да, но мы говорим о Google здесь, помните :-) Один из способов, который я решил эту проблему в меньшем масштабе, состоит в том, что, как только я закончу агрегирование, я урежу таблицу, которую агрегирует Данные были рассчитаны из. Таким образом, вы никогда не получите более часа (или какой бы интервал обновления вы не использовали) «сырых» данных.
Дин Хардинг
4
Также имейте в виду, что данные в вашей таблице «действий» могут использоваться не только для расчета «количества просмотров». Вы также можете использовать его для реализации блоков IP (т. Е. «Не более 1 комментария каждые 10 секунд с одного и того же IP» и т. Д.). Вы также можете создавать графики, показывающие количество просмотров с течением времени, и другие виды вещей, которые простое num_views = num_views + 1не позволяет.
Дин Хардинг
8

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

Стив
источник
4

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

Есть несколько способов измерения просмотров страниц:

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

Из вышеперечисленных пунктов все, кроме одного варианта, предполагают, что обновления будут выполняться партиями. Количество просмотров не является критичным по времени атрибутом, так что все в порядке. Однако заставлять людей ждать просмотра видео на YouTube из-за того, что база данных не может быть в курсе, является критичным по времени действием. Это означает, что обновление столбца в базе данных не будет работать для такого большого сайта, как YouTube. Я лично не был бы удивлен, если бы они выбрали окончательный вариант. Веб-серверы будут регистрировать целый набор информации для каждого посещения, включая то, какой IP-адрес вы используете, как вас перенаправили на страницу и т. Д. Имеет смысл только обрабатывать эти пакеты и обобщать результаты по мере необходимости.

Берин Лорич
источник
Никогда не думал о последнем решении - очень умно! Одно это стоит +1.
Том Такер
1
Мы использовали этот подход для обработки «самых популярных» списков страниц за день / неделю / месяц. Мы свернули счетчик до простого файла свойств за дни, недели и месяцы. Текущий день будет обрабатываться каждый час, а оставшиеся сводные файлы обрабатывались как резервные ленты деда / отца / сына. По сути, нам нужно было не более 8 сводных файлов (еженедельные сводки и сводный файл на каждый день текущей недели).
Берин Лорич
Это похоже на работу RRDTool , хотя RRDTool гораздо сложнее, чем ваше решение, с его элегантной простотой.
Йорг Миттаг
0

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

ChrisW
источник