Problem s podatkovno zbirko (postgreSQL) in povabilo k sodelovanju...

No problem je ta, da stvar požira ogromne količine procesorja in nam povzroča sive lase. Sprva smo mislili, da je večina problemov zaradi indexov in mySQLom. Nato smo šli na posttgreSQL, kjer pa se je stvar še poslabšala.

Zanima me, če je možno, da je taka požrešnost posledica povezovanje med tabelami (join) in da to povzroča ogromno porabo CPUja. Že res, da imamo veliko bazo, kjer je 80 000 vrstic s podnapisi in 20 000 uporabnikov in okoli 30 000 filmov. Vendar samo po sebi naj nebi požiralo toliko procesorske moči. SEdaj imam vprašanje, če mi kdo lahko pove zakaj je taka poraba in kakšne so možne rešitve/ alternative. Kaj se moramo v velikih bazah izogniti povezovanju tabe (join) in tako naprej.

Hkrati bi vabil, da se nam morda kdo pridruži pri popravljanju strani. Saj smo trenutno pošteno v škripcih in je stran zadel infarkt. Tako, da bi morda kakšna sveža prespektiva resnično pripomogla k boljšim rešitvam ... (če še ne vsete gre za stran Podnapisi.NET)


Za vse se vam lepo zahavljujem!

No bili smo presenečeni kako potraten je lahko join pri velikih tabelah, pa ni problem o "pametni" ali "nepametni" uporabi, ker v vsakem primeru je bila poraba procesorja ogromna! No drgač ko smo se joinov znebil smo stran optimiziral za 3500%. Niti sanjal se nam ni na začetku, da je lahko to tak problem... Prej se nam je stran odprla llokalno v okoli 5s, res absurdno in neuporabno po predelavi kode pa se je zmanjšal na 0.11s in to le stem, da smo se znebil joinov... Tak da smo prišli do rezultata, da stvar nikakor ni uporabna za velike tabele (nad 1000 vrstic).

Dej bomo še mal pogledal kodo in malo zoptimiziral, sam do zdej smo naredel že kar ogromno na tem ;).

Join je v osnovi zahtevna operacija. Najprej moras jit po enem indeksu (ali tabeli, ce indeksa ni) in nabrat vse reference, potem pa po drugem indeksu (ali tabeli) in nabrat druge reference. Ce je zraven se tretja tabela moras plezat naprej.

Ce baza ne razume, kaj od nje hoces, se lahko zgodi da gre skozi drugi index tolikokrat, kolikor je vrstic iz prve tabele. Blazno slabo, zato je fino uporabit kak explain, da vidis kaj baza pocne. Poskusis optimizirat join (v dokumentaciji za mysql in za postgres pise kako namignit optimizerju kaj hoces od njega).

Splaca se tudi poganjat analyze table vsake toliko, ker sicer se optimizer brez tezav lahko odloci za povsem napacno zaporedje opravil, ali pa naredi kaj, kar je bistveno drazje kot si on misli.

Stvar je taka zadevo smo rešili stem, da smo se izognili joinom na nepotrebnih mestih in stran dej dela za 3500% hitrej (dejansko izmerjeni čas prej in sedaj je za 3500% različen). Poraba procesorjev enako padla iz 100% na man kot 10%...

KAj mamo samo kot zanimivost, ker ne potrebujem več pomoči...

Gentoo linux
2× athlon 2800+
250 GB disk
1,7GB ECC registriranega rama (tega sicer ni velik, vendar trenutno je dovolj)

> A mi lahko kdo razloži kaj pomeni ta join?
A je to kaka napredna funkcija v (My)SQL ali samo kak način dostopanja do podatkov?

Kater "join"? "Join" nasplošno kot konstrukt v sql poizvedovalnem stavku, ali kaj konkretnega iz te teme, PicNiK?

SELECT bla.foo, lala.foo, fafa.foo, qwe.bar, asd.bar, zxc.bar FROM foo, bar WHERE
id.bar = id.foo AND ....

To je join...

In ce nimas poindexiranih id.bar in id.foo si screwed... ;>

... no pri tem queriju najbrz ne ampak ce kaj bolj kompliciranega naredis, pa se kaj grupiras in sortiras, potem pa zna ratat smorn precej hitr...