Erläuterungen zu den Kosten von dynamischen Tabellen¶
Dieses Thema bietet eine Übersicht zu den mit dynamischen Tabellen verbundenen Compute- und Speicherkosten. Allgemeine Informationen zu Snowflake-Kosten finden Sie unter Erläuterungen zu den Gesamtkosten.
Computekosten¶
dynamische Tabellen verursachen zwei Arten von Computekosten: Computing virtueller Warehouses und Computing von Clouddiensten.
Dynamische Tabellen erfordern virtuelle Warehouses zur Aktualisierung – d. h. zum Ausführen von Abfragen auf Basisobjekten, wenn diese initialisiert und aktualisiert werden, einschließlich geplanter und manueller Aktualisierungen. Diese Operationen nutzen Computeressourcen, die Credits verbrauchen.
Dynamische Tabellen erfordern auch Clouddienst-Computing, um Änderungen in den zugrunde liegenden Basisobjekten zu erkennen und um festzustellen, ob das virtuelle Warehouse aufgerufen werden muss. Wenn keine Änderungen festgestellt werden, werden keine Credits für das virtuelle Warehouse verbraucht, da es keine neuen Daten zu aktualisieren gibt. Beachten Sie, dass es Fälle geben kann, in denen Änderungen an Basisobjekten in der Abfrage der dynamischen Tabellen herausgefiltert werden. In solchen Szenarios verbraucht das virtuelle Warehouse Credits, da die dynamische Tabelle aktualisiert wird, um festzustellen, ob die Änderungen zutreffend sind.
Wenn das zugehörige virtuelle Warehouse angehalten wird und keine Änderungen an Basisobjekten festgestellt werden, wird das angehaltene virtuelle Warehouse nicht aufgerufen und es werden keine Credits verbraucht. Werden hingegen Änderungen festgestellt, wird das virtuelle Warehouse fortgesetzt, um die Aktualisierungen zu verarbeiten.
Aktualisierungen von dynamischen Tabellen werden über die konfigurierte Zielverzögerung gesteuert. Pipelines von dynamischen Tabellen mit geringerer Zielverzögerung aktualisieren häufiger und verursachen daher höhere Computekosten.
Auf der Registerkarte Refresh History in Snowsight können Sie überprüfen, ob virtuelle Warehouses Credits verbraucht haben:
Wählen Sie im Navigationsmenü die Option Monitoring » Dynamic Tables aus.
Wählen Sie Ihre dynamische Tabelle aus, und gehen Sie auf die Registerkarte Refresh History. Aktivieren Sie das Kontrollkästchen Warehouse used only, um die Aktualisierungen anzuzeigen, die auf das Warehouse angewendet wurden.
Tipp
Um ein klares Bild von den Kosten der Pipelines Ihrer dynamischen Tabellen zu erhalten, empfiehlt Snowflake, dynamische Tabellen mit dedizierten Warehouses zu testen, sodass der Verbrauch des virtuellen Warehouses, der den dynamischen Tabellen zugeordnet ist, isoliert werden kann. Sie können Ihre dynamischen Tabellen in ein freigegebenes Warehouse verschieben, nachdem Sie eine Kosten-Baseline erstellt haben.
Speicherkosten¶
Dynamische Tabellen benötigen Speicherplatz, um die materialisierten Ergebnisse zu speichern. Ähnlich wie bei regulären Tabellen können Ihnen zusätzliche Speicherkosten für Time Travel, Fail-safe-Speicherung und das Klonen-Feature entstehen.
In diesem Abschnitt werden die folgenden Speicheraspekte von dynamischen Tabellen behandelt:
Ausführliche Informationen darüber, wie diese Speicherung Kosten verursacht, finden Sie unter Erläuterungen zu den Speicherkosten und Hinweise zur Datenspeicherung.
Speicher für Time Travel und Fail-safe¶
Mit Snowflake Time Travel können Sie auf historische Versionen dynamischer Tabellen zu bestimmten Zeitpunkten zugreifen und diese abfragen, was Ihnen Einblicke in historische Trends, Veränderungen und Anomalien in Ihren Daten verschafft. Beachten Sie, dass sich durch häufige Aktualisierungen mehr Time Travel-Daten ansammeln können, was den Speicherverbrauch erhöht. Weitere Informationen dazu finden Sie unter Verstehen und Verwenden von Time Travel.
Fail-safe-Features schützen Ihre dynamischen Tabellen vor Datenverlust oder -beschädigung. Abhängig von der konfigurierten Fail-safe-Frist können zusätzliche Speichergebühren anfallen.
Replikation von dynamischen Tabellen¶
Dynamischen Tabellen unterstützen die konto- und regionsübergreifende Replikation, sodass Sie Daten aus einer Primärdatenbank in eine Sekundärdatenbank entweder für Notfallwiederherstellung oder Data Sharing kopieren können. Sie kann entweder als Failover-Vorbereitungsstrategie für die Notfallwiederherstellung oder als Mittel zum Data Sharing über verschiedene Bereitstellungen hinweg und rein zu Lesezwecken dienen. Die Verwendung der Replikation mit dynamischen Tabellen unterliegt den Replikationskosten. Weitere Informationen dazu finden Sie unter Replikation und dynamische Tabellen.
Angehaltene dynamische Tabellen¶
Angehaltene dynamische Tabellen verursachen keine zusätzlichen Kosten über die normalen Speichergebühren hinaus und verbrauchen keine Computeressourcen. Wenn es laufende Wartungsaufgaben oder geplante Jobs gibt, die mit der angehaltenen Tabelle interagieren, werden möglicherweise Computeressourcen verbraucht.
Transiente dynamische Tabellen¶
Snowflake unterstützt transiente dynamische Tabellen wie reguläre Tabellen, die bestehen bleiben, bis sie explizit gelöscht werden, und die allen Benutzern mit den entsprechenden Berechtigungen zur Verfügung stehen. Transiente dynamische Tabellen eignen sich am besten für vorübergehende Daten, die nicht dasselbe Maß an Datenschutz und Wiederherstellung benötigen wie permanente Tabellen, sodass Sie die Kosten für die ausfallsichere Fail-safe-Speicherung sparen können.
Zusätzlicher Speicher für inkrementelle Aktualisierungsoperationen¶
Für inkrementelle Aktualisierungsoperationen unterhalten dynamische Tabellen eine zusätzliche interne Metadatenspalte zur Identifizierung jeder Zeile innerhalb der Tabelle. Interne Zeilen-Identifikatoren verbrauchen eine konstante Menge an Speicherplatz pro Zeile und erhöhen die Speicherkosten linear mit der Anzahl der Zeilen in der Tabelle (unabhängig von der Anzahl der Spalten). Bei Tabellen mit sehr wenigen Spalten kann die Zunahme des Speicherplatzes im Vergleich zu einer entsprechenden CTAS-Tabelle signifikant oder sogar dominant sein. Bei breiteren dynamischen Tabellen ist dieser Effekt weniger stark ausgeprägt.
Kosten für Aktualisierungszeitplan¶
Der Zeitplan, nach dem eine dynamische Tabelle aktualisiert wird, ob vollständig oder inkrementell, hat Auswirkungen auf die Gesamtkosten. In diesem Abschnitt werden die Faktoren erörtert, die bei der Entscheidung für einen Aktualisierungszeitplan zu berücksichtigen sind (unter der Annahme, dass jede Aktualisierung nicht leer ist):
Bemerkung
Aktualisierungen sind relativ kostengünstig, wenn sich die Quellen nicht geändert haben. Weitere Informationen dazu finden Sie unter Computekosten (unter diesem Thema).
Zeitplan für vollständige Aktualisierung¶
Die Kosten für eine vollständige Aktualisierung hängen in der Regel von den gescannten Daten und der Aktualisierungshäufigkeit ab. Um Kosten zu sparen, können Sie Ihre dynamischen Tabellen nur bei Bedarf aktualisieren, indem Sie zum Beispiel Ihre dynamischen Tabellen außerhalb der Geschäftszeiten anhalten. Für eine präzise Zeitsteuerung stellen Sie eine nachgelagerte Zielverzögerung für Ihre dynamischen Tabellen ein und verwenden die manuelle Aktualisierung über eine Aufgabe, um benutzerdefinierte Zeitpläne zu automatisieren.
Inkrementeller Aktualisierungszeitplan¶
Die Kosten für die inkrementelle Aktualisierung sind in der Regel proportional zum Umfang der Änderungen in den Quellobjekten, zuzüglich eines gewissen fixen Verwaltungsaufwands oder Overhead.
Wenn der Overhead gering ist, können Sie ohne große Nachteile eine hohe Aktualisierungshäufigkeit einstellen. Dies bedeutet, dass Sie für beste Ergebnisse häufig aktualisieren können. Bei einem einfachen SELECT ... FROM ... WHERE verarbeitet die dynamische Tabelle beispielsweise nur geänderte Zeilen zwischen den Aktualisierungen, was einen minimalen Overhead hat und dank der geringeren zusätzlichen Kosten häufig ausgeführt werden kann.
Wenn der Overhead hoch ist, müssen Sie den Credit-Verbrauch bei hoher Aktualisierungshäufigkeit gegen die geschäftlichen Vorteile der Datenaktualität abwägen. Bei einer dynamischen Tabelle mit einem Join müssen beispielsweise die Änderungen in einer Tabelle mit der anderen Tabelle verknüpft werden. Unabhängig davon, wie klein die Menge der Änderungen ist, ist die Ausführung dieser Verknüpfung in der Regel mit einem Minimum an Kosten verbunden. Wenn dieser Overhead beträchtlich ist, kann er sich mit zunehmender Aktualisierungshäufigkeit anhäufen.