Optimiser la communication entre les emplacements

Lors de l'évaluation de votre débit de communication, tenez compte de la quantité de données brassées qu'exige votre requête. Combien d'octets sont transmis entre les étapes et à chaque emplacement ? Par exemple, une clause GROUP BY transmet des valeurs analogues au même emplacement pour le traitement. La quantité de données brassées a une incidence directe sur le débit de communication et, par conséquent, sur les performances des requêtes.

Les bonnes pratiques présentées ci-dessous vous aideront à mieux contrôler la communication entre les emplacements.

Réduisez les données avant d'utiliser une clause JOIN

Bonne pratique : Réduisez la quantité de données traitées avant une clause JOIN.

Réduisez les données le plus tôt possible dans la requête, avant que celle-ci n'exécute une clause JOIN. Si vous le faites au début du cycle de traitement, le brassage et d'autres opérations complexes ne seront exécutés que sur les données dont vous avez besoin.

Ne considérez pas les clauses WITH comme des instructions préparées

Bonne pratique : Utilisez les clauses WITH principalement pour la lisibilité.

Les clauses WITH sont avant tout utilisées pour la lisibilité, car elles ne sont pas matérialisées. Par exemple, le fait de placer toutes vos requêtes dans des clauses WITH, puis d'exécuter un opérateur UNION ALL constitue un usage abusif de la clause WITH. Si une requête apparaît dans plusieurs clauses WITH, elle s'exécute dans chacune d'elles.

Évitez les tables segmentées par date

Bonne pratique : Utilisez des tables partitionnées par période plutôt que des tables segmentées par date (également appelées tables nommées par date).

Les tables partitionnées offrent de meilleures performances que les tables nommées par date. Lorsque vous créez des tables segmentées par date, BigQuery doit conserver une copie du schéma et des métadonnées pour chacune de ces tables. De plus, leur utilisation peut obliger BigQuery à valider les autorisations pour chaque table interrogée. Cette pratique peut également alourdir le traitement des requêtes et affecter leurs performances.

Évitez de trop segmenter les tables

Bonne pratique : Évitez de créer trop de segments dans vos tables. Si vous segmentez des tables par date, utilisez plutôt des tables partitionnées par période.

La segmentation des tables consiste à diviser de grands ensembles de données en tables séparées et à ajouter un suffixe à chaque nom de table. Si vous segmentez des tables par date, utilisez plutôt des tables partitionnées par période.

En raison du faible coût du stockage BigQuery, vous n’avez pas besoin d’optimiser vos tables comme vous le feriez dans un système de base de données relationnelle. La création d'un grand nombre de segments a un impact négatif sur les performances qui l'emporte sur les avantages en termes de coûts.

Avec des tables segmentées, BigQuery doit gérer le schéma, les métadonnées et les autorisations pour chaque segment. En raison de la charge supplémentaire que cela représente, une segmentation excessive peut affecter les performances des requêtes.

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

Envoyer des commentaires concernant…

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