{"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\/sv\/blog\/administrirovanie\/dba-gramotno-organizovyvaem-sinhronizaczii-i-importy","title":{"rendered":"DBA: vi organiserar synkroniseringar och importer p\u00e5 ett smart s\u00e4tt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vid komplex bearbetning av stora datam\u00e4ngder (olika ETL-processer<\/a><\/noindex>: importer, konverteringar och synkronisering med externa k\u00e4llor) uppst\u00e5r ofta behovet att tempor\u00e4rt \"komma ih\u00e5g\", och snabbt bearbeta<\/b> n\u00e5got omfattande.<\/p>\n

En typisk uppgift av detta slag l\u00e5ter oftast s\u00e5 h\u00e4r: \"H\u00e4r har bokf\u00f6ringen laddat ner senaste betalningar fr\u00e5n kundens bank<\/a><\/noindex> som snabbt m\u00e5ste laddas upp p\u00e5 webbplatsen och kopplas till kontona\".<\/i><\/p>\n

Men n\u00e4r volymen av detta \"n\u00e5got\" b\u00f6rjar m\u00e4tas i hundratals megabyte, och tj\u00e4nsten samtidigt m\u00e5ste forts\u00e4tta fungera med databasen dygnet runt, uppst\u00e5r det m\u00e5nga biverkningar som kommer att f\u00f6rst\u00f6ra din vardag.
\n\"DBA:
\nF\u00f6r att hantera dem i PostgreSQL (och \u00e4ven i andra system) kan man anv\u00e4nda vissa m\u00f6jligheter f\u00f6r optimeringar som g\u00f6r att allt bearbetas snabbare och med mindre resursf\u00f6rbrukning.
\n<\/a><\/noindex><\/p>\n

1. Var ska vi ladda?<\/h2>\n

\nF\u00f6rst, l\u00e5t oss klarg\u00f6ra vart vi kan ladda data som vi vill \"bearbeta\".<\/p>\n

1.1. Tempor\u00e4ra tabeller (TEMPORARY TABLE)<\/h3>\n

\nI princip \u00e4r tempor\u00e4ra tabeller i PostgreSQL precis som vanliga tabeller. D\u00e4rf\u00f6r \u00e4r vidskepligheten om att \"de lagras bara i minnet, och det kan ta slut\"<\/b><\/i>felaktig. Men det finns n\u00e5gra betydande skillnader.<\/p>\n

Ett eget \"namnrum\" f\u00f6r varje anslutning till databasen<\/h4>\n

\nOm tv\u00e5 anslutningar f\u00f6rs\u00f6ker samtidigt utf\u00f6ra CREATE TABLE x<\/code>, s\u00e5 kommer n\u00e5gon garanterat f\u00e5 en unikhetsfel<\/b> f\u00f6r databaskonton.<\/p>\n

Men om b\u00e5da f\u00f6rs\u00f6ker utf\u00f6ra T\u00e4nk p\u00e5 f\u00f6rkortningar. TILLF\u00c4LIG<\/b> TABELL x<\/code>, s\u00e5 kommer b\u00e5da att lyckas, och varje kommer att f\u00e5 sin egen instans<\/b> av tabellen. Och ingenting kommer att vara gemensamt mellan dem.<\/p>\n

\"Sj\u00e4lvf\u00f6rst\u00f6relse\" vid avbrott<\/h4>\n

\nVid st\u00e4ngning av anslutningen tas alla tempor\u00e4ra tabeller automatiskt bort, s\u00e5 det finns ingen mening med att \"manuellt\" utf\u00f6ra DROP TABLE x<\/code> utom\u2026<\/p>\n

Om du arbetar genom pgbouncer i transaktionsl\u00e4ge<\/b>, s\u00e5 anser databasen att anslutningen fortfarande \u00e4r aktiv, och i denna anslutning existerar fortfarande denna tempor\u00e4ra tabell.<\/p>\n

D\u00e4rf\u00f6r kommer ett f\u00f6rs\u00f6k att skapa den igen, redan fr\u00e5n en annan anslutning till pgbouncer, att leda till ett fel. Men detta kan omg\u00e5s genom att anv\u00e4nda SKAPA TILLF\u00c4LLIG TABELL OM DET INTE FINNS<\/b> x<\/code>.<\/p>\n

Men det \u00e4r b\u00e4ttre att inte g\u00f6ra s\u00e5, eftersom man d\u00e5 kan \"ov\u00e4ntat\" uppt\u00e4cka data d\u00e4r, som tillh\u00f6rde \"f\u00f6reg\u00e5ende \u00e4gare\". Ist\u00e4llet \u00e4r det mycket b\u00e4ttre att l\u00e4sa manualen och se att n\u00e4r man skapar en tabell finns det m\u00f6jlighet att skriva till. P\u00c5 \u00c5TAGANDE DROP<\/b><\/code> \u2014 det vill s\u00e4ga vid avslutandet av transaktionen kommer tabellen att tas bort automatiskt.<\/p>\n

Icke-replikering<\/h4>\n

\nEftersom de endast tillh\u00f6r en viss anslutning, replikeras inte tempor\u00e4ra tabeller. Men detta eliminerar behovet av dubbel skrivning av data<\/b> till heap + WAL, s\u00e5 INSERT\/UPDATE\/DELETE till dem \u00e4r avsev\u00e4rt snabbare.<\/p>\n

Men eftersom en tempor\u00e4r tabell fortfarande \u00e4r en \"n\u00e4stan vanlig\" tabell, kan den inte skapas p\u00e5 replikan heller. \u00c5tminstone inte \u00e4nnu, \u00e4ven om en passande patch har funnits l\u00e4nge.<\/p>\n

1.2. Icke-journaliserade tabeller (UNLOGGED TABLE)<\/h3>\n

\nMen vad g\u00f6r man om man till exempel har en kr\u00e5nglig ETL-process som inte kan genomf\u00f6ras i en enda transaktion, och ni har faktiskt pgbouncer i transaktionsl\u00e4ge<\/b>?..<\/p>\n

Eller datastreamen \u00e4r s\u00e5 stor att en enda anslutning inte har tillr\u00e4cklig kapacitet<\/b> till DB (l\u00e4s, en process per CPU)?..<\/p>\n

Eller en del operationer g\u00e5r asynkront<\/b> i olika kopplingar?..<\/p>\n

H\u00e4r finns bara ett alternativ \u2014 att tillf\u00e4lligt skapa en icke-tempor\u00e4r tabell<\/b>. En kalambur, visst. Det vill s\u00e4ga:<\/p>\n