Это довольно сложный вопрос, не делая его слишком общим или широким, поэтому я заранее прошу прощения, если он слишком высок для этого формата вопросов и ответов.
Я работаю над системой, которая включает часто обновляемую систему типов каналов (в стиле «твиттер») и систему, которая ранжирует элементы на основе голосов пользователей.Система основана на API json / restful, написанном на PHP, который обращается к (в основном) базе данных innodb mysql.Сама база данных на самом деле довольно высоко оптимизирована и хорошо нормализована.Система также использует sphinx для поиска и некоторые внешние системы очередей и обработки для обработки данных.
Мой вопрос: есть ли у кого-нибудь какие-либо предложения о способах реализации memcache в системе, где так много зависит от отношений между таблицами базы данных?
Например: «горячий список» основан наранг, который рассчитывается каждый раз, когда кто-то голосует за предмет.Кто-то голосует, для элемента вычисляется новый «ранг» и сохраняется в базе данных mysql как целое число.
Будет ли эффективнее написать что-то наподобие задания cron, чтобы кэшировать этот список записей каждые несколько минут, и, таким образом, попадать в базу данных реже - или - имеет ли смысл извлекать «id» изБД, и вместо того, чтобы кэшировать список, кешировать данные элемента и извлекать данные отдельно из памяти для каждого элемента в списке?
Кривая состоит в том, что для каждого элемента вызов API также должен возвращать, проголосовал ли пользователь за элемент или нет, что также может быть кэшировано, но трудно кэшировать то, что необходимо для существования.быть проверен на.
Я считаю, что это немного умственная гимнастика, пытающаяся определить, какие данные на самом деле имеют смысл или можно кешировать, когда так много зависит от данных, которые так сильно обновляются.
В любом случае, не уверен, является ли это даже правильным вопросом, который нужно задавать, но я хотел бы получить некоторую информацию от любого, кто имеет большой опыт работы с кэшированием для приложений, которые имеют очень мало статических элементов.
Кроме того, я серьезно подумал о том, чтобы рассмотреть возможность использования Redis для управления фидом «ранжированных элементов» ... то есть вместо того, чтобы обращаться к базе данных при обновлении ранга, а просто обновлять список redis.,Хотя я потратил немного времени на работу с Redis, так что я не на 100% уверен, что это лучший способ справиться с этим в системе, которая должна быть супермасштабируемой.