{"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\/et\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","title":{"rendered":"Kogume kokku v\u00e4ikese raha suuremate mahtude puhul PostgreSQL-is","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

J\u00e4tkates teemat suurte andmevoogude salvestamisest, t\u00f5statatud eelnevas artiklis sektsioneerimise kohta<\/a><\/noindex>, vaatleme selles, kuidas v\u00e4heneda \u201ef\u00fc\u00fcsilist\u201c suurust salvestatud<\/b> PostgreSQL-is ja nende m\u00f5ju serveri tulemuslikkusele.<\/p>\n

Jutt l\u00e4heb TOAST seadistustest ja andmete joondamisest<\/b>. \u201eKeskmiselt\u201d v\u00f5imaldavad need meetodid s\u00e4\u00e4sta mitte liiga palju ressursse, kuid \u2014 t\u00e4iesti ilma rakenduskoodi modifitseerimiseta.<\/p>\n

\"Kogume
\nKuid meie kogemus osutus selles osas \u00fcsna produktiivseks, kuna praktiliselt iga j\u00e4lgimise salvestus on oma olemuselt suurel m\u00e4\u00e4ral ainult append-only<\/b> salvestatavate andmete osas. Ja kui teid huvitab, kuidas \u00f5petada andmebaasi kirjutama kettale asemel 200 MB\/s<\/b> kaks korda v\u00e4hem \u2014 tulge edasi.
\n<\/a><\/noindex><\/p>\n

Suurte andmete v\u00e4ikesed saladused<\/h2>\n

\nMeie teenuse profilatsiooni j\u00e4rgi<\/a><\/noindex>, saab regulaarselt logidelt tekstipakette<\/b>.<\/p>\n

Ja kuna SBIS kompleks<\/a><\/noindex>, kelle andmebaase me j\u00e4lgime, on mitmekomponendiline toode keeruliste andmestruktuuridega, siis on ka p\u00e4ringud maksimaalse tulemuslikkuse saavutamiseks<\/b> t\u00e4iesti sellised \u201emitme k\u00f6itega\u201c keerulise algoritmilise loogikaga<\/a><\/noindex>. Seega on iga individuaalse p\u00e4ringu v\u00f5i saadud t\u00e4itmisplaani maht meie logis \"keskmiselt\" piisavalt suur.<\/p>\n

Vaatame \u00fchte tabeli struktuuri, kuhu kirjutame \"tooreid\" andmeid \u2014 st originaalteksti logikirjest:<\/p>\n

CREATE TABLE rawdata_orig(\n  pack -- PK\n    uuid NOT NULL\n, recno -- PK\n    smallint NOT NULL\n, dt -- sektsiooni v\u00f5ti\n    date\n, data -- k\u00f5ige olulisem\n    text\n, PRIMARY KEY(pack, recno)\n);<\/code><\/pre>\n
\nT\u00fc\u00fcpiline selline tabel (juba seotud, loomulikult, seega on see \u2014 sektsiooni mall), kus k\u00f5ige olulisem on tekst. Kohati piisavalt mahukas.<\/p>\n
Kasutame meeles, et PG-s \u00fche kirje \"f\u00fc\u00fcsiline\" suurus ei saa \u00fcletada \u00fchte andmelehek\u00fclge, kuid \"loogiline\" suurus on sootuks teine asi. Mahuliste v\u00e4\u00e4rtuste (varchar\/text\/bytea) salvestamiseks v\u00e4ljal kasutatakse tehnoloogiat TOAST<\/a><\/noindex>:<\/p>\n
PostgreSQL kasutab fikseeritud lehe suurust (tavaliselt 8 KB) ja ei luba tupletitel h\u00f5ivata mitut lehte. Seet\u00f5ttu ei saa v\u00e4ga suuri v\u00e4li v\u00e4\u00e4rtusi otse salvestada. Selle piirangu \u00fcletamiseks surutakse suured v\u00e4li v\u00e4\u00e4rtused kokku ja\/v\u00f5i jagatakse mitmeks f\u00fc\u00fcsiliseks reale. See toimub kasutajale m\u00e4rkamatult ja m\u00f5jutab enamikku serveri koodist minimaalselt. Seda meetodit tuntakse TOAST …<\/p><\/blockquote>\n
\nTegelikult luuakse iga 'potentsiaalselt suure' v\u00e4lja tabeli jaoks automaatselt paarne tabel 't\u00fckeldamisega'<\/a><\/noindex> iga 'suure' kirje kohta segmentide kaupa 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
\nSee t\u00e4hendab, et kui peame kirjutama rea, millel on 'suur' v\u00e4\u00e4rtus data<\/code>, siis t\u00f5eline salvestamine toimub mitte ainult p\u00f5hitaotlemises ja selle PK-s, vaid ka TOAST-is ja selle PK-s<\/b>.<\/p>\n
V\u00e4hendame TOAST-i m\u00f5ju<\/h4>\n
\nKuid enamik kirjeid ei ole siiski nii suured, 8KB peaks olema piisav<\/b> \u2014 kuidas selle pealt kokku hoida?..<\/p>\n
Siin tuleb meile appi atribuut STORAGE<\/code><\/a><\/noindex> tabeli veerus:<\/p>\n
\n