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