Кэширование результатов с разбивкой на страницы, очистка при обновлении - как решить?

Вы также можете взглянуть на стоимость хранения данных кеша с точки зрения ваших усилий и затрат на ЦП по сравнению с тем, что вам купит кеш.

Если вы обнаружите, что 80% просмотров вашего форума просматривают первую страницу темы, вы можете решить кэшировать только эту страницу. Это означало бы, что как чтение, так и запись кэша реализовать намного проще.

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

Просто обновление: я решил, что точка зрения Джоша на использование данных была очень хорошей. Люди вряд ли будут продолжать просматривать 50-ю страницу форума.

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

Таким образом, я могу использовать один ключ кеша для каждого форума, и для очистки/обновления кеша требуется очень мало усилий :-)

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

Спасибо!

Мне удалось решить эту проблему, расширив класс memcache пользовательским классом (скажем, ExtendedMemcache), который имеет защищенное свойство, которое будет содержать хэш-таблицу групповых значений ключей.

Метод ExtendedMemcache->set принимает 3 аргумента ($strGroup, $strKey, $strValue). Когда вы вызываете set, он сохраняет отношение между $strGroup и $strKey в защищенном свойстве, а затем сохраняет отношение $strKey к $strValue в memcache.

Затем вы можете добавить в класс ExtendedMemcache новый метод под названием «deleteGroup», который при передаче строки будет находить ключи, связанные с этой группой, и очищать каждый ключ по очереди.

Это будет примерно так: http://pastebin.com/f566e913b Надеюсь, все это имеет смысл и работает. для вас.

PS. Я предполагаю, что если вы хотите использовать статические вызовы, защищенное свойство может быть сохранено в самом memcache под своим собственным ключом. Просто мысль.

По сути, вы пытаетесь кэшировать представление, что всегда будет сложно. Вместо этого вы должны попытаться кэшировать только данные, потому что данные редко изменяются. Не кэшируйте форум, кэшируйте строки темы. Тогда ваш вызов БД должен просто вернуть список идентификаторов, который у вас уже есть в вашем кеше. Вызов db будет выполняться молниеносно на любой таблице MyISAM, и тогда вам не придется выполнять большое соединение, которое съедает память db.

Одно из возможных решений — не разбивать кеш тредов на форуме, а поместить информацию о треде в Forum::getThreads|$iForumId. Затем в вашем PHP-коде вытащите только те, которые вам нужны для данной страницы, например.

$page = 2;
$threads_per_page = 25;
$start_thread = $page * $threads_per_page;

// Pull threads from cache (assuming $cache class for memcache interface..)
$threads = $cache->get("Forum::getThreads|$iForumId");

// Only take the ones we need
for($i=$start_thread; $i<=$start_thread+$threads_per_page; $i++)
{
    // Thread display logic here...
    showThread($threads[$i]);
}

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

flungabunga: Ваше решение очень близко к тому, что я ищу. Единственное, что удерживает меня от этого, — необходимость сохранять отношения в memcache после каждого запроса и загружать их обратно.

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

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

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

В ответ на флюнгабунга:

Другой способ реализовать группировку — поместить имя группы и порядковый номер в сами ключи и увеличить порядковый номер, чтобы «очистить» группу. Вы сохраняете текущий допустимый порядковый номер для каждой группы в своем собственном ключе.

e.g.

get seqno_mygroup
23

get mygroup23_mykey
<mykeydata...>
get mygroup23_mykey2
<mykey2data...>

Затем «удалить» группу просто:

incr seqno_mygroup

Вуаля:

get seqno_mygroup
24

get mygroup24_mykey
...empty

и т.д..