PostgreSQL Connection Pooling:Deel 1 – Voor- en nadelen

Lang geleden, in een sterrenstelsel ver hier vandaan, waren 'threads' een programmeernieuwigheid die zelden werd gebruikt en zelden werd vertrouwd. In die omgeving besloten de eerste PostgreSQL-ontwikkelaars dat een proces voor elke verbinding met de database de veiligste keuze is. Het zou toch zonde zijn als je database zou crashen.

Sindsdien is er veel water onder die brug doorgestroomd, maar de PostgreSQL-gemeenschap is bij haar oorspronkelijke beslissing gebleven. Het is moeilijk om hun argument te bekritiseren - want het is absoluut waar dat:

• Elke client met zijn eigen proces voorkomt dat een zich slecht gedragende client de hele database laat crashen.
• Op moderne Linux-systemen is het verschil in overhead tussen het forken van een proces en het maken van een thread veel kleiner dan vroeger.
• De overstap naar een multithreaded-architectuur vereist uitgebreide herschrijvingen.

In moderne webapplicaties hebben clients echter de neiging om veel verbindingen te openen. Ontwikkelaars worden vaak sterk afgeraden om een ​​databaseverbinding vast te houden terwijl andere bewerkingen plaatsvinden. "Open een verbinding zo laat mogelijk, sluit een verbinding zo snel mogelijk". Maar dat veroorzaakt een probleem met de architectuur van PostgreSQL:het forken van een proces wordt duur wanneer transacties erg kort zijn, zoals de algemene wijsheid voorschrijft.

De verbindingspoolarchitectuur

Het gebruik van een moderne taalbibliotheek verkleint het probleem enigszins - pooling van verbindingen is een essentieel kenmerk van de meeste populaire bibliotheken met toegang tot databases. Het zorgt ervoor dat 'gesloten' verbindingen niet echt worden gesloten, maar worden teruggebracht naar een pool, en het 'openen' van een nieuwe verbinding geeft dezelfde 'fysieke verbinding' terug, waardoor de daadwerkelijke forking aan de PostgreSQL-kant wordt verminderd.

Moderne webapplicaties zijn zelden monolithisch en gebruiken vaak meerdere talen en technologieën. Het gebruik van een verbindingspool in elke module is nauwelijks efficiënt:

• Zelfs met een relatief klein aantal modules en een kleine pool in elk, krijg je uiteindelijk veel serverprocessen. Het wisselen van context is kostbaar.
• De ondersteuning voor pooling varieert sterk tussen bibliotheken en talen - één slecht gedragende pool kan alle bronnen verbruiken en de database ontoegankelijk maken voor andere modules.
• Er is geen gecentraliseerde controle - u kunt geen maatregelen zoals klantspecifieke toegangslimieten gebruiken.

Als resultaat zijn er populaire middlewares ontwikkeld voor PostgreSQL. Deze bevinden zich tussen de database en de clients, soms op een aparte server (fysiek of virtueel) en soms op dezelfde box, en vormen een pool waarmee clients verbinding kunnen maken. Deze middleware zijn:

• Geoptimaliseerd voor PostgreSQL en zijn vrij unieke architectuur onder moderne DBMS'en.
• Bied gecentraliseerde toegangscontrole voor diverse klanten.
• Hiermee kun je dezelfde beloningen oogsten als pools aan de kant van de klant, en nog wat meer (we zullen deze meer in detail bespreken in onze volgende berichten)!

Nadelen PostgreSQL Connection Pooler

Een pooler voor verbindingen is een bijna onmisbaar onderdeel van een productieklare PostgreSQL-installatie. Hoewel er tal van goed gedocumenteerde voordelen zijn aan het gebruik van een pooler voor verbindingen, zijn er zijn enkele argumenten tegen het gebruik ervan:

• Introductie van een middleware in de communicatie brengt onvermijdelijk enige vertraging met zich mee. Wanneer het zich echter op dezelfde host bevindt en rekening houdt met de overhead van het foren van een verbinding, is dit in de praktijk te verwaarlozen, zoals we in de volgende sectie zullen zien.
• Een middleware wordt een single point of failure. Het gebruik van een cluster op dit niveau kan dit probleem oplossen, maar dat brengt extra complexiteit aan de architectuur met zich mee.

  

• Middleware brengt extra kosten met zich mee. U hebt ofwel een extra server (of 3) nodig, of uw databaseserver(s) moeten voldoende bronnen hebben om een ​​verbindingspooler te ondersteunen, naast PostgreSQL.
• Het delen van verbindingen tussen verschillende modules kan een beveiligingsprobleem worden. Het is erg belangrijk dat we pgPool of PgBouncer configureren om verbindingen op te schonen voordat ze worden teruggestuurd naar de pool.
• De authenticatie verschuift van het DBMS naar de pooler voor verbindingen. Dit is misschien niet altijd acceptabel.

  

• Het vergroot de oppervlakte voor aanvallen, tenzij de toegang tot de onderliggende database is vergrendeld om alleen toegang toe te staan ​​via de verbindingspooler.
• Het creëert nog een ander onderdeel dat moet worden onderhouden, nauwkeurig moet worden afgestemd op uw werklast, vaak moet worden gepatcht en waar nodig moet worden bijgewerkt.

Moet u een PostgreSQL-verbindingspooler gebruiken?

Al deze problemen zijn echter goed besproken in de PostgreSQL-gemeenschap, en beperkende strategieën zorgen ervoor dat de voordelen van een verbindingspooler hun nadelen ver overtreffen. Onze tests tonen aan dat zelfs een klein aantal klanten aanzienlijk kan profiteren van het gebruik van een pooler voor verbindingen. Ze zijn de extra moeite voor configuratie en onderhoud zeker waard.

In het volgende bericht bespreken we een van de meest populaire poolers voor verbindingen in de PostgreSQL-wereld:PgBouncer, gevolgd door Pgpool-II, en tot slot een prestatietestvergelijking van deze twee. PostgreSQL-verbindingspoolers in onze laatste post van de serie.