Abfragen im Cache speichern und PDTs mit Datengruppen neu erstellen

Looker entlastet Ihre Datenbank und verbessert die Leistung, indem im Cache gespeicherte Ergebnisse früherer Abfragen verwendet werden, wenn dies gemäß Ihrer Caching-Richtlinie möglich und zulässig ist. Darüber hinaus können Sie komplexe Abfragen als persistente abgeleitete Tabellen (PDT) erstellen, in denen ihre Ergebnisse für spätere Abfragen gespeichert werden.

Datengruppen sind sehr nützlich, um den ETL-Zeitplan (Extraktion, Transformation und Ladevorgang) Ihrer Datenbank mit der Caching-Richtlinie von Looker und dem Zeitplan zur Neuerstellung der PDT zu koordinieren. Sie können eine Datengruppe verwenden, um den Neuerstellungstrigger für PDTs anzugeben, je nachdem, wann neue Daten in Ihre Datenbank aufgenommen werden. In derselben Datengruppe können Sie ein maximales Cache-Alter für Suchanfragen festlegen, die als ausfallsicher gelten, wenn die Neuerstellung der PDT nicht ausgelöst wird. Auf diese Weise wird der Fehlermodus für eine Datengruppe darin besteht, die Datenbank abzufragen, anstatt veraltete Daten aus dem Looker-Cache bereitzustellen.

Alternativ können Sie eine Datengruppe verwenden, um den PDT-Rebuilding-Trigger vom maximalen Cache-Alter zu trennen. Das kann nützlich sein, wenn du eine Funktion „Entdecken“ nutzt, die auf Daten basiert, die sich sehr häufig aktualisieren, und die mit einer PDT verknüpft ist, die seltener neu erstellt wird. In diesem Fall soll der Abfrage-Cache häufiger zurückgesetzt werden, als die PDT neu erstellt wurde.

Weitere Informationen zum Caching von Abfragen finden Sie auf dieser Dokumentationsseite im Abschnitt Verwendung von im Cache gespeicherten Abfragen.

Datengruppe definieren

Eine Datengruppe wird mit dem Parameter datagroup entweder in einer Modelldatei oder in einer eigenen LookML-Datei definiert. Sie können mehrere Datengruppen definieren, wenn Sie verschiedene Caching- und PDT-Neuerstellungsrichtlinien für verschiedene explorative Datenanalysen und/oder PDTs in Ihrem Projekt verwenden möchten.

Der Parameter datagroup kann die folgenden Unterparameter haben:

  • label: Gibt ein optionales Label für die Datengruppe an.
  • description: gibt eine optionale Beschreibung für die Datengruppe an, die zum Zweck und Zweck der Datengruppe verwendet werden kann.
  • max_cache_age: Gibt einen String an, der einen Zeitraum definiert. Wenn das Alter des Cache einer Abfrage den Zeitraum überschreitet, wird der Cache von Looker ungültig. Wenn die Abfrage das nächste Mal ausgeführt wird, sendet Looker sie an die Datenbank, um neue Ergebnisse zu erhalten.
  • interval_trigger: Gibt einen Zeitplan zum Auslösen der Datengruppe an, z. B. "24 hours".

Weitere Informationen zu diesen Parametern finden Sie auf der Dokumentationsseite zu datagroup.

Eine Datengruppe muss mindestens den Parameter max_cache_age, sql_trigger oder interval_trigger haben.

Eine Datengruppe kann nicht sowohl einen sql_trigger- als auch einen interval_trigger-Parameter haben. Wenn Sie eine Datengruppe mit beiden Parametern definieren, verwendet die Datengruppe den Wert interval_trigger und ignoriert den Wert sql_trigger, da der Parameter sql_trigger erfordert, dass Looker Datenbankressourcen beim Abfragen der Datenbank verwendet.

Hier ein Beispiel für eine Datengruppe, für die eine sql_trigger eingerichtet ist, um die PDT täglich neu zu erstellen. Außerdem wird der max_cache_age so festgelegt, dass der Abfrage-Cache alle zwei Stunden gelöscht wird, falls explorative Datenanalysen zu PDTs mit anderen Daten führen, die häufiger als einmal täglich aktualisiert werden.

datagroup: customers_datagroup {
  sql_trigger: SELECT DATE(NOW());;
  max_cache_age: "2 hours"
}

Nachdem Sie die Datengruppe definiert haben, können Sie sie explorativen Datenanalysen und PDTs zuweisen:

Mit einer Datengruppe einen Trigger für die Neuerstellung von PDTs erstellen

Um einen PDT-Neuerstellungstrigger mithilfe von Datengruppen zu definieren, erstellen Sie einen datagroup-Parameter mit dem Unterparameter sql_trigger oder interval_trigger. Weisen Sie die Daten dann einzelnen PDTs mithilfe des Unterparameters datagroup_trigger in der PDT-Definition derived_table zu. Wenn du datagroup_trigger für deine PDT verwendest, musst du keine andere Persistenzstrategie für die abgeleitete Tabelle angeben. Wenn Sie mehrere Persistenzstrategien für eine PDT angeben, erhalten Sie eine Warnung in der Looker-IDE und nur die datagroup_trigger wird verwendet.

Hier ist ein Beispiel für eine PDT-Definition, in der die Datengruppe customers_datagroup verwendet wird. Diese Definition fügt auch mehrere Indexe für customer_id und first_order_date hinzu. Weitere Informationen zum Definieren von PDTs finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.

view: customer_order_facts {
  derived_table: {
    sql: ... ;;
    datagroup_trigger: customers_datagroup
    indexes: ["customer_id", "first_order_date"]
  }
}

Wenn Sie kaskadierende PDTs und PDTs verwenden, die von anderen PDTs abhängig sind, achten Sie darauf, keine inkompatiblen Caching-Richtlinien für Datengruppen anzugeben.

Für Verbindungen mit Nutzerattributen zum Angeben der Verbindungsparameter müssen Sie eine separate Verbindung über die PDT-Überschreibungsfelder erstellen, wenn Sie eine der folgenden Aktionen ausführen möchten:
• PDTs in Ihrem Modell verwenden
• PDT-Neuerstellungstrigger verwenden
Auch ohne die PDT-Überschreibungen können Sie eine Datengruppe mit max_cache_age verwenden, um die Caching-Richtlinie für Explores zu definieren.

Weitere Informationen zur Funktionsweise von Datengruppen mit PDT finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.

Mit einer Datengruppe das Zurücksetzen des Abfragecaches für Explores festlegen

Wenn eine Datengruppe aktiviert wird, erstellt der Looker-Regenerator die PDTs, die diese Datengruppe als Persistenzstrategie verwenden, neu. Sobald die PDTs der Datengruppe neu erstellt wurden, leert Looker den Cache für „Erkunden“ mit den neu erstellten PDTs. Wenn Sie einen Zeitplan zum Zurücksetzen des Abfragecaches für die Datengruppe anpassen möchten, fügen Sie der Anzeigengruppe-Definition den Parameter max_cache_age hinzu. Mit dem Parameter max_cache_age können Sie den Abfragecache nach einem bestimmten Zeitplan löschen. Außerdem wird das automatische Zurücksetzen des Abfragecaches ausgelöst, das Looker ausführt, wenn die PDTs der Datengruppe neu erstellt werden.

Wenn Sie eine Abfrage-Caching-Richtlinie mit Datengruppen definieren möchten, erstellen Sie einen datagroup-Parameter mit dem Unterparameter max_cache_age.

Verwenden Sie den Parameter persist_with, um eine Datengruppe anzugeben, die zum Zurücksetzen des Abfragecaches auf „Entdecken“ verwendet werden soll:

Die folgenden Beispiele zeigen eine Datengruppe namens orders_datagroup, die in einer Modelldatei definiert ist. Die Datengruppe hat einen sql_trigger-Parameter, der angibt, dass die Abfrage select max(id) from my_tablename verwendet wird, um zu ermitteln, wann ein ETL-Ereignis stattgefunden hat. Auch wenn dieser ETL eine Zeit lang nicht auftritt, gibt das max_cache_age der Datengruppe an, dass die im Cache gespeicherten Daten maximal 24 Stunden verwendet werden.

Der Parameter persist_with des Modells verweist auf die Caching-Richtlinie orders_datagroup. Das ist die Standard-Caching-Richtlinie für alle Explore-Modelle im Modell. Wir möchten jedoch nicht die Standard-Caching-Richtlinie des Modells für customer_facts und customer_background Explores verwenden, damit wir den Parameter persist_with hinzufügen können, um für diese beiden Explores eine andere Caching-Richtlinie anzugeben. orders und orders_facts „Erkunden“ haben keinen persist_with-Parameter. Daher wird die Standard-Caching-Richtlinie des Modells verwendet: orders_datagroup.

datagroup: orders_datagroup {
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  max_cache_age: "24 hours"
}

datagroup: customers_datagroup {
  sql_trigger: SELECT max(id) FROM my_other_tablename ;;
}

persist_with: orders_datagroup

explore: orders { ... }

explore: order_facts { ... }

explore: customer_facts {
  persist_with: customers_datagroup
  ...
}

explore: customer_background {
  persist_with: customers_datagroup
  ...
}

Wenn sowohl persist_with als auch persist_for angegeben sind, erhalten Sie eine Validierungswarnung und die persist_with wird verwendet.

Datengruppe verwenden, um geplante Auslieferungen auszulösen

Mit Datengruppen lässt sich auch die Auslieferung eines Dashboards, eines alten Dashboards oder eines Looks auslösen. Mit dieser Option sendet Looker Ihre Daten, wenn die Datengruppe fertiggestellt ist, sodass der geplante Inhalt auf dem neuesten Stand ist.

Admin für Datengruppen verwenden

Wenn Sie die Rolle „Looker-Administrator“ haben, können Sie im Steuerfeld Admin auf der Seite Gruppen die vorhandenen Datengruppen aufrufen. Sie sehen die Verbindung, das Modell und den aktuellen Status jeder Datengruppe sowie – sofern in LookML angegeben – ein Label und eine Beschreibung für jede Datengruppe. Sie können auch den Cache für eine Datengruppe zurücksetzen, die Datengruppe auslösen oder die LookML der Datengruppe aufrufen.

So verwendet Looker im Cache gespeicherte Abfragen

Bei Abfragen funktioniert der Caching-Mechanismus in Looker so:

  1. Sobald ein Nutzer eine bestimmte Abfrage ausführt, wird das Ergebnis dieser Abfrage im Cache gespeichert. Die Cache-Ergebnisse werden in einer verschlüsselten Datei auf der Looker-Instanz gespeichert.

  2. Wenn eine neue Abfrage geschrieben wird, wird im Cache geprüft, ob die genaue Abfrage zuvor ausgeführt wurde. Alle Felder, Filter und Parameter müssen identisch sein, einschließlich der Einstellungen für Zeilenlimits. Wenn die Abfrage nicht gefunden wird, führt Looker die Abfrage für die Datenbank aus, um aktuelle Datenbankergebnisse zu erhalten, die dann im Cache gespeichert werden.

    Kontextkommentare wirken sich nicht auf das Caching aus. Looker fügt am Anfang jeder SQL-Abfrage einen eindeutigen Kommentar hinzu. Solange die SQL-Abfrage selbst mit einer vorherigen Abfrage identisch ist (ohne die Kontextkommentare), verwendet Looker im Cache gespeicherte Ergebnisse.

  3. Wenn die Abfrage im Cache gefunden wird, prüft Looker die im Modell definierte Caching-Richtlinie, um festzustellen, ob der Cache noch gültig ist. Standardmäßig hebt Looker im Cache gespeicherte Ergebnisse nach einer Stunde auf. Sie können einen persist_for-Parameter (auf Modellebene oder Erkundungsebene) oder einen leistungsfähigeren datagroup-Parameter verwenden, um die Caching-Richtlinie anzugeben, mit der die Umstände bestimmt werden, unter denen die im Cache gespeicherten Ergebnisse ungültig werden und ignoriert werden sollen. Ein Administrator kann die im Cache gespeicherten Ergebnisse für eine Datengruppe auch entwerten.

    • Wenn der Cache noch gültig ist, werden diese Ergebnisse verwendet.
    • Wenn der Cache nicht mehr gültig ist, führt Looker die Abfrage für die Datenbank aus, um aktuelle Abfrageergebnisse zu erhalten. Diese neuen Ergebnisse werden ebenfalls im Cache gespeichert.

Prüfen, ob eine Abfrage aus dem Cache zurückgegeben wurde

Im Fenster Erkunden sehen Sie in der oberen rechten Ecke, ob eine Abfrage aus dem Cache zurückgegeben wurde.

Wenn eine Abfrage aus dem Cache zurückgegeben wird, wird „aus dem Cache“ angezeigt. Andernfalls wird angezeigt, wie lange die Abfrage zurückgegeben werden muss.

Erzwingen, dass neue Ergebnisse aus der Datenbank generiert werden

Im Fenster Erkunden können Sie erzwingen, dass neue Ergebnisse aus der Datenbank abgerufen werden. Wählen Sie im Zahnradmenü die Option Cache leeren & Aktualisieren aus, die Sie nach dem Ausführen einer Abfrage (einschließlich der zusammengeführten Ergebnisse) rechts oben auf dem Bildschirm finden:

Eine persistente abgeleitete Tabelle wird normalerweise basierend auf der Persistenzstrategie des PDT neu generiert. Sie können erzwingen, dass die abgeleitete Tabelle frühzeitig neu erstellt wird, wenn Ihr Administrator Ihnen die Berechtigung develop gewährt hat und Sie sich einen „Entdecken“ ansehen, der Felder aus dem PDT enthält. Wählen Sie im Drop-down-Menü rechts oben auf dem Bildschirm nach dem Ausführen einer Abfrage die Option Abgeleitete Tabellen & Ausführung erstellen aus:

Weitere Informationen zur Option Abgeleitete Tabellen &Ausführen finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.

Wie lange werden Daten im Cache gespeichert?

Verwenden Sie den Parameter persist_for (für ein Modell oder für eine Erkundung) oder den Parameter max_cache_age (für eine Datengruppe), um festzulegen, wie lange es dauert, bis die im Cache gespeicherten Ergebnisse ungültig werden. Hier sind die verschiedenen Verhaltensweisen auf der Zeitachse, je nachdem, ob die persist_for- oder max_cache_age-Zeit abgelaufen ist:

  • Vor Ablauf der Zeit von persist_for oder max_cache_age: Wenn die Abfrage noch einmal ausgeführt wird, ruft Looker Daten aus dem Cache ab.
  • Wenn die Zeit von persist_for oder max_cache_age abläuft, löscht Looker Daten aus dem Cache, es sei denn, Sie haben die Looker Labs-Funktion für Instant Dashboards aktiviert.
  • Nach Ablauf der persist_for- oder max_cache_age-Zeit: Wenn die Abfrage noch einmal ausgeführt wird, ruft Looker die Daten direkt aus der Datenbank ab und setzt den Timer persist_for oder max_cache_age zurück.

Wichtig ist, dass die Daten nach Ablauf der Zeit von persist_for oder max_cache_age aus dem Cache gelöscht werden, solange die Looker Labs-Funktion für Instant Dashboards deaktiviert ist. Für die Funktion Instant Dashboards wird der Cache benötigt, um Ergebnisse im Cache sofort in ein Dashboard zu laden. Wenn Sie Instant Dashboards aktivieren, bleiben die Daten 30 Tage lang im Cache oder bis die Speicherlimits des Caches erreicht sind. Wenn der Cache das Speicherlimit erreicht, werden Daten basierend auf dem LRU-Algorithmus (Least Kürzlich verwendet) entfernt, ohne dass Daten mit abgelaufenen persist_for- oder max_cache_age-Timern auf einmal gelöscht werden.

Minimieren der Zeit, die Ihre Daten im Cache verbringen

Looker benötigt den internen Cache für interne Prozesse, sodass Daten immer in den Cache geschrieben werden, auch wenn Sie die Parameter persist_for und max_cache_age auf 0 setzen. Nachdem die Daten in den Cache geschrieben wurden, werden sie zum Löschen markiert, können aber bis zu 10 Minuten auf dem Laufwerk verfügbar sein.

Alle Kundendaten, die im Festplatten-Cache angezeigt werden, sind jedoch mit AES (Advanced Encryption Standard) verschlüsselt. Mit diesen Änderungen können Sie die Speicherdauer der Daten im Cache minimieren:

  • Deaktivieren Sie die Looker Labs-Funktion für Instant Dashboards, für die Looker Daten im Cache speichern muss.
  • Setzen Sie den Wert für jeden Parameter von persist_for (für ein Modell oder den Messwert „Entdecken“) oder max_cache_age für einen Parameter (für eine Gruppe) auf „0“. Bei Looker-Instanzen mit deaktivierten Instant Dashboards löscht Looker den Cache, wenn die persist_for-Zeit abgelaufen ist oder die Daten die in der Datengruppe angegebene max_cache_age erreicht haben. Dies ist für den Parameter persist_for persistenter abgeleiteter Tabellen nicht erforderlich, da persistente abgeleitete Tabellen in die Datenbank selbst und nicht in den Cache geschrieben werden.
  • Setzen Sie den Parameter suggest_persist_for auf einen kurzen Zeitraum. Der Wert suggest_persist_for gibt an, wie lange Looker Filtervorschläge im Cache aufbewahren soll. Die Filtervorschläge basieren auf einer Abfrage der Werte für das gefilterte Feld. Diese Abfrageergebnisse werden im Cache gespeichert, sodass Looker schnell Vorschläge bereitstellen kann, wenn der Nutzer in das Filtertextfeld eingibt. Standardmäßig werden die Filtervorschläge 6 Stunden lang im Cache gespeichert. Wenn Sie den Zeitraum der Daten im Cache minimieren möchten, legen Sie den Wert für suggest_persist_for auf einen niedrigeren Wert fest, z. B. 5 Minuten.