Как реализовать ТОП просмотров за день, неделю и месяц?

Question

[Станислав]

Интересует сама логика реализации.
У меня на данный момент существует данный рейтинг, но при перерасчете который выполняется каждый час создается очень большая нагрузка на базу данных, в связи с этим нужны какие то альтернативы.
Как сейчас все работает:
У меня есть коллекция, допустим analytics, со сбором статистики, куда прописывается URL с просмотром документа

{
   _id: ID,
   page: "http:......post/id/",
   count: 1, // поле лишнее, просто для наглядности
   createdAt: new Date()
}

Если пользователь просматривает пост, то идет запись в analytics.
Далее я каждый час обновляю данные по крону и собираю информацию сколько пользователей просмотрело определенные URL (суммирую просмотры).

За День этот URL просмотрело N пользователей
За Неделю этот URL просмотрело N пользователей
За Месяц этот URL просмотрело N пользователей
И таких разных URL тысячи.

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

return Analytics.aggregate([
        {
            $match: {
                count: { $exists: !0 },
                createdAt: { $gte: new Date(new Date().setDate(new Date().getDate() - 1)) }
            }
           //....
           {
            $group: {
                _id: "$page",
                count: {
                    $sum: "$count"
                }
            }
        }
    ])

С индексами все в порядке, они есть...

Затем банально сумму просмотров я записываю в коллекцию с постами, обновляю документ, а именно поле popular

//db.posts
{
    _id: ID,
    url: String,
    popular: {
        day: Number,
        week: Number,
        month: Number
    }
}

Как можно перестроить/переделать рейтинг для меньшей нагрузки на базу. Может доп. коллекцию создать для этого дела, но придется как то регулировать актуальность данных для расчета времени просмотров, в общем мне совсем не понятна альтернативная логика текущей.
Любые советы по этому поводу будут полезны для меня.

Comments

[fenrir]

Я вообще не по js, поэтому в формате идеи предложу как решал бы подобную проблему.

Заводим под каждую страницу дек (deque) заданной длины. Подсчет для любого периода сведется к двум операциям: вычесть число которое выпало из дека и прибавить которое туда зашло.

По сути к каждой странице добавится данных в виде 3 массивов длиной 24/7/31 (с месяцами нужна будет аккуратная обработка), зато все вычисления будут за константное время

[Алексей Ярков]

Как реализовать ТОП просмотров за день, неделю и месяц?

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

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

[Станислав]

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

day: [

   {
       date: "10.03.2023",
       count: 1000
   }, {
       date: "11.03.2023",
       count: 900
   }
],
week: [

   {
       date: "10.03.2023",
       count: 7000
   }, {
       date: "11.03.2023",
       count: 6000
   }
]

Ну и получается нужно будет следить за всеми db.posts в базе и удалять устаревшие записи. Но идея имеет место быть.

Алексей Ярков, можно, не проблема, проблема в том что нагрузки на столько велики что может объявится oom killer и офнуть базу, что он в принципе и делает периодически. У меня просто совместно с этими расчетами еще кое какие манипуляции проводятся, поэтому и делаю каждый час. Раньше было все Ок, но по мере роста базы и числа просмотров начались проблемы с этим, разграничу все это дело, а проблема так и останется.

[fenrir]

Станислав, если хранить все в формате key: value, то да.
Поэтому уточнил, что я не знаком с js и не могу подсказать по инструментам детальнее. Я бы не хранил никакие даты, только голыми данными 3 массива и итоговые числа.

Условно есть массив просмотров за неделю [ 1 | 3 | 4 | 3 | 4 | 5 | 6 ] + заранее посчитана сумма 26, которая идет в аналитики. Мы всегда знаем что последняя запись это вчера.
Допустим за день было 3 просмотра, когда день пройдет она сдвинется и будет [ 3 | 4 | 3 | 4 | 5 | 6 | 3 ], а просмотры за неделю 26 - 1 + 3 = 28
Да данных больше, но со временем не раздуется, поскольку новые данные вытесняют старые в чем и суть дека.

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

Answer 1

[Saboteur]

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

Answer 2

[nokimaro]

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

item_id
date_day
counter

если нужно отдельно отсеивать повторные просмотры одного пользователя, то для этого можно завести отдельную таблицу для того чтобы делать проверки перед увеличением счётчика
item_id + user_id

одна эта оптимизация позволит сократить количество хранимых и обрабатываемых данных в аналитике

ещё один трюк который использую для построения топа за день/неделю/месяц это внутри каждого элемента хранить три счётчика для сортировки

item_id
counter_1
counter_7
counter_30

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

Comments

[nokimaro]

Можете посмотреть мой аналогичный вопрос и пример на SQL
Там я спрашивал совета по проблемам с локами таблиц, но у меня объёмы данных были гораздо больше: 20 млн уникальных элементов просматриваемые каждый день и это помноженное на 30 дней хранимой истории.
https://qna.habr.com/q/679395

[Станислав]

У меня коллекция analytics это коллекция статистики куда записываются все важные действия пользователя на сайте, поэтому увеличивать просмотры определенной страницы методом обновления "count" не получится, если только для этого дела завести еще одну коллекцию, сугубо для просмотров, надо будет попробовать, это должно будет облегчить выборку.
Получается в течении дня мне нужно будет обновлять данные просмотра каждой страницы в доп. коллекции, ночью переносить сумму просмотром в db.posts.url, а после в этой доп. коллекции обнулять счетчики страниц для сбора данных нового дня.

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

Надо будет покумекать над этим, что так точно нагрузка уменьшится.

Answer 3

[RaShe]

По поводу индекса, $exists делает partial colscan. Лучше count $gte 0.

Какой индекс используется можно проверить через .explain