Valg av databasesystem (PHP), leseytelse er viktig

[Lokaltog]

Heisann!

 

Håper noen kan hjelpe meg litt her. Jeg er kjent med at PHP har støtte for flere forskjellige databasesystemer, og slik jeg har forstått det har alle systemene sine fordeler og ulemper når det kommer til funksjonalitet/ytelse.

 

Jeg trenger hjelp til å velge et system som er 100% kompatibelt med PHP og Apache, og som har god ytelse på lesing. Det er snakk om et nettsted med opptil 15 000 unike besøkende daglig, og nettstedet har en database med rundt 30 000 brukere og over 1 000 000 private meldinger og gjestebokinnlegg og slikt. Løsningen som blir brukt der i dag er ikke god nok, da serveren til tider kjører veldig sakte, og jeg må derfor finne en bedre løsning på dette problemet.

 

Og da lurer jeg på om det er noen sjeler som kan fortelle meg hva som er best når det kreves svært mye lesning, ikke fullt så mye skriving, og det ikke stilles store krav til avanserte funksjoner. Systemet bør være SQL-basert (om det finnes alternativer), og pris er ikke et problem.

 

På forhånd takk!

[kaffenils]

Det er et komplisert spørsmål du stiller. Svaret er at det ikke finnes "det riktige" RDBMS til denne jobben.

 

Det er mange andre parametere enn valg av RDBMS som vil påvirke suksessfaktoren i ditt tilfelle.

 

Er databasedesignet, tenker da på normalisering, indexering, vedlikeholdsrutiner osv. optimalt for akkurat denne løsningen?

Normalisering sier seg selv. Hvis databasen ikke er normalisert vil det i 99,99% av tilfellene gå ut over performance.

Riktig indexering vil f.eks. øke lesehastigheten, men det går på bekostning av skrivehastigheten. For løsninger med stor andel av lesing i forhold til skriving vil det f.eks. være et godt utganspunkt å indexere kolonner det ofte filtreres på, men som sagt, dette går ut over skrivehastigheten. Dessuten vil det være lurt å måle hvor mange inserts det er i en index mellom hvert vedlikeholdsintervall slik at du kan sette av ledig plass i hver index-page til nye inserts.

Vedlikehold av databasen er svært viktig, spesielt hvis det skrive til den. Indexer blir fragmentert over tid (ja, faktisk) og dette går selvfølgelig ut over performance, både for lesing og skriving. De databasesytemene jeg kjenner til har kommandoer for å reindexere/defragmentere indexer. Kjør disse med jevne mellomrom, men husk at de ofte låser tabellene som indexeres så det er greit å finne et tidspunkt der databasen ikke er i bruk. Dessverre er ikke det alltid så lett...

 

En annen viktig faktor for db-performance er selvfølgelig disksystemet. Hvis du kjører på vanlige ATA-disker så kan du ikke forvente noen fantastisk performance. Penger er eneste begrensing. Hvis du ønsker det så kan du jo plassere hver tabell og hver index på et eget 0+1 RAID volum. Transaksjonsloggen får selvfølgelig også et eget volum for seg selv. Problemet er selvfølgelig at dette koster myyye penger. Derfor kan du jo moderere deg til å sette opp et speilet volum til OS'et, et 0+1 til databasen og et 0+1 til transaksjonsloggen=10 disker totalt. Hvis det blir i meste laget kan du trygt legge db + transaksjonslogg på samme volum.

 

Jeg vet at dette ikke er hva du spurte om, du ville jo bare ha et navn, men jeg ønsker bare å fortelle at hverken MySQL, Oracle eller MS SQL alene kan gjøre jobben for deg.

[Lokaltog]

Takk for lang og god tilbakemelding. Det høres virkelig ut som dette er noe du har god greie på!

 

Dessverre har ikke jeg så lang fartstid at jeg kjenner til alle begrepene du bruker, så det hadde vært kjempeflott om du kunne forklart disse tingene for meg:

 

1. Normalisering av en database

2. Hvordan man indekserer en tabell riktig

3. "Dessuten vil det være lurt å måle hvor mange inserts det er i en index mellom hvert vedlikeholdsintervall slik at du kan sette av ledig plass i hver index-page til nye inserts."

 

Jeg har lett etter mer informasjon rundt dette med ytelse, og slik jeg ser det er det mest aktuelt å kjøre en nyere versjon av MySQL med InnoDB-tabeller på denne serveren. Finnes det funksjoner for vedlikehold av et slikt oppsett?

 

Jeg kjenner ikke til diskoppsettet på serveren slik den står i dag, men jeg skal nevne for kunden hva du har skrevet. Igjen, takker så mye for et godt svar!

[roac]

En annen viktig faktor for db-performance er selvfølgelig disksystemet. Hvis du kjører på vanlige ATA-disker så kan du ikke forvente noen fantastisk performance. Penger er eneste begrensing. Hvis du ønsker det så kan du jo plassere hver tabell og hver index på et eget 0+1 RAID volum. Transaksjonsloggen får selvfølgelig også et eget volum for seg selv. Problemet er selvfølgelig at dette koster myyye penger. Derfor kan du jo moderere deg til å sette opp et speilet volum til OS'et, et 0+1 til databasen og et 0+1 til transaksjonsloggen=10 disker totalt. Hvis det blir i meste laget kan du trygt legge db + transaksjonslogg på samme volum.

Det er nok her man må gjøre noen grep for å få rå ytelse ja. For å få rå ytelse til et minimum av pris synes følgende som en god løsning: Eksternt RAID kabinett fylt med så mange små 10k RPM SCSI disker som man har råd til, konfigurert i Raid 0+1. 15 RPM disker er raskere enn 10k RPM, men også mye dyrere, så rent ytelsesmessig er det raskere med to 10k RPM disker enn en 15k RPM.

 

Som du også var inne på så er korrekt indeksering viktig.

[roac]

Normalisering sier seg selv. Hvis databasen ikke er normalisert vil det i 99,99% av tilfellene gå ut over performance.

Normalisering går ut over størrelse, men ikke nødvendigvis ytelse. Dersom det er en en relativt kompleks sammensetning av flere tabeller kan det helt klar lønne seg å denormalisere databasen, og kanskje spesielt i dette tilfellet siden det var leseytelsen som var viktig. Dette tyder på at det blir gjort vesentlig flere uthentinger av data enn innsettinger og modifiseringer. Man kan derfor leve med den ekstra tiden det tar å oppdatere eller sette inn denormaliserte data, siden man får kjappere uthenting av dataene (siden man slipper mer eller mindre kompliserte joins).

 

Legger ved link til en artikken om denormalization; Responsible Denormalization.

[mikaelandre]

Normalisering sier seg selv. Hvis databasen ikke er normalisert vil det i 99,99% av tilfellene gå ut over performance.

Normalisering går ut over størrelse, men ikke nødvendigvis ytelse. Dersom det er en en relativt kompleks sammensetning av flere tabeller kan det helt klar lønne seg å denormalisere databasen, og kanskje spesielt i dette tilfellet siden det var leseytelsen som var viktig. Dette tyder på at det blir gjort vesentlig flere uthentinger av data enn innsettinger og modifiseringer. Man kan derfor leve med den ekstra tiden det tar å oppdatere eller sette inn denormaliserte data, siden man får kjappere uthenting av dataene (siden man slipper mer eller mindre kompliserte joins).

 

Legger ved link til en artikken om denormalization; Responsible Denormalization.

det stemmer det, men det betyr ikke at du ikke skal normalisere. det beste er å først lage en normalisert database, og så evt. slå sammen noen tabeller som ofte henger sammen, hvis du ønsker å bedre leseytelsen på bekostning av litt redundans. Et eksempel kan være å ha postnummer/poststed i egen tabell, men som kan være mer praktisk å ha i samme tabell som personene.

 

Dessverre har ikke jeg så lang fartstid at jeg kjenner til alle begrepene du bruker, så det hadde vært kjempeflott om du kunne forklart disse tingene for meg:

 

1. Normalisering av en database

2. Hvordan man indekserer en tabell riktig

3. "Dessuten vil det være lurt å måle hvor mange inserts det er i en index mellom hvert vedlikeholdsintervall slik at du kan sette av ledig plass i hver index-page til nye inserts."

 

1. Det finnes 5 vanlige normalformer, men du trenger egentlig bare å tenke på de 4 første.

 

Første normalform sier at alle attributter skal ha atomiske verdier. Litt usikker på den presise definisjonen, men det er noe slikt som at har et attributt int som type i en post, så skal det attributtet ha det i alle postene i den tabellen.

 

Andre normalform er viktigere. Den sier at ingen ikke-nøkkel attriubutter skal være delvis avhengige av nøkkel. Det vi si at en vanlig attributt ikke skal være avhengig av deler av en nøkkel (hvis du har flere attributter som nøkkel)

 

Tredje sier at for alle avhengigheter X->Y skal X enten være en supernøkkel, eller Y være et nøkkelattributt. Dette er den typiske postnummer/poststed formen. Poststed er avhengig av postnummer, men postnummer er mest sannsynlig ikke nøkkelen i en persontabell, det vil være et id felt, evt personnummer.

 

BCNF, eller Boyce-Codd normalform kalles også 3,5 nf. den er nesten det samme som for 3, og sier at for alle avhengigheter X->Y så skal X være en supernøkkel. Dette regnes som den viktigste, og målet bør være å få alle tabeller på bcnf.

 

Finnes også en fjerde normalform som tar seg av flerverdiavhengigheter, men den er ikke så viktig.

 

Men for å få dine tabeller normalisert bør du nok sette deg litt mer inn i dette, evt. poste relasjonsskjema her, så kan vi sikkert hjelpe til.

 

2. Hvordan indeksere riktig. Det er egentlig ganske enkelt. Tenk igjennom hvilke spørringer du vil spørre. Der du har "SELECT.... WHERE attr1='x';" så vil du ha index på attributten 'attr1'. Dette gjelder for de spørringene som stilles mye. typiske ting er id felt, som ofte brukes som primærnøkkel. mange databsesystemer lager automatisk index på primærnøkler. Problemet med index er at insert og update spørringer tar lengre tid. derfor må du vurdere bruken nøye, og prøv å finne ut ca. hvor stor andel av spørringene som vil bli select og insert/update. hvis du legger til og sletter 10000 brukere i uka, vil du ha få indekser. hvis du legger til 100000 brukere en gang og de alltid blir der, så kan du leve med at det tok lang tid den ene gangen du la de til.

 

3. dette kan jeg ikke

 

Håper det var litt hjelp ihvertfall. Og kaffenils, det virker som om du har peiling på dette, så gjerne rett meg om jeg har feil!

 

 

og ja, jeg hadde eksamen i databaser for 3 dager siden

[kaffenils]

1. Databasens normalform forteller noe om redundans av data i databasen. En database bør i som hovedregel ikke inneholde redundant informasjon. Normalisering av en database gjøres vha. normalformer. 3dje normalform er i de fleste tilfeller godt nok for å tilfredsstille krav om god design. Av og til vil du også komme borti Boyce.Codd normal form, så det kan vøre greit å lære seg kravene til denne, men i det tilfellet du nevner i første innlegg så tror jeg ikke du vil trenge denne normalformen.

 

Her er noen linker med gode eksempler:

Første normalform

Andre normalform

Tredje normalform

BCNF, fjerde og femte normalform

 

2. Det finnes ikke noe fasitsvar på hva som er riktig indexering. Primærnøkler er jo alltid indexeret. Fremmednøkler bør også indexeres med mindre variansen av verdier er lav. Med det mener jeg f.eks. at hvis et fremmednøkkelfelt kun inneholder fem forskjellige verdier i en tabell med flere tusen rader så er det liten varianse. MS SQL Server tar f.eks. ikke hensyn til en index hvis er verdi i indexen utgjør mer enn 1% av den totale variansen. Da foretar SQL Server istedet en full sortering og deretter en scanner den gjennom de sorterte dataene. Regner med at mange andre RDBMS også har tilsvarende algoritmer.

Som du skjønner av dette så er det derfor meningsløst å f.eks. indexere en bit/bool verdi.

 

Du bør også indexere felt som det ofte søkes i, gitt at det jeg skrev over er oppfylt. Eksempel på dette kan være brukernavn i brukertabellen. Du vil nå sikkert tenke at meldingsfeltet i databasen vil være lurt å indexere. Svaret her er dessverre nei. Og grunnen er enkel. Som regel så søkes det på ord og uttrykk inni teksten (mao. må det brukes wildcards) og da blir indexen ubrukelig. Hvis RDBMS har støtte for full text indexering er selvføleglig saken løst, og de fleste nyere systemer har det. Det er viktig å merke seg at full text indexer settes opp p åen annen måte en vanlige indexer. I MySQL bruker du f.eks. FULLTEXT funksjonen. MS SQL har en Full-Text Indexing Service. Spørring mot full text indexer gjøres også på en egen måte.

 

3. Dette er et emne som egentlig er meget komplisert å finne noe godt svar på, og jeg kjenner bare til det på SQL Server. I grove trekk går det ut på å sette av ledig plass ved reindexering i hver page (en page er SQL Servers fundamentale lagringsenhet på disk og er 8K) slik at data i minst mulig grad rearrangeres mellom pages.

 

Personlig ville jeg ikke valgt MySQL, da funksjonaliteten i denne er svært begrenset i forhold til SQL Server og Oracle. Kostnadsmessig er derimot MySQL selvfølgelig suveren.

[kaffenils]

Nå har jo faktisk mikaelandre og roac allerede gitt svært gode svar ser jeg.

[Lokaltog]

Tusen takk for knallgode svar, skjønner begrepene nå.

 

Personlig ville jeg ikke valgt MySQL, da funksjonaliteten i denne er svært begrenset i forhold til SQL Server og Oracle. Kostnadsmessig er derimot MySQL selvfølgelig suveren.

Det stilles ingen krav til avanserte funksjoner, da det for det meste vil gå på enkle insert- og select-spørringer. Er det andre argumenter mot bruken av MySQL bortsett fra funksjonalitet? Tenker på hastighet, måten databasene er konstruert på osv.

[Ueland]

altså, denne størrelsen her er IKKE stor for SQL systemer, (Da snakker jeg bla MySQL), hvis ting går tregt allerede så er en av disse tre scenarioene en virkelighet:

 

1) php-systemet er ikke godt nok (som kjent skiftet vi fra phpbb grunnet skalering)

2) databasestrukturen er ikke god nok

3) Serveren er ikke kraftig nok.

 

 

Har du fått undersøkt alt og kommet ned til at det er SQL systemet som er dårlig?

(Bruker dere MySQL i dag og det er tregt så er ikk MySQL problemet hvertfall)

[Lokaltog]

Serverne som kjører i dag kjører en eldre versjon av ASP og SQL Server (tror jeg). Jeg står ikke bak noe av koden der, og aner ikke hva utviklerne tidligere har gjort for å kjøre serveren på trynet.

 

Jeg får muligens en jobb med å rydde opp i disse databasene, og for at kunden skal føle at det er pengene verdt å la meg skrive ny PHP-kode og sette opp ny databasestruktur så forhører jeg meg her, slik at jeg iallefall setter opp databasen riktig.

 

Men hvis du mener at de størrelsene jeg nevner i første post ikke er store for vanlige SQL-systemer som MySQL så er det iallefall betryggende å høre.

 

Skal fortelle videre hva dere har forklart her. Tusen takk for hjelpen, folkens!

[mikaelandre]

det er jo også sånn at sql generellt er mye raskere enn php. ved å skrive gode spørringer som gjør at du slipper å sortere resultatet etterpå kan du spare mye tid. har du feks en tabell med personer og skal ha ut de som bor i oslo, så lar du sql finne ut hvem det er, ikke php. samme med sortering. men det visste du sikkert

[kaffenils]

Det stilles ingen krav til avanserte funksjoner, da det for det meste vil gå på enkle insert- og select-spørringer. Er det andre argumenter mot bruken av MySQL bortsett fra funksjonalitet? Tenker på hastighet, måten databasene er konstruert på osv.

For din egen del (spesielt i jobbsammenheng) så må det være mye mer interessant å lære et "skikkelig" RDBMS som Oracle eller MS SQL Server. MySQL passer foreløpig kun til enkle systemer, og det er derfor det er blitt så populært å bruke som database for CMS og andre webapplikasjoner.

[Ueland]

Er greit hvis du dokumenterer påstandene dine:

 

Du kan jo se på kundelisten til MySQL(http://www.mysql.com/customers/), spørs om pricegrabber, yahoo, google etc mener at mysql kun funker for "små systemer".

[roac]

Er greit hvis du dokumenterer påstandene dine:

 

Du kan jo se på kundelisten til MySQL(http://www.mysql.com/customers/), spørs om pricegrabber, yahoo, google etc mener at mysql kun funker for "små systemer".

Kaffenils skrev enkle, ikke små systemer. Siste versjon jeg har sett på av MySQL hadde en rekke svakheter i forbindelse med komplekse systemer, mao fravær av ting som views, stored procedures, user defined functions og om jeg ikke husker helt feil var det svært begrenset med muligheter for constraints også. Nå er ikke MySQL mitt satsingsområde, så jeg vet ikke hva som har skjedd der den siste tiden. Det jeg dog vet er at MySQL var veldig kjapp, men sannsynligvis på grunn denne mangelen på funksjonalitet. Jeg anser det som meget sannsynlig at ytelsen på MySQL kommer til å droppe (eller har allerede gjort det) når denne funksjonaliteten kommer på plass.

 

Derfor er jeg tilbøyelig til å være enig med kaffenils i at MySQL egner seg for enkle systemer.

 

Noe sier meg at jeg bør ta meg en titt på spesifikasjonene til MySQL igjen, ved en anledning.

[kaffenils]

Er greit hvis du dokumenterer påstandene dine:

 

Du kan jo se på kundelisten til MySQL(http://www.mysql.com/customers/), spørs om pricegrabber, yahoo, google etc mener at mysql kun funker for "små systemer".

Jeg kan kun dokumentere mine påstander med egne erfaringer. MySQL mangler rett og slett for mye funksjonalitet til at det er lønnsomt å bruke det til noe annet en enkle (ikke små, som i små datamengder) systemer. Tenk bare på hvor mye forretningslogikk en kan bygge inn i en stored procedure.

[Lokaltog]

Heh, aner ikke hva halvparten av det dere prater om betyr engang. Noe sier meg at jeg kanskje bør kjøpe en bok eller to om databaser før jeg begir meg ut på mer komplekse prosjekter.

 

Anyhoo, som allerede nevnt krever dette systemet veldig lite funksjoner. Det er som en kjempediger blogg med medlemsfunksjonalitet og sånt, så det bør gå bra med MySQL inntil videre.

 

En annen ting jeg lurer på i denne sammenhengen er hvilken fremgangsmåte som er mest praktisk når det gjelder statistikkfunksjoner. Tenker da på tellere som viser antall innlegg sammenlagt, hvem som er innlogget og andre sånne ting. Funker det å kjøre en SELECT COUNT(`kolonne`)-spørring for hver gang statistikken hentes fram eller er det bedre å sette opp en cron job som teller opp innlegg og sånt om natta? Kortere sagt; vil ytelsen droppe kraftig hvis 5000 brukere samtidig skal vise antallet rader i forskjellige tabeller?

[kaffenils]

Kortere sagt; vil ytelsen droppe kraftig hvis 5000 brukere samtidig skal vise antallet rader i forskjellige tabeller?

 

Ja, hvis 5000 brukere skal utføre COUNT på 1 million rader samtidig så får du store performance problemer (er det derfor dette forumet til tider er siiiiiiiiirup????).

 

De jeg vil anbefale er å lage egne tabeller for statistikk. En tabell kan da inneholde totalt antall innlegg og evt. antall inlegg pr. gruppe/forum hvis du skulle det. Istedet for å gjøre en realtime COUNT så leser du istedet fra denne tabellen. Sett opp en schedulert jobb som f.eks. kjører hvert 10. sekund som oppdaterer statistikktabellen(e) eller endre deler av statistikken ved innlegging av nye rader. Faktisk så vil du allerede her ha nytte av et bedre RDBMS enn MySQL, ved f.eks. bruke triggere eller stored procedures til å utføre oppdateringen av statistikk.

Endret 1. juni 2005 av kaffenils

[Lokaltog]

Ah, tenkte ikke på å kjøre jobben relativt ofte. Men det er jo logisk, å kjøre en COUNT hvert 10. sekund vil ikke være noe problem i forhold til å la 5000 brukere kjøre det på ett sekund. Nok et mysterium oppklart!

[Ueland]

For å løse det enkelt så oppdaterer du f.eks statistikken for totalt antall innlegg når du poster noe, så slipper du unna cron etc.

 

kaffenils: Nei.