Стратегия кэширования, когда кеширование становится бессмысленным?

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

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

Если я кэширую все результаты запроса и группирую их логическими вещами, которые я могу очистить от триггеров, которые имеют смысл, у меня, вероятно, будут десятки тысяч (по крайней мере) крошечных файлов в моем кеше. Будет ли более целесообразно кэшировать только большие результаты запроса?

Я знаю, что это вопрос, связанный с аппаратным обеспечением, но, вообще говоря, какой объем файлов делает кеширование несколько бессмысленным? Значит, если вы загружаете файловую систему со всеми этими крошечными файлами, доступ к ним в конечном итоге становится достаточно медленным, чтобы вы могли просто не кэшировать информацию для начала?

Спасибо всем, меня интересуют любые мнения, которые вы можете предложить

РЕДАКТИРОВАТЬ: На основании ответов, касающихся этого абсолютно конкретного приложения, позвольте мне задать вопрос таким образом, который должен быть универсальным:

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

Быстрее будет делать запрос для извлечения одного из этих элементов непосредственно из базы данных или для извлечения одного из этих элементов из моего каталога кэша с 1 000 000 файлов, каждый из которых содержит сведения об одном из этих элементов?

РЕДАКТИРОВАТЬ: По-видимому, 100 000 было недостаточно, чтобы получить верный ответ, пусть он составит 1 000 000. Кто-нибудь хочет пойти за 1,000,000,000? Потому что я могу это сделать...

Ответ 1

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

Кроме того, не только кешировать запросы. Попробуйте кэшировать целые сегменты приложения на разных этапах цикла рендеринга. Таким образом, вы можете позволить MySQL кэшировать запросы, а затем кэшировать каждый отдельный вид (визуализированный), каждый отдельный блок и каждую страницу. Затем вы можете выбрать, извлекать или не извлекать из кеша на основе запроса.

Например, пользователь без входа может получить полную страницу непосредственно из кеша. Но зарегистрированный пользователь может быть не в состоянии (из-за имени пользователя и т.д.). Таким образом, для него вы сможете отображать 1/2 своих просмотров на странице из кеша (поскольку они не зависят от объекта пользователя). Вы по-прежнему получаете преимущество кэширования, но оно будет многоуровневым на основе необходимости.

Если вы действительно ожидаете много трафика, то определенно стоит посмотреть Memcached. Пусть MySQL сохранит ваши запросы для вас, а затем сохранит все элементы кэша пользовательских земель в memcache...

Изменить: Чтобы ответить на ваше редактирование:

Файловые системы могут стать медленными, если один каталог становится большим. До тех пор, пока вы используете "namespacing" по каталогу (так что в каждом каталоге есть только небольшая часть файлов кеша), вы должны быть в порядке с этой точки зрения. Что касается точного порога, это действительно будет зависеть от вашего оборудования и файловой системы больше всего. Я знаю, что EXT3 становится довольно медленным, если есть загрузка файлов в одном каталоге (у меня есть каталоги с буквально сотнями тысяч файлов, и может потребоваться до половины секунды просто stat() один из файлов, не говоря уже о сделать любой список каталогов)...

Но поймите, что если вы добавите другой сервер, у вас будет либо дублирование кеша (что не очень хорошо), либо придется переписать весь ваш уровень кеша. Есть ли причина не идти с Memcached с самого начала?

EDit 2: Чтобы ответить на ваше последнее изменение:

Слишком сложно позвонить. У меня есть приложение с базой данных объемом около 1,5 млрд. Рядов (рост около 500 тыс. В день). Мы вообще не используем кеширование, потому что у нас нет проблем concurrency. И даже если бы мы это сделали, нам было бы лучше бросить на него больше серверов MySQL, а не добавлять кеширование, так как любая форма кеша имела бы такую низкую скорость, что не стоило бы времени разработки, чтобы добавить ее.

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

Ответ 2

Общее правило: не кэшировать, пока он не нужен, и кэшировать только те вещи, которые необходимо кэшировать.

Ответ 3

Это зависит от оборудования и приложения. Вам необходимо выполнить тесты, чтобы определить порог, при котором индексирование ОС становится больше, чем продолжительность хранения/поиска данных (как на уровне MySQL, так и на уровне кэшированного доступа к файлам). И вам также нужно сравнить это с приемлемым (очень субъективным) порогом вашей аудитории.