{"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\/da\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","title":{"rendered":"Opgradering til dovne: hvordan PostgreSQL 12 forbedrer ydeevnen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Opgradering<\/p>\n

PostgreSQL 12<\/a><\/noindex>, den nyeste version af \"verdens bedste relationsdatabase med \u00e5ben kildekode\" lanceres om et par uger (hvis alt g\u00e5r som planlagt). Dette passer til den s\u00e6dvanlige tidsplan \u2014 en ny version med masser af nye funktioner udgives hvert \u00e5r, og \u00e6rligt talt er det imponerende. Derfor blev jeg en aktiv medlem af PostgreSQL-f\u00e6llesskabet.<\/p>\n

<\/p>\n

Efter min mening indeholder PostgreSQL 12, i mods\u00e6tning til tidligere versioner, ikke en eller to revolutionerende funktioner (som f.eks. partitionering eller foresp\u00f8rgsels parallellisering). Jeg sp\u00f8gte engang med, at den st\u00f8rste funktion i PostgreSQL 12 er st\u00f8rre stabilitet. Er det ikke netop det, man har brug for, n\u00e5r man h\u00e5ndterer kritiske data for sin virksomhed?<\/p>\n

<\/p>\n

Men PostgreSQL 12 stopper ikke der: med de nye funktioner og forbedringer vil applikationerne fungere bedre, og alt hvad du beh\u00f8ver at g\u00f8re, er at opgradere!<\/em><\/p>\n

<\/p>\n

(N\u00e5, m\u00e5ske ogs\u00e5 genopbygge indekserne, men i denne udgivelse er det ikke s\u00e5 slemt, som vi er vant til.)<\/p>\n

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

Det vil v\u00e6re fantastisk \u2014 at opgradere til PostgreSQL og straks nyde betydelige forbedringer uden un\u00f8dvendige anstrengelser. For nogle \u00e5r siden analyserede jeg opdateringen fra PostgreSQL 9.4 til PostgreSQL 10 og s\u00e5, hvordan applikationen blev hurtigere takket v\u00e6re den forbedrede foresp\u00f8rgsels parallellisering i PostgreSQL 10. Og vigtigst af alt, der blev n\u00e6sten ikke kr\u00e6vet noget fra mig (bare indstille en konfigurationsparameter, max_parallel_workers<\/code>).<\/p>\n

<\/p>\n

Enig, det er praktisk, n\u00e5r applikationerne fungerer bedre lige efter opgraderingen. Og vi g\u00f8r virkelig vores bedste for at gl\u00e6de brugerne, da der bliver flere og flere af dem, der bruger PostgreSQL.<\/p>\n

<\/p>\n

Og hvordan en enkel opgradering til PostgreSQL 12 vil g\u00f8re dig glad? Det vil jeg nu fort\u00e6lle om.<\/p>\n

<\/p>\n

Betydelige forbedringer i indeksering<\/h3>\n

<\/p>\n

Uden indeksering kommer databasen ikke langt. Hvordan kan man ellers hurtigt finde information? Det fundamentale indekseringssystem i PostgreSQL kaldes B-tr\u00e6<\/a><\/noindex>. Denne type indeks er optimeret til lagringssystemer.<\/p>\n

<\/p>\n

Vi bruger blot operatoren CREATE INDEX ON some_table (some_column)<\/code>, og PostgreSQL udf\u00f8rer det store arbejde med at holde indekset aktuelt, mens vi konstant inds\u00e6tter, opdaterer og sletter v\u00e6rdier. Alt fungerer af sig selv, som ved magi.<\/p>\n

<\/p>\n

Men indekserne i PostgreSQL har \u00e9t problem \u2014 de vokser.<\/a><\/noindex> og optager un\u00f8dvendig plads p\u00e5 disken, og ydeevnen ved dataudtr\u00e6kning og opdatering falder. Med \"opbl\u00e6sning\" henviser jeg til ineffektiv vedligeholdelse af indeksstrukturen. Dette kan v\u00e6re \u2014 eller ikke v\u00e6re \u2014 forbundet med affaldstuplet, som fjernes VACUUM<\/a><\/noindex> (tak for informationen til Peter Geoghegan (Peter Geoghegan<\/a><\/noindex>)). Opbl\u00e6sning af indekset er is\u00e6r m\u00e6rkbar i arbejdsbelastninger, hvor indekset aktivt \u00e6ndres.<\/p>\n

<\/p>\n

PostgreSQL 12 forbedrer markant ydeevnen af B-tr\u00e6 indeks, og eksperimenter med TPC-C tests har vist, at pladsen nu anvendes, i gennemsnit, 40% mindre. Vi bruger nu mindre tid ikke kun p\u00e5 vedligeholdelse af B-tr\u00e6 indekser (dvs. skriveoperationer), men ogs\u00e5 p\u00e5 dataudtr\u00e6kning, da indekserne er blevet meget mindre.<\/p>\n

<\/p>\n

Applikationer, der aktivt opdaterer deres tabeller \u2014 typisk OLTP-applikationer (online transaction processing<\/a><\/noindex>) \u2014 vil langt mere effektivt bruge disken og behandle foresp\u00f8rgsler. Jo mere plads der er p\u00e5 disken, jo mere plads har databasen til at vokse uden opgradering af infrastrukturen.<\/p>\n

<\/p>\n

Nogle opgraderingsstrategier kr\u00e6ver, at B-tr\u00e6 indekserne genopbygges for at drage fordel af disse fordele (f.eks. pg_upgrade<\/a><\/noindex> genopbygger ikke indeksene automatisk). I tidligere versioner af PostgreSQL f\u00f8rte genopbygning af store indekser i tabeller til betydelige nedetider, da \u00e6ndringer ikke kunne foretages i mellemtiden. Men i PostgreSQL 12 er der endnu en fantastisk funktion: nu kan indekser genopbygges parallelt med kommandoen REINDEX CONCURRENTLY<\/a><\/noindex>, s\u00e5 man helt undg\u00e5r nedetid.<\/p>\n

<\/p>\n

PostgreSQL 12 har ogs\u00e5 andre forbedringer i indekseringsinfrastrukturen. Endnu en ting, hvor magi ikke udeblev, er forh\u00e5ndsskrivningslog<\/a><\/noindex>, ogs\u00e5 kaldet WAL (write-ahead log). Forh\u00e5ndsskrivningsloggen registrerer hver transaktion i PostgreSQL i tilf\u00e6lde af fejl og replikering. Applikationer bruger den til arkivering og gendannelse til et bestemt tidspunkt<\/a><\/noindex>. Selvf\u00f8lgelig skrives forh\u00e5ndsskrivningsloggen til disken, hvilket kan p\u00e5virke ydeevnen.<\/p>\n

<\/p>\n

I PostgreSQL 12 er omkostningerne for WAL-poster, der genereres af GiST-, GIN- og SP-GiST-indekserne, blevet reduceret ved opbygningen af indekser. Dette giver flere m\u00e6rkbare fordele: WAL-posterne fylder mindre p\u00e5 disken, og dataene genoprettes hurtigere, for eksempel under fejlgendannelse eller gendannelse til et tidspunkt. Hvis du bruger s\u00e5danne indekser i dine applikationer (for eksempel de geospatiale applikationer baseret p\u00e5 PostGIS bruger meget GiST-indekset), er det endnu en funktion, der vil forbedre ydeevnen uden nogen anstrengelse fra din side.<\/p>\n

<\/p>\n

Partitionering \u2014 mere, bedre, hurtigere<\/h3>\n

<\/p>\n

I PostgreSQL 10 blev der introduceret deklarativ partitionering<\/a><\/noindex>. I PostgreSQL 11 blev det meget nemmere at bruge. I PostgreSQL 12 kan sektionernes st\u00f8rrelse \u00e6ndres.<\/p>\n

<\/p>\n

I PostgreSQL 12 er ydeevnen for partitionssystemet blevet betydeligt bedre, is\u00e6r hvis tabellen har tusindvis af sektioner. For eksempel, hvis en foresp\u00f8rgsel kun ber\u00f8rer et par sektioner i en tabel med tusindvis, vil den blive udf\u00f8rt meget hurtigere. Ydeevnen er forbedret ikke kun for s\u00e5danne typer foresp\u00f8rgsler. Du vil ogs\u00e5 bem\u00e6rke, hvordan INSERT-operationer i tabeller med mange sektioner er blevet hurtigere.<\/p>\n

<\/p>\n

Datainds\u00e6tning ved hj\u00e6lp af COPY<\/a><\/noindex> \u2014 for resten, dette er en fantastisk m\u00e5de til masseindl\u00e6sning af data<\/a><\/noindex> og her er et eksempel p\u00e5 JSON<\/a><\/noindex> \u2014 i partitionsbaserede tabeller er blevet mere effektiv i PostgreSQL 12. Med COPY var det allerede hurtigt, men i PostgreSQL 12 er det virkelig hurtigt.<\/p>\n

<\/p>\n

Takket v\u00e6re disse fordele kan PostgreSQL gemme datas\u00e6t af endnu st\u00f8rre st\u00f8rrelse, og det er blevet lettere at hente dem. Og ingen anstrengelse fra din side. Hvis din applikation har mange sektioner, for eksempel hvis den indl\u00e6ser tidsseriedata, vil en simpel opgradering forbedre dens ydeevne betydeligt.<\/p>\n

<\/p>\n

Og selvom denne forbedring ikke helt falder ind under kategorien 'vi opgraderede og gl\u00e6der os', kan man i PostgreSQL 12 oprette fremmedn\u00f8gler, der refererer til partitionsbaserede tabeller, s\u00e5 arbejdet med partitionering bliver en forn\u00f8jelse.<\/p>\n

<\/p>\n

WITH-foresp\u00f8rgsler er blevet meget bedre<\/h3>\n

<\/p>\n

N\u00e5r en patch til indbyggede generiske tabeludtryk er blevet anvendt<\/a><\/noindex> (de kaldes ogs\u00e5 CTE, ogs\u00e5 kaldet WITH-foresp\u00f8rgsler), og jeg kunne ikke vente med at skrive en artikel om, hvordan app-udviklerne med PostgreSQL var glade.<\/a><\/noindex>. Dette er en af de funktioner, der vil fremskynde applikationen. Hvis du selvf\u00f8lgelig bruger CTE.<\/p>\n

<\/p>\n

Jeg bem\u00e6rker ofte, at nybegyndere med SQL elsker at bruge CTE: hvis de skrives p\u00e5 en bestemt m\u00e5de, f\u00f8les det faktisk, som om man skriver et imperativt program. Personligt kunne jeg lide at omskrive disse foresp\u00f8rgsler for at undg\u00e5 uden<\/em> CTE og \u00f8ge ydeevnen. Nu er alt anderledes.<\/p>\n

<\/p>\n

PostgreSQL 12 g\u00f8r det muligt at indlejre en bestemt type CTE uden bivirkninger (SELECT<\/code>), som kun anvendes \u00e9n gang t\u00e6ttere p\u00e5 slutningen af foresp\u00f8rgslen. Hvis jeg havde f\u00f8rt statistik over CTE-foresp\u00f8rgsler, som jeg har omskrevet, ville de fleste af dem v\u00e6re i denne kategori. Det hj\u00e6lper udviklere med at skrive forst\u00e5elig kode, der nu ogs\u00e5 k\u00f8rer hurtigt.<\/p>\n

<\/p>\n

Desuden optimerer PostgreSQL 12 udf\u00f8relsen af SQL selv, s\u00e5 du beh\u00f8ver ikke at g\u00f8re noget. Og selvom jeg sikkert ikke l\u00e6ngere beh\u00f8ver at optimere s\u00e5danne foresp\u00f8rgsler, er det godt, at PostgreSQL forts\u00e6tter med at arbejde p\u00e5 optimering af foresp\u00f8rgsler.<\/p>\n

<\/p>\n

Just-in-Time (JIT) - nu som standard<\/h3>\n

<\/p>\n

I systemer med PostgreSQL 12, der underst\u00f8tter LLVM<\/a><\/noindex> JIT-kompilering er aktiveret som standard. For det f\u00f8rste f\u00e5r du st\u00f8tte til JIT<\/a><\/noindex> til nogle interne operationer, og for det andet kan foresp\u00f8rgsler med udtryk (det enkleste eksempel er x + y) i udvalgslisterne (som st\u00e5r efter SELECT), aggregeringer, udtryk med WHERE-klausuler og andre bruge JIT til ydeevneforbedringer.<\/p>\n

<\/p>\n

Da JIT er aktiveret som standard i PostgreSQL 12, vil ydeevnen forbedres automatisk, men jeg anbefaler at teste applikationen i PostgreSQL 11, hvor JIT lige er blevet introduceret, for at m\u00e5le ydeevnen for foresp\u00f8rgsler og finde ud af, om der er behov for justeringer.<\/p>\n

<\/p>\n

Hvad med de \u00f8vrige nye funktioner i PostgreSQL 12?<\/h3>\n

<\/p>\n

PostgreSQL 12 har en masse nye sp\u00e6ndende funktioner - fra muligheden for at arbejde med JSON-data ved hj\u00e6lp af standard SQL\/JSON ruteudtryk til multifaktorautentifikation med parameteren clientcert=verify-full<\/code>, genererede kolonner og meget mere. Det er nok til et separat indl\u00e6g.<\/p>\n

<\/p>\n

Ligesom PostgreSQL 10 vil PostgreSQL 12 straks forbedre den samlede ydeevne efter opgraderingen. Du har selvf\u00f8lgelig din egen vej - test applikationen under lignende forhold i dit produktionssystem, f\u00f8r du aktiverer forbedringerne, som jeg gjorde med PostgreSQL 10. Selvom PostgreSQL 12 allerede nu er mere stabil, end jeg havde antaget, s\u00e5 lad v\u00e6re med at spare p\u00e5 den grundige test af applikationerne, f\u00f8r du sender dem i produktion.<\/p>\n

Kilde: 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\udd47Opgradering for dovne: hvordan PostgreSQL 12 forbedrer ydeevnen | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/37975","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=37975"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/37975\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/28500"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=37975"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=37975"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=37975"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}