A partilha de ligações permite a utilização de partilhas de ligações pré-configuradas nos dialetos de base de dados PostgreSQL e Snowflake.
Se o seu dialeto o suportar, a partilha de ligações à base de dados permite ao Looker usar conjuntos de ligações através do controlador JDBC. A partilha de ligações à base de dados permite um desempenho mais rápido das consultas. Uma nova consulta não precisa de criar uma nova ligação à base de dados, mas pode usar uma ligação existente da partilha de ligações. A capacidade de agrupamento de ligações garante que uma ligação é limpa após a execução de uma consulta e está disponível para reutilização após o fim da execução da consulta.
Pode ativar a partilha de ligações através da opção Partilha de ligações à base de dados quando cria ou edita uma ligação à base de dados no Looker.
O Looker usa o agrupamento de ligações na sua ligação se todas as seguintes condições forem verdadeiras:
- Está a usar um dos dialetos que suportam o agrupamento de ligações de bases de dados.
- A opção Database Connection Pooling está ativada na ligação do Looker.
- Configurou pools de ligações na sua base de dados.
Seguem-se alguns aspetos a considerar quando usa conjuntos de ligações:
Vários utilizadores partilham um conjunto de ligações se os respetivos valores de atributos de utilizador forem idênticos. Os utilizadores que têm valores únicos ou diferentes no respetivo conjunto de atributos do utilizador usam conjuntos de ligações únicos quando se ligam à base de dados.
O número máximo de ligações que podem ser feitas a conjuntos de ligações em todos os nós da base de dados é limitado pelo valor no campo Máximo de ligações por nó na página Ligação da base de dados.
Se o número de consultas simultâneas emitidas para um conjunto de ligações exceder o número máximo de ligações, as consultas são colocadas em fila no Looker até que as consultas anteriores sejam executadas.
As strings de ligação JDBC únicas criam pools de ligações únicos. Por exemplo, os nomes de utilizadores exclusivos da base de dados ou os nomes de grupos da base de dados que ditam o controlo de acesso baseado em funções à base de dados criam cadeias de caracteres de ligação JDBC exclusivas, que, por sua vez, criam conjuntos de ligações exclusivos. Por exemplo, um grupo de finanças numa empresa pode ter uma função de base de dados que lhe concede acesso a todas as tabelas na base de dados, mas a equipa de vendas e marketing pode ter uma função de base de dados que lhe concede acesso apenas a um subconjunto das tabelas da base de dados. Neste caso, cada grupo teria uma string de ligação JDBC única e um conjunto de ligações único. Um terceiro grupo pode ser um conjunto de clientes de estatísticas incorporadas que têm os seus próprios direitos de acesso à base de dados. Os clientes de estatísticas incorporadas também teriam uma string JDBC única e um conjunto de ligações único, pelo que também teriam um conjunto único de ligações que não estão a ser usadas pelos grupos de finanças ou vendas e marketing.
A cláusula
WHEREnuma consulta SQL não causa novos conjuntos de ligações. A cláusulaWHEREnão tem impacto na string de ligação JDBC, pelo que não é criado um novo conjunto de ligações. Por exemplo, os filtros de acesso exclusivos modificam a cláusulaWHERESQL numa consulta e não a string de ligação JDBC, pelo que os filtros de acesso exclusivos não criam novas pools de ligações.Quando são criados vários conjuntos de ligações, o número máximo de ligações é fragmentado em vários conjuntos, com cada conjunto a conter um subconjunto de ligações disponíveis. Isto ocorre porque o número total de associações não pode exceder o valor máximo de associações.
Suporte de dialetos para o agrupamento de ligações à base de dados
A capacidade de usar o agrupamento de ligações à base de dados depende do dialeto da base de dados que a sua ligação do Looker está a usar. No lançamento mais recente do Looker, os seguintes dialetos suportam o agrupamento de ligações à base de dados:
| Dialeto | Compatível? |
|---|---|
| Actian Avalanche | Não |
| Amazon Athena | Não |
| Amazon Aurora MySQL | Não |
| Amazon Redshift | Não |
| Amazon Redshift 2.1+ | Não |
| Amazon Redshift Serverless 2.1+ | Não |
| Apache Druid | Não |
| Apache Druid 0.13+ | Não |
| Apache Druid 0.18+ | Não |
| Apache Hive 2.3+ | Não |
| Apache Hive 3.1.2+ | Não |
| Apache Spark 3+ | Não |
| ClickHouse | Não |
| Cloudera Impala 3.1+ | Não |
| Cloudera Impala 3.1+ with Native Driver | Não |
| Cloudera Impala with Native Driver | Não |
| DataVirtuality | Não |
| Databricks | Não |
| Denodo 7 | Não |
| Denodo 8 & 9 | Não |
| Dremio | Não |
| Dremio 11+ | Não |
| Exasol | Não |
| Firebolt | Não |
| Google BigQuery Legacy SQL | Não |
| Google BigQuery Standard SQL | Não |
| Google Cloud PostgreSQL | 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 |
| Microsoft Azure SQL Database | Não |
| Microsoft Azure Synapse Analytics | Não |
| Microsoft SQL Server 2008+ | Não |
| Microsoft SQL Server 2012+ | Não |
| Microsoft SQL Server 2016 | Não |
| Microsoft SQL Server 2017+ | Não |
| MongoBI | Não |
| MySQL | Não |
| MySQL 8.0.12+ | Não |
| Oracle | Não |
| Oracle ADWC | Não |
| PostgreSQL 9.5+ | Sim |
| PostgreSQL pre-9.5 | Sim |
| PrestoDB | Não |
| PrestoSQL | Não |
| SAP HANA | Não |
| SAP HANA 2+ | Não |
| SingleStore | Não |
| SingleStore 7+ | Não |
| Snowflake | Sim |
| Teradata | Não |
| Trino | Não |
| Vector | Não |
| Vertica | Não |