Verwenden von persistent gespeicherten Abfrageergebnissen

Wenn eine Abfrage ausgeführt wird, wird das Ergebnis für einen Zeitraum gespeichert (d. h. im Cache). Am Ende des Zeitraums wird das Ergebnis aus dem System entfernt.

Snowflake verwendet persistente Abfrageergebnisse, um ein erneutes Generierung der Ergebnisse zu verhindern, wenn sich nichts geändert hat (d. h. „Abrufoptimierung“). Außerdem können Sie persistente Abfrageergebnisse dazu verwenden, Ergebnisse nachzubearbeiten (z. B. Überlagerung der bereits berechneten Ergebnisse durch eine neue Abfrage).

Für persistierte Abfrageergebnisse aller Größen läuft der Cache nach 24 Stunden ab.

Das Sicherheitstoken, das für den Zugriff auf große persistierte Abfrageergebnisse (d. h. mehr als 100 KB) verwendet wird, läuft nach 6 Stunden ab. Ein neues Token kann abgerufen werden, um auf die Ergebnisse zuzugreifen, während sie sich noch im Cache befinden. Bei kleineren persistierten Abfrageergebnissen sollten Sie kein Zugriffstoken verwenden.

Bemerkung

Das dem Snowflake-Konnektor für Spark („Spark-Konnektor“) zur Verfügung gestellt Token läuft unabhängig von der Größe der persistierten Abfrageergebnisse nach 24 Stunden ab. Der Spark-Konnektor nutzt die längere Cache-Ablaufzeit, um in bestimmten Anwendungsfällen Timeouts zu vermeiden.

Unter diesem Thema:

Abrufoptimierung

Wenn ein Benutzer eine bereits ausgeführte Abfrage wiederholt und sich die Daten in den Tabellen seit dem letzten Ausführen der Abfrage nicht geändert haben, dann ist das Ergebnis der Abfrage das gleiche. Anstatt die Abfrage erneut auszuführen, kann Snowflake einfach das gleiche Ergebnis wie zuvor zurückgeben. Dies kann die Abfragedauer erheblich verkürzen, da Snowflake die Abfrageausführung umgeht und das Ergebnis stattdessen direkt aus dem Cache abruft.

In der Regel können Abfrageergebnisse wiederverwendet werden, wenn jede der folgenden Bedingungen erfüllt ist:

  • Die neue Abfrage stimmt genau mit der zuvor ausgeführten Abfrage überein. Jeder Unterschied in der Syntax, einschließlich Klein-/Großbuchstaben oder die Verwendung von Tabellen-Aliassen, verhindert die 100%-Wiederverwendung des Cache-Inhalts. Betrachten Sie zum Beispiel die folgenden Abfragen, die nacheinander ausgeführt werden:

    SELECT DISTINCT(severity) FROM weather_events;
    SELECT DISTINCT(severity) FROM weather_events;
    SELECT DISTINCT(severity) FROM weather_events we;
    select distinct(severity) from weather_events;
    
    Copy

    Die erste Abfrage füllt den Cache, und die identische zweite Abfrage profitiert von der 100%igen Cache-Wiederverwendung. Die dritte und vierte Abfrage lösen jedoch keine Wiederverwendung des Cache aus, weil die dritte Abfrage einen Tabellenalias einführt und die vierte Abfrage Schlüsselwörter in Kleinbuchstaben verwendet.

  • Die Abfrage enthält keine nicht wiederverwendbaren Funktionen, die bei aufeinanderfolgenden Ausführungen der gleichen Abfrage unterschiedliche Ergebnisse liefern. UUID_STRING, RANDOM und RANDSTR sind typische Beispiele für nicht wiederverwendbare Funktionen.

  • Die Abfrage umfasst keine externen Funktionen.

  • Die Tabellendaten, die zum Abfrageergebnis beitragen, haben sich nicht geändert.

  • Das persistierte Ergebnis der vorherigen Abfrage ist noch verfügbar.

  • Die Rolle, die auf die zwischengespeicherten Ergebnisse zugreift, verfügt über die erforderlichen Berechtigungen.

    • Wenn die Abfrage eine SELECT-Abfrage war, muss die Rolle, die die Abfrage ausführt, über die erforderlichen Zugriffsrechte für alle in der zwischengespeicherten Abfrage verwendeten Tabellen verfügen.

    • Wenn die Abfrage eine SHOW-Abfrage war, muss die Rolle, die die Abfrage ausführt, mit der Rolle übereinstimmen, die die zwischengespeicherten Ergebnisse generiert hat.

  • Alle Konfigurationsoptionen, die beeinflussen, wie das Ergebnis generiert wurde, haben sich nicht geändert.

  • Die Mikropartitionen der Tabelle haben sich nicht aufgrund von Änderungen an anderen Daten in der Tabelle verändert (z. B. Reclustering oder Konsolidierung).

Bemerkung

Auch wenn alle diese Bedingungen erfüllt sind, kann nicht garantiert werden, dass Snowflake die Abfrageergebnisse wiederverwendet.

Standardmäßig ist der die Wiederverwendung von Ergebnissen aktiviert. Dies kann aber auf Konto-, Benutzer- und Sitzungsebene mit dem Parameter USE_CACHED_RESULT überschrieben werden.

Bemerkung

Jedes Mal, wenn das persistente Ergebnis für eine Abfrage wiederverwendet wird, setzt Snowflake die 24-stündige Aufbewahrungsfrist für das Ergebnis zurück – bis maximal 31 Tage nach Datum/Uhrzeit der erstmaligen Ausführung der Abfrage. Nach 31 Tagen wird das Ergebnis bereinigt, und beim nächsten Übermitteln der Abfrage wird ein neues Ergebnis generiert und persistent gespeichert.

Weiterverarbeiten von Abfrageergebnissen

In einigen Fällen ist es sinnvoll, das Ergebnis einer bereits ausgeführten Abfrage weiterzuverarbeiten. Beispiel:

  • Sie entwickeln eine komplexe Abfrage Schritt für Schritt, und Sie möchten nun eine neue Schicht zu einer vorherigen Abfrage hinzufügen und die neue Abfrage ausführen, ohne die Teilergebnisse noch einmal komplett neu zu berechnen.

  • Die vorherige Abfrage war eine SHOW <Objekte>-, DESCRIBE <Objekt>- oder CALL-Anweisung, die Ergebnisse in einer Form zurückgibt, die nicht einfach wiederverwendbar ist.

    Sie können z. B. eine gespeicherte Prozedur nicht innerhalb einer komplexeren SQL-Anweisung aufrufen, so wie Sie eine Funktion innerhalb einer SQL-Anweisung aufrufen können, sodass die einzige Möglichkeit, die Ausgabe der gespeicherten Prozedur zu verarbeiten, darin besteht, die gespeicherten Abfrageergebnisse nachzubearbeiten.

Die Weiterverarbeitung kann mit der Tabellenfunktion RESULT_SCAN durchgeführt werden. Die Funktion gibt die Ergebnisse der vorherigen Abfrage als „Tabelle“ zurück, und eine neue Abfrage kann dann auf den tabellarischen Daten ausgeführt werden.

Beispiele

Verarbeiten Sie das Ergebnis eines SHOW TABLES-Befehls, und extrahieren Sie die folgenden Spalten und Zeilen aus dem Ergebnis:

  • Spalten schema_name, table_name und rows

  • Zeilen für Tabellen, die leer sind.

SHOW TABLES;

+-----+-------------------------------+-------------+-------+-------+------+
| Row |           created_on          | name        | ...   | ...   | rows |
+-----+-------------------------------+-------------+-------+-------+------+
|  1  | 2018-07-02 09:43:49.971 -0700 | employees   | ...   | ...   | 2405 |
+-----+-------------------------------+-------------+-------+-------+------+
|  2  | 2018-07-02 09:43:52.483 -0700 | dependents  | ...   | ...   | 5280 |
+-----+-------------------------------+-------------+-------+-------+------+
|  3  | 2018-07-03 11:43:52.483 -0700 | injuries    | ...   | ...   |    0 |
+-----+-------------------------------+-------------+-------+-------+------+
|  4  | 2018-07-03 11:43:52.483 -0700 | claims      | ...   | ...   |    0 |
+-----+-------------------------------+-------------+-------+-------+------+
| ...                                                                      |
| ...                                                                      |
+-----+-------------------------------+-------------+-------+-------+------+

-- Show the tables that are empty.
SELECT  "schema_name", "name" as "table_name", "rows"
    FROM table(RESULT_SCAN(LAST_QUERY_ID()))
    WHERE "rows" = 0;

+-----+-------------+-------------+------+
| Row | schema_name | name        | rows |
+-----+-------------+-------------+------+
|  1  |  PUBLIC     | injuries    |    0 |
+-----+-------------+-------------+------+
|  2  |  PUBLIC     | claims      |    0 |
+-----+-------------+-------------+------+
| ...                                    |
| ...                                    |
+-----+-------------+-------------+------+
Copy

Weitere Beispiele finden Sie unter RESULT_SCAN.