mboost-dp1
mysql optimering!
Ok, folk fra eksperten var sgu ikke til meget hjælp i denne ;)
Jeg står med en database med en relationstabel.
Nu er spørgsmålet bare hvordan den optimeres bedst muligt, eller om mit problem overhovedet har nogen relevans.
Der er to ID'er: grpID og usrID. De bindes sammen med nogle tilladelser: p1, p2, p4...
hvad giver bedst perfomance:
at lave en kolonne til hver tilladelse, eller at samle alle tilladelser i 1 kolonne (og så anvende bitshifting)
Det skal siges at jeg ikke kommer til at lave søgning på selve tilladelserne, så det er først efter at settet er trukket ud, de skal anvendes.
Jeg står med en database med en relationstabel.
Nu er spørgsmålet bare hvordan den optimeres bedst muligt, eller om mit problem overhovedet har nogen relevans.
Der er to ID'er: grpID og usrID. De bindes sammen med nogle tilladelser: p1, p2, p4...
hvad giver bedst perfomance:
at lave en kolonne til hver tilladelse, eller at samle alle tilladelser i 1 kolonne (og så anvende bitshifting)
Det skal siges at jeg ikke kommer til at lave søgning på selve tilladelserne, så det er først efter at settet er trukket ud, de skal anvendes.
Konstruer dine queries, og smid dem igennem med MySQL med kommandoen EXPLAIN.
Fx. hvis du vil have forklaret hvordan "SELECT * FROM users" performer kan du køre kommandoen "EXPLAIN SELECT * FROM users". Du vil nu se hvordan MySQL bruger din data, hvilke joins den bruger, osv.
Fx. hvis du vil have forklaret hvordan "SELECT * FROM users" performer kan du køre kommandoen "EXPLAIN SELECT * FROM users". Du vil nu se hvordan MySQL bruger din data, hvilke joins den bruger, osv.
arne_v (4) skrev:#1
Hvis du kun laver select hvor du henter en enkelt brugers persmission, så er der næppe den store forskel på performance.
Den eneste løsning som duer udfra et software synspunkt er en ekstra tabel med en række per permission.
I tilfældet med en ekstra tabel, kan jeg ligeså godt bruge bitshifting, og have en enkelt kolonne ekstra.
tilfældet er, at jeg kommer til at have nogle udtræk, hvor jeg skal bruge den tabel til at relatere to andre tabeller til hinanden. Jeg selecter ikke nogle af permission colonnerne i relationsudtrækket, og tænker derfor at MySQL selv fjerner den data, hvorfor det egentligt kan være ligegyldigt.
arne_v (6) skrev:#5
Der er et begrænset antal bits i felter af tal typer.
INT er 4 bytes = 32 bits, (-1 for signed), men 31 pladser skulle stadig kunne gøre det :)
Jeg tror dog jeg laver en kolonne for hver tilladelse, også for at gøre debugginf lettere og gøre det mere overskueligt :)
buchi (7) skrev:INT er 4 bytes = 32 bits, (-1 for signed), men 31 pladser skulle stadig kunne gøre det :)
Design et system så det skal redesignes ved mere end 31-32 mulige permissions er ikke godt design.
buchi (7) skrev:Jeg tror dog jeg laver en kolonne for hver tilladelse, også for at gøre debugginf lettere og gøre det mere overskueligt :)
Men et design hvor enhver ændring af permissions kræver ændringer i tabel struktur er naturligvis værre.
Der kommer højst sandsynligt ikke flere permissions (hvis der gør, er det fordi jeg ikke har tænkt mig ordentligt om nu ;) )
hvad skal det sige? Det er en enkelt række der skal opdateres, hvis en tilladelse skal ændre:
| id1 | id2 | p1 | p2 | p3 | p4 | p5 | ...
arne_v (8) skrev:Men et design hvor enhver ændring af permissions kræver ændringer i tabel struktur er naturligvis værre.
hvad skal det sige? Det er en enkelt række der skal opdateres, hvis en tilladelse skal ændre:
| id1 | id2 | p1 | p2 | p3 | p4 | p5 | ...
buchi (9) skrev:
hvad skal det sige? Det er en enkelt række der skal opdateres, hvis en tilladelse skal ændre:
| id1 | id2 | p1 | p2 | p3 | p4 | p5 | ...
Det skal sige, at hvis du på et senere tidspunkt skal tilføje endnu en permission, så skal du ændre hele layoutet på tabellen. Hvilket fra et optimerings synspunkt samt designmæssigt synspunkt ikke er særlig smart.
Hvis du derimod bygger den op i stil med:
userid | permission
hvor du så indsætter et row per permission.
Så er det utrolig simpel at tilføje eller fjerne permissions senere hen, uden at skulle ænder tabel layoutet.
Og hvis du mener det er fordi du ikke har tænkt dig ordentlig om nu, hvis du senere skal bruge flere permissions. Så vil jeg opfodre til du ændre den holdning, det er umuligt at forberede et design til alle eventuelle fremtidige rettelser eller tilføjelser.
D_V (10) skrev:Og hvis du mener det er fordi du ikke har tænkt dig ordentlig om nu, hvis du senere skal bruge flere permissions. Så vil jeg opfodre til du ændre den holdning, det er umuligt at forberede et design til alle eventuelle fremtidige rettelser eller tilføjelser.
Hvornår har linux sidst ændret på deres layout for fil rettigheder? ;) Men det kræver jo selvfølgelig en insigt projektet, for at vide om det er relevant at tale om flere permissions.
Problemet er bare at vi taler mange rækker ;) og hvis jeg skulle lave endnu en tabel med en rettighed pr. række, vil den fylde 10 gange mere end min relationsdatabase gør det.
Det vil desuden tilføje et unødvendigt lag af komplexitet.
Jeg ville faktisk bare vide hvad der var mest optimalt, at samle 10 rettigheder i et felt (i en int værdi) eller splitte dem ud på 10 felter.
Daniel-Dane (12) skrev:Spørger du, om query af én række med efterfølgende bitshifting er hurtigere end query af ti rækker?
Nej, uanset hvad, så antager vi at jeg trækker en række ud. I eksempel 1, er der 3 felter i den række, og i eksempel 2 er der 12. ved eksempel 1 har jeg samlet de 10 tilladelser i 1 int værdi. I eksempel 2 er de delt ud på 10 boolean værdier.
Hvad er hurtigst?
apkat (13) skrev:De havde jo tydeligvis også tænkt sig ordenligt om. Hvilket du er i tvivl om du har.
Egentligt er jeg mest til at holde diskussionen i en ordentlig og saglig tone. Det er du åbenbart ikke glad for. Hvor mange iterationer tror du den tidlige UNIX model har været igennem før layoutet så ud som det gør?
buchi (9) skrev:Der kommer højst sandsynligt ikke flere permissions
Man designer ikke software efter den slags.
buchi (9) skrev:(hvis der gør, er det fordi jeg ikke har tænkt mig ordentligt om nu ;) )
Det er ikke realistisk at kunne forudsige fremtiden.
buchi (9) skrev:hvad skal det sige? Det er en enkelt række der skal opdateres, hvis en tilladelse skal ændre:
Ja, men der skal tilføjes en kolonne, hvis du skal tilføje en ny permission.
buchi (11) skrev:Hvornår har linux sidst ændret på deres layout for fil rettigheder?
Linux overtog et design fra Unix.
buchi (14) skrev:Hvor mange iterationer tror du den tidlige UNIX model har været igennem før layoutet så ud som det gør?
Ikke nok.
Da de jo ca. 1990 da Unix begyndte at bliver meget udbredt kommercielt kunn konstatere at det oprindelige design ikke var godt nok.
buchi (11) skrev:Problemet er bare at vi taler mange rækker ;) og hvis jeg skulle lave endnu en tabel med en rettighed pr. række, vil den fylde 10 gange mere end min relationsdatabase gør det.
Vil du poste hvor mange procent antal brugere x antal permissions x 8 bytes (2 int) udgør af din harddisk?
buchi (14) skrev:Egentligt er jeg mest til at holde diskussionen i en ordentlig og saglig tone. Det er du åbenbart ikke glad for. Hvor mange iterationer tror du den tidlige UNIX model har været igennem før layoutet så ud som det gør?
wat?! Du skriver selv:
buchi (9) skrev:Der kommer højst sandsynligt ikke flere permissions (hvis der gør, er det fordi jeg ikke har tænkt mig ordentligt om nu ;) )
Virker da dumt at lave noget der ikke kan ændres særligt let når du ikke selv er sikker på det er lavet ordenligt.
Indsæt selv "søde", "kære" osv. Jeg forstår ikke hvorfor du tager min kommentar så ilde op.
hmm...
scenarie 1:
det hele ryger i en tabel:
2 int for relation + 1 int for permissions. 12 byte pr relation (konstant)
scenarie 2:
2 int for relation + 1 for unikt id + 10 rækker af 2 int (en til relationsid og en til id for relationstabel). 12 byte + 80 byte = 92 byte (worst case)
hvis vi antager 100 000 rækker, vil det i 1 fylde 1 200 000 byte, eller 1,2 MB
i 2 vil det være 9,2 MB
Størrelsen af tabellerne er ikke problem, men hvad med søgetiden? Det betyder også en del? hvis der skal søges igennem 1 000 000 rækker (med index)
scenarie 1:
det hele ryger i en tabel:
2 int for relation + 1 int for permissions. 12 byte pr relation (konstant)
scenarie 2:
2 int for relation + 1 for unikt id + 10 rækker af 2 int (en til relationsid og en til id for relationstabel). 12 byte + 80 byte = 92 byte (worst case)
hvis vi antager 100 000 rækker, vil det i 1 fylde 1 200 000 byte, eller 1,2 MB
i 2 vil det være 9,2 MB
Størrelsen af tabellerne er ikke problem, men hvad med søgetiden? Det betyder også en del? hvis der skal søges igennem 1 000 000 rækker (med index)
#21
Prøv det dog af, der er tydeligvis ingen her der kender svaret. Og at lave en simpel benchmark vil da være mega simpelt.
Derudover vil jeg mene du ikke bør tænke for meget over perfomance for mysql i nogen af scenarierne, men mere resten af din applikation. Da den nok nærmere vil blive flaskehalsen.
Prøv det dog af, der er tydeligvis ingen her der kender svaret. Og at lave en simpel benchmark vil da være mega simpelt.
Derudover vil jeg mene du ikke bør tænke for meget over perfomance for mysql i nogen af scenarierne, men mere resten af din applikation. Da den nok nærmere vil blive flaskehalsen.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund