, de nieuwste versie van de "beste relationele database ter wereld met open source", wordt over een paar weken uitgebracht (als alles volgens plan verloopt). Dit komt overeen met het gebruikelijke schema: elke nieuwe versie komt elk jaar uit met talloze nieuwe mogelijkheden, en eerlijk gezegd, dat is indrukwekkend. Daarom ben ik een actief lid geworden van de PostgreSQL-gemeenschap.
Naar mijn mening bevat PostgreSQL 12, in tegenstelling tot eerdere uitgaven, niet één of twee revolutionaire functies (zoals, bijvoorbeeld, partitionering of parallelle queryverwerking). Ik grapte ooit dat de belangrijkste eigenschap van PostgreSQL 12 meer stabiliteit is. En dat is toch wat je nodig hebt als je cruciale bedrijfsdata beheert?
Maar PostgreSQL 12 beperkt zich daar niet toe: met nieuwe mogelijkheden en verbeteringen zullen applicaties beter presteren, en van jou wordt enkel een upgrade gevraagd!
(Nou, misschien ook een keer de indexen opnieuw opbouwen, maar in deze release is dat niet zo erg als we gewend zijn.)
Het zou geweldig zijn — PostgreSQL upgraden en meteen genieten van aanzienlijke verbeteringen zonder al te veel gedoe. Een paar jaar geleden analyseerde ik de upgrade van PostgreSQL 9.4 naar PostgreSQL 10 en zag ik hoe de applicatie versnelde dankzij verbeterde parallelle queryverwerking in PostgreSQL 10. En het belangrijkste was dat ik bijna niets hoefde te doen (alleen een configuratieparameter instellen, max_parallel_workers).
Toegegeven, het is handig als applicaties direct na de upgrade beter presteren. En we doen ons best om onze gebruikers tevreden te stellen, want steeds meer mensen kiezen voor PostgreSQL.
En hoe zal een eenvoudige upgrade naar PostgreSQL 12 je gelukkig maken? Ik vertel het je nu.
Serieuze verbeteringen in indexering
Zonder indexering komt een database niet ver. Hoe vind je anders snel informatie? Het fundamentele indexeringssysteem van PostgreSQL wordt genoemd . Dit type index is geoptimaliseerd voor opslag systemen.
We gebruiken simpelweg de operator CREATE INDEX ON some_table (some_column), en PostgreSQL doet het zware werk om de index up-to-date te houden, terwijl we voortdurend waarden invoegen, bijwerken en verwijderen. Het werkt allemaal vanzelf, als magie.
Maar indexen in PostgreSQL hebben één probleem — ze en nemen onnodige schijfruimte in, waardoor de prestaties van gegevensextractie en -bijwerking afnemen. Met 'opblazen' bedoel ik het inefficiënt onderhouden van de indexstructuur. Dit kan — maar hoeft niet — verband te houden met verwijderde junk-tuple's (dank aan Peter Geoghegan voor de informatie ()). Het opblazen van indexen is vooral merkbaar in werklasten waar de index actief verandert.
PostgreSQL 12 verbetert de werking van B-tree indexen aanzienlijk, en experimenten met TPC-C soortgelijke tests hebben aangetoond dat er nu gemiddeld 40% minder ruimte wordt gebruikt. We besteden nu minder tijd aan het onderhouden van B-tree indexen (dat wil zeggen aan schrijfbewerkingen), maar ook aan het extraheren van gegevens, omdat de indexen veel kleiner zijn geworden.
Toepassingen die hun tabellen actief bijwerken — meestal OLTP-toepassingen () — zullen efficiënter gebruik maken van schijfruimte en verzoeken verwerken. Hoe meer schijfruimte beschikbaar is, hoe meer ruimte er voor de database is om te groeien zonder infrastructuur-upgrades.
Bepaalde upgrade-strategieën vereisen het herbouwen van B-tree indexen om van deze voordelen te profiteren (zoals bouwt indexen niet automatisch opnieuw op). In eerdere versies van PostgreSQL leidde het herbouwen van grote indexen in tabellen tot aanzienlijke uitvaltijd, omdat er dan geen wijzigingen konden worden aangebracht. Maar in PostgreSQL 12 is er nog een geweldige functie: indexen kunnen nu parallel worden herbouwd met het commando , om uitvaltijd helemaal te vermijden.
PostgreSQL 12 heeft ook andere verbeteringen op het gebied van indexinfrastructuur. Weer iets waar magie aan te pas kwam, is de , ook wel WAL genoemd (write-ahead log). De write-ahead log registreert elke transactie in PostgreSQL voor het geval van een storing of replicatie. Toepassingen gebruiken deze log voor archivering en . Natuurlijk wordt de write-ahead log op de schijf geschreven, wat de prestaties kan beïnvloeden.
In PostgreSQL 12 zijn de kosten van WAL-berichten die door GiST-, GIN- en SP-GiST-indexen worden aangemaakt bij het bouwen van een index, verminderd. Dit biedt verschillende merkbare voordelen: WAL-berichten nemen minder schijfruimte in beslag en gegevens worden sneller hersteld, bijvoorbeeld tijdens een herstel na een storing of een tijdstipherstel. Als je zulke indexen in je applicaties gebruikt (bijvoorbeeld geospatiale applicaties die veel gebruikmaken van de GiST-index op basis van PostGIS), is dit weer een functie die de werking aanzienlijk verbetert zonder dat daar veel moeite voor gedaan hoeft te worden.
Partitionering — meer, beter, sneller
In PostgreSQL 10 is er . In PostgreSQL 11 is het veel eenvoudiger geworden om te gebruiken. In PostgreSQL 12 kunnen de schalen van de secties worden aangepast.
In PostgreSQL 12 is de prestaties van het partitioneringssysteem aanzienlijk verbeterd, vooral als er duizenden secties in de tabel staan. Bijvoorbeeld, als een query slechts enkele secties in een tabel met duizenden raakt, zal het veel sneller worden uitgevoerd. De prestaties zijn niet alleen verbeterd voor dit soort queries. Je zult ook merken dat INSERT-operaties in tabellen met veel secties versneld zijn.
Gegevens opnemen met — dat is trouwens een geweldige manier en hier is een voorbeeld — in PostgreSQL 12 is de efficiëntie van het inladen in gepartitioneerde tabellen ook verbeterd. Met COPY was het al snel, maar in PostgreSQL 12 gaat het echt razendsnel.
Dankzij deze voordelen kunnen in PostgreSQL nu nog grotere datasets worden opgeslagen, en het wordt eenvoudiger om ze op te vragen. En dat zonder enige inspanning van jouw kant. Als de applicatie veel secties heeft, bijvoorbeeld als deze tijdreeksgegevens opneemt, zal een eenvoudige upgrade de prestaties aanzienlijk verbeteren.
En hoewel deze verbetering niet helemaal in de categorie "ge-Upgraded en blij", in PostgreSQL 12 kunnen er nu externe sleutels worden gemaakt die naar gepartitioneerde tabellen verwijzen, zodat het werken met partitionering een genot is.
WITH-queries zijn aanzienlijk verbeterd
Wanneer (ook wel CTE's, ook wel WITH-queries), ik kon niet wachten om een artikel te schrijven over hoe . Dit is een van die functies die de applicatie zullen versnellen. Tenminste, als je CTE gebruikt.
Ik merk vaak dat nieuwkomers in SQL graag CTE gebruiken: als je ze op een bepaalde manier schrijft, voel je echt dat je een imperatieve programma schrijft. Persoonlijk hield ik ervan om deze queries opnieuw te schrijven om te zonder zonder CTE en de prestaties te verbeteren. Nu is alles anders.
PostgreSQL 12 laat je een bepaald type CTE zonder bijwerkingen inbedden (SELECT), dat maar één keer dichter bij het einde van de query wordt gebruikt. Als ik statistieken bijhield van de queries met CTE die ik herschreef, zouden de meeste in deze categorie vallen. Dit helpt ontwikkelaars om begrijpelijke code te schrijven die nu ook nog eens snel werkt.
Bovendien optimaliseert PostgreSQL 12 de uitvoering van SQL zelf, je hoeft niets te doen. En hoewel ik nu waarschijnlijk geen dergelijke queries meer hoef te optimaliseren, is het geweldig dat PostgreSQL blijft werken aan queryoptimalisatie.
Just-in-Time (JIT) — is nu standaard
In PostgreSQL 12-systemen met ondersteuning voor is JIT-compilatie standaard ingeschakeld. Ten eerste krijg je ondersteuning voor voor sommige interne bewerkingen, en ten tweede kunnen queries met expressies (het eenvoudigste voorbeeld — x + y) in de select-lijsten (die je na SELECT plaatst), aggregaten, expressies met WHERE-voorwaarden en anderen JIT gebruiken voor prestatieverbetering.
Aangezien JIT standaard is ingeschakeld in PostgreSQL 12, zal de prestatie vanzelf verbeteren, maar ik raad aan om de applicatie in PostgreSQL 11 te testen, waar JIT voor het eerst verscheen, om de prestatie van de queries te meten en te zien of er niets geconfigureerd hoeft te worden.
En wat met de andere nieuwe functies van PostgreSQL 12?
PostgreSQL 12 heeft een aantal nieuwe geweldige functies — van de mogelijkheid om JSON-gegevens te verkennen met behulp van standaard SQL/JSON paduitdrukkingen tot multifactor-authenticatie met de optie clientcert=verify-full, generatie van kolommen en nog veel meer. Genoeg voor een aparte post.
Net als PostgreSQL 10 zal PostgreSQL 12 de algehele prestaties onmiddellijk na de upgrade verbeteren. Je kunt natuurlijk je eigen pad hebben — test de applicatie onder vergelijkbare omstandigheden in een productieomgeving voordat je de verbeteringen activeert, zoals ik deed met PostgreSQL 10. Zelfs als PostgreSQL 12 nu al stabiler is dan ik verwachtte, verwaarloos niet om de applicaties grondig te testen voordat je ze in productie brengt.
Bron: habr.com
