Il pooling delle connessioni consente di utilizzare pool di connessioni preconfigurati sui dialetti dei database PostgreSQL e Snowflake.
Se il tuo 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 prestazioni di query più rapide; 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 ripulita 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 modifichi una connessione al database in Looker.
Looker utilizzerà il pooling delle connessioni per la tua connessione se si verificano tutte le seguenti condizioni:
- Utilizzi uno dei dialetti che supportano il pool di connessioni al database.
- L'opzione Pool di connessioni al database è attivata nella connessione di Looker.
- Hai configurato pool di connessioni nel 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 univoci o diversi nel proprio insieme di attributi utente utilizzeranno pool di connessione univoci 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 fino a quando non vengono eseguite le query precedenti.
Le stringhe di connessione JDBC univoche creano pool di connessione univoci. Ad esempio, i nomi utente o di gruppo del database univoci che determinano il controllo dell'accesso basato sui ruoli al database creeranno stringhe di connessione JDBC univoche, che a loro volta creano pool di connessione univoci. Ad esempio, un gruppo finanziario di un'azienda potrebbe avere un ruolo del database che gli concede l'accesso a tutte le tabelle del database, mentre il team di vendita e marketing potrebbe avere un ruolo del database che gli concede l'accesso solo a un sottoinsieme di tabelle del database. In questo caso, ogni gruppo avrà una stringa di connessione JDBC e un pool di connessione univoci. Un terzo gruppo potrebbe essere un insieme di clienti di Analytics integrato che dispongono di propri diritti di accesso al database. I clienti di Dati aziendali integrati avranno anche una stringa JDBC e un pool di connessioni univoci, quindi avranno anche un insieme univoco di connessioni non in uso dai gruppi finanziari o di vendita e marketing.
La clausola
WHEREin una query SQL non genera nuovi pool di connessione. La clausolaWHEREnon influisce sulla stringa di connessione JDBC, pertanto non viene creato un nuovo pool di connessioni. Ad esempio, i filtri di accesso univoci modificano la clausolaWHERESQL in una query, non la stringa di connessione JDBC, pertanto non creano nuovi pool di connessione.Quando vengono creati più pool di connessioni, il numero massimo di connessioni viene frammentato in più pool, ciascuno contenente un sottoinsieme di connessioni disponibili. Questo accade perché il numero totale di connessioni non può superare il valore massimo delle connessioni.
Supporto dei dialetti per il pool di connessioni al database
La possibilità di utilizzare il pool di connessioni del database dipende dal dialetto del database utilizzato dalla connessione di 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 |
| 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 | 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 |