Optimizacija querija

[Mitar]

Zdravo!

Delam en benchmark za primerjavo MongoDB in PostgreSQL in sem spisal v
raznih sistemih isto kodo, ki poskusa prebrati podatke v dummy blog
aplikaciji. Cudi me, da po mojih meritvah je Django query 10x
pocasnejsi od mojega na roke spisanega SQL. Pa me zanima, ce ima kdo
kaksen predlog, kako zoptimizirati ta Django query oziroma kaj delam
narobe:

https://github.com/mitar/peerdb-benchmark/blob/postgresql-python/django_project/benchmark/management/commands/query.py

Veliko hitrejse:

https://github.com/mitar/peerdb-benchmark/blob/postgresql-python/python_only/query2.py


Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

[Domen Kožar]

Ce izvajas enak query, potem je pac Django ORM pocasen. Sestavljanje objektov ni tako poceni operacija :)

--
To sporočilo ste prejeli, ker ste prijavljeni v skupino »Django Slovenia« v Google Skupinah.

Če se želite odjaviti od skupine in ne želite več prejemati njenih e-poštnih sporočil, pišite na naslov django-slo+...@googlegroups.com.
Če želite objavljati v tej skupini, pošljite e-poštno sporočilo na naslov djang...@googlegroups.com.
Obiščite to skupino na naslovu http://groups.google.com/group/django-slo.
Za več možnosti obiščite spletno mesto https://groups.google.com/d/optout.

[Miha Valencic]

Mitar,

verjetno ze poznas, ce pa slucajno ne: mogoce ti v pomoc pride logging
SQL queryev ki jih django izvaja - ko vidis kaksen query naredi,
pogosto lahko optimziras kako bo naredil join tako da vkljucil v
inicialnem queryu tudi child collection.

http://stackoverflow.com/a/11373691/22099

Zelo uporaben pa je seveda tudi DjDT - Django Debug Toolbar:
https://github.com/django-debug-toolbar/django-debug-toolbar
Pogosto se vidi da queryi niso izvedeni z JOIN-i, kar posledicno
pomeni N+1 query kar se zelo zelo pozna pri iteraciji skozi objekte.
Vidim da se uporabljas select_related in prefetch, tako da poglej se
kaksna je dejanska razlika v SQL queryu ki gre na bazo, pa bo tam
kaksen hint.

Sicer pa kreiranje objektov iz data readerja, kot pravi Domen, ni
zastonj... Pri majhnih podatkih in hitri bazi (se posebej ce si ze
izvedel querye, je tabela najverjetneje kar v RAMu) se vecino casa
porabi za ORM.

LP,
Miha.

> To sporočilo ste prejeli, ker ste naročeni na skupino »Django Slovenia« v

> Google Skupinah.
> Če se želite odjaviti od skupine in ne želite več prejemati njenih e-poštnih
> sporočil, pišite na naslov django-slo+...@googlegroups.com.

> Če želite objavljati v tej skupini, pišite na naslov
> djang...@googlegroups.com.
> Obiščite skupino na naslovu http://groups.google.com/group/django-slo.
> Če si želite ogledati več možnosti, obiščite
> https://groups.google.com/d/optout.

[Mitar]

Zdravo!

No, ko sem pogledal querije, ki jih gradi, je gradil taksne, kot sem
jih tudi sam zoptimiziral na roke. Izgleda, da select_related in
prefetch delata res dobro. Queriji sami so bili pod sekundo. Ampak
spraviti to v ORM pa je vzelo potem dodatnih 20 sekund. Tako da se je
dobro tega zavedati. Jaz nisem vedel, da je toliksen overhead. Da je,
mi je jasno, ampak 20x pa je malo strasljivo. :-)

(Mimogrede, ni najhitrejse narediti en velik join med vsem, ker ima
SQL ta problem, da v m2m joinih se veliko delov vrstic potem podvaja
in imas velik prenos podatkov do clienta. Sem sestavil tudi velik join
in je res pocasno. Je boljse narediti tako kot dela select_related in
prefetch in narediti nekaj querijev, ki jih potem zdruzis na clientu.)


Mitar

http://mitar.tnode.com/
https://twitter.com/mitar_m

[Marko Mrdjenovic]

A prav razumem, da SQL izvedba traja skoraj nič, da django iz tega naredi objekte pa 20s?

To se mi zdi noro veliko za to kar django počne…

fry

[Domen Kožar]

sqlalchemy *khem* *khem*

[Gasper Zejn]

Mitar, nikjer nisem zasledil, da si napisal koliko recordov pravzaprav je v
rezultatu.

lp,
Gašper


Dne četrtek, 18. december 2014 ob 20:19:14 je Marko Mrdjenovic napisal(a):

[Mitar]

Zdravo!

Gre za 1000 blog postov s 10000 komentarji. Blog poste sem potagal s
100 tagi in potem sel preko vseh tagov in prebral vse poste z vsemi
komentarji pod tem tagom. Vsi ti queriji skupaj predstavljajo potem
meritev.

OK, malo sem pretiraval, sedaj ko gledam stevilke za branje. Stevilke
so. Python direktno:

1 2.988023
2 20.396734
4 136.500102
6 389.143757
8 759.505686
10 1513.241354

Django:

1 14.415499
2 64.843065
4 276.110180
6 722.425032
8 1798.867594
10 3065.447675

Prva stevilka je multiplyer zgoraj omenjenega stevila dokumentov.
Druge sekunde. Torej prvo je faktor 7 razlke, potem pa se nekje pri
faktorju 2 ustavi. To ni niti tako slabo. Zanimivo, da je pri vecjem
stevilu dokumentov manjsa razlika. To so mogoce kaksne motnje pri
kratkih querijih ali kaj.

Zakaj bi sqlalchemy bil kaj hitrejsi?


Mitar

http://mitar.tnode.com/
https://twitter.com/mitar_m

[Domen Kožar]

SQLAlchemy ponuja vmesen layer imenovan Expression Language API (http://docs.sqlalchemy.org/en/latest/core/tutorial.html),

ki ga Django nima.

Poanta je ravno v tem, da se znebis overheada generiranja objektov in hkrati ohranis moc dinamicnega jezika za sestavljanje SQL-a ter hitrost izvajanja.

Seveda, za vecino primerov to ni relevantno omenim zato, ker v tvojem primeru je.

lpd

[Sebastjan Trepca]

Just use .values()?

[Mitar]

Zdravo!

.values() ti ne da dostop do related objektov potem, ne?


Mitar

http://mitar.tnode.com/
https://twitter.com/mitar_m