Durch die Vorbereitung einer transparenten Übertragung unter Proxy wird GaussDB (für MySQL) stabiler und leistungsfähiger

Von Daten bis hin zu großen Modellanwendungen: Am 25. November fand die Hangzhou Yuanchuang-Konferenz statt, um Entwicklungstipps auszutauschen.

Dieser Artikel wurde von der Huawei Cloud Community geteilt. „ Bereiten Sie eine transparente Übertragung unter Proxy vor, um GaussDB (für MySQL) stabiler und leistungsfähiger zu machen “, Autor: GaussDB-Datenbank.

1. Einführung

In vielen Geschäftsszenarien verarbeiten Datenbankanwendungen eine große Anzahl derselben SQL-Anweisungen – sie ändern lediglich den Text oder die Variablenwerte in den SQL-Anweisungen. Beispiel: Verwenden Sie dieselbe SQL-Vorlage für WHERE-Abfrage-, SET-Aktualisierungs- und VALUES-Einfügevorgänge. Nach dem Empfang der SQL-Anweisung in der Datenbank muss diese analysiert, also in eine maschinenausführbare Sprache übersetzt werden. Eine große Anzahl ähnlicher Anweisungen muss wiederholt übersetzt werden. GaussDB (für MySQL) unterstützt das Prepare-Protokoll, um den Arbeitsaufwand durch wiederholte Übersetzungen zu reduzieren. Das Prepare-Protokoll verwendet ein effizientes Client/Server-Binärprotokoll und verwendet Platzhalter anstelle von Parameterwerten in vorbereiteten Anweisungen, sodass jede vorbereitete Anweisung nur einmal analysiert werden muss, wodurch der Datenbankaufwand reduziert wird.

Darüber hinaus bedenken viele Programmierer aufgrund des unterschiedlichen Niveaus und der Erfahrung der Programmierer nicht das Risiko einer SQL-Injection beim Schreiben von Code, was Kriminellen die Möglichkeit gibt, bösartiges SQL einzuschleusen, um die Datenbank anzugreifen. Durch die SQL-Injection werden bösartige SQL-Abfragen oder Aktualisierungsanweisungen in die Eingabeparameter der Anwendung eingefügt, und die Backend-Datenbank wird bei der SQL-Analyse angegriffen. Da das Prepare-Protokoll die SQL-Vorkompilierung vor der Eingabe von Parametern abgeschlossen hat, wird die Datenbank beim Einfügen von bösartigem SQL als Parameter nicht neu kompiliert, wodurch SQL-Injection-Angriffe verhindert und eine höhere Sicherheit geboten werden.

Zusammenfassend lässt sich sagen, dass das Prepare-Protokoll doppelte Vorteile hinsichtlich der Datenbankleistung und -stabilität bringen kann.

2. Bereiten Sie den Ausführungsprozess vor

Das Prepare-Protokoll ist in zwei Phasen unterteilt. Die erste Phase besteht darin, das vorkompilierte SQL mit Platzhaltern einzureichen. Die zweite Phase besteht darin, die Daten zu übertragen und die Platzhalter durch Daten zur Ausführung zu ersetzen.

Bereiten Sie ein Codebeispiel für eine Protokollanwendung vor:

3. Bereiten Sie das Protokoll im Datenbank-Proxy-Szenario (Proxy) vor

Im Artikel „ Hochverfügbarer schreibgeschützter Zugriff, der RDS für MySQL stabiler macht “ haben wir die Lösung erwähnt, einen Datenbank-Proxy (Proxy) zu verwenden, um eine Lese-/Schreibtrennung und eine hohe Zuverlässigkeit zu erreichen. GaussDB (für MySQL) unterstützt auch mehrere Proxys, um Lösungen mit hoher Zuverlässigkeit und Leistung zu erreichen, wie z. B. Lese-/Schreibtrennung, automatischer Lastausgleich und automatische Weiterleitung an andere Instanzen, wenn eine schreibgeschützte Instanz ausfällt. ——GaussDB (für MySQL) unterstützt auch mehrere Proxys, um eine Lese-/Schreibtrennung, einen automatischen Lastausgleich und eine automatische Weiterleitung an andere Instanzen zu erreichen, wenn eine schreibgeschützte Instanz ausfällt, mit hoher Zuverlässigkeit und hohen Leistungsfähigkeiten.

Der Datenbank-Proxy ist ein Netzwerk-Proxy-Dienst zwischen dem Datenbankserver und dem Anwendungsserver. Er empfängt Verbindungen von Anwendungen und verteilt SQL-Anfragen automatisch an GaussDB-Knoten (für MySQL) zur Ausführung basierend auf Routing-Bedingungen. Der Datenbank-Proxy (im Folgenden als Proxy bezeichnet) zeichnet sich durch hohe Verfügbarkeit, hohe Leistung, Betrieb und Wartung sowie Einfachheit und Benutzerfreundlichkeit aus und bietet Funktionen wie automatische Lese- und Schreibtrennung, Verbindungspooling, Transaktionsaufteilung und Sitzung Konsistenz. Das detaillierte Architekturdiagramm sieht wie folgt aus:

3.1 Implementierungsplan des Prepare-Protokolls unter Proxy

Wenn kein Proxy verwendet wird, werden die beiden Phasen des Prepare-Protokolls (Vorkompilierungsphase und Ausführungsphase) direkt auf dem Datenbankknoten ausgeführt. Da der Datenbank-Proxy nach dem Hinzufügen des Proxys unterschiedliche SQL-Anweisungen über dieselbe Verbindung an mehrere Back-End-Datenbanken verteilt, muss der Datenbank-Proxy die Korrespondenz zwischen der vorkompilierten SQL und den Ausführungsparametern speichern und sie während der Ausführung an den Datenbankknoten übergeben. ausführen am. Derzeit gibt es zwei Implementierungslösungen für das Prepare-Protokoll im Proxy-Szenario:

Textmodus (der frühere Modus)
Transparenter Übertragungsmodus (derzeit beliebter Modus)

3.1.1 Textmodus:

Der Proxy speichert intern die relevanten Informationen des vorkompilierten SQL, konvertiert das vom Client gesendete binäre Vorbereitungsprotokoll zur Übertragung in ein normales Textprotokoll , schließt das Parsen und Ersetzen auf der Proxy-Seite ab und sendet das analysierte und ersetzte SQL an die Back-End-Datenbank ohne Abhängigkeiten. Die Datenbank führt Parsing und Konvertierung durch.

Vorteil:

Die Implementierung ist einfach: Jedes SQL wird bedingungslos in Text-SQL gekapselt und direkt ausgeführt.
Kann beliebig geroutet werden.
Wenn die Verbindung zwischen dem Datenbankagenten und der Back-End-Datenbank getrennt wird, hat der Client keine Kenntnis davon und ist automatisch mit Notfallwiederherstellungsszenarien kompatibel.

Nachteile :

Es ist notwendig, die Typstruktur zu analysieren und das ursprüngliche SQL zusammenzustellen, das stark vom gesendeten Typ abhängt. Beispiel: Führen Sie SELECT * FROM t1 LIMIT aus? Wenn Sie Daten vom Typ String senden, werden diese in einen String-Wert in Anführungszeichen gespleißt: SELECT * FROM t1 LIMIT '10', die Datenbank unterstützt diese SQL-Syntax nicht, was zu einem führt Ausführungsfehler.
Da jedes SQL-Element auf der Datenbank-Proxy-Seite gespleißt werden muss und die Proxy-Seite beim Spleißen SQL-Injection-Probleme basierend auf dem Datentyp behandeln muss, weist die Proxy-Seite erhebliche Leistungseinbußen auf und kann leicht zu einem Engpass werden.

3.1.2 Transparenter Übertragungsmodus

Im transparenten Übertragungsmodus führt die Proxy-Seite nur die Vorkompilierungsphase durch und die Ausführungsphase sendet die vorkompilierten Anweisungen und Parameterdaten direkt an die Back-End-Datenbank. Das heißt, die Proxy-Seite führt keine Analyse und Kompilierung durch. Es gibt zwei Möglichkeiten, den transparenten Übertragungsmodus zu implementieren:

Transparente Broadcast-Übertragung (der von den meisten Datenbankherstellern verwendete Modus)

Bei der transparenten Broadcast-Übertragung wird die vom Client gesendete vorkompilierte Anweisung an alle Back-End-Datenbankknoten gesendet, dh alle Back-End-Datenbankknoten können die Anweisung nach Erhalt der Parameter analysieren, kompilieren und ausführen. Daher müssen Sie beim Senden von Parametern nur willkürlich einen Knoten auswählen, der die vorkompilierte Anweisung zur Übertragung gesendet hat.

Vorteil:

Der Proxy muss SQL nicht zusammenstellen und analysieren.
Der Proxy muss die Zuordnungsbeziehung zwischen vorkompilierten Anweisungen und Back-End-Datenbankknoten nicht aufrechterhalten, sondern muss nur für die Übertragung und Weiterleitung verantwortlich sein, was einfach zu implementieren ist.

Nachteile :

Alle Datenbankknoten stehen unter gleichem Druck. Dieselbe vorkompilierte Anweisung wird von mehreren Datenbankknoten ausgeführt, was zu einer Verschwendung von Ressourcen führt. Wenn ein bestimmter Knoten unter hohem Druck steht, trägt er auch den Druck kompilierter Anweisungen.
Wenn mehrere Knoten nach einer Ausnahme wiederhergestellt werden, muss der Proxy vorkompilierte Anweisungen auf allen wiederhergestellten Datenbankknoten erneut ausführen, um die Übereinstimmung zwischen Parametern und vorkompilierten Anweisungen sicherzustellen. Dies führt zu übermäßigem Druck auf den Proxy.

Transparente Einzelknotenübertragung (vom GaussDB-Agenten (für MySQL) verwendeter Modus)

Transparente Einzelknotenübertragung bedeutet, dass der Datenbankagent die vorkompilierte Anweisung gemäß der Route an einen der Knoten in der Datenbank sendet und die Zuordnungsbeziehung zwischen der vorkompilierten Anweisung und dem Datenbankknoten aufrechterhält. Wenn die Parameterdaten ausgeführt werden, werden die Parameter werden gemäß der Zuordnungsbeziehung zur Ausführung an den angegebenen Knoten gesendet.

Vorteil:

Der Proxy muss SQL nicht zusammenstellen und analysieren.
Es führt nicht zu einer Verschwendung von Back-End-Datenbankressourcen und einem übermäßigen Gesamtdruck.

Nachteile :

Die auf dem Client gespeicherten vorkompilierten Anweisungen werden an einem einzigen Punkt transparent an einen bestimmten Datenbankknoten übertragen. Während der Ausführungsphase müssen die vom Client eingegebenen Parameter an den entsprechenden Knoten weitergeleitet werden. Der Proxy muss diese Beziehung und die Funktion verwalten Die Implementierung ist komplex. Sie wird vom GaussDB-Team (für MySQL) codiert . Bringt größere Herausforderungen mit sich .

4. Leistungsvergleich

Wir haben einen Leistungstest und einen Vergleich des Prepare-Protokolls von GaussDB (für MySQL) im Textmodus und im transparenten Übertragungsmodus im Proxy-Szenario durchgeführt. Tests zeigen, dass die Leistung im transparenten Übertragungsmodus besser ist als im Textmodus, mit einer Leistungsverbesserung von etwa 28 %.

Die Hardware- und Softwarespezifikationen zur Durchführung der Tests sind in der folgenden Tabelle aufgeführt:

Obwohl wir den Leistungsvergleich zwischen dem Broadcast-Transparent-Übertragungsmodus und dem Single-Point-Transparent-Übertragungsmodus aufgrund der aktuellen Bedingungen nicht getestet haben, ist es nicht schwer, aus dem vorherigen Lösungsvergleich vorherzusagen, dass der Single-Point-Transparent-Übertragungsmodus eine höhere Stabilität aufweist Aufgrund seiner Wahrscheinlichkeit ist es weniger wahrscheinlich, dass Ressourcen auf der Proxy-Seite und auf der Datenbankknotenseite verbraucht werden, was zu Engpässen führt.

5. Zusammenfassung

Das Prepare-Protokoll unter GaussDB (für MySQL) Proxy optimiert die ursprüngliche Textmodus-Verarbeitungsmethode in einen transparenten Übertragungsmodus und verbessert seine Leistung erheblich, wodurch das Problem der starken Abhängigkeit von Datentypen im Textmodus gelöst wird. Derzeit verwendet die Branche hauptsächlich den Broadcast-Modus für die transparente Übertragung, während die Proxy-Seite von GaussDB (für MySQL) den Broadcast-Modus in einen Einzelpunkt-Übertragungsmodus optimiert, wodurch der Gesamtleistungsverlust der Datenbank verringert wird.

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