Verbindungs-Pooling ermöglicht die Verwendung vorkonfigurierter Verbindungspools für PostgreSQL- und Snowflake-Datenbankdialekte.
Wenn Ihr Dialekt dies unterstützt, kann Looker durch Datenbankverbindungs-Pooling über den JDBC-Treiber Verbindungspools verwenden. Datenbankverbindungs-Pooling ermöglicht eine schnellere Abfrageleistung. Bei einer neuen Abfrage muss keine neue Datenbankverbindung erstellt werden, sondern kann stattdessen eine vorhandene Verbindung aus dem Verbindungspool verwenden. Die Verbindungs-Pooling-Funktion stellt sicher, dass eine Verbindung nach der Ausführung einer Abfrage bereinigt wird und wieder zur Wiederverwendung nach dem Ende der Abfrageausführung verfügbar ist.
Sie können 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 Database Connection 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 eindeutige Verbindungspools, wenn sie eine Verbindung zur Datenbank herstellen.
Die maximale Anzahl von Verbindungen, die zu Verbindungspools auf allen Datenbankknoten hergestellt werden können, ist 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.
Eindeutige JDBC-Verbindungsstrings erstellen eindeutige Verbindungspools. Eindeutige Datenbank-Nutzernamen oder Datenbankgruppennamen, die die rollenbasierte Zugriffssteuerung auf die Datenbank vorgeben, erstellen beispielsweise eindeutige JDBC-Verbindungsstrings, die dann eindeutige Verbindungspools bilden. Zum Beispiel kann eine Finanzgruppe in einem Unternehmen eine Datenbankrolle haben, die ihnen Zugriff auf alle Tabellen in der Datenbank gewährt, aber das Vertriebs- und Marketingteam kann eine Datenbankrolle haben, die ihnen 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 mit eingebetteten Analysen bestehen, die eigene Zugriffsrechte auf die Datenbank haben. Die Kunden, die die integrierte Analyse nutzen, hätten auch einen eindeutigen JDBC-String und einen eindeutigen Verbindungspool, sodass sie auch über einen eindeutigen Satz an Verbindungen verfügen, 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, sodass kein neuer Verbindungspool erstellt wird. Eindeutige Zugriffsfilter ändern beispielsweise die SQL-WHERE-Klausel in einer Abfrage und nicht den JDBC-Verbindungsstring, sodass durch eindeutige Zugriffsfilter keine neuen Verbindungspools erstellt werden.Wenn mehrere Verbindungspools erstellt werden, wird die maximale Anzahl von Verbindungen in mehrere Pools fragmentiert, wobei jeder Pool eine Teilmenge der verfügbaren Verbindungen enthält. Das liegt daran, dass die Gesamtzahl der Verbindungen den Wert für die maximale Anzahl von Verbindungen nicht überschreiten darf.
Dialektunterstützung für Datenbankverbindungs-Pooling
Die Möglichkeit, Datenbankverbindungs-Pooling zu verwenden, hängt vom Datenbankdialekt ab, den Ihre Looker-Verbindung verwendet. In der neuesten Version von Looker unterstützen die folgenden Dialekte das Pooling von Datenbankverbindungen:
| Dialekt | Unterstützt? |
|---|---|
| Lawine Actian | Nein |
| Amazon Athena | Nein |
| Amazon Aurora MySQL | Nein |
| Amazon Redshift | Nein |
| Apache Druid | Nein |
| Apache Druid 0.13 und höher | Nein |
| Apache Druid 0.18 und höher | Nein |
| Apache Hive 2.3+ | Nein |
| Apache Hive 3.1.2+ | Nein |
| Apache Spark 3 und höher | Nein |
| ClickHouse | Nein |
| Cloudera Impala 3.1+ | Nein |
| Cloudera Impala 3.1+ mit nativem Treiber | Nein |
| Cloudera Impala mit nativem Fahrer | Nein |
| DataVirtuality | Nein |
| Databricks | Nein |
| Denodo 7 | Nein |
| Denodo 8 | Nein |
| Dremio | Nein |
| Dremio 11+ | Nein |
| Exasol | Nein |
| Firebolt | Nein |
| Legacy-SQL von Google BigQuery | Nein |
| Google BigQuery-Standard-SQL | Nein |
| Google Cloud PostgreSQL | Ja |
| Google Cloud SQL | Nein |
| Google Spanner | Nein |
| Grünpflaumen | 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 oder höher | Nein |
| Oracle | Nein |
| Oracle ADWC | Nein |
| PostgreSQL 9.5 oder höher | Ja |
| PostgreSQL vor Version 9.5 | Ja |
| PrestoDB | Nein |
| PrestoSQL | Nein |
| SAP HANA 2+ | Nein |
| SingleStore | Nein |
| SingleStore 7+ | Nein |
| Snowflake | Ja |
| Teradata | Nein |
| Trino | Nein |
| Vektor | Nein |
| Vertica | Nein |