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.
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.
Erforderliche Rollen
Um die Berechtigungen zu erhalten, die Sie zum Abfragen der Ansicht INFORMATION_SCHEMA.TABLE_STORAGE
benötigen, müssen Sie Ihren Administrator bitten, Ihnen einen Zugriff auf die IAM-Rolle BigQuery Metadata Viewer (roles/bigquery.metadataViewer
) für das Projekt zu gewähren.
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 ID des Projekts, das das Dataset enthält. |
PROJECT_NUMBER |
INT64 |
Die Nummer des Projekts, das das Dataset enthält. |
TABLE_CATALOG |
STRING |
Die 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 |
Die Gesamtzahl der physischen Byte für den aktuellen Speicherplatz der Tabelle in allen Partitionen. |
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 (gelöschte oder geänderte Daten, die nach dem Zeitreisefenster aufbewahrt wurden) Byte 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 zeitübergreifenden physischen Speicher verwendet wurden (gelöschte oder geänderte Daten). |
STORAGE_LAST_MODIFIED_TIME |
TIMESTAMP |
Der Zeitpunkt, zu dem Daten in die Tabelle geschrieben wurden. |
DELETED |
BOOLEAN |
Gibt an, ob die Tabelle gelöscht wird. |
TABLE_TYPE |
STRING |
Der Typ der Tabelle. Beispiel: EXTERNAL oder BASE TABLE .
|
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. |
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] |
auf Projektebene | REGION |
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`
Im folgenden Beispiel wird gezeigt, wie Speicherinformationen für Tabellen in einem bestimmten Projekt zurückgegeben werden:
SELECT * FROM `myProject`.`region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE;
Im folgenden Beispiel wird gezeigt, wie Speicherinformationen für Tabellen 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:
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".
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.
Das Ergebnis sieht etwa so aus:
+--------------+--------------------+-----------------------+---------------------+------------------------+--------------------------+-----------------------------+------------------------------+----------------------------------+-------------------------------+----------------------------------+--------------------------------+ | dataset_name | active_logical_gib | long_term_logical_gib | active_physical_gib | long_term_physical_gib | active_compression_ratio | long_term_compression_ratio | forecast_active_logical_cost | forecaset_long_term_logical_cost | forecast_active_physical_cost | forecast_long_term_physical_cost | forecast_total_cost_difference | +--------------+--------------------+-----------------------+---------------------+------------------------+--------------------------+-----------------------------+------------------------------+----------------------------------+-------------------------------+----------------------------------+--------------------------------+ | dataset1 | 10.0 | 10.0 | 1.0 | 1.0 | 10.0 | 10.0 | 0.2 | 0.1 | 0.04 | 0.02 | 0.24 |