02. juni 2003 - 18:59Der er
14 kommentarer og 3 løsninger
optimal opbygning af stor mysql database
Hej eksperter
Jeg står med et problem jeg gerne skulle have løst i går ;-)
Her kommer så de spørgsmålet
Hvad er at fortrække til en database der skal indeholde over 500 tusinde id nummerer(vare ), den skal indeholde information om ca 150 ting om hver varenummer, eks dato, udløbsdato, farve, men på samme tid skal der være plads til ca 200 noter om hver enkel ting, men for at det ikke skal være løgn skal der til hver note være ca 20 unikke informationer der knyttes til hver note, (( note ) hvem har skrevet den, hvornår, afd, ect ).
Jeg kan ikke rigtig se hvordan jeg laver denne database og på samme tid bibeholder en god søgetid.
Der er for mig at se 2 måder at gøre det på.
Enten kan jeg lave en database med eks 18 store tabeller hvor jeg feks sætter den information fra note i en tabel men dette giver problemer da jeg jo skal have plads til 500.000 vare i denne tabel med ca 200 noter til hver vare med ca 20 informationer tilknyttede hver note.
Jeg kan også lave en database med en tabel til hver vare, men så skal jeg også have enten 18 forskellige tabeller på hver vare, som så giver 18 * 500.000 = 9 mil, eller jeg kan fordele det over ca 18 databaser med de tabeller jeg så skal bruge der, men efter som det skal køre fra samme maskine og jeg jo gerne vil bibeholde fordelen ved at bruge den rette størrelse af key_buffer_size og andre cache parametre, men jeg ved ikke rigtig om mysql's styring af cache over flere databaser kan gøres og om det fungere godt på den måde, eller om jeg skal bruge enorme mængder ram, fordi mysql måske ikke kan køre flere databaser op og fordele cache over dem, dette ville jo heller ikke være så smart, for så får jeg på samme tid alt for store mængder ram der lige skal gennemløbes før harddisken bruges.
De steder der står 18 tabeller ect 18 databaser er ud fra et støn jeg har lavet med de ønsker jeg har til hvad der skal være i hver tabel/database da der er nogle data der bliver brugt alene men også skal være en del af andre udtræk fra databasen.
Hov jeg var lige ved at glemme noget, det er også sådan at der på samme til kan være alt fra ca 200 til 3000 bruger inde i systemet på samme tid,, det er der humlen er med søge tiden.
Hvilken form for database opbygning skal jeg bruge ???
Min erfaring er, at det optimale er at du laver nogle gode indexer på de felter, du skal slå op i. Jeg har lavet en database med i alt ca. 17 MB fordelt på ca. 1800 rækker. Søgetiden er på stort set ingenting. En dårligt normaliseret MySQL database behøver ikke at være langsom. Men det kan så være, den fylder meget. Og så tænk på begrænse det arbejde der skal gøres ved hvert opslag.
start med at finde en maskine med masse af ram og installer mysql4 fremfor 3.23.x . Det vil hjælpe rigtigt meget. Deres query cache er ret fantastisk.
Kig rigtigt nøje på dine tabller, hvor har du nogle "variable sized" felter, så er det bare om at få lagt dem ud i tabeller for sig - noget i stil med:
create table kommentar ( id unsigned integer not null, kmnt_id unsigned integer auto_increment, id_forfatter unsigned smallint, kmnt_tid datetime not null);
table kommentar_tekst ( kmnt_id unsigned integer, tekst text)
Kig også meget nøje på alle dine primær nøgler og fremmednøgler. Alle de steder, hvor du kan komme til at bruge tal-felter, som indexes, bør du gøre det (og specielt hvis der er mange rækker) - de er meget mere effektive end tekst-basrede typer.
Man kunne forestille sig en opdeling i to tabellser per varenummer, hvor den ene tabel indeholder alt det, der skal bruges ved en søgning efter et udvalg af poster og den anden indeholdt alle de supplerende oplysninger. Den anden ville man så slå op i for at få flere oplysninger om et bestemt emne.
Det er i øvrigt meget effektivt (hvor du opløser mange-til-mange relationer at lave combined index på begge nøgler - create index ix_table on vare2varegruper (vareid, varegruppeid)
Hvis du har flere fysiske harddiske i serveren, kan du i øvrigt med fordel lægge databaserne ud på de forskellige diske; så kan der ske flere paralelle læsninger og skrivninger.
Til dine brugeroplysninger kan du i øvrigt med fordel lave index på felterne login og password (måske også user_id) - dette vil kunne gøre, at når brugernavn og password skal checkes, behøver mysql kun at kigge i index'et - ikke tabellen - for at finde de oplysniger den skal bruge i query'en, der bruges ved login.
I forhold til valget mellem flere databaser eller flere tables i samme database, så skal du nok også tænke på det administrative vedligehold. Det er nemmere at lave backup, optimize og lignende, når der er flere databaser med mindre data.
At dømme fra dem måde du skriver om databaser og tabeller lyder det som om at du ikke er helt klar på hvordan man udnytter et RDBMS ordentligt. Jeg vil anbefale at du læser lidt om emnet før at du går igang (jeg kender kun nogle elativt omfattende bøger - f. eks. Elmasri og Navathees "Database Systems"). Det er indlysende at der kun skal være tre tabeller (muligvis med nogle hjælpe-tabeller som foreslået ovenfor) og kun een database.
Du skriver f. eks. at du er nervøs ved at have 500.000 poster i en enkelt tabel. Hvis du kører systemet på en maskine med en passende mængde lager (RAM og HD), samt har de rigtige indexes, bør det overhovedet ikke være noget problem.
Det er godt at du spørger om designet for en ting er sikker - der er intet værre end dårligt designede databaser.
Jeg foreslår at du laver et ER-diagram og poster et link her i dette spørgsmål, så vi har et bedre grundlag at diskutere på.
ang Elmasri bogen - nogen bedre sovepille har jeg aldrig fundet. Læg dig med den, og du går ud som et lys.... :-} Men den er udmærket, bare stå op og læs den.
tak for de svar der er kommet endtil nu, men jeg savner stadig et svar på hvordan man laver en tabel der kan indeholde 500.000 id nummer der hver især har 200 notes der igen for hver note har 20 unikke informationer, dette er nok det største problem jeg har lige nu,
Jeg ville hellere vælge at slå op i en tabel med 18 mio. informationer end i 18 tabeller på een gang. Netop af hensyn til søgetiden. Alt for mange store hjemmesider er omtrent 100 år om at finde det de skal. Når du slår op i tabellen, slår du jo ikke op i de 18 mio. informationer, men kun i et eller flere indexerede søgefelter, f.eks. varenummer eller navn. Og indexet betyder jo, at databasen på forhånd ved, omtrent hvor et bestemt opslag ligger. Indexet svarer til at have et index over bøgerne i et bibliotek. (Sal->hylde->nummer->titel->kapitel) Indexet består af en masse pegepinde i databasen, som betyder, at databasen eksempelvis ved, at varenummer xW334411 befinder sig mellem række 111450 og række 111499. Groft sagt. Hvis det altid er nogle bestemte søgekriterier du bruger for at finde en vare, kunne du også vælge at lave een tabel indeholdende netop de ting og een med resten. At lægge adm. oplysninger, user, psw i en tabel for sig som mahler foreslår, kan jeg helt tilslutte mig. Til gengæld har jeg ikke haft problemer med tekstbaserede indexer. Tværtimod. De er enormt effektive.
> Til gengæld har jeg ikke haft problemer med tekstbaserede > indexer. Tværtimod. De er enormt effektive.
Hmm... Jeg påstod ikke at tekst-baserede indexes ikke var effektive, bare at numeriske var langt mere effektive, når man kommer op på rigtigt mange rækker (over 1 million).
Alle de steder, hvor man har brug for at lave queries på tværs af flere tables, hvor et af dem indeholder millioner af rækker, vil du sandsynligvis kunne mærke en forskel.
> (id1 = profil-1 , n1 = note-1 )hvordan ville i så > sætte 20 unikke informationer til disse informationer ? > > og hvad med farten på eks 1 database med 18 mil > informationer kontra mod opslag i 18 databaser med 1 mil i hver
Hvile datatyper ligger i noterne?
Skal du altid bruge alle 18 informationer hver gang du laver en søgning eller kun en?
Så foreslår jeg at du tager et kig på hvad relationships er. Hele fundamentet for relationelle databaser er at den slags konstruktioner ikke bør være nødvendige. Ved du hvad et join er?
Måske du skal ud i at overveje om MySQL er det rette valg? MySQL kan være hurtig nok, men med f.eks. MSSQL får du jo den ekstra ydelse fra stored procedures.
toastmaster: her kunne du istedet sige note, user_id (2 attributer) udfald ville blive : altså - note 1 user_id 1 note 2 user_id 2 note 3 user_id 1 osv. og bibeholde den fornuftige måde at bygge op på. Jeg kan se du har lidt af samme ? som jeg måske endda samme. Når der bygges op som jeg skriver her - hvad så med indexering ? note1, 2 og 3 er ikke kendte men det er user_id derimod men den findes jo X antal gange (og skal netop findes). Og ja mahler du skriver det selv - hvad er hurtigst at søge EN database EN tabel igennem med 18 mil. rows eller gå til en tabel i en anden DB hvor der er 1 million tabeller med hverisær med den info som skal bruges (altså har du først hentet tabel så har du info du skal bruge).
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.
