Hinweise zur Datenspeicherung¶

Unter diesem Thema werden Richtlinien und bewährte Methoden zur Steuerung der Datenspeicherkosten in Verbindung mit Continuous Data Protection (CDP) bereitgestellt, insbesondere für Tabellen.

CDP, das Time Travel und Fail-safe mit einschließt, ist ein Standardsatz von Funktionen, der für alle Snowflake-Konten ohne zusätzliche Kosten verfügbar ist. Da Ihrem Konto jedoch Gebühren für alle Daten entstehen, die sich in Tabellen, Schemas und Datenbanken befinden, die sich von Ihrem Konto erstellt wurden, hat CDP Auswirkungen auf die Speicherkosten, basierend auf der Gesamtmenge der gespeicherten Daten und der Dauer der Datenspeicherung.

Der Speicher wird für die Daten berechnet und in Rechnung gestellt, unabhängig davon, ob diese sich im Status Aktiv, Time Travel oder Fail-safe befinden. Da diese Lebenszyklusstatus sequenziell sind, fallen für aktualisierte/gelöschte Daten, die durch CDP geschützt werden, so lange Speicherkosten an, bis die Daten den Fail-safe-Status verlassen.

Bemerkung

Für TIME_TRAVEL_BYTES und FAILSAFE_BYTES fallen Gebühren an, wenn Sie Daten mit INSERT, COPY oder SNOWPIPE laden. Das liegt daran, dass bei der Defragmentierung kleiner Mikropartitionen kleine Mikropartitionen gelöscht und eine neue Mikropartition mit denselben Daten erstellt wird. Die gelöschten Mikropartitionen tragen zu TIME_TRAVEL_BYTES und FAILSAFE_BYTES bei.

Unter diesem Thema:

Überwachen der Datenspeicherung¶

Speicher für Ihr Konto (nur Kontoadministratoren)¶

Wenn Ihnen die Rolle ACCOUNTADMIN zugewiesen wurde (d. h. Sie sind der oberste Administrator Ihres Snowflake-Kontos), können Sie über Snowsight oder die klassische Weboberfläche den Datenspeicher Ihres gesamten Kontos anzuzeigen:

Snowsight:: Select Admin » Cost Management » Consumption.
Classic Console:: Klicken Sie auf Account » Billing & Usage » Average Storage Used.

Auf dieser Seite wird der durchschnittliche Gesamtdatenspeicher Ihres Kontos sowie der Gesamtwert für alle Datenbanken, interne und benannte Stagingbereiche sowie der Daten im Fail-safe-Status angezeigt.

Weitere Informationen dazu finden Sie unter Untersuchen der Speicherkosten.

Individuelle Tabellenspeicher¶

Jeder Benutzer mit den entsprechenden Berechtigungen kann den Datenspeicher für einzelne Tabellen anzeigen. Snowflake bietet die folgenden Methoden zum Anzeigen von Tabellendatenspeicher:

Classic Console:

Klicken Sie auf Databases » <DB-Name> » Tables

SQL:

Führen Sie einen SHOW TABLES-Befehl aus.

oder

Führen Sie eine Abfrage durch auf:

TABLE_STORAGE_METRICS-Ansicht (in Snowflake Information Schema).
Ansicht Ansicht TABLE_STORAGE_METRICS (in Account Usage).

Von den drei Methoden liefert TABLE_STORAGE_METRICS die detailliertesten Informationen, da hier eine Aufgliederung des physischen Speichers (in Bytes) für Tabellendaten in den folgenden drei Zuständen des CDP-Lebenszyklus enthalten ist:

Aktiv (Spalte ACTIVE_BYTES)
Time Travel (Spalte TIME_TRAVEL_BYTES)
Fail-safe (Spalte FAILSAFE_BYTES)

Die Ansicht enthält auch Spalten, um zwischen dem eigenen Speicher und dem referenzierten Speicher zu unterscheiden, der beim Klonen von Tabellen auftritt (siehe Abschnitt unten).

Speicher für Staging-Dateien (zum Laden von Daten)¶

Um das Massenladen von Daten in Tabellen zu unterstützen, verwendet Snowflake Stagingbereiche, in denen die Dateien gespeichert werden, die die zu ladenden Daten enthalten. Snowflake unterstützt sowohl interne als auch externe Stagingbereiche.

Datendateien, die in internen Snowflake-Stagingbereichen bereitgestellt werden, unterliegen nicht den zusätzlichen Kosten, die mit Time Travel und Fail-safe verbunden sind, sie verursachen jedoch Standardspeicherkosten. Um die Speicherkosten besser verwalten zu können, empfiehlt Snowflake, diese Dateien zu überwachen und aus den Stagingbereichen zu entfernen, sobald die Daten geladen wurden und die Dateien nicht mehr benötigt werden. Sie können diese Dateien entweder während des Ladens von Daten (mit dem Befehl COPY INTO <Tabelle>) oder danach (mit dem Befehl REMOVE) entfernen.

Weitere Informationen dazu finden Sie unter Hinweise zum Laden von Daten.

Tipp

Das regelmäßige Löschen von Staging-Dateien kann weitere Vorteile haben, z. B. eine verbesserte Leistung beim Laden von Daten.

Klonen von Tabellen, Schemas und Datenbanken¶

Die Zero-Copy-Cloning-Funktion von Snowflake bietet eine bequeme Möglichkeit, um schnell eine Momentaufnahme („Snapshot“) einer Tabelle, eines Schemas oder einer Datenbank zu erstellen und eine abgeleitete Kopie dieses Objekts zu erstellen, die den zugrunde liegenden Speicher anfänglich gemeinsam nutzt. Dies kann äußerst nützlich sein, um sofortige Sicherungen zu erstellen, für die keine zusätzlichen Kosten anfallen (bis Änderungen am geklonten Objekt vorgenommen werden).

Durch das Klonen wird die Berechnung der Gesamtspeichernutzung jedoch komplexer, da jeder Klon seinen eigenen Lebenszyklus hat. Dies bedeutet, dass Änderungen am ursprünglichen Objekt oder am Klon unabhängig voneinander vorgenommen werden können und diese Änderungen durch CDP geschützt werden.

Wenn zum Beispiel von einer Tabelle ein Klon erstellt wird, verwendet der Klon keinen Datenspeicher, da er alle vorhandenen Mikropartitionen der ursprünglichen Tabelle zum Zeitpunkt des Klonens gemeinsam nutzt. Jedoch können unabhängig von der ursprünglichen Tabelle Zeilen im Klon hinzugefügt, gelöscht oder aktualisiert werden. Jede Änderung des Klons führt zu neuen Mikropartitionen, die ausschließlich dem Klon gehören und durch CDP geschützt werden.

Darüber hinaus können Klone geklont werden, wobei keine Beschränkung hinsichtlich der Anzahl der Iterationen von Klonen gibt, die erstellt werden können (d. h. können Sie einen Klon eines Klons eines Klons usw. erstellen). Dies führt zu einer Hierarchie von n-Ebenen geklonter Objekte, von denen jedes einen eigenen Anteil an freigegebenem und unabhängigem Datenspeicher besitzt.

Tabellen-IDs¶

Jede Snowflake-Tabelle hat eine ID, mit der die Tabelle eindeutig identifiziert wird. Außerdem ist jeder Tabelle auch eine CLONE_GROUP_ID zugeordnet. Wenn eine Tabelle keine Klone hat, sind ID und CLONE_GROUP_ID identisch. Diese IDs werden in der TABLE_STORAGE_METRICS -Ansicht angezeigt.

Eigener Speicher vs. referenzierter Speicher¶

Wenn eine Tabelle geklont wird, wird ihr eine neue ID und die CLONE_GROUP_ID für die Originaltabelle zugewiesen. Zum Zeitpunkt der Erstellung des Klons werden alle Mikropartitionen in beiden Tabellen vollständig freigegeben. Der mit diesen Mikropartitionen verknüpfte Speicher ist Eigentum der ältesten Tabelle der Klongruppe, und der Klon referenziert diese Mikropartitionen.

Nachdem ein Klon erstellt wurde, verfügen beide Tabellen in der Klongruppe über separate Lebenszyklen, sodass durch beliebige DML-Operationen auf den beiden Tabellen neue Mikropartitionen erstellt werden, die ihren jeweiligen Tabellen gehören. Der mit diesen Mikropartitionen verknüpfte Speicher kann über die Spalte RETAINED_FOR_CLONE_BYTES der Ansicht TABLE_STORAGE_METRICS abgefragt werden.

Da jede Tabelle in einer Klongruppe einen unabhängigen Lebenszyklus hat, muss die Eigentümerschaft des Speichers in diesen Tabellen manchmal auf eine andere Tabelle der Klongruppe übertragen werden. Stellen Sie sich beispielsweise eine Klongruppe vor, die aus Folgendem besteht:

Ursprüngliche Tabelle:

Geklont in:

Geklont in:

T1

»

T2

»

T3

Wenn sich T2 und T3 einige Mikropartitionen teilen und T2 gelöscht wird, muss die Eigentümerschaft dieses Speichers übertragen werden, bevor T2 in den Fail-safe-Status übergeht. In Snowflake erfolgt diese Übertragung zu dem Zeitpunkt, zu dem die Mikropartitionen den Time Travel-Status verlassen und ansonsten in den Fail-safe-Status eintreten. Im obigen Fall werden die zuvor von T2 besessenen Mikropartitionen nach Ablauf der Time Travel-Aufbewahrungsfrist an T3 übertragen.

Verwalten der Kosten für kurzlebige Tabellen¶

CDP ist darauf ausgelegt, Ihre Daten langfristig zu schützen. Diese Daten werden normalerweise in permanenten Tabellen gespeichert. Sofern zum Zeitpunkt der Erstellung nichts anderes angegeben ist, werden Tabellen in Snowflake als permanent erstellt.

Während eines ETL- oder Datenmodellierungsprozesses können Tabellen erstellt werden, die nur kurzzeitig benötigt werden. Für diese Tabellen ist es nicht sinnvoll, die Speicherkosten von CDP zu tragen. Snowflake bietet zwei separate Konzepte zur Unterstützung kurzlebiger Tabellen:

Temporäre Tabellen
Transiente Tabellen

Temporäre Tabellen¶

Ähnlich wie andere SQL-Datenbanken existiert eine temporäre Tabelle nur innerhalb einer einzelnen Benutzersitzung und nur für die Dauer der Sitzung. Temporäre Snowflake-Tabellen sind nicht in Fail-safe und haben eine Time Travel-Aufbewahrungsfrist von nur 0 oder 1 Tag. Die Time Travel-Frist endet jedoch, wenn die Tabelle gelöscht wird.

Die maximalen CDP-Gesamtkosten für eine temporäre Tabelle betragen somit 1 Tag (oder weniger, wenn die Tabelle explizit oder aufgrund der Beendigung der Sitzung gelöscht wird). Während dieser Zeit kann Time Travel auf der Tabelle ausgeführt werden.

Wichtig

Eine Verbindung und eine Sitzung sind verschiedene Konzepte in Snowflake. Wenn Sie bei Snowflake angemeldet sind, können eine oder mehrere Sitzungen erstellt werden. Eine Snowflake-Sitzung wird nur beendet, wenn der Benutzer die Sitzung explizit beendet oder die Sitzung aufgrund von Inaktivität nach 4 Stunden abgelaufen ist. Das Trennen der Verbindung zu Snowflake führt nicht zu einer Beendigung der aktiven Sitzungen. Eine Snowflake-Sitzung kann daher sehr langlebig sein, und temporäre Tabellen, die in dieser Sitzung erstellt wurden, bleiben solange bestehen, bis sie gelöscht werden oder die Sitzung beendet wird.

Um unerwartete Speicherkosten für temporäre Tabellen zu vermeiden, empfiehlt Snowflake, diese nach Bedarf in einer Sitzung zu erstellen und sie zu löschen, sobald sie nicht mehr benötigt werden.

Transiente Tabellen¶

Transiente Tabellen sind eine Besonderheit von Snowflake. Diese Tabellen haben Eigenschaften sowohl von permanenten als auch von temporären Tabellen:

Im Gegensatz zu temporären Tabellen sind transiente Tabellen keiner Sitzung zugeordnet. Sie sind für alle Benutzer sichtbar, die über Zugriffsberechtigungen für diese Tabelle verfügen. Ähnlich wie bei permanenten Tabellen bleiben sie auch nach der Sitzung bestehen, in der sie erstellt wurden.
Wie auch temporäre Tabellen bieten transiente Tabellen kein Fail-safe und eine Time Travel-Aufbewahrungsfrist von nur 0 oder 1 Tag.

Daher fallen für transiente Tabelle CDP-Gebühren von maximal 1 Tag an. Während dieser Zeit kann Time Travel auf der Tabelle ausgeführt werden.

Verwalten der Kosten für große Tabellen mit hoher Änderungsrate¶

Bei Tabellen auf Datenplattformen handelt es normalerweise um Fakten- oder Dimensions-Tabellen, die unterschiedliche Nutzungsmuster und daher unterschiedliche Speicheranforderungen aufweisen:

Faktentabellen sind normalerweise sehr groß und weisen eine geringe Änderungsrate auf (Zeilenaktualisierung oder -löschung). Bei den meisten Änderungen an Faktentabellen handelt es sich um Einfügeaktionen für neue Daten oder in einigen Fällen um die Löschung älterer Daten. Für Faktentabellen ist CDP ist, da sie vollständigen Datenschutz bei sehr geringen Speicherkosten bietet.
Dimensionstabellen haben ein anderes Aktualisierungsmuster. Zeilenaktualisierungen und -löschungen sind in Dimensionstabellen viel häufiger. Wenn eine oder mehrere Zeilen einer Tabelle aktualisiert oder gelöscht werden, beginnen die zugrunde liegenden Mikropartitionen, in denen diese Daten gespeichert sind, mit den Lebenszyklusübergängen von CDP. Bei Dimensionstabellen mit hoher Änderungsrate kann der resultierende Speicher für Time Travel- und Fail-safe-Daten viel größer sein als der aktive Tabellenspeicher.

Für die überwiegende Mehrheit der Dimensionstabellen sind die mit diesen Aktualisierungen verbundenen CDP-Speicherkosten angemessen. Dimensionstabellen sind in der Regel klein, und wenn sie auch häufig aktualisiert werden, sind die Kosten für die Speicherung in Snowflake günstig, und die Vorteile von CDP überwiegen bei Weitem die Kosten.

Bei einigen größeren Tabellen mit hoher Änderungsrate können die mit CDP verbundenen Speicherkosten erheblich sein. Wenn mehrere Aktualisierungen an einer Tabelle vorgenommen werden, werden alle betroffenen Mikropartitionen neu erstellt und durchlaufen dann den CDP-Speicherlebenszyklus.

Dimensionstabellen mit hoher Änderungsrate können durch Berechnen des Verhältnisses von FAILSAFE_BYTES dividiert durch ACTIVE_BYTES in der Ansicht TABLE_STORAGE_METRICS ermittelt werden. Jede Tabelle mit einem großen Verhältnis wird als Tabelle mit hoher Änderungsrate betrachtet. Da der Speicherplatz in Snowflake kostengünstig ist und die meisten Tabellen mit hoher Änderungsrate insgesamt nur wenig Speicherplatz verbrauchen, ist die bevorzugte Option, diese Tabellen als permanent zu erstellen und die Daten mit CDP zu schützen.

In einigen Fällen sind die Speicherkosten für Dimensionstabellen mit hoher Änderungsrate übermäßig hoch, und Sie könnten eine alternative Option zu CDP bevorzugen. Als extremes Beispiel betrachten wir eine Tabelle mit Zeilen, die jeder Mikropartition innerhalb der Tabelle zugeordnet sind (bestehend aus 200 GB physischem Speicher). Wenn jede Zeile 20 Mal am Tag aktualisiert wird, verbraucht die Tabelle den folgenden Speicher:

Aktiv:

200 GB

Time Travel:

4 TB

Fail-safe:

28 TB

Gesamtspeicher:

32,2 TB

Bei großen Dimensionstabellen mit hoher Änderungsrate, die übermäßig hohe CDP-Kosten verursachen, besteht die Lösung darin, diese Tabellen transient und ohne Time Travel-Aufbewahrung zu erstellen (d. h. DATA_RETENTION_TIME_IN_DAYS=0) und dann diese Tabellen regelmäßig in eine permanente Tabelle zu kopieren. Dadurch wird effektiv eine vollständige Sicherung dieser Tabellen erstellt. Da jedes Backup durch CDP geschützt ist, kann das alte Backup beim Erstellen eines neuen Backups gelöscht werden.

Unter Verwendung des obigen Beispiels wären die Speicherkosten für die 200-GB-Tabelle mit hoher Änderungsrate, die einmal täglich gesichert wird, wie folgt:

Aktiv:

200 GB

Time Travel:

200 GB

Fail-safe:

1,4 TB

Backup:

200 GB

Gesamtspeicher:

2 TB

Tipp

Die Sicherungen sollten so oft wie nötig durchgeführt werden, um eine vollständige Wiederherstellung bei Datenverlust sicherzustellen. Für diese Tabellen empfiehlt Snowflake, dass Sicherungen mindestens einmal täglich durchgeführt werden.