El agrupamiento de conexiones permite usar grupos de conexiones preconfigurados en los dialectos de bases de datos 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 más rápido de las consultas; una consulta nueva no necesita crear una conexión de base de datos nueva, 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 su reutilización 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:
- Usas uno de los dialectos que admiten la agrupación de conexiones de bases de datos.
- La opción Database Connection Pooling está habilitada en la conexión de Looker.
- Configuraste grupos de conexiones en tu base de datos.
A continuación, se incluyen algunos aspectos que debes tener en cuenta cuando usas grupos de conexiones:
Varios usuarios comparten un grupo de conexiones si los valores de sus atributos de usuario son idénticos. Los usuarios que tienen valores únicos o diferentes en su conjunto de atributos del 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 Max connections per node en la página Connection de la base de datos.
Si la cantidad de consultas simultáneas que se envían 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 JDBC únicas crean grupos de conexiones únicos. Por ejemplo, los nombres de usuario o los nombres de grupos de bases de datos únicos que dictan el control de acceso basado en roles a la base de datos crearán cadenas de conexión JDBC únicas, que luego crearán grupos de conexiones únicos. Por ejemplo, un grupo de finanzas de una empresa puede tener un rol de base de datos que le otorgue 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 otorgue 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 y un grupo de conexiones únicos. Un tercer grupo podría ser un conjunto de clientes de análisis integrados que tienen sus propios derechos de acceso a la base de datos. Los clientes de análisis integrados también tendrían una cadena JDBC y un grupo de conexiones únicos, por lo que también tendrían un conjunto único de conexiones que no utilizan los grupos de finanzas ni de ventas y marketing.
La cláusula
WHEREen una consulta en SQL no genera agrupaciones de conexiones nuevas. La cláusulaWHEREno tiene ningún impacto en la cadena de conexión JDBC, por lo que no se crea un nuevo grupo de conexiones. Por ejemplo, los filtros de acceso únicos modifican la cláusulaWHEREde SQL en una consulta, no la cadena de conexión JDBC, por lo que los filtros de acceso únicos no crearán nuevos grupos de conexiones.Cuando se crean varios grupos de conexiones, la cantidad máxima de conexiones se fragmenta en varios grupos, y cada uno contiene un subconjunto de las conexiones disponibles. Esto ocurre porque la cantidad total de conexiones no puede superar el valor de conexiones máximas.
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 usa 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? |
|---|---|
| Actian Avalanche | No |
| Amazon Athena | No |
| Amazon Aurora MySQL | No |
| Amazon Redshift | No |
| Amazon Redshift 2.1+ | No |
| Amazon Redshift Serverless 2.1+ | No |
| Apache Druid | No |
| Apache Druid 0.13+ | No |
| Apache Druid 0.18+ | No |
| Apache Hive 2.3+ | No |
| Apache Hive 3.1.2+ | No |
| Apache Spark 3+ | No |
| ClickHouse | No |
| Cloudera Impala 3.1+ | No |
| Cloudera Impala 3.1+ with Native Driver | No |
| Cloudera Impala with Native Driver | No |
| DataVirtuality | No |
| Databricks | No |
| Denodo 7 | No |
| Denodo 8 & 9 | No |
| Dremio | No |
| Dremio 11+ | No |
| Exasol | No |
| Firebolt | No |
| Google BigQuery Legacy SQL | No |
| Google BigQuery Standard SQL | No |
| Google Cloud PostgreSQL | Sí |
| Google Cloud SQL | No |
| Google Spanner | No |
| Greenplum | Sí |
| HyperSQL | No |
| IBM Netezza | No |
| MariaDB | No |
| Microsoft Azure PostgreSQL | Sí |
| Microsoft Azure SQL Database | No |
| Microsoft Azure Synapse Analytics | No |
| Microsoft SQL Server 2008+ | No |
| Microsoft SQL Server 2012+ | No |
| Microsoft SQL Server 2016 | No |
| Microsoft SQL Server 2017+ | No |
| MongoBI | No |
| MySQL | No |
| MySQL 8.0.12+ | No |
| Oracle | No |
| Oracle ADWC | No |
| PostgreSQL 9.5+ | Sí |
| PostgreSQL pre-9.5 | Sí |
| PrestoDB | No |
| PrestoSQL | No |
| SAP HANA | No |
| SAP HANA 2+ | No |
| SingleStore | No |
| SingleStore 7+ | No |
| Snowflake | Sí |
| Teradata | No |
| Trino | No |
| Vector | No |
| Vertica | No |