{"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 qualche centesimo su grandi volumi con PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Continuando il tema della registrazione di grandi flussi di dati sollevato nell'articolo precedente sulla partizione<\/a><\/noindex>, in questo esamineremo i modi in cui \u00e8 possibile ridurre le dimensioni \"fisiche\" dei dati memorizzati<\/b> in PostgreSQL e il loro impatto sulle prestazioni del server.<\/p>\n

Si parler\u00e0 di impostazioni TOAST e allineamento dei dati<\/b>. \"In media\", questi metodi permetteranno un risparmio non troppo significativo di 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 ogni monitoraggio \u00e8 per sua natura per lo pi\u00f9 append-only<\/b> dal punto di vista dei dati scritti. E se siete interessati a sapere come si pu\u00f2 insegnare al database a scrivere su disco invece di 200MB\/s<\/b> in met\u00e0 \u2014 vi invito a continuare a leggere.
\n<\/a><\/noindex><\/p>\n

Piccole segrete sui grandi dati<\/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>le cui basi dati monitoriamo, \u00e8 un prodotto multi-componente con strutture dati complesse, le richieste per raggiungere prestazioni massime<\/b> risultano piuttosto \"multivolumetriche\" con logiche algoritmiche complesse.<\/a><\/noindex>Quindi anche il volume di ciascun singolo esempio di richiesta o del piano di esecuzione risultante nel log che ci arriva risulta \"in media\" piuttosto grande.<\/p>\n

Diamo un'occhiata alla struttura di una delle tabelle in cui scriviamo i \"dati grezzi\" \u2014 ovvero il testo originale registrato nel 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, ovviamente, quindi questo \u00e8 un modello di sezione), dove la cosa pi\u00f9 importante \u00e8 il testo. A volte \u00e8 abbastanza voluminoso.<\/p>\n
Ricordiamo che la dimensione \"fisica\" di una registrazione in PG non pu\u00f2 occupare pi\u00f9 di una pagina di dati, ma la dimensione \"logica\" \u00e8 tutta un'altra cosa. Per scrivere un valore voluminoso in un campo (varchar\/text\/bytea) si utilizza la tecnologia TOAST<\/a><\/noindex>:<\/p>\n
PostgreSQL utilizza una dimensione di pagina fissa (solitamente 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 questa limitazione, i valori di campo grandi vengono compressi e\/o suddivisi in pi\u00f9 righe fisiche. Questo avviene in modo trasparente per l'utente e influisce solo lievemente su gran parte del codice del server. Questo metodo \u00e8 noto come TOAST ...<\/p><\/blockquote>\n
\nIn effetti, per ogni tabella con campi \"potenzialmente grandi\" viene automaticamente creata una tabella ausiliaria con \"segmentazione\"<\/a><\/noindex> di ogni record \"grande\" in segmenti 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 registrazione 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'influenza di TOAST<\/h4>\n
\nMa la maggior parte dei record non \u00e8 comunque cos\u00ec grande, devono rimanere entro 8KB<\/b> \u2014 come possiamo risparmiare su questo?..<\/p>\n
Qui ci viene in aiuto l'attributo STORAGE<\/code><\/a><\/noindex> per la colonna della tabella:<\/p>\n
\n