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