MySQL vs. PostgreSQL
Hoewel MySQL waarschijnlijk de bekendste naam heeft van alle opensourcedatabases, zijn er een aantal zeer goede alternatieven te verkrijgen. Een daarvan is PostgreSQL, waarvan de ontwikkeling in 1986 van start ging. Het doel van het project was in eerste instantie om een opvolger van een andere database genaamd Ingres te ontwerpen. Vandaar ook de naam van het pakket: 'post-Ingres' is langzaam verbasterd naar Postgres en later dus PostgreSQL. De database is inmiddels al bij versie 8.1 beland en wordt beschouwd als zijnde minstens even goed als MySQL, zo niet beter. Omdat de discussie over 'de beste' database een gevoelige en langdradige is wordt deze in dit artikel vermeden, maar het is toch wel interessant om eens te onderzoeken hoe goed of slecht Tweakers.net zou draaien op PostgreSQL.
We kozen ervoor om een cvs-snapshot van PostgreSQL 8.2 (alpha) te compileren, omdat deze naar verluidt beter zou kunnen schalen dan de huidige officiële releases. Omdat er ook een bèta van MySQL 5.1 is geprobeerd vonden we dat PostgreSQL dezelfde kans verdiende. Toen bleek dat de 8.2-versie ondanks zijn experimentele status probleemloos en erg snel werkte, zagen we geen reden meer om terug te vallen op de laatste release.
In tegenstelling tot alle versies van MySQL die we hebben geprobeerd vertoont PostgreSQL bijna perfect schaalgedrag. Onder belasting van tien gelijktijdige gebruikers of meer levert de stap van één naar twee cores gemiddeld 114% betere prestaties op, de stap naar vier cores 96%, en vervolgens naar acht cores nog eens 77%. Dit betekent dat acht cores in totaal 7,4 keer de prestaties leveren van één core. Wat verder een verademing is ten opzichte van MySQL, is dat de prestaties stabiel blijven nadat ze hun maximum hebben bereikt. De server met meer werk opzadelen dan hij eigenlijk aankan zorgt dus niet voor de instorteffecten die we eerder zagen. Wanneer we alleen kijken naar de zware belastingen aan het einde van de grafiek zien we dat de lijnen ongeveer plat worden, waardoor de schaalcijfers nog beter zijn: de winsten van de coreverdubbelingen naar 2, 4 en 8 zijn boven de 40 gelijktijdige gebruikers respectievelijk 122%, 104% en 98%, wat betekent dat het prestatieverschil tussen één en acht cores gemiddeld een factor 9 is.

PostgreSQL zou zo een schoolvoorbeeld kunnen worden voor een goede implementatie van multithreading, en is daardoor precies het soort applicatie waar de UltraSparc T1 zijn tanden in kan zetten. Zolang niet te veel rekenkracht nodig is, maar de software wel in staat is om zich probleemloos op te splitsen in onafhankelijke delen is de T2000 volledig in zijn element. De hieronder weergegeven grafiek van MySQL 5.0.20a (dezelfde als die op de vorige pagina, maar met aangepaste schaal) laat nog eens zien hoe groot het contrast is, en dus hoe belangrijk het is om niet zomaar multithreading in de software te hebben, maar ook een goed schalende implementatie ervan.

Het heeft behoorlijk wat voeten in de aarde gehad om onze benchmark geschikt te maken voor PostgreSQL: de normale code van Tweakers.net is namelijk sterk geoptimaliseerd om de unieke 'persoonlijkheid' van MySQL 4.0 te bevredigen. Een directe kopie van de database en queries leverde dramatisch slechte resultaten op, dus om PostgreSQL een eerlijke kans te geven zijn indices verplaatst, subqueries toegepast en bepaalde joins omgeschreven. Deze optimalisaties zorgden voor een factor vier betere prestaties. Toch is er lang niet zoveel moeite in gestoken als in de MySQL-optimalisaties die letterlijk in de loop der jaren zijn gevonden, waardoor we vermoeden dat er nog wel meer uit te slepen valt.
We kozen ervoor om een cvs-snapshot van PostgreSQL 8.2 (alpha) te compileren, omdat deze naar verluidt beter zou kunnen schalen dan de huidige officiële releases. Omdat er ook een bèta van MySQL 5.1 is geprobeerd vonden we dat PostgreSQL dezelfde kans verdiende. Toen bleek dat de 8.2-versie ondanks zijn experimentele status probleemloos en erg snel werkte, zagen we geen reden meer om terug te vallen op de laatste release.
In tegenstelling tot alle versies van MySQL die we hebben geprobeerd vertoont PostgreSQL bijna perfect schaalgedrag. Onder belasting van tien gelijktijdige gebruikers of meer levert de stap van één naar twee cores gemiddeld 114% betere prestaties op, de stap naar vier cores 96%, en vervolgens naar acht cores nog eens 77%. Dit betekent dat acht cores in totaal 7,4 keer de prestaties leveren van één core. Wat verder een verademing is ten opzichte van MySQL, is dat de prestaties stabiel blijven nadat ze hun maximum hebben bereikt. De server met meer werk opzadelen dan hij eigenlijk aankan zorgt dus niet voor de instorteffecten die we eerder zagen. Wanneer we alleen kijken naar de zware belastingen aan het einde van de grafiek zien we dat de lijnen ongeveer plat worden, waardoor de schaalcijfers nog beter zijn: de winsten van de coreverdubbelingen naar 2, 4 en 8 zijn boven de 40 gelijktijdige gebruikers respectievelijk 122%, 104% en 98%, wat betekent dat het prestatieverschil tussen één en acht cores gemiddeld een factor 9 is.

PostgreSQL zou zo een schoolvoorbeeld kunnen worden voor een goede implementatie van multithreading, en is daardoor precies het soort applicatie waar de UltraSparc T1 zijn tanden in kan zetten. Zolang niet te veel rekenkracht nodig is, maar de software wel in staat is om zich probleemloos op te splitsen in onafhankelijke delen is de T2000 volledig in zijn element. De hieronder weergegeven grafiek van MySQL 5.0.20a (dezelfde als die op de vorige pagina, maar met aangepaste schaal) laat nog eens zien hoe groot het contrast is, en dus hoe belangrijk het is om niet zomaar multithreading in de software te hebben, maar ook een goed schalende implementatie ervan.

Het heeft behoorlijk wat voeten in de aarde gehad om onze benchmark geschikt te maken voor PostgreSQL: de normale code van Tweakers.net is namelijk sterk geoptimaliseerd om de unieke 'persoonlijkheid' van MySQL 4.0 te bevredigen. Een directe kopie van de database en queries leverde dramatisch slechte resultaten op, dus om PostgreSQL een eerlijke kans te geven zijn indices verplaatst, subqueries toegepast en bepaalde joins omgeschreven. Deze optimalisaties zorgden voor een factor vier betere prestaties. Toch is er lang niet zoveel moeite in gestoken als in de MySQL-
Volgende pagina (Sun UltraSparc T1 vs. AMD Opteron - 8/10)