{"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\/nl\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","title":{"rendered":"Bespaar een beetje geld op grote hoeveelheden in PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Het onderwerp van het vastleggen van grote gegevensstromen, dat in het vorige artikel over partitionering werd aangesneden,<\/a><\/noindex>komt hier aan bod met manieren om de 'fysieke' omvang van opgeslagen<\/b> gegevens in PostgreSQL te verminderen en de impact daarvan op de serverprestaties.<\/p>\n

We gaan het hebben over TOAST-instellingen en dataverlies.<\/b>. 'Gemiddeld' zullen deze methodes niet veel middelen besparen, maar ze vereisen ook helemaal geen wijziging van de applicatiecode.<\/p>\n

\"Bespaar
\nOnze ervaring in dit opzicht is echter zeer productief gebleken, aangezien de opslag voor vrijwel elke monitoring van nature grotendeels append-only<\/b> is met betrekking tot de gegevens die worden geschreven. En als je je afvraagt hoe je de database kunt leren om op een snelheid van 200MB\/s<\/b> de helft minder te schrijven - lees dan verder.
\n<\/a><\/noindex><\/p>\n

Kleine geheimen van grote data<\/h2>\n

\nVanwege het type werk van onze service, ontvangt het regelmatig tekstpakketten uit de logs.<\/a><\/noindex>Aangezien het gecombineerde systeem van SBIS,<\/b>.<\/p>\n

wiens databases we controleren, een veelzijdig product met complexe datastructuren is, zijn de verzoeken om maximale prestaties te bereiken<\/a><\/noindex>soms echt 'multi-volume' met complexe algoritmische logica.<\/b> Het resultaat is dat de omvang van elk afzonderlijk exemplaar van een verzoek of uitvoeringsplan in de door ons ontvangen logs 'gemiddeld' behoorlijk groot is. Laten we eens kijken naar de structuur van een van de tabellen waarin we 'rauwe' gegevens schrijven - dat wil zeggen de originele tekst uit de logregistratie:<\/a><\/noindex>CREATE TABLE rawdata_orig(\n pack -- PK\n uuid NOT NULL\n, recno -- PK\n smallint NOT NULL\n, dt -- sectiesleutel\n date\n, data -- het allerbelangrijkste\n text\n, PRIMARY KEY(pack, recno)\n);<\/p>\n

Een typische tabel (al gepartitioneerd, uiteraard, dus dit is een sectiesjabloon), waarbij de tekst het belangrijkste is. Soms behoorlijk omvangrijk.<\/p>\n

Vergeet niet dat de 'fysieke' omvang van een record in PG niet groter kan zijn dan \u00e9\u00e9n datablok, maar de 'logische' omvang - dat is een heel ander verhaal. Om een volumineuze waarde (varchar\/text\/bytea) in een veld op te slaan, wordt<\/code><\/pre>\n
\nde TOAST-technologie gebruikt.<\/p>\n
Laten we ons herinneren dat de \"fysieke\" grootte van een record in PG niet meer dan \u00e9\u00e9n gegevenspagina mag innemen, maar de \"logische\" grootte is iets heel anders. Om een grote waarde in een veld (varchar\/text\/bytea) op te slaan, wordt er gebruik gemaakt van de TOAST-technologie<\/a><\/noindex>:<\/p>\n
PostgreSQL gebruikt een vaste paginagrootte (meestal 8 KB) en staat niet toe dat tuples meerdere pagina's in beslag nemen. Daarom is het niet mogelijk om zeer grote waardevelden direct op te slaan. Om deze beperking te omzeilen, worden grote waardevelden gecomprimeerd en\/of verdeeld over meerdere fysieke rijen. Dit gebeurt onopgemerkt voor de gebruiker en heeft slechts een geringe impact op het grootste deel van de servercode. Deze methode staat bekend als TOAST \u2026<\/p><\/blockquote>\n
\nIn feite wordt er automatisch voor elke tabel met \"potentieel grote\" velden een bijbehorende tabel aangemaakt met \"snedes\"<\/a><\/noindex> van elke \"grote\" opname in segmenten van 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
\nDat wil zeggen, als we een rij met een \"groot\" waarde moeten opslaan, data<\/code>zal de werkelijke opname plaatsvinden niet alleen in de hoofdtafel en zijn PK, maar ook in TOAST en zijn PK.<\/b>.<\/p>\n
De impact van TOAST verminderen<\/h4>\n
\nMaar de meeste opnames zijn nog steeds niet zo groot, moeten binnen 8KB passen<\/b> \u2014 hoe kunnen we hierop besparen?..<\/p>\n
Hier komt de attribuut STORAGE<\/code><\/a><\/noindex> van de kolom in de tabel ons te hulp:<\/p>\n
\n