{"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\/it\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","title":{"rendered":"Risparmiamo sui grandi volumi in PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Continuando il tema della registrazione di grandi flussi di dati, sollevato dall'articolo precedente sul partizionamento<\/a><\/noindex>, in questo esamineremo i metodi attraverso i quali \u00e8 possibile ridurre la dimensione \"fisica\" dei dati salvati<\/b> in PostgreSQL e il loro impatto sulle prestazioni del server.<\/p>\n

Parleremo di impostazioni TOAST e allineamento dei dati<\/b>. \"In media\", questi metodi consentiranno di risparmiare non troppi risorse, ma \u2014 senza modificare il codice dell'applicazione.<\/p>\n

\"Risparmiamo
\nTuttavia, la nostra esperienza si \u00e8 rivelata piuttosto produttiva in questo senso, poich\u00e9 lo storage di quasi qualsiasi monitoraggio \u00e8 per sua natura per lo pi\u00f9 append-only<\/b> per quanto riguarda i dati registrati. E se siete interessati a come si pu\u00f2 insegnare al database a scrivere su disco invece di 200MB\/s<\/b> la met\u00e0 \u2014 vi invito sotto.
\n<\/a><\/noindex><\/p>\n

Piccoli segreti dei big data<\/h2>\n

\nPer il profilo di lavoro del nostro servizio<\/a><\/noindex>, riceve regolarmente dai log pacchetti di testo<\/b>.<\/p>\n

E poich\u00e9 il complesso SBIS<\/a><\/noindex>, i cui database monitoriamo, \u00e8 un prodotto multi-componente con strutture dati complesse, le query per raggiungere le massime prestazioni<\/b> risultano piuttosto simili \u00abmultivolume\u00bb con logica algoritmica complessa<\/a><\/noindex>. Quindi, anche il volume di ciascun singolo esemplare della richiesta o del piano di esecuzione risultante nel nostro log risulta essere \u00abin media\u00bb piuttosto grande.<\/p>\n

Esaminiamo la struttura di una delle tabelle in cui scriviamo i dati \u00abgrezzi\u00bb \u2014 cio\u00e8 il testo originale della registrazione del log:<\/p>\n

CREATE TABLE rawdata_orig(\n  pack -- PK\n    uuid NOT NULL\n, recno -- PK\n    smallint NOT NULL\n, dt -- chiave di sezione\n    date\n, data -- la cosa pi\u00f9 importante\n    text\n, PRIMARY KEY(pack, recno)\n);<\/code><\/pre>\n
\nUna tabella tipica (gi\u00e0 partizionata, naturalmente, quindi questo \u00e8 un modello di sezione), dove la cosa pi\u00f9 importante \u00e8 il testo. A volte piuttosto voluminoso.<\/p>\n
Ricordiamo che la dimensione \u00abfisica\u00bb di una registrazione in PG non pu\u00f2 occupare pi\u00f9 di una pagina di dati, mentre la dimensione \u00ablogica\u00bb \u00e8 un'altra questione. Per memorizzare un valore voluminoso nel campo (varchar\/text\/bytea) si utilizza la tecnologia TOAST<\/a><\/noindex>:<\/p>\n
PostgreSQL utilizza una dimensione di pagina fissa (di solito 8 KB) e non consente ai tuple di occupare pi\u00f9 pagine. Pertanto, non \u00e8 possibile memorizzare direttamente valori molto grandi nei campi. Per superare questo limite, i valori di campo pi\u00f9 grandi vengono compressi e\/o suddivisi in pi\u00f9 righe fisiche. Questo avviene in modo trasparente per l'utente e influisce in modo trascurabile sulla maggior parte del codice del server. Questo metodo \u00e8 noto come TOAST \u2026<\/p><\/blockquote>\n
\nInfatti, per ogni tabella con campi \"potenzialmente grandi\" viene automaticamente creata una tabella parallela con la \"fetta\"<\/a><\/noindex> di ogni registrazione \"grande\" segmentata in pezzi da 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
\nCio\u00e8, se dobbiamo scrivere una riga con un valore \"grande\" data<\/code>, la scrittura reale avverr\u00e0 non solo nella tabella principale e nel suo PK, ma anche in TOAST e nel suo PK<\/b>.<\/p>\n
Riduciamo l'impatto del TOAST<\/h4>\n
\nMa la maggior parte delle registrazioni non \u00e8 poi cos\u00ec grande, dovrebbero rientrare in 8KB<\/b> \u2014 come possiamo risparmiare su questo?..<\/p>\n
Qui ci aiuta l'attributo STORAGE<\/code><\/a><\/noindex> della colonna della tabella:<\/p>\n
\n