Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Ansicht TABLE_STORAGE

Die Ansicht INFORMATION_SCHEMA.TABLE_STORAGE bietet einen aktuellen Snapshot der Speichernutzung für Tabellen und materialisierte Ansichten. Wenn Sie die Ansicht INFORMATION_SCHEMA.TABLE_STORAGE abfragen, wird im Ergebnis jede Tabelle oder materialisierte Ansicht für das aktuelle Projekt in einer eigenen Zeile dargestellt.

Die Daten in der Ansicht INFORMATION_SCHEMA.TABLE_STORAGE werden nicht in Echtzeit gespeichert und Aktualisierungen werden in der Regel um einige Sekunden bis zu einigen Minuten verzögert. Speicheränderungen, die nur durch den Partitions- oder Tabellenablauf oder durch Änderungen am Dataset-Zeitreisefenster verursacht werden, können bis zu einem Tag dauern, bis sie in der INFORMATION_SCHEMA.TABLE_STORAGE-Ansicht angezeigt werden. Wenn ein Dataset mit mehr als 1.000 Tabellen gelöscht wird,wird die Änderung in dieser Ansicht erst angezeigt, wenn das Zeitreisefenster für das gelöschte Dataset abgelaufen ist.

Mit Tabellenspeicheransichten können Sie Ihren aktuellen Speicherverbrauch mühelos beobachten und sehen, ob Ihr Speicher logische unkomprimierte Byte, physische komprimierte Byte oder Zeitreise-Byte verwendet. Diese Informationen können Ihnen bei Aufgaben wie der Planung des zukünftigen Wachstums und dem Verständnis der Aktualisierungsmuster für Tabellen helfen.

In den `*_BYTES`-Spalten enthaltene Daten

Die *_BYTES-Spalten in den Tabellenspeicheransichten enthalten Informationen zur Verwendung der Speicherbyte. Diese Informationen werden anhand der Speichernutzung für materialisierte Ansichten und der folgenden Tabellentypen bestimmt:

Permanente Tabellen, die mit einer der unter Tabellen erstellen und verwenden beschriebenen Methoden erstellt wurden.
Temporäre Tabellen, die in Sitzungen erstellt wurden. Diese Tabellen werden in Datasets mit generierten Namen wie "_c018003e063d09570001ef33ae401fad6ab92a6a" platziert.
Temporäre Tabellen, die in Abfragen mit mehreren Anweisungen ("Scripts") erstellt wurden. Diese Tabellen werden in Datasets mit generierten Namen wie "_script72280c173c88442c3a7200183a50eeeaa4073719" platziert.

Im Abfrageergebnissecache gespeicherte Daten werden Ihnen nicht in Rechnung gestellt und sind daher nicht in den *_BYTES-Spaltenwerten enthalten.

Klone und Snapshots zeigen *_BYTES-Spaltenwerte so an, als wären sie vollständige Tabellen. Sie zeigen also nicht die Differenz zum von der Basistabelle verwendeten Speicher an, sodass es zu einer Überschätzung kommt. In Ihrer Rechnung wird diese Differenz bei der Speichernutzung korrekt berücksichtigt. Weitere Informationen zu den von Klonen und Snapshots gespeicherten und abgerechneten Deltabyte finden Sie in der Ansicht TABLE_STORAGE_USAGE_TIMELINE.

Abrechnung von Speicherprognosen

Um die monatliche Speicherabrechnung für ein Dataset zu schätzen, können Sie je nach verwendetem Dataset-Speicherabrechnungsmodell die logical- oder physical *_BYTES-Spalte in dieser Ansicht verwenden. Beachten Sie, dass dies nur eine grobe Schätzung ist. Die genauen Abrechnungsbeträge werden anhand der Nutzung durch die BigQuery-Speicherabrechnungsinfrastruktur berechnet und sind in Cloud Billing sichtbar.

Für Datasets, die ein logisches Abrechnungsmodell verwenden, können Sie Ihre monatlichen Speicherkosten so schätzen:

((ACTIVE_LOGICAL_BYTES-Wert / POW(1024, 3)) * Preis für aktive logische Byte) + ((LONG_TERM_LOGICAL_BYTES-Wert / POW(1024, 3)) * Preis für langfristige logische Byte)

Der ACTIVE_LOGICAL_BYTES-Wert einer Tabelle spiegelt die aktiven Byte wider, die derzeit von dieser Tabelle verwendet werden.

Für Datasets, die ein physisches Abrechnungsmodell verwenden, können Sie Ihre Speicherkosten so schätzen:

((ACTIVE_PHYSICAL_BYTES + FAIL_SAFE_PHYSICAL_BYTES-Wert / POW(1024, 3)) * Preis für aktive physische Byte) + ((LONG_TERM_PHYSICAL_BYTES-Wert / POW (1024, 3)) * Preis für langfristige physische Byte)

Der ACTIVE_PHYSICAL_BYTES-Wert einer Tabelle spiegelt die aktuell von dieser Tabelle verwendeten aktiven Byte plus die Byte wider, die für die Zeitreise für diese Tabelle verwendet werden.

Wenn Sie nur die aktiven Byte der Tabelle sehen möchten, subtrahieren Sie den TIME_TRAVEL_PHYSICAL_BYTES-Wert vom ACTIVE_PHYSICAL_BYTES-Wert.

Weitere Informationen finden Sie unter Speicherpreise.

Bytewerte im Vergleich zu Abrechnungseinheiten

Die *_BYTES-Spalten in den INFORMATION_SCHEMA.TABLE_STORAGE-Ansichten bieten einen Snapshot Ihres aktuellen Speicherverbrauchs in Byte. Daran können Sie ablesen, wie viele Daten Sie zu diesem Zeitpunkt speichern.

Die Abrechnung für BigQuery-Speicher, wie sie in Ihren Cloud Billing-Berichten angezeigt wird, basiert jedoch nicht nur auf dieser momentanen Größe. Stattdessen wird die Abrechnung anhand der im Laufe der Zeit gespeicherten Datenmenge berechnet. Die Standardabrechnungseinheiten sind GiB-Monat oder TiB-Monat.

Wenn Sie beispielsweise 1 GiB für einen vollen Kalendermonat speichern, ergibt sich eine Nutzung von 1 GiB-Monat, unabhängig davon, ob der Monat 28 bis 31 Tage hat. Ebenso wird die Speicherung von Daten für nur einen Teil des Monats anteilig berechnet. Das Speichern von 31 GiB für einen einzelnen Tag in einem Monat mit 31 Tagen entspricht etwa 1 GiB-Monat. Das Speichern von 28 GiB für einen einzelnen Tag in einem Monat mit 28 Tagen entspricht ebenfalls etwa 1 GiB-Monat.

Die Bytewerte in INFORMATION_SCHEMA.TABLE_STORAGE sind zwar wichtige Eingaben für die Schätzung potenzieller Kosten, Ihre tatsächliche Rechnung spiegelt jedoch die kontinuierliche Berechnung von (bytes stored * duration stored) wider. Die Werte aus dieser Ansicht stimmen voraussichtlich nicht direkt mit den Positionen in Ihrem Abrechnungsbericht überein, die über den Abrechnungszeitraum aggregiert werden.

Ausführliche Informationen zur Berechnung der Speicherkosten finden Sie auf der Seite Speicherpreise.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle BigQuery Metadata Viewer (roles/bigquery.metadataViewer) für das Projekt zuzuweisen. Diese Rolle enthält die Berechtigungen, die Sie zum Abfragen der Ansicht INFORMATION_SCHEMA.TABLE_STORAGE benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierte Rolle enthält die Berechtigungen, die zum Abfragen der Ansicht INFORMATION_SCHEMA.TABLE_STORAGE erforderlich sind. Erweitern Sie den Abschnitt Erforderliche Berechtigungen, um die erforderlichen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Zum Abfragen der Ansicht INFORMATION_SCHEMA.TABLE_STORAGE sind die folgenden Berechtigungen erforderlich:

bigquery.tables.get
bigquery.tables.list

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Schema

Die Ansicht INFORMATION_SCHEMA.TABLE_STORAGE hat das folgende Schema:

Spaltenname	Datentyp	Wert
`project_id`	`STRING`	Die Projekt-ID des Projekts, das das Dataset enthält.
`project_number`	`INT64`	Die Nummer des Projekts, das das Dataset enthält.
`table_catalog`	`STRING`	Die Projekt-ID des Projekts, das das Dataset enthält.
`table_schema`	`STRING`	Der Name des Datasets, das die Tabelle oder materialisierte Ansicht enthält (auch als `datasetId` bezeichnet).
`table_name`	`STRING`	Der Name der Tabelle oder materialisierten Ansicht (auch als `tableId` bezeichnet)
`creation_time`	`TIMESTAMP`	Der Erstellungszeitpunkt der Tabelle.
`total_rows`	`INT64`	Die Gesamtzahl der Zeilen in der Tabelle oder der materialisierten Ansicht.
`total_partitions`	`INT64`	Die Anzahl der vorhandenen Partitionen in der Tabelle oder der materialisierten Ansicht. Nicht partitionierte Tabellen geben 0 zurück.
`total_logical_bytes`	`INT64`	Gesamtzahl der logischen (unkomprimierten) Byte in der Tabelle oder materialisierten Ansicht.
`active_logical_bytes`	`INT64`	Anzahl der logischen (unkomprimierten) Byte, die jünger als 90 Tage sind.
`long_term_logical_bytes`	`INT64`	Anzahl der logischen (unkomprimierten) Byte, die älter als 90 Tage sind.
`current_physical_bytes`	`INT64`	Gesamtzahl der physischen Byte für den aktuellen Speicher der Tabelle über alle Partitionen hinweg.
`total_physical_bytes`	`INT64`	Gesamtzahl der physischen (komprimierten) Byte, die für die Speicherung verwendet werden, einschließlich aktiver, langfristiger und zeitübergreifender physischer Byte (gelöschte oder geänderte Daten) Bytes. Ausfallsichere Byte (gelöschte oder geänderte Daten, die nach dem Zeitreisefenster aufbewahrt werden) sind nicht enthalten.
`active_physical_bytes`	`INT64`	Anzahl der physischen (komprimierten) Byte unter 90 Tagen, einschließlich zeitübergreifender physischer Byte (gelöschte oder geänderte Daten).
`long_term_physical_bytes`	`INT64`	Anzahl der physischen (komprimierten) Byte, die älter als 90 Tage sind.
`time_travel_physical_bytes`	`INT64`	Anzahl der physischen (komprimierten) Byte, die vom Zeitreisespeicher verwendet wurden (gelöschte oder geänderte Daten).
`storage_last_modified_time`	`TIMESTAMP`	Der Zeitpunkt, zu dem Daten in die Tabelle geschrieben wurden. Gibt `NULL` zurück, wenn keine Daten vorhanden sind.
`deleted`	`BOOLEAN`	Gibt an, ob die Tabelle gelöscht wird.
`table_type`	`STRING`	Der Typ der Tabelle. Beispiel: `BASE TABLE`.
`managed_table_type`	`STRING`	Diese Spalte befindet sich in der Vorabversion. Der verwaltete Typ der Tabelle. Beispiel: `NATIVE` oder `BIGLAKE`.
`fail_safe_physical_bytes`	`INT64`	Anzahl der physischen (komprimierten) Byte, die vom ausfallsicheren Speicher verwendet werden (gelöschte oder geänderte Daten).
`last_metadata_index_refresh_time`	`TIMESTAMP`	Die Uhrzeit der letzten Aktualisierung des Metadatenindexes der Tabelle.
`table_deletion_reason`	`STRING`	Grund für das Löschen der Tabelle, wenn das Feld `deleted` „true“ ist. Folgende Werte sind möglich: Tabelle „`TABLE_EXPIRATION:`“ nach Ablauf der festgelegten Frist gelöscht `DATASET_DELETION:` Dataset von Nutzer gelöscht Tabelle „`USER_DELETED:`“ wurde vom Nutzer gelöscht
`table_deletion_time`	`TIMESTAMP`	Der Zeitpunkt, zu dem die Tabelle gelöscht wurde.

Aus Gründen der Stabilität empfehlen wir, Spalten in Ihren Informationsschemaabfragen explizit aufzulisten, anstatt einen Platzhalter (SELECT *) zu verwenden. Durch das explizite Auflisten von Spalten wird verhindert, dass Abfragen fehlschlagen, wenn sich das zugrunde liegende Schema ändert.

Bereich und Syntax

Für Abfragen dieser Ansicht muss ein Regions-Qualifier verwendet werden. In der folgenden Tabelle wird der Regionsbereich für diese Ansicht erläutert:

Ansichtsname	Ressourcenbereich	Regionsbereich
[`PROJECT_ID`.]`region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE[_BY_PROJECT]	Projektebene	`REGION`

Dabei gilt:

Optional: PROJECT_ID: die ID Ihres Google Cloud -Projekts. Wenn keine Angabe erfolgt, wird das Standardprojekt verwendet.
REGION: ist ein beliebiger Dataset-Regionsname. Beispiel: `region-us`

Hinweis: Zum Abfragen von INFORMATION_SCHEMA-Ansichten müssen Sie einen Regions-Qualifier verwenden. Der Ort der Abfrageausführung muss mit der Region der Ansicht INFORMATION_SCHEMA übereinstimmen.

Im folgenden Beispiel wird gezeigt, wie Speicherinformationen für Tabellen in einem bestimmten Projekt und einer bestimmten Region zurückgegeben werden:

SELECT * FROM `myProject`.`region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE;

Im folgenden Beispiel wird gezeigt, wie Speicherinformationen für Tabellen im aktuellen Projekt in einer bestimmten Region zurückgegeben werden:

SELECT * FROM `region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE_BY_PROJECT;

Beispiele

Beispiel 1:

Das folgende Beispiel zeigt die Gesamtzahl der logischen Byte, die für das aktuelle Projekt in Rechnung gestellt werden.

SELECT
  SUM(total_logical_bytes) AS total_logical_bytes
FROM
  `region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE;

Das Ergebnis sieht etwa so aus:

+---------------------+
| total_logical_bytes |
+---------------------+
| 971329178274633     |
+---------------------+

Beispiel 2:

Im folgenden Beispiel werden verschiedene Speicherbytes in GiB auf Dataset-Ebene für das aktuelle Projekt angezeigt.

SELECT
  table_schema AS dataset_name,
  -- Logical
  SUM(total_logical_bytes) / power(1024, 3) AS total_logical_gib,
  SUM(active_logical_bytes) / power(1024, 3) AS active_logical_gib,
  SUM(long_term_logical_bytes) / power(1024, 3) AS long_term_logical_gib,
  -- Physical
  SUM(total_physical_bytes) / power(1024, 3) AS total_physical_gib,
  SUM(active_physical_bytes) / power(1024, 3) AS active_physical_gib,
  SUM(active_physical_bytes - time_travel_physical_bytes) / power(1024, 3) AS active_no_tt_physical_gib,
  SUM(long_term_physical_bytes) / power(1024, 3) AS long_term_physical_gib,
  SUM(time_travel_physical_bytes) / power(1024, 3) AS time_travel_physical_gib,
  SUM(fail_safe_physical_bytes) / power(1024, 3) AS fail_safe_physical_gib
FROM
  `region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE
WHERE
  table_type ='BASE TABLE'
GROUP BY
  table_schema
ORDER BY
  dataset_name

Beispiel 3:

Das folgende Beispiel zeigt, wie Sie die Preisdifferenz pro Dataset zwischen logischen und physischen Abrechnungsmodellen für die nächsten 30 Tage prognostizieren. In diesem Beispiel wird davon ausgegangen, dass die zukünftige Speichernutzung in den nächsten 30 Tagen ab dem Zeitpunkt der Abfrage konstant ist. Beachten Sie, dass die Prognose auf Basistabellen beschränkt ist und alle anderen Tabellentypen innerhalb eines Datasets ausschließt.

Die in den Preisvariablen für diese Abfrage verwendeten Preise gelten für die Region us-central1. Wenn Sie diese Abfrage für eine andere Region ausführen möchten, aktualisieren Sie die Preisvariablen entsprechend. Preisinformationen finden Sie unter Speicherpreise.

Öffnen Sie in der Google Cloud Console die Seite „BigQuery“.

Zur Seite "BigQuery"

Geben Sie im Feld Abfrageeditor die folgende GoogleSQL-Abfrage ein. Für INFORMATION_SCHEMA muss die GoogleSQL-Syntax verwendet werden. GoogleSQL ist in der Google Cloud Console die Standardsyntax.

DECLARE active_logical_gib_price FLOAT64 DEFAULT 0.02;
DECLARE long_term_logical_gib_price FLOAT64 DEFAULT 0.01;
DECLARE active_physical_gib_price FLOAT64 DEFAULT 0.04;
DECLARE long_term_physical_gib_price FLOAT64 DEFAULT 0.02;

WITH
 storage_sizes AS (
   SELECT
     table_schema AS dataset_name,
     -- Logical
     SUM(IF(deleted=false, active_logical_bytes, 0)) / power(1024, 3) AS active_logical_gib,
     SUM(IF(deleted=false, long_term_logical_bytes, 0)) / power(1024, 3) AS long_term_logical_gib,
     -- Physical
     SUM(active_physical_bytes) / power(1024, 3) AS active_physical_gib,
     SUM(active_physical_bytes - time_travel_physical_bytes) / power(1024, 3) AS active_no_tt_physical_gib,
     SUM(long_term_physical_bytes) / power(1024, 3) AS long_term_physical_gib,
     -- Restorable previously deleted physical
     SUM(time_travel_physical_bytes) / power(1024, 3) AS time_travel_physical_gib,
     SUM(fail_safe_physical_bytes) / power(1024, 3) AS fail_safe_physical_gib,
   FROM
     `region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE_BY_PROJECT
   WHERE total_physical_bytes + fail_safe_physical_bytes > 0
     -- Base the forecast on base tables only for highest precision results
     AND table_type  = 'BASE TABLE'
     GROUP BY 1
 )
SELECT
  dataset_name,
  -- Logical
  ROUND(active_logical_gib, 2) AS active_logical_gib,
  ROUND(long_term_logical_gib, 2) AS long_term_logical_gib,
  -- Physical
  ROUND(active_physical_gib, 2) AS active_physical_gib,
  ROUND(long_term_physical_gib, 2) AS long_term_physical_gib,
  ROUND(time_travel_physical_gib, 2) AS time_travel_physical_gib,
  ROUND(fail_safe_physical_gib, 2) AS fail_safe_physical_gib,
  -- Compression ratio
  ROUND(SAFE_DIVIDE(active_logical_gib, active_no_tt_physical_gib), 2) AS active_compression_ratio,
  ROUND(SAFE_DIVIDE(long_term_logical_gib, long_term_physical_gib), 2) AS long_term_compression_ratio,
  -- Forecast costs logical
  ROUND(active_logical_gib * active_logical_gib_price, 2) AS forecast_active_logical_cost,
  ROUND(long_term_logical_gib * long_term_logical_gib_price, 2) AS forecast_long_term_logical_cost,
  -- Forecast costs physical
  ROUND((active_no_tt_physical_gib + time_travel_physical_gib + fail_safe_physical_gib) * active_physical_gib_price, 2) AS forecast_active_physical_cost,
  ROUND(long_term_physical_gib * long_term_physical_gib_price, 2) AS forecast_long_term_physical_cost,
  -- Forecast costs total
  ROUND(((active_logical_gib * active_logical_gib_price) + (long_term_logical_gib * long_term_logical_gib_price)) -
     (((active_no_tt_physical_gib + time_travel_physical_gib + fail_safe_physical_gib) * active_physical_gib_price) + (long_term_physical_gib * long_term_physical_gib_price)), 2) AS forecast_total_cost_difference
FROM
  storage_sizes
ORDER BY
  (forecast_active_logical_cost + forecast_active_physical_cost) DESC;

Klicken Sie auf Ausführen.