26. januar 2008 - 15:59Der er
8 kommentarer og 1 løsning
Design af database, kan det betale
Hej,
Jeg kom til at tænke på noget ...
Jeg har en database med nogle millioner records, hvor der kommer nye hver dag fra nogle spil ....
Lad os antage et simpelt eksempel:
spillerid ,serverid, dag, stats(indeholder flere ting IRL)
Nu har SQL 2008 endelig fået Date og Time adskilt ... Date 3 byte, time 4 byte vist nok, SmallDateTime 4 byte.
Alt i databasen er opgivet i dage, tidspunktet på dagen er uden betydning, så vælger man selvfølgelig "Date" som sin Column type.
Men kan det betale sig at oprette en table ved siden af med dagene, og så lave link mellem dem ... der kommer ca. 300k nye rows per dag, og gamle(dem over x dage gamle) bliver slettet ... ? small int fylder jo kun 2 byte ... så lidt plads kunne man spare, men giver det bare endnu størrer overhead, så man ender ud med dårligere performance ?
Jeg ved at det "behind the scenes" regnes som hel tal ... som ville selvf håbe at man kunne optimere lidt måske ? any one?
Som sagt importere jeg data 1 gang i døgnet, resten af dagen er de tal readonly ... hvad er optimalt her? Fill Factor 100, og så disable Index's når man laver inserts og enable dem igen efter så de opbygger deres index's igen eller kan de godt selv finde ud af at udsætte det Rebuild af index's når man har Fill Factor 100 ?
Det var vist alt ... hvis der er nogen der har rigtigt gode links til performance hints eller tips, må i gerne smide dem her ...
Jeg ville ikke lave den dagnummer-dag tabel. Udfra dine egne tal vil du spare 365*300000*1 bytes = 110 MB om året. Det er ingenting. Og CONTRAINT og JOIN vil koste en lille smule.
300000 INSERT bør ikke være så slemt. Hvor lang tid tager det ? Bare bundt flere INSERT i en enkelt transaktion (BCP er sikkert endnu bedre) og hav data og log op diske der hænger på en RAID controller med cache (sat til writeback og *MED* batteri).
Ja, man skal vel ud og se hvad der er af nye ting :-) og den Date kunne være dejlig lige netop her ... så jeg kan bruge Date i stedet for DateTime ... vigtigt det kører godt og hurtigt på langsom hardware ... så hvis der kommer nok hits, kan computeren jo altid opgraderes :-)
Skal køre på en ældre model ( 3 Ghz P4, 2 GB ram, 80 GB sata )
Ikke så meget pladsen jeg tænkte på ... mere performance, read og write ... plads er så billigt det ikke er et issue, men det er performance ikke ... og der kan jo spares en del, ved at bruge tingene på den optimale måde, så disken ikke bliver overbelastet.
Pt samles de i en SP og så fyres der ca. 20000 på samme tid ... og så igen og igen til de er færdige ...
Men tænkte mere på om det er en fordel at disable Index's inden man laver Inserts ... om det har noget at sige i forhold til ens Clustered Key som er min Primary key.
og så for et par dagen siden skrev jeg et indlæg, men super eksperten har det med at FUCKE, men nu er det lidt frisk på at skrive igen her :-)
Går ud fra at AUTO COMMIT OFF og COMMIT, bare skal ind før og efter x antal insert commands ... ?
Men hvad med den Fill Factor? Data er readonly i resten af døgnet?
Ja, det koster at genskabe ... men at lave en ALTER INDEX table REBUILD eller hvordan den command nu er ... gør jo også at der ikke er noget fragmentering, og ligesom optimere det hele lidt har jeg læst mig frem til ... så kan det jo ske at man alligevel vinder i sidste ende eller ?
hehe, måske, men der kan også skrives meget tykke bøger om hvad du ved :-)
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.
