Utilizzare un pool di connessioni

Lakebase include un pool di connessioni PgBouncer predefinito che gestisce un pool di connessioni server e le condivide tra molte connessioni client. Il pooler supporta fino a 10.000 connessioni simultanee, rendendolo ideale per funzioni serverless, API Web e altre applicazioni che aprono molte connessioni di breve durata.

Il pool di connessioni richiede l'autenticazione password nativa di Postgres. Non è disponibile per i ruoli di identità OAuth o Azure Databricks.

Funzionamento del pool di connessioni

Ogni connessione Postgres utilizza risorse server perché Postgres crea un processo separato per ogni client. Le applicazioni che aprono molte connessioni di breve durata, ad esempio API Web e funzioni serverless, possono esaurire rapidamente il limite di connessione del server.

Il pool di connessioni si trova tra l'applicazione e Postgres. I client si connettono al pooler e il pooler inoltra le query a un pool più piccolo di connessioni server effettive. Al termine di una transazione, il pooler restituisce la connessione server al pool, rendendola disponibile al client successivo.

Lakebase esegue PgBouncer in modalità transazione. In modalità transazione, una connessione server viene mantenuta per la durata di una singola transazione e quindi restituita al pool. In questo modo, molti client condividono un piccolo pool di connessioni server.

La modalità transazione migliora l'efficienza della connessione, ma limita alcune funzionalità di Postgres che richiedono una connessione server persistente. Vedere Limitazioni della modalità transazione.

Pool di connessioni

PgBouncer crea un pool separato per ogni combinazione di database e utente. Due utenti che si connettono allo stesso database ottengono pool indipendenti. Le dimensioni di ogni pool sono circa 90% del limite di connessione diretta dell'ambiente di calcolo.

Quando tutte le connessioni all'interno di un pool sono in uso, le nuove richieste dei client attendono in coda. Se una connessione server non diventa disponibile entro 2 minuti, il client riceve un errore di timeout.

Limiti di connessione

Tre limiti regolano il pool di connessioni:

Il limite di connessione diretta dipende dalle dimensioni di calcolo. Ad esempio, un'unità di calcolo 8 CU supporta 1.678 connessioni dirette e un'unità di calcolo 16 CU supporta 3.357. Per l'elenco completo, vedere Specifiche di calcolo.

Il pool di connessioni consente all'applicazione di supportare utenti molto più simultanei rispetto al limite di connessione diretta consentito.

Prerequisiti

• Il progetto di scalabilità automatica di Lakebase deve essere attivo.
• Nel progetto è necessario avere un ruolo con password nativa in Postgres. Per istruzioni, vedere Creare un ruolo password Postgres nativo.
• Per usare il pooler di sola lettura, è necessario disporre di un endpoint a disponibilità elevata con Consenti l'accesso alle istanze di calcolo di sola lettura abilitate. Vedere Disponibilità elevata.

Abilitare il pool di connessioni

1. Nell'app Lakebase passare al progetto e fare clic su Connetti.
2. Selezionare il ramo e il calcolo a cui connettersi.
3. Nel menu a discesa Ruolo, selezionare un ruolo nativo di password Postgres. L'interruttore Pool di connessioni è visibile solo quando viene selezionato un ruolo di password. È nascosto per i ruoli di identità OAuth e Azure Databricks.
4. Attivare Pool di connessioni.
5. Copiare il stringa di connessione e usarlo nell'applicazione.

Formati di stringa di connessione

Le stringhe di connessione del pooler usano un nome host diverso rispetto alle connessioni dirette al database:

Entrambi i tipi di pooler usano la porta 5432.

Limitazioni della modalità transazione

Le funzionalità postgres seguenti non sono disponibili quando si usa il pool di connessioni:

• Istruzioni preparate a livello SQL: PREPARE e DEALLOCATE non sono supportate in modalità transazione. Le istruzioni preparate a livello di driver (usate internamente da psycopg2, node-postgres, JDBC e librerie simili) funzionano correttamente tramite il supporto a livello di protocollo di PgBouncer. Per JDBC, se vengono visualizzati errori correlati alle istruzioni preparate, impostare prepareThreshold=0 per disabilitare la memorizzazione nella cache delle istruzioni preparate lato server nominate.

• Impostazioni a livello di sessione: SET i comandi non vengono mantenuti tra le transazioni perché ogni transazione può usare una connessione server diversa. Per esempio:

  BEGIN;
  SET search_path TO myschema;
  SELECT * FROM mytable; -- works in this transaction
  COMMIT;
  -- connection returns to pool after COMMIT
  SELECT * FROM mytable; -- ERROR: relation "mytable" does not exist
  

  Per applicare un'impostazione in modo permanente, usare ALTER ROLE invece:

  ALTER ROLE myrole SET search_path TO myschema, public;
  

• Tabelle temporanee mantenute nella sessione: le tabelle temporanee che vengono mantenute tra le transazioni non sono disponibili. Una connessione restituita al pool può essere assegnata a un client diverso nella transazione successiva.

• WITH HOLD cursori: i cursori dichiarati con WITH HOLD richiedono una connessione permanente e non sono supportati.

• Blocchi consultivi: PgBouncer non supporta i blocchi consultivi. I blocchi consultivi richiedono una connessione server persistente, che non è disponibile in modalità di transazione.

• LISTEN/NOTIFY: non supportato. Usare una connessione diretta (non in pool) per le applicazioni che necessitano della messaggistica pub/sub.

• pg_dump e le migrazioni dello schema: Usare una connessione diretta per pg_dump, le migrazioni dello schema e altri strumenti che si basano sullo stato a livello di sessione.

Passaggi successivi

• Stringhe di connessione: riferimento al formato stringa di connessione per le connessioni dirette. Vedere Stringhe di connessione.
• Creare ruoli Postgres: come creare ruoli password Postgres nativi necessari per il pool di connessioni. Vedere Creare ruoli Postgres.
• Informazioni sull'autenticazione: confronto tra metodi di autenticazione OAuth e password. Vedere Informazioni sull'autenticazione.