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.
Puoi attivare il pool di connessioni utilizzando l'opzione Pool di connessioni al database quando crei o modifici una connessione al database in Looker.
Looker utilizzerà il pooling delle connessioni sulla tua connessione se si verificano tutte le seguenti condizioni:
- Stai utilizzando uno dei dialetti che supportano il pool di connessioni al database.
- 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
WHEREin una query SQL non causa nuovi pool di connessioni. La clausolaWHEREnon 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 SQLWHEREin 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:
| Dialetto | Supportato? |
|---|---|
| Actian Avalanche | No |
| Amazon Athena | No |
| Amazon Aurora MySQL | No |
| Amazon Redshift | No |
| Amazon Redshift 2.1+ | No |
| Amazon Redshift Serverless 2.1+ | No |
| Apache Druid | No |
| Apache Druid 0.13+ | No |
| Apache Druid 0.18+ | No |
| Apache Hive 2.3+ | No |
| Apache Hive 3.1.2+ | No |
| Apache Spark 3+ | No |
| ClickHouse | No |
| Cloudera Impala 3.1+ | No |
| Cloudera Impala 3.1+ with Native Driver | No |
| Cloudera Impala with Native Driver | No |
| DataVirtuality | No |
| Databricks | No |
| Denodo 7 | No |
| Denodo 8 & 9 | No |
| Dremio | No |
| Dremio 11+ | No |
| Exasol | No |
| Firebolt | No |
| Google BigQuery Legacy SQL | No |
| Google BigQuery Standard SQL | No |
| Google Cloud PostgreSQL | Sì |
| Google Cloud SQL | No |
| Google Spanner | No |
| Greenplum | Sì |
| HyperSQL | No |
| IBM Netezza | No |
| MariaDB | No |
| Microsoft Azure PostgreSQL | Sì |
| Microsoft Azure SQL Database | No |
| Microsoft Azure Synapse Analytics | No |
| Microsoft SQL Server 2008+ | No |
| Microsoft SQL Server 2012+ | No |
| Microsoft SQL Server 2016 | No |
| Microsoft SQL Server 2017+ | No |
| MongoBI | No |
| MySQL | No |
| MySQL 8.0.12+ | No |
| Oracle | No |
| Oracle ADWC | No |
| PostgreSQL 9.5+ | Sì |
| PostgreSQL pre-9.5 | Sì |
| PrestoDB | No |
| PrestoSQL | No |
| SAP HANA | No |
| SAP HANA 2+ | No |
| SingleStore | No |
| SingleStore 7+ | No |
| Snowflake | Sì |
| Teradata | No |
| Trino | No |
| Vector | No |
| Vertica | No |