Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Rapid Cache

Cette page décrit Rapid Cache, une fonctionnalité qui fournit un cache de lecture zonal basé sur SSD pour les buckets Cloud Storage. Elle peut augmenter le débit et réduire la latence de vos données stockées. Rapid Cache fournit une capacité de stockage et une bande passante qui évoluent automatiquement en fonction de vos besoins. Rapid Cache est un service entièrement géré qui renvoie toujours des données cohérentes.

Rapid Cache est utile pour améliorer les performances des charges de travail à forte intensité de lecture et réduire les coûts réseau. Pour en savoir plus, consultez Avantages.

Consultez Créer et gérer des caches pour savoir comment créer et gérer des caches à l'aide de Rapid Cache.

Comment fonctionne Rapid Cache ?

Rapid Cache vous permet de créer des caches dans la même zone que vos charges de travail. Lorsque vous créez un cache dans une zone, les requêtes de lecture de données provenant de la zone sont traitées par le cache au lieu du bucket. Chaque cache dessert les clients situés dans la même zone que le cache.

Les données d'un bucket sont ingérées dans un cache lorsqu'elles sont lues par une VM résidant dans la même zone que le cache. Si vous configurez le comportement d'ingestion lors de l'écriture, les données sont également ingérées dans le cache lorsqu'elles sont écrites dans le bucket.

Les métadonnées ne sont pas mises en cache. Les requêtes de métadonnées d'objet sont toujours traitées par le bucket au lieu du cache.

Pour en savoir plus sur l'ingestion de données dans un cache, consultez Ingestion de données. Vous pouvez configurer le Time to Live (TTL) et le comportement ingest-on-write d'un cache lorsque vous le créez ou le mettez à jour.

Avantages

Lorsque vous mettez vos données en cache avec Rapid Cache, vous bénéficiez des avantages suivants :

Accès plus rapide aux données : Rapid Cache colocalise vos données dans la même zone que vos ressources de calcul et repose entièrement sur des disques SSD. Cela permet à vos charges de travail d'obtenir un débit allant jusqu'à 2,5 To/s et de réduire la latence pour des lectures plus rapides.
Réduction des frais de transfert de données multirégionaux : les données lues à partir du cache sont facturées avec des frais de transfert de données réduits par rapport aux données lues directement depuis un bucket multirégional.
Réduction des frais de récupération : les frais de récupération pour les buckets de stockage Nearline, Coldline et Archive ne s'appliquent pas aux lectures de données à partir du cache.
Réduction des coûts des opérations de lecture : les opérations de lecture exécutées depuis Rapid Cache sont facturées à moindre coût par rapport aux opérations de classe B exécutées à partir d'un bucket dans le stockage standard.
Mise à l'échelle automatique de la taille de votre cache : la mise en cache des disques SSD dynamiques de Rapid Cache s'adapte automatiquement en fonction de l'utilisation, sans que vous ayez besoin de spécifier une taille.
Utilisation efficace des caches : vous pouvez activer Rapid Cache sur les buckets existants sans avoir à modifier vos applications ni vos API. Les données stockées dans Rapid Cache sont fortement cohérentes.

Pour en savoir plus, consultez les tarifs de Rapid Cache. Pour en savoir plus sur les quotas, consultez Quotas Rapid Cache.

Quand utiliser Rapid Cache ?

Utilisez Rapid Cache pour les données qui sont rarement modifiées et fréquemment lues afin d'accélérer la lecture des données pour les charges de travail d'analyse, ainsi que l'entraînement et le chargement des modèles d'IA/ML.

Imaginons que vous entraîniez un modèle d'IA sur plusieurs nœuds Google Kubernetes Engine, qui lisent tous à plusieurs reprises les données stockées dans vos buckets Cloud Storage et s'exécutent dans la même zone. Lorsque vous créez un cache dans la zone où s'exécute votre charge de travail, le cache fournit une bande passante supplémentaire et vous aide à réduire les frais de transfert de données liés à la lecture de données dans des buckets multirégionaux. Vous pouvez ainsi exécuter des charges de travail plus importantes et à plus grande échelle de manière plus efficace.

Autoscaling de la taille du cache et de la limite de bande passante

Rapid Cache fournit une capacité de stockage et une bande passante temporaires qui évoluent automatiquement en fonction de la quantité de données stockées dans un cache.

La limite de bande passante du cache commence à 100 Gbit/s et évolue à raison de 20 Gbit/s par 1 Tio de données stockées. Vous pouvez augmenter la bande passante de départ ou la limite de bande passante totale en augmentant la quantité de données stockées dans le cache, en créant davantage de caches dans une zone ou en contactant votre responsable de compte technique ou votre représentant Google.

Pour en savoir plus sur les limites de taille et de bande passante pour Rapid Cache, consultez Quotas et limites pour Cloud Storage.

Mettre en cache des données dans des zones

Lorsque vous créez un cache pour un bucket, il doit être créé dans une zone située dans l'emplacement de votre bucket. Par exemple, si votre bucket se trouve dans la région us-east1, vous pouvez créer un cache dans us-east1-b, mais pas dans us-central1-c. Si votre bucket se trouve dans l'emplacement birégional ASIA, vous pouvez créer un cache dans n'importe quelle zone des régions asia-east1 et asia-southeast1.

Pour chaque bucket, vous pouvez créer au maximum un cache par zone. Par exemple, si un bucket est situé dans la région us-east1, vous pouvez créer un cache dans us-east1-b et un autre dans us-east1-c. Si un bucket se trouve dans un emplacement multirégional qui englobe us-central1 et us-east1, vous pouvez créer un cache dans us-central1-a et un autre dans us-east1-b.

Vous pouvez créer des caches dans des zones tant que la capacité est disponible pour la zone. Si la capacité de création d'un cache n'est pas disponible, Rapid Cache continue d'essayer de créer un cache jusqu'à ce que la capacité devienne disponible ou que le processus de création soit annulé par l'utilisateur. Il est possible que la capacité reste indisponible pendant une longue période.

Vous pouvez utiliser Rapid Cache dans les zones suivantes. Ces zones peuvent être utilisées en fonction du type d'emplacement de votre bucket.

Asie

Le tableau suivant indique les zones et les types de lieux disponibles pour Rapid Cache dans la zone géographique Asie.

Nom de la zone	Régional	Birégional	Multirégional	Birégional personnalisé
`asia-east1-a`
`asia-east1-b`
`asia-east1-c`
`asia-northeast1-a`
`asia-northeast1-b`
`asia-northeast1-c`
`asia-south1-a`
`asia-south1-b`
`asia-south1-c`
`asia-southeast1-a`
`asia-southeast1-b`
`asia-southeast1-c`

Europe

Le tableau suivant indique les zones et les types de lieux disponibles pour Rapid Cache dans la zone géographique Europe.

Nom de la zone	Régional	Birégional	Multirégional	Birégional personnalisé
`europe-north1-a`
`europe-north1-b`
`europe-north1-c`
`europe-west1-b`
`europe-west1-c`
`europe-west1-d`
`europe-west3-a`
`europe-west3-b`
`europe-west3-c`
`europe-west4-a`
`europe-west4-b`
`europe-west4-c`
`europe-west4-ai1a` (zone d'IA)
`europe-west6-a`
`europe-west6-b`

États-Unis

Le tableau suivant indique les zones et les types de lieux disponibles pour Rapid Cache dans la zone géographique des États-Unis.

Nom de la zone	Régional	Birégional	Multirégional	Birégional personnalisé
`us-central1-a`
`us-central1-b`
`us-central1-c`
`us-central1-f`
`us-central1-ai1a` (zone d'IA)
`us-east1-b`
`us-east1-c`
`us-east1-d`
`us-east4-a`
`us-east4-b`
`us-east4-c`
`us-east5-a`
`us-east5-b`
`us-east5-c`
`us-south1-a`
`us-south1-b`
`us-south1-c`
`us-south1-ai1b` (zone d'IA)
`us-west1-a`
`us-west1-b`
`us-west1-c`
`us-west2-a`
`us-west3-a`
`us-west3-b`
`us-west3-c`
`us-west4-a`
`us-west4-b`
`us-west4-c`

Ingestion de données pour les caches

Par défaut, les données sont ingérées dans un cache après avoir été demandées pour la première fois.

Comme le cache est vide lorsque cette requête initiale arrive, les données ne peuvent pas encore être trouvées dans le cache. Cela entraîne un échec initial du cache, où le système récupère les données à partir du bucket Cloud Storage sous-jacent. Lorsque le système fournit ces données récupérées à l'utilisateur, il les ingère simultanément dans le cache.

Une fois cette première requête terminée, les données résident dans le cache, ce qui permet de répondre à toutes les lectures suivantes directement à partir du cache en tant que succès de cache à grande vitesse. Ce comportement réduit considérablement la latence de lecture et accélère la récupération des données. Les données ingérées résident dans le cache jusqu'à l'expiration de leur TTL, après quoi elles sont supprimées du cache.

Pour éviter complètement la lenteur de la requête initiale, vous pouvez configurer le cache pour ingérer les données lors de l'écriture en plus de l'ingestion des données après la première lecture.

Ingérer des données sous forme de blocs

Lors de l'ingestion de données dans un cache, Rapid Cache divise les objets en blocs plus petits de taille fixe. La fragmentation des objets permet une mise en cache plus précise, en particulier pour les fichiers volumineux dont seules certaines parties sont consultées.

Un bloc est un bloc de données de 2 Mo. Lorsqu'une requête est effectuée pour un objet, le cache rapide identifie les blocs de 2 Mo qui couvrent la plage d'octets demandée et gère ces blocs de manière indépendante.

Le comportement d'ingestion des données diffère selon la taille de l'objet ingéré dans le cache :

Pour les requêtes de lecture d'objets de plus de 2 Mo, seuls les blocs contenant la plage d'octets demandée sont ingérés. Par exemple, si vous lisez le premier Mo d'un fichier de 100 Mo, seul le premier bloc de 2 Mo est ingéré.
Pour les requêtes de lecture d'objets de moins de 2 Mo (par exemple, une image de 500 Ko), l'intégralité de l'objet est ingérée dans le cache.

Ingérer les données lors de l'écriture

Lorsque vous activez l'ingestion des données dans un cache lors de l'écriture, les données sont ingérées dans le cache au moment où elles sont écrites dans le bucket. Ce comportement peut être activé en plus du comportement de mise en cache par défaut, qui consiste à ingérer les données après la lecture initiale.

La fonctionnalité d'ingestion lors de l'écriture élimine les défauts de cache initiaux et permet à votre charge de travail de bénéficier d'un succès de cache (hit) immédiat dès la première lecture des données. L'ingestion de données lors de l'écriture accélère les charges de travail de lecture après écriture, comme la restauration des points de contrôle du système ou la préparation des pipelines de données pour l'entraînement des modèles.

Vous pouvez activer un cache pour ingérer des données en écriture lorsque vous créez ou mettez à jour le cache. Vous pouvez configurer un cache pour ingérer tous les objets écrits dans un bucket (également appelé "ingestion au niveau du bucket lors de l'écriture") ou ingérer de manière sélective les objets écrits dans le bucket sous un dossier géré spécifié (également appelé "ingestion au niveau du préfixe lors de l'écriture").

Par exemple, supposons que vous activiez un cache pour effectuer une ingestion à l'écriture au niveau du préfixe pour les objets du bucket my-bucket dont le nom comporte le préfixe red/. Vous importez ensuite trois objets dans my-bucket : les objets red/my-dog.png, blue/my-cat.png et red/my-goldfish.png. Par conséquent, seuls les objets red/my-dog.png et red/my-goldfish.png sont ingérés dans le cache lors de leur importation dans my-bucket.

Lorsque vous configurez l'ingestion à l'écriture au niveau du préfixe à l'aide de certains outils (comme la consoleGoogle Cloud ), un dossier géré est automatiquement créé pour vous si vous spécifiez un préfixe qui n'est pas le nom d'un dossier géré existant. Toutefois, lorsque vous utilisez l'API JSON, vous devez créer manuellement le dossier géré et appliquer les paramètres ingestOnWrite pour chaque zone de cache. Vous trouverez les instructions pour activer ou désactiver l'ingestion lors de l'écriture à l'aide de chaque outil dans Utiliser le cache rapide.

Pour savoir comment activer ou désactiver l'ingestion à l'écriture au niveau du bucket ou du préfixe lorsque vous utilisez l'API JSON, développez la section Comprendre comment activer l'ingestion à l'écriture. Les informations de cette section ne concernent principalement que l'API JSON. D'autres outils, tels que la consoleGoogle Cloud , masquent certains paramètres pour faciliter l'activation et la gestion de l'ingestion à l'écriture.

Comprendre comment activer l'ingestion lors de l'écriture

Cette section vous aide à comprendre les paramètres de l'API JSON à utiliser pour activer l'ingestion à l'écriture pour tous les objets écrits dans un bucket, ou uniquement pour certains objets écrits dans le bucket sous un préfixe de dossier géré.

Deux paramètres permettent de contrôler si un cache ingère des données lors de l'écriture pour tous les objets d'un bucket ou uniquement pour certains objets sous un préfixe :

L'activation de l'ingestion à l'écriture au niveau du bucket est obtenue à l'aide du champ ingestOnWrite d'une ressource de cache. Le champ se présente comme suit :
```
{
"zone": "us-east1-a",
"ttl": "24h",
"ingestOnWrite": true
}
```
- Si la valeur est définie sur true, l'ingestion à l'écriture est activée pour tous les objets écrits dans le bucket. Cela remplace tous les paramètres au niveau des dossiers gérés qui activent l'ingestion à l'écriture pour des objets sélectifs par préfixe.
- Si la valeur est définie sur false, l'ingestion à l'écriture est désactivée pour les objets à l'échelle du bucket. Ce paramètre permet d'activer l'ingestion à l'écriture pour des objets spécifiques par préfixe via les paramètres des dossiers gérés.
L'activation de l'ingestion à l'écriture au niveau du préfixe s'effectue à l'aide de dossiers gérés, qui représentent des préfixes de chemin d'accès se terminant par une barre oblique (par exemple, my-prefix/). Lorsque l'ingestion à l'écriture au niveau du préfixe est activée, un cache ingère sélectivement les objets à l'écriture uniquement si l'objet comporte le préfixe dans son nom.

L'ingestion à l'écriture au niveau du préfixe est contrôlée par le champ ingestOnWrite du mappage rapidCacheConfig.policies dans une ressource de dossier géré. Une instance de cache doit exister pour pouvoir être spécifiée dans le mappage rapidCacheConfig.policies.

Le mappage rapidCacheConfig.policies d'un dossier géré se présente comme suit :
```
"rapidCacheConfig": {
  "policies": {
    "us-east1-a": {
      "rapidCacheId": "us-east1-a",
      "ingestOnWrite": "unspecified"
    }
    "us-east1-b": {
      ...,
      ...
    }
  }
}
```
- Les instances de cache spécifiées dans le mappage policies doivent déjà exister pour que l'ingestion à l'écriture au niveau du préfixe fonctionne. Par exemple, pour spécifier rapidCacheId: "us-east1-a" dans le mappage policies, vous devez d'abord disposer d'un cache pour la zone us-east1-a.
- Vous pouvez mettre à jour plusieurs instances de cache spécifiées dans le mappage policies en un seul appel d'API.
- Si ingestOnWrite est défini sur enabled, l'ingestion à l'écriture est activée pour tous les objets écrits dans le bucket sous ce préfixe de dossier géré. L'ingestion à l'écriture au niveau du préfixe ne peut être activée que si le champ ingestOnWrite de la ressource de cache est défini sur false.
- Si la valeur est définie sur unspecified (par défaut), l'activation de l'ingestion à l'écriture est héritée de la ressource parente immédiate, qui peut être un dossier géré parent ou le bucket contenant le dossier géré lui-même.
- Tous les caches non spécifiés dans le mappage des règles sont traités comme si leur paramètre ingestOnWrite était défini sur unspecified.

Vous trouverez ci-dessous un résumé de la procédure à suivre pour configurer vos ressources de cache et de dossiers gérés afin d'activer ou de désactiver l'ingestion à l'écriture au niveau du bucket ou du préfixe :

Activer l'ingestion au moment de l'écriture au niveau du bucket (mais pas au niveau du préfixe)
- Configuration : définissez le champ ingestOnWrite de la ressource de cache sur true.
- Comportement : l'ingestion à l'écriture est activée pour tous les objets écrits dans le bucket. Ce paramètre au niveau du bucket remplace toutes les configurations gérées au niveau du dossier (ce qui signifie que les configurations sélectives au niveau du préfixe sont ignorées).
Activer l'ingestion à l'écriture au niveau du préfixe (mais pas au niveau du bucket)
- Configuration :
  1. Définissez le champ ingestOnWrite de la ressource de cache sur false.
  2. Configurez un mappage policies valide (non nul) dans la ressource du dossier géré.
  3. Définissez le champ ingestOnWrite du dossier géré sur enabled (ou sur unspecified s'il s'agit d'un dossier enfant héritant de enabled d'un dossier géré parent activé).
- Comportement : l'ingestion à l'écriture ne se produit que pour les objets écrits sous des préfixes de dossiers gérés correspondants.
Activer l'ingestion à l'écriture au niveau du préfixe sur les dossiers gérés parents et enfants

Il n'est pas possible d'activer l'ingestion à l'écriture pour les dossiers gérés enfants sans l'activer également pour le dossier géré parent.
Désactiver l'ingestion à l'écriture pour le bucket et le préfixe
- Configuration :
  1. Définissez le champ ingestOnWrite de la ressource de cache sur false.
  2. Définissez tous les champs ingestOnWrite des dossiers gérés sur unspecified, en vous assurant qu'aucun champ ingestOnWrite des dossiers gérés parents n'est défini sur enabled.
    
    Vous pouvez également ne configurer aucune règle en laissant la carte policies null ou en omettant complètement la configuration rapidCacheConfig.
- Comportement : l'ingestion à l'écriture est désactivée à l'échelle mondiale pour le bucket et tous les préfixes.

Lorsque vous activez l'ingestion à l'écriture au niveau du préfixe sur un dossier géré parent, elle est activée pour tous les dossiers gérés enfants imbriqués sous le dossier géré parent. Pour en savoir plus sur la façon dont les ressources héritent de l'activation et de la désactivation de l'ingestion à l'écriture, développez la section Fonctionnement de l'héritage de l'ingestion à l'écriture.

Fonctionnement de l'héritage d'ingestion lors de l'écriture

Lorsqu'un dossier géré n'active pas explicitement l'ingestion à l'écriture (lorsque le champ ingestOnWrite du dossier géré est défini sur unspecified), le comportement d'ingestion à l'écriture du cache est hérité de la ressource parente du dossier géré, qu'il s'agisse du bucket ou d'un dossier géré parent.

Lorsque vous utilisez l'ingestion à l'écriture au niveau du préfixe, le paramètre d'ingestion à l'écriture que vous configurez sur un dossier géré parent est hérité par tous les dossiers gérés enfants.

Prenons les exemples suivants :

Vous disposez d'un dossier géré a/ dont la ressource parente est le bucket my-bucket.
Vous disposez d'un dossier géré a/b/ dont la ressource parente est le dossier géré a/ dans my-bucket.

Lorsqu'un objet nommé a/b/info.txt est écrit, Rapid Cache évalue la hiérarchie de configuration de haut en bas :

Vérifiez le dossier géré immédiat : si a/b/ est défini sur enabled, l'ingestion à l'écriture au niveau du préfixe est activée pour les objets écrits sous a/b/. Si a/b/ est défini sur unspecified, Rapid Cache vérifie la ressource parente immédiate, qui est le dossier géré a/.
Vérifiez le dossier géré parent : si a/ est défini sur enabled, l'ingestion au moment de l'écriture au niveau du préfixe est activée pour a/ et a/b/. Si a/ est défini sur unspecified, Rapid Cache vérifie le bucket parent.
Vérifiez le paramètre ingestOnWrite au niveau du cache du bucket : si le champ ingestOnWrite du cache est défini sur true, l'ingestion à l'écriture au niveau du bucket est activée et remplace tout dossier géré pour lequel l'ingestion à l'écriture au niveau du préfixe est configurée. Si le champ ingestOnWrite du cache est défini sur false et que le champ ingestOnWrite des dossiers gérés parent et enfant est défini sur unspecified, l'ingestion à l'écriture est désactivée pour les objets du bucket qui se trouvent dans les dossiers gérés parent et enfant. Dans ce scénario, s'il n'y a pas d'autres dossiers gérés dans le bucket avec l'ingestion à l'écriture configurée, l'ingestion à l'écriture est désactivée pour tous les objets du bucket.

Valeur TTL (Time To Live)

La valeur TTL d'un cache détermine la durée pendant laquelle les données restent dans le cache avant d'être supprimées. La valeur TTL correspond à la durée pendant laquelle les données restent dans le cache après la dernière lecture. Par exemple, si la valeur TTL est définie sur 24 heures, un fragment de données qui a été lu pour la dernière fois le lundi à 11h et qui n'a pas été lu depuis sera supprimé du cache le mardi à 11h.

Vous pouvez définir le TTL d'un cache lorsque vous le créez ou le mettez à jour. Vous pouvez définir la valeur TTL d'un cache sur une valeur comprise entre 24 heures et 7 jours (inclus). Si aucune valeur n'est spécifiée, la valeur TTL est de 24 heures par défaut.

Opérations de cache

Cette section décrit les opérations que vous pouvez effectuer sur les caches Rapid Cache. Certaines opérations sont asynchrones et renvoient une opération de longue durée, tandis que d'autres sont synchrones, où les opérations sont effectuées immédiatement et renvoient une ressource AnywhereCache.

Créer un cache

Vous pouvez définir l'emplacement, la durée de vie (TTL) et le comportement d'ingestion des données d'un cache lorsque vous créez le cache. Le cache passe à l'état EN COURS DE CRÉATION pendant sa création, puis à l'état EN COURS D'EXÉCUTION lorsqu'il devient actif. La création du cache peut prendre jusqu'à 48 heures, après quoi l'opération expire.

L'API AnywhereCaches Create est asynchrone. Une opération de création entraîne le renvoi d'une opération de longue durée. L'opération de longue durée fournit l'état de l'opération de création et vous permet de l'annuler avant qu'elle ne soit terminée.

Mettre à jour un cache

Vous pouvez définir la valeur TTL ou le comportement d'ingestion de données d'un cache lorsque vous le mettez à jour. Vous ne pouvez mettre à jour que les caches dont l'état est EN COURS D'EXÉCUTION. Il est impossible de mettre à jour un cache dont l'état est EN COURS DE CRÉATION ou DÉSACTIVÉ.

Lorsqu'un cache est en cours de mise à jour, le champ pending_update est défini sur la valeur true. Tant que le champ pending_update affiche la valeur true, le cache ne peut plus être mis à jour. Lorsque la valeur TTL d'un cache a fini d'être mise à jour, la nouvelle valeur TTL s'applique immédiatement aux données existantes et nouvelles du cache.

L'API AnywhereCaches Update est asynchrone et renvoie une opération de longue durée.

Obtenir un cache

Lorsque vous obtenez un cache, Rapid Cache renvoie l'état et la configuration de l'instance de cache. L'API AnywhereCaches Get est synchrone et renvoie une ressource AnywhereCache.

Lister les caches

Vous pouvez renvoyer une liste des caches associés pour un bucket donné. L'API AnywhereCaches List est synchrone et compatible avec la pagination.

Désactiver un cache

Vous pouvez désactiver un cache pour le supprimer définitivement de la configuration de votre bucket. Lorsque vous désactivez un cache, il passe à l'état DÉSACTIVÉ. Dans cet état, vous pouvez toujours lire les données existantes du cache, mais vous ne pouvez pas en ingérer de nouvelles.

Après avoir désactivé un cache, vous disposez d'un délai de grâce d'une heure pendant lequel vous pouvez annuler la désactivation en réactivant le cache. Passé ce délai de grâce d'une heure, le cache est supprimé. Lorsque le cache est supprimé, toutes les données qu'il contient sont supprimées et le cache est retiré du bucket.

Pendant l'heure précédant la suppression du cache, vous pouvez rétablir l'état DÉSACTIVÉ en réactivant le cache, qui reprend alors l'état EN COURS D'EXÉCUTION.

L'API AnywhereCaches Disable est synchrone et renvoie une ressource AnywhereCache.

Réactiver un cache

Vous pouvez reprendre les caches qui affichent l'état DÉSACTIVÉ, à condition que le cache désactivé soit compris dans le délai de grâce d'une heure. Après le délai de grâce d'une heure, l'opération de reprise est effectuée au mieux de ses capacités, car le cache peut être supprimé à tout moment après le délai de grâce. Une fois qu'un cache a été repris, il passe à l'état EN COURS D'EXÉCUTION.

L'API AnywhereCaches Resume est synchrone et renvoie une ressource AnywhereCache.

Outil de recommandation Rapid Cache

L'outil de recommandation Rapid Cache fournit des recommandations et des insights pour créer des caches dans des paires zone/bucket en analysant votre consommation des données et votre stockage. Pour obtenir des informations générales et des instructions sur l'utilisation de l'outil de recommandation Rapid Cache, consultez Outil de recommandation Rapid Cache.

Utiliser le cache rapide pour accélérer les lectures pour BigQuery

Rapid Cache peut être utilisé pour diffuser des données pour les demandes de lecture d'objets émises par BigQuery. En utilisant Rapid Cache, vous pouvez accélérer la lecture des données pour vos applications tout en optimisant l'efficacité des coûts.

Bien que BigQuery soit un service régional, ses ressources de calcul sous-jacentes peuvent parfois passer d'une zone à une autre pour l'équilibrage de charge. En guise de bonne pratique, activez le cache Rapid pour une charge de travail BigQuery dans toutes les zones d'une région afin de vous assurer qu'un cache est disponible en cas de changement de zone des ressources de calcul sous-jacentes. Si un cache dans une zone n'est pas utilisé, il n'entraîne aucun coût supplémentaire, car Rapid Cache est un service à la demande. Notez que si les ressources d'une charge de travail changent de zone, le cache de la nouvelle zone devra réingérer les données, ce qui peut entraîner une augmentation ponctuelle des coûts d'ingestion de données.

Chiffrement des données mises en cache

Les données sont stockées dans le cache au format chiffré côté serveur d'origine, ce qui assure la compatibilité avec les options de chiffrement compatibles avec Cloud Storage.

Limites et restrictions

Pour supprimer un bucket, vous devez d'abord supprimer tous les caches associés. La seule exception concerne la suppression d'un bucket à l'aide de la console Google Cloud , qui supprime tous les caches associés en même temps que le bucket.
Lorsque vous créez, désactivez, reprenez ou mettez à jour des caches, limitez le nombre d'opérations à une par seconde. Si vous effectuez plusieurs opérations par seconde, des échecs peuvent se produire.
Rapid Cache n'est pas un stockage durable. Les données peuvent être supprimées du cache dans différents scénarios. Par exemple, le cache peut être redimensionné automatiquement pour garantir que des ressources suffisantes sont disponibles pour vos charges de travail. Dans ce scénario, certaines données peuvent être évincées selon un algorithme dit du "moins récemment utilisé" (LRU, least recently used) jusqu'à ce que le service Rapid Cache ait fini d'augmenter la taille du cache.

Dans tous les cas, vos données restent stockées de manière sécurisée dans votre bucket source. Lorsque des données sont supprimées du cache pour des raisons autres que l'expiration de la valeur TTL, le service Rapid Cache tente de les réingérer dans le cache de manière transparente et sans frais. Si les données ne peuvent pas être réingérées de manière transparente ou ont été supprimées en raison de l'expiration de la valeur TTL, le service Rapid Cache les réingère lors de la première lecture.
Les recommandations et les insights générés par l'outil de recommandation Rapid Cache ne peuvent pas être lus à l'aide de BigQuery.

Considérations sur les performances

Échecs de récupération de blocs : si une requête couvre plusieurs blocs et que certains sont dans le cache tandis que d'autres ne le sont pas, le cache rapide récupère de manière transparente les blocs manquants à partir du bucket source.
TTL et expulsion : les règles d'expulsion TTL (Time to Live) et LRU (Least Recently Used) fonctionnent également sur les blocs. Les parties fréquemment utilisées d'un fichier volumineux peuvent rester dans le cache, tandis que les parties peu utilisées sont supprimées.

Tarifs

Pour en savoir plus, consultez les tarifs de Rapid Cache.

Contrôle des coûts

Développez les conseils suivants pour découvrir comment minimiser les coûts d'exécution des caches :

Sélection du bucket

Vous ne devez créer des caches que pour les buckets contenant les données que vous souhaitez mettre en cache.

Sélectionner la zone

Vous ne devez créer des caches que dans les zones où votre charge de travail bénéficiera de la mise en cache.

Paramètre TTL

Vous devez spécifier la valeur TTL minimale dont vous avez besoin pour stocker les données dans le cache. Vous pouvez modifier la valeur TTL sans interruption. La valeur par défaut est de 1 jour.

Désactiver le cache

Vous pouvez désactiver un cache pour le supprimer définitivement du service et arrêter l'accumulation de tous les frais de cache associés.

Résoudre les problèmes liés au manque temporaire de ressources

Les sections suivantes décrivent comment résoudre les problèmes liés au manque temporaire de ressources, lorsque la capacité de disque SSD ou de diffusion dans une zone spécifiée est insuffisante pour créer un cache, augmenter sa taille ou augmenter sa limite de bande passante.

Échec de la création d'un cache

Rapid Cache peut ne pas réussir à créer un cache dans une zone spécifique en raison d'un manque de capacité de disque SSD ou de ressources de diffusion du débit, ce qui entraîne un manque temporaire de ressources. Pendant cette période, Rapid Cache tente de créer le nouveau cache pendant 48 heures maximum. Si des ressources deviennent disponibles dans un délai de 48 heures, Rapid Cache traite la demande de création du cache. Si les ressources ne deviennent pas disponibles dans le délai de 48 heures, la requête de création du cache échoue.

Dépannage : pour éviter toute interruption de la mise en cache, vous pouvez annuler manuellement l'opération de création du cache et en créer un dans une autre zone où de la capacité est peut-être disponible. Pour surveiller ou annuler une opération de création de cache, consultez Utiliser des opérations de longue durée.

Échec de l'augmentation de la taille du cache

Rapid Cache peut ne pas parvenir à augmenter la taille d'un cache lorsque la quantité requise de capacité de disque SSD n'est pas disponible dans la zone du cache.

Bien que Rapid Cache propose des augmentations automatiques de la taille du cache à la demande, celles-ci dépendent de la disponibilité de la capacité de disque SSD. Si la capacité de disque SSD n'est pas disponible lors de la demande d'augmentation automatique de la taille du cache, Rapid Cache continue d'envoyer la demande jusqu'à ce que le manque temporaire de ressources prenne fin ou qu'une augmentation de la taille du cache ne soit plus nécessaire.

En cas de manque temporaire de ressources, de nouvelles données sont ingérées et les données existantes dans le cache sont supprimées en fonction de leur date d'utilisation la plus récente. Les caches suffisamment volumineux pour stocker la plupart des données "chaudes" n'ont que peu ou pas d'impact sur les métriques de cache. Les caches dont la capacité est inférieure à la quantité de données "chaudes" peuvent évincer des données et les réingérer plus souvent que les caches non affectés par les manques de ressources. Lorsque la taille réelle de votre cache est beaucoup plus petite que la capacité requise, vous pouvez rencontrer les problèmes suivants liés au manque de ressources :

Une limite de bande passante du cache et un débit du cache inférieurs, une consommation du quota de bande passante du transfert de données plus élevée et un impact possible sur d'autres métriques
La facturation peut être affectée de différentes manières :
- Augmentation des coûts liés aux frais d'ingestion du cache
- Réduction des coûts liés aux frais de stockage du cache
- Réduction des coûts liés aux frais de transfert de données sortantes du cache
- Réduction des coûts liés aux frais d'opération de transfert de données sortantes du cache
- Augmentation des coûts liés aux frais de transfert de données multirégionaux
- Augmentation des coûts liés à l'utilisation des opérations de classe B

Pour en savoir plus sur ces frais, consultez les tarifs de Rapid Cache.

Comment résoudre les problèmes : pour obtenir les meilleurs résultats en cas de manque temporaire de ressources, nous vous recommandons de surveiller vos caches et de désactiver les caches ou les charges de travail inutiles en fonction de vos besoins.

Échec du scaling à la hausse de la limite de bande passante d'un cache

Une insuffisance temporaire de la limite de bande passante du cache peut se produire lors d'une augmentation de la taille du cache lorsque les ressources de diffusion du débit dans une zone spécifique sont insuffisantes pour effectuer le scaling de la limite de bande passante des caches existants à 20 Gbit/s par Tio. En cas d'insuffisance de bande passante du cache, Rapid Cache ne permet pas à la limite de bande passante du cache d'évoluer à 20 Gbit/s par Tio de données, mais le cache continue de répondre aux requêtes de lecture. Pour demander plus de bande passante de cache, contactez votre responsable de compte technique ou votre représentant Google. En cas d'insuffisance de bande passante de cache disponible, vous pouvez constater peut-être une augmentation de la consommation de bande passante de sortie des données de votre bucket.

Étapes suivantes

Créez et gérez des caches.