Ответ 1
Используйте MySQL, построенный в кеше запросов, вместо того, чтобы пытаться его поддерживать самостоятельно. Он автоматически очистят кэшированные запросы к таблицам, когда они будут записаны. Кроме того, он работает в памяти, поэтому он должен быть очень эффективным...
Кроме того, не только кешировать запросы. Попробуйте кэшировать целые сегменты приложения на разных этапах цикла рендеринга. Таким образом, вы можете позволить MySQL кэшировать запросы, а затем кэшировать каждый отдельный вид (визуализированный), каждый отдельный блок и каждую страницу. Затем вы можете выбрать, извлекать или не извлекать из кеша на основе запроса.
Например, пользователь без входа может получить полную страницу непосредственно из кеша. Но зарегистрированный пользователь может быть не в состоянии (из-за имени пользователя и т.д.). Таким образом, для него вы сможете отображать 1/2 своих просмотров на странице из кеша (поскольку они не зависят от объекта пользователя). Вы по-прежнему получаете преимущество кэширования, но оно будет многоуровневым на основе необходимости.
Если вы действительно ожидаете много трафика, то определенно стоит посмотреть Memcached. Пусть MySQL сохранит ваши запросы для вас, а затем сохранит все элементы кэша пользовательских земель в memcache...
Изменить: Чтобы ответить на ваше редактирование:
Файловые системы могут стать медленными, если один каталог становится большим. До тех пор, пока вы используете "namespacing" по каталогу (так что в каждом каталоге есть только небольшая часть файлов кеша), вы должны быть в порядке с этой точки зрения. Что касается точного порога, это действительно будет зависеть от вашего оборудования и файловой системы больше всего. Я знаю, что EXT3 становится довольно медленным, если есть загрузка файлов в одном каталоге (у меня есть каталоги с буквально сотнями тысяч файлов, и может потребоваться до половины секунды просто stat() один из файлов, не говоря уже о сделать любой список каталогов)...
Но поймите, что если вы добавите другой сервер, у вас будет либо дублирование кеша (что не очень хорошо), либо придется переписать весь ваш уровень кеша. Есть ли причина не идти с Memcached с самого начала?
EDit 2: Чтобы ответить на ваше последнее изменение:
Слишком сложно позвонить. У меня есть приложение с базой данных объемом около 1,5 млрд. Рядов (рост около 500 тыс. В день). Мы вообще не используем кеширование, потому что у нас нет проблем concurrency. И даже если бы мы это сделали, нам было бы лучше бросить на него больше серверов MySQL, а не добавлять кеширование, так как любая форма кеша имела бы такую низкую скорость, что не стоило бы времени разработки, чтобы добавить ее.
И это причина, по которой я так категоричен в том, что не кеширую скорость. Всегда будет объект, который не находится в кеше. Поэтому, если вы нажмете на страницу один из этих объектов, он все равно должен быть быстрым. Как правило, я пытаюсь кэшировать все, что будет доступно заново в течение следующих нескольких минут (я все равно оставлю время около 5 минут на производстве в других приложениях). Поэтому, если элементы не получают больше нескольких ударов за этот промежуток времени, или скорость попадания очень низкая (менее 90%), я не беспокоюсь о кешировании этого элемента....