Ytelsesmessig forskjell på en eller flere tabeller

[simenss]

Om man har en database med brukere som inneholder personlig data, samt brukerens innstillinger for den aktuelle nettsiden: Vil det være en ytelsesmessig forskjell mellom å dele tabellen i to (f.eks. user_data og user_settings)?

[blackbrrd]

Det kommer faktisk litt an på bruken av tabellene. I dette tilfellet tviler jeg på at det vil ha noe å si, utenom at du nok gjør evt videreutviklingsjobb lettere for deg selv.

[Manfred]

Jeg ser ingen grunn til å dele de, med mindre du gjør mye oppslag mot settings hele tiden. Noe man også kanskje burde og kan unngå ved å bruke cookies / sessions...

[roac]

Om man har en database med brukere som inneholder personlig data, samt brukerens innstillinger for den aktuelle nettsiden: Vil det være en ytelsesmessig forskjell mellom å dele tabellen i to (f.eks. user_data og user_settings)?

9567351[/snapback]

Slik jeg forstår dette, så kan dette være f eks snakk om et forum. I så tilfelle må du huske på at du vil hente NOE informasjon om posterne når du viser postene, f eks hvor lenge brukeren har vært medlem. Denne informasjonen bør ligge i en tabell da, mens brukerens innstillinger bør ligge i en annen, slik at datamengden det gjøres oppslag mot er så liten som mulig for vising av postene.

 

Det kan selvfølgelig være andre forhold også, men som jeg tror jeg har vist ganske klart nå så må man ikke bare vite hva slags data man har for å kunne svare på spørsmålet ditt, men også hvordan de brukes.

[simenss]

Slik jeg forstår dette, så kan dette være f eks snakk om et forum. I så tilfelle må du huske på at du vil hente NOE informasjon om posterne når du viser postene, f eks hvor lenge brukeren har vært medlem. Denne informasjonen bør ligge i en tabell da, mens brukerens innstillinger bør ligge i en annen, slik at datamengden det gjøres oppslag mot er så liten som mulig for vising av postene.

 

Det kan selvfølgelig være andre forhold også, men som jeg tror jeg har vist ganske klart nå så må man ikke bare vite hva slags data man har for å kunne svare på spørsmålet ditt, men også hvordan de brukes.

9569647[/snapback]

Skal gi en litt grundigere forklaring på hvordan dataene brukes: Tabellen for brukere inneholder foreløpig innloggingsinformasjon, personlig informasjon til brukerens profil og brukerens innstillinger for hvordan siden oppfører seg (alternativer for e-post, meldinger, standarder etc.). De innstillingene som brukes hele tiden, lagres i sessions når brukeren logger på.

 

Men når en bruker f.eks. skal stemme på et objekt, kobles brukernavnet fra tabellen users med objektene fra tabellen objects. Slike koblinger bruker jeg mye. Blant annet til visning av profiler, hvor brukerens objekter kobles mot profilens bruker. Har er det kun noen få av radene i users som hentes ut.

 

Det samme gjelder brukerens venneliste. Her hentes brukerens venner fra friends som kobles opp mot vennenes brukernavn (tabellen users).

 

Det jeg tenkte var at det ville være mindre krevende å koble f.eks. brukernavn og objekt, om tabellen users inneholdt > 15 rader for innstillinger. Men jeg vet egentlig ikke hva jeg snakker om, så det er mulig jeg tar helt feil.

[Manfred]

en ting her først som sist: du bruker ikke brukernavn som nøkkel i de andre tabellene??

[simenss]

en ting her først som sist: du bruker ikke brukernavn som nøkkel i de andre tabellene??

9573257[/snapback]

Hehe, nei. Noe klønete skrevet. Hver bruker har en unik ID på 9 siffer, så nøkkelen som kobler tabellene sammen er ID-en. Tenkte mer på at ofte skal brukernavnet vises i forbindelse med f.eks. profiler, objekter, stemmer etc. og da må brukernavnet hentes fra user-tabellen.

Endret 25. september 2007 av simenss

[Manfred]

*puste lettet ut*

[roac]

To mulige løsninger for optimal ytelse, og da i prioritert rekkefølge.

 

1) God indeksering

 

Det synes å være en stor grad av eksakte oppslag (match kolonne = verdi), og indekser kan da gjør stort utslag på ytelse.

 

2) Splitt brukertabell til bruker og innstillinger

 

Vil ikke ha på langt nær så stor innvirkning som pkt 1, men vil bedre situasjonen hvis pkt 1 av en eller annen grunn ikke tas til etteretning.

[kaffenils]

*puste lettet ut*

9576882[/snapback]

 

Hvorfor puste lettet ut av det? Det hadde vært like riktig bruke brukernavn som primær- og fremmednøkler.

[blackbrrd]

Tjah..

 

La oss si at brukernavnet er på f.eks 8 tegn encodet i unicode, du har da opptil 8*16bit= 16byte pr primær/fremmednøkkel

 

La oss si at du bruker en id av typen integer som er på 4byte.

 

La oss si at du har en primærnøkkel og 8 fremmednøkkler og du må indeksere alle disse. Du får da indekser på 16*9=144byte pr rad, mens du hvis du bruker integer må ha en ekstra indeks på brukernavn for oppslag, mao 9*4+16=52byte per rad.

 

La oss si at du har 1 000 000 brukere, du får da indekser på enten 144mb eller 52mb. For at det skal hjelpe noe særlig må man gjerne ha indekser i minne, noe som er mye lettere når de er på 52mb istedetfor 144mb.

 

En ting til - hva hvis du tillater brukeren å endre brukernavn - hvis du har det som primær/fremmednøkkel må du huske på alle tabeller som referer til primærnøkkelen... I ett litt større system så kan du kanskje ha 30 tabeller som referer til brukertabellen... Ikke spesiellt morsomt å måtte kjøre en update på 30+ tabeller istedetfor 1.

[kaffenils]

Selvfølgelig kan du ikke la brukeren endre navn hvis du bruker brukernavn som PK.

 

Angående indexer så regner jeg med at spørringer mot brukertabell blir utført basert på et spesifikt brukernavn. Da har det lite å si om indexen er 50 eller 150 MB. Vet ikke hvordan mysql lagrer et B-tre, men for SQL Server så ville forskjellen vært prkatisk talt umålbar mhp. tid.

 

Hvis dette er et forum så vil det ha større negativ effekt å bruke Int som primærnøkkel hvis du skal vise brukenavn for hvert innlegg eller post. Da må alle spørringer joine brukertabellen med brukerid for å hente ut brukernavn, istedet for at brukernavn er PK og en dermed slipper å gjøre joinen mot bruketabellen.

 

Om en skal velge brukerid (int) eller brukernavn (varchar) som PK og FK kommer helt an på bruken. For et forum ville jeg valgt brukernavn.

 

Forskjellen på indexstørrelsen mellom int og varchar(16) blir forresten lagt fra så stor som du har kalkulert (52 og 144 MB). Du må ta hensyn til at hver rad i indexen sannsynligvis har en header på noen bytes. Radene er sannsynligvis også oppdelt i pages som også muligens har en header på noen titalls bytes. Slik er det i hvertfall i SQL Server, men jeg kan ikke si hvordan MySQL eller PostgreSQL gjør det.

[blackbrrd]

Selvfølgelig kan du ikke la brukeren endre navn hvis du bruker brukernavn som PK.

9577799[/snapback]

Ikke bra design spør du meg

 

Angående indexer så regner jeg med at spørringer mot brukertabell blir utført basert på et spesifikt brukernavn. Da har det lite å si om indexen er 50 eller 150 MB. Vet ikke hvordan mysql lagrer et B-tre, men for SQL Server så ville forskjellen vært prkatisk talt umålbar mhp. tid.

9577799[/snapback]

 

Jeg er helt enig at du ikke vil se forskjell i tiden det tar å slå opp indeksen om den er på 50mb eller 150mb. Poenget er at hvis resten av designet i databasen er tilsvarende vil du ende opp med at indeksene dine er 3x så store som de trenger å være, noe som igjen gjør at du kan ende opp med å ha for lite minne til å holde alle delene av indeksene som er ofte brukti minne, men må hente de inn fra disk hele tiden. I så tilfelle vil du merke stor forskjell i ytelse.

Endret 26. september 2007 av blackbrrd

[kaffenils]

Jeg pleier selv å bruke surrogatnøkler istedet for naturlige nøkler, så jeg snakker egentlig i mot meg selv her.

 

Det var egentlig et svar til manfred som mente at det er HELT hårreisende å bruke brukernavn som nøkkel. Jeg ville kommentere at det er helt greit å bruke brukernavn så lenge du vet om begrensingene som følger med, f.eks. at brukernavnet i praksis ikke kan endres.

 

Som alltid er det fordeler og ulemper med begge alternativer, og det er egentlig bruken som bestemmer hvilken løsning en bør velge. Av erfaring vet vi at bruken frem i tid ikke er enkel å bestemme, så jeg har lært av erfaring av surrogatnøkler er mest fleksible.

[kaffenils]

Selvfølgelig kan du ikke la brukeren endre navn hvis du bruker brukernavn som PK.

9577799[/snapback]

Ikke bra design spør du meg

 

Tror du hoppet over et "ikke" i setningen min. Betydningen blir annerledes hvis du gjør det

[blackbrrd]

Selvfølgelig kan du ikke la brukeren endre navn hvis du bruker brukernavn som PK.

9577799[/snapback]

Ikke bra design spør du meg

 

Tror du hoppet over et "ikke" i setningen min. Betydningen blir annerledes hvis du gjør det

9578276[/snapback]

 

Å ikke la brukeren endre brukernavn fordi du har brukt brukernavnet som primary/foreign key er dårlig design.

[blackbrrd]

Jeg pleier selv å bruke surrogatnøkler istedet for naturlige nøkler, så jeg snakker egentlig i mot meg selv her.

 

Det var egentlig et svar til manfred som mente at det er HELT hårreisende å bruke brukernavn som nøkkel. Jeg ville kommentere at det er helt greit å bruke brukernavn så lenge du vet om begrensingene som følger med, f.eks. at brukernavnet i praksis ikke kan endres.

 

Som alltid er det fordeler og ulemper med begge alternativer, og det er egentlig bruken som bestemmer hvilken løsning en bør velge. Av erfaring vet vi at bruken frem i tid ikke er enkel å bestemme, så jeg har lært av erfaring av surrogatnøkler er mest fleksible.

9578270[/snapback]

 

Jepp

 

Det var derfor jeg mente det var rart du tok det fram, og kommenterte at det er dårlig design av diverse årsaker...

[kaffenils]

Det var derfor jeg mente det var rart du tok det fram, og kommenterte at det er dårlig design av diverse årsaker...

 

Hæh?

Jeg har ikke sagt sagt at det ene er feil og det andre er riktig. Brukernavn utgjør en grei naturlig nøkkel så lenge du er klar over de begrensninger som følger med. Det var mer en "protest" mot manfreds kommentar om at det er er HELT idiotisk å bruker brukernavn som PK, for det mener jeg at det ikke er. Men jeg mener at det er mer fleksibelt å bruke en surrogatnøkkel, og burde kanskje fått med det i mitt første innlegg hvor jeg sier at begge er like riktige.

 

Uansett så er vi enige

[blackbrrd]

Godt sagt