Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
High Performance SQLAlchemy
Search
Vladimir Magamedov
November 01, 2014
Programming
5
890
High Performance SQLAlchemy
PyCon Ukraine 2014
Vladimir Magamedov
November 01, 2014
Tweet
Share
More Decks by Vladimir Magamedov
See All by Vladimir Magamedov
Microservices
vmagamedov
0
44
grpclib: pure-Python gRPC implementation
vmagamedov
0
520
Microservices / gRPC
vmagamedov
1
420
Other Decks in Programming
See All in Programming
CSC307 Lecture 03
javiergs
PRO
1
490
[KNOTS 2026登壇資料]AIで拡張‧交差する プロダクト開発のプロセス および携わるメンバーの役割
hisatake
0
250
Rust 製のコードエディタ “Zed” を使ってみた
nearme_tech
PRO
0
150
AgentCoreとHuman in the Loop
har1101
5
230
プロダクトオーナーから見たSOC2 _SOC2ゆるミートアップ#2
kekekenta
0
200
インターン生でもAuth0で認証基盤刷新が出来るのか
taku271
0
190
QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する #RSGT2026
shibayu36
2
4.3k
高速開発のためのコード整理術
sutetotanuki
1
390
Patterns of Patterns
denyspoltorak
0
1.4k
登壇資料を作る時に意識していること #登壇資料_findy
konifar
4
990
2026年 エンジニアリング自己学習法
yumechi
0
130
AIエージェント、”どう作るか”で差は出るか? / AI Agents: Does the "How" Make a Difference?
rkaga
4
2k
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
128
17k
Test your architecture with Archunit
thirion
1
2.1k
Everyday Curiosity
cassininazir
0
130
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.3k
For a Future-Friendly Web
brad_frost
182
10k
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
160
Ten Tips & Tricks for a 🌱 transition
stuffmc
0
64
The Cult of Friendly URLs
andyhume
79
6.8k
Designing Experiences People Love
moore
144
24k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
117
110k
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
160
The Cost Of JavaScript in 2023
addyosmani
55
9.5k
Transcript
High Performance SQLAlchemy Vladimir Magamedov @vmagamedov
Как выполнять работу быстре? 1. Не делать ничего лишнего ◦
Не загружать лишние данные ◦ joinedload, subqueryload ◦ Не использовать ORM объекты
Как выполнять работу быстре? 1. Не делать ничего лишнего 2.
Оптимизировать оставшееся
Как оптимизировать оставшееся? 1. Профилировать – борьба со следствием
Как оптимизировать оставшееся? 1. Профилировать – борьба со следствием 2.
Писать простой код – исправить причину
Как влияет простота кода на его эффективность? 1. Решение любой
задачи зависит от того, как мы на неё смотрим 2. Простой код облегчает изменение кода
Признаки сложного кода? Условия (if..else) 1. Наделяют код умом 2.
Логика распределяется по всему приложению
Признаки сложного кода? Условия (if..else) 1. Наделяют код умом 2.
Логика распределяется по всему приложению Решение: выносить логику как можно выше, концентрировать в одном месте
Признаки сложного кода? Универсальные функции – Функции, выполняющие более одной
задачи
Признаки сложного кода? Универсальные функции – Функции, выполняющие более одной
задачи Решение: как можно большая часть функций должна выполнять одну задачу
Признаки сложного кода? Избыточные аргументы 1. Чаще всего это ORM
объекты 2. Ещё хуже когда обращаются к связанным объектам, например: product.company.owner.contacts.phone
Признаки сложного кода? Избыточные аргументы 1. Чаще всего это ORM
объекты 2. Ещё хуже когда обращаются к связанным объектам Решение: принцип "Бритвы Оккама"
Признаки сложного кода? Неявные запросы Routing View Template Helpers queries
queries queries
Признаки сложного кода? Неявные запросы 1. Спрятанные запросы внутрь функций
◦ снаружи на них никак нельзя повлиять
Признаки сложного кода? Неявные запросы 1. Спрятанные запросы внутрь функций
2. Ленивая загрузка колонок и объектов ◦ ведет к проблеме N+1 запросов
Признаки сложного кода? Неявные запросы 1. Спрятанные запросы внутрь функций
2. Ленивая загрузка колонок и объектов Решение: запросы как и логику надо выносить как можно выше, чтобы иметь возможность ими управлять
Вывод 1. Использовать только необходимое 2. Бо́льшая часть простых функций,
выполняющих одну задачу 3. Концентрировать логику и запросы в одном месте
Вывод 1. Использовать только необходимое 2. Бо́льшая часть простых функций,
выполняющих одну задачу 3. Концентрировать логику и запросы в одном месте Решение: SQLConstruct
SQLConstruct Декларативный способ описания запросов…
SQLConstruct Декларативный способ описания запросов… … позволяющий описать что мы
хотим получить из базы данных…
SQLConstruct Декларативный способ описания запросов… … позволяющий описать что мы
хотим получить из базы данных… … и как эти данные преобразовать в удобный для использования вид.
Пример query = ConstructQuery( # аналог session.query() { "id": User.id,
# название атрибута "name": User.name, # вычисляемое значение }, db.session, # scoped session ) # результат запроса [Object({"id": 1, "name": "Guido"}), Object({"id": 2, "name": "Barry"})]
apply_ query = ConstructQuery( { "id": User.id, "name": apply_(string.upper, #
функция [User.name]), # аргументы }, db.session, ) [Object({"id": 1, "name": "GUIDO"}), Object({"id": 2, "name": "BARRY"})]
if_ { "text": Comment.text, "author": if_(Comment.user_id, then_=User.name, else_="Anonymous"), }
define query = ( ConstructQuery( { "name": User.name, "photo": apply_(url_for_photo,
[Photo.id, Photo.name]), }, db.session, ) .join(User.photo) )
define @define def url_for_photo(photo) def body(photo_id, photo_name): return url_for('photo', id=photo_id,
slug=slugify(photo_name)) return body, [photo.id, photo.name]
define # в описании результата url_for_photo.defn(Photo) # объектная форма url_for_photo(photo)
# функциональная форма url_for_photo.func(photo.id, photo.name)
define query = ( ConstructQuery( { "name": User.name, "photo": url_for_photo.defn(Photo),
}, db.session, ) .join(User.photo) )
get_ query = ConstructQuery( { "name": User.name, "photo": get_(url_for_photo.defn(Photo), User.photo),
# relationship }, db.session, )
map_ query = ConstructQuery( { "name": Product.name, "photos": map_(url_for_photo.defn(Photo), Product.photos),
}, db.session, )
Вопросы? github:vmagamedov/sqlconstruct