Как правильно хранить оценки для постов, но быстро сортировать посты по средней оценке?

Question

[GeneAYak]

Есть посты о фильмах. Таких постов очень много. У каждого фильма есть рейтинг от 1 до 10. Понятное дело, если все нормализовать, то все фильмы лежат в одной таблице, все рейтинги в другой. Но встает задача за все время вывести топ 100 фильмов с максимальными средним рейтингом.

На ум приходит два варианта:
1) мы могли бы просто взять все рейтинги, сгруппировать по фильмам, посчитать средние, взять топ сто средних. Но это как будто неэффективно
2) когда происходит добавление очередного рейтинга, помещать его в таблицу, но и тут же пересчитать его, и дописать в специальную колонку с фильмом. Это звучит эффективно для выборки, но как будет дело обстоять с конкурентной записью? Или транзакция будет ставить в очередь при одновременном добавлении двух оценок?

А может есть другие практики?

Comments

[Сергей]

К Redis не присматривались?

Answer 1

[Иван Шумов]

Как уже правильно было сказано должно быть:

• таблица с постами
  
• таблица с оценками
  
• таблица с рейтингом
  

Прим. Не обязательно таблица, не обязательно база реляционная - для задачи это не играет никакой роли

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

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

Для того чтобы сделать все красиво существуют Message Brokers (RabbitMQ, Kafka, ... да какой угодно в принципе - выбор зависит от требований к системе).
Архитектура такая:

1. пользователь оставляет оценку к посту
   
2. оценка сохраняется в базе оценок
   
3. после сохранения в брокера падает сообщение "у поста 12345 новая оценка" (сама оценка для этого кейса не важна, но ее можно тоже указать)
   
4. клиент счастливо идет дальше серфить интернеты, не ожидая обработки всякой логики, которую задумал программист
   
5. на той стороне брокера сидит маленький демон и слушает эти события
   
6. при появлении события демон моментально пересчитывает рейтинг поста и обновляет его в отдельной таблице
   
7. при росте нагрузки на демона ничего страшного не происходит - все сообщения встают в очередь и ждут обработки
   
8. ну, если хочется совсем все быстро обрабатывать - запускаем ХХХ этих демонов чтобы пережевывали за раз больше информации
   

Вот так. Надеюсь вам поможет такой маленький пример их мира энтерпрайз-разработки

Comments

[Игорь Воротнёв]

+1, единственное реально рабочее и проверенное решение для проектов "чуть больше среднего"

[hckn]

Разница между оценкой и рейтингом? Это две одинаковые сущности, зачем для каждой таблица?

[Иван Шумов]

hckn,

• оценка это реакция пользователя на пост
  
• рейтинг - скалькулированное значение относительно поста/фильма (по исходной задаче есть некоторая неясность)
  

Рейтинг может иметь разные алгоритмы рассчета и со временм может понадобиться его пересчитать. Это очень весомая причина хранить сырые данные.

Так же реакция пользователя это очень весомая метрика по которой можно проводить аналитику

[hckn]

Иван Шумов, понял. Видимо проблема в нейминге. Я просто сел подумать как назвать эти таблицы, а английское слово Rating - значит и рейтинг и оценку. Это слова синонимы по сути. Видимо, надо что-то вроде Rating и UserScore.

Answer 2

[x67]

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

Comments

[GeneAYak]

ну вот и я так думаю, и второй метод вроде норм, спрашиваю ибо вдруг все-таки есть что-то страшное, а я не чувствую этого

[Adamos]

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

[x67]

Adamos, а если это новинка или я напишу бота, который будет менять оценки постоянно? А если фильм популярный и ему меняют оценки каждую наносекунду? Тут много деталей и много условий можно и нужно вложить во "время от времени" в зависимости от задачи. Но лучше именно время от времени - так легче прогнозировать нагрузку.

[Adamos]

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

[x67]

Adamos, но не получится пренебречь особенностями архитектуры. Если это релляционная база данных, то один запрос в час и один проход по таблице с аггрегацией по film_id будет предпочтительнее тысячи запросов с каждой оценкой. Это просто накладно. Для новинок кино это будет меганакладно, даже с учетом индексов

[Adamos]

x67, а по-моему, вы придумали взаимоисключающие условия. При тысячах запросов на новинки у вас в базах будут миллионы отзывов на старые фильмы, которые вы будете перетряхивать каждый час без всякой на то необходимости. А откуда, собственно, возьмутся миллионы оценок каждую секунду? Если это наплыв ботов - так лучше пусть сервис реально затормозит и провалит этот наплыв, чем писать заведомо фальшивые данные в базу.

[Андрей Федосеев]

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

[x67]

Андрей Федосеев, я писал выше, для этого метода нужны ограничения

[x67]

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

[Adamos]

x67, Сложность ненужного действия, которое не выполняется вовсе - О(0). Выигрывает всегда ;)

[Иван Шумов]

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