Comprendre les coûts de Cortex Search Services¶
Catégories de coûts¶
Cortex Search Services prend en charge les types de coûts suivants :
Catégorie |
Description |
|---|---|
Calcul de l’entrepôt virtuel |
Un Cortex Search Service nécessite un entrepôt virtuel pour actualiser le service : pour exécuter des requêtes sur les objets de base lorsqu’ils sont initialisés et actualisés, y compris l’orchestration des tâches d’intégration de texte et la création de l’index de recherche. Ces opérations utilisent des ressources de calcul, qui consomment des crédits. Si aucun changement n’est identifié lors d’une actualisation, les crédits de l’entrepôt virtuel ne sont pas consommés puisqu’il n’y a pas de nouvelles données à actualiser. |
Calcul des jetons EMBED_TEXT |
Un Cortex Search Service intègre automatiquement chaque ligne de texte dans la colonne de recherche spécifiée dans le paramètre |
Calcul de service |
Un Cortex Search Service utilise un calcul de service multi-locataire, séparé d’un entrepôt virtuel fourni par l’utilisateur, pour établir un service à faible latence et à haut débit. Le coût de calcul pour cette composante est calculé par GB par mois (GB/mo) de données indexées non compressées, les données indexées étant les données fournies par l’utilisateur dans la requête source de Cortex Search, plus les intégrations vectorielles calculées pour le compte de l’utilisateur. Vous supportez ces coûts tant que le service est disponible pour répondre aux requêtes, même si aucune requête n’est servie au cours d’une période donnée. Pour connaître le taux de crédit du service Cortex Search par GB/mo de données indexées, consultez la Snowflake Service Consumption Table. |
Stockage |
Les Cortex Search Services matérialisent la requête source dans une table stockée dans votre compte. Cette table est transformée en structures de données optimisées pour un service à faible latence, également stockées dans votre compte. Le stockage pour la table et les structures de données intermédiaires est basé sur un tarif forfaitaire par téraoctet (TB). |
Calcul des services Cloud |
Les Cortex Search Services utilisent le calcul Cloud Services pour identifier les changements dans les objets de base sous-jacents et déterminer si l’entrepôt virtuel doit être invoqué. Le coût de calcul des services Cloud est soumis à la contrainte selon laquelle Snowflake ne facture que si le coût quotidien des services Cloud est supérieur à 10 % du coût quotidien de l’entrepôt pour le compte. |
Cette rubrique fournit des informations sur ces coûts, ainsi que des recommandations pour une gestion efficace de ces coûts.
Gestion des coûts d’indexation¶
Les conseils suivants peuvent vous être utiles pour gérer les coûts d’indexation d’un Cortex Search Service :
- Réduire la taille de l’entrepôt
La plupart des services ne voient pas les performances d’indexation s’améliorer au-delà d’un entrepôt LARGE et beaucoup n’ont besoin que d’un MEDIUM. La majeure partie du temps de calcul nécessaire à la création d’un index est consommée par la fonction d’intégration de texte, qui ne bénéficie pas de plus de cœurs ou de mémoire supplémentaire lorsqu’elle dispose déjà de ressources suffisantes.
- Suspendre l’indexation lorsque le niveau d’actualisation n’est pas important
Suspendez l’indexation (ou augmentez la latence cible) lorsque vous n’avez pas besoin que les modifications apportées à vos documents soient immédiatement propagées vers le service de recherche (c’est-à-dire lorsque le niveau d’actualisation n’est pas aussi importante pendant une certaine période).
- Définir une latence cible en fonction des exigences de l’entreprise
Toutes les applications de recherche ne nécessitent pas une indexation en temps réel. Une latence cible trop faible peut entraîner une actualisation plus fréquente que nécessaire de votre index. Par exemple, si vos données sources sont mises à jour toutes les cinq minutes, mais que le consommateur des données n’interroge le service de recherche qu’une fois par heure, définissez la latence cible à une heure, et non à cinq minutes.
- Regrouper des changements
Le coût d’une mise à jour est fixe, de sorte que des mises à jour moins nombreuses et plus importantes sont moins coûteuses que des mises à jour plus fréquentes et plus petites. De même, toute modification d’une valeur dans une ligne déclenche la réintégration de la colonne de recherche dans cette ligne, même si les données de cette colonne de recherche restent inchangées ; il est donc préférable d’accumuler toutes les modifications d’une ligne en une seule mise à jour.
- Réduire au minimum les modifications apportées aux données sources
Toute modification du schéma de la requête source entraîne une réactualisation complète du service, y compris l’intégration des vecteurs et les index. Lorsque vous créez un service de grande taille, pensez à inclure des colonnes de charge utile supplémentaires pour une utilisation ultérieure, de sorte que vous n’ayez pas à déclencher une actualisation complète en modifiant le schéma lorsque vous avez besoin d’ajouter une colonne. Le coût des colonnes supplémentaires est faible.
Astuce
La matérialisation des données dans une table de la requête source à l’aide d’une commande CREATE OR REPLACE entraîne l’actualisation et la réintégration complètes de tous les vecteurs par le service. Il est préférable de mettre à jour la table source de manière incrémentielle (par exemple, à l’aide de MERGE INTO).
- Veillez à ce que la requête source soit aussi simple que possible
Les jointures ou autres opérations complexes peuvent augmenter le coût de l’indexation (et il peut être préférable de les appliquer pendant ETL ou à une autre zone de préparation). Reportez-vous aux meilleures pratiques en matière de tables dynamiques pour plus d’informations sur l’optimisation des pipelines.
Gestion des coûts de service¶
Les conseils suivants peuvent vous être utiles pour gérer les coûts de service d’un Cortex Search Service :
- Suspendre le service lorsqu’il ne répond pas aux requêtes
Un service de recherche en cours d’exécution génère des coûts même s’il ne répond pas aux requêtes. Suspendez le service lorsqu’il n’est pas nécessaire, par exemple pendant le développement. La reprise d’un service suspendu ne prend généralement que quelques minutes.
Observation des coûts¶
Pour en savoir plus sur les coûts de vos services Cortex Search, utilisez les vues Account Usage suivantes.
Vue CORTEX_SEARCH_DAILY_USAGE_HISTORY contient les totaux quotidiens de l’utilisation du calcul des jetons EMBED_TEXT et du calcul des crédits de service par service. Snowflake a l’intention de fournir également l’utilisation de l’entrepôt virtuel dans cette vue à l’avenir.
Vue CORTEX_SEARCH_SERVING_USAGE_HISTORY comprend des crédits horaires par service.
Snowflake a l’intention de rendre ces informations disponibles dans l’interface d’administration de Cortex Search à l’avenir.
Estimation des coûts¶
Calcul des jetons EMBED_TEXT¶
Le calcul des jetons EMBED_TEXT est facturé par jeton de texte dans la colonne de recherche, par document, facturé au coût du taux de crédit du modèle d’intégration sélectionné. Ce coût de calcul est pris en charge pour chaque ligne insérée ou mise à jour, y compris pour chaque ligne de la colonne ON lors de l’initialisation du service et pour chaque insertion ou mise à jour ultérieure. Pour obtenir des informations sur le coût par jeton de chaque modèle d’intégration, voir Modèles d’intégration de Cortex Search :
Par exemple, si vous créez un service sur une requête source de 10 millions de lignes, chacune contenant 500 jetons, et que le modèle d’intégration sélectionné entraîne 0,05 crédit pour 1 million de jetons, vous devriez payer les frais suivants pour l’actualisation initiale :
(0,05 crédit par million de jetons) * (10 000 000 lignes) * (500 jetons par ligne) / (1 000 000 jetons)
= 250 crédits
Pour chaque ligne insérée ou mise à jour par la suite, vous devrez payer un coût de 0,05 crédit pour 1 million de jetons.
Astuce
À titre approximatif, un jeton équivaut à environ 3/4 d’un mot anglais, soit environ 4 caractères. Pour obtenir une estimation précise du nombre de jetons par ligne, utilisez la fonction COUNT_TOKENS avec un échantillon représentatif de vos données réelles.
Calcul de service¶
Le calcul du service est facturé par gigaoctet-mois de données indexées, les données indexées étant les données fournies par l’utilisateur dans la requête source de Cortex Search, plus les intégrations vectorielles calculées pour le compte de l’utilisateur. Il s’agit d’un coût permanent qui est pris en charge aussi longtemps que le statut de service du service est repris. Ce coût est fonction du nombre de lignes indexées, de la taille de l’ensemble des données indexées et de la dimensionnalité du modèle d’intégration vectorielle sélectionné. Pour obtenir des informations sur la dimensionnalité de chaque modèle d’intégration, voir Modèles d’intégration de Cortex Search :
Par exemple, si vous avez un service de 10 millions de lignes, que le modèle d’intégration sélectionné a une dimension de 768, que chaque ligne de la requête source fait environ 1 000 octets (y compris la colonne de recherche) et que le coût du crédit par GB/mois de données indexées est de 6,3, vous devez vous attendre à payer le coût suivant :
(6,3 crédits par GB) * (10 000 000 lignes) * (768 dimensions * 4 octets par dimension + 1 000 octets par ligne) / (1 000 000 000 octets par GB)
= 256,5 crédits mensuels
Note
La taille des données par ligne varie selon le cas d’utilisation et augmente avec la quantité de données (nombre de lignes et de colonnes) indexées par le service, indépendamment de la désignation d’une colonne en tant que colonne de recherche ou d’attribut.
Calcul d’entrepôt¶
Le coût de calcul de l’entrepôt virtuel pour Cortex Search Services peut varier en fonction du taux de changement de vos données, de la latence cible et de la taille de l’entrepôt. En général, les Cortex Search Services avec des valeurs de latence cible plus faibles et des taux de modification des données sous-jacentes plus élevés prendront en charge des coûts de calcul plus importants liés à l’entrepôt.
Astuce
Pour bien comprendre les coûts d’entrepôt liés à vos pipelines de Cortex Search, testez Cortex Search en utilisant des entrepôts dédiés afin de pouvoir isoler la consommation de l’entrepôt virtuel attribuée aux actualisations de Cortex Search. Vous pouvez déplacer votre Cortex Search Service vers un entrepôt partagé après avoir établi une base de coûts.
Stockage¶
Les Cortex Search Services ont besoin de stockage pour conserver les résultats matérialisés de la requête source, ainsi que l’index de recherche. La taille des données stockées peut être estimée en matérialisant la requête source dans une table à l’aide de la fonction de table CORTEX_SEARCH_DATA_SCAN, puis en examinant la taille de cette table.
Pour des informations détaillées sur la manière dont ce stockage engendre des coûts, voir Comprendre le coût de stockage.
Services Cloud¶
Les Cortex Search Services utilisent le calcul Cloud Services pour déclencher des actualisations lorsqu’un objet de base sous-jacent a changé. Ces coûts peuvent varier en fonction du taux de changement de vos données, de la latence cible et de la taille de l’entrepôt. Le coût des services Cloud pour le suivi des modifications dans Cortex Search tend à être moins élevé pour les cas d’utilisation présentant un faible taux de modification. Le coût de calcul des services Cloud est soumis à la contrainte selon laquelle Snowflake ne facture que si le coût quotidien des services Cloud est supérieur à 10 % du coût quotidien de l’entrepôt pour le compte.