У меня есть приложение, которое позволяет людям делать ставки на результат футбольных матчей. Оценка каждой отдельной ставки (= сущности) рассчитывается путем сопоставления сделанных ставок ставки с фактическим результатом в игре (= объект). Ставки заключаются в Betrounds. Betrounds - это организации, в которых группы ставят на игровые группы (группы игр, например, одиночные совпадения). Одиночные группы могут иметь несколько вариантов.Как кэшировать сложные расчетные временные данные
Резюмируя реляционную модель: UserGroup 1: N BetRounds 1: N Bets N: 1 Игру
В каждом betround я создать resulttable, где я показывать каждый пользователь с их результирующими точками и позицией. Чтобы рассчитать позицию одного пользователя, мне нужно вычислить точки каждого пользователя в пределах ставки. Эти точки из одного круга объединены в группы, и внутри группы снова появляется результат.
Пример
- в группу, с: 20 пользователей
- Один сезон имеет 34 дни матчей
- Один тур имеет 9 игр
Для того, чтобы вычислить точки для этого usergroup Мне нужно было бы рассчитать очки от 20 * 34 * 9 = 6120 ставок.
Поскольку это много, чтобы рассчитать, я не хочу это делать каждый раз, когда показываю результат. В настоящее время я вижу два варианта, чтобы сэкономить время вычислений:
- Cache
- Сохранить промежуточные результаты (например, по ставке объекта) в базе данных
- Может быть сочетание обоих.
- Cache
Если кэширование правильный путь, я не уверен, на каком уровне и как аннулированию. Есть несколько вариантов, что в кэш: - pointresult одиночного ставка - pointresults одиночных пользователей в betround - вся таблице результатов в betround (точки & положения) - pointresult от одного пользователя в группах пользователей - весь resulttable из группа пользователей
Я уверен, как кэшировать эти данные: - только целые значения для позиций и точек - целые сущности (например, ставки) - временные не постоянные объекты (например, для представления в resulttables) - HTML, выход таблицы
Тогда в зависимости от формата кэширования: - представления html могут быть кэшированы через обратные прокси - значения/сущности, вероятно, через redis/memcache и т. Д.
В будущем мы можем перейти на одностраничное приложение, которое передается только через restapi, тогда кеширование выходов html не является вариантом.
В зависимости от стратегии кэширования возникает вопрос о том, как сделать недействительным кеш и, возможно, согреть его, чтобы результат никогда не вычислялся в приложении, а только пересчитывался, когда кеш недействителен и немедленно заменяется новым результатом.
Я читал очень часто, что недействительность кэша является злом. Я не уверен, что это относится к моему прецеденту, поскольку все точки/результаты/таблицы и т. Д. Меняются только тогда, когда мой интерфейс обновляет результаты игр. Это единственный момент, когда очки меняются.
2.Save промежуточные результаты (например, по ставке объекта) в базе данных
Я не уверен, что если этот сценарий применим на всех уровнях. Сначала я думал о сохранении фактического результата на ставке вместо того, чтобы всегда сравнивать ставки с фактическими баллами. Это сделало бы мою модель данных немного избыточным, и я увеличил бы сложность, если бы неправильный результат был получен с помощью моего интерфейса, а затем вернётся, и мои очки не пересчитываются.
На всех других уровнях мне нужно будет создавать новые временные объекты для постоянного хранения результатов таблиц.
3.Mix обоих
Я не уверен, как смешивание как будет выглядеть, и если это имеет смысл на всех, но я думал, что это может быть вариант.
Любой совет, ввод или опыт были бы высоко оценены.
Привет, поэтому для меня это означает сохранение результата ставки в базе данных и обновление этого значения, если основная игра изменится. Все таблицы не должны храниться, но только кеширование должно быть кэшировано (так что только частичный вид, а не необработанные данные, а затем повторно снятые). Это означает, что я могу использовать что-то вроде https://github.com/asm89/twig-cache-extension для него или лак с краем. К сожалению, облачный провайдер пока не предлагает лак. Поэтому я, вероятно, займусь блогами кэша в twig. – m0c