Mit dem Verbindungspool können Sie vorkonfigurierte Verbindungspools in PostgreSQL- und Snowflake-Datenbankdialekten verwenden.
Wenn Ihr Dialekt dies unterstützt, kann Looker durch Datenbankverbindungs-Pooling Verbindungspools über den JDBC-Treiber verwenden. Das Pooling von Datenbankverbindungen ermöglicht eine schnellere Abfrageleistung. Für eine neue Abfrage muss keine neue Datenbankverbindung erstellt werden, sondern es kann stattdessen eine vorhandene Verbindung aus dem Verbindungspool verwendet werden. Die Funktion „Verbindungs-Pooling“ stellt sicher, dass eine Verbindung nach der Ausführung einer Abfrage bereinigt wird und nach der Ausführung der Abfrage wiederverwendet werden kann.
Sie können das Verbindungs-Pooling mit der Option Datenbankverbindungs-Pooling aktivieren, wenn Sie eine Datenbankverbindung in Looker erstellen oder bearbeiten.
Looker verwendet Verbindungs-Pooling für Ihre Verbindung, wenn alle der folgenden Bedingungen erfüllt sind:
- Sie verwenden einen der Dialekte, die das Datenbankverbindungs-Pooling unterstützen.
- Die Option Datenbankverbindungs-Pooling ist für die Looker-Verbindung aktiviert.
- Sie haben Verbindungspools in Ihrer Datenbank konfiguriert.
Bei der Verwendung von Verbindungspools sollten Sie Folgendes beachten:
Mehrere Nutzer teilen sich einen Verbindungspool, wenn ihre Nutzerattributwerte identisch sind. Nutzer mit eindeutigen oder unterschiedlichen Werten in ihren Nutzerattributen verwenden beim Herstellen einer Verbindung zur Datenbank eindeutige Verbindungspools.
Die maximale Anzahl von Verbindungen, die zu Verbindungspools über alle Datenbankknoten hinweg hergestellt werden können, wird durch den Wert im Feld Max. Verbindungen pro Knoten auf der Seite Verbindung der Datenbank begrenzt.
Wenn die Anzahl der gleichzeitig an einen Verbindungspool gesendeten Abfragen die maximale Anzahl von Verbindungen überschreitet, werden Abfragen in Looker in die Warteschlange gestellt, bis vorherige Abfragen ausgeführt werden.
Mit eindeutigen JDBC-Verbindungsstrings werden eindeutige Verbindungspools erstellt. Beispielsweise werden durch eindeutige Datenbanknutzernamen oder Datenbankgruppennamen, die die rollenbasierte Zugriffssteuerung für die Datenbank festlegen, eindeutige JDBC-Verbindungsstrings erstellt, die dann eindeutige Verbindungspools erstellen. So kann eine Finanzgruppe in einem Unternehmen beispielsweise eine Datenbankrolle haben, die ihr Zugriff auf alle Tabellen in der Datenbank gewährt, während das Vertriebs- und Marketingteam eine Datenbankrolle hat, die ihm nur Zugriff auf einen Teil der Datenbanktabellen gewährt. In diesem Fall hätte jede Gruppe einen eindeutigen JDBC-Verbindungsstring und einen eindeutigen Verbindungspool. Eine dritte Gruppe könnte aus einer Reihe von Kunden bestehen, die eingebettete Analysen nutzen und die ihre eigenen Zugriffsrechte für die Datenbank haben. Die Kunden mit eingebetteten Analysen haben auch einen eindeutigen JDBC-String und einen eindeutigen Verbindungspool. Sie haben also auch eine eindeutige Reihe von Verbindungen, die nicht von den Finanz-, Vertriebs- und Marketinggruppen verwendet werden.
Die
WHERE-Klausel in einer SQL-Abfrage verursacht keine neuen Verbindungspools. DieWHERE-Klausel hat keine Auswirkungen auf den JDBC-Verbindungsstring. Es wird also kein neuer Verbindungspool erstellt. Beispielsweise ändern eindeutige Zugriffsfilter die SQL-WHERE-Klausel in einer Abfrage und nicht den JDBC-Verbindungsstring, sodass keine neuen Verbindungspools erstellt werden.Wenn mehrere Verbindungspools erstellt werden, wird die maximale Anzahl der Verbindungen in mehrere Pools aufgeteilt. Jeder Pool enthält einen Teil der verfügbaren Verbindungen. Das liegt daran, dass die Gesamtzahl der Verbindungen den Wert für die maximale Anzahl von Verbindungen nicht überschreiten darf.
Unterstützung von Dialekten für das Pooling von Datenbankverbindungen
Ob Sie Datenbankverbindungs-Pooling verwenden können, hängt vom Datenbankdialekt ab, den Ihre Looker-Verbindung verwendet. In der neuesten Version von Looker unterstützen die folgenden Dialekte das Datenbankverbindungs-Pooling:
| Dialekt | Unterstützt? |
|---|---|
| Actian Avalanche | Nein |
| Amazon Athena | Nein |
| Amazon Aurora MySQL | Nein |
| Amazon Redshift | Nein |
| Druid | Nein |
| Apache Druid 0.13+ | Nein |
| Apache Druid 0.18 und höher | Nein |
| Apache Hive 2.3 und höher | Nein |
| Apache Hive 3.1.2 und höher | Nein |
| Apache Spark 3 und höher | Nein |
| ClickHouse | Nein |
| Cloudera Impala 3.1 und höher | Nein |
| Cloudera Impala 3.1+ mit nativem Treiber | Nein |
| Cloudera Impala mit nativem Treiber | Nein |
| DataVirtuality | Nein |
| Databricks | Nein |
| Denodo 7 | Nein |
| Denodo 8 | Nein |
| Dremio | Nein |
| Dremio 11 und höher | Nein |
| Exasol | Nein |
| Firebolt | Nein |
| Google BigQuery Legacy SQL | Nein |
| Google BigQuery-Standard-SQL | Nein |
| Google Cloud PostgreSQL | Ja |
| Google Cloud SQL | Nein |
| Google Spanner | Nein |
| Greenplum | Ja |
| HyperSQL | Nein |
| IBM Netezza | Nein |
| MariaDB | Nein |
| Microsoft Azure PostgreSQL | Ja |
| Microsoft Azure SQL-Datenbank | Nein |
| Microsoft Azure Synapse-Analyse | Nein |
| Microsoft SQL Server 2008 und höher | Nein |
| Microsoft SQL Server 2012 und höher | Nein |
| Microsoft SQL Server 2016 | Nein |
| Microsoft SQL Server 2017 und höher | Nein |
| MongoBI | Nein |
| MySQL | Nein |
| MySQL 8.0.12 und höher | Nein |
| Oracle | Nein |
| Oracle ADWC | Nein |
| PostgreSQL 9.5 und höher | Ja |
| PostgreSQL vor Version 9.5 | Ja |
| PrestoDB | Nein |
| PrestoSQL | Nein |
| SAP HANA 2 und höher | Nein |
| SingleStore | Nein |
| SingleStore 7 und höher | Nein |
| Snowflake | Ja |
| Teradata | Nein |
| Trino | Nein |
| Vektor | Nein |
| Vertica | Nein |