Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

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.

MySQL-logoNieuw 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.

Door Harm Hilvers

Freelance nieuwsposter

13-04-2008 • 11:40

54 Linkedin Google+

Lees meer

Reacties (54)

Wijzig sortering
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?
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.
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.
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 13 april 2008 16:02]

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.
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.
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.
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
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 Ron.IT op 13 april 2008 12:55]

"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.
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.
of mensen lopen gewoon tegen de beperkingen van mysql aan, mysql schaalt echt niet oneindig ;)
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.
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). ;)
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...
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 Bonjour op 13 april 2008 23:16]

Op dit item kan niet meer gereageerd worden.


OnePlus 7 Pro (8GB intern) Nintendo Switch Lite LG OLED C9 Google Pixel 3a XL FIFA 19 Samsung Galaxy S10 Sony PlayStation 5 Laptops

'14 '15 '16 '17 2018

Tweakers vormt samen met Tweakers Elect, Hardware Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True