{"id":79039,"date":"2020-04-23T19:43:26","date_gmt":"2020-04-23T17:43:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql"},"modified":"2020-04-23T19:43:26","modified_gmt":"2020-04-23T17:43:26","slug":"ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","title":{"rendered":"Spar penge p\u00e5 store m\u00e6ngder i PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Forts\u00e6ttende emnet om registrering af store datastreams, som blev rejst i den tidligere artikel om partitionering<\/a><\/noindex>, vil vi i denne se p\u00e5 metoderne, som kan reducere den \"fysiske\" st\u00f8rrelse af det gemte<\/b> i PostgreSQL, og deres indflydelse p\u00e5 serverens ydeevne.<\/p>\n

Vi vil tale om TOAST-indstillinger og datajustering<\/b>. \"I gennemsnit\" vil disse metoder ikke spare for mange ressourcer, men de kr\u00e6ver slet ingen \u00e6ndringer af applikationens kode.<\/p>\n

\"Spar
\nVores erfaring har dog vist sig at v\u00e6re ret produktiv i denne henseende, da opbevaringen af n\u00e6sten enhver overv\u00e5gning i sin natur er st\u00f8rstedelen append-only<\/b> set fra dataskrivning. Og hvis du er nysgerrig efter, hvordan man kan l\u00e6re databasen at skrive til disk med 200MB\/s<\/b> halv st\u00f8rrelse \u2014 er du velkommen under cut.
\n<\/a><\/noindex><\/p>\n

Sm\u00e5 hemmeligheder fra store data<\/h2>\n

\nI forhold til vores services profil<\/a><\/noindex>, modtager den regelm\u00e6ssigt fra loggene tekstpakker<\/b>.<\/p>\n

Og da SBIS-systemet<\/a><\/noindex>, hvis databaser vi overv\u00e5ger, er et flerkomponentprodukt med komplekse datastrukturer, s\u00e5 bliver foresp\u00f8rgslerne for at opn\u00e5 maksimal ydeevne<\/b> ret meget \"flertoml\u00e6kker\" med kompleks algoritmisk logik.<\/a><\/noindex>S\u00e5 st\u00f8rrelsen af hver enkelt instans af foresp\u00f8rgslen eller den resulterende udf\u00f8relsesplan, der n\u00e5r os i loggen, viser sig at v\u00e6re \"i gennemsnit\" ret stor.<\/p>\n

Lad os se p\u00e5 strukturen af en af tabellerne, hvor vi skriver \"r\u00e5\" data \u2014 alts\u00e5 den originale tekst fra logregistreringen:<\/p>\n

CREATE TABLE rawdata_orig(\n  pack -- PK\n    uuid NOT NULL\n, recno -- PK\n    smallint NOT NULL\n, dt -- sektionens n\u00f8gle\n    date\n, data -- det vigtigste\n    text\n, PRIMARY KEY(pack, recno)\n);<\/code><\/pre>\n
\nEn typisk tabel (allerede partitioneret, uden tvivl, derfor er dette en skabelon til sektion), hvor det vigtigste er teksten. Nogle gange ret omfattende.<\/p>\n
Lad os huske, at den \"fysiske\" st\u00f8rrelse af en post i PG ikke kan overstige \u00e9n datagruppe, men den \"logiske\" st\u00f8rrelse er en helt anden sag. For at skrive en stor v\u00e6rdi (varchar\/text\/bytea) i et felt anvendes TOAST-teknologien.<\/a><\/noindex>:<\/p>\n
PostgreSQL bruger en fast sidest\u00f8rrelse (normalt 8 KB) og tillader ikke, at tupler optager mere end \u00e9n side. Derfor kan meget store feltv\u00e6rdier ikke gemmes direkte. For at overvinde denne begr\u00e6nsning komprimeres og\/eller opdeles store feltv\u00e6rdier i flere fysiske r\u00e6kker. Dette sker uset for brugeren og p\u00e5virker kun en lille del af serverkoden. Denne metode er kendt som TOAST \u2026<\/p><\/blockquote>\n
\nFaktisk oprettes der automatisk et par af tabeller med \"potentielt store\" felter en \"skiver\"<\/a><\/noindex> for hver \"stor\" post segmenteret i 2KB:<\/p>\n
TOAST(\n  chunk_id\n    integer\n, chunk_seq\n    integer\n, chunk_data\n    bytea\n, PRIMARY KEY(chunk_id, chunk_seq)\n);<\/code><\/pre>\n
\nDet vil sige, at hvis vi skal gemme en r\u00e6kke med en \"stor\" v\u00e6rdi data<\/code>, s\u00e5 vil den faktiske optagelse ske ikke kun i hovedtabellen og dens PK, men ogs\u00e5 i TOAST og dens PK<\/b>.<\/p>\n
Reducer TOAST-p\u00e5virkningen<\/h4>\n
\nMen st\u00f8rstedelen af vores poster er trods alt ikke s\u00e5 store, de burde kunne v\u00e6re inden for 8KB<\/b> \u2014 hvordan kan vi spare p\u00e5 dette?..<\/p>\n
Her kommer attributten STORAGE<\/code><\/a><\/noindex> for kolonnen i tabellen os til hj\u00e6lp:<\/p>\n
\n