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

Door , , 11 reacties
Bron: PostgreSQL, submitter: cariolive23

PostgreSQL is een opensource relational database management system dat op diverse besturingssystemen gedraaid kan worden. De ontwikkelaars hebben nu versie 8.4 laten verschijnen, na eerder twee bètaversies en een release candidate te hebben uitgebracht. In versie 8.4 is het mogelijk om een restore parallel uit te voeren en permissies op kolommen te zetten. Ook wordt het gebruik van ssl-certificaten om gebruikers te authenticeren nu ondersteund. De bijbehorende aankondiging ziet er als volgt uit:

PostgreSQL 8.4 Released: Now Easier to Use than Ever

The PostgreSQL Global Development Group has released version 8.4, continuing the rapid development of the world's most advanced open source database. This release contains an abundance of enhancements to make administering, querying, and programming of PostgreSQL databases easier than ever before. Our development team has spent 16 months adding over two hundred improvements to all aspects of database functionality, helping every PostgreSQL user in small or large ways.

Many of the changes in PostgreSQL 8.4 are new or improved administration and monitoring tools and commands. Each user has their own favorite features which will make day-to-day work with PostgreSQL easier and more productive for them. Among the most popular enhancements are:
  • Parallel Database Restore, speeding up recovery from backup up to 8 times
  • Per-Column Permissions, allowing more granular control of sensitive data
  • Per-database Collation Support, making PostgreSQL more useful in multi-lingual environments
  • In-place Upgrades through pg_migrator (beta), enabling upgrades from 8.3 to 8.4 without extensive downtime
  • New Query Monitoring Tools, giving administrators more insight into query activity
  • Greatly Reduced VACUUM Overhead through the Visibility Map
  • New Monitoring Tools for current queries, query load and deadlocks
Version 8.4 also makes data analysis easier through the advanced ANSI SQL2003 features of windowing functions, common table expressions and recursive queries. Enhancements to stored procedures, such as default parameters and variadic parameters, make database server programming simpler and more compact. Of course, there are also performance improvements included in this version.

Download version 8.4 today and start enjoying using PostgreSQL even more!
Moderatie-faq Wijzig weergave

Reacties (11)

Zijn er ergens benchmarks van deze PostgreSQL versus MySQL 5.1 (de laatste stable versies van die 2).. Zou wel leuk zijn. Of misschien leuk voor tweakers om weer eens te doen?

Tot nu toe heb ik maar 1 recente benchmark gevonden: http://www.randombugs.com...ostgresql-benchmarks.html
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 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.
Gezien postgresql sinds enkele jaren een grote voorsprong heeft op mysql qua snelheid, functionaliteit en vooral stabiliteit stel ik me de vraag: waarom zou je in hemelsnaam mysql nog gebruiken?
En niet te vergeten dat de licentie van PostgreSQL wat meer ruimte overlaat dan die van MySQL (BSD vs GPL). Nu denk je misschien big deal, ik prog toch zelf niks aan de DB, maar dit geld ook voor de conntector libraries (JDBC, ODBC, etc) !
Gevalletje melk horen klotsen maar niet weten waar de uiers hangen denk ik.
Hoe moet je versie 8.x upgraden naar 8.4 of is dit nit mogelijk.
Er is inmiddels een conversieprogramma voor een overstap van 8.3 naar 8.4, pg_migrator.

Voor alle andere soorten migraties hou je de oude methode: maak een backup van de oude versie en restore deze in de nieuwe versie. Wanneer je beide versies naast elkaar kunt laten draaien, eventueel op verschillende servers, kun je de backup direct laten restoren in de nieuwe versie. Je moet dan wel de nieuwe versie even naar een ander poortnummer laten luisteren. De downtime die je met deze opzet hebt, is zeer minimaal: wanneer de oude databases keurig zijn gerestored in de nieuwe versie nog even het poortnummer aanpasseen en de database stoppen en starten. Dat kun je met een minuutje geregeld hebben.
Dat werkt natuurlijk alleen als er tussendoor geen schrijfhandelingen zijn. Bij grotere databases is de kans daarop natuurlijk wel vrij fors. En dan ontkom je er haast niet aan om in ieder geval heel even je omgeving plat te gooien of in een read-only modus te zetten.
Ik heb verder geen idee of de log-archiving functionaliteit ook tussen verschillende versies gebruikt kan worden, nog afgezien van het feit dat dat pas in 8.3 (?) is toegevoegd.

Dus in veel gevallen zal je nog de dump-restore cycle moeten doorlopen, met een stuk downtime.
Je kunt uiteraard ook eerst een replica aanmaken met bv. Slony en dan de slave (die je uiteraard op de nieuwe versie zet) omschakelen naar master. Vervolgens ga je de oude master migreren naar de nieuwe versie en laat je deze synchroniseren met de nieuwe master.

Met de dump-restore aanpak heb je een downtime gedurende het maken van de backup + een paar minuten voor controles en het aanpassen van postgresql.conf. De nieuwe versie installeren en testen kun je vooraf al doen, dat hoef je niet meer te doen wanneer je daadwerkelijk gaat migreren. Uiteraard doe je wel een intake nadat alles klaar lijkt te zijn, maar dat hoor je toch al met iedere migratie te doen. De totale downtime valt ook met deze aanpak meestal wel mee en zal meestal ook wel acceptabel zijn. Anders had je al wel een replicatiesysteem opgezet, ongeacht de migratie.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True