Ein Verbindungspooler ist eine Softwarekomponente, die Datenbankverbindungen verwaltet. Dies kann auf vielfältige Weise dazu beitragen, die Ressourcennutzung zu verbessern, beim Lastausgleich oder Failover zu helfen und die Transaktionszeiten erheblich zu verkürzen. In diesem Blogbeitrag werden wir sehen, was ein Verbindungspooler ist und wie man ihn konfiguriert.
Ein Verbindungspooler ist eine Softwarekomponente das Datenbankverbindungen verwaltet. Dies kann auf vielfältige Weise dazu beitragen, die Ressourcennutzung zu verbessern, beim Lastausgleich oder Failover zu helfen und die Transaktionszeiten erheblich zu verkürzen. In diesem Blogbeitrag werden wir sehen, was ein Verbindungspooler ist und wie man ihn konfiguriert.
Was ein Verbindungspooler ist und warum er nützlich ist
Das Öffnen einer Verbindung zur Datenbank dauert viele Schritte. Wir müssen eine Verbindung zum Server herstellen und den ersten Handshake durchführen, uns auf die Verschlüsselungs- und Verbindungseinstellungen einigen und dann die neue Verbindungsressource über alle Schichten (Netzwerktreiber, Betriebssystemschicht, Datenbankschicht usw.) hinweg beibehalten. Jede Verbindung verbraucht Speicher, dessen Größe von der Datenbank-Engine abhängt. Bei PostgreSQL können dies sogar 1,3 MB Speicher für eine Verbindung sein. Das Öffnen einer Verbindung nimmt ebenfalls Zeit in Anspruch, da wir die Einstellungen der neuen Verbindung aushandeln müssen.
Wenn wir für jede SQL-Abfrage ständig eine neue Verbindung öffnen, kann es zu mehreren Problemen für den Datenbankserver kommen:
Das Öffnen von Verbindungen kostet Zeit und Ressourcen, daher sind unsere Transaktionen langsamer
Wir überschreiten möglicherweise das Limit der aktiven Verbindungen (das standardmäßig auf etwas eingestellt sein kann). (z. B. hundert Verbindungen)
Datenbank verbraucht möglicherweise mehr Speicher, was sich negativ auf die Cache-Trefferquote und den für Abfragen verfügbaren freien Speicher auswirken kann
Anstatt zu öffnen Wenn wir für jede SQL-Abfrage eine neue Verbindung erstellen, können wir die Verbindungen bündeln. Wir können den Verbindungspooler konfigurieren, der die Anzahl der Verbindungen behält und sie für alle Clients wiederverwendet. Auf diese Weise stellt unsere Anwendung eine Verbindung zum Pooler statt direkt zur Datenbank her, und dann stellt der Pooler eine Verbindung zur Datenbank her. Dies bringt mehrere Vorteile mit sich:
Der Verbindungspooler hält die Verbindungen viel länger offen, was den Aufwand für das Öffnen und Schließen der Verbindungen auf der Datenbankseite reduziert und die Latenz reduziert.
Wir können einen Lastausgleich zwischen den Verbindungen oder sogar zwischen Datenbanken erreichen, was die Leistung erhöht.
Der Pooler kann eine stabile Anzahl von Verbindungen aufrechterhalten, sodass wir das Problem vermeiden von zu vielen aktiven Verbindungen, was die Ressourcennutzung reduziert.
Der Pooler kann die Verbindungen zwischen dem Primär- und dem Standby-Server umleiten, um ein Failover bereitzustellen, das die Stabilität und Skalierbarkeit erhöht.
Der Pooler kann das Passwort für die Datenbank an einem zentralen Ort speichern, was die Sicherheit erhöht.
Der Pooler kann die Ergebnisse zwischenspeichern, um die Abfrageleistung zu verbessern.
Der Verbindungspooler hat auch einige Nachteile:
Es ist eine weitere Komponente in unserem System, die zu einem Fehlerpunkt werden kann.
Die Netzwerklatenz kann sich aufgrund eines weiteren Netzwerksprungs zwischen der Anwendung und der Datenbank leicht erhöhen.
Ein ineffizienter Verbindungspooler kann zu einem Engpass werden.
Wir müssen den Verbindungspooler optimieren und warten, was den Wartungsaufwand erhöht.
Verschiedene Arten von Verbindungspooling
Es gibt viele Möglichkeiten zur Implementierung von Verbindungspooling. In diesem Abschnitt werfen wir einen Blick auf verschiedene Implementierungsdetails.
Externer oder interner Verbindungspooler
In einem typischen Fall stellen wir eine Verbindung von unserer Anwendung zur Datenbank her. Wir können einen Verbindungspooler jetzt an einer von zwei Stellen platzieren: in der Anwendung selbst oder irgendwo zwischen der Anwendung und der Datenbank.
Das Platzieren des Verbindungspools in der Anwendung (anwendungsseitiger Verbindungspooler) kann sehr einfach sein Da viele ORMs oder Datenbanktreiber dies standardmäßig unterstützen. JDBC unterstützt dies beispielsweise mit c3p0 und ODBC unterstützt dies standardmäßig. Das bringt viele Vorteile mit sich. Wir müssen keine zusätzlichen Komponenten installieren und warten, da sich der Pooler innerhalb der Anwendung befindet. Wir müssen nur die neue Version der Anwendung bereitstellen und bereiten das Pooling vor. Dies reduziert auch die Netzwerklatenz, da wir keine zusätzlichen Netzwerk-Hops haben (alles lebt in unserer Anwendung).
Leider hat der anwendungsseitige Verbindungspooler einige Nachteile. Der größte Nachteil besteht darin, dass es nur für eine Anwendung konfiguriert ist. Wenn wir viele Anwendungen haben (insbesondere in einer verteilten Umgebung), müssen wir den Pooler an vielen Stellen konfigurieren. Ganz zu schweigen davon, dass wir auf der Serverseite möglicherweise immer noch das Verbindungslimit erreichen, da die Pooler nichts voneinander wissen. Viele Verbindungspooler verursachen auch eine höhere Ressourcennutzung und sind in der Regel weniger leistungsfähig.
Wir können auch einen externen Verbindungspooler verwenden, der irgendwo zwischen der Anwendung und der Datenbank sitzt. Dies kann mit einer beliebigen Anzahl von Anwendungen funktionieren und ermöglicht uns eine genaue Kontrolle des Verbindungslimits. Ein zentraler Verbindungspooler kann auch Ressourcen besser steuern und uns ein Failover oder eine Lastverteilung ermöglichen.
Ein externer Verbindungspooler hat auch einige Nachteile. In erster Linie handelt es sich um eine weitere Komponente, die wir im Laufe der Zeit installieren, konfigurieren, optimieren und warten müssen. Wir müssen auch jede Anwendung neu konfigurieren, um den Verbindungspooler zu verwenden (was so einfach sein sollte wie das Ändern einiger Verbindungszeichenfolgen und das erneute Bereitstellen der Anwendung). Der externe Pooler führt außerdem zu einer gewissen Netzwerklatenz, da er eine weitere Netzwerkkomponente zwischen der Anwendung und der Datenbank darstellt.
Der externe Verbindungspooler kann ebenfalls zu einer Fehlerquelle werden. Wenn der Pooler aus irgendeinem Grund ausfällt, können Anwendungen keine Verbindung mehr zur Datenbank herstellen. Wenn der Pooler langsam oder ineffizient ist, wirkt sich dies auf alle Anwendungen aus, die ihn verwenden. Daher muss der Pooler von hoher Qualität sein, um die Gesamtleistung nicht zu beeinträchtigen.
Arten des Poolings
Jeder Pooler muss entscheiden, wie er den Clients Verbindungen zuweist. Im Allgemeinen gibt es drei Ansätze.
Der erste ist Session-Pooling. Bei diesem Ansatz wird die Verbindung dem Client für die Dauer der Sitzung zugewiesen (also bis der Client die Verbindung trennt oder ein Timeout erreicht wird). Dies ist der einfachste Ansatz, allerdings wird dadurch effektiv die Anzahl der Clients begrenzt, da normalerweise jeder Client eine Verbindung verbraucht.
Die nächste Lösung ist Transaktionspooling. Bei diesem Ansatz weist der Pooler die Verbindung für jede Transaktion und nur für die Transaktionsdauer zu. Wenn ein Client eine weitere Transaktion ausführen möchte, muss er eine andere Verbindung herstellen (und möglicherweise warten, bis eine andere Verbindung verfügbar ist). Dadurch kann der Pooler mehr Clients verwalten und ist der empfohlene Ansatz.
Der letzte Ansatz besteht darin, die Verbindung für jede SQL-Anweisung unabhängig zuzuweisen. Theoretisch bringt dies die höchste Flexibilität und Verbindungsauslastung. Dies führt jedoch dazu, dass sich eine Transaktion über viele Verbindungen erstreckt. Da viele Transaktionseinstellungen an die Verbindung gebunden sind, kann dies zu einer technischen Einschränkung werden.
Verbindungspooling-Lösungen
Abhängig vom verwendeten Datenbanktyp gibt es möglicherweise einige integrierte Lösungen oder Möglicherweise müssen Sie sie manuell konfigurieren. Sehen wir uns einige Beispiele an.
Integrierte Lösungen
Abhängig von Ihrem Infrastrukturanbieter können Sie möglicherweise integrierte oder nahezu integrierte Lösungen verwenden:
Neon PostgreSQL-Datenbank verfügt über einen integrierten PgBouncer
Supabase verfügt über einen integrierten Supavisor
Azure-Datenbank für PostgreSQL unterstützt integrierten PgBouncer
DigitalOceans PostgreSQL enthält PgBouncer
Azure-Datenbank kann mit ProxySql verwendet werden
Azure-Datenbank kann mit Heimdall Database Proxy verwendet werden
ADO.NET unterstützt einen integrierten Verbindungspool
Oracle unterstützt Universal Connection Pool für JDBC
Oracle Autonomous Database unterstützt Database Resident Connection Pool
Externe Lösungen
Es gibt viele externe Lösungen, die Sie nutzen können Verwenden Sie:
Amazon RDS Proxy
Pgpool
PgBouncer
odyssey
Heimdall Database Proxy
ProxySQL
pgcat
Fallstudie: Konfiguration von PgBouncer
In diesem Beispiel untersuchen wir PgBouncer.
Wir beginnen mit der Installation wie in der Dokumentation beschrieben.
Wir müssen es dann konfigurieren. Die wichtigsten Einstellungen sind:
pool_mode: Wie mit Verbindungen umgegangen wird; wir können die Transaktion verwenden
max_client_conn: Dies konfiguriert, wie viele Clients sich mit dem Verbindungspooler verbinden können
default_pool_size: Konfiguriert, wie viele Serververbindungen zulässig sind für jede Benutzerdatenbank
min_pool_size: Wie viele Standby-Verbindungen beibehalten werden sollen
Nachdem wir den Pooler konfiguriert haben, können wir seine Leistung mit pgbench überprüfen:
pgbench -c 10 -p -j 2 -t 1000 database_name
Nach dem Login kopieren
PgBouncer kann die Anzahl der Transaktionen pro Sekunde problemlos um 60 % steigern, wie in Benchmarks gezeigt:
Benchmarking PostgreSQL-Verbindungspooler: PgBouncer, PgCat und Supavisor
Datenbankleistung durch Verbindungspooling verbessern
PostgreSQL mit PgBouncer aufladen
Zusammenfassung
Verbindungspooler können die Leistung verbessern und den Ressourcenverbrauch reduzieren. Es gibt viele integrierte Lösungen, die wir problemlos mit unseren Datenbanken verwenden können, unabhängig davon, wo wir sie hosten und mit welcher Datenbank-Engine wir arbeiten. Wir müssen bedenken, dass der Verbindungspooler eine weitere Fehlerquelle darstellt und mit Vorsicht behandelt werden muss. Ein gut konfigurierter Verbindungspooler kann die Anzahl der Transaktionen pro Sekunde nahezu verdoppeln, was die Leistung erheblich verbessert.
Das obige ist der detaillierte Inhalt vonKonfigurieren eines Verbindungspools. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
