Pooling des connexions de base de données

Le pooling de connexions permet d'utiliser des pools de connexions préconfigurés dans les dialectes de base de données PostgreSQL et Snowflake.

Si votre dialecte le permet, 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 améliore les performances des requêtes. Une nouvelle requête n'a pas besoin de créer une nouvelle connexion de 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 l'exécution d'une requête et qu'elle peut être réutilisée une fois l'exécution de la requête terminée.

Vous pouvez activer le pool de connexions à l'aide de l'option Pool 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 pooling de connexions sur votre connexion si toutes les conditions suivantes sont remplies:

Voici quelques éléments à prendre en compte lorsque vous utilisez des pools de connexions:

  • Plusieurs utilisateurs partagent un pool de connexion si les valeurs de leurs attributs utilisateur sont identiques. Les utilisateurs dont l'ensemble d'attributs utilisateur comporte des valeurs uniques ou différentes utiliseront des pools de connexion uniques lorsqu'ils se connecteront à la base de données.

  • Le nombre maximal de connexions pouvant être établies avec les pools de connexions sur tous les nœuds de base de données est limité par la valeur du champ Max Connections per node (Nombre maximal de connexions par nœud) sur la page Connection (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.

  • Des chaînes de connexion JDBC uniques créent des pools de connexions uniques. Par exemple, les noms d'utilisateur ou de groupe de base de données uniques qui dictent le contrôle des accès basé sur les rôles de 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 d'une entreprise peut disposer d'un rôle de base de données qui lui permet d'accéder à toutes les tables de la base de données, tandis que l'équipe commerciale et marketing peut disposer d'un rôle de base de données qui ne lui permet d'accéder qu'à un sous-ensemble des tables de la base de données. Dans ce cas, chaque groupe dispose d'une chaîne de connexion JDBC et d'un pool de connexion uniques. 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 et d'un pool de connexion uniques. Ils ont donc également un ensemble unique de connexions qui ne sont pas utilisées par les groupes Finance, Ventes et Marketing.

  • La clause WHERE d'une requête SQL ne génère pas de nouveaux pools de connexions. La clause WHERE n'a aucun impact sur la chaîne de connexion JDBC. Aucun pool de connexions n'est donc créé. Par exemple, les filtres d'accès uniques modifient la clause SQL WHERE d'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. Cela se produit parce que le nombre total de connexions ne peut pas dépasser la valeur maximale de connexions.

Prise en charge des dialectes pour le pool de connexions de base de données

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 à la base de données:

Dialecte Compatibilité
Avalanche d'Actian
Non
Amazon Athena
Non
Amazon Aurora MySQL
Non
Amazon Redshift
Non
Apache Druid
Non
Apache Druid 0.13 et versions ultérieures
Non
Apache Druid 0.18 et versions ultérieures
Non
Apache Hive 2.3 et versions ultérieures
Non
Apache Hive 3.1.2 et versions ultérieures
Non
Apache Spark 3 et versions ultérieures
Non
ClickHouse
Non
Cloudera Impala 3.1+
Non
Cloudera Impala 3.1 ou version ultérieure avec pilote natif
Non
Cloudera Impala avec Native Driver
Non
DataVirtuality
Non
Databricks
Non
Denodo 7
Non
Denodo 8
Non
Dremio
Non
Dremio 11 ou version ultérieure
Non
Exasol
Non
Flèche de feu
Non
Ancien SQL de Google BigQuery
Non
SQL standard Google BigQuery
Non
Google Cloud PostgreSQL
Oui
Google Cloud SQL
Non
Google Spanner
Non
Greenplum
Oui
HyperSQL
Non
IBM Netezza
Non
MariaDB
Non
Microsoft Azure PostgreSQL
Oui
Microsoft Azure SQL Database
Non
Microsoft Azure Synapse Analytics
Non
Microsoft SQL Server 2008 et versions ultérieures
Non
Microsoft SQL Server 2012 ou version ultérieure
Non
Microsoft SQL Server 2016
Non
Microsoft SQL Server 2017 et versions ultérieures
Non
MongoBI
Non
MySQL
Non
MySQL 8.0.12 ou version ultérieure
Non
Oracle
Non
Oracle ADWC
Non
PostgreSQL 9.5 ou version ultérieure
Oui
PostgreSQL version antérieure à 9.5
Oui
PrestoDB
Non
PrestoSQL
Non
SAP HANA 2 et versions ultérieures
Non
SingleStore
Non
SingleStore 7 et versions ultérieures
Non
Snowflake
Oui
Teradata
Non
Trino
Non
Vecteur
Non
Vertica
Non