{"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\/no\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","title":{"rendered":"Sparer penger p\u00e5 store volum i PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Fortsett med temaet for registrering av store datastreamer, tatt opp i den forrige artikkelen om partisjonering<\/a><\/noindex>, her ser vi p\u00e5 metodene for \u00e5 redusere den \u00abfysiske\u00bb st\u00f8rrelsen p\u00e5 lagret<\/b> i PostgreSQL, og deres innvirkning p\u00e5 serverytelsen.<\/p>\n

Det vil bli snakk om TOAST-innstillinger og datalignering<\/b>. \u00abI gjennomsnitt\u00bb vil disse metodene ikke spare s\u00e5 mye ressurser, men \u2014 helt uten modifikasjon av applikasjonskoden.<\/p>\n

\"Sparer
\nLikevel, v\u00e5r erfaring har vist seg \u00e5 v\u00e6re ganske produktiv p\u00e5 dette omr\u00e5det, ettersom lagringsl\u00f8sningen for nesten all overv\u00e5king i sin natur er for det meste append-only<\/b> n\u00e5r det gjelder de innspilte dataene. Og hvis du er interessert i hvordan du kan l\u00e6re databasen \u00e5 skrive til disk i stedet for 200MB\/s<\/b> halvparten s\u00e5 mye \u2014 vennligst les videre.
\n<\/a><\/noindex><\/p>\n

Sm\u00e5 hemmeligheter om store data<\/h2>\n

\nI profileringen av tjenesten v\u00e5r<\/a><\/noindex>, f\u00e5r den regelmessig tekstpakker fra loggene<\/b>.<\/p>\n

Og siden SBIS-systemet<\/a><\/noindex>, hvis databaser vi overv\u00e5ker, er et flerfaglig produkt med komplekse datamodeller, er foresp\u00f8rslene for \u00e5 oppn\u00e5 maksimal ytelse<\/b> helt klart \u00abflermoduls\u00bb med komplisert algoritmisk logikk<\/a><\/noindex>. S\u00e5 st\u00f8rrelsen p\u00e5 hver enkelt foresp\u00f8rsel eller den resulterende utf\u00f8relsesplanen i loggene som kommer til oss viser seg \u00e5 v\u00e6re \u00abi gjennomsnitt\u00bb ganske stor.<\/p>\n

La oss ta en titt p\u00e5 strukturen til en av tabellene hvor vi skriver \u00abr\u00e5\u00bb data \u2014 det vil si, den originale teksten fra loggoppf\u00f8ringen:<\/p>\n

CREATE TABLE rawdata_orig(\n  pack -- PK\n    uuid NOT NULL\n, recno -- PK\n    smallint NOT NULL\n, dt -- partisjonsn\u00f8kkel\n    date\n, data -- det viktigste\n    text\n, PRIMARY KEY(pack, recno)\n);<\/code><\/pre>\n
\nEn typisk tabell (allerede partisjonert, selvf\u00f8lgelig, s\u00e5 dette er en mal for partisjonen), der det viktigste er teksten. Noen ganger ganske omfattende.<\/p>\n
La oss huske at den \u00abfysiske\u00bb st\u00f8rrelsen p\u00e5 en post i PG ikke kan ta mer enn \u00e9n datakilde, men den \u00ablogiske\u00bb st\u00f8rrelsen er helt forskjellig. For \u00e5 skrive en stor verdi i et felt (varchar\/text\/bytea) brukes TOAST-teknologi<\/a><\/noindex>:<\/p>\n
PostgreSQL bruker en fast sidestr\u00f8rrelse (vanligvis 8 KB), og tillater ikke at tupler opptar flere sider. Derfor er det ikke mulig \u00e5 lagre veldig store feltverdier direkte. For \u00e5 omg\u00e5 denne begrensningen komprimeres og\/eller deles store feltverdier opp i flere fysiske rader. Dette skjer usynlig for brukeren og p\u00e5virker for det meste serverkoden lite. Denne metoden er kjent som TOAST \u2026<\/p><\/blockquote>\n
\nFaktisk, for hver tabell med \"potensielt store\" felt, opprettes automatisk en tilknyttede tabell med \"skiver\"<\/a><\/noindex> av hver \"stor\" post i segmenter p\u00e5 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 si, hvis vi m\u00e5 skrive en rad med et \"stort\" verdi data<\/code>, vil den faktiske innspillingen skje ikke bare i hovedtabellen og dens PK, men ogs\u00e5 i TOAST og dens PK<\/b>.<\/p>\n
Redusere TOAST-p\u00e5virkningen<\/h4>\n
\nMen de fleste postene v\u00e5re er likevel ikke s\u00e5 store, de burde passe inn i 8KB<\/b> \u2014 hvordan kan vi spare p\u00e5 dette?..<\/p>\n
Her kommer attributtet STORAGE<\/code><\/a><\/noindex> til hjelp i tabellkolonnen:<\/p>\n
\n