Кэширование фрагментов русской куклы с ключами для автоматического истечения срока действия - преимущества и недостатки производительности

Вопрос основан на 2 статьях:
- Basecamp Next от DHH от 37signals
- Продвинутое кеширование в рельсах Адама Хокинса

Я немного смущен о последствиях использования кеширования русской куклы, в частности:

При использовании ключей автоматического истечения срока действия кажется, что каждый запрос приведет к доступу к базе данных для извлечения метки времени объекта - я что-то упустил? (Я понимаю, что в лучшем случае вы должны сделать это только для ключа верхнего уровня в иерархии, но все же...)
В первой статье они кэшируют список дел, а также каждый предмет todo. Кэширование списка имеет смысл, поскольку оно экономит много работы (запрос БД для всех элементов). Но зачем кешировать отдельные предметы? Вы уже собираетесь в базу данных, чтобы получить метку времени элемента, и что именно вы сохраняете? Создание нескольких строк html?
Во второй статье Адам кэширует куски такого вида: cache [post, 'main-content']... cache [post, 'comments'] Когда добавляется комментарий, он меняет отметку времени публикации, и поэтому делает ее недействительной. Однако main-content не изменился - вы не хотите его регенерировать!!! Как можно было бы сделать недействительными только комментарии. (Это действительно очень распространенный случай пользователя - модель, которая имеет несколько логически независимых частей: сам объект, различные ассоциации, данные в каком-то другом магазине и т.д.)

Мне кажется, что кеширование русской куклы имеет смысл только тогда, когда у вас есть глубокая иерархия вложенного объекта. (в basecamp у вас есть список проектов → todos → todo → ). Однако, если у вас есть мелкая иерархия, лучше просто сделать недействительность самостоятельно.

Любая обратная связь будет оценена! Благодарю.

Ответ 1

На верхнем уровне нужно попасть в базу данных. Это можно избежать, сохранив метку времени в отдельной записи в кэш, с ключом по модели и идентификатору. Один из комментаторов статьи 1 (Мануэль Ф. Лара) предложил то же самое: "Есть ли еще один кеш, например, проекты/15-кратное время, когда у вас всегда есть последняя отметка времени для списка проектов?"
Я думаю, что вы правы в отношении "самого низкого" уровня в гнездовании. Возможно, вам придется провести некоторое тестирование, чтобы увидеть относительную производительность доступа к БД и визуализации частичного частичного.
Еще один хороший момент. Согласно рельсам docs, если вы передадите символ в :touch, он обновит этот атрибут в дополнение к updated_at - возможно, есть способ пропустить изменение Post#updated_at и обновить только столбец, например comments_updated_at. Затем вы можете использовать последний для кэширования. Но если вы пытаетесь избежать доступа к БД, вам нужно будет сохранить еще один ключ кеша для этой метки времени (например, в # 1 выше).

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

Ответ 2

Да. Но обычно сценарии с наилучшими сценариями и довольно хорошими сценариями встречаются довольно часто.
Да. В некоторых приложениях, которые я разрабатываю, рендеринг представления занимает в 10-20 раз больше времени, чем выполнение запросов. Посмотрите на свои тесты.
Если рендеринг сообщения является дорогостоящим, вы можете не захотеть прикоснуться к сообщению, но вместо этого составить ключ кеша списка комментариев из [@post.comments.max(:updated_at), @post.comments.size].