{"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\/da\/blog\/administrirovanie\/dba-gramotno-organizovyvaem-sinhronizaczii-i-importy","title":{"rendered":"DBA: organiserer synkroniseringer og importer korrekt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ved kompleks behandling af store datas\u00e6t (forskellige ETL-processer<\/a><\/noindex>: importer, konverteringer og synkronisering med eksterne kilder) opst\u00e5r der ofte behov for at midlertidigt \"huske\", og hurtigt behandle<\/b> noget volumin\u00f8st.<\/p>\n

En typisk opgave af denne art lyder som regel nogenlunde s\u00e5dan her: \"Her har regnskabsafdelingen hentet fra klientbank<\/a><\/noindex> de senest modtagne betalinger, de skal hurtigt overf\u00f8res til hjemmesiden og knyttes til regnskaberne\"<\/i><\/p>\n

Men n\u00e5r m\u00e6ngden af dette 'noget' begynder at m\u00e5les i hundrede megabyte, og tjenesten stadig skal fungere 24\/7 med databasen, opst\u00e5r der mange bivirkninger, der vil g\u00f8re dit liv besv\u00e6rligt.
\n\"DBA:
\nFor at h\u00e5ndtere dem i PostgreSQL (og ikke kun der) kan man anvende nogle optimeringsmuligheder, som muligg\u00f8r hurtigere behandling med f\u00e6rre ressourceforbrug.
\n<\/a><\/noindex><\/p>\n

1. Hvor skal vi l\u00e6gge det?<\/h2>\n

\nLad os f\u00f8rst bestemme, hvor vi kan indl\u00e6se de data, vi \u00f8nsker at \"behandle\".<\/p>\n

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

\nI princippet er midlertidige tabeller i PostgreSQL de samme som alle andre tabeller. Derfor er overtroen om, \"der gemmes kun i hukommelsen, og den kan l\u00f8be t\u00f8r\"<\/b><\/i>forkert. Men der er ogs\u00e5 nogle v\u00e6sentlige forskelle.<\/p>\n

En \"navnerum\" for hver forbindelse til DB<\/h4>\n

\nHvis to forbindelser fors\u00f8ger at udf\u00f8re CREATE TABLE x<\/code>, vil nogen uundg\u00e5eligt f\u00e5 fejl p\u00e5 grund af ikke-unikhed<\/b> af DB-objekter.<\/p>\n

Men hvis begge fors\u00f8ger at udf\u00f8re CREATE MIDLTID<\/b> TABEL x<\/code>, s\u00e5 vil begge g\u00f8re det uden problemer, og hver vil f\u00e5 sin egen instans<\/b> af tabellen. Og der vil ikke v\u00e6re noget f\u00e6lles mellem dem.<\/p>\n

\"Selvdestruktion\" ved frakobling<\/h4>\n

\nVed lukning af forbindelsen slettes alle midlertidige tabeller automatisk, s\u00e5 der er ingen mening i at udf\u00f8re DROP TABLE x<\/code> udover\u2026<\/p>\n

Hvis du arbejder via pgbouncer i transaktionsmode<\/b>, s\u00e5 tror databasen stadig, at denne forbindelse stadig er aktiv, og at denne midlertidige tabel stadig eksisterer i den.<\/p>\n

Derfor vil et fors\u00f8g p\u00e5 at oprette den igen, allerede fra en anden forbindelse til pgbouncer, f\u00f8re til en fejl. Men dette kan omg\u00e5s ved at bruge OPRET MIDLERTIDIG TABEL HVIS IKKE DER FINDES<\/b> x<\/code>.<\/p>\n

Men det er bedst ikke at g\u00f8re det, fordi man s\u00e5 pludselig kan opdage data tilbage fra \"den tidligere ejer\". I stedet er det meget bedre at l\u00e6se manualen n\u00f8je og se, at der ved oprettelse af tabellen er mulighed for at tilf\u00f8je P\u00c5 COMMIT DROP<\/b><\/code> \u2014 det vil sige, at n\u00e5r transaktionen er f\u00e6rdig, vil tabellen automatisk blive slettet.<\/p>\n

Ikke-replikation<\/h4>\n

\nP\u00e5 grund af tilknytning kun til en bestemt forbindelse, replikeres midlertidige tabeller ikke. Til geng\u00e6ld fjerner dette behovet for dobbelt dataregistrering<\/b> i heap + WAL, s\u00e5 INSERT\/UPDATE\/DELETE i den er betydeligt hurtigere.<\/p>\n

Men da en midlertidig tabel stadig er en \"n\u00e6sten almindelig\" tabel, kan den heller ikke oprettes p\u00e5 replika. I det mindste ikke endnu, selvom en passende patch har v\u00e6ret tilg\u00e6ngelig i lang tid.<\/p>\n

1.2. Uregistrerede tabeller (UNLOGGED TABLE)<\/h3>\n

\nMen hvad g\u00f8r man, hvis man har en tung ETL-proces, som ikke kan implementeres i en enkelt transaktion, og man har stadig pgbouncer i transaktionsmode<\/b>?..<\/p>\n

Eller hvis datastreamen er s\u00e5 stor, at kapaciteten af \u00e9n forbindelse<\/b> til DB (l\u00e6s: \u00e9n proces p\u00e5 CPU) ikke er tilstr\u00e6kkelig? ..<\/p>\n

Eller hvis nogle operationer foreg\u00e5r asynkront<\/b> i forskellige forbindelser? ..<\/p>\n

Her er der kun \u00e9n mulighed \u2014 tilf\u00e6ldig oprettelse af en ikke-midlertidig tabel<\/b>. Sp\u00f8g, ikke? Det vil sige:<\/p>\n