Le regroupement de connexions permet d'utiliser des pools de connexions préconfigurés sur les dialectes de base de données PostgreSQL et Snowflake.
Si votre dialecte le prend en charge, le regroupement de connexions de base de données permet à Looker d'utiliser des pools de connexions via le pilote JDBC. Le regroupement de connexions de base de données permet d'améliorer les performances des requêtes. Une nouvelle requête n'a pas besoin de créer une connexion de base de données, mais peut utiliser une connexion existante à partir du pool de connexions. La fonctionnalité de regroupement de connexions garantit qu'une connexion est nettoyée après l'exécution d'une requête et qu'elle est disponible pour être réutilisée une fois l'exécution de la requête terminée.
Vous pouvez activer le regroupement de connexions à l'aide de l'option Regroupement de connexions de base de données lorsque vous créez ou modifiez une connexion de base de données dans Looker.
Looker utilisera le regroupement de connexions sur votre connexion si toutes les conditions suivantes sont remplies :
- Vous utilisez l'un des dialectes qui prennent en charge le regroupement de connexions de base de données.
- L'option Regroupement de connexions de base de données est activée sur la connexion Looker.
- Vous avez configuré des pools de connexions sur votre base de données.
Voici quelques points à prendre en compte lorsque vous utilisez des pools de connexions :
Plusieurs utilisateurs partagent un pool de connexions si les valeurs de leurs attributs utilisateur sont identiques. Les utilisateurs dont les valeurs sont uniques ou différentes dans leur ensemble d'attributs utilisateur utiliseront des pools de connexions uniques lorsqu'ils se connecteront à la base de données.
Le nombre maximal de connexions pouvant être établies avec des pools de connexions sur tous les nœuds de base de données est limité par la valeur du champ Nombre maximal de connexions par nœud de la page Connexion de la base de données.
Si le nombre de requêtes simultanées envoyées à un pool de connexions dépasse le nombre maximal de connexions, les requêtes sont mises en file d'attente dans Looker jusqu'à ce que les requêtes précédentes soient exécutées.
Les chaînes de connexion JDBC uniques créent des pools de connexions uniques. Par exemple, les noms d'utilisateur de base de données ou les noms de groupe de base de données uniques qui dictent le contrôle des accès basé sur les rôles à la base de données créent des chaînes de connexion JDBC uniques, qui créent ensuite des pools de connexions uniques. Par exemple, un groupe de finances d'une entreprise peut disposer d'un rôle de base de données qui lui donne accès à toutes les tables de la base de données, mais l'équipe commerciale et marketing peut disposer d'un rôle de base de données qui lui donne accès uniquement à un sous-ensemble des tables de la base de données. Dans ce cas, chaque groupe dispose d'une chaîne de connexion JDBC unique et d'un pool de connexions unique. Un troisième groupe peut être un ensemble de clients d'analyse intégrée qui disposent de leurs propres droits d'accès à la base de données. Les clients d'analyse intégrée disposent également d'une chaîne JDBC unique et d'un pool de connexions unique. Ils disposent donc également d'un ensemble unique de connexions qui ne sont pas utilisées par les groupes de finances ou de ventes et de marketing.
La clause
WHEREd'une requête SQL n'entraîne pas la création de nouveaux pools de connexions. La clauseWHEREn'a aucune incidence sur la chaîne de connexion JDBC. Par conséquent, aucun nouveau pool de connexions n'est créé. Par exemple, les filtres d'accès uniques modifient la clause SQLWHEREd'une requête, et non la chaîne de connexion JDBC. Par conséquent, les filtres d'accès uniques ne créent pas de nouveaux pools de connexions.Lorsque plusieurs pools de connexions sont créés, le nombre maximal de connexions est fragmenté en plusieurs pools, chacun contenant un sous-ensemble des connexions disponibles. Cela se produit, car le nombre total de connexions ne peut pas dépasser la valeur maximale de connexions.
Prise en charge du regroupement de connexions de base de données par dialecte
La possibilité d'utiliser le regroupement de connexions de base de données dépend du dialecte de base de données de votre connexion Looker. Dans la dernière version de Looker, les dialectes suivants prennent en charge le regroupement de connexions de base de données :
| Dialecte | Compatibilité |
|---|---|
| Actian Avalanche | |
| Amazon Athena | |
| Amazon Aurora MySQL | |
| Amazon Redshift | |
| Amazon Redshift 2.1+ | |
| Amazon Redshift Serverless 2.1+ | |
| Apache Druid | |
| Apache Druid 0.13+ | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| Cloudera Impala 3.1+ | |
| Cloudera Impala 3.1+ with Native Driver | |
| Cloudera Impala with Native Driver | |
| DataVirtuality | |
| Databricks | |
| Denodo 7 | |
| Denodo 8 & 9 | |
| Dremio | |
| Dremio 11+ | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud AlloyDB for PostgreSQL | |
| Google Cloud PostgreSQL | |
| Google Cloud SQL | |
| Google Spanner | |
| Greenplum | |
| HyperSQL | |
| IBM Netezza | |
| MariaDB | |
| Microsoft Azure PostgreSQL | |
| Microsoft Azure SQL Database | |
| Microsoft Azure Synapse Analytics | |
| Microsoft SQL Server 2008+ | |
| Microsoft SQL Server 2012+ | |
| Microsoft SQL Server 2016 | |
| Microsoft SQL Server 2017+ | |
| MongoBI | |
| MySQL | |
| MySQL 8.0.12+ | |
| Oracle | |
| Oracle ADWC | |
| PostgreSQL 9.5+ | |
| PostgreSQL pre-9.5 | |
| PrestoDB | |
| PrestoSQL | |
| SAP HANA | |
| SAP HANA 2+ | |
| SingleStore | |
| SingleStore 7+ | |
| Snowflake | |
| Teradata | |
| Trino | |
| Vector | |
| Vertica |