Strategie für Verbindungspooling mit PgBouncer in Azure Database for PostgreSQL – Flexible Server

Dieser Artikel bietet strategische Orientierung bei der Auswahl eines Mechanismus für das Verbindungspooling für Ihre Flexible Server von Azure Database for PostgreSQL.

Einleitung

Wenn Sie einen Azure Database for PostgreSQL flexiblen Server verwenden, erstellen Sie eine Verbindung mit der Datenbank, indem Sie einen Kommunikationskanal zwischen der Clientanwendung und dem Server herstellen. Dieser Kanal verwaltet Daten, führt Abfragen aus und initiiert Transaktionen. Nachdem Sie die Verbindung hergestellt haben, kann die Clientanwendung Befehle an den Server senden und Antworten empfangen. Das Erstellen einer neuen Verbindung für jeden Vorgang kann jedoch Leistungsprobleme für unternehmenskritische Anwendungen verursachen. Jedes Mal, wenn Sie eine neue Verbindung erstellen, startet Azure Database for PostgreSQL einen neuen Prozess mithilfe des Postmasterprozesses, der mehr Ressourcen verbraucht.

Verwenden Sie zur Behebung dieses Problems Verbindungspooling, um einen Cache von Verbindungen zu erstellen, die von Azure Database for PostgreSQL wiederverwendet werden können. Wenn eine Anwendung oder ein Client eine Verbindung anfordert, stammt sie aus dem Verbindungspool. Nach Abschluss der Sitzung oder Transaktion wird die Verbindung zur Wiederverwendung in den Pool zurückgegeben. Indem Sie Verbindungen wiederverwenden, reduzieren Sie die Ressourcennutzung und verbessern die Leistung.

Obwohl verschiedene Tools für verbindungspooling vorhanden sind, werden in diesem Abschnitt verschiedene Strategien zur Verwendung von Verbindungspooling mithilfe von PgBouncer erläutert.

Was ist PgBouncer?

PgBouncer ist ein effizienter Verbindungspooler, der für PostgreSQL entwickelt wurde. Dadurch wird die Verarbeitungszeit reduziert und die Ressourcennutzung beim Verwalten mehrerer Clientverbindungen mit einer oder mehreren Datenbanken optimiert. PgBouncer bietet drei verschiedene Pooling-Modi für die Verbindungsverwaltung:

• Sitzungspooling: Diese Methode weist der Clientanwendung für die gesamte Dauer der Clientverbindung eine Serververbindung zu. Wenn die Clientanwendung die Verbindung trennt, gibt PgBouncer die Serververbindung umgehend wieder an den Pool zurück. Sitzungspooling ist der Standardmodus in Open Source PgBouncer. Weitere Informationen finden Sie unter PgBouncer-Konfiguration.
• Transaktionspooling: Beim Transaktionspooling wird während einer Transaktion eine Serververbindung für die Clientanwendung dediziert. Sobald die Transaktion erfolgreich abgeschlossen wurde, gibt PgBouncer die Serververbindung frei, sodass sie wieder im Pool verfügbar ist. Transaktionspooling ist der Standardmodus im integrierten PgBouncer von Azure Database for PostgreSQL und unterstützt keine vorbereiteten Transaktionen.
• Anweisungspooling: Beim Anweisungspooling wird der Clientanwendung für jede einzelne Anweisung eine Serververbindung zugeordnet. Nach Abschluss der Anweisung wird die Serververbindung an den Verbindungspool zurückgegeben. Transaktionen mit mehreren Anweisungen werden in diesem Modus nicht unterstützt.

Sie können PgBouncer in drei unterschiedlichen Verwendungsmustern verwenden:

• Gemeinsame Bereitstellung von PgBouncer und Anwendung
• Anwendungsunabhängige zentralisierte PgBouncer-Bereitstellungen
• Integrierte PgBouncer- und Datenbankbereitstellung

Jedes dieser Muster hat seine eigenen Vor- und Nachteile.

Gemeinsame Bereitstellung von PgBouncer und Anwendung

Wenn Sie diesen Ansatz verwenden, stellen Sie PgBouncer auf demselben Server bereit, auf dem Ihre Anwendung gehostet wird. Sie können die Anwendung und PgBouncer auf herkömmlichen virtuellen Computern oder in einer mikroservicesbasierten Architektur bereitstellen, wie hervorgehoben:

PgBouncer in anwendungs-VM bereitgestellt

Wenn Ihre Anwendung auf einer Azure-VM ausgeführt wird, können Sie PgBouncer auf derselben VM einrichten. Informationen zur Installation und Konfiguration von PgBouncer als Proxy für Verbindungspooling mit Ihrem Azure Database for PostgreSQL Flexible Server finden Sie unter Schritte zum Installieren und Konfigurieren des PgBouncer-Proxys für Verbindungspooling.

Die Bereitstellung von PgBouncer auf einem Anwendungsserver kann mehrere Vorteile bieten, insbesondere beim Arbeiten mit Datenbanken in Azure Database for PostgreSQL – Flexibler Server. Einige der wichtigsten Vorteile und Einschränkungen dieser Bereitstellungsmethode sind:

Vorteile:

• Reduzierte Latenz: Durch die Bereitstellung von PgBouncer auf derselben Anwendungs-VM ist die Kommunikation zwischen der primären Anwendung und dem Verbindungspooler aufgrund ihrer Nähe effizient. Die Bereitstellung von PgBouncer in einer Anwendungs-VM minimiert die Latenz und sorgt für reibungslose und zügige Interaktionen.
• Verbesserte Sicherheit:PgBouncer kann als sicherer Vermittler zwischen der Anwendung und der Datenbank fungieren, wodurch eine zusätzliche Sicherheitsschicht vorhanden ist. Es kann Authentifizierung und Verschlüsselung erzwingen und so sicherstellen, dass nur autorisierte Clients auf die Datenbank zugreifen können.

Insgesamt bietet die Bereitstellung von PgBouncer auf einem Anwendungsserver einen effizienteren, sichereren und skalierbareren Ansatz für die Verwaltung von Verbindungen mit Datenbanken in Azure Database for PostgreSQL – Flexibler Server, wodurch die Leistung und Zuverlässigkeit der Anwendung verbessert wird.

Limitations:

• Einzelner Fehlerpunkt: Wenn Sie PgBouncer als einzelne Instanz auf dem Anwendungsserver bereitstellen, wird es zu einem potenziellen einzelnen Fehlerpunkt. Wenn die PgBouncer-Instanz ausfällt, kann dies den gesamten Datenbankverbindungspool unterbrechen, was zu Ausfallzeiten für die Anwendung führt. Um diesen einzelnen Fehlerpunkt zu minimieren, richten Sie mehrere PgBouncer-Instanzen hinter einem Lastenausgleich für hohe Verfügbarkeit ein.
• Eingeschränkte Skalierbarkeit: Die Skalierbarkeit von PgBouncer hängt von der Kapazität des Servers ab, auf dem er bereitgestellt wird. Wenn der Anwendungsserver seine Verbindungsgrenze erreicht, kann PgBouncer zu einem Engpass werden und die Fähigkeit zur Skalierung der Anwendung einschränken. Möglicherweise müssen Sie die Verbindungslast über mehrere PgBouncer-Instanzen verteilen oder alternative Lösungen wie Verbindungspooling auf Anwendungsebene in Betracht ziehen.
• Konfigurationskomplexität: Das Konfigurieren und Optimieren von PgBouncer kann komplex sein, insbesondere wenn Faktoren wie Verbindungsgrenzwerte, Pooldimensionierung und Lastenausgleich berücksichtigt werden. Für die Administration zuständige Personen müssen die PgBouncer-Konfiguration sorgfältig an die Anforderungen der Anwendung anpassen und eine optimale Leistung und Stabilität gewährleisten.

Wiegen Sie diese Einschränkungen gegen die Vorteile und bewerten Sie, ob PgBouncer die richtige Wahl für Ihre spezifische Anwendung und Datenbankeinrichtung ist.

PgBouncer als AKS Sidecar bereitgestellt

Sie können PgBouncer als Sidecar-Container verwenden, wenn Ihre Anwendung containerisiert ist und auf Azure Kubernetes Service (AKS), Azure Container Instance (ACI), Azure Container Apps (ACA) oder Azure Red Hat OpenShift (ARO) ausgeführt wird. Das Sidecar-Muster ist von dem Konzept eines Beiwagens inspiriert, der an einem Motorrad befestigt ist. Ein Hilfscontainer, der als Sidecar-Container bezeichnet wird, wird an eine übergeordnete Anwendung angefügt. Dieses Muster bereichert die übergeordnete Anwendung, indem es ihre Funktionen erweitert und zusätzliche Unterstützung bietet.

Durch die Bereitstellung von PgBouncer in einem AKS-Sidecar werden die Anwendungs- und Sidecar-Lebenszyklus eng gekoppelt und Ressourcen wie Hostname und Netzwerk gemeinsam genutzt, um Ressourcen effizient zu nutzen. Das PgBouncer-Sidecar wird zusammen mit dem Anwendungscontainer innerhalb desselben Pods in Azure Kubernetes Service (AKS) in einer 1:1-Zuordnung betrieben und dient als Proxy für Verbindungspooling für Azure Database for PostgreSQL Flexible Server.

Microsoft veröffentlicht ein PgBouncer-Sidecarproxy-Image in der Microsoft-Containerregistrierung.

Weitere Informationen finden Sie hier.

Einige der wichtigsten Vorteile und Einschränkungen dieser Bereitstellungsmethode sind:

Vorteile:

• Reduzierte Latenz: Durch die Bereitstellung von PgBouncer als AKS-Sidecar ist die Kommunikation zwischen der primären Anwendung und dem Verbindungspooler aufgrund ihrer Nähe nahtlos und effizient. Die Bereitstellung von PgBouncer als AKS-Sidecar minimiert die Latenz und sorgt für reibungslose und schnelle Interaktionen.
• Vereinfachte Verwaltung und Bereitstellung: Die enge Kopplung von PgBouncer mit dem Anwendungscontainer vereinfacht den Verwaltungs- und Bereitstellungsprozess. Beide Komponenten sind eng integriert, sodass Sie sie einfacher verwalten und nahtlos koordinieren können.
• Hohe Verfügbarkeit und Verbindungsresilienz: Wenn ein Anwendungscontainerfehler oder ein Neustart auftritt, folgt der PgBouncer Sidecar-Container genau und stellt eine hohe Verfügbarkeit sicher. Dieses Setup garantiert die Verbindungsresilienz und behält auch bei Failovern eine vorhersagbare Leistung bei, was zu einem zuverlässigen und robusten System beiträgt.

Wenn Sie PgBouncer als AKS-Sidecar betrachten, können Sie diese Vorteile nutzen, um die Leistung Ihrer Anwendung zu verbessern, die Verwaltung zu optimieren und die kontinuierliche Verfügbarkeit des Verbindungspoolers sicherzustellen.

Limitations:

• Probleme mit der Verbindungsleistung: Große Anwendungen, die Tausende von Pods verwenden, von denen jeder einen Sidecar-PgBouncer ausführt, könnten auf potenzielle Herausforderungen im Zusammenhang mit der Ausschöpfung der verfügbaren Datenbankverbindungen stoßen. Diese Situation kann zu Leistungsbeeinträchtigung und Dienstunterbrechungen führen. Durch die Bereitstellung eines Sidecar-PgBouncer für jeden Pod wird die Anzahl gleichzeitiger Verbindungen mit dem Datenbankserver erhöht, wodurch die Kapazität überschritten werden kann. Daher kann die Datenbank Schwierigkeiten haben, das hohe Volumen eingehender Verbindungen zu bewältigen, wodurch es zu Leistungsproblemen wie erhöhten Reaktionszeiten oder sogar Dienstausfällen kommen kann.
• Komplexe Bereitstellung: Die Verwendung des Sidecar-Musters führt zu einer Komplexität des Bereitstellungsprozesses, da zwei Container innerhalb desselben Pods ausgeführt werden. Diese Komplexität kann die Problembehandlung und das Debuggen von Aktivitäten möglicherweise erschweren, was zusätzliche Anstrengungen erfordert, um Probleme zu identifizieren und zu beheben.
• Skalierungsprobleme: Das Sidecar-Muster ist möglicherweise nicht die ideale Wahl für Anwendungen, die hohe Skalierbarkeit erfordern. Die Einbindung eines Sidecar-Containers kann einen höheren Ressourcenbedarf verursachen und dadurch potenziell die Anzahl der Pods begrenzen, die Sie effektiv erstellen und verwalten können.

Bewerten Sie bei der Betrachtung dieses Sidecar-Musters sorgfältig die Kompromisse zwischen Bereitstellungskomplexität und Skalierbarkeitsanforderungen, um den am besten geeigneten Ansatz für Ihr spezifisches Anwendungsszenario zu ermitteln.

Anwendungsunabhängig – zentrale PgBouncer-Bereitstellung

Wenn Sie diesen Ansatz verwenden, stellen Sie PgBouncer als zentralisierten Dienst bereit, der unabhängig von der Anwendung ist. Sie können den PgBouncer-Dienst auf herkömmlichen virtuellen Computern oder in einer mikroservicesbasierten Architektur bereitstellen, wie in den folgenden Abschnitten hervorgehoben:

PgBouncer in einer Ubuntu-VM hinter einem Azure Load Balancer bereitgestellt

Richten Sie den PgBouncer-Verbindungsproxy zwischen der Anwendung und der Datenbankschicht hinter einem Azure Load Balancer ein, wie in der folgenden Abbildung dargestellt. In diesem Muster stellen Sie mehrere PgBouncer-Instanzen als Service hinter einem Load Balancer bereit, um einen Single Point of Failure zu vermeiden. Dieses Muster eignet sich auch in Szenarien, in denen die Anwendung in einem verwalteten Dienst wie Azure-App Services oder Azure Functions ausgeführt wird und eine Verbindung mit dem PgBouncer-Dienst für eine einfache Integration in Ihre vorhandene Infrastruktur hergestellt wird.

Informationen zum Installieren und Einrichten des PgBouncer-Connection-Pooling-Proxys für flexible Server von Azure Database for PostgreSQL finden Sie unter Schritte zum Installieren und Einrichten des PgBouncer-Connection-Pooling-Proxys.

Einige der wichtigsten Vorteile und Einschränkungen dieser Bereitstellungsmethode sind:

Vorteile:

• Entfernen eines einzelnen Fehlerpunkts: Die Anwendungskonnektivität ist nicht von dem Fehler einer einzelnen PgBouncer-VM betroffen, da mehrere PgBouncer-Instanzen hinter Azure Load Balancer liegen.
• Nahtlose Integration mit verwalteten Diensten: Wenn Ihre Anwendung auf einer verwalteten Dienstplattform wie Azure-App Services oder Azure Functions gehostet wird, ermöglicht die Bereitstellung von PgBouncer auf einer VM eine einfache Integration in Ihre vorhandene Infrastruktur.
• Vereinfachte Einrichtung auf einer Azure-VM: Wenn Sie Ihre Anwendung bereits auf einer Azure-VM ausführen, ist das Einrichten von PgBouncer auf derselben VM einfach. Durch die Bereitstellung von PgBouncer in vm wird sichergestellt, dass PgBouncer in unmittelbarer Nähe zu Ihrer Anwendung bereitgestellt wird, wodurch die Netzwerklatenz minimiert und die Leistung maximiert wird.
• Nicht invasive Konfiguration: Durch die Bereitstellung von PgBouncer auf einer VM können Sie vermeiden, Parameter auf Ihrem flexiblen Azure Database for PostgreSQL-Server zu ändern. Diese Konfiguration ist nützlich, wenn Sie PgBouncer auf einem Azure Database for PostgreSQL flexiblen Server konfigurieren möchten. Beispielsweise kann das Ändern des SSLMODE-Parameters in "required" auf einem Azure Database for PostgreSQL flexiblen Server dazu führen, dass bestimmte Anwendungen, die auf SSLMODE=FALSE basieren, fehlschlagen. Durch die Bereitstellung von PgBouncer auf einer separaten VM können Sie die Standardserverkonfiguration beibehalten und gleichzeitig die Vorteile von PgBouncer nutzen.

Wenn Sie diese Vorteile berücksichtigen, bietet die Bereitstellung von PgBouncer auf einer VM eine praktische und effiziente Lösung zur Verbesserung der Leistung und Kompatibilität Ihrer Anwendung, die in der Azure-Infrastruktur ausgeführt wird.

Limitations:

• Verwaltungsaufwand: Wenn Sie PgBouncer auf einem virtuellen Computer installieren, haben Sie möglicherweise Verwaltungsaufwand, um mehrere Konfigurationsdateien zu verwalten. Dieses Setup erschwert die Bewältigung von Versionsupgrades, neuen Versionen und Produktupdates.
• Featureparität: Wenn Sie von herkömmlicher PostgreSQL zu einem Azure Database for PostgreSQL flexiblen Server migrieren und PgBouncer verwenden, können einige Featurelücken bestehen. Beispiel: Fehlende Md5-Unterstützung in Azure Database for PostgreSQL.

Zentralisierte PgBouncer-Bereitstellung als Dienst in AKS

Wenn Sie mit hoch skalierbaren und großen containerisierten Bereitstellungen auf Azure Kubernetes Service (AKS) arbeiten, bestehend aus Hunderten von Pods oder in Situationen, in denen mehrere Anwendungen eine Verbindung mit einer freigegebenen Datenbank herstellen müssen, verwenden Sie PgBouncer als eigenständigen Dienst anstelle eines Sidecar-Containers.

Durch den Einsatz von PgBouncer als separatem Dienst können Sie das Verbindungs-Pooling für Ihre Anwendungen effizient und in größerem Maßstab verwalten. Bei diesem Ansatz wird die Verbindungspoolfunktion zentralisiert, sodass mehrere Anwendungen eine Verbindung mit derselben Datenbankressource herstellen und gleichzeitig eine optimale Leistung und Ressourcenauslastung gewährleisten.

Verwenden Sie das PgBouncer Sidecar-Proxy-Image, das in der Microsoft-Containerregistrierung veröffentlicht wurde, um einen Dienst zu erstellen und bereitzustellen.

Einige der wichtigsten Vorteile und Einschränkungen dieser Bereitstellungsmethode sind:

Vorteile:

• Verbesserte Zuverlässigkeit: Durch die Bereitstellung von PgBouncer als eigenständiger Dienst können Sie sie auf hoch verfügbare Weise konfigurieren. Diese Konfiguration verbessert die Gesamtsicherheit der Verbindungspoolinfrastruktur und sorgt für eine kontinuierliche Verfügbarkeit auch bei Fehlern oder Unterbrechungen.
• Optimale Ressourcenauslastung: Wenn Ihre Anwendung oder der Datenbankserver über begrenzte Ressourcen verfügt, kann ein separater Computer zum Ausführen des PgBouncer-Diensts vorteilhaft sein. Durch die Bereitstellung von PgBouncer auf einem Computer mit ausreichend Ressourcen stellen Sie eine optimale Leistung sicher und verhindern Ressourcenkonfliktprobleme.
• Zentrale Verbindungsverwaltung: Wenn eine zentralisierte Verwaltung von Datenbankverbindungen erforderlich ist, bietet ein eigenständiger PgBouncer-Dienst einen optimierten Ansatz. Durch die Konsolidierung von Verbindungsverwaltungsaufgaben in einem zentralisierten Dienst können Sie Datenbankverbindungen über mehrere Anwendungen hinweg effektiv überwachen und steuern, wodurch die Verwaltung vereinfacht und Konsistenz sichergestellt wird.

Wenn Sie PgBouncer als eigenständigen Dienst in AKS betrachten, können Sie diese Vorteile nutzen, um eine verbesserte Zuverlässigkeit, Ressourceneffizienz und eine zentralisierte Verwaltung von Datenbankverbindungen zu erzielen.

Limitations:

• Erhöhte N/W-Latenz: Berücksichtigen Sie bei der Bereitstellung von PgBouncer als eigenständiger Dienst die potenzielle Einführung einer größeren Latenz. Diese Latenz tritt auf, da die Anwendung und der PgBouncer-Dienst Verbindungen über das Netzwerk übergeben müssen. Bewerten Sie die Latenzanforderungen Ihrer Anwendung, und berücksichtigen Sie die Kompromisse zwischen der zentralen Verbindungsverwaltung und potenziellen Latenzproblemen.

Während PgBouncer , der als eigenständiger Dienst ausgeführt wird, Vorteile wie zentralisierte Verwaltung und Ressourcenoptimierung bietet, bewerten Sie die Auswirkungen der potenziellen Latenz auf die Leistung Ihrer Anwendung, um sicherzustellen, dass sie ihren spezifischen Anforderungen entspricht.

Integrierter PgBouncer in Azure Database for PostgreSQL

Azure Database for PostgreSQL bietet PgBouncer als integrierte Verbindungspoollösung an. Sie können diesen optionalen Dienst pro Datenbankserver aktivieren. PgBouncer wird auf demselben virtuellen Computer wie der Azure Database for PostgreSQL flexible Server ausgeführt. Da sich die Anzahl der Verbindungen über ein paar Hundert oder Tausend erhöht, kann Azure Database for PostgreSQL auf Ressourcenbeschränkungen stoßen. In solchen Fällen kann der integrierte PgBouncer einen erheblichen Vorteil bieten, indem er die Verwaltung von ungenutzten und kurzlebigen Verbindungen auf dem Datenbankserver verbessert.

Informationen dazu, wie Sie PgBouncer-Verbindungspooling in Azure Database for PostgreSQL aktivieren und einrichten, finden Sie unter PgBouncer in Azure Database for PostgreSQL – Flexible Server.

Einige der wichtigsten Vorteile und Einschränkungen dieser Bereitstellungsmethode sind:

Vorteile:

• Nahtlose Konfiguration: Wenn Sie den integrierten PgBouncer in Ihrem Azure Database for PostgreSQL flexiblen Server verwenden, benötigen Sie keine separate Installation oder ein komplexes Setup. Sie können sie ganz einfach direkt aus den Parametern konfigurieren, um eine problemlose Erfahrung zu gewährleisten.
• Komfort des verwalteten Diensts: Als verwalteter Dienst können Sie die Vorteile anderer Azure verwalteter Dienste genießen. Dieser Vorteil umfasst automatische Updates, ohne dass manuelle Wartung erforderlich ist und sichergestellt wird, dass PgBouncer mit den neuesten Features und Sicherheitspatches auf dem neuesten Stand bleibt.
• Unterstützung für öffentliche und private Verbindungen: Der integrierte PgBouncer in Ihrem Azure Database for PostgreSQL flexiblen Server bietet Unterstützung für öffentliche und private Verbindungen. Diese Unterstützung ermöglicht es Ihnen, sichere Verbindungen über private Netzwerke herzustellen oder extern zu verbinden, je nach Ihren spezifischen Anforderungen.
• Hochverfügbarkeit: Im Falle eines Failovers, bei dem ein Standbyserver zur primären Rolle heraufgestuft wird, wird PgBouncer nahtlos im neu heraufgestuften Standby neu gestartet, ohne dass Änderungen an der Anwendungsverbindungszeichenfolge erforderlich sind. Dieses Feature stellt die kontinuierliche Verfügbarkeit sicher und minimiert Unterbrechungen der Anwendung.
• Kosteneffizient: Es ist kosteneffizient, da Sie nicht für zusätzliche Compute wie VM oder die Container bezahlen müssen, obwohl es einige CPU-Auswirkungen hat, da es sich um einen anderen Prozess handelt, der auf demselben Computer ausgeführt wird.

Durch die Verwendung des integrierten PgBouncer in einem Azure Database for PostgreSQL flexiblen Server können Sie den Komfort der vereinfachten Konfiguration, die Zuverlässigkeit eines verwalteten Diensts, die Unterstützung für verschiedene Poolingmodi und die nahtlose hohe Verfügbarkeit während Failoverszenarien genießen.

Limitations:

• Nicht unterstützt mit Burstable:PgBouncer wird derzeit nicht mit burstable server compute tier unterstützt. Wenn Sie die Berechnungsschicht von „Universell“ oder „arbeitsspeicheroptimiert“ auf „burstfähig“ ändern, verlieren Sie die PgBouncer-Funktion.
• Erneutes Herstellen von Verbindungen nach neustarten: Wenn der Server während der Skalierungsvorgänge, des HA-Failovers oder eines Neustarts neu gestartet wird, wird der PgBouncer zusammen mit dem virtuellen Servercomputer neu gestartet. Daher müssen vorhandene Verbindungen erneut hergestellt werden.

In diesem Artikel werden verschiedene Methoden zur Implementierung von PgBouncer erläutert. In der folgenden Tabelle wird zusammengefasst, für welche Bereitstellungsmethode Sie sich entscheiden sollen:

Auswahlkriterien	PgBouncer auf einer App-VM	PgBouncer auf einer VM mit ALB*	PgBouncer auf AKS-Sidecar	PgBouncer als Dienst	Azure Database for PostgreSQL mit integriertem PgBouncer
Vereinfachte Verwaltung
Hochverfügbarkeit
Containerisierte Apps
Geringere Netzwerkbelastung und Latenz
Präzise Steuerung der Überwachung und des Debuggens

Legende

Schwierigkeitsgrad	Symbol
Easy
Mittelstufe
Schwierig

*ALB: Azure Load Balancer.

Verwandte Inhalte

• PgBouncer in Azure-Datenbank für Flexible Server für PostgreSQL
• Verbindungsbibliotheken