Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Il pooling delle connessioni consente l'utilizzo di pool di connessioni preconfigurati nei dialetti di database PostgreSQL e Snowflake.
Se il dialetto lo supporta, il pooling delle connessioni al database consente a Looker di utilizzare pool di connessioni tramite il driver JDBC. Il pooling delle connessioni al database consente di migliorare le prestazioni delle query. Una nuova query non deve creare una nuova connessione al database, ma può utilizzare una connessione esistente dal pool di connessioni. La funzionalità di pooling delle connessioni garantisce che una connessione venga pulita dopo l'esecuzione di una query e sia disponibile per il riutilizzo al termine dell'esecuzione della query.
L'opzione Pool di connessioni al database è abilitata nella connessione Looker.
Hai configurato i pool di connessioni sul tuo database.
Ecco alcuni aspetti da considerare quando utilizzi i pool di connessioni:
Più utenti condividono un pool di connessioni se i valori degli attributi utente sono identici. Gli utenti che hanno valori unici o diversi nel loro insieme di attributi utente utilizzeranno pool di connessioni unici quando si connettono al database.
Il numero massimo di connessioni che possono essere effettuate ai pool di connessioni in tutti i nodi del database è limitato dal valore nel campo Numero massimo di connessioni per nodo nella pagina Connessione del database.
Se il numero di query simultanee inviate a un pool di connessioni supera il numero massimo di connessioni, le query vengono messe in coda in Looker finché non vengono eseguite le query precedenti.
Stringhe di connessione JDBC uniche creano pool di connessioni unici. Ad esempio, nomi utente univoci del database o nomi di gruppi di database che determinano il controllo dell'accesso basato sui ruoli al database creeranno stringhe di connessione JDBC univoche, che a loro volta creeranno pool di connessioni univoci. Ad esempio, un gruppo finanziario di un'azienda potrebbe avere un ruolo di database che gli concede l'accesso a tutte le tabelle del database, mentre il team di vendite e marketing potrebbe avere un ruolo di database che gli concede l'accesso solo a un sottoinsieme delle tabelle del database. In questo caso, ogni gruppo avrebbe una stringa di connessione JDBC univoca e un pool di connessioni univoco. Un terzo gruppo potrebbe essere un insieme di clienti di embedded analytics che dispongono di propri diritti di accesso al database. I clienti di analisi incorporate avrebbero anche una stringa JDBC univoca e un pool di connessioni univoco, quindi avrebbero anche un insieme univoco di connessioni non utilizzate dai gruppi di finanza o vendite e marketing.
La clausola WHERE in una query SQL non causa nuovi pool di connessioni. La clausola WHERE non ha alcun impatto sulla stringa di connessione JDBC, pertanto non viene creato un nuovo pool di connessioni. Ad esempio, i filtri di accesso univoci modificano la clausola SQL WHERE in una query, non la stringa di connessione JDBC, quindi non creano nuovi pool di connessioni.
Quando vengono creati più pool di connessioni, il numero massimo di connessioni viene frammentato in più pool, ognuno dei quali contiene un sottoinsieme di connessioni disponibili. Ciò accade perché il numero totale di connessioni non può superare il valore massimo di connessioni.
Supporto dei dialetti per il pool di connessioni al database
La possibilità di utilizzare il pool di connessioni al database dipende dal dialetto del database utilizzato dalla connessione Looker. Nell'ultima release di Looker, i seguenti dialetti supportano il pooling delle connessioni al database:
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[],[],null,["# Database connection pooling\n\nConnection pooling enables the use of preconfigured connection pools on [PostgreSQL](/looker/docs/db-config-postgresql) and [Snowflake](/looker/docs/db-config-snowflake) database dialects.\n\n[If your dialect supports it](#dialect_support_for_database_connection_pooling), database connection pooling enables Looker to use pools of connections through the JDBC driver. Database connection pooling enables faster query performance; a new query does not need to create a new database connection but can instead use an existing connection from the connection pool. The connection pooling capability ensures that a connection is cleaned up after a query execution and is available for reuse after the query execution ends.\n\nYou can enable connection pooling using the [**Database Connection Pooling**](/looker/docs/admin-panel-general-labs#database_connection_pooling) option when you [create](/looker/docs/connecting-to-your-db) or [edit](/looker/docs/admin-panel-database-connections#editing_connections) a database connection in Looker.\n| **Note:** Database connection pooling was previously a Looker [Labs](/looker/docs/admin-panel-general-labs) feature. When **Database Connection Pooling** moved out of Labs, Looker automatically applied the **Database Connection Pooling** Labs setting to the **Database Connection Pooling** connection setting for any database connections on your instance that support connection pooling.\n\nLooker will use connection pooling on your connection if all of the following are true:\n\n- You are using one of the [dialects that support database connection pooling](#dialect_support_for_database_connection_pooling).\n- The **Database Connection Pooling** option is enabled on the Looker connection.\n- You have configured connection pools on your database.\n\nHere are some things to consider when you're using connection pools:\n\n- Multiple users share a connection pool if their user attribute values are identical. Users who have unique or differing values in their set of user attributes will use unique connection pools when connecting to the database.\n\n- The maximum number of connections that can be made to connection pools across all database nodes is limited by the value in the [**Max connections per node**](/looker/docs/connecting-to-your-db#max_connections) field in the database's **Connection** page.\n\n- If the number of concurrent queries being issued to a connection pool exceeds the maximum number of connections, queries are queued in Looker until prior queries are executed.\n\n- Unique JDBC connection strings create unique connection pools. For example, unique database usernames or database group names that dictate role-based access control to the database will create unique JDBC connection strings, which then create unique connection pools. For example, a finance group in a company may have a database role that grants them access to all tables in the database, but the sales and marketing team may have a database role that grants them access to only a subset of the database tables. In this case, each group would have a unique JDBC connection string and a unique connection pool. A third group might be a set of [embedded analytics](/looker/docs/single-sign-on-embedding) customers who have their own access rights to the database. The embedded analytics customers would also have a unique JDBC string and a unique connection pool, so they would also have a unique set of connections that are not in use by the finance or sales and marketing groups.\n\n- The `WHERE` clause in a SQL query does not cause new connection pools. The `WHERE` clause has no impact on the JDBC connection string, so a new connection pool is not created. For example, unique [access filters](/looker/docs/reference/param-explore-access-filter) modify the SQL `WHERE` clause in a query, not the JDBC connection string, so unique access filters won't create new connection pools.\n\n- When multiple connection pools are created, the maximum number of connections is fragmented into multiple pools, with each pool containing a subset of available connections. This occurs because the total number of connections cannot exceed the maximum connections value.\n\nDialect support for database connection pooling\n-----------------------------------------------\n\nThe ability to use database connection pooling depends on the database dialect your Looker connection is using. In the latest release of Looker, the following dialects support database connection pooling:"]]
