PostgreSQL Connection Pooling:Del 1 – Fordele og ulemper

For lang tid siden, i en galakse langt langt væk, var 'tråde' en programmeringsnyhed, der sjældent blev brugt og sjældent var tillid til. I det miljø besluttede de første PostgreSQL-udviklere, at det er det sikreste valg, at forgrening af en proces for hver forbindelse til databasen. Det ville trods alt være en skam, hvis din database gik ned.

Siden da er der fløjet meget vand under den bro, men PostgreSQL-fællesskabet har holdt fast ved deres oprindelige beslutning. Det er svært at tage fejl af deres argument – ​​da det er helt rigtigt, at:

• Hver klient har sin egen proces forhindrer en dårligt opførende klient i at crashe hele databasen.
• På moderne Linux-systemer er forskellen i overhead mellem forgrening af en proces og oprettelse af en tråd meget mindre, end den plejede at være.
• At flytte til en flertrådsarkitektur vil kræve omfattende omskrivninger.

I moderne webapplikationer har klienter dog en tendens til at åbne mange forbindelser. Udviklere frarådes ofte kraftigt at holde en databaseforbindelse, mens andre operationer finder sted. "Åbn en forbindelse så sent som muligt, luk en forbindelse så hurtigt som muligt". Men det forårsager et problem med PostgreSQLs arkitektur – at forgrene en proces bliver dyrt, når transaktioner er meget korte, som den almindelige visdom tilsiger, at de burde være.

The Connection Pool Architecture

Brug af et moderne sprogbibliotek reducerer problemet noget – pooling af forbindelse er en væsentlig egenskab i de fleste populære biblioteker med databaseadgang. Det sikrer, at 'lukkede' forbindelser ikke rigtig lukkes, men returneres til en pool, og at 'åbne' en ny forbindelse returnerer den samme 'fysiske forbindelse' tilbage, hvilket reducerer den faktiske forgrening på PostgreSQL-siden.

Men moderne webapplikationer er sjældent monolitiske og bruger ofte flere sprog og teknologier. At bruge en forbindelsespulje i hvert modul er næppe effektivt:

• Selv med et relativt lille antal moduler og en lille puljestørrelse i hver, ender du med en masse serverprocesser. Kontekstskift mellem dem er dyrt.
• Pooling-understøttelsen varierer meget mellem biblioteker og sprog – en dårligt opført pool kan forbruge alle ressourcer og efterlade databasen utilgængelig for andre moduler.
• Der er ingen centraliseret kontrol – du kan ikke bruge foranstaltninger som klientspecifikke adgangsbegrænsninger.

Som et resultat er populære middlewares blevet udviklet til PostgreSQL. Disse sidder mellem databasen og klienterne, nogle gange på en separat server (fysisk eller virtuel) og nogle gange på den samme boks, og skaber en pulje, som klienter kan oprette forbindelse til. Disse middleware er:

• Optimeret til PostgreSQL og dets ret unikke arkitektur blandt moderne DBMS'er.
• Lav centraliseret adgangskontrol til forskellige klienter.
• Lad dig høste de samme belønninger som puljer på klientsiden, og så nogle flere (vi vil diskutere disse mere detaljeret i vores næste indlæg)!

PostgreSQL Connection Pooler Ulemper

En forbindelsespooler er en næsten uundværlig del af en produktionsklar PostgreSQL-opsætning. Selvom der er masser af veldokumenterede fordele ved at bruge en forbindelsespooler, er der nogle argumenter mod at bruge en:

• Introduktion af en middleware i kommunikationen introducerer uundgåeligt en vis forsinkelse. Men når det er placeret på den samme vært, og der tages højde for omkostningerne ved at forgrene en forbindelse, er dette ubetydeligt i praksis, som vi vil se i næste afsnit.
• En middleware bliver et enkelt fejlpunkt. Brug af en klynge på dette niveau kan løse dette problem, men det introducerer ekstra kompleksitet til arkitekturen.

  

• En middleware medfører ekstra omkostninger. Du har enten brug for en ekstra server (eller 3), eller din(e) databaseserver(e) skal have nok ressourcer til at understøtte en forbindelsespooler, ud over PostgreSQL.
• Deling af forbindelser mellem forskellige moduler kan blive en sikkerhedssårbarhed. Det er meget vigtigt, at vi konfigurerer pgPool eller PgBouncer til at rense forbindelser, før de returneres til poolen.
• Godkendelsen skifter fra DBMS til forbindelsespooleren. Dette er måske ikke altid acceptabelt.

  

• Det øger overfladearealet for angreb, medmindre adgangen til den underliggende database er låst for kun at tillade adgang via forbindelsespooleren.
• Den skaber endnu en komponent, der skal vedligeholdes, finjusteres til din arbejdsbyrde, sikkerhedsrettelser ofte og opgraderes efter behov.

Skal du bruge en PostgreSQL Connection Pooler?

Men alle disse problemer er veldiskuteret i PostgreSQL-fællesskabet, og afhjælpningsstrategier sikrer, at fordelene ved en forbindelsespooler langt overstiger deres ulemper. Vores test viser, at selv et lille antal klienter kan drage stor fordel af at bruge en forbindelsespooler. De er den ekstra konfigurations- og vedligeholdelsesindsats værd.

I det næste indlæg vil vi diskutere en af ​​de mest populære forbindelsespoolere i PostgreSQL-verdenen – PgBouncer, efterfulgt af Pgpool-II, og til sidst en præstationstest-sammenligning af disse to PostgreSQL-forbindelsespoolere i vores sidste indlæg i serien.