» »

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

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

Tito ::

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!

BigWhale ::

Treba delat pametne indexe in pametne joine... Nisi se nic omenil kak hardware to vse skupaj laufa...

Pregledat tudi kako je s povezavami na bazo koliko querijev se dela in splaca se narediti kak cache v ramu... to precej pohitri zadeve...

Tito ::

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 ;).

BigWhale ::

Joini so potratni ja... :) Zato jih moras pametno uporabljat ;)

Zgodovina sprememb…

  • spremenil: BigWhale ()

jype ::

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.

ADF ::

Predlagam ti, da napišeš sledeče stvari:
- CREATE TABLE ... stavke (da vidimo, katere podatkovne tipe uporabljaš)
- CREATE INDEX ... stavke
- SELECT ... stavke, ki so tako potratni.

Poleg tega nebi škodilo če poveš kak hardware uporabljate, kateri OS in katero verzijo baze.
Kot pa je jype omenil, bi rekel, da je velika možnost, da po kreaciji indeksov niste ANALYZE TABLE ... pognali .

Tito ::

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)

pivmik ::

Tito priporočam ti, da se znebiš baze filmov, ker tako ali tako imamo iMDB.
Brezveze delaš kopijo celega iMDBja še na svojem strežniku.
Pri podnapisu bi bil dovolj iMDB link za več info o filmu.
(je pa kul da ima podnapis sliko filma, žanr, zaplet)


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?
LP, Gregor GRE^

Ziga Dolhar ::

> 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?
https://dolhar.si/

Tito ::

... Gre le za to da v enem queriju izbiraš podatke iz dveh tabel, seveda z določinimi pogoji ...

No drgač pa glede filmske baze ima svoj smisel na strani, ker je povezovalni element, ker je nujno potrebna za to da so imena podnapisov točna ... Drugače pa poglej malo po bazi in vidu boš da so pri nas dobrodošle tudi serije, ki so lepo razdeljene po določenih epizodah in hkrati imajo prevod. Potem so še tu opisi / recenzije in podobne stvari. Ni sploh nobenega problema, ker sedaj stran dela zelo hitro...:D

BigWhale ::

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...

pivmik ::

Ok, hvala za pojasnilo, sem že razumel ko je povedal Tito, BigWhale pa je še potrdil z primerom in dobro razlago.

Ziggga: Govorim o joinu o katerem se tukaj pogovarjajo :)
LP, Gregor GRE^


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

SQL inner join

Oddelek: Programiranje
392424 (1679) smacker
»

Normalizirana struktura - query

Oddelek: Programiranje
191412 (1032) frudi
»

SQL indeks?

Oddelek: Programiranje
9849 (849) ta_pravi
»

pgSQL problem z indexi...

Oddelek: Izdelava spletišč
7898 (808) Tito
»

MySQL združevanje tabel..

Oddelek: Programiranje
191407 (1222) Nemenej

Več podobnih tem