Présentation des tables en cluster

Ce document offre un aperçu de la prise en charge du clustering des tables dans BigQuery.

Présentation

Lorsque vous créez une table en cluster dans BigQuery, les données de la table sont automatiquement organisées en fonction du contenu d'une ou plusieurs colonnes du schéma de la table. Les colonnes que vous spécifiez sont utilisées pour rapprocher les données associées. Lorsque vous mettez une table en cluster à l'aide de plusieurs colonnes, l'ordre des colonnes que vous spécifiez est important. Il détermine l'ordre de tri des données.

Le clustering peut améliorer les performances de certains types de requêtes, telles que les requêtes utilisant des clauses de filtre et celles agrégeant des données. Lorsque des données sont écrites dans une table en cluster par une tâche de requête ou de chargement, BigQuery trie les données à l'aide des valeurs des colonnes de clustering. Ces valeurs permettent d'organiser les données en plusieurs blocs dans le stockage BigQuery. Lorsque vous soumettez une requête contenant une clause filtrant les données en fonction des colonnes de clustering, BigQuery utilise les blocs triés pour éviter l'analyse de données inutiles.

De même, lorsque vous soumettez une requête qui agrège des données sur la base des valeurs des colonnes de clustering, les performances sont améliorées car les blocs triés rapprochent les lignes avec des valeurs similaires.

Quand utiliser le clustering

BigQuery prend actuellement en charge le clustering sur une table partitionnée. Utilisez le clustering sur une table partitionnée lorsque :

  • vos données sont déjà partitionnées sur une colonne de date ou d'horodatage ;
  • vous utilisez couramment des filtres ou des agrégations sur des colonnes particulières de vos requêtes.

Le clustering de tables est compatible avec les tables partitionnées avec date d'ingestion et avec les tables partitionnées sur une colonne DATE ou TIMESTAMP. Actuellement, le clustering n'est pas pris en charge pour les tables non partitionnées.

Lorsque vous utilisez le clustering et le partitionnement ensemble, les données peuvent être partitionnées en fonction d'une colonne de date ou d'horodatage, puis mises en cluster sur un ensemble de colonnes différent. Dans ce cas, les données de chaque partition sont mises en cluster en fonction des valeurs des colonnes de clustering. Le partitionnement permet d'obtenir des estimations de coûts précises pour les requêtes (en fonction des partitions analysées).

Mettre en cluster des tables partitionnées

Dans une table partitionnée par une colonne de date ou d'horodatage, chaque partition contient les données d'un seul jour. Lorsque les données sont stockées, BigQuery garantit que toutes les données d'un bloc appartiennent à une même partition. Une table partitionnée conserve ces propriétés dans toutes les opérations qui la modifient : tâches de requête, instructions LMD (Data Manipulation Language), instructions DDL (Data Definition Language), tâches de chargement et tâches de copie. Cela nécessite que BigQuery gère plus de métadonnées qu'une table non partitionnée. À mesure que le nombre de partitions augmente, la quantité de métadonnées augmente.

Bien qu'il soit nécessaire de gérer davantage de métadonnées, BigQuery, en s'assurant que les données sont partitionnées globalement, peut estimer avec plus de précision la quantité d'octets traités par une requête avant qu'elle ne soit exécutée. Ce calcul des coûts permet de définir un plafond de coût final de la requête.

Dans une table en cluster, BigQuery trie automatiquement les données en fonction des valeurs des colonnes de clustering et les organise dans des blocs de stockage de taille optimale. Vous pouvez réaliser un tri plus fin en créant une table à la fois mise en cluster et partitionnée. Une table en cluster conserve les propriétés de tri dans le contexte de chaque opération qui la modifie. Par conséquent, BigQuery risque de ne pas pouvoir estimer avec précision les octets traités par la requête ou le coût de la requête. Lorsque des blocs de données sont éliminés lors de l'exécution de la requête, BigQuery permet de réduire au mieux les coûts de la requête.

Au fil du temps, alors que de plus en plus d'opérations modifient une table, le degré de tri des données commence à s'affaiblir et la table est partiellement triée. Dans une table partiellement triée, les requêtes utilisant les colonnes de clustering peuvent avoir à analyser davantage de blocs qu'avec une table entièrement triée. Vous pouvez remettre les données de la table entière en cluster en exécutant une requête SELECT * qui sélectionne et écrase des données dans la table (ou toute partition spécifique). De plus, toute partie arbitraire de la table peut être remise en cluster à l'aide de l'instruction LMD MERGE.

Quotas et limites des tables en cluster

Lorsque vous utilisez la fonctionnalité de table en cluster avec une table partitionnée, vous êtes soumis aux limites imposées sur les tables partitionnées.

Les quotas et les limites s'appliquent également aux différents types de tâches que vous pouvez exécuter sur des tables en cluster, comme par exemple :

Pour plus d'informations sur tous les quotas et limites, consultez la page Quotas et limites.

Tarifs des tables en cluster

Lorsque vous créez et utilisez des tables en cluster dans BigQuery, vos frais sont basés sur la quantité de données stockées dans les tables et sur les requêtes que vous exécutez sur les données :

  • Pour en savoir plus sur la tarification relative au stockage, consultez la section Tarifs du stockage.
  • Pour en savoir plus sur la tarification relative aux requêtes, consultez la section Tarifs des requêtes.

De nombreuses opérations sur les tables en cluster sont gratuites, comme par exemple le chargement de données dans les tables, la copie de tables et de partitions et l'exportation de données. Bien que gratuites, ces opérations sont soumises aux quotas et limites de BigQuery. Pour plus d'informations sur toutes les opérations gratuites, consultez la section Opérations gratuites sur la page des tarifs.

Pour obtenir un exemple détaillé de tarif de tables en cluster, consultez la page des Tarifs.

Fonctionnalités en cours de développement

Les fonctionnalités suivantes sont en cours de développement, mais ne sont pas encore disponibles :

  • Prise en charge du clustering pour les tables non partitionnées.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Besoin d'aide ? Consultez notre page d'assistance.