Le regroupement de connexions permet d'utiliser des pools de connexions préconfigurés sur les dialectes de base de données Amazon Redshift, PostgreSQL et Snowflake.
Cette option permet à Looker d'utiliser des pools de connexions via le pilote JDBC. Le pooling de connexions aux bases de données accélère les performances des requêtes. Une nouvelle requête n'a pas besoin de créer de connexion à la base de données, mais peut utiliser une connexion existante du pool de connexions. La fonctionnalité de pooling de connexions garantit qu'une connexion est nettoyée après une exécution de requête et qu'elle peut être réutilisée à la fin de cette exécution.
Pour activer le pooling de connexions, activez la fonctionnalité expérimentale Pooling de connexions à la base de données. Lorsque la fonctionnalité expérimentale est activée, si vous avez configuré des pools de connexions dans votre base de données et que vous utilisez l'un des dialectes listés ci-dessus, Looker utilisera le pool de connexions.
Voici quelques éléments à prendre en compte lorsque vous utilisez des pools de connexions:
Plusieurs utilisateurs partagent un pool de connexions si leurs valeurs d'attributs utilisateur sont identiques. Les utilisateurs dont les attributs possèdent des valeurs uniques ou différentes se connecteront à la base de données à l'aide de pools de connexions uniques.
Le nombre maximal de connexions pouvant être établies aux pools de connexions sur tous les nœuds de base de données est limité par le 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 émises vers un pool de connexions dépasse la limite maximale, 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 connexion uniques. Par exemple, les noms d'utilisateur ou les noms de groupes de bases 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 connexion uniques. Par exemple, un groupe financier dans 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, alors que l'équipe commerciale et marketing peut disposer d'un rôle de base de données qui ne lui donne accès qu'à un sous-ensemble des tables de 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 utilisant les données analytiques intégrées qui disposent de leurs propres droits d'accès à la base de données. Les clients des analyses intégrées disposeraient également d'une chaîne JDBC unique et d'un pool de connexions unique. Ils disposeraient donc également d'un ensemble de connexions unique, qui ne sont pas utilisées par les groupes des services financiers, commerciaux et marketing.
La clause
WHEREdans une requête SQL ne génère pas de nouveaux pools de connexions. La clauseWHEREn'a aucun impact sur la chaîne de connexion JDBC. Par conséquent, aucun pool de connexion n'est créé. Par exemple, les filtres d'accès uniques modifient la clause SQLWHEREdans 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, chaque pool contenant un sous-ensemble de connexions disponibles. En effet, le nombre total de connexions ne peut pas dépasser la valeur maximale.