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

Можно конечно, https://docs.djangoproject.com/en/1.8/topics/cache/#the-low-level-cache-api

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

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

у меня там 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 ?

http://django-cachalot.readthedocs.org/en/latest/

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

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

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

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

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

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

ну да, select where id in tree_level

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

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

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

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

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

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

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

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

Обосрётся твой безграмотный админ, мой грамотный админ решит эту проблему.

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

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

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