Pool di connessioni al database

Il pool di connessioni consente l'utilizzo di pool di connessioni preconfigurati sui dialetti dei database PostgreSQL e Snowflake.

Se il tuo dialetto lo supporta, il pool di 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 pooling delle connessioni utilizzando l'opzione Pooling delle connessioni al database quando crei o modifichi una connessione al database in Looker.

Looker utilizzerà il pool di connessioni sulla connessione se tutte le seguenti condizioni sono vere:

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 in parallelo inviate a un pool di connessioni supera il numero massimo di connessioni, le query vengono messe in coda in Looker fino all'esecuzione di 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 creeranno pool di connessioni 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 univoca e un pool di connessioni univoci. Un terzo gruppo può essere un insieme di clienti di analisi incorporate che dispongono dei 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 WHERE in una query SQL non causa nuovi pool di connessioni. La clausola WHERE non ha alcun impatto sulla stringa di connessione JDBC, quindi 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 pooling delle connessioni al 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
Druid Apache
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 o 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
Netezza di IBM
No
MariaDB
No
PostgreSQL Microsoft Azure
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 pre-9.5
Sì
PrestoDB
No
PrestoSQL
No
SAP HANA 2 o versioni successive
No
SingleStore
No
SingleStore 7 e versioni successive
No
Snowflake
Sì
Teradata
No
Trino
No
Vettoriale
No
Vertica
No