Комментарии 12
Введение в оптимизация запросов к БД на django c помощью silk
Поправьте заголовок, например : Оптимизация запросов к БД на django
С graphql не работал, но слышал что там не всё так просто. Поделитесь опытом как его использование отразилось на производительности.
Производительность я не сравнивал, думаю не будет сильно отличаться от аналогичного rest api если там nestedserializers. Там можно использовать как сериализаторы, так всякие ObjectType из графена, это может отличаться. Это довольно инопланетянская штука при использовании с django и я не очень умею её готовить. Особенность в том, что фронту не надо просить менять что-то на каждый чих и может запрашивать разные наборы данных, включая связанные модели(в пределах описанной схемы), и это может привести или к лишним запросам или к N+1, но, наверное можно как-то по-умному составлять динамически запрос к БД, в зависимости от graphql запроса, но там где я его использовал был ограниченный набор запросов. И "мутации" писать мне не очень понравилось, хотя там можно создавать/обновлять сразу много объектов тоже в одном запросе.
Думаю сильно зависит от особенностей самого проекта, где-то это ложится хорошо, где-то overkill.
Я думал будет что-то вроде. Берём Джанго. Выкидываем Джанго. Пишем запросы руками - счастье радость восторг овации.
Но когда в руках молоток - весь мир гвоздь. Можно и на django sql оптимизировать ради "скорости разработки".
Джанга вполне себе инструмент. Да, надо помнить об оптимизации, а где не надо?
Что предлагаете? Фастапи? Старлайт? Фласк?
Пишем запросы руками.. И лишаемся автоматических миграций(да, это можно и без orm сделать, но тем не менее), конструктора запросов - теперь когда у нас разный запрос в зависимости от параметров запроса, например, разные фильтры - мы будем лепить это его в виде строки. Всякие валидаторы и сериализаторы будем изобретать заново. В итоге это будет больше кода и потенциально больше багов и уязвимостей. То что на django делается в несколько строк - например какой-то viewset с несколькими фильтрами будет сотни строк кода и десяток разных запросов руками.
В общем, орм придумали не просто так. Да, есть проекты, где без них вполне можно обойтись, но для всякого CRUD они сильно облегчают жизнь.
Опен-сорс это помойка процентов на 90. И ORM - это как раз то ещё хламище. Если сил не хватает свой генератор запросов сделать - ну одна дорога да в ОРМ. Он прекрасен...
ORM нормальный инструмент для своего круга задач. Быстрый старт, дешёвая поддержка. С производительностью и сложными запросами могут быть проблемы.
Один инструмент не будет эффективен на всех проектах, не надо везде строить свои велосипеды.
Ну да. Инженеры с головой тоже так думают, что свои велосипеды строить не надо.
Поэтому в нашем мире нет кафки, кликхауса, графаны и кубернетиса.
Или есть...
Да сделайте вы свой конструктор запросов. Ну ёлки зелёные!
Это всего на всего билд строки. Есть Jinja2. Она умеет.
Ну шир-потреб этот ОРМ, ну ё-маё.
Мы сделали свой велосипед. И не разу не пожалели об этом.
Да, в первые 3 месяца это был велосипед и ехал он не лучше не хуже ОРМ.
Но пол года спустя уже был похож на мотоцикл.
2 Года спустя - ну это летающая тарелка с генератором холодного синтеза и кварп ядром. На ней запросы в 3000 строк SQL писать и поддерживать легко.
А главное наш велосипед не избавляет разработчиков от знания/понимания SQL и баз данных.
В целом, мне не понятно. Откуда у людей любовь к готовым решениям.
Мы выкинули ОРМ со всех проектов, после первого нагрузочного теста...
У нас аж 3 ОРМ-а было и 2 мигратора. Никого не осталось.
ОРМ решает всего одну проблему, которую решать не нужно - как снизить когнитивную нагрузку с человека, который в СУБД полез. Всё.
Описание красивое. Похвастайтесь теперь деталями. Что за база? Как выглядит ваш ускоренный запрос на получение чего-то по айди? Запрос чтобы вытащить страницу фильтрованных данных и простой джойн двух табличек.
ОРМ решает всего одну проблему, которую решать не нужно - как снизить
когнитивную нагрузку с человека, который в СУБД полез. Всё.
Jinja2 решает проблему билда строки. Зачем вам это готовое решение, которое ещё и снижает когнитивную нагрузку с человека который складывает строки?
Миграциям на запросы побоку, они на модельках.
Публикации
Оптимизация запросов к БД на django