O pool de conexões permite o uso de pools de conexões pré-configurados nos dialetos de banco de dados PostgreSQL e Snowflake.
Se o seu dialeto oferecer suporte, o pool de conexões de banco de dados permite que o Looker use pools de conexões pelo driver JDBC. O pooling de conexões de banco de dados permite uma performance de consulta mais rápida. Uma nova consulta não precisa criar uma nova conexão de banco de dados, mas pode usar uma conexão existente do pool de conexões. O recurso de agrupamento de conexões garante que uma conexão seja limpa após a execução de uma consulta e fique disponível para reutilização após o término da execução.
É possível ativar o agrupamento de conexões usando a opção Agrupamento de conexões de banco de dados ao criar ou editar uma conexão de banco de dados no Looker.
O Looker vai usar o pool de conexões se todas as condições a seguir forem verdadeiras:
- Você está usando um dos dialetos que oferecem suporte ao pool de conexões de banco de dados.
- A opção Agrupamento de conexões de banco de dados está ativada na conexão do Looker.
- Você configurou pools de conexão no seu banco de dados.
Veja alguns pontos a serem considerados ao usar pools de conexão:
Vários usuários compartilham um pool de conexões se os valores dos atributos do usuário forem idênticos. Os usuários que têm valores únicos ou diferentes no conjunto de atributos do usuário usam pools de conexão exclusivos ao se conectar ao banco de dados.
O número máximo de conexões que podem ser feitas em pools de conexões em todos os nós do banco de dados é limitado pelo valor no campo Conexões máximas por nó na página Conexão do banco de dados.
Se o número de consultas simultâneas emitidas para um pool de conexões exceder o número máximo de conexões, as consultas serão enfileiradas no Looker até que as consultas anteriores sejam executadas.
As strings de conexão JDBC exclusivas criam pools de conexões exclusivos. Por exemplo, nomes de usuário ou de grupo de banco de dados exclusivos que determinam o controle de acesso baseado em função ao banco de dados criam strings de conexão JDBC exclusivas, que, por sua vez, criam pools de conexões exclusivos. Por exemplo, um grupo financeiro em uma empresa pode ter uma função de banco de dados que concede acesso a todas as tabelas, mas a equipe de vendas e marketing pode ter uma função que concede acesso apenas a um subconjunto das tabelas do banco de dados. Nesse caso, cada grupo teria uma string de conexão JDBC e um pool de conexões exclusivos. Um terceiro grupo pode ser um conjunto de clientes de análise integrada que têm direitos de acesso próprios ao banco de dados. Os clientes da Análises incorporadas 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 estão em uso pelos grupos de finanças ou de vendas e marketing.
A cláusula
WHEREem uma consulta SQL não causa novos pools de conexão. A cláusulaWHEREnão tem impacto na string de conexão JDBC, portanto, um novo pool de conexões não é criado. Por exemplo, filtros de acesso únicos modificam a cláusulaWHEREdo SQL em uma consulta, não a string de conexão JDBC. Portanto, eles não criam 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.
Suporte a dialeto para pool de conexões de banco de dados
A capacidade de usar o pool de conexões do banco de dados depende do dialeto do banco de dados que a conexão do Looker está usando. Na versão mais recente do Looker, os seguintes dialetos oferecem suporte ao pool de conexões de banco de dados:
| Dialeto | Compatível? |
|---|---|
| Actian Avalanche | 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 mais recente | Não |
| Apache Druid 0.18 ou mais recente | Não |
| Apache Hive 2.3 ou mais recente | Não |
| Apache Hive 3.1.2 ou mais recente | Não |
| Apache Spark 3 ou mais recente | Não |
| ClickHouse | Não |
| Cloudera Impala 3.1+ | 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 |
| Dremio | Não |
| Dremio 11 ou mais recente | Não |
| Exasol | Não |
| Firebolt | 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 | Não |
| Greenplum | Sim |
| HyperSQL | Não |
| IBM Netezza | Não |
| MariaDB | Não |
| Microsoft Azure PostgreSQL | Sim |
| Banco de dados SQL do Microsoft Azure | Não |
| Microsoft Azure Synapse Analytics | Não |
| Microsoft SQL Server 2008 ou mais recente | Não |
| Microsoft SQL Server 2012 ou mais recente | Não |
| Microsoft SQL Server 2016 | Não |
| Microsoft SQL Server 2017 ou mais recente | Não |
| MongoBI | Não |
| MySQL | Não |
| MySQL 8.0.12 ou mais recente | Não |
| Oracle | Não |
| Oracle ADWC | Não |
| PostgreSQL 9.5 ou mais recente | Sim |
| PostgreSQL anterior à versão 9.5 | Sim |
| PrestoDB | Não |
| PrestoSQL | Não |
| SAP HANA 2+ | Não |
| SingleStore | Não |
| SingleStore 7+ | Não |
| Snowflake | Sim |
| Teradata | Não |
| Trino | Não |
| Vetor | Não |
| Vertica | Não |