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 pool di connessioni al database consente prestazioni più rapide 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 ripulita dopo l'esecuzione di una query e sia disponibile per il riutilizzo al termine dell'esecuzione della query.
Puoi abilitare il pool di connessioni utilizzando l'opzione Pool di connessioni 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:
- Stai utilizzando uno dei dialetti che supportano il pool di connessioni al database.
- L'opzione Pool di connessioni database è abilitata sulla connessione di Looker.
- Hai configurato dei pool di connessioni sul database.
Ecco alcuni aspetti da considerare quando utilizzi i pool di connessioni:
Più utenti condividono un pool di connessioni se i valori dei loro attributi utente sono identici. Gli utenti con valori univoci o diversi nel set di attributi utente utilizzeranno pool di connessioni univoci durante la connessione al database.
Il numero massimo di connessioni che è possibile effettuare ai pool di connessioni in tutti i nodi di 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 all'esecuzione di query precedenti.
Le stringhe di connessione JDBC univoche creano pool di connessioni univoci. Ad esempio, nomi utente univoci del database o nomi di gruppi di database che determinano il controllo dell'accesso basato sui ruoli al database creano stringhe di connessione JDBC univoche, che a loro volta creano pool di connessioni univoci. Ad esempio, un gruppo finanziario di un'azienda potrebbe avere un ruolo nel database che gli concede l'accesso a tutte le tabelle del database, ma il team addetto alle vendite e al 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 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 dell'analisi incorporata avranno anche una stringa JDBC univoca e un pool di connessioni univoci, in modo da avere anche un insieme unico di connessioni che non sono utilizzati dal gruppo finanziario, dalle vendite e dal marketing.
La clausola
WHERE
in una query SQL non causa nuovi pool di connessioni. La clausolaWHERE
non ha alcun impatto sulla stringa di connessione JDBC, quindi non viene creato un nuovo pool di connessioni. Ad esempio, filtri di accesso univoci modificano la clausolaWHERE
SQL in una query, non la stringa di connessione JDBC, quindi i filtri di accesso univoci non creeranno nuovi pool di connessioni.Quando vengono creati più pool di connessioni, il numero massimo di connessioni viene frammentato in più pool e ogni pool contiene un sottoinsieme di connessioni disponibili. Ciò si verifica 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 a Looker. Nella versione più recente di Looker, i seguenti dialetti supportano il pool di connessioni ai database:
Dialetto | Supportata? |
---|---|
Valanga Actia | 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 o versioni successive | No |
Apache Hive 3.1.2 o versioni successive | No |
Apache Spark 3 e versioni successive | No |
ClickHouse | No |
Cloudera Impala 3.1 o versioni successive | No |
Cloudera Impala 3.1 o 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 |
Firebolt | No |
SQL precedente di Google BigQuery | No |
SQL standard di Google BigQuery | No |
Google Cloud PostgreSQL | 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 o versioni successive | No |
Microsoft SQL Server 2016 | No |
Microsoft SQL Server 2017 o versioni successive | No |
MongoBI | No |
MySQL | No |
MySQL 8.0.12 o 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+ | No |
Snowflake | Sì |
Teradata | No |
Trino | No |
Vettoriale | No |
Vertica | No |