На работе поставили задачку, прикрутить мем-кеш к системе.

Абстрактно система следующая: 
1. Есть объекты блокнотов. (id, title, owner_id)
2. Есть объекты записей, привязанных к блокнотам. (id, title, owner_id, content, notebook_id)
3. Есть связь между пользователями системы (владелец еще может шарить блокнот другим пользователям) (notebook_id, user_id)

Вопросов будет несколько.
1. Во первых есть ли смысл это кешировать? (Лично я считаю, что запросы в эти таблица дешевы и кеш тут ненужен - руководство ествественно думает иначе)
2. Во вторых. Представим, что кешировать надо независимо от того хотим или нет. Какой подходк к кешированию этих данных был бы оптимальным?
3. Руководство хочет кешировать все это дело как один большой объект блокнтота. Это нормально? Какие могут быть подводные камни?
4. И вопрос, выходящий далеко за рамки этой задачи (интересует меня уже давно). Вот настроили мы кеширование ( не важно одним большим объектом или кучей маленьких) и встала у нас задача произвести выборку всех блокнтово определенного пользователя, созданных за последнюю неделю. Естественно из кеша мы выборку не сделаем - обращаемся к базе данных. Выходит, что у нас теперь два подхода к инициализации объекта: брать его из кеша или из базы. Есть какие-нибудь подходы (паттерны) к реализации этой функции?

Что кэшить может подсказать только профайлер, тупой замер всего базы запросов, функции которые кажется тяжелыми. 

Дешевле ngnix кэшить результат почти мгновенная отдача пользователю всей страницы (пример сайт) 
Кэш стандартный на страницы 1-2 мин можно даже memcache прекрутить. 
Нужен только сброс кэша что бы сбрасывать кэш можно отправлять на туже страницу при добавлении или изменении записи какой не будь заголовок, куку

Блочный кэш спасает до пары до времени

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


Когда данных будет очень много кэш оправдает себя особенно если там есть сортировка и условия поиска по дате. 




Это сообщение отредактировал(а) Sanchezzz - 14.3.2013, 19:53

Вопросы ставятся и решаются не абстрактно, а по мере анализа ситуации. Промерить время, затраченное на вычисление запросов, посчитать выигрыши по кэшированию... Посчитать насколько оно нужно. Первым делом нужно запустить профайлер и вычислить тонкие места.
Если сервер только один - нужно думать кому отдать память - nginx'у для кэширования или memcache.

Наиболее простой, понятный и, как правило, эффективный метод - кэшировать запросы в базу, используя md5 от самого запроса как ключ. Некоторые проблемы будут с парными запросами, например `select SQL_CALC_FOUND_ROWS ...` и парный к нему `SELECT FOUND_ROWS() `,их нужно кэшировать единовременно. В любом случае - само кэширование вне уровня драйвера базы данных совершенно прозрачно, вся работа по получению данных ведется тем-же комплектом sql запросов. При таком подходе 4 вопрос лишается смысла.

С какого фига не сделаем?
Только если кешу не хватило памяти и ключи оказались вытесненными.

Но ksnk, правильно заметил. С точки зрения получения данных процесс должен быть абсолютно прозрачным для кода.
Не играет роли из кеша или БД.