Sun laat Mysql 'grote sprong voorwaarts' maken

Sun zal volgende week versie 5.1 van Mysql lanceren. In deze release zitten een aantal veelgevraagde features, die Mysql op een vergelijkbaar functieniveau als andere commerciële databases moet brengen.

Nieuw in versie 5.1 van Mysql zijn onder meer mogelijkheden voor het partitioneren, het plannen van database-events, replicatie met rijen als basis en clustering op basis van disks. De meeste van deze features zijn reeds standaard in de databasesoftware van Microsoft, IBM en Oracle. Verder is een groot aantal bugs uit versie 5.0 in deze Mysql-release opgelost, aldus Zack Urlocker, vice-president van de Mysql-productafdeling bij Sun. Daarnaast is de performance met gemiddeld twintig procent verbeterd en is er gewerkt aan het schaalbaarder maken van de databasesoftware.

Sun, dat sinds begin dit jaar eigenaar is van Mysql, zal de nieuwe versie van de software komende week tijdens een conferentie aan het grote publiek voorstellen. Naast het bespreken van Mysql 5.1 zal er gesproken worden over een bijgewerkte roadmap voor Mysql, aangezien Sun daar sinds de overname nog weinig over heeft laten weten. Ook zullen de verdere gevolgen van de overname door Sun de revue passeren.

Verder zal er gesproken worden over de vraag welke database-engine de basis moet vormen voor transactionele functionaliteit. Op dit moment wordt er vooral gebruikgemaakt van Innodb, maar die engine is sinds enkele jaren eigendom van Oracle. Mysql werkt al geruime tijd aan de alternatieve Falcon-engine en er wordt door een voormalige Mysql-ontwikkelaar aan de Maria-engine gebouwd. De bouwers van zowel de Falcon- als de Maria-engine willen hun product de standaard Mysql-engine laten worden.

Reacties (54)

[Parasietje]

Ik begrijp niet goed waarom elk serieus bedrijf van MySQL gebruik maakt. Wat is er precies mis met concurrent PostgreSQL, die beter standaarden volgt en meer features heeft in hun database-model?

[ACM]

In het verleden was PostgreSQL langzamer en in een heel vroeg verleden zelfs minder stabiel. Daarnaast is PostgreSQL altijd wat lastiger in het gebruik en installatie geweest (vacuum en analyze anyone?).

Als je dan eenmaal met MySQL begonnen bent is het ook weer niet triviaal om over te stappen op PostgreSQL, zeker als die de simpele queries die gebruikt worden ook niet of nauwelijks sneller uitvoert. Als je PostgreSQL als drop-in replacement voor MySQL bekijkt, dan zal de performance iig weinig beter zijn. Pas als je queries gaat combineren of anderzins herschrijven, tabelstructuren bijwerkt en nieuwe indexen plaatst, komt de performance van PostgreSQL een stuk beter naar voren.

Wat dan natuurlijk vergeten wordt, is dat je in PostgreSQL dan standaard met transactionele tabellen werkt, waar MySQL-gebruikers nog vaak een mix van InnoDB en MyISAM hebben. En dat PostgreSQL ingevoerde data in queries wat beter controleert itt MySQL's standaard gedrag om alles stilletjes te negeren of aan te passen naar iets dat wel past.

[Olaf van der Spek]

En dat PostgreSQL ingevoerde data in queries wat beter controleert itt MySQL's standaard gedrag om alles stilletjes te negeren of aan te passen naar iets dat wel past.

Dat soort controles voer je toch uit in je app code?

[ACM]

Dat soort controles kan je uitvoeren in je applicatie inderdaad. Maar het is nogal suf als je database waarden op laat slaan die uberhaupt niet geldig zijn.
Een bekend voorbeeld is het op laten slaan van 31 februari in eerdere versies van MySQL. Een ander voorbeeld is dat MySQL in een string-int vergelijking de string evalueert naar 0. Dus als je "SELECT * FROM sometable WHERE somevarchar = 0" doet, krijg je alle records... Voor een database, wiens taak het is om die data veilig en correct op te slaan en op te zoeken, is dat natuurlijk wel cruciaal om goed te doen.

[SPee]

Sorry, maar het is toch echt aan de DBA/Programmeur om ervoor te zorgen dat hij Tekst niet als Getallen gaat gebruiken.
Dan doe je iets fout en kun/mag je de schuld niet op de Database schuiven.

Garbage in => Garbage out

[cariolive23]

En Garbage in kan je database dus gewoon weigeren, programmeurs en dba's (= mensen?) maken nu eenmaal fouten. Door de juiste datatypes en check-constraints in te stellen, verminder je het aantal fouten en de kans op fouten. Dus wordt bouwen, testen en debuggen goedkoper.

Configuratie van je database server is altijd nodig, denk alleen al aan het instellen van het geheugengebruiken, waar het geheugen voor wordt gebruikt, het aantal gelijktijdige users, etc. etc.

[Atmosphere]

Vanuit security oogpunt zelfs aan de client en aan de server kant

Voor serverperformance kist je voor client side controlle, echter alleen deze controlles geven een kwaadwillende dan de mogelijkheid willekeurige gegevens in je database te schrijven (namelijk buiten de applicatie om)

Serverside (bv. doormiddels van update/insert-triggers) controlle heeft vaak nadelig gevolgen voor de gehele performance maar je kan extra garanties creeeren over de correctheid van de gegevens

[Reactie gewijzigd door Atmosphere op 24 juli 2024 01:34]

[Tanuki]

Dat zit er nou eenmaal zo in.

In den beginne was MySQL een database die retesnel was (maar wel bepaalde features miste), iedereen vond het snel dus iedereen wou het gebruiken.

Terwijl PostgreSQL en verwanten ook snel waren (maar niet zo snel als MySQL, wat wil je, als je ook sub query's, transacties, stored procedures, etc. etc. moet ondersteunen), is er bij MySQL steeds meer toegevoegd. Nu in versie 5 ondersteunt MySQL ook bovenstaande features.

Nu biedt zo'n beetje elke hoster MySQL 5 (of zelfs 4... grrr) aan. PostgreSQL zal je vrijwel nergens tegenkomen, Oracle e.d. al helemaal niet.

MySQL pronkte in het begin gewoon met haar snelle database en heeft zo interesse gewekt -> iedereen wil MySQL -> alle hosters installeren MySQL -> geen interesse voor andere database servers.

[arjankoole]

en MySQL is nu eenmaal een stuk eenvoudiger te beheren dan PostgreSQL.

ik ken ze beide, en kan met beide lezen en schrijven, maar qua gemak van dingen doen, is MySQL echt veel beter.

[cariolive23]

Leg eens uit, ik ben erg nieuwsgierig. Ik heb namelijk een totaal andere ervaring, data in MySQL is per definitie onbetrouwbaar, 1x de verkeerde mode (of standaard mode) instellen en zeg maar dag met je handje naar de dataintegriteit. Ik zie niet in wat daar eenvoudig aan is.

Daarnaast kost debuggen van een systeem in MySQL veel meer tijd, een fatsoenlijke foutmeling op een foute query is vaak al teveel gevraagd...

[Olaf van der Spek]

Bepaalde subqueries worden in 5.0 en volgens mij ook 5.1 echter zo traag uitgevoerd dat het beter was geweest ze er gewoon uit te laten.

[killingdjef]

Als er dusdanige complexe queries nodig zijn dat je database het niet trekt, dan zou ik toch ook even kijken naar je database structuur. Normaliseren kost in het begin misschien veel denkwerk maar voorkomt in de meeste gevallen complexe, zware queries.

[Olaf van der Spek]

Als er dusdanige complexe queries nodig zijn dat je database het niet trekt,

Ik heb het niet over complexe queries. MySQL kan bepaalde simpele subqueries niet goed uitvoeren.

[killingdjef]

Zou je een voorbeeld kunnen geven van een query die niet goed wordt uitgevoerd?

[Olaf van der Spek]

Zie http://dev.mysql.com/doc/...ubquery-restrictions.html

Subquery optimization for IN is not as effective as for the = operator or for the IN(value_list) operator.

A typical case for poor IN subquery performance is when the subquery returns a small number of rows but the outer query returns a large number of rows to be compared to the subquery result.

The problem is that, for a statement that uses an IN subquery, the optimizer rewrites it as a correlated subquery. Consider the following statement that uses an uncorrelated subquery:

SELECT ... FROM t1 WHERE t1.a IN (SELECT b FROM t2);

The optimizer rewrites the statement to a correlated subquery:

SELECT ... FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.b = t1.a);

If the inner and outer queries return M and N rows, respectively, the execution time becomes on the order of O(M×N), rather than O(M+N) as it would be for an uncorrelated subquery.

An implication is that an IN subquery can be much slower than a query written using an IN(value_list) operator that lists the same values that the subquery would return.

[Verwijderd]

Een subquery is alles behalve complex en zwaar en een vrij normale situatie.
Als een database niet eens fatsoenlijk een subquery kan uitvoeren.. dan is het niet serieus te noemen.

subqueries hebben niks met je database structuur te maken maar met een bepaalde informatiebehoefte die haaks kán staan op een genomaliseerd model

[_JGC_]

Helaas zie ik mensen meteen teruggrijpen naar inefficiente subqueries terwijl ze ook gewoon een join kunnen gebruiken.

[gassiepaart]

als een ontwikkelaar nou eens leert dat een subquery een slechte en domme manier van ontwikkelen is....

[Verwijderd]

Zou geweldig nieuws zijn als MySQL ook op het niveau van Postgres komt. Moet wel zeggen dat er toch behoorlijk wat ondersteuning is voor postgres bij de webhosters.

[Crew One]

Als je een site hebt die goed, snel en stabiel draait op MySQL, (Wat heus niet elke site of applicatie zal doen, dat zal ik niet beweren...) ... waarom zou je dan moeite doen om over te stappen op PostgresSQL?

[Killemov]

Precies ... if it ain't broke ...

Maar goed, wat als je niet echt controle hebt over de applicatie, maar wel over de database? Postgres anytime.

[Verwijderd]

Ik hoop van harte dat de 20% snelheidsverbetering waar is. Wij hebben vele servers staan waarbij MySQL de bottleneck is. Stuk goedkoper om MySQL te upgraden dan snellere CPU of meer geheugen.

Hopelijk is de POSIX code voor de Windows versie ook aangepast. Tuurlijk is het gemakkelijk om de schuld bij Microsoft te leggen, omdat Windows niet 100% POSIX compatible is, maar dat lost het probleem niet op.

Wordt dus een drukke tijd voor de vele database managers en coders, want niet alleen zullen de meeste eerst een test setup uitproberen voordat de produktieserver wordt vernieuwd, tevens zullen de coders aan de slag kunnen. Met alle nieuwe ondersteuning is nog meer optimalisatie mogelijk.

Tijd om de trommels af te stoffen en de slagsweep met olie in te smeren

@Nestor, alles is geoptimaliseerd, maar met een average van meer dan 2000 queries per seconden op één van onze servers voor een forse social-network site, houd het een keertje op. Doordat CPU kracht tegenwoordig goedkoop is, ligt de bottleneck het vaakst bij de trage hardeschijf toegang, en we gebruiken dan ook soms de snelste vorm van hardeschijfopslag, Fiber optic SAS met RAID-50 bijvoorbeeld via hardware matige XOR kaarten, 64GB systeemgeheugen met veel cache, etc, etc. Echter soms zijn onze handen gebonden, omdat de klant niet meer besteden voor een load-balanced opzet. Dit soort berichten van Sun zijn dus van harte welkom, om meer snelheid uit bestaande hardware te halen.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 01:34]

[InputOutput]

"Hopelijk is de POSIX code voor de Windows versie ook aangepast. Tuurlijk is het gemakkelijk om de schuld bij Microsoft te leggen, omdat Windows niet 100% POSIX compatible is, maar dat lost het probleem niet op."

Hoezo? Het probleem ligt dan toch bij Microsoft?

Zij moeten het probleem ook oplossen, of je moet als Microsoft klant op zoek naar een andere leverancier.

Nu vraag je MySQL allemaal rare hacks te maken, iets wat ik echt niet in een database product thuis vind horen.

[Tjeerd]

Er vanuit gaande dat de queries e.d. al prima zijn in jullie situatie, lees ik wel vaker dat mensen MySQL traag vinden. Wat blijkt dan: de tabellen zijn bijvoorbeeld slecht genormaliseerd (lees: slechte databasestructuur), de queries zijn niet geoptimaliseerd enzovoorts. Het is vaak makkelijk om MySQL de schuld te geven wanneer het traag gaat, maar aan de andere kant maakt het ook erg veel uit hoe het een en ander geimplementeerd is. Ook is er nogal wat te optimaliseren. Als ik soms zie wat mensen aan databaseschema's in elkaar zetten en wat voor queries ze bouwen, dan vermoed ik dat daar nog best wat aan kan worden verbeterd. Het ziet er vaak heel interessant uit om ingewikkelde queries te maken. Een database die goed in elkaar zit zou met betrekkelijk eenvoudige queries ook al de gewenste informatie moeten kunnen ophalen, is mijn mening dan.

[moto-moi]

of mensen lopen gewoon tegen de beperkingen van mysql aan, mysql schaalt echt niet oneindig

[_JGC_]

Doet me ook meteen denken aan de presentatie van FreeBSD 7 op FOSDEM waar ze diverse linuxversies gingen vergelijken met diverse versies van FreeBSD. Op alle platformen zakte MySQL toen behoorlijk inelkaar qua scalability waarbij Postgresql gewoon doorschaalde.

[killingdjef]

Zou graag dezelfde test zien bij de nieuwe versie van MySQL aangezien deze test al een jaar oud is.

[cariolive23]

Inderdaad, en PostgreSQL is inmiddels ook al weer bij versie 8.3.1 aanbeland. Die schijnt nog weer een heel stuk sneller te zijn dan 8.2.

[ThE_ED]

Ja, volgens mij heeft ACM daar ook eens heel wat over gepost, weet niet meer of dat hier of op fok! was. Of was jij dat?

Wat je ook vaak ziet is dat men gewoon ooit eens met een site begint, en dan knal je lekker makkelijk MySQL ergens neer, leest een boek en gaan! Alleen als het dan groter wordt blijkt dat je toch een specialist nodig hebt, maarja je site groeit. Sommige sites kopen belachelijk veel servers in omdat ze gewoon te snel groeien.

[burne]

Als je nu al I/O-buond bent gaat een nieuwe, snellere versie je I/O niet sneller maken. Het gaat 20% makkelijker worden om I/O-bound te worden, meer niet.

[barfieldmv]

Misschien is er wel 20% minder I/O dus ~20% meer performance.

[SuperDre]

Mysql werkt al geruime tijd aan de alternatieve Falcon-engine en er wordt door een voormalige Mysql-ontwikkelaar aan de Maria-engine gebouwd. De bouwers van zowel de Falcon- als de Maria-engine willen hun product de standaard Mysql-engine laten worden.

En zo krijg je dus weer vrolijk verschillende versies wat dus niet goed is voor compatibliteit..

[SPee]

Ligt eraan.
Je gebruikt de database functionaliteit.
Wat die intern doet, zou je als gebruiker niet moeten uitmaken.
Het enige wat die 2 engines doen is een verschillende manier om data op te slaan/op te halen. Hoe ze dat doen hangt van de engine af. Wat jij als gebruiker moet weten is welke engine je moet gebruiken om de optimale performance te behalen.

Je hebt in MSSQL toch ook de mogelijkheid om te kiezen voor SQL2000 (= dus een andere engine).

[skysoft]

Sterker nog;

voor sommige taken kan het kiezen van een andere engine heel gunstig uitpakken. Als je bijvoorbeeld weet dat je bergen tijdelijke data moet verwerken dan kan de engine die volledig in het geheugen draait heel gunstig voor je verwerkingstijd zijn...

[Verwijderd]

Het leuke is dat postgresSQL standaard wordt meegeleverd in Solaris 10. Je moet zelfs moeite doen om sommige softwarepakketten binnen solaris van een andere database gebruik te laten maken. Ben benieuwd hoe men dit straks gaat aanpakken bij Sun.

Solaris 10 was de snelste ter wereld met PostgresSQL

[Reactie gewijzigd door Verwijderd op 24 juli 2024 01:34]

[Xeon_vl]

hehe dat werd tijd een jaar geleden zeiden ze nog dat mysql 5.1 in de nabije toekomst zou worden uitgebracht. Ik snap dat die sun overname wat tijd heeft opgeslorpt, maar ze hebben er toch wel eventjes de tijd voor genomen. Ik draai de beta al op een test machine, en die doet het goed.

[Olaf van der Spek]

Het is wel apart dat MySQL geen nieuwe release candidate uitbrengt maar gelijk de final, aangezien er sinds de laatste RC een groot aantal bugs zijn gefixed en dus code is veranderd.

[volgensbartjes.]

Wat ik mij eigelijk afvraag, ik gebruik ook mysql databases op mijn webhosting (is de standaard), maar als een server nou op die andere software zou draaien (postgres ofzo) blijven je sql querys die je in php bijv schrijft dan gewoon het zelfde? of zijn die querys die ik nu gebruik speciaal voor mysql?
er zijn hier mensen die zeggen van, waarom gaan mensen niet naar postgres, maar als je dan al je codes moet omgooien lijkt me dat niet echt handig? of het moet dus het zelfde kunnen blijven? en dan is mysql ook nog gratis om op webhosting te gebruiken toch? en die anderen niet? (betaalde versie, is dat dan alleen voor intern bij bedrijven ofzo?)

[Kettrick]

Dat hangt er vanaf hoe je SQL geschreven is, sommige dingen zijn MySQL specifiek. In de praktijk zullen weinig applicaties één op één over kunnen, hooguit een simpel gastenboekje

[daft_dutch]

als je normale queries hebt zonder multi row functies moet je alleen maar naar LIMIT kijken.

[Xthemes.us]

Niet alles zal vlekkeloos werken, maar het merendeel zal werken.

Je kan ook gebruik maken in PHP (en ook python) van http://adodb.sourceforge.net/ deze zorgt ervoor dat het overstappen op een andere database een stuk makkelijker is.

[Verwijderd]

Daarvoor heb je in php ook PDO: http://nl2.php.net/pdo
maar elke database heeft natuurlijk zijn eigen SQL dialect

[hackerhater]

Een beetje slimme programmeur laat de applicatie ook niet direct met de DB praten, maar gebruikt een DAL.
Hierdoor is je applicatie onafhankelijk van de keuze van de DB

sommige dingen zijn idd DB-specifiek, maar het standaard SQL niet.