{"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\/ro\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","title":{"rendered":"Recent, am povestit cum, folosind re\u021bete standard, s\u0103 cre\u0219tem performan\u021ba interog\u0103rilor SQL \u201ela citire\u201d din.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Continu\u00e2nd tema \u00eenregistr\u0103rii fluxurilor mari de date, ridicat\u0103 \u00een articolul precedent despre sec\u021bionare<\/a><\/noindex>, \u00een acesta vom analiza modalit\u0103\u021bile prin care putem reduce \u201edimensiunea fizic\u0103\u201d a datelor stocate<\/b> \u00een PostgreSQL \u0219i influen\u021ba lor asupra performan\u021bei serverului.<\/p>\n

Vor fi discutate set\u0103rile TOAST \u0219i alinierea datelor<\/b>. \u201e\u00cen medie\u201d, aceste modalit\u0103\u021bi vor permite economisirea nu prea multor resurse, dar \u2014 f\u0103r\u0103 nicio modificare a codului aplica\u021biei.<\/p>\n

\"Recent,
\nCu toate acestea, experien\u021ba noastr\u0103 s-a dovedit a fi destul de productiv\u0103 \u00een acest sens, deoarece stocarea aproape oric\u0103rei monitoriz\u0103ri este, prin natura sa, \u00een cea mai mare parte, append-only<\/b> din punctul de vedere al datelor scrise. \u0218i dac\u0103 v\u0103 intereseaz\u0103 cum se poate \u00eenv\u0103\u021ba baza s\u0103 scrie pe disc \u00eentr-o vitez\u0103 de 200MB\/s<\/b> mult mai mic\u0103 \u2014 v\u0103 rog s\u0103 citi\u021bi \u00een continuare.
\n<\/a><\/noindex><\/p>\n

Secrete mici despre Big Data<\/h2>\n

\nConform profilului de activitate al serviciului nostru<\/a><\/noindex>, acesta prime\u0219te \u00een mod regulat din loguri pachete de text<\/b>.<\/p>\n

\u0218i deoarece complexul SBIS<\/a><\/noindex>, ale c\u0103rui baze de date le monitoriz\u0103m, este un produs multicomponent cu structuri complexe de date, cererile pentru a atinge performan\u021ba maxim\u0103<\/b> au devenit astfel \u201emultivoluminoase\u201d cu o logic\u0103 algeritmic\u0103 complex\u0103.<\/a><\/noindex>Astfel, volumul fiec\u0103rui exemplu de cerere sau al planului de execu\u021bie rezultat din logul care ne sose\u0219te este \u201e\u00een medie\u201d destul de mare.<\/p>\n

S\u0103 ne uit\u0103m la structura uneia dintre tabele, \u00een care scriem datele \u201eneprelucrate\u201d \u2014 adic\u0103 textul original din \u00eenregistrarea logului:<\/p>\n

CREATE TABLE rawdata_orig(\n  pack -- PK\n    uuid NOT NULL\n, recno -- PK\n    smallint NOT NULL\n, dt -- cheia sec\u021biunii\n    date\n, data -- cel mai important\n    text\n, PRIMARY KEY(pack, recno)\n);<\/code><\/pre>\n
\nEste o tabel\u0103 tipic\u0103 (deja sec\u021bionat\u0103, desigur, prin urmare acesta este un \u0219ablon de sec\u021biune), unde cel mai important este \u2014 textul. Uneori este destul de voluminos.<\/p>\n
S\u0103 ne amintim c\u0103 dimensiunea \u201efizic\u0103\u201d a unei \u00eenregistr\u0103ri \u00een PG nu poate ocupa mai mult de o pagin\u0103 de date, dar dimensiunea \u201elogic\u0103\u201d este o alt\u0103 poveste. Pentru a scrie o valoare voluminoas\u0103 \u00eentr-un c\u00e2mp (varchar\/text\/bytea) se utilizeaz\u0103 tehnologia TOAST<\/a><\/noindex>:<\/p>\n
PostgreSQL utilizeaz\u0103 o dimensiune fix\u0103 a paginii (de obicei 8 KB) \u0219i nu permite ca tuplurile s\u0103 ocupe mai multe pagini. Prin urmare, nu este posibil s\u0103 stoca\u021bi direct valori foarte mari ale c\u00e2mpurilor. Pentru a dep\u0103\u0219i aceast\u0103 limitare, valorile mari ale c\u00e2mpurilor sunt comprimate \u0219i\/sau fragmentate \u00een mai multe linii fizice. Acest lucru se \u00eent\u00e2mpl\u0103 f\u0103r\u0103 ca utilizatorul s\u0103 observe \u0219i afecteaz\u0103 \u00eentr-o m\u0103sur\u0103 nesemnificativ\u0103 majoritatea codului serverului. Aceast\u0103 metod\u0103 este cunoscut\u0103 sub numele de TOAST …<\/p><\/blockquote>\n
\nDe fapt, pentru fiecare tabel cu c\u00e2mpuri \u201epoten\u021bial mari\u201d, se creeaz\u0103 automat o tabel\u0103 suplimentar\u0103 cu \u201efelii\u201d<\/a><\/noindex> fiecare \u00eenregistrare \u201emare\u201d segmentat\u0103 \u00een buc\u0103\u021bi de 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
\nAsta \u00eenseamn\u0103 c\u0103, atunci c\u00e2nd trebuie s\u0103 scriem un r\u00e2nd cu o valoare \u201emare\u201d, data<\/code>\u00eenregistrarea real\u0103 va avea loc nu doar \u00een tabela principal\u0103 \u0219i cheia ei primar\u0103, ci \u0219i \u00een TOAST \u0219i cheia sa primar\u0103<\/b>.<\/p>\n
Reducerea impactului TOAST<\/h4>\n
\nDar majoritatea \u00eenregistr\u0103rilor noastre nu sunt at\u00e2t de mari, ar trebui s\u0103 se \u00eencadreze \u00een 8KB<\/b> \u2014 cum putem economisi pe acest lucru?..<\/p>\n
Aici ne ajut\u0103 atributul STORAGE<\/code><\/a><\/noindex> de la coloana tabelului:<\/p>\n
\n