Datenautobahn: Detaillierte Erläuterung der Data Warehouse-Cluster-Kommunikationstechnologie

[Vorschau der Live-Übertragung] 99 Yuan virtuelle Cloud-Maschine × 9 Yuan native Cloud-Architektur √

Dieser Artikel wurde von der Huawei Cloud Community geteilt: „ Live Broadcast Review | Data Highway – Detaillierte Erklärung der Data Warehouse Cluster Communication Technology “ von Hu Latang.

Im Zeitalter von Big Data wird der Umfang der Cluster immer größer, die geschäftliche Parallelität wird immer höher und auch der Kommunikationsdruck zwischen den Knoten des Datenbankclusters nimmt zu. In dieser Live-Übertragung zum Thema „Data Highway – Detaillierte Erläuterung der Data Warehouse-Cluster-Kommunikationstechnologie“ haben wir Herrn Wei Deng, technischen Evangelisten von Huawei Cloud GaussDB (DWS), eingeladen, ausführlich zu erklären, wie die Cluster-Kommunikationstechnologie GaussDB (DWS) funktionieren kann in großem Maßstab bereitgestellt werden. Wie man ein leistungsstarkes verteiltes Kommunikationssystem implementiert, wenn Dienste mit hoher Parallelität in einem Cluster übertragen werden.

1. Überblick über die Clusterkommunikation von GaussDB (DWS).

Im GaussDB (DWS)-Cluster gibt es einen oder mehrere Koordinationsknoten (CN), jeder Host verfügt über mehrere Datenknoten (CN), einen globalen Transaktionscontroller (GTM), ein Betriebs- und Wartungsverwaltungsmodul (OM) und ein Clusterverwaltungsmodul ( CM), Datenimport- und -exportmodul (GDS).

Koordinationsknoten (CN): Verantwortlich für die Anforderungszerlegung, Planung und Ergebnisrückgabe; SQL-Analyse und -Optimierung; es werden nur Metadaten gespeichert, keine Daten.
Datenknoten (DN): Verantwortlich für das Speichern tatsächlicher Tabellendaten (angegebene Verteilungsmethode: Hash-Tabelle, Replikationstabelle, RroundRobin-Tabelle); Ausführen von SQL-Aufgaben und Zurückgeben von Ausführungsergebnissen an CN.
Global Transaction Controller (GTM) : Verantwortlich für die Generierung und Pflege globaler Transaktions-IDs, Transaktions-Snapshots, Zeitstempel und anderer weltweit eindeutiger Informationen.
Betriebs- und Wartungsmanagementmodul (OM) : Bietet tägliches Betriebs- und Wartungsmanagement sowie Konfigurationsmanagement.
Cluster-Management-Modul (CM) : Cluster-Management und Überwachung der physischen Ressourcennutzung jeder Einheit.
GDS Loader : Batch-Datenladen, parallele Beschleunigung

Alle oben genannten Module kommunizieren über das Cluster-Netzwerk miteinander. Die Cluster-Kommunikation unterscheidet sich von herkömmlichen Datenbankmodulen wie Executoren, Optimierern und Speicher. Die Cluster-Kommunikation ist einzigartig für verteilte Datenbanken. Die Optimierung der Clusterleistung hat einen großen Einfluss auf die Lokalisierung von Clusterproblemen.

Die folgende Abbildung stellt eine Übersicht über den GaussDB (DWS)-Cluster dar. Durch die gemeinsame Nutzung von Inhalten wurde die Darstellung vereinfacht. GaussDB (DWS) ist eine verteilte MPP-Datenbank, die die Share Nothing-Architektur nutzt. Daten werden in verschiedenen DN-Knoten verteilt und gespeichert. CN speichert keine Daten. Als Einstiegspunkt für den Empfang von Abfragen wird der generierte Plan zur möglichst parallelen Ausführung an DN weitergeleitet, um die Leistung zu verbessern. Wenn DN einen Multi-Table-Join durchführt, ist ein Datenaustausch zwischen DNs erforderlich, um Tabellendaten oder Zwischenergebnisse zentral zu verteilen, da der lokale DN nur Teildaten enthält.

Datenkommunikationsprozess der allgemeinen Abfrage von GaussDB (DWS) : (grüner Pfeil)

Der Client stellt eine Verbindung zum CN her und gibt die Abfrage aus.
CN verbindet alle DNs, generiert und gibt Ausführungspläne aus;
Tabellendaten oder Zwischenergebnisse zwischen DNs über das Netzwerk austauschen;
DN führt die Datenverarbeitung lokal durch und gibt die Ergebnismenge an CN zurück.
CN aggregiert und verarbeitet die Ergebnismenge und gibt sie an den Client zurück.

Übersicht über die GaussDB(DWS) -Clusterkommunikation

2. Einführung in das CN-Kommunikationsframework

1. IP- und Portinformationen

Der Client stellt über den IP-Port eine Verbindung zu CN her. Die Systemtabelle pgxc_node in CN speichert die IP- und Portinformationen aller Knoten im Cluster und hilft CN dabei, eine Verbindung zu anderen Knoten im Cluster herzustellen.

In der Systemtabelle pgxc_node in der folgenden Abbildung sind node_port und node_host Hostinformationen; node_port1 und node_host1 sind Standby-Informationen. hostis_primary hat eine Master-Standby-Beziehung. Wenn dies der Fall ist, stellt CN zuerst eine Verbindung zum Host und dann zum Standby her und umgekehrt. Der hostis_primary-Wert wird von der CM-Cluster-Verwaltungskomponente beim Aktiv-/Standby-Umschalten automatisch aktualisiert.

2. Der Client kommuniziert mit CN

Der Client führt den Abfrageprozess aus:

Der Client initiiert eine Verbindung zum Überwachungsport von CN;
Der CN-Postmaster-Hauptthread akzeptiert die Verbindung, erstellt einen Postgres-Thread und übergibt die Verbindung zur Verarbeitung an diesen Thread.
Der Client sendet die Anfrage an den CN;
Der Postgres-Thread des CN übermittelt den Abfrageplan an andere CNs/DNs und die Abfrageergebnisse werden über den ursprünglichen Pfad an den Client zurückgegeben.
Die Client-Anfrage endet und die Verbindung wird geschlossen;
Der entsprechende Postgres-Thread auf CN wird zerstört und beendet.

Diagramm der Kommunikation zwischen Client und CN

Der Vorgang zum Herstellen einer Verbindung zwischen CN und DN ist grundsätzlich derselbe wie der zwischen Client und CN. Um den Aufwand für den Verbindungsaufbau zwischen CN und DN sowie für die Erstellung und Zerstörung von Postgres-Threads im DN-Prozess zu reduzieren, implementiert die CN-Seite einen Pooler-Verbindungspool.

3. Pooler- Verbindungspool

Der Pooler-Verbindungspool speichert alle Verbindungen zwischen CN und anderen CN/DN-Prozessen. Jede Verbindung entspricht einem Postgres-Thread auf anderen CN/DN. Der Pooler-Verbindungspool reduziert den Aufwand für das Herstellen von Verbindungen sowie das Erstellen und Zerstören von Postgres-Threads durch die Wiederverwendung von Verbindungen und Threads.

Pooler- Wiederverwendungsprozess:

Wenn die Sitzung eine Verbindung herstellen muss, suchen Sie über DB+USER den richtigen Pooler-Verbindungspool für den Schlüssel und nehmen Sie zuerst die vorhandene Verbindung daraus.
Nach Abschluss der Abfrage gibt der Postgres-Thread von CN die Verbindung nicht zurück und die Verbindung kann für die nächste Abfrage der aktuellen Sitzung verwendet werden.
Nach Beendigung der Sitzung stellt der Postgres-Thread von CN die Verbindung zum entsprechenden Pooler zurück. Der Postgres-Thread auf dem entsprechenden DN wird nicht beendet. Er befindet sich in ReadCommand und wartet darauf, dass der neue Postgres-Thread von CN nach der Wiederverwendung eine Aufgabe initiiert.

Pooler- Verbindungspooldiagramm

4. Pooler- Ansicht

Die Ansicht pg_pooler_status zeichnet alle Verbindungsinformationen im Pooler-Verbindungspool auf. Wie in der folgenden Abbildung dargestellt, stellt jede Zeile eine von diesem CN initiierte Verbindung dar, die einem Postgres-Thread des Gegenstückprozesses entspricht. in_use ist „t“, was bedeutet, dass die Verbindung von einem Thread verwendet wird, und „f“, was bedeutet, dass die inaktive Verbindung auf Wiederverwendung wartet. tid wird als Thread-Nummer dieses CN aufgeführt, der diese Verbindung hält, node_name wird als Peer-Prozessnummer aufgeführt und remote_pid wird als Peer-Thread-Nummer aufgeführt. Wenn query_id 0 ist oder CN/DN inkonsistent sind, ermitteln Sie die CN- und DN-Verbindungsbeziehung über die Pooler-Ansicht.

5. Reinigung der Poolverbindung

Es gibt zwei Arten von Verbindungspool-Bereinigungsmechanismen: von der Sitzung gehaltene Verbindungen und Verbindungen im inaktiven Verbindungspool von Pooler.

Von der Sitzung gehaltene Verbindung:

Cache_Connection, ob der Pooler-Verbindungspool zum Zwischenspeichern von Verbindungen verwendet werden soll;
session_timeout, die Clientverbindung meldet nach dem Leerlauf-Timeout einen Fehler und beendet die Verbindung und gibt sie zurück.
enable_force_reuse_connections, erzwingen, dass die Verbindung nach Beendigung der Transaktion zurückgegeben wird;
conn_recycle_timeout (2.1), gibt die Verbindung zurück, nachdem die CN-Leerlaufsitzung abgelaufen ist.

Pooler-Verbindungen im Leerlauf-Verbindungspool:

pg_clean_free_conn, bereinigt 1/4 der inaktiven Verbindungspoolverbindungen, CM ruft es regelmäßig auf;
Bereinigen Sie die Verbindung. Bereinigen Sie alle inaktiven Verbindungen, die der Datenbank oder dem Benutzer entsprechen.

3. Einführung in das DN-Kommunikationsframework

1. Stream- Betreiber

GaussDB (DWS) ist eine verteilte MPP-Datenbank, die die Share Nothing-Architektur verwendet. Daten werden in verschiedenen DN-Knoten gespeichert. Daten in zwei Tabellen, die die Join-Bedingungen erfüllen, müssen auf demselben DN verteilt werden. Tabellen, die die Bedingungen nicht erfüllen, müssen verteilt werden neu verteilt. Das heißt, es wird ein Stream-Operator generiert.

Jeder Stream-Operator benötigt zwei Threads, um asynchrone Netzwerk-E/A zu verarbeiten. Die untere Schicht, die Daten sendet, wird als Produzent bezeichnet, und die obere Schicht, die Daten empfängt, wird als Verbraucher bezeichnet.

2. Thread streamen

Jeder Stream-Operator auf DN muss einen Stream-Thread starten, um Netzwerkdaten asynchron zu senden. Wenn SMP-Parallelität aktiviert ist, muss ein Stream-Operator möglicherweise mehrere Stream-Threads starten und mehr Verbindungen zwischen DNs herstellen. Es gibt drei Arten von Stream-Operatoren (Streaming):

GATHER: CN kommuniziert mit DN und sammelt DN-Ergebnissätze
BROADCAST: DN sendet alle lokalen Daten an andere DNs
REDISTRIBUTE: Der DN hasht die lokalen Daten und sendet sie an den entsprechenden DN.

3. Thread-Pool streamen

Der Stream-Thread-Pool implementiert die Wiederverwendung von DN-Stream-Threads und vermeidet den Mehraufwand für die Erstellung, Initialisierung, Bereinigung und Zerstörung von Stream-Threads.

Der Stream-Thread-Pool wird mithilfe einer sperrenfreien Warteschlange implementiert. 2000 Stream-Threads werden gleichzeitig gestartet und die Zeit wird von 2 Sekunden auf 10 ms optimiert. Wenn der Stream-Operator einen Stream-Thread benötigt, gleicht er den entsprechenden Stream-Thread-Pool über den DB-Namen ab und verwendet zunächst die vorhandenen Threads derselben DB wieder. Der erstellte Stream-Thread wird in den Thread-Pool gestellt, um nach Abschluss der Abfrage auf die Wiederverwendung zu warten. Die Threads im Stream-Thread-Pool selbst haben im Leerlauf eine Timeout-Funktion und alle 60 Sekunden wird 1/4 recycelt. Der Parameter max_stream_pool legt die Obergrenze des Thread-Pool-Cache fest. Wenn er 0 ist, ist die Stream-Thread-Pool-Funktion deaktiviert. Er kann auch vorübergehend so eingestellt werden, dass der Stream-Thread bereinigt wird.

Stream- Thread-Pool-Diagramm

4. Libcomm- Kommunikationsbibliothek

Wenn der Cluster 1000 DNs erreicht, muss jeder Stream-Thread 1000 Verbindungen herstellen. Wenn 1000 Stream-Threads gleichzeitig ausgeführt werden, muss DN insgesamt 1 Million Verbindungen herstellen, was viele Verbindungs-, Speicher- und FD-Ressourcen verbraucht. Basierend auf dieser Situation wurde die Libcomm-Kommunikationsbibliothek entworfen. Die Libcomm-Kommunikationsbibliothek simuliert n logische Verbindungen auf einer physischen langen Verbindung, sodass alle gleichzeitigen Daten auf einer physischen Verbindung laufen, was das Problem der übermäßigen Anzahl physischer Verbindungen und der Zeit- aufwändiger Verbindungsaufbau. Das Problem.

4. Lokalisierung von Kommunikationsproblemen

1. Kommunikationsproblem

Schritte zum Auffinden von Kommunikationsproblemen:

Suchen Sie die query_id der Problemabfrage in der Ansicht pgxc_stat_activity.
Fragen Sie die pgxc_thread_wait_status-Ansicht basierend auf query_id ab.
Nach dem Herausfiltern des Warteknotens, dem Leeren von Daten und dem Synchronisieren des Beendigungsstatus wird der Abfrageblockierungspunkt gefunden.
Wenn sich alle oben genannten drei Zustände in den oben genannten drei Zuständen befinden, verwenden Sie zur weiteren Positionierung die logische Verbindungsansicht von Libcomm.

2. Kommunikationsfehlerproblem

Häufige Kommunikationsfehlerprobleme sind in der Abbildung dargestellt:

3. Lokalisierung von Kommunikationsleistungsproblemen

Nutzen Sie die EXPLAIN-Leistungsanalyse;

Suchen Sie den Hot-Blocking-Stack entsprechend dem Hang-Problem.
Verwenden Sie das gsar-Tool, um zu überprüfen, ob in der Umgebung Netzwerkpaketverluste und Neuübertragungen auftreten.

4. Probleme mit der Netzwerkumgebung

Verwenden Sie das gsar-Tool, um zu bestätigen, ob Netzwerkpaketverluste und Neuübertragungen auftreten.
Verwenden Sie den Befehl netstat, um zu bestätigen, über welche Verbindung die erneute Übertragung erfolgt.

Verwenden Sie den Befehl top, um zu überprüfen, ob die CPU-Auslastung des ksoftirq-Prozesses auf den Computern an beiden Enden der Verbindung abnormal ist.
Verwenden Sie Ping, Telnet und TCPdump, um Paketverlustprobleme weiter zu analysieren.

Damit ist diese Freigabe beendet. Weitere Informationen zur technischen Analyse von GaussDB (DWS)-Produkten und zur Einführung neuer Funktionen von Data Warehouse-Produkten finden Sie im GaussDB (DWS)-Forum. Technische Blog-Sharing- und Live-Übertragungsvereinbarungen werden veröffentlicht auf GaussDB (DWS) so schnell wie möglich. Forum.

Forum-Link: https://bbs.huaweicloud.com/forum/forum-598-1.html

Link zur Live-Wiedergabe: https://bbs.huaweicloud.com/live/cloud_live/202312191630.html

Klicken Sie hier, um zu folgen und so schnell wie möglich mehr über die neuen Technologien von Huawei Cloud zu erfahren~