Ik ken helaas ook geen goede recente vergelijkingen, ik zit ook de wachten op Tweakers...
De benchmark die je hier noemt, heb ik m'n twijfels over. PostgreSQL heeft daarin een paar zeer grote uitschieters, die lijken mij niet helemaal lekker. Tuurlijk, als PostgreSQL-gebruiker zie je dit soort dingen ook liever niet, maar wanneer bepaalde tests ineens duizenden keren langzamer zijn, dan zit er wel ergens iets goed fout.
bulk_modify() 0.2 0.05 640.61
0.05 seconde voor MySQL 5.1 en dan 640.61 secondes voor PostgreSQL? En andere tests zijn min of meer gelijk? Voordat je hier een conclusie aan verbind, moet je eerst weten waarom het zo gruwelijk slecht gaat, het verschil is véél te groot.
Zelf heb ik afgelopen weken wat vergelijkingen gemaakt tussen een 8.2 en 8.4 database , daarin viel met name op dat onderhoud veel sneller ging. 8.4 databases zijn een stuk compacter (in GB's) t.o.v. de 8.2 versie. Auto_vacuum loopt hierdoor veel lekkerder (en is ook eenvoudig per tabel in te stellen), COPY is veel sneller geworden en indexen zijn efficienter. Ben dan ook druk bezig om een migratieplan op te stellen, versie 8.4 gaat het beheer eenvoudiger en sneller maken.
Onze vergelijking is eigenlijk nooit een eerlijke MySQL vs PostgreSQL-vergelijking geweest. In het begin is er wat meer aandacht aan de performance binnen PostgreSQL besteed, terwijl er later juist meer aandacht naar MySQL is gegaan.
De resultaten van onze laatste benchmark (geen idee wanneer dat gepubliceerd gaat worden) zullen je dan ook wellicht wat tegenvallen, MySQL's schaling is behoorlijk opgepept sinds de vorige benchmark een paar jaar geleden... en daardoor is ie PostgreSQL in onze benchmark nu de baas.
Maar daarbij komt dus dat het geen heel eerlijke benchmark is, ik heb de indruk dat we te weinig schrijven ivt onze echte omgeving. Maar tegelijk verbinden we in het echt vaker met de database, maar doen we weer relatief meer werk tussen de queries in, waardoor de effecten daarvan weer anders uitpakken.
Overigens is de compactheid van de database een wijziging van 8.3, toen is de overhead per row aardig naar beneden bijgesteld.
[Reactie gewijzigd door ACM op vrijdag 3 juli 2009 10:45]
Klopt, een groot deel van de performance haal je uit de wijze waarop een applicatie met een database werkt. Wanneer de applicatie de verkeerde keuzes maakt, keuzes die niet het beste uit een bepaald merk database halen, zul je nooit het maximale uit een database kunnen halen. Het was eigenlijk al bijzonder om te zien dat Tweakers uit een MySQL-applicatie zoveel performance met een PostgreSQL-database kreeg zonder alles opnieuw te moeten gaan bouwen.
Het grootste knelpunt van MySQL, veel concurrent users, is flink verbeterd of zelfs opgelost.
Voor een goede performance van een database, zul je vanaf het allereerste begin een goede strategie moeten hebben. Lukraak wat INSERT's, UPDATE, DELETE's en SELECT's loslaten op een database, dat wordt niks. Zo zitten we hier nog met wat overbodige lusjes in de applicatiecode en onbruikbare indexen, wat per actie een 20.000 sequential scans oplevert... Hier zou 1 enkele query op zijn plaats zijn geweest, deze kan dezelfde data in een fractie van een seconde ophalen. Nu kost dit een minuut of 5....
Om een goede vergelijking tussen databases te maken, zou je eigenlijk per database een applicatie moeten hebben die is geoptimaliseerd voor deze database maar verder dezelfde functionaliteit heeft als de applicaties voor de andere databases die je wilt gaan vergelijken. Maar ja, wie gaat er nu een X-aantal applicaties maken voor een X-aantal databases? Dat gaat je flink wat tijd (en dus geld) kosten.
Voorlopig ben ik blij dat we hier met PostgreSQL werken, is eenvoudig te beheren en levert uitstekende performance. Zelfs met een applicatie die niet optimaal is, weet PostgreSQL de maximaal haalbare performance te leveren.
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
17:14
16:49
Door 
