, de nieuwste versie van ‘de beste open source relationele database ter wereld’, komt over een paar weken uit (als alles volgens plan verloopt). Dit volgt het gebruikelijke schema van het één keer per jaar uitbrengen van een nieuwe versie met een heleboel nieuwe functies, en eerlijk gezegd is dat indrukwekkend. Daarom werd ik een actief lid van de PostgreSQL-gemeenschap.
Naar mijn mening bevat PostgreSQL 12, in tegenstelling tot eerdere releases, niet een of twee revolutionaire functies (zoals partitionering of parallellisme van query's). Ik grapte ooit dat het belangrijkste kenmerk van PostgreSQL 12 een grotere stabiliteit is. Is dat niet wat u nodig heeft als u de kritieke gegevens van uw bedrijf beheert?
Maar PostgreSQL 12 houdt daar niet op: met nieuwe functies en verbeteringen zullen applicaties beter presteren, en het enige wat u hoeft te doen is upgraden!
(Nou ja, misschien de indexen opnieuw opbouwen, maar in deze release is het niet zo eng als we gewend zijn.)
Het zal geweldig zijn om PostgreSQL te upgraden en onmiddellijk te profiteren van aanzienlijke verbeteringen, zonder onnodig gedoe. Een paar jaar geleden bekeek ik een upgrade van PostgreSQL 9.4 naar PostgreSQL 10 en zag hoe de applicatie versnelde dankzij het verbeterde query-parallellisme in PostgreSQL 10. En het allerbelangrijkste: er was bijna niets van mij vereist (stel gewoon een configuratieparameter in max_parallel_workers).
Mee eens, het is handig als applicaties direct na een upgrade beter werken. En we doen ons uiterste best om gebruikers tevreden te stellen, omdat PostgreSQL er steeds meer heeft.
Dus hoe kan een eenvoudige upgrade naar PostgreSQL 12 u gelukkig maken? Ik zal het je nu vertellen.
Belangrijke indexeringsverbeteringen
Zonder indexering komt een database niet ver. Hoe kun je anders snel informatie vinden? Het fundamentele indexeringssysteem van PostgreSQL wordt genoemd . Dit type index is geoptimaliseerd voor opslagsystemen.
Wij gebruiken gewoon de operator CREATE INDEX ON some_table (some_column), en PostgreSQL doet veel werk om de index up-to-date te houden, terwijl we voortdurend waarden invoegen, bijwerken en verwijderen. Alles werkt vanzelf, als bij toverslag.
Maar PostgreSQL-indexen hebben één probleem: zij en nemen extra schijfruimte in beslag en verminderen de prestaties bij het ophalen en bijwerken van gegevens. Met "bloat" bedoel ik het ineffectief behouden van de indexstructuur. Dit kan (of kan niet) verband houden met de afval-tupels die worden verwijderd (met dank aan Peter Gaghan voor de informatie))). Indexzwelling is vooral merkbaar bij werklasten waarbij de index actief verandert.
PostgreSQL 12 verbetert de prestaties van B-tree-indexen aanzienlijk, en experimenten met benchmarks zoals TPC-C hebben aangetoond dat er nu gemiddeld 40% minder ruimte wordt gebruikt. Nu besteden we niet alleen minder tijd aan het onderhouden van B-tree-indexen (dat wil zeggen aan schrijfbewerkingen), maar ook aan het ophalen van gegevens, omdat de indexen veel kleiner zijn.
Applicaties die hun tabellen actief bijwerken - meestal OLTP-applicaties () - zal schijf- en procesaanvragen veel efficiënter gebruiken. Hoe meer schijfruimte, hoe meer ruimte de database heeft om te groeien zonder de infrastructuur te upgraden.
Sommige upgradestrategieën vereisen het opnieuw opbouwen van B-tree-indexen om van deze voordelen te kunnen profiteren (bijv. indexen niet automatisch opnieuw opbouwen). In eerdere versies van PostgreSQL resulteerde het opnieuw opbouwen van grote indexen op tabellen in aanzienlijke downtime omdat er in de tussentijd geen wijzigingen konden worden aangebracht. Maar PostgreSQL 12 heeft nog een leuke functie: nu kun je indexen parallel aan de opdracht opnieuw opbouwen om stilstand volledig te voorkomen.
Er zijn nog andere verbeteringen aan de indexeringsinfrastructuur in PostgreSQL 12. Nog iets waar magie in zat - , ook bekend als WAL (write-ahead log). Een vooruitschrijflogboek registreert elke transactie in PostgreSQL in geval van falen en replicatie. Toepassingen gebruiken het voor archivering en . Uiteraard wordt het vooruitschrijflogboek naar schijf geschreven, wat de prestaties kan beïnvloeden.
PostgreSQL 12 heeft de overhead verminderd van WAL-records die worden gemaakt door de GiST-, GIN- en SP-GiST-indexen tijdens de constructie van de index. Dit biedt verschillende tastbare voordelen: WAL-records nemen minder schijfruimte in beslag en gegevens worden sneller afgespeeld, bijvoorbeeld tijdens noodherstel of herstel op een bepaald tijdstip. Als u dergelijke indexen in uw applicaties gebruikt (op PostGIS gebaseerde geospatiale applicaties gebruiken de GiST-index bijvoorbeeld veel), is dit een andere functie die de ervaring aanzienlijk zal verbeteren zonder enige inspanning van uw kant.
Partitioneren - groter, beter, sneller
PostgreSQL 10 geïntroduceerd . In PostgreSQL 11 is het veel eenvoudiger in gebruik geworden. In PostgreSQL 12 kunt u de schaal van secties wijzigen.
In PostgreSQL 12 zijn de prestaties van het partitiesysteem aanzienlijk beter geworden, vooral als er duizenden partities in de tabel staan. Als een query bijvoorbeeld slechts enkele partities in een tabel met duizenden partities beïnvloedt, wordt deze veel sneller uitgevoerd. De prestaties zijn niet alleen verbeterd voor dit soort zoekopdrachten. U zult ook merken hoe sneller INSERT-bewerkingen zijn op tabellen met meerdere partities.
Gegevens vastleggen met - dit is trouwens een geweldige manier en hier is een voorbeeld — gepartitioneerde tabellen in PostgreSQL 12 zijn ook efficiënter geworden. Met COPY ging alles al snel, maar in PostgreSQL 12 vliegt het absoluut.
Dankzij deze voordelen kunt u met PostgreSQL nog grotere datasets opslaan en ze gemakkelijker terugvinden. En geen enkele inspanning van uw kant. Als de applicatie veel partities heeft, zoals het opnemen van tijdreeksgegevens, zal een eenvoudige upgrade de prestaties aanzienlijk verbeteren.
Hoewel dit niet bepaald een "upgrade en geniet"-verbetering is, kun je met PostgreSQL 12 externe sleutels maken die verwijzen naar gepartitioneerde tabellen, waardoor het werken met partities een plezier wordt.
MET-query's zijn nu een stuk beter geworden
Wanneer (ook bekend als CTE, oftewel MET vragen), ik kon niet wachten om er een artikel over te schrijven . Dit is een van die functies die de applicatie zullen versnellen. Tenzij je natuurlijk CTE gebruikt.
Ik merk vaak dat nieuwelingen op het gebied van SQL graag CTE's gebruiken; als je ze op een bepaalde manier schrijft, voelt het echt alsof je een imperatief programma schrijft. Persoonlijk vond ik het leuk om deze vragen te herschrijven om rond te komen без CTE en verhoog de productiviteit. Nu is alles anders.
Met PostgreSQL 12 kunt u een specifiek type CTE inline plaatsen zonder bijwerkingen (SELECT), dat slechts één keer wordt gebruikt aan het einde van het verzoek. Als ik de CTE-query's zou bijhouden die ik heb herschreven, zouden de meeste in deze categorie vallen. Dit helpt ontwikkelaars om duidelijke code te schrijven die nu ook snel draait.
Bovendien optimaliseert PostgreSQL 12 de SQL-uitvoering zelf, zonder dat u iets hoeft te doen. En hoewel ik dergelijke query's nu waarschijnlijk niet hoef te optimaliseren, is het geweldig dat PostgreSQL blijft werken aan query-optimalisatie.
Just-in-Time (JIT) - nu standaard
Op PostgreSQL 12-systemen met ondersteuning JIT-compilatie is standaard ingeschakeld. Allereerst krijg je ondersteuning voor sommige interne bewerkingen, en ten tweede kunnen query's met expressies (het eenvoudigste voorbeeld is x + y) in geselecteerde lijsten (die je hebt na SELECT), aggregaten, expressies met WHERE-clausules en andere JIT gebruiken om de prestaties te verbeteren.
Omdat JIT standaard is ingeschakeld in PostgreSQL 12, zullen de prestaties vanzelf verbeteren, maar ik raad aan om de applicatie te testen in PostgreSQL 11, waarin JIT werd geïntroduceerd, om de queryprestaties te meten en te zien of je iets moet afstemmen.
Hoe zit het met de rest van de nieuwe functies in PostgreSQL 12?
PostgreSQL 12 heeft een heleboel coole nieuwe functies, van de mogelijkheid om JSON-gegevens te onderzoeken met behulp van standaard SQL/JSON-route-expressies tot meervoudige authenticatie met een parameter clientcert=verify-full, kolommen gemaakt 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 op het productiesysteem voordat je verbeteringen inschakelt, zoals ik deed met PostgreSQL 10. Zelfs als PostgreSQL 12 al stabieler is dan ik had verwacht, wees dan niet lui bij het testen applicaties grondig door, voordat ze in productie worden genomen.
Bron: www.habr.com