Regroupement de connexions de base de données

Le pool 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 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 pool 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 utilise le pooling de connexions sur votre connexion si toutes les conditions suivantes sont remplies:

Voici quelques points à prendre en compte lorsque vous utilisez des pools de connexion:

  • 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 de 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.

  • Les chaînes de connexion JDBC uniques créent des pools de connexion 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 dans une requête SQL ne crée pas de nouveaux pools de connexions. La clause WHERE n'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 SQL WHERE d'une requête, et non la chaîne de connexion JDBC. Ils ne créent donc pas de pools de connexion.

  • 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 regroupement 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 sont compatibles avec le regroupement des connexions de base de données:

Dialecte Compatibilité
Actian Avalanche
Non
Amazon Athena
Non
Amazon Aurora MySQL
Non
Amazon Redshift
Non
Apache Druid
Non
Apache Druid 0.13 ou version ultérieure
Non
Apache Druid 0.18 ou version ultérieure
Non
Apache Hive 2.3 ou version ultérieure
Non
Apache Hive 3.1.2 ou version ultérieure
Non
Apache Spark 3 ou version ultérieure
Non
ClickHouse
Non
Cloudera Impala 3.1 ou version ultérieure
Non
Cloudera Impala 3.1 ou version ultérieure avec pilote natif
Non
Cloudera Impala avec pilote natif
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
Google BigQuery Legacy SQL
Non
SQL standard de 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 ou version ultérieure
Non
Microsoft SQL Server 2012 ou version ultérieure
Non
Microsoft SQL Server 2016
Non
Microsoft SQL Server 2017 ou version ultérieure
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 ou version ultérieure
Non
SingleStore
Non
SingleStore 7+
Non
Snowflake
Oui
Teradata
Non
Trino
Non
Vecteur
Non
Vertica
Non