Comments 18
А запросы к субд при этом какие происходят?
Запросы идентичные с точностью до последовательности полей — разумеется, я это проверял в первую очередь, но оставил за пределами поста, чтобы его не загромождать.
> from django.contrib.auth.models import User
Почему вы используете стандартный класс? Мне, например, не очевидно, что джанга не делает что-нибудь этакое в этом классе после получения данных из базы, что может замедлить работу теста. Предлагаю убрать магию и написать модель User с нуля для джанго-тестов.
Почему вы используете стандартный класс? Мне, например, не очевидно, что джанга не делает что-нибудь этакое в этом классе после получения данных из базы, что может замедлить работу теста. Предлагаю убрать магию и написать модель User с нуля для джанго-тестов.
«Стандартный» класс никак не отличается от любых других, тем более что входит в contrib, а не в core. Сделал я это лишь чтобы не отвлекать внимание на детали создания таблицы. «Этакое» джанга видимо делает со всеми классами — я то начал тесты не потому, что испытывал проблемы со стандартными классами, а как раз наоборот — потому что проблемы были с моими собственными.
Конечно, для чистоты эксперимента вероятно нужно было бы сделать совсем пустой (только объявления полей) тестовый класс. Я подумываю о более широком обзоре скорострельности различных операций в различных ORM, там наверно сделаю именно так.
Конечно, для чистоты эксперимента вероятно нужно было бы сделать совсем пустой (только объявления полей) тестовый класс. Я подумываю о более широком обзоре скорострельности различных операций в различных ORM, там наверно сделаю именно так.
> Запросы идентичные с точностью до последовательности полей
Как минимум, вы забыли, поле is_superuser в sqlalchemy и pony тестах. Я бы вообще предложил создать таблицу руками и замапить на неё модели фрймворков. Джанга и sqlalchemy это умеют, про пони не в курсе.
Как минимум, вы забыли, поле is_superuser в sqlalchemy и pony тестах. Я бы вообще предложил создать таблицу руками и замапить на неё модели фрймворков. Джанга и sqlalchemy это умеют, про пони не в курсе.
Хотелось бы увидеть тут и peewee
А на стороне БД нельзя настроить правильное кеширование?
В предложенных условиях, БД отрабатывает настолько оптимально, насколько это вообще возможно. В своем первом посте я вроде бы упоминал, что неоптимизированный код нашего приложения приводил к тому, что нагрузка на процессор со стороны нашего кода была в несколько раз выше, чем нагрузка со стороны СУБД. После перевода наиболее критических запросов на чистый SQL, нагрузка стала распределяться примерно поровну.
Очень хорошее начинание. Может, стоит выложить на БитБакет, например? ORM — большая головная боль с т.з. производительности, но Алхимия — ещё хуже. Хотел бы увидеть, как ваш код работает и насколько он удобен.
Ладно производительность, но вот в деле «трансляции Python выражений в SQL» они конечно всех превзошли…
select(p for p in Person if 'o' in p.name)
Все ORM будут всегда тормозить. Надо построить нечто «компилируемое» в код Python в зависимости типа базы данных и прочее, что позволит без лишних операций и тысяч уровней абстракций производить необходимые действия. Фактический получится RAW SQL с человечным интерфейсом.
Вы имеете ввиду
простую компиляцию, из серии «а ассемблер быстрее», с чистым SQL-кодом на выходе,
или препроцессинг исходников перед деплоем на продакшн,
или некий построитель запросов в IDEна подобии как это в 1С сделано?
простую компиляцию, из серии «а ассемблер быстрее», с чистым SQL-кодом на выходе,
или препроцессинг исходников перед деплоем на продакшн,
или некий построитель запросов в IDEна подобии как это в 1С сделано?
Я имею ввиду кодо-генератор. На подобие Protobuf. Вы описываете необходимые структуры/схему базы данных, а «компилятор» генерирует код который работает с такой БД. Фактически получая статический код, который отсылает прямые запросы на сервер без лишних телодвижений построения сложных запросов ибо уже все построено. Само собой это накладывает ограничение на гибкость, но ничто не запрещает добавить необходимый набор «инструкций» описывающих необходимые операции.
Ну вот за счет многочисленных кешей компилированных и полукомпилированных запросов, pony имхо как раз ближе всего оказалась именно к такому подходу.
Ближе, но всеравно логики не мало в целом. Если потребуется массивная выборка данных, по несколько тысяч записей, создание тысяч микро объектов займет время. Выборка ненужных данных также займет не мало времени. Как возможный частичный выход попробуйте генерировать код классов с объявленным __slots__, что снизит накладные расходы на инстанцирование.
Sign up to leave a comment.
Снова о производительности ORM, или новый перспективный проект — Pony ORM