2014-01-07 2 views
0

У меня есть приложение, которое позволяет людям делать ставки на результат футбольных матчей. Оценка каждой отдельной ставки (= сущности) рассчитывается путем сопоставления сделанных ставок ставки с фактическим результатом в игре (= объект). Ставки заключаются в Betrounds. Betrounds - это организации, в которых группы ставят на игровые группы (группы игр, например, одиночные совпадения). Одиночные группы могут иметь несколько вариантов.Как кэшировать сложные расчетные временные данные

Резюмируя реляционную модель: UserGroup 1: N BetRounds 1: N Bets N: 1 Игру

В каждом betround я создать resulttable, где я показывать каждый пользователь с их результирующими точками и позицией. Чтобы рассчитать позицию одного пользователя, мне нужно вычислить точки каждого пользователя в пределах ставки. Эти точки из одного круга объединены в группы, и внутри группы снова появляется результат.

Пример

  • в группу, с: 20 пользователей
  • Один сезон имеет 34 дни матчей
  • Один тур имеет 9 игр

Для того, чтобы вычислить точки для этого usergroup Мне нужно было бы рассчитать очки от 20 * 34 * 9 = 6120 ставок.

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

  1. Cache
  2. Сохранить промежуточные результаты (например, по ставке объекта) в базе данных
  3. Может быть сочетание обоих.
  1. Cache

Если кэширование правильный путь, я не уверен, на каком уровне и как аннулированию. Есть несколько вариантов, что в кэш: - pointresult одиночного ставка - pointresults одиночных пользователей в betround - вся таблице результатов в betround (точки & положения) - pointresult от одного пользователя в группах пользователей - весь resulttable из группа пользователей

Я уверен, как кэшировать эти данные: - только целые значения для позиций и точек - целые сущности (например, ставки) - временные не постоянные объекты (например, для представления в resulttables) - HTML, выход таблицы

Тогда в зависимости от формата кэширования: - представления html могут быть кэшированы через обратные прокси - значения/сущности, вероятно, через redis/memcache и т. Д.

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

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

Я читал очень часто, что недействительность кэша является злом. Я не уверен, что это относится к моему прецеденту, поскольку все точки/результаты/таблицы и т. Д. Меняются только тогда, когда мой интерфейс обновляет результаты игр. Это единственный момент, когда очки меняются.

2.Save промежуточные результаты (например, по ставке объекта) в базе данных

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

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

3.Mix обоих

Я не уверен, как смешивание как будет выглядеть, и если это имеет смысл на всех, но я думал, что это может быть вариант.

Любой совет, ввод или опыт были бы высоко оценены.

ответ

1

Я только мягко понимаю, что ставки, так что, надеюсь, это поможет.

Это звучит, как вы задаете два вопроса:

  1. Когда рассчитать результаты?
  2. Сколько кеширования я должен использовать?

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

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

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

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

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

+0

Привет, поэтому для меня это означает сохранение результата ставки в базе данных и обновление этого значения, если основная игра изменится. Все таблицы не должны храниться, но только кеширование должно быть кэшировано (так что только частичный вид, а не необработанные данные, а затем повторно снятые). Это означает, что я могу использовать что-то вроде https://github.com/asm89/twig-cache-extension для него или лак с краем. К сожалению, облачный провайдер пока не предлагает лак. Поэтому я, вероятно, займусь блогами кэша в twig. – m0c

Смежные вопросы