Mit dem Verbindungs-Pooling können vorkonfigurierte Verbindungspools für PostgreSQL und Snowflake Datenbankdialekte verwendet werden.
Wenn Ihr Dialekt dies unterstützt, kann Looker mit dem Datenbankverbindungs-Pooling Verbindungspools über den JDBC-Treiber verwenden. Das Datenbankverbindungs-Pooling ermöglicht eine schnellere Abfrageleistung. Für eine neue Abfrage muss keine neue Datenbankverbindung erstellt werden, sondern es kann eine vorhandene Verbindung aus dem Verbindungspool verwendet werden. Durch das Verbindungs-Pooling wird sichergestellt, dass eine Verbindung nach der Ausführung einer Abfrage bereinigt wird und nach dem Ende der Abfrageausführung wiederverwendet werden kann.
Sie können das Verbindungs-Pooling mit der Option Datenbankverbindungs-Pooling aktivieren, wenn Sie in Looker eine Datenbankverbindung 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.
Hier sind einige Punkte, die Sie bei der Verwendung von Verbindungspools beachten sollten:
Mehrere Nutzer verwenden einen Verbindungspool gemeinsam, 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 auf allen Datenbankknoten hergestellt werden können, wird durch den Wert im Feld Maximale 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 übersteigt, werden die Abfragen in Looker in die Warteschlange gestellt, bis die vorherigen Abfragen ausgeführt wurden.
Eindeutige JDBC-Verbindungs-Strings erstellen eindeutige Verbindungspools. Beispielsweise erstellen eindeutige Datenbanknutzernamen oder Datenbankgruppennamen, die die rollenbasierte Zugriffssteuerung für die Datenbank festlegen, eindeutige JDBC-Verbindungs-Strings, die dann eindeutige Verbindungspools erstellen. So hat beispielsweise eine Finanzgruppe in einem Unternehmen möglicherweise eine Datenbankrolle, die ihr Zugriff auf alle Tabellen in der Datenbank gewährt. Das Vertriebs- und Marketingteam hat jedoch möglicherweise eine Datenbankrolle, die ihm nur Zugriff auf eine Teilmenge der Datenbanktabellen gewährt. In diesem Fall hat jede Gruppe einen eindeutigen JDBC-Verbindungs-String und einen eindeutigen Verbindungspool. Eine dritte Gruppe könnte eine Reihe von Kunden mit eingebetteten Analysen sein, die eigene 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- oder 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-Verbindungs-String, sodass kein neuer Verbindungspool erstellt wird. Beispielsweise ändern eindeutige Zugriffsfilter die SQL-WHEREKlausel in einer Abfrage, nicht den JDBC-Verbindungs-String. Daher werden durch eindeutige Zugriffsfilter keine neuen Verbindungspools erstellt.Wenn mehrere Verbindungspools erstellt werden, wird die maximale Anzahl von Verbindungen auf mehrere Pools aufgeteilt, 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 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 | |
| Amazon Athena | |
| Amazon Aurora MySQL | |
| Amazon Redshift | |
| Amazon Redshift 2.1+ | |
| Amazon Redshift Serverless 2.1+ | |
| Apache Druid | |
| Apache Druid 0.13.x - 0.17.x | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| Cloudera Impala 3.1+ | |
| Cloudera Impala 3.1+ with Native Driver | |
| Cloudera Impala with Native Driver | |
| DataVirtuality | |
| Databricks | |
| Denodo 7 | |
| Denodo 8 & 9 | |
| Dremio | |
| Dremio 11+ | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud AlloyDB for PostgreSQL | |
| Google Cloud PostgreSQL | |
| Google Cloud SQL | |
| Google Spanner | |
| Greenplum | |
| HyperSQL | |
| IBM Netezza | |
| MariaDB | |
| Microsoft Azure PostgreSQL | |
| Microsoft Azure SQL Database | |
| Microsoft Azure Synapse Analytics | |
| Microsoft SQL Server 2008+ | |
| Microsoft SQL Server 2012+ | |
| Microsoft SQL Server 2016 | |
| Microsoft SQL Server 2017+ | |
| MongoBI | |
| MySQL | |
| MySQL 8.0.12+ | |
| Oracle | |
| Oracle ADWC | |
| PostgreSQL 9.5+ | |
| PostgreSQL pre-9.5 | |
| PrestoDB | |
| PrestoSQL | |
| SAP HANA | |
| SAP HANA 2+ | |
| SingleStore | |
| SingleStore 7+ | |
| Snowflake | |
| Teradata | |
| Trino | |
| Vector | |
| Vertica |