LINUX.ORG.RU

выборочное кеширование в Django

 ,


1

2

Можно ли в Django работать с кешем не на уровне представлений, а на уровне запросов?

есть тяжёлая база, которая даже без ORM долго шевелится, хочется засунуть пару тройку результатов запроса из представления в кеш до черезнедельного обновления базы

★★

Может, но в твоём случае лучше работать с кэшем на уровне СУБД или переписать код таким образом, чтобы оно не тормозило.

Goury ★★★★★ ()

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

gnunixon ★★★ ()
Ответ на: комментарий от Goury

у меня там mptt деревья, одно из них с 6 тысячами листиков, которые возвращаются от mptt::get_descendants, а потом через ManyToManyField выборка в 200 сотням тысяч items

индексы стоят

переопределил get_descendants так, чтобы работало не со всем деревом, с определённым уровнем

и четырёх этажный подсточёт количества (для пагинации) items

Item.objects.filter(category__in=category.get_descendants(include_self=True), hidden=False).annotate(count_items=Count('id')).count()

тоже переписан на sql, вместо 4 запросов к 3 таблицам, один с подзапросом к двумя

key_buffer_size = 512M

вроде на уровне Django orm и sql некуда больше оптимизировать — вот и думаю про кеширование.

а что за кеширование на уровне СубД?

имеет ли смысл выносить эти таблицы (read only) в sqlite ?

fMad ★★ ()
Последнее исправление: fMad (всего исправлений: 2)
Ответ на: комментарий от fMad

Item.objects.filter(category__in=category.get_descendants(include_self=True))

Насколько понимаю весь профит от mptt здесь берется и превращается в тыкву. То есть итоговый запрос начинает выглядеть как SELECT ... from items WHERE category IN (:categories).

A1 ()
Ответ на: комментарий от fMad

а что за кеширование на уровне СубД?

А что за база данных без админа базы данных?
Найми нормального админа и у него спроси.

а потом через ManyToManyField выборка в 200 сотням тысяч items

m2m явно не для такого извращения придумывались.

Goury ★★★★★ ()
Ответ на: комментарий от Goury

Найми нормального админа и у него спроси.

Нормальный админ дороже разработчика, который умеет в app-level кеш раза в три. К тому же что будет делать админ когда память на сервере кончится? А? Обосрется твой админ.

A1 ()
Ответ на: комментарий от A1

ребята, давайте жить дружно

по делу, там в прайсе товары которые могут быть в нескольких разных категориях и подкатегориях, по-этому без M2M ни как (вроде бы)

база, обычный большуший прайс, обновляемый раз в неделю, по-этому смысл загонять его в память mysql сервера не большой, память для другого может понадобиться

fMad ★★ ()
Ответ на: комментарий от fMad

По делу, постгря с массивами в которых содержится цепочка вложенности и gin индекс на него подойдет гораздо лучше.

Ты можешь закешировать выдачу дерева. Но количество листиков скорее всего будет сильно просаживать выборки айтемов на верхних уровнях и их тоже надо будет кешировать. Кстати ты можешь хранить товары в сфинксе, бесплатно получишь обратный индекс для категории и FT одновременно.

A1 ()
Ответ на: комментарий от A1

Хотя если у тебя каталог меньше миллиона, то это детский сад и этот датасет влезет полностью в память даже на дохлой vps.

A1 ()
Ответ на: комментарий от Goury

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

A1 ()
Ответ на: комментарий от A1

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

Goury ★★★★★ ()
Ответ на: комментарий от Goury

А у нас и нет проблем. С определенных уровней нагрузок DBA просто не нужны как класс.

A1 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.