{"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\/nl\/blog\/administrirovanie\/dba-gramotno-organizovyvaem-sinhronizaczii-i-importy","title":{"rendered":"DBA: we organiseren synchronisaties en imports op een nette manier","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bij de complexe verwerking van grote datasets (verschillende ETL-processen<\/a><\/noindex>: imports, conversies en synchronisaties met een externe bron) ontstaat vaak de noodzaak om tijdelijk iets te 'onthouden', en snel te verwerken<\/b> iets omvangrijks.<\/p>\n

Een typische taak van deze aard klinkt meestal ongeveer zo: \"Hier heeft de boekhouding recent ontvangen betalingen uit het klantensysteem ge\u00ebxporteerd, we moeten deze snel naar de website uploaden en aan rekeningen koppelen\" Maar wanneer de omvang van dit \"iets\" begint te meten in honderden megabytes, en de service tegelijkertijd 24\u00d77 met de database moet blijven werken, ontstaan er veel side-effecten die je het leven moeilijk maken.<\/a><\/noindex> Om hiermee om te gaan in PostgreSQL (en niet alleen daar), kunnen we gebruikmaken van verschillende optimalisatiemogelijkheden die het mogelijk maken om alles sneller en met minder middelen te verwerken.<\/i><\/p>\n

Maar wanneer de hoeveelheid van dit \"iets\" begint te worden gemeten in honderden megabytes, en de service ondertussen 24\/7 met een database moet blijven werken, ontstaan er veel bijeffecten die je leven kunnen verpesten.
\n\"DBA:
\nLaten we eerst vaststellen waar we de gegevens kunnen uploaden die we willen 'verwerken'.
\n<\/a><\/noindex><\/p>\n

1.1. Tijdelijke tabellen (TEMPORARY TABLE)<\/h2>\n

\nIn principe zijn tijdelijke tabellen in PostgreSQL net zo'n tabel als elke andere. Daarom zijn bijgeloof zoals<\/p>\n

\"het wordt alleen in het geheugen opgeslagen, en dat kan op raken\"<\/h3>\n

\nniet correct. Maar er zijn ook enkele belangrijke verschillen.<\/b><\/i>Een eigen 'naamruimte' voor elke databaseverbinding<\/p>\n

Als twee verbindingen tegelijkertijd proberen uit te voeren<\/h4>\n

\nCREATE TABLE x , dan krijgt iemand zeker een<\/code>uniquenessfout van databaseobjecten.<\/b> Maar als beide proberen uit te voeren,<\/p>\n

, dan kunnen beiden dit normaal doen, en krijgt elke verbinding CREATE Tijdelijk<\/b> TABEL x<\/code>zijn eigen instantie van de tabel. En er is niets gemeen tussen hen.<\/b> \"Zelfvernietiging\" bij disconnect<\/p>\n

Bij het sluiten van de verbinding worden alle tijdelijke tabellen automatisch verwijderd, dus heeft het geen zin om<\/h4>\n

\nDROP TABLE x handmatig uit te voeren, behalve\u2026<\/code> Als je werkt via<\/p>\n

pgbouncer in transaction mode , dan denkt de database dat deze verbinding nog steeds actief is, en dan bestaat deze tijdelijke tabel daar nog steeds.<\/b>Dus de poging om deze opnieuw te maken, al vanuit een andere pgbouncer-verbinding, zal resulteren in een fout. Maar dit kan worden omzeild door gebruik te maken van<\/p>\n

Een poging om het opnieuw te cre\u00ebren vanuit een andere verbinding naar pgbouncer zal leiden tot een fout. Maar dit kan worden omzeild door gebruik te maken van CRE\u00cbER TUSSENTIJDELIJKE TABEL ALS HET NOG NIET BESTAAT<\/b> x<\/code>.<\/p>\n

Het is beter om dit niet te doen, omdat je dan plotseling gegevens kunt ontdekken die van de 'vorige eigenaar' zijn. In plaats daarvan is het veel beter om de handleiding te lezen en te zien dat er bij het aanmaken van een tabel de mogelijkheid is om Bij commit DROP<\/b><\/code> \u2014 dat wil zeggen dat de tabel automatisch zal worden verwijderd bij het afronden van de transactie.<\/p>\n

Niet-replicatie<\/h4>\n

\nVanwege de toewijzing aan een specifiek verband worden tijdelijke tabellen niet gerepliceerd. Maar dit elimineert de noodzaak voor dubbele gegevensopslag<\/b> in heap + WAL, waardoor INSERT\/UPDATE\/DELETE daarin aanzienlijk sneller zijn.<\/p>\n

Maar omdat een tijdelijke tabel toch 'bijna een gewone' tabel is, kan deze ook niet op de replica worden aangemaakt. Tenminste, voorlopig niet, hoewel de bijbehorende patch al lang in omloop is.<\/p>\n

1.2. Niet-logbare tabellen (UNLOGGED TABLE)<\/h3>\n

\nMaar wat te doen als je bijvoorbeeld een zwaar ETL-proces hebt dat niet binnen \u00e9\u00e9n transactie kan worden uitgevoerd en dat je toch , dan denkt de database dat deze verbinding nog steeds actief is, en dan bestaat deze tijdelijke tabel daar nog steeds.<\/b>?..<\/p>\n

Of de gegevensstroom is zo groot dat de bandbreedte van \u00e9\u00e9n verbinding niet voldoende is<\/b> met de database (lees: \u00e9\u00e9n proces op de CPU)?..<\/p>\n

Of sommige operaties verlopen asynchroon<\/b> via verschillende verbindingen?..<\/p>\n

Hier is er maar \u00e9\u00e9n optie \u2014 tijdelijk een niet-tijdelijke tabel aanmaken<\/b>. Een woordgrap, h\u00e8. Dat wil zeggen:<\/p>\n