Sun, 05 Oct 2003 at 10:08 GMT Morten Trab wrote
> I forbindelse med et nyt site (
www.smsnyheder.com) har vi i udviklingsfasen
> diskuteret lidt om MySQL kan håndtere alle de database kald, samt den mængde
> data der kommer med tiden...
>
> Her i starten kan MySQL SAGTENS følge med, men med tiden forventes der mange
> kald og store mængder data...
Ganske normal udvikling. Fornuftigt at bekymre sig på forhånd.
> Hvor kommer MySQL's begrænsninger, og er der i det hele taget sådanne??
Hvis I bruger transaktioner er Mysql ikke super hurtig. Hvis I bruger MyISAM
filer (tabeller) skal i passe på ved inserts da mysql gerne måser hele tabellen
mens den opdaterer sine index'er.
Min erfaring med MySQL er at hvis man kan undvære transaktioner er det kun
dårligt applikationsdesign der kan kvæle den.
Tabeller unden fornuftige index'er, enorme mængder data der skal sorteres til
ingen verdens nytte o.s.v.
Stil som krav til udviklerene at der skal argumenteres for hver sql som explain
mener koster mere end et par læste rækker.
Da MySQL ikke (i en produktions-version) kan køre med subselects vil man ofte
komme til at kode disse i applikationen. Det bør man i sin analyse beregne som
en enkelt sql, som her er det altså summen af rækker rapporteret med explain
der skal trigge de rynkede øjenbryn.
MySQL har ikke view's. Det kan jeg godt lide, da man så med ro i sjælen kan
tillade sig at lave kolonner med redundant information. Disse redundante
kolonner er database-design-mæssigt noget hø, men de kan speede en bikses
select gevaldigt op.
Ulempen er naturligvis at det fylder mere på disken og tager en lille smule
længere at skrive data. Og så naturligvis at man skal kode det er producere
det redundante data.
Men disk og cpu-tid er som oftests forsvindende billigt i forhold til det
en enkelt søgning på et disksystem koster.
> Og i så fald at der er begrænsninger vi kan risikere at rende panden imod,
> hvor skal vi så hen mht. database der kan håndtere det, samt køre på Linux??
Måske noget med den maksimale tabelstørelse. Gamle Linux'er synes ikke om
filer stører end 2G. Dette arves så af MySQL som ikke gør super fornuftigt
hvis datamængden overskrider denne grænse.
I kan måske preloade jeres "site" med syntetiske bruger-data, for så at teste
performance.
Man kan også få MySQL til at logge SQL'er der tager længere end en grænse i
selv sætter. Hvis I fylder en hulens masse realistiske data i databasen, og
så sætter grænsen til 1 sekund vil i måske fange nogle smuttere fra
explain-øvelsen.
Hvis I virkelig skal kunen skalere som gale kan det anbefales at afskille
selects og updates+inserts+deletes til at bruge hver deres database-handle.
Det vil vise sig nyttigt hvis i sidenhen beslutter at splitte
database-serveren op på flere maskiner via replikering.
Replikering er dog kun nyttigt som performance-booster hvis I har markant
flere læsninger end skrivninger.
Replikering var forøvrigt forbavsende let at få til at virke. (synes jeg)
/Morten
