Optimisation des coûts¶
Cette rubrique aborde les moyens d’optimiser Snowflake pour réduire les coûts et optimiser vos dépenses.
Optimisation des coûts des services Cloud¶
Si vous constatez que votre utilisation des services Cloud est plus élevée que prévu, vérifiez si votre utilisation de Snowflake suit l’un des modèles suivants. Chaque modèle comprend une recommandation qui peut vous aider à réduire les coûts associés aux services Cloud.
Modèle : requêtes bloquées en raison de verrous de transactions
Modèle : commandes SHOW à haute fréquence (par des applications de données et des outils tiers)
Modèle : insertions d’une seule ligne et schémas fragmentés (par les applications de données)
- Modèle : requêtes bloquées en raison de verrous de transactions
Les commandes de mise à jour et de fusion placent un verrou de transaction sur une table, ce qui empêche les autres commandes de s’exécuter sur cette table jusqu’à ce que le verrou soit libéré. Les requêtes consomment des crédits de services Cloud dans l’attente de la libération d’un verrou. Plus les requêtes restent longtemps sur la couche de services Cloud à attendre le verrouillage, plus elles consomment de crédits.
Recommandation : les verrous de transaction se produisent souvent lorsque des utilisateurs exécutent des commandes concurrentes de mise à jour/fusion sur une même table, en particulier lorsque chaque commande ne met à jour que quelques lignes. Vous pouvez réduire ces verrous en utilisant une commande par lot plutôt que des mises à jour individuelles. Dans le cadre de cette stratégie, vous procédez comme suit :
Utilisez une instruction INSERT par lot pour charger de nouvelles données dans une table temporaire. Évitez d’utiliser une insertion à une seule ligne. Même les appels API qui chargent de nouvelles données en continu doivent être conçus de manière à soumettre des insertions par lots plutôt que des insertions à une seule ligne.
Utilisez la table temporaire pour mettre à jour/fusionner la table de destination.
Si la source envoie de nouvelles données en continu tout au long de la journée, envisagez d’utiliser une tâche pour mettre à jour la table de destination de manière périodique.
- Modèle : commandes de copie peu sélectives
L’exécution des commandes de copie consiste à répertorier les fichiers d’Amazon Simple Storage Service (S3). Étant donné que répertorier des fichiers n’utilise que le calcul des services Cloud, l’exécution de commandes de copie peu sélectives peut entraîner une utilisation élevée des services Cloud.
Recommandation : envisagez de modifier la structure de votre compartiment S3 pour y inclure une sorte de préfixe de date, afin de ne répertorier que les fichiers ciblés dont vous avez besoin.
- Modèle : opérations DDL à haute fréquence et clonage
Les opérations en langage de définition de données (DDL), en particulier le clonage, sont entièrement des opérations de métadonnées, ce qui signifie qu’elles n’utilisent que le calcul des services Cloud. La création ou la suppression fréquente de schémas ou de tables de grande taille, ou le clonage de bases de données à des fins de sauvegarde, peuvent entraîner une utilisation importante des services Cloud.
Recommandation : le clonage n’utilise qu’une fraction des ressources nécessaires pour effectuer des copies profondes, vous devriez donc continuer à cloner. Vérifiez vos modèles de clonage pour vous assurer qu’ils sont aussi granulaires que possible et qu’ils ne sont pas exécutés trop fréquemment. Par exemple, vous pouvez souhaiter cloner uniquement des tables individuelles plutôt qu’un schéma entier.
- Modèle : fréquence élevée, requêtes simples
La consommation de services Cloud par une simple requête est négligeable, mais l’exécution de requêtes telles que
SELECT 1
,SELECT sequence1.NEXTVAL
ouSELECT CURRENT_SESSION()
à une fréquence extrêmement élevée (des dizaines de milliers de fois par jour) peut entraîner une utilisation importante des services Cloud.Recommandation : vérifiez la fréquence de vos requêtes et déterminez si elle est adaptée à votre cas d’utilisation. Si vous observez une fréquence élevée de requêtes
SELECT CURRENT_SESSION()
provenant d’outils partenaires utilisant le pilote JDBC, confirmez que le partenaire a mis à jour son code pour utiliser la méthodegetSessionId()
dans l’interface SnowflakeConnection. Cela permet de tirer parti de la mise en cache et de réduire l’utilisation des services Cloud.
- Modèle : requêtes INFORMATION_SCHEMA à haute fréquence
Les requêtes portant sur Schéma d’information de Snowflake ne consomment que les ressources des services Cloud. La consommation de services Cloud par une seule requête sur les vues INFORMATION_SCHEMA peut être négligeable, mais l’exécution de ces requêtes à une fréquence extrêmement élevée (des dizaines de milliers de fois par jour) peut entraîner une utilisation importante des services Cloud.
Recommandation : vérifiez la fréquence de vos requêtes et déterminez si elle est adaptée à votre cas d’utilisation. Vous pouvez également interroger une vue dans le schéma ACCOUNT_USAGE au lieu d’une vue INFORMATION_SCHEMA. L’interrogation du schéma ACCOUNT_USAGE utilise un entrepôt virtuel plutôt que des services Cloud.
- Modèle : commandes SHOW à haute fréquence (par des applications de données et des outils tiers)
Les commandes SHOW sont entièrement des opérations de métadonnées, ce qui signifie qu’elles ne consomment que des ressources de services Cloud. Ce modèle se produit généralement lorsque vous avez créé une application basée sur Snowflake qui exécute des commandes SHOW à une fréquence élevée. Ces commandes peuvent également être lancées par des outils tiers.
Recommandation : vérifiez la fréquence de vos requêtes et déterminez si elle est adaptée à votre cas d’utilisation. Dans le cas d’outils partenaires, contactez votre partenaire pour savoir s’il a l’intention d’adapter son utilisation.
- Modèle : insertions d’une seule ligne et schémas fragmentés (par les applications de données)
Snowflake n’étant pas un système OLTP, les insertions d’une seule ligne sont sous-optimales et peuvent consommer d’importantes ressources de services Cloud.
La création d’une application de données qui définit un schéma par client peut entraîner plusieurs charges de données dans un laps de temps donné, ce qui peut se traduire par une forte consommation de services Cloud.
Ce modèle se traduit également par un nombre beaucoup plus important de métadonnées que Snowflake doit maintenir, et les opérations sur les métadonnées consomment des ressources des services Cloud. Chaque opération sur les métadonnées consomme individuellement des ressources minimes, mais la consommation peut être importante dans l’ensemble.
Recommandation : en général, il est préférable d’effectuer des chargements par lots ou en masse plutôt que des insertions d’une seule ligne.
L’utilisation d’un schéma partagé est nettement plus efficace, ce qui permet de réduire les coûts. Vous voudrez probablement regrouper toutes les tables sur
customer_ID
et utiliser des vues sécurisées.
- Modèle : requêtes SQL complexes
Les requêtes peuvent consommer beaucoup de calcul de services Cloud si elles comprennent un grand nombre de jointures/produits cartésiens, si elles utilisent l’opérateur IN avec de grandes listes ou s’il s’agit de requêtes très volumineuses. Ces types de requêtes ont tous des durées de compilation élevées.
Recommandation : passez en revue vos requêtes pour confirmer qu’elles font ce que vous voulez qu’elles fassent. Snowflake prend en charge ces requêtes et ne vous facturera que les ressources consommées.