MySQL: MyISAM vs InnoDB

[CofidiS]

Hei!

 

Har en database med ca 1,5 millioner entries som jeg trenger å kjøre omtrent like mange spørringer mot på kortest mulig tid.. Spørsmålet et da, bør databasen da være MyISAM eller InnoDB? Fordeler og ulemper med InnoDB vs MyISAM ?

[roac]

Har en database med ca 1,5 millioner entries som jeg trenger å kjøre omtrent like mange spørringer mot på kortest mulig tid.. Spørsmålet et da, bør databasen da være MyISAM eller InnoDB? Fordeler og ulemper med InnoDB vs MyISAM ?

7585425[/snapback]

Hvis du ikke trenger f eks referanseintegritet og tenker på ren ytelse ved uthenting vil MyISAM være det klart beste alternativet.

[Frank2004]

Hei!

 

Har en database med ca 1,5 millioner entries som jeg trenger å kjøre omtrent like mange spørringer mot på kortest mulig tid..

Hvordan ser datasettet og spørringene dine ut?

 

Det er som regel mange faktorer som er viktigere enn hvilken db-motor du bruker, bla.a. caching og indeksering. Også viktig at du prøver å tenke i sett-operasjoner når du skriver sql, det er sjelden effektivt å jobbe med en og en rad.

[DarkSlayer]

MyISAM er veldig bra til å gjøre gjøre enkle oppgaver som select, insert og update. Men den har ingen relasjoner, og dårlig på låsing. Det betyr at databasen kan bli veldig treig når flere tråder skal oppdatere rundt omkring.

 

Skal du ha flere tråder som går å oppdaterer poster så bruk innodb.

Innodb er også bra på å gjøre store oppgaver (la oss si at 1mill poster skal oppdateres, spesielt når det foregår andre oppdateringer i tabellen).

 

Jeg vil egentlig si at man bør bruke InnoDB som standard, med mindre man har en god grunn til å la vær. Dette fordi det er en bedre motor generellt sett. Og ut fra dette lite informative spørsmålet så sier jeg InnoDB, dette fordi du snakker om å gjøre masse spørringer.

 

Men om det er en webside, og du skal gjøre tonnevis av enkle select ... og låsing ikke er noe issue, så kan nok MyIsam funke.

 

*låsing har med teknikker for å hindre at 2 tråder oppdaterer samme post, og føkker for hverandre.

[Ueland]

select, insert og update

"Langt ifra".

 

MyISAM er bra når det er _mye_ SELECTs, slik som det er på typiske webapplikasjoner.(~70%++) Med en gang du skal gjøre mye endringer på tabellens innhold med UPDATE/INSERT låses tabellen for lesing, og alt av cache dumpes ved hver endring. Kjører du da mange endringer på en tabell det leses mye av stopper dermed alt av lesing inntil oppdateringene er utført.

 

Så ved mange oppdateringer er MyISAM vinneren for den låser bare den aktuelle raden(e) som oppdateres slik at alt annet kan fortsette som normalt uansett.

Endret 9. januar 2007 av Ueland

[DarkSlayer]

eh ja seff ... rota litt der.

Myisam har kun tabellås. Må på innodb for å få rad lås.

Endret 9. januar 2007 av DarkSlayer

[kaffenils]

eh ja seff ... rota litt der.

Myisam har kun tabellås. Må på innodb for å få rad lås.

7679442[/snapback]

 

Og hvis en velger InnoDB så ser jeg ikke helt poenget med å bruke MySQL i det hele tatt. Da kan en like godt velge PostgreSQL som både har mer funksjonalitet og yter bedre enn MySQL og InnoDB.

[DarkSlayer]

Ja ... du er inne på noe.

 

Nå kjenner jeg ikke hvilke server muligheter trådstarter har, om han kan velge db så er det jo en god ide å sjekke ut flere varianter. Men det kan gjerne være at man kun har mulighet for MySQL.

 

Men uansett så er det ikke så lett å synse over dette føler jeg. Savner litt flere detaljer fra trådstarter på hvilke muligheter han har, hva slags applikasjon dette er, type program ... hva slags spørringer er det han ser for seg å bruke....

[Ueland]

Å skifte database system er heller ikke noe man "bare gjør" uten videre.

For å svare trådstarter: Bruk InnoDB tabeller, det bør være det raskeste for din del så lenge du ikke bruker fulltekstsindekser på tabellene, akkurat det fungerer kun på MyISAM.

[kaffenils]

Bruk InnoDB tabeller, det bør være det raskeste for din del så lenge du ikke bruker fulltekstsindekser på tabellene, akkurat det fungerer kun på MyISAM.

7683585[/snapback]

 

Bare for å "gni" det litt inn. Diskusjon.no bruker vel MySQL, og flere ganger til dagen henger hele forumet noe forferdelig. Jeg antar at dette skyldes at MySQL er forferdelig dårlig på å håndtere låsing.

 

Dere burde seriøst vurdere å bytte databasesystem...

[Ueland]

Vi bruker MySQL med heap og MyISAM tabeller og har ~0 problem med låsing av tabeller. Vi har heller ingenting som tilsier at det henger flere ganger til dagen så problemet ligger nok et annet sted

 

Dog er MySQL (og sikkert ~ca alle andre DB-systemer) glad i minne, noe som medfører at vi nå må skifte ut databaseserveren vår til en ny med mer minne igjen.

[kaffenils]

Vi bruker MySQL med heap og MyISAM tabeller og har ~0 problem med låsing av tabeller. Vi har heller ingenting som tilsier at det henger flere ganger til dagen så problemet ligger nok et annet sted

7699891[/snapback]

 

Godt mulig at problemet deres ligger en annen plass, men det er ikke hos meg. Grunnen til at jeg mistenker MySQL er at jeg opplever samme "hengingen" på andre forum som bruker samme forumsystem som dere. Derfor antar jeg at det er MySQL som er synderen.

 

Hvis du ikke tror meg så foreslår jeg at dere kjører et trace på alle spørringer for å se hvor lang tid de tar. Sorter på synkende eksekveringstid i slutten av hver dag, så er jeg meget sikker på at dere vil se at noen få spørringer bruker veeeldig lang tid.

[siDDis]

For råest mulig ytelse der 90% er select så er SQLite kongen. Den er og rask til å skrive data men når det kjem til mange updates osv så går det treigt då den låser *heile* databasefila.

 

Ikkje minst er det public domain så du ikkje trenger å kjøpe kommersiell lisens av MySQL eller følge GPL slavisk.

[roac]

Det største problemet med SQLite er at det ikke er en databasesever, all logikken ligger i applikasjonen. Så det blir helt galt å sammenligne SQLite med databaseservere. Skal du smamenligne med noe burde det være tilsvarende produkter, som f eks SQL Server Compact Edition. Har du testet de to opp mot hverandre?

[siDDis]

Eg vil nå kalle SQLite ein databaseserver, og i tillegg så er MySQL ein såpass lett database at ein fint kan samanlikne SQLite mot den. Og det er svært få ting SQLite gjer dårlegare enn MySQL, stort sett handler det om å plassere databasen på ein eigen ekstern maskin eller å tilpasse databasen for mange samtidige brukerar.

 

SQLite blir brukt til mange ting som er heilt usynleg for dei fleste. Blant anna i Mac OS X operativsystemet, Safari, Solaris, Firefox, Thunderbird, Trolltech's QT osv. Også er det ganske mogleg ditt nye digital TV bruker SQLite. Det er eit kjempeflott alternativ til ein liten/middelsstor webapplikasjon istadenfor å kjøre noko større og tungvindt som MySQL.

 

Når det gjelder SQL Server Compact Edition samanlikan mot SQLite så har eg ein mur eg ikkje greier å rive ned rett forann meg for å få samanlikna dei skikkeleg...

Basert på tidlegare erfaring så koster det sikkert penger, er ikkje open source eller basert på ein veldig fri lisens, bare tilgjengeleg på windows platformer, bloated med Microsoft sine eigne standarder for databaser, Microsoft standard for testing altså bugs er ofte features(Hadde nettopp forelesning med Hans Schaefer).

 

Så nei eg må først bli heilt skikkeleg overbevist over at SQL Server Compact Edition har faktisk fleksibilitet før eg prøver det.

[Ueland]

MySQL er ikke en database. MySQL er en applikasjon som bruker Databasemotorene MySQL, MyISAM, BerkelyDB o.l, SQLlite er heller ikke en databasetjener, det er en programsnutt som kan inkluderes i programvare

 

SQLite er sikkert fint for små systemer, men snakker man GB er MySQL, PostgreSQL osv fint.

 

Erfaringsmessig holder jeg meg til MySQL (dog har jeg startet å snuse på PostgreSQL).

 

 

 

kaffenils: Det som tar lengst tid hos oss er innlesing av lokal cache, desverre er forumløsningen vår bygget opp litt teit så det medfører en god del cachedata.

[endrebjo]

select, insert og update

"Langt ifra".

 

MyISAM er bra når det er _mye_ SELECTs, slik som det er på typiske webapplikasjoner.(~70%++) Med en gang du skal gjøre mye endringer på tabellens innhold med UPDATE/INSERT låses tabellen for lesing, og alt av cache dumpes ved hver endring. Kjører du da mange endringer på en tabell det leses mye av stopper dermed alt av lesing inntil oppdateringene er utført.

 

Så ved mange oppdateringer er MyISAM vinneren for den låser bare den aktuelle raden(e) som oppdateres slik at alt annet kan fortsette som normalt uansett.

7679276[/snapback]

Jeg håper du mener InnoDB i det siste avsnittet der. Ellers så er jeg mektig forvirret.

[Ueland]

MyISAM låser tabellen, mens InnoDB låser raden, selvsagt

[roac]

SQLite blir brukt til mange ting som er heilt usynleg for dei fleste. Blant anna i Mac OS X operativsystemet, Safari, Solaris, Firefox, Thunderbird, Trolltech's QT osv. Også er det ganske mogleg ditt nye digital TV bruker SQLite. Det er eit kjempeflott alternativ til ein liten/middelsstor webapplikasjon istadenfor å kjøre noko større og tungvindt som MySQL.

 

Når det gjelder SQL Server Compact Edition samanlikan mot SQLite så har eg ein mur eg ikkje greier å rive ned rett forann meg for å få samanlikna dei skikkeleg...

Basert på tidlegare erfaring så koster det sikkert penger, er ikkje open source eller basert på ein veldig fri lisens, bare tilgjengeleg på windows platformer, bloated med Microsoft sine eigne standarder for databaser, Microsoft standard for testing altså bugs er ofte features(Hadde nettopp forelesning med Hans Schaefer).

 

Så nei eg må først bli heilt skikkeleg overbevist over at SQL Server Compact Edition har faktisk fleksibilitet før eg prøver det.

7914631[/snapback]

Nå vet jeg ikke hva du sikter til som bruker SQLite i OSX og QT, men jeg tør vedde på at det er løsninger der det er en kobling mot databasen om gangen. Det er ikke snakk om å definere om SQLite er en server eller ikke, den lytter ikke på noen porter, og er ikke tilgjengelig utenfra. Det blir det samme som å kalle Access en databaseserver.

 

Basert på tidligere erfaring sjekker du heller ikke ting, da hadde du visst at SQL Server CE ikke kostet penger. Ellers skal det sies at SQL Server følger SQL-standardene veldig godt. Det er ikke perfekt, det er det ikke for noen databasemotor, men hvis jeg skulle tippe på at en var "best" ville jeg tippe IBM UDB (DB2).

 

Når det gjelder bugs så tror jeg du bør gå i andre retninger på databasesiden enn mot Microsoft. Det er flere rapporter som viser til at Oracle har langt svakere sikkerhet enn MSSQL. Så jeg har en mistanke om at du er noe forutinntatt.

 

For all del, misforstå meg rett. Jeg ønsker SQLite velkommen på databasemarkedet, den gjør blant annet en glimrende jobb i Adobe Lightroom (som dessverre forsatt er i beta), men jeg vil ikke kalle det en databaseservice eller databaseserver, men en databasemotor, og jeg mener bestemt at det er to forskjellige ting, og ikke minst at det har to vidt forskjellige bruksområder.

 

Edit: En rapport som i tillegg til Oracle og MSSQL også inneholder DB2, Sybase og MySQL.

Endret 10. februar 2007 av roac