{"id":37975,"date":"2019-10-31T22:20:56","date_gmt":"2019-10-31T19:20:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost\/"},"modified":"2019-10-31T22:20:56","modified_gmt":"2019-10-31T19:20:56","slug":"apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","title":{"rendered":"Upgrade voor luiaards: hoe PostgreSQL 12 de prestaties verbetert","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Upgrade<\/p>\n

PostgreSQL 12<\/a><\/noindex>, 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.<\/p>\n

<\/p>\n

Naar mijn mening bevat PostgreSQL 12, in tegenstelling tot eerdere uitgaven, niet \u00e9\u00e9n 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?<\/p>\n

<\/p>\n

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!<\/em><\/p>\n

<\/p>\n

(Nou, misschien ook een keer de indexen opnieuw opbouwen, maar in deze release is dat niet zo erg als we gewend zijn.)<\/p>\n

<\/a><\/noindex><\/p>\n

Het zou geweldig zijn \u2014 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<\/code>).<\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

En hoe zal een eenvoudige upgrade naar PostgreSQL 12 je gelukkig maken? Ik vertel het je nu.<\/p>\n

<\/p>\n

Serieuze verbeteringen in indexering<\/h3>\n

<\/p>\n

Zonder indexering komt een database niet ver. Hoe vind je anders snel informatie? Het fundamentele indexeringssysteem van PostgreSQL wordt genoemd B-tree<\/a><\/noindex>. Dit type index is geoptimaliseerd voor opslag systemen.<\/p>\n

<\/p>\n

We gebruiken simpelweg de operator CREATE INDEX ON some_table (some_column)<\/code>, 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.<\/p>\n

<\/p>\n

Maar indexen in PostgreSQL hebben \u00e9\u00e9n probleem \u2014 ze groeien te veel<\/a><\/noindex> en nemen onnodige schijfruimte in, waardoor de prestaties van gegevensextractie en -bijwerking afnemen. Met 'opblazen' bedoel ik het ineffici\u00ebnt onderhouden van de indexstructuur. Dit kan \u2014 maar hoeft niet \u2014 verband te houden met verwijderde junk-tuple's VACUUM<\/a><\/noindex> (dank aan Peter Geoghegan voor de informatie (Peter Geoghegan<\/a><\/noindex>)). Het opblazen van indexen is vooral merkbaar in werklasten waar de index actief verandert.<\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

Toepassingen die hun tabellen actief bijwerken \u2014 meestal OLTP-toepassingen (real-time transactie verwerking<\/a><\/noindex>) \u2014 zullen effici\u00ebnter 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.<\/p>\n

<\/p>\n

Bepaalde upgrade-strategie\u00ebn vereisen het herbouwen van B-tree indexen om van deze voordelen te profiteren (zoals pg_upgrade<\/a><\/noindex> 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 REINDEX CONCURRENTLY<\/a><\/noindex>, om uitvaltijd helemaal te vermijden.<\/p>\n

<\/p>\n

PostgreSQL 12 heeft ook andere verbeteringen op het gebied van indexinfrastructuur. Weer iets waar magie aan te pas kwam, is de write-ahead log<\/a><\/noindex>, 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 tijdstip herstel<\/a><\/noindex>. Natuurlijk wordt de write-ahead log op de schijf geschreven, wat de prestaties kan be\u00efnvloeden.<\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

Partitionering \u2014 meer, beter, sneller<\/h3>\n

<\/p>\n

In PostgreSQL 10 is er declaratieve partitionering<\/a><\/noindex>. In PostgreSQL 11 is het veel eenvoudiger geworden om te gebruiken. In PostgreSQL 12 kunnen de schalen van de secties worden aangepast.<\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

Gegevens opnemen met COPY<\/a><\/noindex> \u2014 dat is trouwens een geweldige manier van massaal gegevens laden<\/a><\/noindex> en hier is een voorbeeld van een JSON-invoer<\/a><\/noindex> \u2014 in PostgreSQL 12 is de effici\u00ebntie van het inladen in gepartitioneerde tabellen ook verbeterd. Met COPY was het al snel, maar in PostgreSQL 12 gaat het echt razendsnel.<\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

WITH-queries zijn aanzienlijk verbeterd<\/h3>\n

<\/p>\n

Wanneer er is een patch toegepast voor ingebouwde algemene tabeluitdrukkingen<\/a><\/noindex> (ook wel CTE's, ook wel WITH-queries), ik kon niet wachten om een artikel te schrijven over hoe gelukkig de ontwikkelaars van applicaties waren met PostgreSQL<\/a><\/noindex>. Dit is een van die functies die de applicatie zullen versnellen. Tenminste, als je CTE gebruikt.<\/p>\n

<\/p>\n

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<\/em> CTE en de prestaties te verbeteren. Nu is alles anders.<\/p>\n

<\/p>\n

PostgreSQL 12 laat je een bepaald type CTE zonder bijwerkingen inbedden (SELECT<\/code>), dat maar \u00e9\u00e9n 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.<\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

Just-in-Time (JIT) \u2014 is nu standaard<\/h3>\n

<\/p>\n

In PostgreSQL 12-systemen met ondersteuning voor LLVM<\/a><\/noindex> is JIT-compilatie standaard ingeschakeld. Ten eerste krijg je ondersteuning voor JIT<\/a><\/noindex> voor sommige interne bewerkingen, en ten tweede kunnen queries met expressies (het eenvoudigste voorbeeld \u2014 x + y) in de select-lijsten (die je na SELECT plaatst), aggregaten, expressies met WHERE-voorwaarden en anderen JIT gebruiken voor prestatieverbetering.<\/p>\n

<\/p>\n

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.<\/p>\n

<\/p>\n

En wat met de andere nieuwe functies van PostgreSQL 12?<\/h3>\n

<\/p>\n

PostgreSQL 12 heeft een aantal nieuwe geweldige functies \u2014 van de mogelijkheid om JSON-gegevens te verkennen met behulp van standaard SQL\/JSON paduitdrukkingen tot multifactor-authenticatie met de optie clientcert=verify-full<\/code>, generatie van kolommen en nog veel meer. Genoeg voor een aparte post.<\/p>\n

<\/p>\n

Net als PostgreSQL 10 zal PostgreSQL 12 de algehele prestaties onmiddellijk na de upgrade verbeteren. Je kunt natuurlijk je eigen pad hebben \u2014 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.<\/p>\n

Bron: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

PostgreSQL 12, \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u044f\u044f \u0432\u0435\u0440\u0441\u0438\u044f \u00ab\u043b\u0443\u0447\u0448\u0435\u0439 \u0432 \u043c\u0438\u0440\u0435 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u043c \u043a\u043e\u0434\u043e\u043c\u00bb, \u0432\u044b\u0445\u043e\u0434\u0438\u0442 \u0447\u0435\u0440\u0435\u0437 \u043f\u0430\u0440\u0443-\u0442\u0440\u043e\u0439\u043a\u0443 \u043d\u0435\u0434\u0435\u043b\u044c (\u0435\u0441\u043b\u0438 \u0432\u0441\u0435 \u043f\u043e\u0439\u0434\u0435\u0442 \u043f\u043e \u043f\u043b\u0430\u043d\u0443). \u042d\u0442\u043e \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u0435\u0442 \u043e\u0431\u044b\u0447\u043d\u043e\u043c\u0443 \u0440\u0430\u0441\u043f\u0438\u0441\u0430\u043d\u0438\u044e \u2014 \u043d\u043e\u0432\u0430\u044f \u0432\u0435\u0440\u0441\u0438\u044f \u0441 \u0443\u0439\u043c\u043e\u0439 \u043d\u043e\u0432\u044b\u0445 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0435\u0439 \u0432\u044b\u0445\u043e\u0434\u0438\u0442 \u0440\u0430\u0437 \u0432 \u0433\u043e\u0434, \u0438, \u0447\u0435\u0441\u0442\u043d\u043e \u0433\u043e\u0432\u043e\u0440\u044f, \u044d\u0442\u043e \u0432\u043f\u0435\u0447\u0430\u0442\u043b\u044f\u0435\u0442. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u044f \u0438 \u0441\u0442\u0430\u043b \u0430\u043a\u0442\u0438\u0432\u043d\u044b\u043c \u0447\u043b\u0435\u043d\u043e\u043c \u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u0430 PostgreSQL. \u041f\u043e-\u043c\u043e\u0435\u043c\u0443, \u0432 \u043e\u0442\u043b\u0438\u0447\u0438\u0435 \u043e\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28500,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37975","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Upgrade voor luie mensen: hoe PostgreSQL 12 de prestaties verbetert | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u043f\u0433\u0440\u0435\u0439\u0434 \u0434\u043b\u044f \u043b\u0435\u043d\u0438\u0432\u044b\u0445: \u043a\u0430\u043a PostgreSQL 12 \u043f\u043e\u0432\u044b\u0448\u0430\u0435\u0442 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c | ProHoster","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:20:56+00:00","article:modified_time":"2019-10-31T19:20:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37975","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 19:59:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:17:22","updated":"2026-01-23 19:59:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/37975","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=37975"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/37975\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/28500"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=37975"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=37975"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=37975"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}