Load Balancing erhöht die Systemleistung, insbesondere aus Anwendungssicht, da mehrere Computer die gleichen Daten bereitstellen können. Es funktioniert so, dass die Last zwischen Client-Anfragen an Replikknoten neben dem primären oder Master-Knoten verteilt wird, während Datenbankänderungen nur an den Master-Knoten weitergeleitet werden. Alle Änderungen am Master-Knoten werden anschließend mithilfe der PostgreSQL-Streaming-Replikation an jedes Replikat weitergegeben.
Wie können Load Balancer PostgreSQL beeinflussen?
Die Verwendung von Load-Balancing soll Client-Anwendungen anweisen, sich mit dem Load-Balancing-Server zu verbinden, und die initiierten Verbindungen je nach Art der Abfrageanforderungen an die verfügbaren PostgreSQL-Knoten verteilen. Dies trägt dazu bei, die ausstehende Last auf einem bestimmten PostgreSQL-Server zu belasten, und fördert den parallelen Lastausgleich zwischen den verfügbaren Knoten innerhalb des Clusters.
Bei Verwendung von PostgreSQL gibt es bereits eine Handvoll bestehender Lösungen, um dies zum Laufen zu bringen. Diese Lösungen können nahtlos funktionieren oder der Lastausgleich kann mit der aktuellen Topologie funktionieren – mit primären und Standby-Knoten –, aber der Lastausgleich wird in der Anwendungsschicht selbst implementiert. Der Lastausgleich steht vor Herausforderungen mit Synchronisierungsproblemen, was die grundlegende Schwierigkeit für die Zusammenarbeit von Servern darstellt. Da es keine einzelne Lösung gibt, die die Auswirkungen des Synchronisierungsproblems für alle Anwendungsfälle beseitigt, gibt es mehrere Lösungen. Jede Lösung geht dieses Problem auf unterschiedliche Weise an und minimiert seine Auswirkungen für eine bestimmte Arbeitslast.
In diesem Blog werfen wir einen Blick auf diese Load Balancer, indem wir sie vergleichen und wie vorteilhaft sie für Ihre PostgreSQL-Workload sind.
HAProxy-Lastausgleich für PostgreSQL
HAProxy ist eine ereignisgesteuerte, nicht blockierende Engine, die einen Proxy mit einer sehr schnellen E/A-Schicht und einem prioritätsbasierten Multithread-Scheduler kombiniert. Da es mit Blick auf ein Datenweiterleitungsziel entwickelt wurde, ist seine Architektur so konzipiert, dass es in einem leichtgewichtigen Prozess arbeitet, der darauf optimiert ist, Daten so schnell wie möglich mit möglichst wenigen Vorgängen zu verschieben. Es konzentriert sich auf die Optimierung der CPU-Cache-Effizienz, indem Verbindungen so lange wie möglich mit derselben CPU verbunden bleiben. Als solches implementiert es ein Schichtenmodell, das Bypass-Mechanismen auf jeder Ebene bietet, um sicherzustellen, dass Daten nur dann höhere Ebenen erreichen, wenn dies erforderlich ist. Der größte Teil der Verarbeitung wird im Kernel durchgeführt. HAProxy tut sein Bestes, um dem Kernel zu helfen, die Arbeit so schnell wie möglich zu erledigen, indem es einige Hinweise gibt oder bestimmte Operationen vermeidet, wenn es vermutet, dass sie später gruppiert werden könnten. Als Ergebnis zeigen typische Zahlen, dass 15 % der Verarbeitungszeit in HAProxy gegenüber 85 % im Kernel im TCP- oder HTTP-Schließmodus und etwa 30 % für HAProxy gegenüber 70 % für den Kernel im HTTP-Keep-Alive-Modus aufgewendet werden.
HAProxy hat auch zusätzliche Funktionen zum Lastenausgleich. Die TCP-Proxy-Funktion ermöglicht es uns beispielsweise, sie für Datenbankverbindungen zu verwenden, insbesondere für PostgreSQL, indem die integrierte Prüfdienstunterstützung verwendet wird. Obwohl Datenbankdienstunterstützung vorhanden ist, reicht dies nicht für die gewünschte Zustandsprüfung aus, insbesondere für einen Replikationstyp von Clustern. Der Standardansatz bei der Bereitstellung für die Produktion besteht darin, die TCP-Prüfung zu verwenden und sich dann auf xinetd mit HAProxy zu verlassen.
Vorteile der Verwendung von HAProxy für PostgreSQL
Das Beste an HAProxy ist, dass es leicht, einfach zu konfigurieren und zu verwenden ist und seine Arbeit wie erwartet erledigt. Die Verwendung von HAProxy auf einem PostgreSQL-Cluster wurde mehrfach von großen Organisationen für verschiedene KMUs/KMUs für deren Produktionsnutzung implementiert und bereitgestellt. Es hat sich seit langem für die Produktion und hohe Workload-Kapazität nicht nur für Datenbanken, sondern auch für andere Netzwerkdienste wie Webanwendungen oder für Geo-Load-Balancing (Verteilung des Datenverkehrs auf mehrere Rechenzentren) bewährt. HAProxy auf PostgreSQL bietet Benutzern die Möglichkeit, Antworten zu drosseln oder zu begrenzen, um die Last korrekt zu parallelisieren und auf alle verfügbaren Knoten im Cluster zu verteilen. Der integrierte Mechanismus mit HAProxy ermöglicht es dem Benutzer auch, Hochverfügbarkeit nahtlos einzurichten und bei Bedarf leichter zu skalieren und Single Point of Failure (SPOF) zu vermeiden.
Nachteile der Verwendung von HAProxy für PostgreSQL
HAProxy bietet weder eine Abfragefilterung noch eine Abfrageanalyse, um die Art der angeforderten Anweisungen zu identifizieren. Es fehlt die Fähigkeit, eine Lese-/Schreibaufteilung auf einem einzelnen Port durchzuführen. Das Einrichten eines Lastenausgleichs auf HAProxy erfordert, dass Sie mindestens unterschiedliche Ports für Ihre Schreibvorgänge und unterschiedliche für Ihre Lesevorgänge einrichten müssen. Dies erfordert Anwendungsänderungen, die Ihren Anforderungen entsprechen.
HAProxy bietet auch eine sehr einfache Funktionsunterstützung mit PostgreSQL für die Zustandsprüfung, jedoch bestimmt dies nur, ob der Knoten aktiv ist oder nicht, als ob es nur den Knoten pingen und auf eine Bounce-Back-Antwort warten würde. Es gibt nicht an, welche Rolle ein Knoten spielt, um die angeforderten Verbindungen vom Client an den gewünschten Knoten weiterzuleiten. Daher versteht es nicht oder keine Funktion in HAProxy, um die Replikationstopologie zu verstehen. Obwohl ein Benutzer separate Listener basierend auf verschiedenen Ports erstellen kann, fügt er dennoch Änderungen innerhalb der Anwendung hinzu, um die Lastausgleichsanforderungen zu erfüllen. Dies bedeutet, dass entweder die Verwendung eines externen Skripts mit xinetd die Problemumgehung sein kann, um die Anforderungen zu erfüllen. Dennoch ist es nicht in HAProxy integriert und kann anfällig für menschliche Fehler sein.
Wenn ein Knoten oder eine Gruppe von Knoten in den Wartungsmodus versetzt werden muss, müssen Sie auch Änderungen an Ihrem HAProxy vornehmen, andernfalls kann es katastrophal werden.
Pgpool-II für den Lastenausgleich Ihres PostgreSQL
Pgpool-II ist eine Open-Source-Software und wird von der massiven PostgreSQL-Community für die Implementierung des Lastausgleichs angenommen und verwendet dies, um als ihre Middleware von der Anwendung bis zur Proxy-Schicht zu fungieren und dann die Last zu verteilen nachdem es die Art der Anfrage pro Abfrage oder Datenbankverbindung vollständig analysiert hat. Pgpool-II gibt es schon so lange seit 2003, das ursprünglich Pgpool hieß, bis es 2006 zu Pgpool-II wurde, was als Beweis für ein sehr stabiles Proxy-Tool dient, das nicht nur für den Lastausgleich, sondern auch für jede Menge cooler Funktionen dient .
Pgpool-II ist als das Schweizer Taschenmesser für PostgreSQL bekannt und ist eine Proxy-Software, die zwischen PostgreSQL-Servern und einem PostgreSQL-Datenbankclient sitzt. Die Grundidee von PgPool-II ist, dass es sich auf dem Client befindet, dann müssen Leseabfragen an die Standby-Knoten übermittelt werden, während das Schreiben oder die Änderungen direkt an den primären Knoten gehen. Es handelt sich um eine sehr intelligente Load-Balancing-Lösung, die nicht nur Load-Balancing durchführt, sondern auch Hochverfügbarkeit unterstützt und Verbindungs-Pooling bereitstellt. Der intelligente Mechanismus ermöglicht den Lastausgleich zwischen Master und Slave. Schreibvorgänge werden also auf den Master geladen, während Verarbeitungslesevorgänge an die verfügbaren Nur-Lese-Server geleitet werden, die Ihre angeblichen Hot-Standby-Knoten sind. Pgpool-II bietet auch eine logische Replikation. Obwohl seine Verwendung und Bedeutung mit der Verbesserung der integrierten Replikationsoptionen auf der PostgreSQL-Serverseite abgenommen hat, bleibt dies immer noch eine wertvolle Option für ältere Versionen von PostgreSQL. Darüber hinaus bietet es auch Connection Pooling.
Pgpool-II hat eine kompliziertere Architektur als PgBouncer, um alle seine Funktionen zu unterstützen. Da beide Connection Pooling unterstützen, hat letzteres keine Load-Balancing-Funktionen.
Pgpool-II kann mehrere PostgreSQL-Server verwalten. Die Verwendung der Replikationsfunktion ermöglicht die Erstellung einer Echtzeitsicherung auf 2 oder mehr physischen Festplatten, sodass der Dienst im Falle eines Festplattenausfalls fortgesetzt werden kann, ohne Server anzuhalten. Da Pgpool-II auch Connection-Pooling-fähig ist, kann es für eine Begrenzung der überzähligen Verbindungen sorgen. Die maximale Anzahl gleichzeitiger Verbindungen mit PostgreSQL ist begrenzt, und Verbindungen werden nach so vielen Verbindungen abgelehnt. Das Festlegen der maximalen Anzahl von Verbindungen erhöht jedoch den Ressourcenverbrauch und beeinträchtigt die Systemleistung. pgpool-II hat auch eine Begrenzung der maximalen Anzahl von Verbindungen, aber zusätzliche Verbindungen werden in die Warteschlange gestellt, anstatt sofort einen Fehler zurückzugeben.
Beim Lastenausgleich:Wenn eine Datenbank repliziert wird, führt die Ausführung einer SELECT-Abfrage auf einem beliebigen Server zum gleichen Ergebnis. pgpool-II nutzt die Replikationsfunktion, um die Last auf jedem PostgreSQL-Server zu reduzieren, indem SELECT-Abfragen auf mehrere Server verteilt werden, wodurch der Gesamtdurchsatz des Systems verbessert wird. Im besten Fall verbessert sich die Leistung proportional zur Anzahl der PostgreSQL-Server. Der Lastenausgleich funktioniert am besten in einer Situation, in der viele Benutzer viele Abfragen gleichzeitig ausführen.
Mithilfe der parallelen Abfragefunktion können Daten auf mehrere Server aufgeteilt werden, sodass eine Abfrage auf allen Servern gleichzeitig ausgeführt werden kann, um die Gesamtausführungszeit zu verkürzen. Parallele Abfragen funktionieren am besten, wenn umfangreiche Daten durchsucht werden.
Vorteile der Verwendung von Pgpool für PostgreSQL
Es ist eine funktionsreiche Art von Software, nicht nur für den Lastenausgleich. Die Kernfunktionen und die Unterstützung dieses Tools sind hochgradig bedarfsorientiert und bieten Verbindungspooling, einen alternativen Go-PgBouncer, native Replikation, Online-Wiederherstellung, In-Memory-Abfrage-Caching, automatisches Failover und Hochverfügbarkeit mit seinem Unterprozess, der Watchdog verwendet. Dieses Tool ist so alt und wird von der PostgreSQL-Community kontinuierlich massiv unterstützt, sodass es nicht schwer sein kann, Hilfe bei der Bewältigung von Problemen zu suchen. Die Dokumentation ist hier Ihr Freund, wenn Sie Fragen suchen, aber die Suche nach Hilfe in der Community ist nicht schwierig, und die Tatsache, dass dieses Tool Open Source ist, können Sie frei verwenden, solange Sie die BSD-Lizenz einhalten.
Pgpool-II hat auch einen SQL-Parser. Dies bedeutet, dass es in der Lage ist, die SQLs genau zu analysieren und die Abfrage neu zu schreiben. Dadurch kann Pgpool-II die Parallelität je nach Abfrageanforderung erhöhen.
Nachteile der Verwendung von Pgpool für PostgreSQL
Pgpool-II bietet kein STONITH (dem anderen Knoten in den Kopf schießen), das einen Knoten-Fencing-Mechanismus bereitstellt. Wenn der PostgreSQL-Server ausfällt, hält er die Dienstverfügbarkeit aufrecht. Pgpool-II kann auch der Single Point of Failure (SPOF) sein. Sobald der Knoten ausfällt, stoppt Ihre Datenbankkonnektivität und -verfügbarkeit ab diesem Punkt. Obwohl dies behoben werden kann, indem Redundanz mit Pgpool-II vorhanden ist und Watchdog verwendet werden muss, um mehrere Pgpool-II-Knoten zu koordinieren, fügt dies zusätzliche Arbeit hinzu.
Für diejenigen, die sich nur auf das Verbindungspooling konzentrieren, eignet sich Pgpool-II leider nicht sehr gut für das Verbindungspooling, insbesondere für eine kleine Anzahl von Clients. Da jeder untergeordnete Prozess seinen eigenen Pool hat und es keine Möglichkeit gibt, zu kontrollieren, welcher Client sich mit welchem untergeordneten Prozess verbindet, wird bei der Wiederverwendung von Verbindungen zu viel dem Glück überlassen.
Verwenden des JDBC-Treibers zum Lastenausgleich Ihres PostgreSQL
Java Database Connectivity (JDBC) ist eine Anwendungsprogrammierschnittstelle (API) für die Programmiersprache Java, die definiert, wie ein Client auf eine Datenbank zugreifen darf. Es ist Teil der Java Standard Edition-Plattform und bietet Methoden zum Abfragen und Aktualisieren von Daten in einer Datenbank und orientiert sich an relationalen Datenbanken.
Der PostgreSQL-JDBC-Treiber (kurz PgJDBC) ermöglicht es Java-Programmen, eine Verbindung zu einer PostgreSQL-Datenbank herzustellen, indem standardmäßiger, datenbankunabhängiger Java-Code verwendet wird. Ist ein Open-Source-JDBC-Treiber, der in Pure Java (Typ 4) geschrieben ist und im nativen PostgreSQL-Netzwerkprotokoll kommuniziert. Aus diesem Grund ist der Treiber plattformunabhängig; Einmal kompiliert, kann der Treiber auf jedem System verwendet werden.
Es ist nicht vergleichbar mit Load-Balancing-Lösungen, auf die wir zuvor hingewiesen haben. Daher ist dieses Tool Ihre Anwendungsprogrammierschnittstellen-API, mit der Sie von Ihrer Anwendung aus eine Verbindung für jede Art von Programmiersprache herstellen können, die JDBC unterstützt oder zumindest über einen Adapter für die Verbindung mit JDBC verfügt. Günstiger ist es dagegen bei Java-Anwendungen.
Der Lastausgleich mit JDBC ist ziemlich naiv, kann aber die Arbeit erledigen. Ausgestattet mit den Verbindungsparametern, die den Load-Balancing-Mechanismus auslösen können, den dieses Tool zu bieten hat,
- targetServerType – ermöglicht das Öffnen von Verbindungen nur zu Servern mit dem erforderlichen Status/der erforderlichen Rolle gemäß dem Definitionsfaktor für die PostgreSQL-Server. Die zulässigen Werte sind „any“, „primary“, „master“ (veraltet), „slave“ (veraltet), „sekundär“, „preferSlave“ und „preferSecondary“. Der Status oder die Rolle wird bestimmt, indem beobachtet wird, ob der Server Schreibvorgänge zulässt oder nicht.
- hostRecheckSeconds - steuert, wie lange in Sekunden das Wissen über einen Hoststatus im JVM-weiten globalen Cache zwischengespeichert wird. Der Standardwert ist 10 Sekunden.
- loadBalanceHosts – erlaubt Ihnen zu konfigurieren, ob immer der erste Host versucht wird (wenn auf „false“ gesetzt) oder ob Verbindungen zufällig ausgewählt werden (wenn auf „true“ gesetzt)
Verwenden Sie also loadBalanceHosts, das einen booleschen Wert akzeptiert. loadBalanceHosts ist im Standardmodus deaktiviert und Hosts werden in der angegebenen Reihenfolge verbunden. Wenn aktiviert, werden Hosts zufällig aus der Menge geeigneter Kandidaten ausgewählt. Die grundlegende Syntax beim Herstellen einer Verbindung zur Datenbank mithilfe von jdbc lautet wie folgt:
- jdbc:postgresql:database
- jdbc:postgresql:/
- jdbc:postgresql://host/database
- jdbc:postgresql://host/
- jdbc:postgresql://host:port/database
- jdbc:postgresql://host:port/
Angesichts der Tatsache, dass loadBalanceHosts und die Verbindung mehrere Hosts empfangen, die genau wie unten konfiguriert sind,
jdbc:postgresql://host1:port1,host2:port2,host3:port3/databaseDies ermöglicht JDBC, zufällig aus der Menge geeigneter Kandidaten auszuwählen.
Vorteile der Verwendung von PgJDBC für PostgreSQL
Keine Notwendigkeit für Middleware oder Proxy als Load Balancer. Dieser Prozess erhöht die Leistung des Anwendungs-Frontends weiter, da es keine zusätzliche Ebene für jede Anforderung gibt, die passieren muss. Wenn Sie Anwendungen bereit haben und geschrieben sind, um die Schnittstelle zu JDBC zu unterstützen, kann dies von Vorteil sein und wenn Sie keine weitere Middleware benötigen, insbesondere wenn Ihr Budget knapp ist und Sie nur die Prozesse einschränken möchten, die ausschließlich ihrem Zweck und ihrer Funktion gewidmet sind. Anders als bei Anwendungen mit hohem Datenverkehr und großer Nachfrage kann es erforderlich sein, dass Proxy-Server als Load Balancer fungieren und zusätzliche Ressourcen erfordern, um hohe Verbindungsanforderungen ordnungsgemäß zu verarbeiten, was auch eine CPU- und Speicherverarbeitung erfordert.
Nachteile der Verwendung von PgJDBC für PostgreSQL
Sie müssen Ihren Code für jede anzufordernde Verbindung einrichten. Es handelt sich um eine Anwendungsprogrammierschnittstelle, was bedeutet, dass einiges an Arbeit dahintersteckt, insbesondere wenn Ihre Anwendung sehr hohe Anforderungen an jede Anforderung stellt, die an die richtigen Server gesendet werden soll. Es gibt keine hohe Verfügbarkeit, keine automatische Skalierbarkeit und einen Single-Point-of-Failure.
Wie wäre es mit Wrappern oder Tools, die mit libpq für den Lastenausgleich Ihres PostgreSQL implementiert werden?
libpq ist die Schnittstelle des C-Anwendungsprogrammierers zu PostgreSQL. libpq ist eine Reihe von Bibliotheksfunktionen, die es Client-Programmen ermöglichen, Abfragen an den PostgreSQL-Backend-Server weiterzuleiten und die Ergebnisse dieser Abfragen zu empfangen.
libpq ist auch die zugrunde liegende Engine für mehrere andere PostgreSQL-Anwendungsschnittstellen, einschließlich derer, die für C++, PHP, Perl, Python, Tcl, Swift und ECPG geschrieben wurden. Daher werden einige Aspekte des Verhaltens von libpq für Sie wichtig sein, wenn Sie eines dieser Pakete verwenden.
libpq automatisiert das Load-Balancing nicht und ist nicht als Tool für Load-Balancing-Lösungen zu betrachten. Es ist jedoch in der Lage, eine Verbindung zu den nächsten verfügbaren Servern herzustellen, wenn die vorherigen Server, die für die Verbindung aufgelistet sind, ausfallen. Wenn Sie beispielsweise zwei verfügbare Hot-Standby-Knoten haben und der erste Knoten zu beschäftigt ist und nicht auf den entsprechenden Zeitüberschreitungswert antwortet, stellt er eine Verbindung zum nächsten verfügbaren Knoten in der angegebenen Verbindung her. Es hängt davon ab, welche Art von Sitzungsattributen Sie angegeben haben. Dies beruht auf dem Parameter target_session_attrs.
Der Parameter target_session_attrs akzeptiert Werte read-write und any, was der Standardwert ist, wenn nicht angegeben. Was der Parameter target_session_attrs bedeutet, ist, wenn er auf Read-Write gesetzt ist, nur eine Verbindung, in der Read-Write-Transaktionen während der Verbindung akzeptiert werden. Die Abfrage SHOW transaction_read_only wird bei jeder erfolgreichen Verbindung gesendet. Wenn das Ergebnis eingeschaltet ist, wird die Verbindung geschlossen, was bedeutet, dass der Knoten als Replikat identifiziert wird oder keine Schreibvorgänge verarbeitet. Wenn mehrere Hosts in der Verbindungszeichenfolge angegeben wurden, werden alle verbleibenden Server ausprobiert, als ob der Verbindungsversuch fehlgeschlagen wäre. Der Standardwert dieses Parameters ist beliebig, was bedeutet, dass alle Verbindungen akzeptabel sind. Obwohl es für den Lastausgleich nicht ausreicht, sich auf target_session_attrs zu verlassen, können Sie möglicherweise eine Round-Robin-Methode simulieren. Siehe meinen Beispiel-C-Code unten mit libpq,
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <unistd.h>
#include <libpq-fe.h>
const char* _getRoundRobinConn() {
char* h[2];
h[0] = "dbname=node40 host=192.168.30.40,192.168.30.50";
h[1] = "dbname=node50 host=192.168.30.50,192.168.30.40";
time_t t;
//srand((unsigned)time(&t));
sleep(1.85);
srand((unsigned)time(NULL));
return h[rand() % 2];
}
void
_connect()
{
PGconn *conn;
PGresult *res;
char strConn[120];
snprintf(strConn, 1000, "user=dbapgadmin password=dbapgadmin %s target_session_attrs=any", _getRoundRobinConn());
//printf("\nstrConn value is: %s\n", strConn);
conn = PQconnectdb(strConn);
res = PQexec(conn, "SELECT current_database(), inet_client_addr();");
if ( PQresultStatus(res)==PGRES_TUPLES_OK )
{
printf("current_database = %s on %s\n", PQgetvalue(res, 0, 0),
PQhost(conn));
} else {
printf("\nFailed... Message Code is: %d\n", PQresultStatus(res));
}
PQclear(res);
PQfinish(conn);
}
int main(void)
{
int i;
for (i=0 ; i<5 ; i++)
_connect();
return 0;
}Das Ergebnis verrät,
[email protected]:/home/vagrant# gcc -I/usr/include/postgresql -L/usr/lib/postgresql/12/lib libpq_conn.c -lpq -o libpq_conn; ./libpq_conn
current_database = node40 on 192.168.30.40
current_database = node40 on 192.168.30.40
current_database = node50 on 192.168.30.50
current_database = node40 on 192.168.30.40
current_database = node50 on 192.168.30.50Beachten Sie, dass, wenn Knoten .40 (der primäre Knoten) ausfällt, er die Verbindung immer zu .50 leitet, solange Ihr target_session_attrs-Wert beliebig ist.
In diesem Fall können Sie mit Hilfe von libpq einfach Ihre eigenen frei erstellen. Obwohl der Prozess, sich auf libpq und/oder seine Wrapper zu verlassen, einfach zu grob ist, um zu sagen, dass dies den gewünschten Lastausgleichsmechanismus mit gleichmäßiger Verteilung auf die vorhandenen Knoten bereitstellen kann. Dieser Ansatz und die Codierung können definitiv verbessert werden, aber der Gedanke ist, dass dies kostenlos und Open Source ist und Sie codieren können, ohne sich auf Middleware zu verlassen, und die Art und Weise, wie Ihr Lastausgleich funktionieren soll, frei gestalten können.
Vorteile der Verwendung von libpq für PostgresQL
Dielibpq-Bibliothek ist die Anwendungsschnittstelle des Programmierers, die in der Programmiersprache C erstellt wurde. Die Bibliothek wurde jedoch in verschiedenen Sprachen als Wrapper implementiert, sodass Programmierer mit der PostgreSQL-Datenbank in ihren bevorzugten Sprachen kommunizieren können. Sie können direkt Ihre eigene Anwendung mit Ihren bevorzugten Sprachen erstellen und dann die Server auflisten, von denen Sie beabsichtigen, dass Abfragen gesendet werden, aber erst nacheinander, wenn ein Fehler oder eine Zeitüberschreitung Ihre Last an die verfügbaren Knoten sendet, auf die Sie die Last verteilen möchten. Es ist in Sprachen wie Python, Perl, PHP, Ruby, Tcl oder Rust verfügbar.
Nachteile der Verwendung von libpq für PostgresQL
Implementierung für Lastparallelität ist nicht perfekt und Sie müssen Ihren eigenen Lastausgleichsmechanismus per Code schreiben. Es gibt keine Konfiguration, die Sie verwenden oder anpassen können, da es sich allein um eine Programmierschnittstelle zur PostgreSQL-Datenbank mit Hilfe des Parameters target_session_attrs handelt. Das bedeutet, dass Sie beim Erstellen einer Datenbankverbindung eine Reihe von Leseverbindungen zu Ihren Replikat-/Standby-Knoten haben müssen und dann Abfragen schreiben müssen, die an den Writer- oder Primärknoten in Ihrem Code gehen, unabhängig davon, ob es sich um Ihre Anwendung handelt oder Sie erstellen müssen Ihre eigene API zur Verwaltung der Load-Balancing-Lösung.
Die Verwendung dieses Ansatzes erfordert definitiv keine Middleware oder verlässt sich von der Front-End-Anwendungsperspektive auf die Datenbank als Back-End. Das ist natürlich leichtgewichtig, aber wenn Sie die Liste der Server bei der Verbindung senden, bedeutet dies nicht, dass die Last verstanden und gleichmäßig gesendet wird, es sei denn, Sie müssen Ihren Code für diesen Ansatz hinzufügen. Dies erhöht nur den Aufwand, aber es gibt bereits Lösungen, warum also das Rad neu erfinden?
Fazit
Die Implementierung Ihrer Load Balancer mit PostgreSQL kann anspruchsvoll sein, hängt jedoch von der Art der Anwendung und den Kosten ab, mit denen Sie es zu tun haben. Manchmal ist für eine hohe Lastanforderung Middleware erforderlich, die als Proxy fungiert, um die Last richtig zu verteilen und auch den Zustand oder Zustand des Knotens zu überwachen. Andererseits kann es Serverressourcen erfordern, entweder muss es auf einem dedizierten Server ausgeführt werden oder erfordert zusätzliche CPU und Speicher, um die Anforderungen zu erfüllen, und dies erhöht die Kosten. Daher gibt es auch eine einfache, aber zeitaufwändige Möglichkeit, die Last auf die verfügbaren Server zu verteilen, die Sie bereits haben. Es erfordert jedoch Programmierkenntnisse und ein Verständnis der API-Funktionalität.
