Mit dem Verbindungspool können Sie vorkonfigurierte Verbindungspools in PostgreSQL- und Snowflake-Datenbankdialekten verwenden.
Wenn Ihr Dialekt dies unterstützt, kann Looker mithilfe des Datenbankverbindungs-Poolings 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. Durch die Verbindungspool-Funktion wird sichergestellt, dass eine Verbindung nach der Ausführung einer Abfrage bereinigt wird und nach Abschluss 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 das Verbindungs-Pooling für Ihre Verbindung, wenn alle 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 gleichzeitigen Abfragen, die an einen Verbindungspool gesendet werden, die maximale Anzahl von Verbindungen überschreitet, werden die Abfragen in Looker in die Warteschlange gestellt, bis die vorherigen Abfragen ausgeführt wurden.
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 nur auf einen Teil der Datenbanktabellen zugreifen kann. In diesem Fall hat jede Gruppe einen eindeutigen JDBC-Verbindungsstring und einen eindeutigen Verbindungspool. Eine dritte Gruppe könnte aus Kunden mit eingebetteten Analysen bestehen, die eigene Zugriffsrechte auf 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 führt nicht zu 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, nicht den JDBC-Verbindungsstring. Daher werden durch eindeutige Zugriffsfilter keine neuen Verbindungspools erstellt.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.
Dialektunterstützung für das Datenbankverbindungs-Pooling
Die Möglichkeit, das 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 Datenbankverbindungs-Pooling:
| Dialekt | Unterstützt? |
|---|---|
| Actian Avalanche | Nein |
| Amazon Athena | Nein |
| Amazon Aurora MySQL | Nein |
| Amazon Redshift | Nein |
| Apache Druid | Nein |
| Apache Druid 0.13 oder höher | 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 und höher 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 Analytics | 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+ | Nein |
| Snowflake | Ja |
| Teradata | Nein |
| Trino | Nein |
| Vektor | Nein |
| Vertica | Nein |