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:
- Vous utilisez l'un des dialectes compatibles avec le pooling de connexions de base de données.
- L'option Pooling des connexions aux bases de données est activée sur la connexion Looker.
- Vous avez configuré des pools de connexions sur votre base de données.
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 clauseWHERE
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 SQLWHERE
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 |