Vue TABLE_STORAGE
La vue INFORMATION_SCHEMA.TABLE_STORAGE
fournit un instantané actuel de l'utilisation du stockage pour les tables et les vues matérialisées. Lorsque vous interrogez la vue INFORMATION_SCHEMA.TABLE_STORAGE
, les résultats de la requête contiennent une ligne pour chaque table ou une vue matérialisée du projet en cours. Les données de la vue INFORMATION_SCHEMA.TABLE_STORAGE
ne sont pas conservées en temps réel et les mises à jour sont généralement retardées de quelques secondes à quelques minutes. Les modifications de stockage provoquées uniquement par l'expiration de la partition ou de la table, ou par des modifications apportées à la fenêtre de fonctionnalité temporelle de l'ensemble de données, peuvent prendre jusqu'à une journée pour être reflétées dans la vue INFORMATION_SCHEMA.TABLE_STORAGE
.
Les vues de stockage de tables vous permettent de surveiller facilement la consommation de stockage actuelle. Elles fournissent également des informations sur l'utilisation d'octets logiques non compressés, d'octets compressés physiques ou d'octets de fonctionnalité temporelle dans votre espace de stockage. Ces informations peuvent vous aider dans des tâches telles que la planification de la croissance future et la compréhension des modèles de mise à jour des tables.
Données incluses dans les colonnes *_BYTES
Les colonnes *_BYTES
des vues de stockage de tables incluent des informations sur votre utilisation des octets de stockage. Ces informations sont déterminées en examinant votre utilisation de l'espace de stockage pour les vues matérialisées et les types de tables suivants :
- Tables permanentes créées via l'une des méthodes décrites sur la page Créer et utiliser des tables
- Tables temporaires créées dans des sessions. Ces tables sont placées dans des ensembles de données ayant des noms générés comme "_c018003e063d09570001ef33ae401fad6ab92a6a".
- Tables temporaires créées dans des requêtes à plusieurs instructions ("scripts"). Ces tables sont placées dans des ensembles de données ayant des noms générés comme "_script72280c173c88442c3a7200183a50eeeaa4073719".
Les données stockées dans le cache des résultats de requête ne vous sont pas facturées et ne sont donc pas incluses dans les valeurs des colonnes *_BYTES
.
Les clones et les instantanés affichent les valeurs de la colonne *_BYTES
comme s'il s'agissait de tables complètes, plutôt que d'afficher les valeurs delta du stockage utilisé par la table de base, ce qui constitue une surestimation. Votre facture tient compte correctement de ce delta dans l'utilisation de l'espace de stockage. Pour en savoir plus sur les octets delta stockés et facturés par les clones et les instantanés, consultez la page Vue TABLE_STORAGE_USAGE_TIMELINE
.
Prévoir la facturation du stockage
Afin de prévoir la facturation mensuelle du stockage d'un ensemble de données, vous pouvez utiliser les colonnes logical
ou physical *_BYTES
de cette vue, selon le modèle de facturation du stockage des ensembles de données utilisé par l'ensemble de données. Notez qu'il ne s'agit que d'une prévision approximative. Les montants de facturation précis sont calculés en fonction de l'utilisation par l'infrastructure de facturation de l'espace de stockage BigQuery et sont visibles dans Cloud Billing.
Pour les ensembles de données qui utilisent un modèle de facturation logique, vous pouvez prévoir vos coûts de stockage mensuels comme suit :
((ACTIVE_LOGICAL_BYTES
valeur / POW
(1024, 3)) * tarification des octets logiques actifs) +
((valeur LONG_TERM_LOGICAL_BYTES
/ POW
(1024, 3)) * tarification des octets logiques à long terme)
La valeur ACTIVE_LOGICAL_BYTES
d'une table reflète les octets actifs actuellement utilisés par cette table.
Pour les ensembles de données qui utilisent un modèle de facturation physique, vous pouvez prévoir vos coûts de stockage comme suit :
((valeur ACTIVE_PHYSICAL_BYTES + FAIL_SAFE_PHYSICAL_BYTES
/ POW
(1024, 3)) * tarification des octets physiques actifs) +
((valeur LONG_TERM_PHYSICAL_BYTES
/ POW
(1024, 3)) * tarification des octets physiques à long terme)
La valeur ACTIVE_PHYSICAL_BYTES
d'une table reflète les octets actifs actuellement utilisés par cette table, ainsi que les octets utilisés pour les fonctionnalités temporelles de cette table.
Pour afficher uniquement les octets actifs de la table, soustrayez la valeur TIME_TRAVEL_PHYSICAL_BYTES
de la valeur ACTIVE_PHYSICAL_BYTES
.
Pour en savoir plus, consultez les tarifs de stockage.
Rôles requis
Pour obtenir les autorisations nécessaires pour interroger la vue INFORMATION_SCHEMA.TABLE_STORAGE
, demandez à votre administrateur de vous accorder le rôle IAM Lecteur de métadonnées BigQuery (roles/bigquery.metadataViewer
) sur le projet.
Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.
Ce rôle prédéfini contient les autorisations requises pour interroger la vue INFORMATION_SCHEMA.TABLE_STORAGE
. Pour afficher les autorisations exactes requises, développez la section Autorisations requises :
Autorisations requises
Les autorisations suivantes sont requises pour interroger la vue INFORMATION_SCHEMA.TABLE_STORAGE
:
-
bigquery.tables.get
-
bigquery.tables.list
Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.
Schéma
La vue INFORMATION_SCHEMA.TABLE_STORAGE
présente le schéma suivant :
Nom de la colonne | Type de données | Valeur |
---|---|---|
PROJECT_ID |
STRING |
ID du projet qui contient l'ensemble de données. |
PROJECT_NUMBER |
INT64 |
Numéro du projet qui contient l'ensemble de données. |
TABLE_CATALOG |
STRING |
ID du projet qui contient l'ensemble de données. |
TABLE_SCHEMA |
STRING |
Nom de l'ensemble de données qui contient la table ou la vue matérialisée, également appelé datasetId . |
TABLE_NAME |
STRING |
Nom de la table ou de la vue matérialisée, également appelé tableId . |
CREATION_TIME |
TIMESTAMP |
Horodatage de création de la table. |
TOTAL_ROWS |
INT64 |
Nombre total de lignes dans la table ou la vue matérialisée. |
TOTAL_PARTITIONS |
INT64 |
Nombre de partitions présentes dans la table ou la vue matérialisée. Les tables non partitionnées renvoient la valeur 0. |
TOTAL_LOGICAL_BYTES |
INT64 |
Nombre total d'octets logiques (non compressés) dans la table ou la vue matérialisée. |
ACTIVE_LOGICAL_BYTES |
INT64 |
Nombre d'octets logiques (non compressés) datant de moins de 90 jours. |
LONG_TERM_LOGICAL_BYTES |
INT64 |
Nombre d'octets logiques (non compressés) datant de plus de 90 jours. |
CURRENT_PHYSICAL_BYTES |
INT64 |
Nombre total d'octets physiques pour le stockage actuel de la table sur l'ensemble des partitions. |
TOTAL_PHYSICAL_BYTES |
INT64 |
Nombre total d'octets (compressés) physiques utilisés pour le stockage, y compris les octets actifs, à long terme et de fonctionnalité temporelle (données supprimées ou modifiées). Les octets sécurisés (données supprimées ou modifiées conservées après la fenêtre temporelle) ne sont pas inclus. |
ACTIVE_PHYSICAL_BYTES |
INT64 |
Nombre d'octets physiques (compressés) datant de moins de 90 jours, y compris les octets de fonctionnalité temporelle (données supprimées ou modifiées). |
LONG_TERM_PHYSICAL_BYTES |
INT64 |
Nombre d'octets physiques (compressés) datant de plus de 90 jours. |
TIME_TRAVEL_PHYSICAL_BYTES |
INT64 |
Nombre d'octets physiques (compressés) utilisés par le stockage temporel (données supprimées ou modifiées). |
STORAGE_LAST_MODIFIED_TIME |
TIMESTAMP |
Date et heure de la dernière écriture des données dans la table. |
DELETED |
BOOLEAN |
Indique si la table est supprimée ou non. |
TABLE_TYPE |
STRING |
Type de table. Par exemple, EXTERNAL ou BASE TABLE .
|
FAIL_SAFE_PHYSICAL_BYTES |
INT64 |
Nombre d'octets physiques (compressés) utilisés par le stockage sécurisé (données supprimées ou modifiées). |
LAST_METADATA_INDEX_REFRESH_TIME |
TIMESTAMP |
La dernière actualisation de l'index de métadonnées de la table. |
Champ d'application et syntaxe
Les requêtes exécutées sur cette vue doivent inclure un qualificatif de région. Le tableau suivant explique le champ d'application de la région pour cette vue :
Nom de la vue | Champ d'application de la ressource | Champ d'application de la région |
---|---|---|
[`PROJECT_ID`.]`region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE[_BY_PROJECT] |
Niveau Projet | REGION |
Facultatif : PROJECT_ID
: ID de votre projet Google Cloud. Si non spécifié, le projet par défaut est utilisé.
REGION
: tout nom de région d'ensemble de données.
Par exemple, `region-us`
.
L'exemple suivant montre comment renvoyer des informations de stockage pour les tables d'un projet spécifié :
SELECT * FROM `myProject`.`region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE;
L'exemple suivant montre comment renvoyer des informations de stockage pour les tables d'une région spécifiée :
SELECT * FROM `region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE_BY_PROJECT;
Exemples
Exemple 1 :
L'exemple suivant montre le nombre total d'octets logiques facturés pour le projet en cours.
SELECT SUM(total_logical_bytes) AS total_logical_bytes FROM `region-REGION`.INFORMATION_SCHEMA.TABLE_STORAGE;
Le résultat ressemble à ce qui suit :
+---------------------+ | total_logical_bytes | +---------------------+ | 971329178274633 | +---------------------+
Exemple 2 :
L'exemple suivant montre comment prévoir la différence de prix par ensemble de données entre les modèles de facturation logiques et physiques pour les 30 prochains jours. Dans cet exemple, nous partons du principe que l'utilisation future de l'espace de stockage est constante au cours des 30 prochains jours à compter de l'exécution de la requête. Notez que les prévisions sont limitées aux tables de base. Elles excluent tous les autres types de tables au sein d'un ensemble de données.
Les tarifs utilisés dans les variables de tarification de cette requête concernent la région us-central1
. Si vous souhaitez exécuter cette requête pour une autre région, mettez à jour les variables de tarification de manière appropriée. Pour en savoir plus, consultez les Tarifs de stockage.
Ouvrez la page BigQuery dans la console Google Cloud.
Saisissez la requête GoogleSQL suivante dans la zone Éditeur de requête.
INFORMATION_SCHEMA
requiert la syntaxe GoogleSQL. GoogleSQL est la syntaxe par défaut dans la console Google Cloud.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;
Cliquez sur Exécuter.
Le résultat se présente comme suit :
+--------------+--------------------+-----------------------+---------------------+------------------------+--------------------------+-----------------------------+------------------------------+----------------------------------+-------------------------------+----------------------------------+--------------------------------+ | 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 |