Pool di connessioni PostgreSQL:parte 1 – Pro e contro

Tanto tempo fa, in una galassia molto lontana, i "thread" erano una novità di programmazione usata raramente e di rado attendibile. In quell'ambiente, i primi sviluppatori di PostgreSQL hanno deciso che il fork di un processo per ogni connessione al database fosse la scelta più sicura. Sarebbe un peccato se il tuo database andasse in crash, dopotutto.

Da allora, molta acqua è passata sotto quel ponte, ma la comunità di PostgreSQL è rimasta fedele alla sua decisione originale. È difficile criticare la loro argomentazione, poiché è assolutamente vero che:

• Ogni client con il proprio processo impedisce a un client che si comporta male di mandare in crash l'intero database.
• Nei moderni sistemi Linux, la differenza di sovraccarico tra il fork di un processo e la creazione di un thread è molto inferiore rispetto a prima.
• Il passaggio a un'architettura multithread richiederà ampie riscritture.

Tuttavia, nelle moderne applicazioni web, i client tendono ad aprire molte connessioni. Gli sviluppatori sono spesso fortemente sconsigliati dal mantenere una connessione al database mentre sono in corso altre operazioni. "Apri una connessione il più tardi possibile, chiudi una connessione il prima possibile". Ma ciò causa un problema con l'architettura di PostgreSQL:il fork di un processo diventa costoso quando le transazioni sono molto brevi, come dice la saggezza comune che dovrebbero essere.

L'architettura del pool di connessioni

L'uso di una libreria di lingua moderna riduce in qualche modo il problema:il pool di connessioni è una caratteristica essenziale delle librerie di accesso ai database più popolari. Garantisce che le connessioni "chiuse" non siano realmente chiuse, ma restituite a un pool e "l'apertura" di una nuova connessione restituisca la stessa "connessione fisica", riducendo l'effettivo fork sul lato PostgreSQL.

Tuttavia, le moderne applicazioni web sono raramente monolitici e spesso utilizzano più linguaggi e tecnologie. L'utilizzo di un pool di connessioni in ogni modulo è poco efficiente:

• Anche con un numero relativamente piccolo di moduli e una piccola dimensione del pool in ciascuno, si finisce con molti processi server. Il passaggio da un contesto all'altro è costoso.
• Il supporto per il pool varia ampiamente tra le librerie e le lingue:un pool che si comporta male può consumare tutte le risorse e lasciare il database inaccessibile ad altri moduli.
• Non esiste un controllo centralizzato:non puoi utilizzare misure come i limiti di accesso specifici del client.

Di conseguenza, sono stati sviluppati middleware popolari per PostgreSQL. Questi si trovano tra il database e i client, a volte su un server separato (fisico o virtuale) e talvolta sulla stessa scatola, e creano un pool a cui i client possono connettersi. Questi middleware sono:

• Ottimizzato per PostgreSQL e la sua architettura piuttosto unica tra i moderni DBMS.
• Fornisci il controllo centralizzato degli accessi a diversi client.
• Ti permettono di raccogliere gli stessi premi dei pool lato client, e poi altri ancora (ne parleremo più in dettaglio nei prossimi post)!

Contro del pool di connessioni PostgreSQL

Un pool di connessioni è una parte quasi indispensabile di una configurazione PostgreSQL pronta per la produzione. Sebbene ci siano molti vantaggi ben documentati nell'utilizzo di un pool di connessioni, ci sono sono alcuni argomenti da addurre contro l'utilizzo di uno:

• L'introduzione di un middleware nella comunicazione introduce inevitabilmente una certa latenza. Tuttavia, quando si trova sullo stesso host e si tiene conto dell'overhead di biforcazione di una connessione, in pratica ciò è trascurabile, come vedremo nella prossima sezione.
• Un middleware diventa un singolo punto di errore. L'utilizzo di un cluster a questo livello può risolvere questo problema, ma ciò introduce una maggiore complessità nell'architettura.

  

• Un middleware implica costi aggiuntivi. O hai bisogno di un server aggiuntivo (o 3) oppure i tuoi server di database devono disporre di risorse sufficienti per supportare un pool di connessioni, oltre a PostgreSQL.
• La condivisione di connessioni tra moduli diversi può diventare una vulnerabilità di sicurezza. È molto importante configurare pgPool o PgBouncer per pulire le connessioni prima che vengano restituite al pool.
• L'autenticazione passa dal DBMS al pool di connessioni. Questo potrebbe non essere sempre accettabile.

  

• Aumenta la superficie per l'attacco, a meno che l'accesso al database sottostante non sia bloccato per consentire l'accesso solo tramite il pool di connessioni.
• Crea ancora un altro componente che deve essere mantenuto, ottimizzato per il tuo carico di lavoro, patch di sicurezza spesso e aggiornato secondo necessità.

Dovresti usare un pool di connessioni PostgreSQL?

Tuttavia, tutti questi problemi sono ben discussi nella comunità di PostgreSQL e le strategie di mitigazione assicurano che i vantaggi di un pool di connessioni superino di gran lunga i loro contro. I nostri test mostrano che anche un numero limitato di clienti può trarre vantaggio dall'utilizzo di un pool di connessioni. Valgono bene lo sforzo aggiuntivo di configurazione e manutenzione.

Nel prossimo post parleremo di uno dei pool di connessioni più popolari nel mondo PostgreSQL:PgBouncer, seguito da Pgpool-II, e infine un confronto dei test delle prestazioni di questi due Pooler di connessioni PostgreSQL nel nostro ultimo post della serie.