Александр Кошелев

Нет, я не про музыку решил написать. А про композицию данный, агрегацию если хотите.

В джанге на данный момент агрегации в ORM нет. Но как известно скоро должна появиться, а значит жизнь в очередной раз станет проще.

Зачем?

Но на много ли? Да, писать запросы с агрегацией станет проще. Но в большинстве случаешь выполнять запрос для сервера легче не станет. Вот ту на помощь приходит техника денормализации.

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

Наверно многие из вас в своих проектах писали код наподобие такого, тем более, если писали "свой блог движок":

class Post(models.Model):
   comment_count = models.PositiveIntegerField(default=0)

class Comment(models.Model):
   post = models.ForeignKey(Post, related_name="comments")

   def save(self):
      super(Comment, self).save()
      self.post.comment_count = self.post.comments.count()

   def delete(self):
      super(Comment, self).delete ...

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

Декларативность действительно была моей целью. Поскольку джанга сама в очень многих местах декларативна, то конечно хотелось инструмент выдержанный в том же стиле, но не теряющий от этого функциональности.

Ситуация с многоэтажными декораторами меня тоже напрягает, и сейчас например файл, где хранятся шаблонные теги для этого блога, напоминает действительно urls.py в случае массового использования generic views.

Решение одно - разделить функционал и мета информацию инвалидации. Т.е. грубо говоря принудительно применять декоратор в старом синтаксисе "функция=декоратор(функция)". Тут то как раз и идея с одним "инвалидационным" файл пригодится.

В конце концов, моя реализация лишь proof of concept идеи сигнальной инвалидации. Как мне кажется, вот этот самый "proof" получился. Оно работает! Понятно, что в отдельных конкретных проектах, она может оказаться неудобной или не очень полезной. Но тут каждый сам волен обтесать её под свои нужды и условия.

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

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

Итак, у нас есть приложения блога и в нем такие модели:

class Post( models.Model ):
    title = models.CharField(max_length=100)
    date = models.DateTimeField(default=datetime.now)
    text = models.TextField()

class Comment( models.Model ):
    post = models.ForeignKey( Post, related_name = "comments" )
    text = models.TextField()

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

def get_latest_posts():
    return Post.objects.all().order_by( "-date" )[ :5 ]

Отлично, функция готова и мы её можем применять в нужном нам месте. Но зачем каждый раз мучить базу и просить её вернуть последние посты? Ведь пишу то я не часто (ну так получается:)), поэтому можно это дело закешировать и не тратить ресурсы попусту, т.к. они не часто обновляются.

Но классический вариант с таймаутом тут не очень удобен: если сделать маленький таймаут, то падает эффективность кеширования, если же учитывая большие интервалы между добавлением новых постов, то можно и таймаут побольше поставить, но тут сразу появляется проблема. Я добавил новый пост, а кеш обновится только через сутки (ну реально большие интервалы ...

Как я обещал ранее, реализация кеширования с инвалидацией по-средствам сигналов - стала моей целью на прошедших каникулах. И была сделана в легкой и непринужденной атмосфере благополучия и меланхолии(я в первые с первого курса заработал стипендию!:)).

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

Ещё хочу отметить, что система уже некоторое время успешно применяется в данном блоге.

Кратко суть. Идея состоит в том чтобы кеш протухал не по таймауту, а при возникновении некоторого события, которое порождает сигнал, который потом обрабатывается и может справоцировать инвалидацию. Следовательно данный подход должен быть боле логичен и более оптимален чем классический. Поскольку использование таймаута может быть неэффективено, когда периодичность изменения не детерминирована. Либо получается, что кеш слишком часто обновляется, либо наоборот долго висит старый. Первый вариант сказывается на производительности, а второй на актуальности информации, которую получает пользователь сайта. И того и другого хочется избежать.

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

Все хотят выжать из своих приложений максимум производительности. Общепринятые техники это - оптимизация и кеширование. Про один из вариантов оптимизации - запросов к базе, я уже писал, а вот про кеширование ещё нет. Сейчас хочу рассказать о некоторых способах кеширования, которые почерпнул из джанго сообщества, помимо конечно стандартных средств, их вы и так прекрасно знаете:)

Кеширование шаблонных тегов

Интересный метод, который позволяет кешировать результат работы шаблонного тега, особенно актуален для разного вида inclusion тегов. Пример реализации предложил Маньяк в своём форуме вот тут. Основной проблемой как всегда является инвалидация и уникальный идентификатор записи. В данном случае первая решается выставление таймаута, вторая определением специальной функции, которая должна сгенерировать уникальный идентификатор.

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

Инвалидация кеша с помощью сигналов

Это интересная идея принадлежит Сергею Кириллову(хотя конечно наверно не ему одному она пришла в голову, просто попался на глаза именно его вариант), которую он озвучил в django-developers Суть простая - сбрасывать кеш, по пришествию какого-либо сигнала. Просто и со вкусом, но почему-то не получила большого отклика по горячим следам в том треде.

Если развить и унифицировать, то может получиться очень интересно и практично. Всё хочу этим заняться ...