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 pooling de connexions de base de données permet à Looker d'utiliser des pools de connexions via le pilote JDBC. Le regroupement des connexions de base de données permet d'accélérer les performances des requêtes. Il n'est pas nécessaire de créer une nouvelle connexion à la base de données, mais vous pouvez 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 pooling de connexions à l'aide de l'option Pooling des connexions à la 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 connexions si leurs valeurs d'attribut utilisateur sont identiques. Les utilisateurs ayant des valeurs uniques ou différentes dans leur ensemble d'attributs utilisateur utiliseront des pools de connexions uniques lors de la connexion à la base de données.

  • Le nombre maximal de connexions pouvant être établies vers les pools de connexions de tous les nœuds de la base de données est limité par la valeur du champ Nombre maximal de connexions par nœud sur 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'à l'exécution des requêtes précédentes.

  • Des chaînes de connexion JDBC uniques créent des pools de connexions uniques. Par exemple, des noms d'utilisateur de base de données uniques ou des noms de groupes de bases de données qui dictent le contrôle des accès basé sur les rôles à la base de données créeront des chaînes de connexion JDBC uniques, qui créeront ensuite des pools de connexions uniques. Par exemple, un groupe financier dans une entreprise peut avoir 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 des ventes et du marketing peut avoir un rôle de base de données qui ne lui accorde l'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 d'analyses intégrées qui disposent de leurs propres droits d'accès à la base de données. Les clients de l'analytique embarquée auraient également une chaîne JDBC unique et un pool de connexions unique, de sorte qu'ils disposent également d'un ensemble unique de connexions qui ne sont pas utilisées par les groupes des finances, des ventes et du 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 est dû au fait que le nombre total de connexions ne peut pas dépasser la valeur du nombre maximal de connexions.

Prise en charge du dialecte pour le regroupement des connexions à la base de données

La possibilité d'utiliser le regroupement de connexions à la base de données dépend du dialecte de base de données utilisé par 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 Compatible ?
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+ avec pilote natif
Non
Cloudera Impala avec Native Driver
Non
DataVirtuality
Non
Databricks
Non
Denodo 7
Non
Denodo 8
Non
Dremio
Non
Dremio 11 et versions ultérieures
Non
Exasol
Non
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
Base de données Microsoft Azure SQL
Non
Microsoft Azure Synapse Analytics
Non
Microsoft SQL Server 2008 et versions ultérieures
Non
Microsoft SQL Server 2012 et versions ultérieures
Non
Microsoft SQL Server 2016
Non
Microsoft SQL Server 2017 et versions ultérieures
Non
MongoBI
Non
MySQL
Non
MySQL 8.0.12 et versions ultérieures
Non
Oracle
Non
Oracle ADWC
Non
PostgreSQL 9.5 et versions ultérieures
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