Стратегии кэширования с постраничными / отфильтрованными данными - PullRequest
2 голосов
/ 26 мая 2009

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

Мой вопрос касается эффективного кэширования выгружаемых или отфильтрованных данных, но более того, распределенного кэширования. Последнее я решил использовать с memcached и, более конкретно, с его портом .NET. Я видел еще один коммерческий вариант в виде NCache, но memcached кажется мне вполне приемлемым и, по-видимому, используется на Facebook, MySpace и т. Д. *

Тогда мой запрос - это стратегия my, в которой вы можете содержать объекты в кеше, а также ссылку на них с постраничными данными. Если у меня есть 100 элементов, и я их распечатываю, то я могу кэшировать идентификаторы продуктов 1-10 внутри кэша и кэшировать каждый продукт отдельно. Если бы я сортировал элементы по убыванию, то элементы 1-10 были бы разными продуктами, поэтому я не хотел бы хранить фактические объекты каждый раз, когда изменяемые данные / сортировка / фильтрация разбивались по страницам, а вместо этого сохранял идентификаторы объектов, чтобы затем выполнить trabsactional поиск в базе данных, если некоторые из них еще не существуют в кэше или недействительны.

Моя первоначальная идея была для ключа кеша.

paged_<pageNumber><pageSize><sort><sortDirection>[<filter>]

Затем я бы перебрал все ключи кеша и удалил все, которые начинаются с "paged_". В конечном счете, мой вопрос заключается в том, знает ли кто-нибудь какие-либо шаблоны или идеи относительно ограничений в отношении кэширования таких шаблонов данных, таких как выгружаемые данные, а также чтобы что объекты не кэшируются более одного раза.

memcached - это нативный код, и у него не будет проблем с очисткой кеша, как я описал выше, но очевидно, что чем больше элементов в кеше, тем больше времени потребуется. Мне интересно, знает ли кто-нибудь какое-либо решение или теорию этого типа проблемы, которая в настоящее время используется. Я уверен, что будет. Спасибо за ваше время

ТИА

Andrew

1 Ответ

0 голосов
/ 27 мая 2009

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

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

...