Чому на більшості веб-сайтів кількість переглядів повідомлень відстає?

10

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

Youtube не самотній у цьому. Більшість дощок оголошень реалізовані таким чином, і кількість переглядів оновлюється, як і кожні 10 хвилин.

Хтось знає причину цього?

Дякую.

caching

— Том Такер
джерело

20

Запис переглядів дуже простий, просто додайте рядок до таблиці, яка представляє дію "view". Це швидко, тому що не потрібно блокувати в базі даних, ви просто додаєте рядок у кінці купи.

Сукупність цих даних у загальній кількості переглядів вимагає щось подібне до виконання, SELECT COUNT(*) FROM ...що означає, що вам потрібно заблокувати таблицю під час проходження обчислення. Крім того, UPDATE ... SET num_views = num_views + 1також потрібно блокувати відповідний рядок кожного разу, коли хтось його переглядає.

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

Примітка. Насправді я не знаю архітектури YouTube, чи вони взагалі використовують реляційну базу даних для зберігання своїх даних, але що б вони не використовували, принцип, ймовірно, той самий: вставлення даних дешеве, агрегація значень (відносно) дорога .

— Дін Хардінг
джерело

4

Чи він не використовує BigTable з рештою Google?

— TheLQ

@Dean Harding Спасибі, але чи це не означає, що в таблиці будуть мільярди, якщо не трильйони, записів для веб-сайту навіть при помірному трафіку, набагато менше в 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 набагато складніший за ваше рішення з його елегантною простотою.

— Йорг W Міттаг

0

Це може бути пов'язано з низкою причин. Все це зводиться до алгоритмів, що використовуються кожним відповідним веб-сайтом. Якщо хтось тут насправді не є розробником YouTube, я сумніваюся, що ви отримаєте точну відповідь тут.

— chrisw
джерело