24. maj 2010 - 15:51Der er
18 kommentarer og 1 løsning
database design for hastighed
jeg har oprettet to felter på en kundetabel som hedder extraInfoIDs og extraInfo hvor id'er og info er separaret af et specialtegn. Dette har jeg gjort istedet for at lægge dem i en separat tabel, fordi jeg mener jeg kan fordele arbejdsbyrden bedre mellem webserver og dbserver på den måde. Jeg kan så sortere dem i koden på webserveren med en split streng funktion og sætte dem i de rigtige felter i brugerfladen.
Nu har jeg så et medfølgende problem når jeg skal lave en søgning i extraInfo med et id som er i ekstraInfoIDs. Jeg er nødt til at splitte strengen i mysql samtidig med sægningen. Hvordan?
Skal jeg droppe min metode og gøre det på den traditionelle måde ?
Teknologi, AI og forretning er i centrum på Computerworlds Cloud og AI Festival i København d. 18. og 19. september. Se hele programmet for den store konference om strategisk brug af Cloud og AI på: www.cloud-festival.dk
Okay, jeg vil gætte på du har ret, men når nu der kommer 500.000 kunder og hver kunde har 5 ekstra felter, bliver søgningen ikke langsommere når der 2,5 millioner records istedet for 500.000 ? Synes egentlig det var mere overskueligt på min måde, fortæl mig hvorfor jeg tager fej, jeg forstår det ikke helt.
okay, det tænkte jeg nok. det er så nu jeg skal lære at bruge indexer. jeg har en slags fobi mod at læse om det fordi det lyder så ekstremt kedeligt, så hvis du giver mig sql sætningen til at lave indexet helt kort i denne situation er pointene dine.
Nu går jeg ud fra at det er en MySQL database du har, og MySQL tilbyder desværre ikke så mange forskellige index muligheder, som f.eks. PostgreSQL, men der er stadig muligheder for at optimere databasen og motoren bag den.
Men kig også på din SQL queries, da de har en stor del af performancen med også, og søg evt. på brugen af Denormalization hvis du har mange og/eller store JOIN queries. Her kan du også hente en del performance, også selvom du bruger lidt længere tid på at duplikere data i flere tabeller er trade-off'et langt bedre i mange join tilfælde.
Og så skal du kigge på dine queries om det er range, point, multipoint, etc. og om der bliver brugt nogle af de mere tunge funktioner som Distinct og Group By, som også fortjener ekstra behandling. Og tænk over på hvad koden kan gøre for dig og hvad databasen skal gøre for dig og hvad de i fællesskab skal gøre.
Jeg forsøger at holde mig til helt simpel mysql da jeg muligvis skal migrere til mssql senere. Det er derfor jeg helst vil joine og sortere i koden, plus jeg er bedst at til kode i forhold til db optimering. Indtil videre går det lynhurtigt med 20 brugere og 30000 kundeemner. public2, vil du også mene jeg skal droppe den metode jeg har beskrevet i første indlæg ? kommer søgningen med den metode til at være for langsom når der er 500.000 kundeemner ?
Jeg vil nu sige, at jeg ikke har arbejdet 5 års fuldtid med databaser, men jeg bruger og har brugt denormalisering ganske fornuftigt og alt efter opgaven, også ganske ofte til at optimere min performance.
Jeg arbejder med databaser i kraft af mit studie, men går ikke ud fra at det er hvad du tænker på. Men selvfølgelig er der altid plads til at blive bedre og gøre det bedre.
Hvis man skal lave 1000 tabeller så vil der måske være: - 800 tabeller uden performance problemer - 190 tabeller hvor man skal optimere index for at få passende performance - 9 tabeller hvor man skal bruge et materialized view for at få passende performance - 1 tabel hvor man skal denormalisere for at få passende performance
Og det ene tilfælde vil altid være denormalisering på M siden og ikke som i dette tilfælde her på 1 siden.
På 1 siden giver det en liste af værdier i en kolonne og det vil ikke forbedre performance men derimod totalt dræbe performance.
Jeg prøvede at lave en lille test med 10000 korte række med 10 rækker i en anden tabel tilknytet versus 10000 lidt længere rækker og søge på de id'er som er PK versus konkataneteret. Java og MySQL.
Den normaliserede udgave var næsten 300 gange (ikke 300% men 300 gange) hurtigere.
okay, så vidt jeg forstår, så er denormalisering det jeg har gang i. Det er simpelthen nemmere for mig at kode. Men jeg forstår godt for- og bagdelene nu. Læg et svar.
Hvis det du har gang i er flere værdier kommasepareret i samme felt, så er der ingen fordele!
:-)
Og et svar fra mig.
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.