Le pooling de connexions permet d'utiliser des pools de connexions préconfigurés sur les dialectes de la base de données Amazon Redshift, PostgreSQL et Snowflake.
Cette option permet à Looker d'utiliser des pools de connexions via le pilote JDBC. Le regroupement de connexions à la base de données permet d'accélérer 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 à la place utiliser une connexion existante du pool de connexions. La fonctionnalité de regroupement 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é Pools de connexion de 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 répertoriés ci-dessus, Looker utilisera le pooling des connexions.
Points à 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 valeurs d'attributs utilisateur sont uniques ou différentes utilisent des pools de connexions uniques lorsqu'ils se connectent à la base de données.
Le nombre maximal de connexions pouvant être effectuées sur 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 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 uniques ou les noms de groupes de bases de données qui imposent un contrôle d'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, mais l'équipe commerciale et marketing peut disposer d'un rôle de base de données qui ne leur donne accès qu'à un sous-ensemble des tables de la base de données. Dans ce cas, chaque groupe possède une chaîne de connexion JDBC unique et un pool de connexions unique. Un troisième groupe peut être un ensemble de clients Powered by Looker (PBL) qui disposent de leurs propres droits d'accès à la base de données. Les clients PBL disposeraient également d'une chaîne JDBC unique et d'un pool de connexions unique. Ils disposeraient donc également d'un ensemble unique de connexions qui ne sont pas utilisées par les services financiers, commerciaux ou marketing.
La clause
WHEREdans une requête SQL n'entraîne pas de nouveaux pools de connexions. La clauseWHEREn'a aucun impact sur la chaîne de connexion JDBC. Par conséquent, aucun pool de connexions 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 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.