Google PCD: Données d'application, état et modèles de stockage — Guide d'étude

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Developer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Magasins opérationnels NoSQL : Firestore et Bigtable

Choisissez le modèle NoSQL qui correspond aux schémas de requête et au profil de débit.

• Firestore (document)

  • Modèle de données : les collections contiennent des documents ; les documents peuvent avoir des sous-collections. Modélisez en fonction des schémas de requête ; évitez les écritures en arborescence profonde (fan-out) sur des documents uniques « chauds ».
  • Accès et transactions : les lectures de documents et les requêtes sont fortement cohérentes (strongly consistent) en mode Natif. Utilisez les écritures par lots (batched writes) pour une atomicité « au plus une fois » sur plusieurs documents, et les transactions pour les opérations de lecture-modification-écriture avec vérification des conflits.
  • Index : les index sur un seul champ sont automatiques. Les index composites sur plusieurs champs doivent être définis lors de l’utilisation de plusieurs filtres de plage/inégalité ou d’ordres de tri. La dénormalisation est courante pour que les requêtes n’utilisent que les index.
  • Synchronisation client : les écouteurs en temps réel (listeners) diffusent les changements ; les caches hors ligne se réconcilient avec une sémantique « le dernier qui écrit gagne » (last-write-wins). Protégez-vous contre une arborescence d’écouteurs non limitée ; préférez les curseurs de requête et les filtres.
  • Limites et modes de défaillance : le taux d’écriture sur un seul document est sérialisé ; des mises à jour à QPS élevé et soutenu sur un seul document créent des conflits. Utilisez des compteurs fragmentés (sharded counters) avec N sous-documents et agrégez à la lecture.

• Cloud Bigtable (colonnes larges)

  • La conception de la clé de ligne (row-key) est primordiale. Bigtable partitionne les lignes de manière lexicographique ; les segments de début de clé déterminent le hotspotting. Évitez les clés séquentielles comme les horodatages en premier ou les ID utilisateur non fragmentés.
  • Schémas :
    • Horodatage inversé dans la clé pour les lectures de séries temporelles : key = device#hash(device_id)#reverse_ts.
    • Hachez ou segmentez le premier composant pour répartir les écritures : bucket = crc32(user_id) % 128.
  • Stockez des cellules petites et nombreuses ; évitez les lignes volumineuses qui s’étendent sur plusieurs tablettes. Tirez parti de plusieurs familles de colonnes pour le contrôle d’accès et la séparation des politiques de garbage collection (GC).
  • Débit et service :
    • Utilisez plusieurs clusters pour la réplication et la proximité de lecture régionale ; les écritures inter-clusters deviennent éventuellement cohérentes (eventually consistent).
    • Ajustez les profils d’application et le routage ; maintenez des pools de threads et des pools de canaux généreux côté client.
  • GC et TTL : le GC basé sur la version et le temps supprime les anciennes cellules de manière asynchrone ; les données persistent jusqu’au compactage, ne comptez donc pas sur une suppression immédiate pour les échéances réglementaires.

Schémas de mise en cache et de stockage d’objets

• Memorystore (Redis/Memcached)

  • Stratégies de mise en cache :
    • Read-through (lecture à travers) : l’application récupère les données du cache ; en cas d’échec (miss), elle les charge depuis la source et remplit le cache.
    • Write-through (écriture à travers) : les écritures sont effectuées de manière synchrone dans le cache et dans la source.
    • Write-behind (écriture différée) : met en tampon les écritures dans le cache et les vide de manière asynchrone ; à utiliser avec prudence en raison du risque de perte.
  • Expiration et invalidation :
    • Appliquez des TTL cohérents avec la tolérance à l’obsolescence des données. Invalidez les clés lors des changements de la source de vérité ; pour les caches d’agrégats, utilisez des clés versionnées pour éviter les ruées (stampedes).
    • Utilisez un mutex ou un mécanisme de single-flight pour empêcher les ruées sur le cache (cache stampedes) pour les clés populaires.
  • Sessions : stockez les données de session éphémères avec un TTL ; chiffrez les valeurs ou ne stockez que des jetons opaques si elles sont sensibles.
  • Limitation de débit avec Redis :
    • Fenêtre fixe (Fixed-window) : INCR avec EXPIRE sur une clé par identité.
    • Fenêtre glissante (Sliding-window) ou seau à jetons (token-bucket) pour des limites plus lisses ; envisagez des scripts Lua pour l’atomicité.
  • Disponibilité : le niveau Basic n’a pas de basculement (failover) ; le niveau Standard fournit une haute disponibilité (HA) régionale. Traitez le cache comme volatil ; jamais comme un stockage faisant autorité.

  Exemple : limitation de débit simple à fenêtre fixe

  • Commandes :
    • INCR rate:login:USER123:20260903T1000
    • EXPIRE rate:login:USER123:20260903T1000 60

• Cloud Storage

  • Objets et cohérence : cohérence forte globale (strong global consistency) pour les lectures, écritures, réécritures, suppressions et listages. Les objets sont immuables ; les mises à jour créent de nouvelles générations.
  • URL signées : déchargez les téléversements/téléchargements volumineux directement entre les clients et les buckets sans passer par votre application. Définissez des expirations courtes ; restreignez la méthode, le chemin et les en-têtes de contenu.
  • Téléversements reprenables : à utiliser pour les fichiers >5 Mo et les réseaux peu fiables ; gérez les erreurs 5xx/429 avec un backoff exponentiel tronqué et des jetons de reprise.
  • Cycle de vie : définissez des règles pour faire passer les objets d’une classe de stockage à une autre, supprimer les anciennes versions et appliquer la rétention. Combinez avec le versionnement d’objets pour la sécurité lors des déploiements.
  • Notifications : intégrez les notifications Pub/Sub pour déclencher un traitement en aval lors de la finalisation/suppression d’un objet, et incluez des préconditions (ifGenerationMatch) pour vous protéger contre les concurrences (races).

  Exemple : téléverser des fichiers locaux

  • gsutil cp ./data/*.parquet gs://my-bucket/ingest/

Migration, cohérence, partitionnement et protection des données

• Migration de base de données

  • Choisir entre une migration en ligne ou hors ligne : en ligne avec Database Migration Service pour un temps d’arrêt minimal ; hors ligne pour plus de simplicité lorsque des fenêtres de maintenance sont acceptables.
  • Schéma en premier : réconcilier les types et les contraintes ; pour Spanner, envisager des outils pour mapper les schémas et les données MySQL/PostgreSQL, puis ajuster les clés et les index pour la distribution.
  • Exécution en parallèle et basculement : pendant la migration en ligne, effectuer une double écriture ou répliquer les journaux de modifications (changelogs). Valider le nombre de lignes, les sommes de contrôle (checksums) et le comportement des requêtes critiques avant le basculement final.

• Migrations de schéma et restauration (rollback)

  • Utiliser des migrations versionnées et automatisées (par exemple, avec un outil de migration) dans le cadre du CI/CD. Concevoir des modifications additives et rétrocompatibles : ajouter des colonnes et des index, remplir les données a posteriori (backfill), déployer du code qui lit/écrit sur les deux versions, puis supprimer les artefacts obsolètes.
  • Planifier la restauration avec des transformations de données : si le déploiement du code échoue, être prêt à désactiver les nouvelles écritures et à s’appuyer sur des indicateurs de fonctionnalité (feature flags) ; éviter les migrations destructrices qui bloquent la restauration.

• Workflows transactionnels ou à cohérence à terme (eventually consistent)

  • Utiliser des transactions ACID lorsque les invariants doivent être maintenus de manière synchrone (transferts de fonds, décrémentations de stock).
  • Préférer la cohérence à terme pour les fonctionnalités principalement en lecture, orientées utilisateur, où la latence est prédominante (flux, recherche, compteurs). Implémenter des clés d’idempotence, les patrons Outbox/Saga, et des nouvelles tentatives avec backoff (intervalle exponentiel).
  • Combiner : valider l’état faisant autorité dans un stockage transactionnel ; publier des événements pour des projections à cohérence à terme.

• Partitionnement des données et gestion des connexions

  • Partitionner par locataire (tenant), géographie ou type de charge de travail pour isoler les points chauds (hotspots). Pour Bigtable et Spanner, encoder les clés de partition dans les clés primaires ; pour Cloud SQL, utiliser un schéma par locataire ou un sharding de table avec des routeurs.
  • Gérer les connexions :
    • Cloud SQL : mettre en pool et réutiliser ; plafonner la simultanéité ; échelonner les démarrages à froid.
    • Spanner : réutiliser les sessions ; préchauffer les pools au démarrage ; limiter les nouvelles tentatives.
    • Memorystore : réutiliser les connexions TCP ; éviter les connexions par requête.

• Protection des données, archivage, vérification de la restauration et comportement de suppression

  • Sauvegardes et archivage :
    • Cloud SQL : sauvegardes automatisées + restauration à un instant T (PITR) ; tester les restaurations.
    • Spanner : sauvegardes gérées ; tester la restauration dans un environnement hors production.
    • Firestore : exportations planifiées vers Cloud Storage ; vérifier les importations.
    • Bigtable : sauvegardes et instantanés (snapshots) ; tester le clonage et la restauration.
    • Cloud Storage : règles de conservation, verrouillages d’objet et accès uniforme au niveau du bucket pour la gouvernance ; archiver vers des classes de stockage plus froides via le cycle de vie.
  • Vérification de la restauration : restaurer périodiquement dans des environnements isolés et exécuter des requêtes de validation et des tests de fumée (smoke tests) applicatifs. Suivre les RTO/RPO par rapport à la politique définie.
  • Comportement de suppression :
    • Le nettoyage (GC) et le cycle de vie de Bigtable sont asynchrones — ne pas promettre un effacement immédiat.
    • Le versioning de Cloud Storage conserve les générations jusqu’à ce que le cycle de vie les supprime.
    • La suppression via TTL et par exportation dans Firestore est asynchrone.
    • Pour des SLA de suppression définitive, concevoir des processus qui marquent pour suppression, mettent en file d’attente et vérifient la suppression, avec des journaux d’audit.

Scénario de problème pratique

Aurora Outfitters migre une plateforme e-commerce monolithique vers Google Cloud. Ils doivent : 1) effectuer un lift-and-shift de MySQL pour réduire les risques, 2) gérer des téléversements de médias de produits de 500 Mo sans surcharger l’application, 3) mettre à l’échelle le débit de lecture pour les catalogues de produits, et 4) appliquer des limites de débit par utilisateur pendant les pics de vente.

Approche :

1. Migrer MySQL vers Cloud SQL avec une adresse IP privée et une haute disponibilité régionale

   • Justification : L’adresse IP privée élimine l’exposition publique et les listes d’autorisation d’IP, simplifiant la connectivité sécurisée depuis GKE et Compute Engine. La haute disponibilité régionale protège contre les pannes de zone ; s’attendre à de brèves interruptions de connexion lors du basculement, donc l’application implémentera des transactions réessayables et une logique de reconnexion.

2. Activer les sauvegardes automatisées et la restauration à un instant T (PITR), et valider la restauration

   • Justification : Les sauvegardes automatisées et les journaux de transactions permettent une restauration à un instant T suite à des erreurs d’utilisateur ou d’application. Une restauration planifiée vers une instance hors production chaque semaine vérifie que les sauvegardes sont utilisables et mesure le RTO.

3. Ajouter un réplica en lecture pour les lectures de catalogue

   • Justification : Déplacer les requêtes de catalogue vers un réplica en lecture réduit la contention sur l’instance principale. L’application lit depuis l’instance principale lorsqu’une écriture après lecture est nécessaire (panier/paiement), et depuis le réplica pour la consultation du catalogue, en comprenant les compromis liés au décalage du réplica (replica lag).

4. Introduire un pooling de connexions côté application et plafonner la simultanéité

   • Justification : PgBouncer/HikariCP limite et réutilise les connexions, évitant les tempêtes de connexions lors de l’autoscaling et des basculements de haute disponibilité. Les pools sont dimensionnés en fonction des cœurs de CPU, et non du nombre maximum de pods, ce qui évite la surcharge.

5. Décharger les téléversements de médias vers Cloud Storage avec des URL signées et des téléversements reprenables

   • Justification : L’application émet des URL signées à courte durée de vie pour que les clients téléversent directement. Les téléversements reprenables s’adaptent aux réseaux peu fiables ; le service de médias écoute les notifications de finalisation de Pub/Sub pour déclencher le traitement. Les en-têtes de précondition (ifGenerationMatch) protègent contre les concurrences d’accès en écriture (overwrite races).

6. Implémenter Memorystore for Redis pour la mise en cache de pages, les sessions et la limitation de débit

   • Justification : Les caches de type read-through réduisent la charge sur la base de données pour les pages de produits avec des TTL alignés sur la fréquence de mise à jour. Les données de session sont conservées de manière éphémère dans Redis avec des TTL courts ; l’état de l’application reste dans Cloud SQL. Une stratégie de jeton à fenêtre fixe utilise INCR/EXPIRE pour les plafonds de requêtes par utilisateur. Le cache est traité comme non faisant autorité ; l’application tolère la perte du cache et le remplit à nouveau lors des échecs de cache (misses).

7. Préparer un cheminement par phases vers Cloud Bigtable pour les fonctionnalités de consultation de catalogue à haut débit

   • Justification : À mesure que le trafic augmente, les vues de catalogue dénormalisées et optimisées pour la lecture sont déplacées vers Bigtable. Les clés de ligne sont conçues comme bucket#catégorie#timestamp_inversé pour distribuer les écritures et prendre en charge les listages par ordre chronologique sans créer de points chauds (hotspotting).

8. Établir des procédures de migration de schéma et de restauration (rollback)

   • Justification : Les migrations sont additives : ajouter des colonnes/index, remplir les données a posteriori avec des tâches idempotentes, déployer du code qui lit/écrit sur les deux versions, puis supprimer les anciens champs plus tard. Des indicateurs de fonctionnalité (feature flags) protègent les nouveaux chemins d’exécution ; la restauration désactive les écritures vers les nouveaux champs sans DDL destructeur.

9. Définir des politiques de cycle de vie et de protection des données

   • Justification : Les buckets Cloud Storage utilisent des règles de cycle de vie pour faire passer les vignettes vers un stockage plus froid et supprimer les téléversements temporaires obsolètes. Les sauvegardes Cloud SQL et Spanner/Bigtable (au fur et à mesure de leur adoption) sont régulièrement restaurées à des fins de vérification. Les journaux d’audit capturent les workflows de suppression ; le nettoyage (GC) de Bigtable est reconnu comme asynchrone dans les documents de conformité.

10. Implémenter des nouvelles tentatives côté client et serveur avec un intervalle exponentiel binaire tronqué (truncated exponential backoff)

    • Justification : Cloud Storage peut renvoyer des erreurs 429/5xx lors des pics de charge ; le backoff lisse la charge et réduit les taux d’erreur. Les opérations sur la base de données et le cache utilisent des clés d’idempotence pour garantir des nouvelles tentatives sûres, en particulier lors des basculements et des micro-coupures réseau.

Ce plan offre une réduction immédiate des risques via Cloud SQL avec une connectivité privée et une haute disponibilité, maintient l’application réactive et rentable grâce à la mise en cache et aux téléversements par URL signées, et établit un chemin clair pour faire évoluer le débit de lecture et la résilience des données à mesure que le trafic augmente.

← Conception d’API · Tous les domaines · Identité →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Google →