MySQL ingen Oracle-konkurrent, eller?

[int20h]

EU gransker fortsatt Oracles kjøp av Sun pga. MySQL, men er de to databasene egentlig rivaler?

 

Les mer

[Anders Jensen]

MySQL er nok ingen direkte konkurrent til Oracle DB og med Oracle på eiersiden vil MySQL heller aldri bli det. Var det resonnementet virkelig så vanskelig?

 

Og hvor kult blir det å måtte skyte spurv med kanon hver gang du trenger en middels bra DB, bare fordi de billige alternativene har stagnert utviklingen? Da med den antagelsen at det skjer med MySQL når Oracle tar over.

[siDDis]

"verdens mest utbredte open-source database"

Feil det er SQLite som er verdas mest utbredte open-source database. Forøvrig er SQLite også ein meir teknisk avansert database som har skikkeleg ACID støtte som standard.

 

MySQL er filledatabase frå topp til tå, med standardinnstillingar som bare er optimalisert for hurtigheit og ikkje for dataintegritet.

 

Og stiller du SQLite opp mot MySQL for webbruk så har SQLite meir funksjonalitet enn MySQL. Støtte for transaksjoner, triggere og fulltekstsøk samtidig, samt at den er raskare og har standardstøtte for ACID aktivert.

 

Og trenger man noko meir avansert der SQLite ikkje strekker til så må jo PostgreSQL være eit soleklart valg. Kva skal man med MySQL? Vise at ein ikkje har tatt databasevalget seriøst?

Endret 8. september 2009 av siDDIs

[DanteUseless]

Sverger jeg ser samme duden skrive det samme hver gang mysql er nevnt

[DarkSlayer]

Sverger jeg ser samme duden skrive det samme hver gang mysql er nevnt

Enig med han jeg. MySQL er en møkkabase. Det største problemet slik jeg ser det er alle utviklere som ikke ser... eller riktigere sagt: ikke vil se begrensningene, og gjør alt de kan for å fortsette med faenskapet mens de lyver til seg selv og andre om at "pytt pytt - det problemet er ikke et problem".

[jonnor]

Problemet er ikke at utviklerne foretrekker MySQL, men at de skriver koden sin direkte for den databasen uten noen form for abstraksjonslag.

 

I tilfelle MySQL er det å bruke moderselskapets omsetning et særdeles dårlig mål på hvor viktig programvaren er for markedet. Den store majoritet av innstalsjoner bringer tross alt ikke fem flate øre i omsetning for MySQL AB. Derfor ser jeg ikke at det skal være et godt argument mot at Oracle ikke sikrer seg betydelige deler av markedet med dette oppkjøpet (og følgelig muligens bryter EU's konkurranselovgivning).

[DanteUseless]

Sverger jeg ser samme duden skrive det samme hver gang mysql er nevnt

Enig med han jeg. MySQL er en møkkabase. Det største problemet slik jeg ser det er alle utviklere som ikke ser... eller riktigere sagt: ikke vil se begrensningene, og gjør alt de kan for å fortsette med faenskapet mens de lyver til seg selv og andre om at "pytt pytt - det problemet er ikke et problem".

 

Joda, det er vel lov å mene det. Men måtte le at nok en gang klarte det å bli et lite utbrudd mot mysql, med mange gode forklaringer hvorfor det er så jævlig og nok av forslag til bedre databaser..

 

if ($artikkel =~ m/<my_fav_topic>/) { print $default_rant }

[deviant]

Jeg har lang erfaring med drift av databaseløsninger og synes MySQL gjør en solid jobb for en mengde oppgaver.

 

For øvrig er det ikke nødvendigvis utvikleren som bestemmer hvilken databaseplattform som skal benyttes. Ofte er det merkantile hensyn som er avgjørende og teknisk involverer man gjerne noen med spisskompetanse på databaser.

 

Hva oppkjøpet angår er alle nøkkelkomponenter i MySQL sluppet under en åpen lisens som gjør det mulig for andre å ta over utviklingen dersom Oracle stagnerer. Jeg ser for meg at dette alene vil gjøre at Oracle ikke nedprioriterer produktet.

 

I den grad MySQL benyttes til virksomhetskritiske applikasjoner eller integrerte løsninger er det også et stort inntjeningspotensiale for Oracle. Support på MySQL har alltid vært en kostbar affære og overstiger gjerne tilsvarende tjeneste fra Oracle.

 

Jeg er litt usikker på hvordan markedsandelen bør vurderes i dette tilfellet. Brukerne av MySQL Community Edition har på ingen måte blitt kjøpt opp dermed er det kanskje bare den betalende kundemassen som egentlig bør vurderes.

[siDDis]

Utviklinga i MySQL 5 har ikkje akkurat gått i eit veldig bra tempo...og enda så eksisterer 5-10 år gamle KRITISKE feil. Utviklinga med PostgreSQL går i overlegen tempo og antall feil er bare ein brøkdel samt andel alvorlege kjente feil finnes ikkje!

 

Og når du seier at har lang erfaring med drift og seier at MySQL gjer ein god jobb så trur eg deg nemleg ikkje. MyISAM forårsaker hyppig datatap, og InnoDB er så vanvittig treig at med ein gang det blir *litt* last så greier ikkje den å returnere spørjingane i det heile tatt.

[deviant]

Og når du seier at har lang erfaring med drift og seier at MySQL gjer ein god jobb så trur eg deg nemleg ikkje. MyISAM forårsaker hyppig datatap, og InnoDB er så vanvittig treig at med ein gang det blir *litt* last så greier ikkje den å returnere spørjingane i det heile tatt.

 

For noe tøys. Allerede i 2004 kjørte jeg omfattende webapplikasjoner med ekstreme ytelseskrav på MySQL, deriblant det som var landets største nettsammfunn på den tiden. Jeg er ikke overbevist om at vi på denne applikasjonen kunne levert samme ytelse med Oracle på samme maskinvare.

 

Flere av de største nettstedene i Norge kjører også i dag på MySQL, hvilket neppe hadde vært tilfelle dersom plattformen var plaget med slike omfattende problemer rundt ytelse og ikke minst datatap.

 

Dersom du sliter med dårlig ytelse på moderat last er det noe som ikke er riktig i din løsning. Det er en mengde mulige årsaker så jeg skal ikke spekulere for mye i det, men vanlige problemstillinger er unødvendig låsing som følge av dårlige spørringer, for lite IO eller feil tuning.

[blackbrrd]

Og når du seier at har lang erfaring med drift og seier at MySQL gjer ein god jobb så trur eg deg nemleg ikkje. MyISAM forårsaker hyppig datatap, og InnoDB er så vanvittig treig at med ein gang det blir *litt* last så greier ikkje den å returnere spørjingane i det heile tatt.

 

For noe tøys. Allerede i 2004 kjørte jeg omfattende webapplikasjoner med ekstreme ytelseskrav på MySQL, deriblant det som var landets største nettsammfunn på den tiden. Jeg er ikke overbevist om at vi på denne applikasjonen kunne levert samme ytelse med Oracle på samme maskinvare.

 

Brukte du MyISAM eller InnoDB?

[deviant]

Brukte du MyISAM eller InnoDB?

 

På akkurat denne applikasjonen ble MyISAM forsøkt initielt men ble raskt byttet ut med InnoDB fordi buffer cache og row level locking gav stor gevinst.

[siDDis]

For noe tøys. Allerede i 2004 kjørte jeg omfattende webapplikasjoner med ekstreme ytelseskrav på MySQL, deriblant det som var landets største nettsammfunn på den tiden. Jeg er ikke overbevist om at vi på denne applikasjonen kunne levert samme ytelse med Oracle på samme maskinvare.

 

Flere av de største nettstedene i Norge kjører også i dag på MySQL, hvilket neppe hadde vært tilfelle dersom plattformen var plaget med slike omfattende problemer rundt ytelse og ikke minst datatap.

 

Dersom du sliter med dårlig ytelse på moderat last er det noe som ikke er riktig i din løsning. Det er en mengde mulige årsaker så jeg skal ikke spekulere for mye i det, men vanlige problemstillinger er unødvendig låsing som følge av dårlige spørringer, for lite IO eller feil tuning.

 

Verdas største nettsamfunn Facebook har bytta ut store deler av MySQL klusteret sitt med ein lausning frå Oracle. Og for å ta eit anna eksempel ca 1 år tilbake så hadde Facebook eit MySQL kluster på nesten 2000 servere, i motsetning så hadde nettsamfunnet myyearbook.com (som har 1/10 av antall brukere som Facebook) bare 17 PostgreSQL servere kjørande.

 

Eg har prøvd fleire antall oppsett av MySQL, Oracle og PostgreSQL og tuna dei alle så mykje som det går an. Oracle og PostgreSQL takler fint heftig trafkk. MySQL dør og slutter å svare heilt. Så lenge skriveytelsen er moderat og du bruker enkle spørringer så "fungerer" MySQL. Men det einaste alternativet er InnoDB og når du har aktivert dei 4-5 tingene for å få skikkeleg ACID så er den jo omtrent like treig som ein Access database....

[deviant]

Verdas største nettsamfunn Facebook har bytta ut store deler av MySQL klusteret sitt med ein lausning frå Oracle. Og for å ta eit anna eksempel ca 1 år tilbake så hadde Facebook eit MySQL kluster på nesten 2000 servere, i motsetning så hadde nettsamfunnet myyearbook.com (som har 1/10 av antall brukere som Facebook) bare 17 PostgreSQL servere kjørande.

 

Det er neppe noen her som har erfaring med løsninger med flere millioner samtidige brukere så det blir litt poengløst å ta diskusjonen på et slikt nivå. Jeg snakker kun ut fra egne erfaringer som strekker seg til norske bedrifter og nettsteder.

 

Eg har prøvd fleire antall oppsett av MySQL, Oracle og PostgreSQL og tuna dei alle så mykje som det går an. Oracle og PostgreSQL takler fint heftig trafkk. MySQL dør og slutter å svare heilt.

 

Dersom motoren slutter helt å svare kan det tyde på at ting ikke er riktig tunet i forhold til den maskinvaren du kjører på. Det er vanligvis ønskelig at motoren ikke aksepterer mer last enn den faktisk klarer å håndtere.

 

Utover det er det vanskelig for meg å si noe om akkurat din løsning og hvorfor du ikke opplever forventet ytelse.

 

Så lenge skriveytelsen er moderat og du bruker enkle spørringer så "fungerer" MySQL. Men det einaste alternativet er InnoDB og når du har aktivert dei 4-5 tingene for å få skikkeleg ACID så er den jo omtrent like treig som ein Access database....

 

Personlig anbefaler jeg ikke MySQL til løsninger hvor det er behov for hverken fullt transaksjonsskille eller prosedyrespråk, men så er dette heller ikke typiske behov i løsninger hvor MySQL benyttes.

 

PostgreSQL har jeg svært liten erfaring med, av den enkle grunn at ingen har tilbudt meg penger for å jobbe med denne plattformen - Likevel tør jeg mene at en løsning ikke blir automatisk blir dårlig fordi om det finnes gode alternativer.

[siDDis]

Det er neppe noen her som har erfaring med løsninger med flere millioner samtidige brukere så det blir litt poengløst å ta diskusjonen på et slikt nivå. Jeg snakker kun ut fra egne erfaringer som strekker seg til norske bedrifter og nettsteder.

 

Dersom motoren slutter helt å svare kan det tyde på at ting ikke er riktig tunet i forhold til den maskinvaren du kjører på. Det er vanligvis ønskelig at motoren ikke aksepterer mer last enn den faktisk klarer å håndtere.

 

Utover det er det vanskelig for meg å si noe om akkurat din løsning og hvorfor du ikke opplever forventet ytelse.

Og det er stort sett min erfaring og, til nettsteder så har MySQL ingen problemer så lenge innhaldet kan caches. Men MySQL sliter mykje me litt større spørringer som krever eindel joins og som ikkje skal caches. Har ein mange samtidige brukerar så dør den bare ved litt stor last. Det har ingenting med optimalisering av spørring eller hardware å gjere, det har rett og slett med query planneren til MySQL som surrer det skikkeleg til.

 

Same oppsett og spørring håndterer PostgreSQL og Oracle på sekundet.

Nå skal det også sies at SMP patchen frå Google og den nyaste InnoDB hjelper på MySQL om du kompilerer den frå kjeldekode med dei modulane, det går framleis treigt men den dør ikkje ut.

 

Personlig anbefaler jeg ikke MySQL til løsninger hvor det er behov for hverken fullt transaksjonsskille eller prosedyrespråk, men så er dette heller ikke typiske behov i løsninger hvor MySQL benyttes.

 

PostgreSQL har jeg svært liten erfaring med, av den enkle grunn at ingen har tilbudt meg penger for å jobbe med denne plattformen - Likevel tør jeg mene at en løsning ikke blir automatisk blir dårlig fordi om det finnes gode alternativer.

 

Eg anbefaler aldri ein database som ikkje tar i bruk transaksjoner, det trengs alltid fordi ingen vil miste data. Sjølv for eit lite nettsted som trenger nyheiter så skal det håndere versjonering, logger, rettigheiter osv. Og då er ein fort innom fleire tabeller når ein oppretter ein nyheit. Sjølv om det er lite skrive aktivitet så er faren der...

[deviant]

Men MySQL sliter mykje me litt større spørringer som krever eindel joins og som ikkje skal caches. Har ein mange samtidige brukerar så dør den bare ved litt stor last.

 

Et typisk scenario i min community løsning var meldingsboks. Brukerinformasjon fra 3 tabeller med 500.000 rader joines med meldingstabellen som har 25.000.000 rader. I test leverte en mellomstor server med MySQL 4 over 10.000 slike spørringer i sekundet med responstid under 10 ms.

 

En stor problemstilling i dette scenarioet er at MySQL 4 kun bruker èn indeks og ikke støtter nøstede spørringer - noe man må ta hensyn til når spørringen utformes.

 

Kombinert med ca 15% skriv (nye meldinger samt statusendringer) kom jeg den gangen til at den aktuelle serveren kunne håndtere meldingene til 50.000 samtidige brukere. Mer enn dobbelt av peak på norges største nettsamfunn.

 

Dette regner jeg som god ytelse.

[blackbrrd]

4 tabeller i en spørring er ikke det jeg ville kalle kompleks.

[deviant]

4 tabeller i en spørring er ikke det jeg ville kalle kompleks.

 

Sant nok, men vi snakker vel om løsninger for publisering, nettsamfunn, diskusjonsforum, handlekurv osv - ikke CRM og BI.

 

Escenic, som antagelig er den viktigste publiseringsplattformen her i landet, bruker heller ikke særlig mye spørringer med mer enn 4-5 tabeller på leveransesiden. Selv har jeg kun kjørt Escenic på Oracle, men MySQL 5 er nå anbefalt plattform og skal etter sigende ha god ytelse.

[siDDis]

4 tabeller i en spørring er ikke det jeg ville kalle kompleks.

 

Sant nok, men vi snakker vel om løsninger for publisering, nettsamfunn, diskusjonsforum, handlekurv osv - ikke CRM og BI.

 

Escenic, som antagelig er den viktigste publiseringsplattformen her i landet, bruker heller ikke særlig mye spørringer med mer enn 4-5 tabeller på leveransesiden. Selv har jeg kun kjørt Escenic på Oracle, men MySQL 5 er nå anbefalt plattform og skal etter sigende ha god ytelse.

 

En kan gjere mykje med bare 4-10 joins, men skal ein vise litt statistikk av for eksempel aktivitet i løpet av dei siste 10 minutta, med informasjon om kven, kva, kvar, tilstand, tid og med snittverdier så får ein fort ein komplisert spørring sjølv på eit vanleg nettsted. Spesielt når dataen ikkje skal caches.

 

Og skriveytelse utan transaksjoner eller fsync() skalere nå langt betre på filnivå enn i ein database. Det er jo ein grunn til at f.eks Apache greier å logge kvar einaste request utan at skriveytelsen skulle bli ein flaskehals på eit nettsted.

[deviant]

En kan gjere mykje med bare 4-10 joins, men skal ein vise litt statistikk av for eksempel aktivitet i løpet av dei siste 10 minutta, med informasjon om kven, kva, kvar, tilstand, tid og med snittverdier så får ein fort ein komplisert spørring sjølv på eit vanleg nettsted. Spesielt når dataen ikkje skal caches.

 

Dette passer det vel greit å cache uansett? Burde holde med en oppdatering i minuttet?

 

Tenkte å sjekke på blink og nettby, men blink har visst ikke noe statistikk og nettby er nede..

 

Litt artig cache på blink forresten. Vekslet mellom gammel og ny forside på hver refresh i et par minutter.

 

Og skriveytelse utan transaksjoner eller fsync() skalere nå langt betre på filnivå enn i ein database. Det er jo ein grunn til at f.eks Apache greier å logge kvar einaste request utan at skriveytelsen skulle bli ein flaskehals på eit nettsted.

 

Men så var det vel ikke akkurat ytelse som var grunnen til at vi beveget oss bort fra flate filer, eller hva?

Endret 11. september 2009 av deviant