Google Cloud Professional Cloud Database Engineer
Dernière révision : mai 2026
Une référence concise des modèles d'architecture évalués par l'examen PCDE. Lisez de haut en bas ou sautez à une section.
Plateforme e-commerce mondiale nécessitant des transactions ACID, une forte cohérence et une disponibilité de 99,999 % sur plusieurs continents.
Cloud Spanner avec une configuration multi-régions (par exemple, nam-eur-asia).
Pourquoi: Spanner est le seul service géré de GCP offrant des transactions ACID fortement cohérentes et distribuées globalement à grande échelle avec un SLA de 99,999 %.
Migration d'une grande base de données Oracle OLTP haute performance avec des procédures stockées complexes et des besoins en requêtes analytiques.
AlloyDB pour PostgreSQL.
Pourquoi: AlloyDB offre des performances PostgreSQL supérieures, des fonctionnalités de compatibilité Oracle et un moteur columnar pour accélérer les requêtes analytiques (HTAP) sans impacter les charges de travail transactionnelles.
Ingestion à haut débit (millions d'OPS) de données de séries chronologiques (par exemple, IoT, journaux) nécessitant des lectures à faible latence et une expiration automatique des données.
Cloud Bigtable avec une conception de clé de ligne `(entity_id)#(reverse_timestamp)` et une politique de récupération de place (garbage collection).
Pourquoi: Bigtable est conçu pour des charges de travail clé/valeur à grande échelle et à faible latence. Un horodatage inversé dans la clé de ligne co-localise les données récentes pour des analyses efficaces. La récupération de place gère le TTL.
Application mobile ou web nécessitant un schéma flexible, une synchronisation de données en temps réel avec les clients et un support hors ligne.
Firestore en mode natif.
Pourquoi: Firestore est conçu spécifiquement pour ce modèle de backend d'application sans serveur, offrant des écouteurs en temps réel et une persistance hors ligne via ses SDK clients, prêts à l'emploi.
Recherche de similarité à grande échelle (plus de 10 millions de vecteurs) pour les applications d'IA/ML (par exemple, RAG, recommandations) nécessitant une latence inférieure à 100 ms.
AlloyDB pour PostgreSQL avec l'extension pgvector et un index ScaNN.
Pourquoi: AlloyDB intègre l'algorithme ScaNN haute performance de Google pour la recherche de plus proches voisins approximatifs (ANN), surpassant les implémentations de recherche vectorielle standard à grande échelle.
Concevoir un schéma Cloud Spanner pour une charge de travail à forte intensité d'écriture afin d'éviter les hotspots sur un seul serveur.
Concevoir des clés primaires qui n'utilisent pas de valeurs augmentant de manière monotone (par exemple, des ID séquentiels, des horodatages) comme première partie de la clé. Utiliser plutôt des UUID, des valeurs hachées ou des séquences inversées de bits.
Pourquoi: Spanner distribue les données de manière lexicographique par clé primaire. Les clés séquentielles dirigent toutes les écritures vers un seul split, créant un hotspot. Les clés distribuées aléatoirement répartissent les écritures sur tous les splits.
Un schéma Spanner a une forte relation parent-enfant (par exemple, Clients et Commandes) et les requêtes récupèrent fréquemment un parent avec tous ses enfants.
Utiliser des tables entrelacées (interleaved tables), en définissant la table enfant avec `INTERLEAVE IN PARENT`.
Pourquoi: L'entrelacement co-localise physiquement les lignes enfants avec leur ligne parent dans le stockage. Cela rend les jointures parent-enfant extrêmement efficaces, car cela devient une analyse de plage hautement optimisée sur un seul split.
Suivi des emplacements en temps réel pour une flotte massive de véhicules (plus de 50 000 écritures/seconde) avec des requêtes pour trouver des véhicules dans une zone géographique.
Cloud Bigtable avec une clé de ligne préfixée par un GeoHash de l'emplacement du véhicule.
Pourquoi: Bigtable gère le débit d'écriture extrême. L'encodage GeoHash convertit les coordonnées 2D en une chaîne 1D où les préfixes représentent la proximité géographique, permettant des analyses de plage géospatiales efficaces.
Stocker et analyser des données à l'échelle du pétaoctet (par exemple, données génomiques, journaux) avec des requêtes SQL analytiques complexes.
Stocker les données brutes dans Cloud Storage et les interroger directement depuis BigQuery à l'aide de tables externes, ou les charger dans le stockage natif de BigQuery.
Pourquoi: BigQuery est un entrepôt de données sans serveur conçu pour l'analyse à l'échelle du pétaoctet. Sa séparation du stockage et du calcul offre des performances de requête inégalées et une rentabilité pour les charges de travail OLAP.
Un cache en mémoire haute disponibilité pour des structures de données complexes (hachages, ensembles) avec des capacités pub/sub pour l'invalidation du cache.
Memorystore pour Redis Standard Tier avec répliques en lecture.
Pourquoi: Le Standard Tier offre un SLA de 99,9 % avec basculement automatique. Redis prend en charge des types de données complexes et le pub/sub, contrairement à Memcached. Les répliques en lecture peuvent faire évoluer le débit de lecture.
Concevoir une application SaaS multi-locataire sur Spanner nécessitant une forte isolation des données et des garanties de performance par locataire.
Utiliser tenant_id comme premier composant de la clé primaire pour toutes les tables. Pour une isolation plus forte, utiliser un modèle "une base de données par locataire" au sein d'une seule instance Spanner.
Pourquoi: Un préfixe tenant_id co-localise naturellement toutes les données d'un seul locataire, optimisant les requêtes et permettant à Spanner de diviser les données par locataire. Le modèle "une base de données par locataire" offre l'isolation logique la plus forte.
Une base de données Cloud SQL rencontre des performances de requête lentes et une utilisation élevée du CPU.
Utiliser Query Insights pour identifier les requêtes les plus gourmandes en ressources, analyser leurs plans d'exécution et identifier les index manquants ou les schémas inefficaces.
Pourquoi: Query Insights est l'outil principal et intégré pour diagnostiquer les performances des requêtes dans Cloud SQL. Il visualise la charge des requêtes, identifie les événements d'attente et aide à cerner la cause profonde sans outils tiers.
Une organisation a besoin d'un tableau de bord unique et d'un ensemble de politiques d'alerte pour des dizaines d'instances de base de données réparties sur plusieurs projets GCP.
Créer un espace de travail Cloud Monitoring dans un projet central et configurer son "étendue de métriques" pour inclure tous les projets contenant des instances de base de données.
Pourquoi: Les étendues de métriques (Metrics scopes) permettent à un seul espace de travail Monitoring d'agréger et d'afficher les métriques de plusieurs projets, offrant une vue unifiée sans duplication de données ni configuration complexe.
Nécessité de provisionner et gérer les instances Cloud SQL dans les environnements de développement, de préproduction et de production de manière cohérente et avec contrôle de version.
Utiliser Terraform avec le fournisseur Google Cloud. Définir un module Cloud SQL et utiliser des fichiers `.tfvars` distincts pour chaque environnement.
Pourquoi: Terraform fournit l'Infrastructure as Code (IaC), permettant des déploiements reproductibles, auditables et contrôlés par version. Cela évite les erreurs de configuration manuelles et assure la cohérence entre les environnements.
Un contractant a besoin d'un accès temporaire et élevé à la base de données qui doit être automatiquement révoqué après 4 heures.
Accorder le rôle IAM nécessaire avec une condition IAM qui utilise une expression basée sur le temps (`request.time < timestamp(...)`).
Pourquoi: Les conditions IAM offrent un moyen natif et sécurisé d'accorder un accès limité dans le temps sans nettoyage manuel, ce qui est source d'erreurs. L'accès est automatiquement refusé après l'expiration de l'horodatage.
Une politique de sécurité exige que tout le chiffrement des disques de base de données utilise des clés gérées par le client (CMEK) avec une rotation contrôlée.
Configurer l'instance Cloud SQL ou AlloyDB pour utiliser une clé de Cloud KMS. Configurer la rotation automatique sur la clé KMS.
Pourquoi: CMEK offre un contrôle et une auditabilité sur les clés utilisées pour le chiffrement au repos. Cloud KMS gère de manière transparente le cycle de vie des clés, y compris la rotation automatisée.
La conformité exige la capture de toutes les requêtes SQL exécutées sur une instance Cloud SQL pour PostgreSQL, avec des journaux conservés pendant 7 ans.
Activer l'extension `pgaudit` sur l'instance. Configurer les journaux d'audit Cloud pour l'accès aux données. Créer un collecteur de journaux (log sink) de Cloud Logging vers BigQuery pour une rétention et une analyse à long terme.
Pourquoi: pgaudit fournit un audit détaillé au niveau SQL. L'envoi des journaux vers BigQuery est le modèle standard et rentable pour une rétention de journaux à long terme et consultable au-delà des valeurs par défaut de Cloud Logging.
Les analystes de données doivent exécuter des requêtes analytiques lourdes sur les données de production Cloud SQL sans impacter la charge de travail transactionnelle.
Créer une réplique en lecture et y diriger toutes les requêtes analytiques. Pour des analyses plus complexes, utiliser des requêtes fédérées BigQuery sur la réplique en lecture.
Pourquoi: Une réplique en lecture isole complètement le trafic de lecture analytique de l'instance principale, protégeant les performances OLTP. La fédération permet d'utiliser le puissant moteur de BigQuery sans pipeline ETL séparé.
Un cluster Bigtable présente une charge CPU inégale, avec certains nœuds fortement utilisés tandis que d'autres sont inactifs, indiquant un goulot d'étranglement des performances.
Utiliser l'outil Key Visualizer dans la console Cloud pour analyser les modèles d'accès et identifier les plages de clés de ligne spécifiques qui sont accédées trop fréquemment (hotspotting).
Pourquoi: Key Visualizer est l'outil de diagnostic spécialement conçu pour les problèmes de performance de Bigtable. Il fournit une carte thermique de l'accès aux clés, ce qui facilite l'identification des hotspots qui doivent être traités par une refonte du schéma.
Nécessité de répliquer les changements d'une base de données Cloud SQL OLTP vers un entrepôt de données BigQuery en quasi temps réel.
Utiliser Datastream pour configurer un flux de capture de données modifiées (Change Data Capture - CDC) de l'instance Cloud SQL source directement vers BigQuery.
Pourquoi: Datastream est un service CDC géré et à faible latence qui lit les journaux de base de données, minimisant l'impact sur la source. Il gère la dérive de schéma et livre les changements de manière fiable à BigQuery.
Une application Cloud Run épuise les connexions à la base de données en raison d'une mise à l'échelle rapide pendant les pics de trafic.
Déployer le Cloud SQL Auth Proxy en tant que conteneur sidecar et le configurer pour le pooling de connexions (ou l'utiliser avec un pooler dédié comme PgBouncer).
Pourquoi: Les plateformes sans serveur peuvent s'adapter à des milliers d'instances, dépassant les limites de connexion de la base de données. Un pooler de connexions multiplexe ces nombreuses connexions d'applications éphémères sur un petit ensemble stable de connexions de base de données.
Migration d'une grande base de données MySQL sur site (5 To) vers Cloud SQL pour MySQL avec un temps d'arrêt maximal de 30 minutes.
Utiliser le service de migration de base de données (DMS) pour configurer un travail de réplication continue. DMS effectue un chargement initial puis diffuse les changements jusqu'à la bascule.
Pourquoi: DMS est la solution gérée pour les migrations avec temps d'arrêt minimal. La réplication continue signifie que le seul temps d'arrêt est le temps nécessaire pour arrêter les écritures, attendre la synchronisation finale et pointer l'application vers la nouvelle base de données.
Migration d'une base de données Oracle vers AlloyDB pour PostgreSQL, y compris les procédures stockées PL/SQL complexes.
Utiliser DMS pour la migration des données. Utiliser des outils de conversion de schéma (comme Ora2Pg ou DMS Schema Conversion) pour convertir les schémas et le PL/SQL en PL/pgSQL, suivi d'une révision et de tests manuels.
Pourquoi: Les migrations hétérogènes nécessitent à la fois la migration des données (gérée par DMS) et la conversion du schéma/code. Les outils automatisés gèrent environ 80 % de la conversion, mais un effort manuel est toujours nécessaire pour les fonctionnalités spécifiques à Oracle.
Nécessité de vérifier l'intégrité et l'exhaustivité des données après la migration d'une base de données d'un centre de données sur site vers Google Cloud.
Utiliser l'outil de validation de données open source (DVT). Le configurer pour comparer le nombre de lignes, les agrégations au niveau des colonnes (min, max, somme) et les hachages au niveau des lignes entre la source et la cible.
Pourquoi: DVT fournit un cadre complet, évolutif et personnalisable pour la validation des données qui va au-delà des simples comptages de lignes, détectant les subtiles corruptions de données ou les problèmes de transformation.
Migration d'une application MySQL shardée vers une base de données unique et globalement cohérente.
Utiliser plusieurs tâches Dataflow parallèles pour migrer chaque shard simultanément vers une seule base de données Cloud Spanner. Refondre le schéma pour éliminer le besoin de sharding au niveau de l'application.
Pourquoi: Spanner est conçu pour remplacer les architectures shardées complexes. Une approche de migration parallèle avec Dataflow est le moyen le plus efficace en termes de temps pour consolider de grands ensembles de données shardées dans Spanner.
Migration d'une base de données SQL Server utilisant l'authentification Windows (Active Directory) vers Cloud SQL pour PostgreSQL.
Intégrer Cloud SQL avec Cloud Identity en utilisant l'authentification de base de données IAM. Synchroniser les groupes AD avec les groupes Google via GCDS et mapper les rôles de base de données à ces groupes.
Pourquoi: Cette approche reproduit le modèle de contrôle d'accès centralisé basé sur les groupes d'AD de manière native dans le cloud, évitant la gestion manuelle des utilisateurs/mots de passe et tirant parti des structures d'identité existantes.
Migration d'une application d'Amazon DynamoDB vers Cloud Bigtable.
Mapper la clé primaire composite DynamoDB (clé de partition + clé de tri) à une clé de ligne Bigtable concaténée, séparée par un délimiteur (par exemple, `partitionKey#sortKey`).
Pourquoi: Cette conception de clé de ligne préserve les capacités de requête de la clé composite DynamoDB, permettant des recherches efficaces par préfixe de clé de partition et des analyses de plage sur la partie de la clé de tri.
Une application se connectant à une instance Cloud SQL haute disponibilité doit survivre à un basculement zonal sans intervention manuelle.
Se connecter à la base de données en utilisant le Cloud SQL Auth Proxy avec le nom de connexion de l'instance (project:region:instance), et non une adresse IP statique.
Pourquoi: L'adresse IP de l'instance change lors d'un basculement. L'Auth Proxy et le nom de connexion de l'instance fournissent un point de terminaison stable qui se résout automatiquement à l'adresse IP de l'instance primaire actuelle.
Une application Spanner globale a des utilisateurs en Amérique du Nord et en Asie. Les écritures proviennent principalement d'Amérique du Nord, mais les utilisateurs asiatiques ont besoin de lectures à faible latence.
Utiliser une configuration multi-régions avec la région leader en Amérique du Nord (`nam*`). Les lectures en Asie seront servies par des répliques locales en lecture seule.
Pourquoi: Les écritures dans Spanner sont acheminées via la région leader, de sorte que la placer près de la source d'écriture minimise la latence d'écriture. Les répliques en lecture dans d'autres régions offrent des lectures à faible latence pour les utilisateurs distribués globalement.
Une application basée sur AlloyDB a un rapport lectures/écritures de 10:1 et doit s'adapter pour gérer un trafic de lecture élevé tout en maintenant une disponibilité de 99,99 %.
Configurer l'instance principale avec une haute disponibilité et ajouter plusieurs instances de pool de lecture. Diriger le trafic de lecture vers le pool de lecture.
Pourquoi: La haute disponibilité d'AlloyDB offre un SLA de 99,99 %. Les instances de pool de lecture sont conçues pour la mise à l'échelle horizontale des lectures, déchargeant le trafic de l'instance principale vers des nœuds dédiés optimisés pour la lecture.
Une instance Cloud SQL sensible à la latence avec stockage SSD a des performances d'E/S insuffisantes.
Augmenter la taille de stockage provisionnée de l'instance.
Pourquoi: Dans Cloud SQL, les IOPS en lecture et en écriture évoluent linéairement avec la quantité de stockage sur disque persistant provisionnée. Augmenter la taille du disque est le moyen direct d'augmenter les IOPS disponibles.
Nécessité de déployer un changement de schéma risqué sur une base de données Cloud SQL critique avec une capacité de retour arrière rapide.
Créer une réplique en lecture de l'instance de production (bleue). Promouvoir la réplique en une instance autonome (verte), appliquer et valider les changements de schéma. Ensuite, rediriger le trafic de l'application vers l'instance verte. Garder l'instance bleue en fonctionnement pour le retour arrière.
Pourquoi: Ce modèle permet de tester entièrement les changements sur une copie des données à l'échelle de la production sans impacter le système en direct. Le trafic peut être basculé instantanément, et le retour arrière est aussi simple que de rediriger le trafic vers l'instance bleue.
Nécessité de tester un plan de reprise après sinistre de base de données trimestriellement sans affecter l'environnement de production.
Créer une instance de test temporaire en restaurant à partir d'une sauvegarde de production récente. Exécuter les procédures de DR documentées sur cette instance de test, y compris le basculement simulé et les tests de reconnexion d'application.
Pourquoi: Les tests sur une sauvegarde restaurée offrent un environnement réaliste pour valider les RTO/RPO et les procédures de récupération sans risquer de provoquer une panne de production.
Un service Cloud Run doit se connecter à une instance Cloud SQL de manière sécurisée sans que le trafic ne transite par l'internet public.
Configurer Cloud SQL avec une IP privée. Créer un connecteur d'accès VPC sans serveur (Serverless VPC Access) dans le même VPC et configurer le service Cloud Run pour y acheminer le trafic.
Pourquoi: C'est le modèle standard et sécurisé pour connecter le calcul sans serveur aux ressources natives du VPC. Le connecteur relie l'environnement sans serveur et votre VPC, en maintenant tout le trafic sur le réseau privé de Google.
Ajout d'une nouvelle colonne non-nullable à une table Cloud Spanner massive et activement écrite sans interruption de service.
1. Ajouter la colonne comme nullable. 2. Mettre à jour le code de l'application pour écrire dans la nouvelle colonne. 3. Remplir les lignes existantes par lots à l'aide de Dataflow. 4. Après le remplissage, modifier la colonne pour qu'elle soit NOT NULL.
Pourquoi: Ce processus en plusieurs étapes est le modèle standard de modification de schéma en ligne pour les grandes tables. Il évite de verrouiller la table pendant une longue durée ou de provoquer une opération de remplissage massive et impactant les performances en une seule transaction.
