Globalement, partitionner et clusteriser, ça sert un peu à la même chose oui : optimiser les coûts et les temps de réponse.

Mais pour plus de détails :

Partitionnement:

Dans l’arrière-boutique, BigQuery crée autant de tables que de partitions

Les avantages :

• C’est facile de calculer le gain : tu ne scannes que les partitions nécessaires à la requête

• Implication : si tu filtres sur une date qui n’existe pas en bdd, ça te coutera 0€.

• C’est pratique pour gérer des remplacement ou des expirations de partitions. (il y a des fonctions pour ça)

Les inconvénients :

• On ne peut partitionner que par une unique colonne, de type Date(time) ou Integer

• Un nombre max de partition à 10000, ce qui empêche de partitionner par heure sur un long historique de données par exemple

• C’est généralement recommandé de ne pas faire trop de petites partitions pour éviter un overhead

Clustering:

BigQuery garde ses données dans la même table, mais co-locate les données ayant le même hash de ses colonnes de clustering

Les avantages :

• Tu es libre d’avoir plusieurs colonnes, ça peut être n’importe quel type de colonne

Les inconvénients :

• Gain moins prédictible à l’avance, ça va dépendre du plan d’exécution de BigQuery.

• J’ai pas testé, mais trop en mettre devrait être contre-productif je pense

Sur ****, dans l’exemple pris, les cd_type_produit = 4 représente environ 3% de l’ensemble des validations, d’où la grande efficacité du clustering, surtout combiné au partitonnement.

J’ai refait le test aujourd’hui :

SELECT cd_type_produit, dt_validation FROM prod_dwh.dim_validation_terrain;

-> 84.38Go

SELECT cd_type_produit, dt_validation FROM prod_dwh.dim_validation_terrain WHERE cd_type_produit = '4';

-> 9.05Go

SELECT cd_type_produit, dt_validation FROM prod_dwh.dim_validation_terrain WHERE dt_validation = '2025-11-11';

-> 41.45Mo

SELECT cd_type_produit, dt_validation FROM prod_dwh.dim_validation_terrain WHERE cd_type_produit = '4' AND dt_validation = '2025-11-11';

-> 9.17Mo