Pool di connessioni al database

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:

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 è possibile effettuare 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 quelle 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 embedded 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 WHERE in una query SQL non genera nuovi pool di connessione. La clausola WHERE non influisce sulla stringa di connessione JDBC, pertanto non viene creato un nuovo pool di connessioni. Ad esempio, i filtri di accesso univoci modificano la clausola WHERE SQL 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 o versioni successive
No
Apache Druid 0.18 o versioni successive
No
Apache Hive 2.3 e versioni successive
No
Apache Hive 3.1.2 e versioni successive
No
Apache Spark 3 e versioni successive
No
ClickHouse
No
Cloudera Impala 3.1 e versioni successive
No
Cloudera Impala 3.1 e versioni successive con driver nativo
No
Cloudera Impala con driver nativo
No
DataVirtuality
No
Databricks
No
Denodo 7
No
Denodo 8
No
Dremio
No
Dremio 11+
No
Exasol
No
Fulmine
No
SQL precedente di Google BigQuery
No
SQL standard di Google BigQuery
No
PostgreSQL di Google Cloud
Sì
Google Cloud SQL
No
Google Spanner
No
Greenplum
Sì
HyperSQL
No
IBM Netezza
No
MariaDB
No
Microsoft Azure PostgreSQL
Sì
Database SQL di Microsoft Azure
No
Microsoft Azure Synapse Analytics
No
Microsoft SQL Server 2008 e versioni successive
No
Microsoft SQL Server 2012 e versioni successive
No
Microsoft SQL Server 2016
No
Microsoft SQL Server 2017 e versioni successive
No
MongoBI
No
MySQL
No
MySQL 8.0.12 e versioni successive
No
Oracle
No
Oracle ADWC
No
PostgreSQL 9.5 e versioni successive
Sì
PostgreSQL precedente alla versione 9.5
Sì
PrestoDB
No
PrestoSQL
No
SAP HANA 2 e versioni successive
No
SingleStore
No
SingleStore 7 e versioni successive
No
Snowflake
Sì
Teradata
No
Trino
No
Vettoriale
No
Vertica
No