Сортировка по совокупности по большому набору данных в реальном времени

Question

Я бы хотел, чтобы пользователи могли сортировать видео по «наиболее просматриваемым» по периодам (день, неделя, месяц, год и т. Д.).

В настоящее время все данные находятся в MySQL, и в основном установка представляет собой таблицу «видео» и таблицу «представления», которая содержит строки с столбцами video_id, session_id и datetime.

Для сортировки по "наиболее просматриваемым" для каждого видеоролика генерируется вычисленное поле с COUNT(), которое подсчитывает все строки представления за указанный период. Это работает отлично для таких периодов, как «час» и «день», но такие периоды, как «месяц» и «год», могут занять много времени.

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

Я прошу об общем решении/стратегии, которая является масштабируемой. Есть ли такие вещи, как это сделать в MySQL, или я должен рассматривать другую базу данных?

Answer 1

Для статистики использования (или журналов) данных следующая стратегия агрегации могут быть использованы:

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

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