Автор оригинала: Alexandre
korchasa вот тебе пример:
нужно вывести список товаров определенной категории. Пусть запрос отдает 300 товаров, которые мы разбивает по 20 товаров на стр., получается 15 страниц.
если сделать по умному, пусть статистика показывает, что Посетитель как правило, далее 10 страниц не идет.
Выбираем 200 записей и кешируем их.
Далее организуем навигацию по кешу по 20 записей на стр.
На этом мы - сокращаем кол-во обращений к БД уже, где-то в 5-10 раз. Ни один mysql_proxy не делает этого.
Мы сокращаем кол-во файлов в кешевой директории в 10 раз.
Ну если уж назойливый Посетитель или гугль-бот, то отдадим ему еще один запрос на оставшиеся 100 записей (5 страниц)
Хороший пример. Страничную навигация еще та головная боль. По умолчанию принимаем, что выборка списка товаров "тяжелая"(например товары самых популярных фирм), иначе зачем нам кеширование
Вот тут кеширование объектов, если они имеют данные о популярности фирмы, рулит, т.к. мы можем определить на какую страницу попадет товар. Проще запихнуть коллекцию объектов в кеш, либо закешировать блок HTML для каждого товара, а потом при добавлении нового товара в список, просто добавлять его в коллекцию.
В случае же кеширования результатов запроса мы получаем проблему в виде полного сброса кеша, при добавлении любого товара. Можно, конечно, рядом хранить популярность "нижнего" товара в странице, но это еще один кеш
Автор оригинала: Alexandre
выставлять время валидации кеша, как впрочем сделано в мемкеше. Алгоритм везде одинаковый...
Это честная схема. Мы просто говорим, что наши данные немножко "отстают" от реальности. Только пользователи этого почему то не любят
Кстати, кроме ttl и id, можно обновлять и
тегами.
...тогда всегда можно отследить, например в админке, изменение определенных таблиц, соответственно валидность определенных кешАйДи. разве это недостаток?
Недостаток в том, что отследить можно только изменение таблиц, а не ОБЪЕКТОВ, с их связями.
Это просто недоработка кода. Можно всегда сделать получение результата в виде массива объектов, или одного объекта. Я сам сторонник объектного подхода.
например, у меня во фреймворке были методы:
$db->Fetch()
$db->FetchAll()
$db->FetchObject()
Правда, в последнем модуле (dbCache) $db->FetchObject() отсутствует. Но, как правило, результаты сразу передаются в шаблонизатор массивом, по этому я и ограничился массивом. Будет спрос - будет и код
Из-за пожелания третьего, который еще не уверен нужен ли ему модуль, дорабатывать не буду. Если попросят те два, которые его используют - то уж... придется доработать... времени - минут 40-час.
Я согласен, что кеширование данных полезно. Просто так получилось, что я резко шагнул из проектов где мне проще было кешировать ручками по тому же SQL (там их было не много, и я не особо заморачивался с автоматизацией), в проекты где это уже не работает (из-за требований по времени валидности кеша). И на мой взгляд кеширование по тексту запроса это полумера, т.к. если данные обновляются часто, то либо кеш надо будет часто сбрасывать, либо выставлять небольшой ttl. И в первом, и во втором случае мы все равно имеем нагрузку на базу. Получается, что ниша, которую он занимает - редкоизменяющиеся данные. Очевидный плюс - простота реализации и использования.
Я совсем не понимаю зачем из того, что в dbal встроена поддержка кеша делать заявление о мега-фиче, как будто это "серебряная пуля". Для меня, например, это далеко не главное.
ЗЫ: Извиняюсь, что сумбурно, наверное сказывается время суток
