PostgreSQL Connection Pooling:Del 1 – För- och nackdelar

För länge sedan, i en galax långt borta, var "trådar" en programmeringsnyhet som sällan användes och som man sällan litade på. I den miljön beslutade de första PostgreSQL-utvecklarna att dela en process för varje anslutning till databasen är det säkraste valet. Det skulle vara synd om din databas kraschade trots allt.

Sedan dess har mycket vatten runnit under bron, men PostgreSQL-communityt har hållit fast vid sitt ursprungliga beslut. Det är svårt att klandra deras argument – ​​eftersom det är helt sant att:

• Varje klient har sin egen process förhindrar att en klient som fungerar dåligt kraschar hela databasen.
• På moderna Linux-system är skillnaden i overhead mellan att splittra en process och skapa en tråd mycket mindre än den brukade vara.
• Att flytta till en flertrådsarkitektur kommer att kräva omfattande omskrivningar.

Men i moderna webbapplikationer tenderar klienter att öppna många anslutningar. Utvecklare avråds ofta starkt från att ha en databasanslutning medan andra operationer äger rum. "Öppna en anslutning så sent som möjligt, stäng en anslutning så snart som möjligt". Men det orsakar problem med PostgreSQL:s arkitektur – att forfla en process blir dyrt när transaktioner är mycket korta, vilket den vanliga visdomen säger att de borde vara.

The Connection Pool Architecture

Att använda ett modernt språkbibliotek minskar problemet något – anslutningspoolning är en viktig funktion i de flesta populära databasåtkomstbibliotek. Det säkerställer att "stängda" anslutningar inte riktigt stängs, utan återgår till en pool, och att "öppna" en ny anslutning returnerar samma "fysiska anslutning" tillbaka, vilket minskar den faktiska splittringen på PostgreSQL-sidan.

Men moderna webbapplikationer är sällan monolitiska och använder ofta flera språk och tekniker. Att använda en anslutningspool i varje modul är knappast effektivt:

• Även med ett relativt litet antal moduler, och en liten poolstorlek i varje, slutar du med många serverprocesser. Det är kostsamt att växla mellan dem.
• Stödet för poolning varierar kraftigt mellan bibliotek och språk – en pool som fungerar dåligt kan förbruka alla resurser och göra databasen oåtkomlig för andra moduler.
• Det finns ingen centraliserad kontroll – du kan inte använda åtgärder som klientspecifika åtkomstgränser.

Som ett resultat har populära mellanprogram utvecklats för PostgreSQL. Dessa sitter mellan databasen och klienterna, ibland på en separat server (fysisk eller virtuell) och ibland på samma box, och skapar en pool som klienterna kan ansluta till. Dessa mellanprogram är:

• Optimerad för PostgreSQL och dess ganska unika arkitektur bland moderna DBMS:er.
• Tillhandahålla centraliserad åtkomstkontroll för olika klienter.
• Låt dig skörda samma belöningar som pooler på klientsidan, och sedan några till (vi kommer att diskutera dessa mer i detalj i våra nästa inlägg)!

PostgreSQL Connection Pooler Nackdelar

En anslutningspoolare är en nästan oumbärlig del av en produktionsklar PostgreSQL-installation. Även om det finns många väldokumenterade fördelar med att använda en anslutningspoolare, finns det några argument mot att använda en:

• Att introducera en mellanprogramvara i kommunikationen introducerar oundvikligen en viss latens. Men när den är placerad på samma värd och tar hänsyn till omkostnaderna för att splittra en anslutning, är detta försumbart i praktiken som vi kommer att se i nästa avsnitt.
• En mellanprogramvara blir ett enda fel. Att använda ett kluster på den här nivån kan lösa det här problemet, men det introducerar ökad komplexitet till arkitekturen.

  

• En mellanprogram medför extra kostnader. Du behöver antingen en extra server (eller 3), eller så måste din databasserver(ar) ha tillräckligt med resurser för att stödja en anslutningspoolare, förutom PostgreSQL.
• Att dela anslutningar mellan olika moduler kan bli en säkerhetsrisk. Det är mycket viktigt att vi konfigurerar pgPool eller PgBouncer för att rengöra anslutningar innan de returneras till poolen.
• Autentiseringen skiftar från DBMS till anslutningspoolern. Detta kanske inte alltid är acceptabelt.

  

• Det ökar ytan för attack, såvida inte åtkomsten till den underliggande databasen är låst för att endast tillåta åtkomst via anslutningspoolern.
• Det skapar ännu en komponent som måste underhållas, finjusteras för din arbetsbelastning, säkerhetskorrigeras ofta och uppgraderas vid behov.

Bör du använda en PostgreSQL Connection Pooler?

Men alla dessa problem diskuteras väl i PostgreSQL-gemenskapen, och begränsningsstrategier säkerställer att fördelarna med en anslutningspoolare vida överstiger deras nackdelar. Våra tester visar att även ett litet antal kunder kan dra stor nytta av att använda en anslutningspooler. De är väl värda den extra konfigurationen och underhållsarbetet.

I nästa inlägg kommer vi att diskutera en av de mest populära anslutningspoolarna i PostgreSQL-världen – PgBouncer, följt av Pgpool-II, och slutligen en prestandatestjämförelse av dessa två PostgreSQL-anslutningspoolare i vårt sista inlägg i serien.