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 benötigen mindestens ein virtuelles Warehouse, um Aktualisierungen auszuführen. Sie können optional ein zweites Warehouse zuweisen, wenn Sie die Computekosten für verschiedene Operationen voneinander trennen möchten. Weitere Informationen dazu finden Sie unter Erläuterungen zur Nutzung von Warehouses für dynamische Tabellen.
Aktualisierungen dynamischer Tabellen verbrauchen Compute-Credits. Ihre Häufigkeit wird durch die konfigurierte Zielverzögerung bestimmt: niedrigere Zielverzögerungswerte lösen häufigere Aktualisierungen und damit höhere Computekosten aus.
Dynamische Tabellen erfordern auch Clouddienst-Computing, um Änderungen in den zugrunde liegenden Basisobjekten zu erkennen und um zu bestimmen, ob ein virtuelle Warehouse ausgeführt werden muss. Wenn das Clouddienst-Computing keine Änderungen feststellt, werden keine Warehouse-Compute-Credits verbraucht, da keine neuen Daten aktualisiert werden müssen. Falls Änderungen vorliegen, selbst wenn die dynamische Tabellenabfrage diese filtert, verbraucht das virtuelle Warehouse Credits, da die dynamische Tabelle aktualisiert wird, um zu prüfen, ob diese Änderungen zutreffen.
Wenn die zugehörigen virtuellen Warehouses angehalten werden und das Clouddienst-Computing keine Änderungen in den Basistabellen feststellt, bleiben die Warehouses angehalten und die dynamischen Tabellen verbrauchen keine Credits. Wenn das Clouddienst-Computing Änderungen in den Basistabellen feststellt, wird das entsprechende Warehouse automatisch fortgesetzt. Wenn die Änderungen eine inkrementelle Aktualisierung unterstützen, wird die dynamische Tabelle unter Verwendung des Parameters WAREHOUSE aktualisiert. Wenn eine Neuinitialisierung erforderlich ist – z. B. aufgrund einer Änderung des Schemas einer Basistabelle – verwendet die dynamische TabelleINITIALIZATION_WAREHOUSE, um eine vollständige Neuinitialisierung auszuführen. Informationen darüber, wie dynamische Tabellen automatisch angehalten werden, finden Sie unter Automatisches Anhalten dynamischer Tabellen.
Überprüfen des Verbrauchs von Credits für virtuelle Warehouses¶
Um zu überprüfen, ob die Aktualisierungen Ihrer dynamischen Tabelle virtuelle Warehouse-Credits verbraucht haben, verwenden Sie die Registerkarte Refresh History in Snowsight:
Wählen Sie im Navigationsmenü die Option Transformation » Dynamic tables aus.
Wählen Sie Ihre dynamische Tabelle aus, und wählen Sie dann die Registerkarte Refresh History aus.
Um Aktualisierungen anzuzeigen, die das Warehouse zur Aktualisierung verwendet haben, aktivieren Sie das Kontrollkästchen Warehouse used only.
Tipp
Um die Kosten für Ihre dynamischen Tabellenpipelines besser zu verstehen, empfiehlt Snowflake, dass Sie dynamische Tabellen mit dedizierten Warehouses testen. Auf diese Weise können Sie den Verbrauch des virtuellen Warehouses isolieren, der den dynamischen Tabellen zugeordnet ist. Sie können Ihre dynamischen Tabellen in ein freigegebenes Warehouse verschieben, nachdem Sie eine Kosten-Baseline erstellt haben.
Weitere Informationen dazu finden Sie unter Erläuterungen zur Nutzung von Warehouses für dynamische Tabellen.
Computekosten für Unveränderlichkeitseinschränkungen¶
Wenn Sie die IMMUTABLE WHERE-Einschränkung verwenden, berechnet Snowflake nur die Zeilen neu, die nicht der Unveränderlichkeitsbedingung entsprechen, wodurch die Kosten für die Neuinitialisierung gesenkt werden können. Dies ist in Situationen nützlich, in denen eine Neuinitialisierung erfolgen kann, wie z. B. in den folgenden Szenarios:
Neuerstellen von vorgelagerten Tabellen oder Ansichten.
Änderungen an vorgelagerten Data Governance-Richtlinien.
Failover in eine Sekundärregion in einer Failover-Gruppe.
Das Verwenden der IMMUTABLE WHERE-Einschränkung kann Ihnen dabei helfen, die Kosten für inkrementelle und vollständige Aktualisierungen zu senken, da die Einschränkung Änderungen und Daten ignoriert, die mit ihrem Prädikat übereinstimmen.
Das Hinzufügen von Unveränderlichkeitsbeschränkungen zu einer dynamischen Tabelle löst keine zusätzlichen Berechnungen aus, das Entfernen hingegen schon, da es bei der nächsten Aktualisierung eine Neuinitialisierung verursacht. Das Ändern des Prädikats in einer IMMUTABLE WHERE-Einschränkung kann eine Neuinitialisierung auslösen, je nachdem, ob Snowflake feststellen kann, dass die Zeilen, die mit der ursprünglichen Bedingung zurückgegeben werden, weiterhin mit der neuen Bedingung zurückgegeben werden.
Die folgenden Änderungen lösen zum Beispiel keine Neuinitialisierung aus:
Von
(ts < CURRENT_TIMESTAMP() – INTERVAL '2 Tage')zu(ts < CURRENT_TIMESTAMP() – INTERVAL '1 Tag')Von
(Jahr <= 2023)zu(Jahr <= 2024)
Die folgenden Änderungen lösen eine Neuinitialisierung aus:
Von
(ts < '2025-01-02')zu(ts < '2025-01-01')Von
(Jahr < 2024)zu(Monat < 10)
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 Klonen-Features entstehen.
Dynamische Apache Iceberg™-Tabellen verursachen keine Snowflake-Speicherkosten. Weitere Informationen dazu finden Sie unter Rechnungsstellung.
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.
Durch häufige Aktualisierungen können sich mehr Time Travel-Daten ansammeln, 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 Sie laufende Wartungsaufgaben oder geplante Jobs haben, die mit der angehaltenen Tabelle interagieren, verbrauchen Ihre dynamischen Tabellen möglicherweise Computeressourcen.
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 unter der Annahme, dass jede Aktualisierung nicht leer ist, zu berücksichtigen sind:
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 davon ab, wie viele Daten Ihre dynamische Tabelle scannt und wie oft sie aktualisiert wird. 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 die nachgelagerte Zielverzögerung für Ihre dynamischen Tabellen ein und verwenden die manuelle Aktualisierung über eine Aufgabe, um Ihre kundenspezifischen Zeitpläne zu automatisieren.
Inkrementeller Aktualisierungszeitplan¶
Die Kosten für eine 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 die dynamische Tabelle kann dank der geringeren zusätzlichen Kosten häufig ausgeführt werden.
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 Sie beispielsweise die Änderungen in einer Tabelle mit der anderen Tabelle verknüpfen. Unabhängig davon, wie klein die Menge der Änderungen ist, ist die Ausführung dieses Joins in der Regel mit minimalen Kosten für Sie verbunden. Wenn dieser Overhead beträchtlich ist, kann er sich mit zunehmender Aktualisierungshäufigkeit anhäufen.