{"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\/de\/blog\/administrirovanie\/dba-gramotno-organizovyvaem-sinhronizaczii-i-importy","title":{"rendered":"DBA: Synchronisationen und Importe sinnvoll organisieren","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bei der komplexen Verarbeitung gro\u00dfer Datens\u00e4tze (verschiedene ETL-Prozesse<\/a><\/noindex>: Importe, Konvertierungen und Synchronisationen mit externen Quellen) entsteht oft die Notwendigkeit tempor\u00e4r \"zu speichern\" und sofort schnell zu verarbeiten<\/b> etwas Umfangreiches.<\/p>\n

Eine typische Aufgabe dieser Art lautet im Allgemeinen etwa so: \"Hier hat die Buchhaltung die letzten eingegangenen Zahlungen aus dem Kundenbankupdate exportiert, die m\u00fcssen schnell auf die Website hochgeladen und den Konten zugewiesen werden\"<\/a><\/noindex> Doch wenn das Volumen dieses \"etwas\" in Hunderten von Megabytes gemessen wird und der Dienst dabei 24 \u00d7 7 mit der Datenbank arbeiten muss, treten viele Nebenwirkungen auf, die Ihr Leben erschweren.<\/i><\/p>\n

Aber wenn das Volumen dieses \u201eetwas\u201c in Hunderten von Megabyte gemessen wird und der Dienst gleichzeitig mit der Datenbank im 24\/7-Betrieb weiter laufen muss, treten viele Nebenwirkungen auf, die Ihnen das Leben schwer machen werden.
\n\"DBA:
\n1. Wo hochladen?
\n<\/a><\/noindex><\/p>\n

Zun\u00e4chst sollten wir kl\u00e4ren, wohin wir die Daten hochladen k\u00f6nnen, die wir \"verarbeiten\" wollen.<\/h2>\n

\n1.1. Tempor\u00e4re Tabellen (TEMPORARY TABLE)<\/p>\n

Prinzipiell sind tempor\u00e4re Tabellen in PostgreSQL ganz normale Tabellen wie alle anderen auch. Daher sind Aberglauben wie<\/h3>\n

\n\"dort wird alles nur im Speicher gespeichert, und der kann ausgehen\" nicht zutreffend. Aber es gibt auch einige wesentliche Unterschiede.<\/b><\/i>Eine eigene \"Namespaces\" f\u00fcr jede Verbindung zur Datenbank<\/p>\n

Wenn zwei Verbindungen gleichzeitig versuchen,<\/h4>\n

\nCREATE TABLE x , dann wird einer von ihnen definitiv<\/code>einen Fehler der Nicht-Eindeutigkeit von DB-Objekten erhalten.<\/b> Wenn jedoch beide versuchen,<\/p>\n

, wird jeder dies ordnungsgem\u00e4\u00df durchf\u00fchren und jeder wird CREATE VOR\u00dcBERGEHEND<\/b> TABELLE x<\/code>seinen eigenen Instanz der Tabelle erhalten. Und es wird nichts Gemeinsames zwischen ihnen geben.<\/b> \"Selbstzerst\u00f6rung\" bei der Trennung<\/p>\n

Beim Schlie\u00dfen der Verbindung werden alle tempor\u00e4ren Tabellen automatisch gel\u00f6scht, daher macht es \"von Hand\"<\/h4>\n

\nDROP TABLE x keinen Sinn, au\u00dfer ...<\/code> Wenn Sie \u00fcber<\/p>\n

pgbouncer im Transaktionsmodus , dann denkt die Datenbank weiterhin, dass diese Verbindung noch aktiv ist, und in ihr existiert diese tempor\u00e4re Tabelle nach wie vor.<\/b>Deshalb wird der Versuch, sie erneut aus einer anderen Verbindung zu pgbouncer zu erstellen, zu einem Fehler f\u00fchren. Aber das l\u00e4sst sich umgehen, indem man<\/p>\n

Es ist jedoch besser, so etwas zu vermeiden, da man dann \"unerwartet\" Daten finden k\u00f6nnte, die vom \"vorherigen Besitzer\" \u00fcbrig geblieben sind. Stattdessen ist es viel besser, tats\u00e4chlich das Handbuch zu lesen und zu sehen, dass man bei der Erstellung einer Tabelle die M\u00f6glichkeit hat, diese zu erg\u00e4nzen. TEMPOR\u00c4RE TABELLE ERSTELLEN WENN NICHT EXISTIERT<\/b> x<\/code>.<\/p>\n

Nat\u00fcrlich ist es besser, dies so nicht zu machen, da man dann \u201epl\u00f6tzlich\u201c Daten findet, die vom \u201evorherigen Besitzer\u201c \u00fcbrig geblieben sind. Stattdessen ist es viel besser, das Handbuch zu lesen und zu sehen, dass beim Erstellen einer Tabelle die M\u00f6glichkeit besteht, erg\u00e4nzende Informationen hinzuzuf\u00fcgen. BEI BEST\u00c4TIGUNG DROP<\/b><\/code> \u2014 das hei\u00dft, nach Abschluss der Transaktion wird die Tabelle automatisch gel\u00f6scht.<\/p>\n

Nicht-Replikation<\/h4>\n

\nAufgrund der Zugeh\u00f6rigkeit zu einer bestimmten Verbindung werden tempor\u00e4re Tabellen nicht repliziert. Daf\u00fcr befreit es von der Notwendigkeit der doppelten Datenspeicherung<\/b> in Heap + WAL, weshalb INSERT\/UPDATE\/DELETE darin erheblich schneller ist.<\/p>\n

Aber da eine tempor\u00e4re Tabelle dennoch eine \"fast gew\u00f6hnliche\" Tabelle ist, kann sie auch auf der Replik nicht erstellt werden. Zumindest im Moment, obwohl der entsprechende Patch schon lange existiert.<\/p>\n

1.2. Nicht-protokollierte Tabellen (UNLOGGED TABLE)<\/h3>\n

\nWas ist jedoch zu tun, wenn Sie beispielsweise einen ziemlich schwerf\u00e4lligen ETL-Prozess haben, den Sie nicht innerhalb einer einzigen Transaktion realisieren k\u00f6nnen, und Sie dennoch , dann denkt die Datenbank weiterhin, dass diese Verbindung noch aktiv ist, und in ihr existiert diese tempor\u00e4re Tabelle nach wie vor.<\/b>?..<\/p>\n

Oder wenn der Datenstrom so gro\u00df ist, dass die Bandbreite einer einzigen Verbindung<\/b> zur DB (sprich, eines Prozesses auf der CPU) nicht ausreicht? ..<\/p>\n

Oder wenn Teile der Operationen asynchron<\/b> in verschiedenen Verbindungen durchgef\u00fchrt werden? ..<\/p>\n

Hier gibt es nur eine M\u00f6glichkeit \u2014 vor\u00fcbergehend eine Nicht-Tempor\u00e4re Tabelle zu erstellen<\/b>. Wortspiel, ja. Das hei\u00dft:<\/p>\n