Beachten Sie, dass Sie sich gerade die Looker-Dokumentation ansehen. Die Looker Studio-Dokumentation finden Sie unter https://support.google.com/looker-studio.

Diese Seite wurde von der Cloud Translation API übersetzt.

Looker mit Ihrer Datenbank verbinden

Nachdem Sie Ihre Datenbank gesichert und konfiguriert haben, können Sie sie mit Looker verbinden.

Wählen Sie im Bereich Datenbank des Admin-Bereichs die Option Verbindungen aus. Klicken Sie auf der Seite Connections (Verbindungen) auf die Schaltfläche Add Connection (Verbindung hinzufügen). In Looker wird die Seite Verbindungseinstellungen angezeigt.

Weitere Informationen zum Anwenden von Nutzerattributen auf Verbindungseinstellungen finden Sie im Abschnitt Verbindungen der Dokumentationsseite Nutzerattribute.

Auf dieser Seite werden allgemeine Felder beschrieben, die Looker auf der Seite Verbindungseinstellungen anzeigt. Welche Felder auf der Seite Verbindungseinstellungen genau angezeigt werden, hängt von Ihrer Dialekteinstellung ab.

Klicken Sie hier, um die Links zu den Dialekt-spezifischen Anweisungen in der Looker-Dokumentation anzuzeigen.

Nachdem Sie die Einstellungen für die Datenbankverbindung eingegeben haben, können Sie die Schaltfläche Test (Testen) auf der Seite Connection Settings (Verbindungseinstellungen) auswählen, um die Verbindung zu testen und sicherzustellen, dass sie richtig konfiguriert ist. Klicken Sie auf Test, um zu prüfen, ob die Verbindung erfolgreich ist. Informationen zur Fehlerbehebung finden Sie auf der Dokumentationsseite Datenbankverbindung testen. Wenn in Looker Verbindung möglich angezeigt wird, klicken Sie auf Verbinden, um die Verbindung herzustellen. Ihre Datenbankverbindung wird dann der Liste auf der Looker-Admin-Seite Verbindungen hinzugefügt.

Allgemeine Einstellungen

Name

Der gewünschte Name für die Verbindung. Sie benötigen diesen Datenbankverbindungsnamen, um den Parameter connection Ihres LookML-Modells zu verwenden. Der Name der Datenbankverbindung dient auch dazu, die Verbindung auf der Seite Verbindungen Admin von Looker zu identifizieren. Verwenden Sie für diese Einstellung nicht die Namen von Ordnern. Dieser Wert muss mit nichts in Ihrer Datenbank übereinstimmen. Name ist ein Label, das diese Verbindung innerhalb der Looker-Benutzeroberfläche identifiziert.

Verbindungszugehörigkeit

Wählen Sie aus, ob die Verbindung mit allen Projekten oder nur mit einem Projekt verwendet werden kann.

Verwenden Sie diese Option zusammen mit den folgenden Berechtigungen, um die Verbindungsverwaltung und die Modellkonfiguration zu delegieren:

Dialekt

Der SQL-Dialekt, der Ihrer Verbindung entspricht. Es ist wichtig, den richtigen Wert auszuwählen, damit Ihnen die richtigen Verbindungsoptionen angezeigt werden und Looker Ihren LookML-Code richtig in SQL übersetzen kann.

ID des Abrechnungsprojekts

Nur bei Google BigQuery-Verbindungen ist die ID des Abrechnungsprojekts die Google Cloud-Projekt-ID.

Host

Der Hostname Ihrer Datenbank, mit dem Looker eine Verbindung zu Ihrem Datenbankhost herstellen soll.

Wenn Sie mit einem Looker-Analysten zusammengearbeitet haben, um einen SSH-Tunnel zu Ihrer Datenbank zu konfigurieren, geben Sie im Feld Host "localhost" ein.

Port

Der Port Ihrer Datenbank, mit dem Looker eine Verbindung zu Ihrem Datenbankhost herstellen soll.

Wenn Sie mit einem Looker-Analysten zusammengearbeitet haben, um einen SSH-Tunnel zu Ihrer Datenbank zu konfigurieren, geben Sie im Feld Port die Portnummer ein, die zu Ihrer Datenbank weiterleitet und vom Looker-Analysten bereitgestellt worden sein sollte.

Datenbank

Der Name der Datenbank auf Ihrem Host. Angenommen, Sie haben den Hostnamen my-instance.us-east-1.redshift.amazonaws.com, auf der sich eine Datenbank namens sales_info befindet. In dieses Feld würden Sie sales_info eingeben. Wenn Sie mehrere Datenbanken auf demselben Host haben, müssen Sie möglicherweise mehrere Verbindungen erstellen, um sie verwenden zu können (mit Ausnahme von MySQL, bei dem das Wort Datenbank etwas anderes bedeutet als in den meisten SQL-Dialekten).

Schema

Das von Looker verwendete Standardschema, wenn kein Schema angegeben ist. Dies gilt bei der Verwendung von SQL Runner, bei der LookML-Projektgenerierung und bei der Abfrage von Tabellen.

Authentifizierung

Wählen Sie für Google BigQuery-, Snowflake-, Trino- und Databricks-Verbindungen den Authentifizierungstyp aus, den Looker für den Zugriff auf die Datenbank verwenden soll:

Bei Google BigQuery-Verbindungen können Sie OAuth oder ein Dienstkonto für Looker zur Authentifizierung bei Ihrer Datenbank konfigurieren.
Bei Snowflake-, Trino- und Databricks-Verbindungen haben Sie die Möglichkeit, OAuth oder ein Datenbankkonto für Looker zur Authentifizierung bei Ihrer Datenbank zu konfigurieren.

Wenn Sie OAuth verwenden, müssen sich Ihre Nutzer in Ihrer Datenbank anmelden, um Abfragen von Looker auszuführen. Weitere Informationen zum Konfigurieren von OAuth für eine Verbindung zu Looker finden Sie in den Verbindungsverfahren für Google BigQuery, Snowflake, Trino oder Databricks.

Nutzername

Der Benutzername eines Benutzerkontos in Ihrer Datenbank, mit dem Looker eine Verbindung zu Ihrer Datenbank herstellen kann.

Passwort

Das Passwort eines Benutzerkontos in Ihrer Datenbank, mit dem Looker eine Verbindung zu Ihrer Datenbank herstellen kann.

Optionale Einstellungen

SSH-Server

Die Option SSH-Server ist nur verfügbar, wenn die Instanz in einer Kubernetes-Infrastruktur bereitgestellt wird und wenn die Möglichkeit zum Hinzufügen von Konfigurationsinformationen zum SSH-Server zu Ihrer Looker-Instanz aktiviert wurde. Wenn diese Option in Ihrer Looker-Instanz nicht aktiviert ist und Sie sie aktivieren möchten, wenden Sie sich an einen Google Cloud-Vertriebsexperten oder stellen Sie eine Supportanfrage.

Der SSH-Server wählt automatisch den Localhost-Port für Sie aus. Es ist nicht möglich, den Localhost-Port anzugeben. Wenn Sie eine SSH-Verbindung erstellen müssen, bei der ein Localhost-Port angegeben werden muss, öffnen Sie eine Supportanfrage.

Wenn Sie eine Verbindung zur Datenbank über einen SSH-Tunnel herstellen möchten, aktivieren Sie die Ein/Aus-Schaltfläche und wählen Sie in der Drop-down-Liste eine SSH-Serverkonfiguration aus.

Lokaler Port

Standardmäßig wählt Looker automatisch einen verfügbaren lokalen Port für den SSH-Tunnel aus. Wenn Sie einen lokalen Port manuell auswählen möchten, wählen Sie Manuelle Eingabe aus und geben Sie eine Portnummer in das Feld Benutzerdefinierter lokaler Port ein. Achten Sie darauf, dass der lokale Port auf Ihrer Instanz verfügbar ist.

Persistente abgeleitete Tabellen (PDTs)

PDTs aktivieren

Aktivieren Sie die Ein/Aus-Schaltfläche PDTs aktivieren, um persistente abgeleitete Tabellen zu aktivieren. Wenn PDTs aktiviert sind, werden im Fenster Verbindung zusätzliche PDT-Felder und der Abschnitt PDT-Überschreibungen angezeigt. Die Ein/Aus-Schaltfläche PDTs aktivieren wird in Looker nur angezeigt, wenn der Datenbankdialekt die Verwendung von PDTs unterstützt.

Beachten Sie Folgendes zu PDTs:

PDTs werden für Snowflake-Verbindungen, die OAuth verwenden, nicht unterstützt.
Durch das Deaktivieren von PDTs für eine Verbindung werden die mit Ihren PDTs verknüpften Datengruppen nicht deaktiviert. Auch wenn Sie PDTs deaktivieren, führen vorhandene Datengruppen weiterhin ihre sql_trigger-Abfragen für die Datenbank aus. Wenn Sie verhindern möchten, dass eine Datengruppe ihre sql_trigger-Abfrage für Ihre Datenbank ausführt, müssen Sie den Parameter datagroup aus Ihrem LookML-Projekt löschen oder auskommentieren. Alternativ können Sie die Einstellung Datengruppe und PDT-Wartungszeitplan für die Verbindung aktualisieren, sodass Looker PDTs und Datengruppen sehr selten oder nie prüft.
Bei Snowflake-Verbindungen setzt Looker den Wert für den Parameter AUTOCOMMIT auf TRUE (Standardwert von Snowflake). AUTOCOMMIT ist für SQL-Befehle erforderlich, die Looker zur Verwaltung des PDT-Registrierungssystems ausführt.

Temp Database

Obwohl diese Bezeichnung Temp Database heißt, geben Sie je nach SQL-Dialekt entweder den Datenbanknamen oder den Schemanamen ein, den Looker zum Erstellen von persistenten abgeleiteten Tabellen verwenden soll. Diese Datenbank oder dieses Schema sollten Sie im Voraus mit den entsprechenden Schreibberechtigungen konfigurieren. Wählen Sie auf der Dokumentationsseite Datenbankkonfigurationsanleitung Ihren Datenbankdialekt aus, um die entsprechende Anleitung aufzurufen.

Jede Verbindung muss eine eigene Temp Database oder ein eigenes Schema haben. Sie können nicht von mehreren Verbindungen gemeinsam genutzt werden.

Max. Anzahl der Verbindungen für PDT-Generator

Mit der Einstellung Maximale Anzahl von PDT-Builder-Verbindungen können Sie angeben, wie viele Tabellen-Builds der Looker-Regenerator für Ihre Datenbankverbindung gleichzeitig initiieren kann. Die Einstellung Maximale Anzahl von PDT-Builder-Verbindungen gilt nur für die Tabellentypen, für die der Looker-Regenerator Neuerstellungen initiiert:

Trigger-persistente Tabellen (persistente abgeleitete Tabellen und zusammengefasste Tabellen, die die Persistenzstrategie datagroup_trigger oder sql_trigger_value verwenden
Persistente Tabellen, die die persist_for-Strategie verwenden, aber nur, wenn die Tabelle persist_for Teil einer Kaskade abgeleiteter Tabellen ist, von der sie von einer Tabelle abhängig ist, die die Persistenzstrategie datagroup_trigger oder sql_trigger_value verwendet. In diesem Fall erstellt der Looker-Regenerator eine persist_for-Tabelle neu, da die Tabelle benötigt wird, um eine andere Tabelle in der Kaskade neu zu erstellen. Andernfalls initiiert der Regenerator keine Builds für persist_for-Tabellen.

Die Einstellung Max number of PDT Builder connections (Maximale Anzahl von PDT-Builder-Verbindungen) ist standardmäßig auf 1 festgelegt, kann aber auch auf bis zu 10 festgelegt werden. Der Wert darf jedoch nicht höher sein als der Wert im Feld Max. Anzahl von Verbindungen pro Knoten oder per-user-query-limit, der in den Startoptionen von Looker festgelegt wurde.

Wählen Sie diesen Wert mit Bedacht. Ist der Wert zu hoch, überlastet dies möglicherweise Ihre Datenbank. Wenn der Wert niedrig ist, können PDTs oder aggregierte Tabellen mit langer Ausführungszeit die Erstellung anderer persistenter Tabellen verzögern oder andere Abfragen für die Verbindung verlangsamen. Datenbanken, die Mehrmandantenfähigkeit unterstützen, wie BigQuery, Snowflake und Redshift, sind bei der Verarbeitung paralleler Abfrage-Builds möglicherweise leistungsfähiger.

Wenn Sie die Einstellung Max number of PDT Builder connections (Maximale Anzahl von PDT-Builder-Verbindungen) erhöhen möchten, empfiehlt es sich, sie in Schritten von 1 zu erhöhen. Sollte ein unerwartetes Verhalten auftreten, setzen Sie den Wert auf den Standardwert 1 zurück. Andernfalls können Sie, wenn die Abfrageleistung nicht beeinträchtigt wird, sie schrittweise um 1 erhöhen und die Leistung jedes Intervall überprüfen, bevor Sie die Einstellung weiter erhöhen.

Beachten Sie bei der Einstellung Max number of PDT Builder connections (Maximale Anzahl von PDT-Builder-Verbindungen) Folgendes:

Die Einstellung Maximale Anzahl von PDT-Builder-Verbindungen gilt nur für Verbindungen, die für die Neuerstellung von Tabellen erforderlich sind, nicht für die für Triggerprüfungen benötigten Verbindungen. Eine Triggerprüfung ist eine Abfrage, die prüft, ob die Persistenzstrategie der Tabelle ausgelöst wird. Da diese Auslöserprüfungsabfragen immer nacheinander ausgeführt werden, gilt die Einstellung Max. Anzahl von PDT-Builder-Verbindungen nicht.
In einer geclusterten Looker-Instanz wird der Regenerator nur auf dem Hauptknoten ausgeführt. Die Einstellung Max. Anzahl von PDT-Builder-Verbindungen gilt nur für den Hauptknoten und legt daher das Limit für den gesamten Cluster fest.
Die Einstellung Maximale Anzahl von PDT-Builder-Verbindungen gilt nicht für die folgenden Tabellentypen. Diese Tabellentypen werden nacheinander erstellt:
- Tabellen, die über den Parameter persist_for beibehalten werden (es sei denn, die Tabelle ist von Tabellen mit der Strategie datagroup_trigger oder sql_trigger_value abhängig).
- Tabellen im Entwicklungsmodus
- Tabellen, die mit der Option Abgeleitete Tabellen neu erstellen und ausführen neu erstellt wurden.
- Tabellen, bei denen eine Abhängigkeit von einer anderen in einer Abhängigkeits-Kaskade abhängt. Eine Tabelle kann nicht gleichzeitig mit einer Tabelle erstellt werden, von der sie abhängt. Wenn table_B beispielsweise von table_A abhängt, muss table_A die Neuerstellung abschließen, bevor table_B mit dem Neuerstellen beginnen kann.

Wartungszeitplan für Datengruppe und PAT

Der Looker-Regenerator prüft Datengruppen und persistente Tabellen (sowohl aggregierte Tabellen als auch persistente abgeleitete Tabellen), die auf sql_trigger_value basieren. Auf der Grundlage dieser Prüfungen erstellt der Looker-Regenerator die persistenten Tabellen neu oder löscht sie aus dem Scratch-Schema Ihrer Datenbank.

Mit dem Wert Datagroup and PDT Maintenance Schedule (Datengruppe und PDT-Wartungszeitplan) wird das Intervall cron für den Looker-Regenerator festgelegt. Der Looker-Regenerator initiiert einen Regenerator-Zyklus, um Datengruppen und persistente Tabellen im Intervall cron zu prüfen. Wenn ein Looker-Regenerator-Zyklus im nächsten cron-Intervall noch läuft, schließt der Looker-Regenerator den Regenerator-Zyklus ab und wartet dann bis zum nachfolgenden Intervall cron, um mit dem nächsten Regenerator-Zyklus zu beginnen.

Für die Einstellung Datengruppe und PDT-Wartungszeitplan kann ein cron-Ausdruck verwendet werden. Der Standardwert ist */5 * * * *. Das bedeutet, dass der Looker-Regenerator-Zyklus nach Abschluss des vorherigen Regenerator-Zyklus einen Zyklus im fünfminütigen Intervall initiiert. Wenn der vorherige Regenerator-Zyklus noch nicht abgeschlossen wurde, startet der Looker-Regenerator im nächsten 5-Minuten-Intervall nach Abschluss des Zyklus.

Der Standardwert von fünf Minuten ist auch das häufigste Intervall, das für den Datengruppe- und PDT-Wartungszeitplan unterstützt wird. Looker erzwingt kein maximales Intervall für den Datengruppe- und PDT-Wartungszeitplan. Das bedeutet, dass Sie das Intervall zwischen den Looker-Regenerator-Zyklen so lange verlängern können, wie dies mit einem cron-Ausdruck angegeben werden kann. Beachten Sie, dass sich längere Regenerator-Zyklen von Looker negativ auf die Aktualität der Daten im Cache und in persistenten Tabellen auswirken können.

Nachdem der Looker-Regenerator alle Prüfungen und PDT-Neuerstellungen in einem Zyklus abgeschlossen hat, wartet er auf das nächste cron-Intervall, um den nächsten Zyklus zu starten. Bei PDT-Builds mit langer Ausführungszeit können zwischen den Zyklen des Looker-Regenerators lange Zeit liegen. Die Dauer der Neuerstellung Ihrer Tabellen kann von anderen Faktoren beeinflusst werden, wie auf der Seite Abgeleitete Tabellen in Looker im Abschnitt Wichtige Überlegungen zum Implementieren persistenter Tabellen beschrieben.

Wenn Ihre Datenbank nicht rund um die Uhr verfügbar ist, sollten Sie die Überprüfung auf Zeiten beschränken, zu denen die Datenbank aktiv ist. Hier sind einige zusätzliche cron-Ausdrücke:

`cron`-Ausdruck	Definition
`/5 8-17 * MON-FRI`	Datengruppen und PDTs während der Geschäftszeiten alle 5 Minuten prüfen, montags bis freitags
`/5 8-17 * *`	Datengruppen und PDTs während der Geschäftszeiten alle 5 Minuten prüfen, täglich
`0 8-17 * * MON-FRI`	Datengruppen und PDTs während der Geschäftszeiten stündlich prüfen, montags bis freitags
`1 3 * * *`	Datengruppen und PDTs täglich um 3:01 prüfen

Beachten Sie beim Erstellen eines cron-Ausdrucks Folgendes:

Looker verwendet parse-cron v0.1.3, das ? in cron-Ausdrücken nicht unterstützt.
Der Ausdruck cron verwendet die Zeitzone der Looker-Anwendung, um zu bestimmen, wann Prüfungen durchgeführt werden.
Wenn keine PDTs erstellt werden, setzen Sie den Cron-String auf den Standardwert */5 * * * * zurück.

Im Folgenden finden Sie einige Ressourcen, die Sie beim Erstellen von cron-Strings unterstützen:

https://crontab.guru – Hilfe beim Bearbeiten und Testen von cron-Strings.
http://www.crontab-generator.org: Wählen Sie Zeiteinstellungen aus. Der Generator erstellt dann den entsprechenden cron-String.

Fehlgeschlagene PAT-Builds wiederholen

Mit der Ein/Aus-Schaltfläche Fehlgeschlagene PDT-Builds wiederholen wird konfiguriert, wie der Looker-Regenerator versucht, ausgelöste Tabellen neu zu erstellen, die im vorherigen Regenerator-Zyklus fehlgeschlagen sind. Der Looker-Regenerator ist der Prozess, der trigger-persistente Tabellen (PDTs und aggregierte Tabellen) gemäß dem Intervall neu erstellt, das in der Verbindungseinstellung Datengruppe und PDT-Wartungszeitplan konfiguriert wurde. Wenn die Ein/Aus-Schaltfläche Fehlgeschlagene PDT-Builds wiederholen aktiviert ist, versucht der Looker-Regenerator, eine PDT neu zu erstellen, die im vorherigen Regenerator-Zyklus fehlgeschlagen ist, auch wenn die Triggerbedingung der PDT nicht erfüllt ist. Wenn diese Einstellung deaktiviert ist, versucht der Looker-Regenerator nur dann, eine zuvor fehlgeschlagene PDT neu zu erstellen, wenn die Auslösebedingung der PDT erfüllt ist. Fehlgeschlagene PDT-Builds wiederholen ist standardmäßig deaktiviert.

Weitere Informationen zum Looker-Regenerator finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.

API-Steuerung für PAT

Mit der Ein/Aus-Schaltfläche PDT API Control können Sie festlegen, ob die API-Aufrufe start_pdt_build, check_pdt_build und stop_pdt_build für diese Verbindung verwendet werden können. Wenn die Ein/Aus-Schaltfläche PDT API Control deaktiviert ist, schlagen diese API-Aufrufe fehl, wenn sie bei dieser Verbindung auf PDTs verweisen. Die Ein/Aus-Schaltfläche PDT API Control ist standardmäßig deaktiviert.

PAT-Überschreibungen

Wenn Ihre Datenbank persistente abgeleitete Tabellen unterstützt und Sie in den Verbindungseinstellungen die Ein/Aus-Schaltfläche PDTs aktivieren aktiviert haben, wird in Looker der Abschnitt PDT-Überschreibungen angezeigt. Im Bereich PDT-Überschreibungen können Sie separate JDBC-Parameter (Host, Port, Datenbank, Nutzername, Passwort, Schema, zusätzliche Parameter und After Connect-Anweisungen) eingeben, die für PDT-Prozesse spezifisch sind. Dies kann aus verschiedenen Gründen hilfreich sein:

Wenn Sie einen separaten Datenbanknutzer für PDT-Prozesse erstellen, können Sie PDTs in Ihrem Looker-Projekt auch dann verwenden, wenn Sie Ihren Datenbank-Anmeldedaten Nutzerattribute zuweisen oder OAuth für die Datenbankverbindung verwenden.
PDT-Prozesse können durch einen eigenen Datenbankbenutzer authentifiziert werden, der über eine höhere Priorität verfügt. Somit kann die Datenbank PDT-Jobs eine höhere Priorität einräumen als weniger wichtigen Benutzerabfragen.
Der Schreibzugriff kann für die Standard-Looker-Datenbankverbindung entzogen und nur einem bestimmten Benutzer zugewiesen werden, den PDT-Prozesse zur Authentifizierung verwenden. Dies ist für die meisten Unternehmen eine bessere Sicherheitsstrategie.
Für Datenbanken wie Snowflake können PDT-Prozesse an leistungsfähigere Hardware geleitet werden, die nicht für den Rest der Looker-Nutzer freigegeben ist. Auf diese Weise können PDTs schnell erstellt werden, ohne dass die Notwendigkeit entsteht, jederzeit kostenintensive Hardware vorzuhalten.

Die folgende Konfiguration zeigt beispielsweise eine Verbindung, in die Felder für Benutzernamen und Passwort auf Benutzerattribute festgelegt sind. Somit kann jeder Benutzer mit seinen eigenen Anmeldedaten auf die Datenbank zugreifen. Im Bereich PDT Overrides (PDT-Überschreibungen) wird ein separater Nutzer (pdt_user) mit eigenem Passwort erstellt. Das pdt_user-Konto wird für alle PDT-Prozesse mit entsprechenden Zugriffsebenen verwendet, um PDTs zu erstellen und zu aktualisieren.

Bereich „PD-Overrides“ auf der Seite „Verbindungseinstellungen“.

Zeitzone

Zeitzone der Datenbank

Die Zeitzone, in der Ihre Datenbank zeitbasierte Informationen speichert. Looker muss diese kennen, damit Zeitwerte für Benutzer konvertiert werden können. Dies erleichtert das Verständnis und die Nutzung zeitbasierter Daten. Weitere Informationen finden Sie auf der Dokumentationsseite Zeitzoneneinstellungen verwenden.

Zeitzone der Abfrage

Die Option Zeitzone für Suchanfrage ist nur sichtbar, wenn die Option Nutzerspezifische Zeitzonen deaktiviert ist.

Wenn Nutzerspezifische Zeitzonen deaktiviert sind, ist die Zeitzone für Abfragen die Zeitzone, die Ihren Nutzern angezeigt wird, wenn sie zeitbasierte Daten abfragen, und die Zeitzone, in die Looker zeitbasierte Daten aus der Datenbankzeitzone umwandelt.

Weitere Informationen finden Sie auf der Dokumentationsseite Zeitzoneneinstellungen verwenden.

Zusätzliche Einstellungen

Zusätzliche JDBC-Parameter

Bei Bedarf können Sie hier zusätzliche JDBC-Parameter (Java Database Connectivity) für Ihre Abfragen angeben.

Um in einem JDBC-Parameter auf ein Nutzerattribut zu verweisen, verwenden Sie die Syntax für Liquid-Vorlagen: _user_attributes['name_of_attribute']. Beispiel:

my_jdbc_param={{ _user_attributes['name_of_attribute'] }}

Max. Verbindungen pro Knoten

Hier können Sie die Anzahl der Verbindungen festlegen, die Looker höchstens mit Ihrer Datenbank herstellen kann. Dabei legen Sie überwiegend die Anzahl der Abfragen fest, die Looker gleichzeitig für Ihre Datenbank ausführen kann. Looker reserviert zudem bis zu drei Verbindungen für das Beenden von Abfragen. Ist der Verbindungspool sehr klein, reserviert Looker weniger Verbindungen.

Wählen Sie diesen Wert mit Bedacht. Ist der Wert zu hoch, überlastet dies möglicherweise Ihre Datenbank. Ist er zu niedrig, müssen sich Abfragen eine kleine Anzahl an Verbindungen teilen. Das bedeutet, dass viele Abfragen Benutzern langsam erscheinen, da die Abfragen warten müssen, bis andere, frühere Abfragen beantwortet wurden.

Der Standardwert (der je nach verwendetem SQL-Dialekt unterschiedlich ausfällt) ist in der Regel ein guter Ausgangspunkt. Die meisten Datenbanken verfügen außerdem über ihre eigenen Einstellungen für die von ihnen maximal akzeptierte Anzahl Verbindungen. Wenn Ihre Datenbankkonfiguration Verbindungen einschränkt, achten Sie darauf, dass der Wert für Max. Verbindungen pro Knoten dem Limit Ihrer Datenbank entspricht oder darunter liegt.

Connection Pool Timeout

Wenn Ihre Nutzer mehr Verbindungen anfordern, als die Einstellung Max. Anzahl der Verbindungen pro Knoten zulässt, werden die Anfragen erst ausgeführt, wenn die anderen Verbindungen abgeschlossen sind. Hier wird die maximale Wartezeit für eine Anforderung festgelegt. Die Standardeinstellung beträgt 120 Sekunden.

Diesen Wert sollten Sie mit Bedacht wählen. Wenn er zu niedrig ist, werden Suchanfragen für Nutzer möglicherweise abgebrochen, da die Zeit nicht ausreicht, um die Abfragen anderer Nutzer abzuschließen. Ist er zu hoch, kann es zu einer großen Anzahl von Abfragen kommen, wodurch Nutzer sehr lange warten müssen. Der Standardwert ist in der Regel ein guter Ausgangspunkt.

SSL

Wählen Sie aus, ob Ihre Daten bei der Übergabe zwischen Looker und Ihrer Datenbank mit SSL-Verschlüsselung geschützt werden sollen. SSL ist nur eine Option, mit der Sie Ihre Daten schützen können. Andere sichere Optionen werden auf der Dokumentationsseite Sicheren Datenbankzugriff aktivieren beschrieben.

SSL überprüfen

Geben Sie an, ob die Verifizierung des von der Verbindung verwendeten SSL-Zertifikats angefordert werden soll. Wenn eine Bestätigung erforderlich ist, muss die SSL-Zertifizierungsstelle, die das SSL-Zertifikat signiert hat, aus der Liste der vertrauenswürdigen Quellen des Clients stammen. Handelt es sich bei der Zertifizierungsstelle um keine vertrauenswürdige Quelle, wird die Datenbankverbindung nicht hergestellt.

Wenn dieses Kästchen nicht ausgewählt ist, wird die SSL-Verschlüsselung weiterhin für die Verbindung verwendet, es ist jedoch keine Bestätigung der SSL-Verbindung erforderlich. Daher kann eine Verbindung hergestellt werden, wenn sich die Zertifizierungsstelle nicht auf der Liste der vertrauenswürdigen Quellen des Clients befindet.

SQL-Runner-Precache

In SQL-Runner werden alle Tabelleninformationen unmittelbar nach der Auswahl einer Verbindung und eines Schemas vorab geladen. Dadurch kann SQL Runner Tabellenspalten schnell anzeigen, sobald Sie auf einen Tabellennamen klicken. Für Verbindungen und Schemata mit vielen Tabellen oder sehr großen Tabellen soll SQL-Runner jedoch möglicherweise nicht alle Informationen vorab laden.

Wenn SQL Runner Tabelleninformationen nur dann lädt, wenn eine Tabelle ausgewählt ist, können Sie die Option SQL Runner Precache deaktivieren, um das Vorabladen von SQL Runner für die Verbindung zu deaktivieren.

Fetch Information Schema For SQL Writing

Bei einigen SQL-Schreibfunktionen wie Aggregatfunktionen verwendet Looker das Informationsschema Ihrer Datenbank, um die SQL-Schreibvorgänge zu optimieren. Wenn das Informationsschema nicht im Cache gespeichert ist, muss Looker gelegentlich das Schreiben von SQL in die Datenbank blockieren, um das Informationsschema abrufen zu können. Bei Dialekten, die das Hadoop Distributed File System (HDFS) verwenden, kann das Abrufen des Informationsschemas lange genug dauern, um die Leistung Ihrer Looker-Abfragen erheblich zu beeinträchtigen. Wenn Sie wissen, dass Ihr Informationsschema langsam ist, können Sie die Option Fetch Information Schema For SQL Writing (Informationsschema für SQL-Schreibvorgänge abrufen) für Ihre Verbindung deaktivieren. Wenn Sie diese Funktion deaktivieren, werden einige der Looker SQL-Optimierungen für bestimmte Funktionen verhindert. Daher sollten Sie die Option Fetch Information Schema For SQL Writing (Informationenschema für SQL-Schreibvorgänge abrufen) aktivieren, sofern Sie nicht wissen, dass das Informationsschema Ihrer Verbindung besonders langsam ist.

Kostenschätzung

Die Ein/Aus-Schaltfläche Kostenschätzung gilt nur für die folgenden Datenbankverbindungen:

Mit der Ein/Aus-Schaltfläche Kostenschätzung werden die folgenden Features für die Verbindung aktiviert:

Weitere Informationen finden Sie auf der Dokumentationsseite Daten in Looker erkunden.

Database Connection Pooling

Bei Dialekten, die Datenbankverbindungs-Pooling unterstützen, ermöglicht diese Funktion Looker, Verbindungspools über den JDBC-Treiber zu verwenden. Datenbankverbindungs-Pooling ermöglicht eine schnellere Abfrageleistung. Eine neue Abfrage muss keine neue Datenbankverbindung erstellen, sondern kann stattdessen eine vorhandene Verbindung aus dem Verbindungspool verwenden. 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. Weitere Informationen finden Sie auf der Dokumentationsseite Datenbankverbindungs-Pooling.

Ihre Verbindungseinstellungen testen

Sie können Ihre Verbindungseinstellungen auf der Looker-Benutzeroberfläche an verschiedenen Stellen testen:

Wählen Sie unten auf der Seite Connections Settings (Verbindungseinstellungen) die Schaltfläche Test (Testen) aus.
Wählen Sie die Schaltfläche Testen aus, die neben dem Eintrag der Verbindung auf der Admin-Seite Verbindungen angezeigt wird, wie auf der Dokumentationsseite Verbindungen beschrieben.

Nachdem Sie die Verbindungseinstellungen eingegeben haben, klicken Sie auf Test, um zu prüfen, ob die Informationen korrekt sind und die Datenbank eine Verbindung herstellen kann.

Wenn Ihre Verbindung einen oder mehrere Tests nicht besteht, haben Sie folgende Möglichkeiten zur Fehlerbehebung:

Führen Sie einige der Schritte zur Fehlerbehebung auf der Dokumentationsseite Datenbankverbindung testen aus.
Wenn Sie die Mongo-Version 3.6 oder älter mit Atlas ausführen und ein Kommunikationslinkfehler auftritt, finden Sie weitere Informationen in der Dokumentation auf der Dokumentationsseite für Mongo-Connector.
Meldungen zu erfolgreichen Verbindungen für das Temp-Schema und PDTs erhalten Sie nur, wenn Sie diese Funktion bei der Konfiguration Ihrer Looker-Datenbank aktiviert haben. Eine Anleitung dazu finden Sie auf der Dokumentationsseite Datenbankkonfigurationsanleitung.

Sollten weiterhin Probleme auftreten, wenden Sie sich an den Support von Looker.

Als Nutzer testen

Wenn Sie einen oder mehrere Verbindungsparameterwerte für ein Nutzerattribut festgelegt haben, wird die Option Als Nutzer testen angezeigt. Wählen Sie einen Nutzer aus und klicken Sie auf Test, um zu prüfen, ob sich die Datenbank verbinden und Abfragen als dieser Nutzer ausführen kann.

Weitere Informationen

Nachdem Sie die Datenbank mit Looker verbunden haben, können Sie die Anmeldeoptionen für Ihre Nutzer konfigurieren.