06. februar 2004 - 23:22Der er
5 kommentarer og 1 løsning
Overfører mange rækker eller beregne meget på database serveren?
Hejsa
Jeg har et lille problem, som jeg ikke lige kan gemmenskue.
Hvad er bedst, at overfører rigtig meget data fra databasen, eller lave rigtig mange beregninger på serveren?
Sagen er den, at jeg er ved at lave noget statistik til hjemmesider. Hvergang en side bliver vist, bliver der gemt én række i databasen.
Hvis man så forestiller sig en godt besøgt side, lad os sige 100.000 sidevisninger om dagen, og man vil have statistik for en måned, jeg så bliver det 3.000.000 rækker der skal overføres. Så her ville det være en fordel, at gruppere alle sidevisninger på dag, således at der maks bliver overført 31 rækker.
Men hvordan bestemmer man grænsen for, om det er databaseserveren eller applikationen der skal lave regnearbejdet?
Generelt kan det betale sig at lave alle bulk operationer på database serveren. Den er normalt hurtigst til at arbejde med store datamængder.
Men det afhænger naturligvis også af hvilken database det drejer sig om - Access, SQL Server, Oracle og MySQL - og hvor kraftig databaseserveren er i forhold til applikationsserveren - plus hvad netforbindelse du har mellem de to servere.
Releationelle databaser er i virkeligheden den gode gamle mængdelære fra folkeskolen (det der med prikker og cirkler der lapper over hinanden) - flytter du over på en applikationsserver skal du pludselig behandle data række for række, og det er normalt langsommere.
Med 3 millioner rækker ville jeg nok vælge at lade databaseserveren (hvis det er Oracle eller SQL Server på rimelig hardware) foretage opsummeringerne. Der skal naturligvis være de nødvendige indeks til at understøtte tingene, ellers dutter det ikke. Opsummeringer her opfatter jeg som ting der kan holdes i ren SQL med GROUP BY og lignende operationer.
Men er det operationer der kræver at du opbygger en rigtigt loop (WHILE, FOR NEXT etc) og håndterer data række for række - f.eks. med IF udtryk etc og måske flere underliggende LOOPS - så vil jeg mene at applikationsserveren vil være bedre end databaseserveren. Database servere er som nævnt ikke beregnet til at håndtere data række for række.
Jeg har lært den hårde vej, at det er vigtigt at lave god SQL. F.eks. har jeg på food4u.dk (den er lavet for et par år siden) brugt rigtig dårligt SQL. Hvis jeg f.eks. skulle lave en liste med titlen og datoen af de fem første opskrifter, så har jeg bare sagt select * from food4u, og så brugt de fem første rækker, og det ved jeg nu at man IKKE skal.
Derfor vil jeg i fremtiden bruge tid på min SQL, er der en god bog eller hjemmeside, hvor man kan læse om optimere osv., især sådan noget med at sammensætte to tabeller osv?
Der findes en del om at optimere SQL - bla jeg har selv lavet et par artikler der ligger her på eksperten; Basal performance tuning, 1-3. Det giver en grundide der er specielt beregnet på Microsoft SQL Server, men en del kan direkte overføres på andre databasesystemer.
Der er nogle rigtig hardcore kurser der handler om performance tuning. I MS SQL regis, check bl.a. efter en fyr der hedder Peter Otzen.
Prøv at søge i Google på ordene: performance tuning sql
MySQL kender jeg ikke meget til, rent optimeringsmæssigt. Da jeg arbejdsmæssigt ikke benytter MySQL har jeg nemlig ikke gidet sætte mig ind i dens opbygning - så nedenstående er altså kun fornemmelser (og delvist hvad jeg lige har skimmet på deres hjemmeside):
På mange måder er basen ret primitiv, bl.a. er det først i de nyeste versioner der understøttes indeks, subqueries og sådanne ting som triggers, procedurer og funktioner kommer først i senere versioner.
Umiddelbart har jeg indtryk af, at den ikke har en særlig effektiv query rewriter (en intern processs der der omskriver din sql til mere effektive udtryk) og jeg ved intet om hvordan dens Query Optimizer benytter indeks og statistikker i forbindelse med udarbejdelsen af en query plan (hvordan den vælger at tilgå data, hvilke tabeller og indeks der skal bruges først etc).
Hvis Query Optimizeren er som jeg tror, så er den regelbaseret fremfor cost-baseret. Ved en regelbaseret optimizer har det ekstrem betydning i hvad rækkefølge du skriver tabeller og join-kriterier - ved en costbased har det ingen betydning; Udfra statistikkerne og indeks vælger den den mest effektive måde at få data ud på. Men også ved costbased optimizers er der forskelle her; Oracle kan fx kun bruge ét indeks i optimeringen, Microsoft SQL Server kan bruge flere. Det betyder at oprettelse af et godt indeks er sværrere på Oracle end på MsSQL.
Der er en artikel i artikelsektionen om at optimere MySQL ved brug af indeks - den er nok værd at læse. Skal du gøre noget seriøst mht optimering så er du nød til at sætte dig ind i de ovennævne dele af MySQL's databasemotor - du vil nok kunne finde informationerne på deres hjemmeside.
Nej, der er stor forskel på de forskellige databaser og deres optimering. Der er nogle tommelfingerregler man kan gå ud fra, men hvilke afhænger af, hvordan databasen opfører sig.
Og uddybning vedr. regelbaseret: Ved en regelbaseret optimizer er det op til *dig* at få joinet tabeller så det største antal rækker skæres af hurtigst muligt (fx join altid den lille tabel på venstre side og den store på højre) - ved en costbased kan du (som regel) regne med, at optimizeren selv sørger for at joine mest effektivt.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.