Hvor stort kan en MySQL database få før resultatene begynner å degradere

stemmer
258

På hvilket punkt gjør en MySQL database begynner å miste ytelsen?

  • Har fysisk database størrelse noen rolle?
  • Har antall poster noe?
  • Er noen forringelse av ytelsen lineær eller eksponentiell?

Jeg har det jeg mener er en stor database med omtrent 15M poster som tar opp nesten 2 GB. Basert på disse tallene, er det noe insentiv for meg å rengjøre data ut, eller er jeg trygt å la det fortsette skalering for noen år?

Publisert på 04/08/2008 klokken 14:31
kilden bruker
På andre språk...                            


13 svar

stemmer
175

Den fysiske database størrelse spiller ingen rolle. Antall poster ikke saken.

I min erfaring er det største problemet at du kommer til å kjøre på er ikke størrelsen, men antall spørsmål du kan håndtere på en gang. Mest sannsynlig at du er nødt til å flytte til en master / slave konfigurasjon slik at lese forespørsler kan kjøre mot slavene og skrive spørringer kjøres mot mesteren. Men hvis du ikke er klar for dette ennå, kan du alltids finpusse indeksene for de spørsmål du kjører for å øke hastigheten på responstid. Også er det en masse tweaking du kan gjøre for å nettverket stabelen og kjernen i Linux som vil hjelpe.

Jeg har hatt mine få opp til 10 GB, med bare et moderat antall tilkoblinger, og det håndterte forespørsler helt fint.

Jeg ville fokusere først på indekser, så har en server admin titt på OS, og hvis alle som ikke hjelper kan det være tid til å gjennomføre en master / slave konfigurasjon.

Svarte 04/08/2008 kl. 15:26
kilden bruker

stemmer
73

Vanligvis er dette en veldig subtil sak og ikke trivielt hodet. Jeg oppfordrer deg til å lese mysqlperformanceblog.com og High Performance MySQL . Jeg tror det er noe generelt svar på dette.

Jeg jobber med et prosjekt som har en MySQL database med nesten 1 TB med data. Den viktigste skalerbarhet faktoren er RAM. Dersom indeksene til dine tabeller passe inn i minnet og dine spørsmål er svært optimalisert, kan du tjene en rimelig mengde forespørsler med en gjennomsnittlig maskin.

Antall poster gjør saken, avhengig av hvordan tabellene ser ut. Det er en forskjell å ha mye VARCHAR felter eller bare et par ints eller lengter.

Den fysiske størrelsen på databasen saker også: tenke på backup, for eksempel. Avhengig av motoren din, dine fysiske db filer på vokse, men ikke krympe, for eksempel med InnoDB. Så sletter en rekke rader, hjelper ikke å krympe fysiske filer.

Det er mye å dette problemer og som i mange tilfeller djevelen er i detaljene.

Svarte 04/08/2008 kl. 18:44
kilden bruker

stemmer
34

Databasen størrelse spiller ingen rolle . Hvis du har mer enn ett bord med mer enn en million plater, så ytelsen begynner faktisk å bli dårligere. Antall poster gjør selvfølgelig påvirke ytelsen: MySQL kan være treg med store tabeller . Hvis du treffer en million plater vil du få ytelsesproblemer hvis indeksene ikke er satt riktig (for eksempel ingen indekser for felt i "der uttalelser" eller "PÅ forhold" i tiltrer). Hvis du treffer 10 millioner plater, vil du begynne å få ytelsesproblemer selv om du har alle indeksene rett. Maskinvareoppgraderinger - legge til mer minne og mer prosessorkraft, spesielt minne - ofte bidra til å redusere de alvorlige problemene ved å øke ytelsen igjen, i hvert fall til en viss grad. For eksempel 37 signaler som gikk fra 32 GB RAM 128 GB RAM for Camp databasetjeneren.

Svarte 26/01/2012 kl. 10:33
kilden bruker

stemmer
21

Jeg ville fokusere først på indekser, enn har en server admin titt på OS, og hvis alle som ikke hjelper kan det være tid for en master / slave konfigurasjon.

Det er sant. En annen ting som vanligvis fungerer er å bare redusere mengden av data som er gjentatte ganger jobbet med. Hvis du har "gamle data" og "nye data" og 99% av dine spørsmål arbeide med nye data, bare flytte alle de gamle dataene til en annen tabell - og ikke se på det;)

-> Ta en titt på partisjonering .

Svarte 11/08/2008 kl. 19:19
kilden bruker

stemmer
19

2GB og ca 15M poster er en veldig liten database - Jeg har kjørt mye større de på en Pentium III og alt har fortsatt kjøre ganske fort .. Hvis din er treg det er en database / program design problem, ikke en mysql (!) en.

Svarte 05/08/2010 kl. 09:03
kilden bruker

stemmer
16

Det er litt meningsløst å snakke om "database performance", "søket performance" er et bedre begrep her. Og svaret er: det avhenger av spørring, data som den opererer på, indekser, hardware, etc. Du kan få en idé om hvor mange rader skal skannes og hva indeksene skal brukes med FORKLARE syntaks.

2GB teller egentlig ikke som en "stor" database - det er mer en middels størrelse.

Svarte 06/08/2008 kl. 19:53
kilden bruker

stemmer
9

Et punkt å vurdere er også hensikten med systemet og dataene i dag til dag.

For eksempel, for et system med GPS-overvåking av biler er ikke relevant søk data fra posisjonene til bilen i tidligere måneder.

Derfor dataene kan overføres til andre historiske tabeller for mulig konsultasjon og redusere gjennomførings tider av daglige spørringer.

Svarte 06/12/2012 kl. 05:13
kilden bruker

stemmer
9

Jeg ble en gang bedt om å se på en mysql som hadde "sluttet å virke". Jeg oppdaget at DB filene ble bosatt på Network Appliance filer montert med NFS2 og med en maksimal filstørrelse på 2 GB. Og ganske riktig, bordet som hadde sluttet å godta transaksjoner var akkurat 2 GB på disken. Men med hensyn til ytelse kurve jeg fortalt at det var å jobbe som en mester helt til det ikke fungerte i det hele tatt! Denne erfaringen serverer alltid for meg som en fin påminnelse om at det alltid er dimensjoner over og under den du naturligvis mistenker.

Svarte 06/08/2008 kl. 04:27
kilden bruker

stemmer
9

Også se opp for komplekse tiltrer. Transaksjons kompleksitet kan være en stor faktor i tillegg til transaksjonsvolum.

Ommøblerer tunge spørsmål tilbyr noen ganger en stor ytelsesforbedring.

Svarte 04/08/2008 kl. 19:01
kilden bruker

stemmer
6

Jeg er for tiden administrerende en MySQL database på Amazons cloud infrastruktur som har vokst til 160 GB. Spørringsytelsen er fine. Hva har blitt et mareritt er sikkerhetskopiering, gjenoppretting, og legger slaver, eller noe annet som omhandler hele datasettet, eller DDL på store bord. Å få en ren import av en dump filen har blitt problematisk. For å gjøre prosessen stabil nok til å automatisere, ulike valg måtte gjøres for å prioritere stabilitet over ytelsen. Hvis vi noen gang har hatt for å gjenopprette fra en katastrofe ved hjelp av en SQL backup, ville vi være nede i flere dager.

Horisontalt skalering SQL er også ganske smertefullt, og i de fleste tilfeller fører til å bruke det på måter du sannsynligvis ikke har tenkt når du valgte å sette dataene i SQL i første omgang. Skår, lese slaver, multi-mester, et al, de er alle virkelig shitty løsninger som legger kompleksitet til alt du gjør med DB, og ikke en av dem løser problemet; bare reduserer det på noen måter. Jeg vil sterkt foreslå å se på å flytte noen av dine data ut av MySQL (eller egentlig noen SQL) når du begynner å nærme seg et datasett av en slik størrelse at disse typer ting bli et problem.

Svarte 30/06/2017 kl. 16:25
kilden bruker

stemmer
4

Ytelse kan brytes ned i løpet av noen få tusen rader hvis databasen ikke er konstruert riktig.

Hvis du har riktig indekser, bruke riktig motorer (ikke bruk MyISAM der flere DMLs forventes), bruk partisjonering, allokere riktige minne avhengig av bruk og selvfølgelig har god server konfigurasjon, MySQL kan håndtere data selv i terabyte!

Det er alltid måter å forbedre databasen ytelse.

Svarte 19/09/2013 kl. 11:26
kilden bruker

stemmer
3

Det avhenger av søket og validering.

For eksempel, i arbeidet med en tabell over 100 000 midler som har en kolonnegenerisk navn hvor den har mer enn 15 tegn for hvert stoff i denne tabellen .Jeg sette en spørring for å sammenligne med det generiske navn stoffer mellom to tabeller.Hotellet spørring tar flere minutter å kjøre.Personalet Same, hvis du sammenligner narkotika bruker stoffet indeksen, ved hjelp av en id-kolonne (som sagt ovenfor), det tar bare noen sekunder.

Svarte 29/11/2016 kl. 12:05
kilden bruker

stemmer
2

Database Størrelsen betyr noe når det gjelder bytes og tabellens rader nummer. Du vil merke en stor ytelse forskjell mellom en lys database og en blob fylt ett. Når søknaden min ble sittende fast fordi jeg satt binære bilder inne felt i stedet for å holde bildene i filer på disken og setter bare filnavn i databasen. Itera et stort antall rader på den annen side er ikke gratis.

Svarte 05/06/2017 kl. 10:27
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more