O pool de conexões permite o uso de pools de conexão pré-configurados nos dialetos de banco de dados PostgreSQL e Snowflake.
Caso seu dialeto ofereça suporte, o pool de conexões do banco de dados permite que o Looker use pools de conexões pelo driver do JDBC. O pool de conexões de banco de dados permite um desempenho de consulta mais rápido. Uma nova consulta não precisa criar uma nova conexão de banco de dados, mas pode usar uma do pool de conexões. O recurso de pool de conexões garante que uma conexão seja limpa após a execução de uma consulta e esteja disponível para reutilização após o término da execução da consulta.
É possível ativar o pool de conexões usando a opção Pooling de conexões de banco de dados ao criar ou editar uma conexão de banco de dados no Looker.
O Looker usará o pool de conexões na sua conexão se todas as condições a seguir forem verdadeiras:
- Você está usando um dos dialetos compatíveis com o pool de conexões de banco de dados.
- A opção Pooling de conexão de banco de dados é ativada na conexão do Looker.
- Você configurou pools de conexão no seu banco de dados.
Confira o que você precisa considerar ao usar pools de conexão:
Vários usuários compartilham um pool de conexões se os valores de atributo do usuário forem idênticos. Os usuários com valores exclusivos ou diferentes no conjunto de atributos vão usar pools de conexões exclusivos ao se conectar ao banco de dados.
O número máximo de conexões que podem ser feitas para pools de conexão em todos os nós do banco de dados é limitado pelo valor no campo Máximo de conexões por nó na página Conexão do banco de dados.
Se o número de consultas simultâneas em um pool de conexões exceder o máximo de conexões, elas serão enfileiradas no Looker até que as consultas anteriores sejam executadas.
Strings de conexão JDBC exclusivas criam pools de conexão exclusivos. Por exemplo, nomes de usuários de bancos de dados ou nomes de grupos de bancos de dados que determinam o controle de acesso baseado em papéis ao banco de dados criam strings de conexão JDBC exclusivas, que criam pools de conexão exclusivos. Por exemplo, um grupo financeiro de uma empresa pode ter um papel de banco de dados que concede acesso a todas as tabelas do banco de dados, mas as equipes de vendas e marketing podem ter um papel de banco de dados que concede acesso a apenas um subconjunto das tabelas do banco de dados. Nesse caso, cada grupo teria uma string de conexão JDBC exclusiva e um pool de conexões exclusivo. Um terceiro grupo pode ser um conjunto de clientes de análises incorporados que têm os próprios direitos de acesso ao banco de dados. Os clientes de análise incorporada também teriam uma string JDBC exclusiva e um pool de conexões exclusivo, ou seja, um conjunto exclusivo de conexões que não são usados pelos grupos de finanças ou de vendas e marketing.
A cláusula
WHEREem uma consulta SQL não gera novos pools de conexão. Como a cláusulaWHEREnão tem impacto na string de conexão do JDBC, um novo pool de conexões não é criado. Por exemplo, filtros de acesso exclusivos modificam a cláusulaWHEREdo SQL em uma consulta, e não a string de conexão do JDBC, para que filtros de acesso único não criem novos pools de conexão.Quando vários pools de conexões são criados, o número máximo de conexões é fragmentado em vários pools, e cada pool contém um subconjunto de conexões disponíveis. Isso ocorre porque o número total de conexões não pode exceder o valor máximo de conexões.
Suporte a dialetos para pool de conexões de banco de dados
A capacidade de usar o pool de conexões de banco de dados depende do dialeto do banco de dados usado pela conexão do Looker. Na versão mais recente do Looker, os seguintes dialetos são compatíveis com o pool de conexões de banco de dados:
| Dialeto | Compatível? |
|---|---|
| Avalanche Actian | Não |
| Amazon Athena | Não |
| MySQL do Amazon Aurora | Não |
| Amazon Redshift | Não |
| Apache Druid | Não |
| Apache Druid 0.13 ou superior | Não |
| Apache Druid 0.18 ou superior | Não |
| Apache Hive 2.3 ou superior | Não |
| Apache Hive 3.1.2 ou posterior | Não |
| Apache Spark 3 ou mais recente | Não |
| ClickHouse | Não |
| Cloudera Impala 3.1 ou superior | Não |
| Cloudera Impala 3.1+ com driver nativo | Não |
| Cloudera Impala com driver nativo | Não |
| DataVirtuality | Não |
| Databricks | Não |
| Denodo 7 | Não |
| Denodo 8 | Não |
| Drêmio | Não |
| Dremio 11 ou superior | Não |
| Exasol | Não |
| Bola de fogo | Não |
| SQL legado do Google BigQuery | Não |
| SQL padrão do Google BigQuery | Não |
| PostgreSQL do Google Cloud | Sim |
| Google Cloud SQL | Não |
| Google Spanner (em inglês) | Não |
| Greenplum | Sim |
| HyperSQL | Não |
| IBM Netezza | Não |
| MariaDB | Não |
| PostgreSQL do Microsoft Azure | Sim |
| Banco de dados SQL do Microsoft Azure | Não |
| Análises do Microsoft Azure Synapse | Não |
| Microsoft SQL Server 2008 ou superior | Não |
| Microsoft SQL Server 2012 ou posterior | Não |
| Microsoft SQL Server 2016 | Não |
| Microsoft SQL Server 2017 ou posterior | Não |
| MongoBI | Não |
| MySQL | Não |
| MySQL 8.0.12 ou mais recente | Não |
| Oracle | Não |
| ADWC da Oracle | Não |
| PostgreSQL 9.5 ou mais recente | Sim |
| PostgreSQL anterior à 9.5 | Sim |
| PrestoDB | Não |
| PrestoSQL | Não |
| SAP HANA 2 ou posterior | Não |
| SingleStore | Não |
| SingleStore 7 ou superior | Não |
| Snowflake | Sim |
| Teradata | Não |
| Trino | Não |
| Vetor | Não |
| Vertica | Não |