{"id":74953,"date":"2020-03-22T08:42:22","date_gmt":"2020-03-22T05:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/dba-gramotno-organizovyvaem-sinhronizaczii-i-importy"},"modified":"2020-03-22T08:42:22","modified_gmt":"2020-03-22T05:42:22","slug":"dba-gramotno-organizovyvaem-sinhronizaczii-i-importy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/dba-gramotno-organizovyvaem-sinhronizaczii-i-importy","title":{"rendered":"DBA: organizando de forma eficaz sincronia e importa\u00e7\u00f5es","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ao lidar com grandes conjuntos de dados complexos (diferentes Processos ETL<\/a><\/noindex>: importa\u00e7\u00f5es, convers\u00f5es e sincroniza\u00e7\u00f5es com fontes externas), muitas vezes surge a necessidade de \"lembrar\" temporariamente e processar rapidamente<\/b> algo volumoso.<\/p>\n

A tarefa t\u00edpica desse tipo geralmente soa mais ou menos assim: \"Aqui, a contabilidade exportou do banco de clientes<\/a><\/noindex> os \u00faltimos pagamentos recebidos, precisamos carreg\u00e1-los rapidamente no site e vincul\u00e1-los \u00e0s contas\"<\/i><\/p>\n

Mas quando o volume desse \"algo\" come\u00e7a a ser medido em centenas de megabytes, enquanto o servi\u00e7o deve continuar operando com a base em modo 24\/7, surgem muitos efeitos colaterais que podem atrapalhar sua vida.
\n\"DBA:
\nPara lidar com eles no PostgreSQL (e n\u00e3o apenas nele), podemos usar alguns recursos de otimiza\u00e7\u00e3o que permitir\u00e3o processar tudo mais rapidamente e com menor consumo de recursos.
\n<\/a><\/noindex><\/p>\n

1. Onde carregar?<\/h2>\n

\nPrimeiro, vamos definir onde podemos carregar os dados que queremos \"processar\".<\/p>\n

1.1. Tabelas tempor\u00e1rias (TEMPORARY TABLE)<\/h3>\n

\nBasicamente, para o PostgreSQL, tempor\u00e1rios s\u00e3o tabelas como qualquer outra. Portanto, n\u00e3o \u00e9 verdade que existam supersti\u00e7\u00f5es do tipo \"tudo \u00e9 armazenado apenas na mem\u00f3ria, e ela pode acabar\".<\/b><\/i>Mas existem algumas diferen\u00e7as significativas.<\/p>\n

Seu \"namespace\" para cada conex\u00e3o ao BD<\/h4>\n

\nSe duas conex\u00f5es tentarem executar ao mesmo tempo CREATE TABLE x<\/code>, ent\u00e3o algu\u00e9m definitivamente receber\u00e1 um erro de n\u00e3o unicidade<\/b> de objetos BD.<\/p>\n

Mas se ambos tentarem executar CREATE TEMPOR\u00c1RIO<\/b> TABELA x<\/code>, ambos far\u00e3o isso normalmente, e cada um receber\u00e1 sua pr\u00f3pria inst\u00e2ncia<\/b> da tabela. E nada em comum entre elas.<\/p>\n

\"Auto-destrui\u00e7\u00e3o\" ao desconectar<\/h4>\n

\nAo fechar a conex\u00e3o, todas as tabelas tempor\u00e1rias s\u00e3o automaticamente removidas, ent\u00e3o n\u00e3o faz sentido executar manualmente DROP TABLE x<\/code> , exceto por\u2026<\/p>\n

Se voc\u00ea estiver trabalhando atrav\u00e9s do pgbouncer no modo de transa\u00e7\u00e3o<\/b>, o banco ainda acredita que essa conex\u00e3o ainda est\u00e1 ativa, e nela essa tabela tempor\u00e1ria ainda existe.<\/p>\n

Portanto, a tentativa de cri\u00e1-la novamente, j\u00e1 de outra conex\u00e3o ao pgbouncer, resultar\u00e1 em erro. Mas isso pode ser contornado, usando CRIE UMA TABELA TEMPOR\u00c1RIA SE N\u00c3O EXISTIR<\/b> x<\/code>.<\/p>\n

Embora seja melhor n\u00e3o fazer isso, porque voc\u00ea pode \"repentinamente\" descobrir dados restantes do \"propriet\u00e1rio anterior\". Em vez disso, \u00e9 muito melhor ler o manual e verificar que ao criar a tabela h\u00e1 uma op\u00e7\u00e3o para adicionar AO COMMIT DROP<\/b><\/code> \u2014 ou seja, ao final da transa\u00e7\u00e3o, a tabela ser\u00e1 deletada automaticamente.<\/p>\n

N\u00e3o-replica\u00e7\u00e3o<\/h4>\n

\nDevido \u00e0 sua associa\u00e7\u00e3o a uma conex\u00e3o espec\u00edfica, tabelas tempor\u00e1rias n\u00e3o s\u00e3o replicadas. No entanto, isso elimina a necessidade de gravar os dados duas vezes<\/b> em heap + WAL, tornando as opera\u00e7\u00f5es de INSERT\/UPDATE\/DELETE muito mais r\u00e1pidas.<\/p>\n

Mas como uma tabela tempor\u00e1ria \u00e9, na verdade, uma tabela \"quase normal\", ela tamb\u00e9m n\u00e3o pode ser criada na r\u00e9plica. Pelo menos, n\u00e3o ainda, embora o patch correspondente j\u00e1 esteja em circula\u00e7\u00e3o h\u00e1 muito tempo.<\/p>\n

1.2. Tabelas n\u00e3o registradas (UNLOGGED TABLE)<\/h3>\n

\nMas o que fazer, por exemplo, se voc\u00ea tem algum processo ETL complexo que n\u00e3o consegue ser realizado dentro de uma \u00fanica transa\u00e7\u00e3o, e voc\u00ea realmente do pgbouncer no modo de transa\u00e7\u00e3o<\/b>?..<\/p>\n

Ou se o fluxo de dados \u00e9 t\u00e3o grande que n\u00e3o h\u00e1 largura de banda suficiente de uma \u00fanica conex\u00e3o<\/b> com o banco de dados (leia-se, um \u00fanico processo no CPU)?..<\/p>\n

Ou se parte das opera\u00e7\u00f5es ocorre ass\u00edncronamente<\/b> em diferentes conex\u00f5es?..<\/p>\n

Aqui a \u00fanica op\u00e7\u00e3o \u00e9 \u2014 criar temporariamente uma tabela n\u00e3o tempor\u00e1ria<\/b>. Um trocadilho, sim. Ou seja:<\/p>\n