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 par 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 (langage de manipulation de données), instructions LDD (langage de définition de données), 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 croît également.

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 ni son coût. Lorsque des blocs de données sont éliminés lors de l'exécution d'une requête, BigQuery permet de réduire au mieux les coûts de cette dernière.

Remettre automatiquement en cluster

Lorsque des données sont ajoutées à une table en cluster, les données nouvellement insérées peuvent être écrites dans des blocs contenant des plages de clés qui chevauchent celles des blocs déjà écrits. Ce chevauchement des clés affaiblit la propriété de tri de la table.

Pour préserver les caractéristiques de performance d'une table en cluster, BigQuery effectue une remise en cluster automatique en arrière-plan afin de restaurer la propriété de tri de la table. Pour les tables partitionnées, le clustering est maintenu pour les données comprises dans le champ d'application de chaque partition.

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, telles que le chargement de données dans les tables, la copie de tables et de partitions et l'exportation de données. Ces opérations sont toutefois soumises aux quotas et limites propres à BigQuery. Pour en savoir plus 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.