Agrupación de conexiones de bases de datos

La agrupación de conexiones permite el uso de grupos de conexiones preconfigurados en los dialectos de bases de datos de PostgreSQL y Snowflake.

Si tu dialecto lo admite, la agrupación de conexiones de bases de datos permite que Looker use grupos de conexiones a través del controlador JDBC. La agrupación de conexiones de bases de datos permite un rendimiento de consultas más rápido. Una consulta nueva no necesita crear una nueva conexión con la base de datos, sino que puede usar una conexión existente del grupo de conexiones. La capacidad de agrupación de conexiones garantiza que una conexión se limpie después de la ejecución de una consulta y esté disponible para volver a usarse después de que finalice la ejecución de la consulta.

Puedes habilitar la agrupación de conexiones con la opción Agrupación de conexiones de bases de datos cuando creas o editas una conexión de base de datos en Looker.

Looker usará la agrupación de conexiones en tu conexión si se cumplen todas las siguientes condiciones:

Estos son algunos aspectos que debes tener en cuenta cuando usas grupos de conexiones:

  • Varios usuarios comparten un grupo de conexiones si sus valores del atributo de usuario son idénticos. Los usuarios que tengan valores únicos o diferentes en su conjunto de atributos de usuario usarán grupos de conexiones únicos cuando se conecten a la base de datos.

  • La cantidad máxima de conexiones que se pueden realizar a los grupos de conexiones en todos los nodos de la base de datos está limitada por el valor del campo Cantidad máxima de conexiones por nodo en la página Conexión de la base de datos.

  • Si la cantidad de consultas simultáneas que se emiten a un grupo de conexiones supera la cantidad máxima de conexiones, las consultas se ponen en cola en Looker hasta que se ejecuten las consultas anteriores.

  • Las cadenas de conexión de JDBC únicas crean grupos de conexiones únicos. Por ejemplo, los nombres de usuario únicos de bases de datos o los nombres de grupos de bases de datos que dictan el control de acceso basado en roles a la base de datos crearán cadenas de conexión de JDBC únicas, que luego crearán grupos de conexiones únicos. Por ejemplo, un grupo financiero en una empresa puede tener un rol de base de datos que le otorga acceso a todas las tablas de la base de datos, pero el equipo de ventas y marketing puede tener un rol de base de datos que le otorga acceso solo a un subconjunto de las tablas de la base de datos. En este caso, cada grupo tendría una cadena de conexión JDBC única y un grupo de conexiones único. Un tercer grupo podría ser un conjunto de clientes de estadísticas incorporadas que tienen sus propios derechos de acceso a la base de datos. Los clientes de estadísticas incorporadas también tendrían una cadena única de JDBC y un grupo de conexiones único, por lo que también tendrían un conjunto único de conexiones que no usan los grupos de finanzas, ventas y marketing.

  • La cláusula WHERE en una consulta en SQL no genera grupos de conexiones nuevos. La cláusula WHERE no tiene impacto en la string de conexión de JDBC, por lo que no se crea un grupo de conexiones nuevo. Por ejemplo, los filtros de acceso únicos modifican la cláusula WHERE de SQL en una consulta, no la cadena de conexión de JDBC, por lo que los filtros de acceso únicos no crearán grupos de conexiones nuevos.

  • Cuando se crean varios grupos de conexiones, la cantidad máxima de conexiones se fragmenta en varios grupos, y cada grupo contiene un subconjunto de conexiones disponibles. Esto ocurre porque la cantidad total de conexiones no puede superar el valor máximo de conexiones.

Compatibilidad con dialectos para la agrupación de conexiones de bases de datos

La capacidad de usar la agrupación de conexiones de bases de datos depende del dialecto de la base de datos que use tu conexión de Looker. En la versión más reciente de Looker, los siguientes dialectos admiten la agrupación de conexiones de bases de datos:

Dialecto ¿Es compatible?
Avalancha de Actian
No
Amazon Athena
No
Amazon Aurora MySQL
No
Amazon Redshift
No
Apache Druid
No
Apache Druid 0.13 y versiones posteriores
No
Apache Druid 0.18 y versiones posteriores
No
Apache Hive 2.3 y versiones posteriores
No
Apache Hive 3.1.2 y versiones posteriores
No
Apache Spark 3 y versiones posteriores
No
ClickHouse
No
Cloudera Impala 3.1 y versiones posteriores
No
Cloudera Impala 3.1+ con controlador nativo
No
Cloudera Impala con controlador nativo
No
DataVirtuality
No
Databricks
No
Denodo 7
No
Denodo 8
No
Dremio
No
Dremio 11 y versiones posteriores
No
Exasol
No
Bola de fuego
No
SQL heredado de Google BigQuery
No
SQL estándar de Google BigQuery
No
PostgreSQL en Google Cloud
Sí
Google Cloud SQL
No
Google Spanner
No
Greenplum
Sí
HyperSQL
No
IBM Netezza
No
MariaDB
No
Microsoft Azure PostgreSQL
Sí
Base de datos de Microsoft Azure SQL
No
Microsoft Azure Synapse Analytics
No
Microsoft SQL Server 2008 y versiones posteriores
No
Microsoft SQL Server 2012 y versiones posteriores
No
Microsoft SQL Server 2016
No
Microsoft SQL Server 2017 y versiones posteriores
No
MongoBI
No
MySQL
No
MySQL 8.0.12 y versiones posteriores
No
Oracle
No
Oracle ADWC
No
PostgreSQL 9.5 y versiones posteriores
Sí
PostgreSQL anterior a 9.5
Sí
PrestoDB
No
PrestoSQL
No
SAP HANA 2 y versiones posteriores
No
SingleStore
No
SingleStore 7 y versiones posteriores
No
Snowflake
Sí
Teradata
No
Trino
No
Vector
No
Vertica
No