Я постил недавно простенький SSH скрипт (можно переписать на PHP), который дампит все таблицы с данными, а для всяких кэшей - только структуру. Чуть сложней тупого дампа базы, но зато заметно удобней.

Таблицы realurl вряд ли можно вынести в memcached. Во первых в memcached не структурированные данные, и возможно realurl по разным полям поиск делает. Во вторых, у нас на одном проекте до 2 гигов таблицы realurl занимают. Сильно жирно столько памяти на один realurl выделять :)

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

В дополнение к этому, и это пишут как минус в http://wiki.typo3.org/Caching_framework, тэги и данные могут быть удалены memcached произвольно и независимо друг от друга. Ведь memcached это такая штука, которая ничего никому не гарантирует "by design".

Есть такое расширение "truncate_tables" - суть его в том, что там где сброс кэшей - появляется новая молния. При нажатии на нее очищается список указанных таблиц. Я немного модифицировал его в одном из расшриений - и он у меня чистит все таблицы, которые содержат *cache*, А также sys_log и другие которые содержат временные данные.

Можно сделать "еще одну молнию на основе этого SSH->PHP скрипта" - при нажатии на нее будет создаваться бэк ап БД сайта и ложится в папку fileadmin/__temp__/ - но пока не знаю на сколько это нужно? Либо еще круче - нажал на кнопку и получил бэкап БД. Просто я обычно делаю дамп БД через Админер - после нажатия на синию молнию (ну восстановятся кэши потом - не 100 раз же на дню я ее нажимаю синуюю молнию) - получаю чистую БД без кэшей...

--
Просто все таки стремлюсь сделать саму БД - чистой.
Вот как таблица excel - мы же пишем там только нужные данные, а весь старый мусор бросаем в корзину...

В общем по тэгам - тогда посмотрю и напишу в эту тему.:o

вот этот Caching_framework - по умолчанию он пишется на Бд.
Можно очисть кэш конкретной страницы по ID-страницы.
А вот очистить кэш расширения, сгенерированного через useCacheHash - уже не получится...

Но думаю, что здесь все равно с тэгами особо большоего смысла углублятся в "извращения" нет.... Не знаю на сколько сложная логика кэширования реализована на typo3.org - но думаю там все предельно просто, добавил - сбросил. А где то наверное и вовсе Не кэшируется. И все работает! При БД в 70Gb и посещаемостью наверно достаточной.

Так вы же не знаете что там за железо. Может там отказоустойчивый кластер из 50 серверов: 10 на БД, 10 на статику, 20 на фронтенд и 5 на бэкенд, и 5 еще на какую-нибудь хрень :)

Ну главное же что работает...:)
Вот с тэгами сейчас разбираюсь и посмотрю есть ли смысл заморачиватьс по схеме...

При добавлении новости:

1. сбросить карту сайта sitemap.xml
2. сбросить карту сайта - страницу
3. сбросить главную
4. сбросить баннеры (последние новости)
5. сбросить постраничную навигацию
6. сбросить комментарии к новости
--
x. и т.д

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

Ну пока из наблюдений - что мне показалось в отличие от файлов - это то что запись в memcache - как-то быстрее происходит....:)

Как раз "при добавлении" - это самый хитрый момент в чистке кэшей.

Обычно как: вывели список новостей, закэшировали, в качестве тэгов использовали id-шники новостей. Соответственно при изменении или удалении (скрытии) новости одновременно сбрасываем кэши по "тэгу id-шнику".

А новая новость еще ни с какими кэшами-тэгами не связана! Так что сбрасывать?

PS: На тестовой машине, когда кэшей мало считывание из файла и из memcached, ИМХО, может быть одинаковым по времени. Так как обращение к файлам ОС + ФС кэширует в памяти, и получается по сути то же самое. А вот в реальной жизни, когда кэшей много, всю ФС в память не поместишь и разница будет.

В общем сейчас прихожу к выводу - кэшируется на БД realurl - и ладно...
В этом нет ничего плохого...
С memcache - конечно лучше стало (имею в виду, то что удалось поставить на memcache)... И это заметно даже на не большой проекте.

Единственное проблема с которой столкнулся при использовании memcache - это на основе чего генерировать уникальный ключ кэша - что бы разрешить запись кэша?

На основе id-страницы - не подходит
На основе useCacheHash - также не подходит

В обоих случаях пользователь может ввести id=xxxx - и будет создан кэш + 1...
И таким образом будет насоздано куча всяких "несущесвующих" кэшей.

А с тэгами ищу решение...