Кэширование вычисленных результатов для каждого пользователя - имеет ли таблица, предназначенную для каждого пользователя, смысл?

Question

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

Примерами могут служить:

1. количество игр
2. подборам
3. забил
4. помогает
5. -й минуте за игру
6. игроков, что другие ваши друзья, как
7. вероятность торгуются - вам часто нужны игроки, которые e будет торговаться

В nba около 500 игроков. С точки зрения производительности запрос является непомерно высоким - бросая предпочтения других людей и т. Д. Мы думали о альтернативных подходах. Один из подходов - это NoSQL, где каждый пользователь получает документ каждого игрока. Честно говоря, это похоже на слишком много unkowns, поскольку у меня есть нулевой опыт. Другой подход заключается в том, что каждый человек в системе получит таблицу, посвященную им. Возможно, выпишите определение таблицы через cron на ночной основе, и когда пользователь войдет в систему, выполните инструкцию create table, а затем запросите выделенный запрос. Это звучит очень уродливо для меня (хотя это возможно). У нас также может быть одна таблица, в которой каждый пользователь имеет строку для каждого игрока. Я бы предпочел не предполагать, что вся система отключена от объединения. Похоже, что он запрашивает офф-лайн, и мы можем измерить 1000 игроков против этих разных параметров.

Есть ли другие идеи, которые мне не хватает? Я не хочу ничего слишком эзотерического - желательно просто MySQL и Python. Был бы использовать InnoDB и не очень беспокоиться о разделении таблиц на каждую базу данных на главную проблему.

Были бы оценены любые другие идеи или опыт реального слова? Я уверен, что это было решено много раз.

ТНХ

Answer 1

Я использую MongoDB сейчас в первый раз, и я считаю, что это будет действительно удивительным в том, как она позволяет представлять документ в значительной степени, как классовая структура объектно-ориентированной. Вы можете легко иметь документ на пользователя, который хранит любое количество встроенных документов. Ваши игроки могут быть во вложенном словаре или списке, и вы можете индексировать имена игроков. Затем, когда вы запрашиваете пользователя, нет соединений. У вас есть все ваши данные. Кроме того, существует гибкая схема, поэтому вы всегда можете просто добавлять дополнительные поля, когда захотите.

Что касается mysql table-per-user, я соглашаюсь с тем, что он действительно грязный и может выйти из-под контроля.

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