Ich habe die Google BigQuery Materialized Views anhand der Dokumentation getestet. Während die meisten Funktionen und Einschränkungen korrekt sind, gibt es ein paar Probleme, die Sie beachten sollten.
Einrichtung
Für den Rest des Beitrags werde ich diese Tabellen und Ansichten verwenden:
Beispiel BQ-Schema:
Beispielhafte Ansicht:
Erzeugung von Daten
Zusätzlich zu den statischen Daten habe ich die Ansicht auch mit konstanten Datenströmen in die Basistabelle getestet. Das geht ganz einfach mit einer Google Dataflow-Vorlage. Mit dieser Vorlage können Sie schnell große Streaming-Puffer generieren (bei Bedarf 10k Zeilen/Sek.). Ich empfehle sie, wenn Sie etwas mit einer großen Stichprobe von Streaming-Daten testen müssen. (Das Ziel kann Google BigQuery, Pub/Sub oder GCS sein.)
Materialisierte Ansichten können nicht über die UI/API erstellt werden, sondern nur über die DDL
Bei der Abfrage von materialisierten Ansichten führt Google BigQuery die Abfrage auch auf der "Partition" der Basistabelle aus, die noch nicht zwischengespeichert wurde, so dass Sie immer ein genaues Ergebnis erhalten.
Aus diesem Grund können nur solche Aggregatfunktionen verwendet werden, bei denen "Teilergebnisse" berechnet werden können (z. B. max, sum, avg, aber nicht rank)
Aus demselben Grund sind analytische Funktionen ausgeschlossen.
Das Umschreiben von Abfragen funktioniert manchmal. Diese Funktion bedeutet, dass, wenn Sie die Basistabelle abfragen und das Ergebnis (zumindest teilweise) auf der Grundlage der materialisierten Ansicht berechnet werden kann, die Google BigQuery-Engine die Abfrage umschreibt, um sie zu verwenden. Wenn Sie diese Funktion nutzen möchten, sollten Sie Folgendes beachten:
Die Abfrage (oder ein Teil davon) muss eine "Teilmenge" der materialisierten Ansicht sein. Das heißt, Sie können nur nach Spalten filtern, die der Ansicht zur Verfügung stehen; außerdem müssen Sie die gleichen (oder mehr) Aggregationen wie die Ansicht durchführen (falls vorhanden). Als Beispiel wurde die erste Abfrage immer umgeschrieben, während die zweite nur in etwa 50 % der Fälle abgefragt wurde:
Der einzige Unterschied zwischen diesen Abfragen ist die Position der WHERE-Klausel. In der ersten habe ich sie in den Teil der vollständigen Tabellendurchsuchung verschoben, während die JOIN-Tabelle direkt mit der materialisierten Ansicht ausgetauscht werden kann. Im zweiten Beispiel bezieht sich der Filter auf die gesamte verknüpfte Tabelle; die Engine wird dadurch verwirrt und scannt die Tabelle für beide Teile der Abfrage.
Materialisierte Ansichten werden innerhalb von 5 Minuten nach einer Tabellenänderung aktualisiert, aber nur einmal alle 30 Minuten. Dies kann mit DDL auf einen Zeitraum zwischen 1 Minute und 7 Tagen geändert werden. Für einen Anwendungsfall mit konstantem Datenfluss könnte es ratsam sein, die Auffrischung zu verringern (auf 5 bis 10 Minuten). Dies hängt natürlich von der Menge der eingegebenen Daten, der Komplexität der Abfrage und der Preisgestaltung ab.
Schlussfolgerung
Wo sollten Sie materialisierte Ansichten verwenden? Leider nicht als standardmäßiges "Zwischenspeichern dieses Abfrageergebnisses" für jeden Anwendungsfall, da es Einschränkungen gibt: sowohl bei den reduzierten SQL-Funktionen, die akzeptiert werden können, als auch bei der Begrenzung der Anzahl der materialisierten Ansichten, die eine Tabelle haben kann (bis zu 20 innerhalb eines einzigen Datensatzes; das Umschreiben von Abfragen funktioniert nur innerhalb des Datensatzes). Die folgenden Szenarien sind erwägenswert:
Caching einer kompatiblen Abfrage, die performant sein muss.
Leider ist eine Verlaufsansicht vom Typ 2 nicht kompatibel, da sie analytische Funktionen verwendet.
Zwischenspeicherung von "Basis"- oder allgemeinen Aggregationen für BI-Zwecke. Wenn beispielsweise ein Data Studio-Diagramm die Möglichkeit bietet, die Daten mit drei verschiedenen Aggregationen darzustellen, kann es sich lohnen, drei materialisierte Ansichten zu erstellen. Alle Filter oder Sortierungen, die auf die BI-Diagramme angewendet werden, werden dann auf diese Ansichten anstatt auf die vollständige Tabelle angewendet. Dies kann ein leistungsfähiges Werkzeug sein, um sowohl Kosten zu sparen als auch die Leistung zu steigern, vorausgesetzt, die materialisierte Ansicht ist wesentlich kleiner.
Sie können das Clustering einer materialisierten Ansicht einstellen, sodass Sie Ansichten für häufige Aggregations-/Sortierungsszenarien erstellen können, um noch größere Gewinne zu erzielen.
