{"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\/it\/blog\/administrirovanie\/dba-gramotno-organizovyvaem-sinhronizaczii-i-importy","title":{"rendered":"DBA: organizziamo le sincronizzazioni e gli import con competenza","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nella gestione complessa di grandi quantit\u00e0 di dati (differenti processi ETL<\/a><\/noindex>: importazioni, conversioni e sincronizzazioni con fonti esterne) spesso si presenta la necessit\u00e0 di \"memorizzare\" temporaneamente e elaborare rapidamente<\/b> qualcosa di voluminoso.<\/p>\n

Un compito tipico di questo tipo suona solitamente cos\u00ec: \u00abEcco qui la contabilit\u00e0 ha esportato dal client bancario<\/a><\/noindex> i pagamenti ricevuti pi\u00f9 recenti, dobbiamo caricarli velocemente sul sito e abbinarli ai conti\u00bb<\/i><\/p>\n

Ma quando la quantit\u00e0 di questo \"qualcosa\" inizia a misurarsi in centinaia di megabyte e il servizio deve continuare a lavorare con il database 24×7, sorgono numerosi effetti collaterali che possono complicarti la vita.
\n\"DBA:
\nPer affrontarli in PostgreSQL (e non solo), si possono utilizzare alcune funzionalit\u00e0 per ottimizzazioni che permetteranno di elaborare tutto pi\u00f9 rapidamente e con un minore consumo di risorse.
\n<\/a><\/noindex><\/p>\n

1. Dove caricare?<\/h2>\n

\nInnanzitutto, definiamo dove possiamo caricare i dati che vogliamo \"elaborare\".<\/p>\n

1.1. Tabelle temporanee (TEMPORARY TABLE)<\/h3>\n

\nIn linea di principio, le tabelle temporanee in PostgreSQL sono come qualsiasi altra tabella. Pertanto, sono infondate le superstizioni del tipo \u00abl\u00ec tutto \u00e8 memorizzato solo nella memoria, e questa pu\u00f2 esaurirsi\u00bb<\/b><\/i>. Ma ci sono anche alcune differenze sostanziali.<\/p>\n

Un proprio 'namespace' per ogni connessione al DB<\/h4>\n

\nSe due connessioni provano a eseguire simultaneamente CREATE TABLE x<\/code>, allora qualcuno otterr\u00e0 sicuramente un errore di non unicit\u00e0<\/b> degli oggetti del DB.<\/p>\n

Ma se entrambi provano a eseguire CREARE TEMPORANEA<\/b> TABELLA x<\/code>, allora entrambi lo faranno correttamente, e ognuno otterr\u00e0 la propria istanza<\/b> della tabella. E non ci sar\u00e0 nulla in comune tra loro.<\/p>\n

\u00abAuto-distruzione\u00bb al momento della disconnessione<\/h4>\n

\nQuando viene chiusa una connessione, tutte le tabelle temporanee vengono eliminate automaticamente, quindi non ha senso eseguire DROP TABLE x<\/code> a meno che non sia\u2026<\/p>\n

Se stai lavorando tramite pgbouncer in modalit\u00e0 transaction<\/b>, il database continua a considerare che questa connessione sia ancora attiva, e in essa questa tabella temporanea esiste ancora.<\/p>\n

Pertanto, il tentativo di crearla nuovamente da un'altra connessione a pgbouncer porter\u00e0 a un errore. Ma questo pu\u00f2 essere aggirato, utilizzando CREA UNA TABELLA TEMPORANEA SE NON ESISTE<\/b> x<\/code>.<\/p>\n

\u00c8 vero, sarebbe meglio non farlo, perch\u00e9 si potrebbe poi \"improvvisamente\" scoprire di avere dati lasciati dal \"precedente proprietario\". \u00c8 molto meglio leggere il manuale e vedere che, durante la creazione della tabella, c'\u00e8 l'opzione per aggiungere ALL'IMPEGNO ELIMINA<\/b><\/code> \u2014 cio\u00e8 alla conclusione della transazione, la tabella verr\u00e0 automaticamente eliminata.<\/p>\n

Non-replicazione<\/h4>\n

\nIn virt\u00f9 del fatto che appartengono solo a una connessione specifica, le tabelle temporanee non vengono replicate. Tuttavia, questo elimina la necessit\u00e0 di una doppia scrittura dei dati<\/b> in heap + WAL, quindi INSERT\/UPDATE\/DELETE in esse \u00e8 significativamente pi\u00f9 veloce.<\/p>\n

Tuttavia, poich\u00e9 una tabella temporanea \u00e8 comunque \"quasi una tabella normale\", non pu\u00f2 essere creata neanche nella replica. Almeno, per ora, anche se la relativa patch circola da tempo.<\/p>\n

1.2. Tabelle non registrabili (UNLOGGED TABLE)<\/h3>\n

\nMa cosa fare, ad esempio, se hai un qualche processo ETL ingombrante che non pu\u00f2 essere realizzato all'interno di una singola transazione, e hai pgbouncer in modalit\u00e0 transaction<\/b>?..<\/p>\n

Oppure, il flusso di dati \u00e8 cos\u00ec grande che non basta la larghezza di banda di una connessione<\/b> con il DB (leggi, un processo su CPU)?..<\/p>\n

Oppure parte delle operazioni avviene in modo asincrono<\/b> in diverse connessioni?..<\/p>\n

C'\u00e8 solo un'opzione qui \u2014 creare temporaneamente una tabella non temporanea<\/b>. Gioco di parole, eh. Quindi:<\/p>\n