{"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: wir organisieren Synchronisierungen und Importe geschickt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bei der komplexen Verarbeitung gro\u00dfer Datens\u00e4tze (verschiedene ETL-Prozesse<\/a><\/noindex>: Importe, Konversionen und Synchronisationen mit externen Quellen) besteht h\u00e4ufig die Notwendigkeit, etwas vor\u00fcbergehend zu \"merken\" und sofort schnell zu verarbeiten,<\/b> was auch immer umfangreich ist.<\/p>\n

Typische Aufgaben in diesem Bereich lauten normalerweise etwa so: \"Hier hat die Buchhaltung die letzten Zahlungen aus dem Kundenbank abgeholt, wir m\u00fcssen diese schnell auf die Website laden und mit den Konten verkn\u00fcpfen.\"<\/a><\/noindex> Wenn das Volumen dieses \"Irgendwas\" jedoch in Hunderten von Megabyte gemessen wird und der Dienst dabei 24\/7 mit der Datenbank arbeiten muss, entstehen viele Nebeneffekte, die Ihnen das Leben schwer machen.<\/i><\/p>\n

Doch wenn die Menge dieses \u201eEtwas\u201c in Hunderten von Megabyte gemessen wird und der Dienst weiterhin rund um die Uhr mit der Datenbank arbeiten muss, entstehen zahlreiche Nebenwirkungen, die Ihnen das Leben schwer machen werden.
\n\"DBA:
\n1. Wohin laden?
\n<\/a><\/noindex><\/p>\n

Lassen Sie uns zun\u00e4chst kl\u00e4ren, wohin wir die Daten hochladen k\u00f6nnen, die wir \"verarbeiten\" m\u00f6chten.<\/h2>\n

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

Im Grunde genommen sind tempor\u00e4re Tabellen in PostgreSQL genau wie jede andere Tabelle. Aberglaube wie<\/h3>\n

\nIm Prinzip sind tempor\u00e4re Tabellen in PostgreSQL genau wie alle anderen Tabellen. Daher sind Aberglauben wie Hier wird alles nur im Speicher gespeichert, und der kann schnell voll sein.<\/b><\/i>Es gibt jedoch auch einige wesentliche Unterschiede.<\/p>\n

Ein eigener \"Namespace\" f\u00fcr jede Datenbankverbindung.<\/h4>\n

\nWenn zwei Verbindungen gleichzeitig versuchen, CREATE TABLE x<\/code>, wird einer von beiden garantiert einen Fehler wegen Nicht-Eindeutigkeit<\/b> der Datenbankobjekte erhalten.<\/p>\n

Wenn jedoch beide versuchen, ERSTELLEN TEMPOR\u00c4R<\/b> TABELLE x<\/code>, dann k\u00f6nnen beide das erfolgreich durchf\u00fchren, und jede Verbindung erh\u00e4lt ihren eigenen Instanz<\/b> der Tabelle. Und zwischen ihnen wird es keine Gemeinsamkeiten geben.<\/p>\n

\u201eSelbstzerst\u00f6rung\u201c bei der Trennung<\/h4>\n

\nWenn die Verbindung geschlossen wird, werden alle tempor\u00e4ren Tabellen automatisch gel\u00f6scht, daher macht es keinen Sinn, DROP TABLE x<\/code> manuell auszuf\u00fchren, au\u00dfer...<\/p>\n

Wenn Sie \u00fcber pgbouncer im Transaktionsmodus arbeiten,<\/b>denn die Datenbank denkt weiterhin, dass diese Verbindung noch aktiv ist, und in dieser existiert diese tempor\u00e4re Tabelle nach wie vor.<\/p>\n

Daher 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 TEMPOR\u00c4RE TABELLE ERSTELLEN WENN NICHT EXISTIERT<\/b> x<\/code>.<\/p>\n

Es ist jedoch besser, dies zu vermeiden, da man sonst m\u00f6glicherweise pl\u00f6tzlich Daten vom \"vorherigen Besitzer\" entdecken k\u00f6nnte. Stattdessen ist es weitaus besser, das Handbuch zu lesen und zu erkennen, dass es beim Erstellen einer Tabelle die M\u00f6glichkeit gibt, diese zu erg\u00e4nzen. BEIMEN WIDMEN L\u00d6SCHEN<\/b><\/code> \u2014 das hei\u00dft, dass die Tabelle nach Abschluss der Transaktion automatisch gel\u00f6scht wird.<\/p>\n

Keine Replikation<\/h4>\n

\nAufgrund der Zugeh\u00f6rigkeit zu einer bestimmten Verbindung werden tempor\u00e4re Tabellen nicht repliziert. Allerdings entfernt dies die Notwendigkeit einer doppelten Datenspeicherung<\/b> in Heap + WAL, weshalb INSERT\/UPDATE\/DELETE deutlich schneller ist.<\/p>\n

Aber da eine tempor\u00e4re Tabelle ja dennoch \"fast wie eine normale\" Tabelle ist, kann sie auch nicht auf der Replik erstellt werden. Zumindest bislang nicht, obwohl der entsprechende Patch schon lange bekannt ist.<\/p>\n

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

\nAber was tun, wenn Sie beispielsweise einen umfangreichen ETL-Prozess haben, der nicht innerhalb einer einzigen Transaktion realisiert werden kann, und Sie dennoch pgbouncer im Transaktionsmodus arbeiten,<\/b>?..<\/p>\n

Oder wenn der Datenstrom so gro\u00df ist, dass die Bandbreite einer Verbindung<\/b> mit der Datenbank nicht ausreicht (lesen Sie: ein Prozess pro CPU)?<\/p>\n

Oder wenn Teile der Operationen asynchron<\/b> in verschiedenen Verbindungen ablaufen?<\/p>\n

In diesem Fall gibt es nur eine M\u00f6glichkeit \u2014 tempor\u00e4re nicht-tempor\u00e4re Tabellen erstellen<\/b>. Wortspiel, oder? Das bedeutet:<\/p>\n