Svar: MyISAM vs InnoDB

[Oracel]

Haha for en retardert tråd! Jeg lo :!: Jeg har aldri sett noen drite seg ut så råbra som du gjorde der, hotstian :!: Snakk om å trekke feil konklusjon etter å ha sammenlignet to forskjellige ting uten engang å vite hva du sammenligner! Haha herlig! :!:

[blackbrrd]

Kommentarer som den der Oracel synes jeg ikke hører hjemme på dette forumet.

 

Det er vel heller du som driter deg ut som ikke sier noe om hva han har gjort feil men kommer med en kommentar som for alt vi vet er tatt rett ut av luften.

[Oracel]

Andre før meg i tråden har vel allerede påpekt, gjentatt og understreket hvilke skivebommer som har blitt gjort, så jeg føler det er unødvendig å bidra ytterligere. I verste fall kan det føre til at hotstian føler seg nedfor, og det vil vi jo ikke.

 

Om du sitter igjen med en følelse av at utbruddet mitt var "tatt rett ut av luften", så kan jeg dessverre ikke hjelpe deg på noen annen måte enn å plukke opp en bok om innføring i databaser, og studere det opprinnelige innlegget til hotstian nok en gang.

 

Om det er noe som ikke hører hjemme på dette forumet her, så er det trådstarterens innlegg, som er horribelt villedende.

[blackbrrd]

Du har fortsatt ikke kommet med noe konstruktivt, så jeg ser fortsatt ikke hvorfor du poster i denne tråden.

[Oracel]

Du har fortsatt ikke kommet med noe konstruktivt, så jeg ser fortsatt ikke hvorfor du poster i denne tråden.

6055430[/snapback]

Jeg nekter å følge denne avsporingen videre, og lar meg ikke provosere av trollingen din.

 

noen som vet om det er mulig å konvertere en MyISAM tabell til InnoDB?

5906159[/snapback]

 

Du kan gjøre det slik: ALTER TABLE `tabellnavn` TYPE = innodb

Og samme vei tilbake: ALTER TABLE `tabellnavn` TYPE = myisam

Det påvirker ikke dataene dine. Om du har lagt inn fk's, så kan du få en feilmelding om du prøver å konvertere tilbake fra InnoDB til MyISAM.

[Deelay]

Og MyISAM "stoetter" ikke en gang fremmednoekler!

5907326[/snapback]

 

Jeg kan ikke mye om MyISAM ennå, men vi bruker det nå på skolen! Og det går fint med fremmednøkler der...

Endret 10. mai 2006 av Oxido

[abcd423417984]

Nå vet ikke jeg hva som har skjedd med MyISAM i de siste par årene, men jeg har opplevd flere ganger å _måtte_ velge InnoDB pga støtten for transactions. Transactions er _essensielt_ i mange sammenhenger for at databasen skal beholde integritet, og da hjelper det svært lite å slenge opp en såpass intetsigende test/konklusjon som dette.

 

Beklager, men dette holder ikke. Til enhvert kritisk bruk er nok InnoDB fremdeles best, men for all del: For en personlig hjemmeside så har du sikkert helt rett.

[Frank2004]

Beklager, men dette holder ikke. Til enhvert kritisk bruk er nok InnoDB fremdeles best, men for all del: For en personlig hjemmeside så har du sikkert helt rett.

6076298[/snapback]

Feil er jeg redd. For alt hvor sqlite ikke holder, så er Postgres best.

[abcd423417984]

Beklager, men dette holder ikke. Til enhvert kritisk bruk er nok InnoDB fremdeles best, men for all del: For en personlig hjemmeside så har du sikkert helt rett.

6076298[/snapback]

Feil er jeg redd. For alt hvor sqlite ikke holder, så er Postgres best.

6076818[/snapback]

 

Altså. Jeg snakker om MySQL, men for all del

[blackbrrd]

Jeg bruker postgres til diverse applikasjoner og kan anbefale den varmt.

 

Jeg har ingen erfaring med InnoDB og vil derfor ikke anbefale postgres istedetfor, men det er jo helt klart et alternativ.

 

Postgres finnes nå for windows (fra og med versjon 8) og kan svært enkelt innstalleres og testes for de nysgjerrige Det er faktisk så enkelt og kjappt at jeg tror at enhver person som kan innstallere et program i windows hadde klart det!

 

Å si at "postgres er best" ser jeg ikke poenget med i det hele tatt, ettersom de helt klart har forskjellige styrker. Iflg diverse halvgode tester og hear-say så takler postgres flere samtidige brukere som driver med en god blanding av insert/update/select mens mysql klarer seg på minimalt med hardware og gir god ytelse hvis du stort sett har selects.

 

Jeg vil påstå at både postgres og innodb er gode databaser, men innodb var ikke tilgjengelig når jeg trengte en gratis database og myisam var rett og slett ikke aktuellt.

Endret 10. mai 2006 av blackbrrd

[Ueland]

Det som er sikkert er at for 90% av alle sider på nettet i dag som bruker DB vil fint klare seg med MyISAM, evnt Postgree eller hva utviklerene der har valgt og bruke.

 

Det er jo tross alt først når vi snakker store nettsteder/bedrifter (hvor pengene og ligger) at transaksjoner og liknende blir mer viktig.

 

Noen spurde om konvertering fra MyISAM til InnoDB, det finnes ikke et verktøy for det per i dag. Løsningen er å dumpe databasen til en SQL fil, for så å lese denne inn i InnoDB databasen etterpå.

 

Er det noen som har noe informasjon om hvordan Postgree oppfører seg med tanke på tabellkrasj og linkende, spesielt hva som kan gjøres når krasjet har oppstått og hvor lenge det vil ta å løse opp i problemene?

 

Dette diskusjonsforumet kjører i dag MyISAM på alle tabellene, forruten en tabell som inneholder oversikt over sessions, denne kjøres som minnetabell (HEAP) for å unngå tregheter da tabellen oppdateres ved hver sidevisning. Dette kuttet spørringene mot tabellen ned fra 0.00(0)x til 0.0000X, noe som jo er en god del.

 

Desverre er ulempen til MyISAM den at når tabellen først krasjer så tar det tid å reparere den, spesielt når vi snakker tabeller i størrelsen 5GB plusspluss.

 

Jeg er og utvikler av forumprosjektet Vikingboard, og der har vi tatt råd fra brukere her om å kjøre alle databasekall i egne "drivere" slik at administratorene selv kan ta i bruk det databasesystemet som er best for deres løsning, ser at det er en grei måte å løse det på slik at flere vil kunne bryke systemet.

Endret 11. mai 2006 av Ueland

[blackbrrd]

Har brukt postgres i hovedystemet til en bedrift med 70 ansatte, og har brukt det i ca 4-5 år nå. Har enda ikke opplevd en kræsj av databasen som har ført til korrupte data.

 

(Noget amatørmessig ble serveren kjørt uten ups en god stund og gikk da ned pga strømbrudd en god del ganger, men firmaet hadde ikke 70 ansatte da, og som sagt, vi mistet aldri data pga det)

 

Har ingen tabeller med mer enn 5 millioner rader, og ikke så mange av dem heller. Den største tabellen tar vel med indekser ca 1,5GB.

 

Ville selv brukt hibernate (en object relation mapper, ORM) for å gjøre meg uavhengig av databasespesifike kall, desverre bruker ikke vårt system det enda, mest fordi det ikke fantes når vi startet prosjektet for 4-5 år siden og fordi jeg ikke var klar over det før nå. www.hibernate.org

 

Fordelen med hibernate er at der er alt ferdigskrevet, hvis man vil så kan man nesten slutte å tenke på at man jobber med en database og tenke at man jobber med objekter. Det finnes også level 2 cache systemer som gjør at man får hastigheten av en in-memory database som er optimalisert for det og kjører native i java. Minne begynner jo å bli rimelig billig så det begynner jo faktisk å bli et alternativ. (2x2gb minne for totalt 4200kr sier egentlig alt når en 1U dual socket server med 6 minneslotter koster 7000kr - det koster riktignok 10000 å få to dual core prosessorer i den, men det er detaljer!)

 

MyIsam er vel etter det jeg kjenner til den databasen som er mest utsatt for korrupte tabeller? Har ihvertfall ikke hørt noe særlig om det, hverken i postgres eller innodb. Det er en grunn til å bruke databaser med transaksjonsstøtte

 

Kikket litt på det nå, og hvis du f.eks tar backup 1 gang i døgnet og bruker wal (write ahead logging) så skal du ikke trenge å gjøre noe mer enn å restore database og kjøre et replay av WAL'n så er du klar igjen.

 

Tenker WAL også fikser et "problem" postgres har med ytelse og fsync, dvs flushing av data, med WAL så går det an å skru av forced fsync for høyere skriveytelse.

 

Angående hastighet og myisam i forhold til innodb, etter hva jeg husker av en test på anandtech.com så skalerer myisam ganske dårlig med flere prosessorer, husker ikke om det var på 2 eller 4 prosessorer innodb tok den igjen på ytelse. Tiden man bruker på å gjenopprette en korrupt database i forhold til prisen på et par ekstra prosessorer tenker jeg går i favør anskaffelse mer prosessorkraft.

Endret 12. mai 2006 av blackbrrd

[roac]

Noget amatørmessig ble serveren kjørt uten ups en god stund og gikk da ned pga strømbrudd en god del ganger, men firmaet hadde ikke 70 ansatte da, og som sagt, vi mistet aldri data pga det

6086367[/snapback]

Dette er vel et resultat av at datasen er ACID-compliant. Du mister da ikke data ved strømbrudd etc. Dersom du får diskcrash vil det uansett ta tid å bygge opp databasen på nytt, men dersom database og logg ligger på forskjellige disker vil du heller ikke her får datatap med en ACID-compliant database.

 

Det ueland påpeker med at det tar tid å reparere databasen har i mine øyne rett og slett med å gjøre at det er en sårbar (les: elendig) databaseløsning.

[DarkSlayer]

Godt at noen tar tak i mytene om at MySQL er så sinnsvakt bra.

 

Lager man en applikasjon der ingen skal ha skrivetilgang til samme data, så funker Isam bra. (Tenk avis, der en person legger inn data og 100 leser).

 

Har man scenario hvor man har et fåtall personer skal kunne redigere samme data, så funker Isam med låsing av tabeller helt greit. (tenk lagerstyringssystem for liten bedrift der flere kna gå inn og endre mengde på en bestemt vare.)

 

Begynner man med scenario der enten mange skal kunne endre samme data, eller at man har lange databasejobber (oppdatere HELE vareregisteret f.eks) - så bruk innodb hvis man på død og liv skal ha mysql.

 

Trenger man fremmednøkler så bruk innodb.

[blackbrrd]

Jeg hadde aldri brukt myisam i en database hvor dataene faktisk var viktige, hvis du har et system med få brukere så spiller ikke ytelsen noen rolle og du kan liksågodt bruke en database som er endel hakk mer robust.

[kaffenils]

Godt at noen tar tak i mytene om at MySQL er så sinnsvakt bra.

 

Støttes på det sterkeste. Jeg har nærmest blitt rullet i tjære og fjær når jeg har ymtet frempå at MySQL ikke er i nærheten av hva det er hypet opp til å være, og at det finnes mye bedre gratis alternativer, som f.eks. PostreSql.