Не очень понятно, зачем вообще использовать DRF, если не использовать ORM? В чём глубокий смысл?
Конечно, могут быть отдельные редкие задачи, для которых зачем-то там полезно сделать прямой запрос в базу, но если всё приложение никак Django не использует - зачем тогда ему Django?
я бы не был столь категоричен - Django ORM не самая быстрая. Кроме того наверняка есть случаи, когда лучше использовать комбинацию ORM и psycopg2 - именно про них я и спрашивал !
Вадим, во-первых, вся суть Django в том, чтобы обеспечить разработчику возможность писать прикладной код на более высоком уровне абстракции. Причём практически все механизмы фреймворка построены вокруг ORM. Уход на более низкий уровень превратится в борьбу с фреймворком. Легче тогда взять Flask или Aiohttp. Во-вторых, "не быстрая" - это смотря с чем сравнивать. Если руки прямые, то обеспечить 300 rps одним инстансом вполне реально. А при наличии Celery, memcached и кубика с десятками подов, можно обеспечить обработку десятков тысяч запросов в секунду, как это делает тот же Instagram.
Дмитрий, откуда информация? Ещё пару лет назад их инженер писал, что единственный тюнинг, который они делали - запускали интерпретатор с отключенным сборщиком мусора. В их инженерном блоге я информации о переписывании ORM не нашёл.
Дмитрий, вот за это я так люблю видео, надо потратить час жизни, чтобы продолжить беседу, идеальный формат передачи знаний. На сколько я понял из слайдов, что-то с ORM они сделали достигнув 500 миллионов пользователей, и потребность у них в этом появилась не потому, что ORM медленный, а потому что СУБД задыхалась под нагрузкой и нужен был шардинг. Не? Ну, и замечу, что они ORM переписывали, а не на psycopg2 переходили.
Дмитрий, я посмотрел видео. Слайды были поняты правильно, инстаграм переписывал ORM не потому, что он показывал плохую производительность, а потому что им нужен был шардинг. Даже если бы они слали напрямую sql-запросы через psycopg2, на тех же объёмах данных и тех же нагрузках их СУБД загнулась бы без шардинга. К тому же в 2014-м они перешли на TAO, который вообще графовая СУБД, а потому реляционный Django ORM вообще не смог бы с ней работать. Очень интересная часть на 51-й минуте, когда докладчик говорит, что стоковый Django способен показывать очень высокую производительность и потребность в оптимизациях не появится раньше, чем проект достигнет масштабов инстаграма. Что вполне ответ на вопрос Вадим
Простой
Средний
