La agrupación de conexiones permite usar grupos de conexiones preconfigurados en los dialectos de base 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 que las consultas se ejecuten más rápido, ya que no es necesario crear una conexión de base de datos nueva para cada consulta, sino que se puede usar una conexión del grupo de conexiones. La función de agrupación de conexiones asegura que una conexión se limpia después de la ejecución de una consulta y está disponible para volver a usarse cuando finaliza la ejecución de la consulta.
Puedes habilitar la agrupación de conexiones mediante 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 condiciones siguientes:
- Estás usando uno de los dialectos que admiten la agrupación de conexiones de bases de datos.
- La opción Grupo de conexiones de base de datos está habilitada en la conexión de Looker.
- Ha configurado grupos de conexiones en su base de datos.
A continuación, te indicamos algunos aspectos que debes tener en cuenta al usar grupos de conexiones:
Varios usuarios comparten un grupo de conexiones si los valores de sus atributos 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 al conectarse a la base de datos.
El número máximo de conexiones que se pueden establecer en los grupos de conexiones de todos los nodos de la base de datos está limitado por el valor del campo Conexiones máximas por nodo de la página Conexión de la base de datos.
Si el número de consultas simultáneas que se envían a un grupo de conexiones supera el número máximo de conexiones, las consultas se ponen en cola en Looker hasta que se ejecuten las anteriores.
Las cadenas de conexión JDBC únicas crean grupos de conexiones únicos. Por ejemplo, los nombres de usuario o de grupo de la base de datos únicos que determinan el control de acceso basado en roles a la base de datos crearán cadenas de conexión JDBC únicas, que a su vez 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 conceda 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 conceda 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 pool de conexiones único. Un tercer grupo podría ser un conjunto de clientes de analíticas insertadas que tienen sus propios derechos de acceso a la base de datos. Los clientes de analíticas insertadas también tendrían una cadena JDBC y un pool de conexiones únicos, por lo que también tendrían un conjunto de conexiones único que no utilizarían los grupos de finanzas, ventas y marketing.
La cláusula
WHEREde una consulta de SQL no provoca que se creen nuevos grupos de conexiones. La cláusulaWHEREno influye 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 no crean grupos de conexiones nuevos.Cuando se crean varios grupos de conexiones, el número máximo de conexiones se fragmenta en varios grupos, y cada grupo contiene un subconjunto de las conexiones disponibles. Esto ocurre porque el número total de conexiones no puede superar el valor máximo de conexiones.
Compatibilidad con dialectos para el grupo de conexiones de bases de datos
La posibilidad de usar la agrupación de conexiones de bases de datos depende del dialecto de la base de datos que utilice 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 |