{"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\/pt\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","title":{"rendered":"Economizando um pouco em grandes volumes no PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dando continuidade ao tema de registro de grandes fluxos de dados, levantado no artigo anterior sobre particionamento<\/a><\/noindex>, neste artigo vamos explorar m\u00e9todos para reduzir o tamanho \"f\u00edsico\" dos dados armazenados<\/b> no PostgreSQL e seu impacto no desempenho do servidor.<\/p>\n

Vamos falar sobre as configura\u00e7\u00f5es TOAST e o alinhamento de dados<\/b>. \"Em m\u00e9dia\", esses m\u00e9todos permitir\u00e3o economizar n\u00e3o muitos recursos, mas \u2014 sem qualquer modifica\u00e7\u00e3o no c\u00f3digo do aplicativo.<\/p>\n

\"Economizando
\nNo entanto, nossa experi\u00eancia foi bastante produtiva nesse aspecto, j\u00e1 que o armazenamento da maioria das monitoriza\u00e7\u00f5es \u00e9 em grande parte apenas append-only<\/b> no que diz respeito aos dados gravados. E se voc\u00ea est\u00e1 curioso sobre como fazer um banco escrever em disco em vez de 200MB\/s<\/b> metade disso \u2014 continue lendo.
\n<\/a><\/noindex><\/p>\n

Pequenos segredos de grandes dados<\/h2>\n

\nDe acordo com o perfil de trabalho do nosso servi\u00e7o<\/a><\/noindex>, ele recebe regularmente dos logs pacotes de texto<\/b>.<\/p>\n

E como o complexo SBIS<\/a><\/noindex>, cujos bancos de dados monitoramos, \u00e9 um produto multi-componente com estruturas de dados complexas, as consultas para alcan\u00e7ar o m\u00e1ximo desempenho<\/b> s\u00e3o, portanto, \"multivolumes\" com l\u00f3gica algor\u00edtmica complexa<\/a><\/noindex>. Assim, o volume de cada inst\u00e2ncia de consulta ou do plano de execu\u00e7\u00e3o resultante nos logs \u00e9, em m\u00e9dia, bastante grande.<\/p>\n

Vamos dar uma olhada na estrutura de uma das tabelas onde escrevemos os dados \"brutos\" \u2014 ou seja, o texto original do registro no log:<\/p>\n

CREATE TABLE rawdata_orig(\n  pack -- PK\n    uuid NOT NULL\n, recno -- PK\n    smallint NOT NULL\n, dt -- chave de se\u00e7\u00e3o\n    date\n, data -- o mais importante\n    text\n, PRIMARY KEY(pack, recno)\n);<\/code><\/pre>\n
\nUma tabela t\u00edpica (j\u00e1 particionada, sem d\u00favida, portanto, isso \u00e9 um modelo de se\u00e7\u00e3o), onde o mais importante \u00e9 o texto. \u00c0s vezes, bastante extenso.<\/p>\n
Lembre-se de que o tamanho \"f\u00edsico\" de um registro no PG n\u00e3o pode ocupar mais do que uma p\u00e1gina de dados, mas o tamanho \"l\u00f3gico\" \u00e9 outra hist\u00f3ria. Para gravar um valor extenso (varchar\/text\/bytea) no campo \u00e9 utilizada a tecnologia TOAST<\/a><\/noindex>:<\/p>\n
O PostgreSQL utiliza um tamanho fixo de p\u00e1gina (geralmente 8 KB) e n\u00e3o permite que tuplas ocupem v\u00e1rias p\u00e1ginas. Portanto, n\u00e3o \u00e9 poss\u00edvel armazenar valores muito grandes diretamente em campos. Para contornar essa limita\u00e7\u00e3o, grandes valores de campos s\u00e3o comprimidos e\/ou divididos em v\u00e1rias linhas f\u00edsicas. Isso acontece de forma discreta para o usu\u00e1rio e impacta pouco a maior parte do c\u00f3digo do servidor. Esse m\u00e9todo \u00e9 conhecido como TOAST \u2026<\/p><\/blockquote>\n
\nNa verdade, para cada tabela com campos \"potencialmente grandes\", automaticamente \u00e9 criada uma tabela auxiliar com \"fatiamento\"<\/a><\/noindex> de cada registro \"grande\" em segmentos de 2KB:<\/p>\n
TOAST(\n  chunk_id\n    inteiro\n, chunk_seq\n    inteiro\n, chunk_data\n    bytea\n, CHAVE PRIM\u00c1RIA(chunk_id, chunk_seq)\n);<\/code><\/pre>\n
\nOu seja, se precisamos gravar uma linha com um valor \"grande\" data<\/code>, a grava\u00e7\u00e3o real ocorrer\u00e1 n\u00e3o apenas na tabela principal e seu PK, mas tamb\u00e9m no TOAST e seu PK<\/b>.<\/p>\n
Reduzindo o impacto do TOAST<\/h4>\n
\nMas a maioria dos registros n\u00e3o \u00e9 t\u00e3o grande assim, deveriam caber nos 8KB<\/b> \u2014 como economizar nisso?..<\/p>\n
Aqui, o atributo STORAGE<\/code><\/a><\/noindex> da coluna da tabela vem em nosso aux\u00edlio:<\/p>\n
\n