{"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 in modo efficace le sincronizzazioni e gli import","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Quando si tratta di elaborare grandi set di dati complessi (diversi processi ETL<\/a><\/noindex>: importazioni, conversioni e sincronizzazioni con una fonte esterna) sorge spesso la necessit\u00e0 di 'memorizzare' temporaneamente e trattare rapidamente<\/b> qualcosa di voluminoso.<\/p>\n

Un compito tipico di questo tipo \u00e8 di solito formulato pi\u00f9 o meno cos\u00ec: \u00abEcco qui la contabilit\u00e0 ha estratto dal client banking<\/a><\/noindex> gli ultimi pagamenti ricevuti, bisogna caricarli rapidamente sul sito e associarli ai conti\u00bb<\/i><\/p>\n

Ma quando il volume di questa \"cosa\" inizia a misurarsi in centinaia di megabyte, e il servizio deve continuare a lavorare con il database in modalit\u00e0 24\/7, sorgono numerosi effetti collaterali che rovineranno la tua vita.
\n\"DBA:
\nPer affrontarli in PostgreSQL (e non solo in esso), \u00e8 possibile utilizzare alcune funzionalit\u00e0 di ottimizzazione che consentono di elaborare tutto pi\u00f9 rapidamente e con un minore consumo di risorse.
\n<\/a><\/noindex><\/p>\n

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

\nPrima di tutto, definiamo dove possiamo caricare i dati che vogliamo 'processare'.<\/p>\n

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

\nIn linea di principio, per PostgreSQL le tabelle temporanee sono tabelle proprio come tutte le altre. Quindi le superstizioni come \u00abl\u00ec tutto \u00e8 memorizzato solo in memoria, e questa potrebbe finire\u00bb<\/b><\/i>non sono corrette. Ma ci sono anche diverse differenze sostanziali.<\/p>\n

Uno 'spazio dei nomi' per ogni connessione al DB<\/h4>\n

\nSe due connessioni tentano di eseguire contemporaneamente CREATE TABLE x<\/code>, allora qualcuna ricever\u00e0 sicuramente un errore di non unicit\u00e0<\/b> degli oggetti DB.<\/p>\n

Ma se entrambi tentano di eseguire CREATE TEMPORANEO<\/b> TABELLA x<\/code>, allora entrambi lo faranno correttamente e ciascuno ricever\u00e0 la propria istanza<\/b> della tabella. E non ci sar\u00e0 nulla in comune tra loro.<\/p>\n

\u00abAutoannullamento\u00bb alla disconnessione<\/h4>\n

\nQuando la connessione si chiude, tutte le tabelle temporanee vengono automaticamente rimosse, quindi eseguire manualmente DROP TABLE x<\/code> non ha alcun senso, tranne...<\/p>\n

Se si lavora tramite pgbouncer in modalit\u00e0 transazione<\/b>, il database continuer\u00e0 a ritenere che questa connessione sia ancora attiva, e in essa questa tabella temporanea esister\u00e0 ancora.<\/p>\n

Quindi, il tentativo di crearla di nuovo, gi\u00e0 da un'altra connessione a pgbouncer, porter\u00e0 a un errore. Ma questo si pu\u00f2 aggirare, utilizzando CREARE UNA TAVOLO TEMPORANEA SE NON ESISTE<\/b> x<\/code>.<\/p>\n

\u00c8 vero, sarebbe meglio non farlo, perch\u00e9 poi si potrebbe \u00abscoprire all'improvviso\u00bb l\u00ec dentro i dati rimasti dal \u00abproprietario precedente\u00bb. \u00c8 molto meglio leggere il manuale e vedere che nella creazione della tabella c'\u00e8 la possibilit\u00e0 di aggiungere ALLA COMMIT DROP<\/b><\/code> \u2014 cio\u00e8 al completamento della transazione, la tabella verr\u00e0 eliminata automaticamente.<\/p>\n

Non replicazione<\/h4>\n

\nA causa della sua appartenenza solo a una certa connessione, le tabelle temporanee non vengono replicate. Tuttavia, questo elimina la necessit\u00e0 di una doppia registrazione dei dati<\/b> in heap + WAL, quindi INSERT\/UPDATE\/DELETE in essa \u00e8 notevolmente pi\u00f9 veloce.<\/p>\n

Ma poich\u00e9 una tabella temporanea \u00e8 comunque una tabella \u00abquasi normale\u00bb, non \u00e8 possibile crearla nemmeno sulla replica. Almeno, per ora, sebbene la patch corrispondente circoli da molto tempo.<\/p>\n

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

\nMa cosa fare, ad esempio, se hai un qualche pesante processo ETL che non riesci a realizzare all'interno di una singola transazione, e hai comunque pgbouncer in modalit\u00e0 transazione<\/b>?..<\/p>\n

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

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

L'unica opzione qui \u00e8 \u2014 creare temporaneamente una tabella non temporanea<\/b>. Gioco di parole, eh. Cio\u00e8:<\/p>\n