Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Le pooling 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 à la base de données permet d'améliorer les performances des requêtes. En effet, une nouvelle requête n'a pas besoin de créer une connexion à la base de données, mais peut utiliser une connexion existante à partir du pool de connexions. La fonctionnalité de mise en pool des connexions garantit qu'une connexion est nettoyée après l'exécution d'une requête et qu'elle est disponible pour être réutilisée une fois l'exécution de la requête terminée.
L'option Regroupement de connexions à la base 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 points à prendre en compte lorsque vous utilisez des pools de connexions :
Plusieurs utilisateurs partagent un pool de connexions 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 aux pools de connexions sur tous les nœuds de 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'à ce que les requêtes précédentes soient exécutées.
Des chaînes de connexion JDBC uniques créent des pools de connexion uniques. Par exemple, des 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 à la base de données créeront des chaînes de connexion JDBC uniques, qui créeront 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 donne accès à 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 lui donne accès à un sous-ensemble des tables de la base de données. Dans ce cas, chaque groupe disposerait d'une chaîne de connexion JDBC et d'un pool de connexions 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 connexions uniques. Ils ont donc aussi un ensemble unique de connexions qui ne sont pas utilisées par les groupes Finance, et Ventes et marketing.
La clause WHERE dans une requête SQL ne provoque 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 WHERE SQL d'une requête, et non la chaîne de connexion JDBC. Ils ne créeront donc pas de nouveaux pools de connexions.
Lorsque plusieurs pools de connexions sont créés, le nombre maximal de connexions est fragmenté en plusieurs pools, chacun contenant un sous-ensemble des 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 à la 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 de connexions à la base de données :
Dialecte
Compatibilité
Actian Avalanche
Non
Amazon Athena
Non
Amazon Aurora MySQL
Non
Amazon Redshift
Non
Amazon Redshift 2.1+
Non
Amazon Redshift Serverless 2.1+
Non
Apache Druid
Non
Apache Druid 0.13+
Non
Apache Druid 0.18+
Non
Apache Hive 2.3+
Non
Apache Hive 3.1.2+
Non
Apache Spark 3+
Non
ClickHouse
Non
Cloudera Impala 3.1+
Non
Cloudera Impala 3.1+ with Native Driver
Non
Cloudera Impala with Native Driver
Non
DataVirtuality
Non
Databricks
Non
Denodo 7
Non
Denodo 8 & 9
Non
Dremio
Non
Dremio 11+
Non
Exasol
Non
Firebolt
Non
Google BigQuery Legacy SQL
Non
Google BigQuery Standard SQL
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+
Non
Microsoft SQL Server 2012+
Non
Microsoft SQL Server 2016
Non
Microsoft SQL Server 2017+
Non
MongoBI
Non
MySQL
Non
MySQL 8.0.12+
Non
Oracle
Non
Oracle ADWC
Non
PostgreSQL 9.5+
Oui
PostgreSQL pre-9.5
Oui
PrestoDB
Non
PrestoSQL
Non
SAP HANA
Non
SAP HANA 2+
Non
SingleStore
Non
SingleStore 7+
Non
Snowflake
Oui
Teradata
Non
Trino
Non
Vector
Non
Vertica
Non
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[],[],null,["# Database connection pooling\n\nConnection pooling enables the use of preconfigured connection pools on [PostgreSQL](/looker/docs/db-config-postgresql) and [Snowflake](/looker/docs/db-config-snowflake) database dialects.\n\n[If your dialect supports it](#dialect_support_for_database_connection_pooling), database connection pooling enables Looker to use pools of connections through the JDBC driver. Database connection pooling enables faster query performance; a new query does not need to create a new database connection but can instead use an existing connection from the connection pool. The connection pooling capability ensures that a connection is cleaned up after a query execution and is available for reuse after the query execution ends.\n\nYou can enable connection pooling using the [**Database Connection Pooling**](/looker/docs/admin-panel-general-labs#database_connection_pooling) option when you [create](/looker/docs/connecting-to-your-db) or [edit](/looker/docs/admin-panel-database-connections#editing_connections) a database connection in Looker.\n| **Note:** Database connection pooling was previously a Looker [Labs](/looker/docs/admin-panel-general-labs) feature. When **Database Connection Pooling** moved out of Labs, Looker automatically applied the **Database Connection Pooling** Labs setting to the **Database Connection Pooling** connection setting for any database connections on your instance that support connection pooling.\n\nLooker will use connection pooling on your connection if all of the following are true:\n\n- You are using one of the [dialects that support database connection pooling](#dialect_support_for_database_connection_pooling).\n- The **Database Connection Pooling** option is enabled on the Looker connection.\n- You have configured connection pools on your database.\n\nHere are some things to consider when you're using connection pools:\n\n- Multiple users share a connection pool if their user attribute values are identical. Users who have unique or differing values in their set of user attributes will use unique connection pools when connecting to the database.\n\n- The maximum number of connections that can be made to connection pools across all database nodes is limited by the value in the [**Max connections per node**](/looker/docs/connecting-to-your-db#max_connections) field in the database's **Connection** page.\n\n- If the number of concurrent queries being issued to a connection pool exceeds the maximum number of connections, queries are queued in Looker until prior queries are executed.\n\n- Unique JDBC connection strings create unique connection pools. For example, unique database usernames or database group names that dictate role-based access control to the database will create unique JDBC connection strings, which then create unique connection pools. For example, a finance group in a company may have a database role that grants them access to all tables in the database, but the sales and marketing team may have a database role that grants them access to only a subset of the database tables. In this case, each group would have a unique JDBC connection string and a unique connection pool. A third group might be a set of [embedded analytics](/looker/docs/single-sign-on-embedding) customers who have their own access rights to the database. The embedded analytics customers would also have a unique JDBC string and a unique connection pool, so they would also have a unique set of connections that are not in use by the finance or sales and marketing groups.\n\n- The `WHERE` clause in a SQL query does not cause new connection pools. The `WHERE` clause has no impact on the JDBC connection string, so a new connection pool is not created. For example, unique [access filters](/looker/docs/reference/param-explore-access-filter) modify the SQL `WHERE` clause in a query, not the JDBC connection string, so unique access filters won't create new connection pools.\n\n- When multiple connection pools are created, the maximum number of connections is fragmented into multiple pools, with each pool containing a subset of available connections. This occurs because the total number of connections cannot exceed the maximum connections value.\n\nDialect support for database connection pooling\n-----------------------------------------------\n\nThe ability to use database connection pooling depends on the database dialect your Looker connection is using. In the latest release of Looker, the following dialects support database connection pooling:"]]
