Google PCD: Datos de aplicación, estado y patrones de almacenamiento — Guía de estudio

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

Forma parte de la Google Professional Cloud Developer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Resumen

Las aplicaciones modernas en Google Cloud combinan de forma rutinaria múltiples almacenes de datos para equilibrar la latencia, la consistencia, la escalabilidad, el costo y la complejidad operativa. Seleccionar servicios y patrones adecuados para cada propósito —y comprender sus modos de fallo— es fundamental para un diseño resiliente. Esta sección resume orientaciones prácticas para Cloud SQL, Cloud Spanner, Firestore, Bigtable, Memorystore y Cloud Storage, y aborda las migraciones, el particionamiento y la protección de datos.

Datos Relacionales en Cloud SQL

Cloud SQL proporciona servicios gestionados de MySQL, PostgreSQL y SQL Server con la semántica familiar de los RDBMS.

Conectividad privada
- Usa IP privada para mantener el tráfico de la base de datos en tu VPC. Esto elimina las reglas de entrada públicas y las listas de IP permitidas, y evita la complejidad de la salida a través de NAT.
- Asegúrate de que las rutas y las reglas de firewall permitan el tráfico de la VPC a la instancia. La resolución de nombres para la IP privada se gestiona automáticamente cuando se habilita la IP privada.
- Para entornos serverless (Cloud Run, App Engine, Cloud Functions), prefiere los conectores de Cloud SQL, que gestionan la autenticación de IAM y TLS, incluso con IP privada.
Alta disponibilidad y réplicas
- La alta disponibilidad (HA) regional ubica la instancia principal y la de reserva en zonas diferentes con replicación síncrona de disco. Es de esperar una breve caída de la conexión durante el failover; las aplicaciones deben reintentar los errores transitorios y reconectarse.
- Las réplicas de lectura son asíncronas y descargan el tráfico de lectura. Usa réplicas entre regiones para recuperación ante desastres (DR) y proximidad de lectura, entendiendo que las réplicas son eventualmente consistentes.
- Promociona una réplica de lectura para la recuperación o para intercambios de roles planificados. Prueba los procedimientos de promoción con regularidad.
Copias de seguridad y recuperación a un punto en el tiempo
- Habilita las copias de seguridad automáticas y los registros de transacciones/PITR. Programa las copias de seguridad en horas de baja demanda para reducir la contención de E/S.
- Conserva múltiples copias y valida periódicamente las restauraciones en una instancia separada. Una copia de seguridad que no puedes restaurar es operacionalmente equivalente a no tener ninguna.
Pools de conexiones y límites
- Cloud SQL impone un máximo de conexiones; un exceso de conexiones de corta duración causa saturación de la CPU y latencia. Usa pooling del lado de la aplicación (p. ej., HikariCP, PgBouncer, ProxySQL).
- Dimensiona los pools basándote en los núcleos de CPU y la concurrencia de la carga de trabajo, no solo en la memoria de la instancia. Empieza con un tamaño pequeño y escala de forma empírica.
- Para cómputo efímero/serverless, el conector de Cloud SQL específico del lenguaje mantiene un pool por revisión; aun así, limita la concurrencia para evitar tormentas de conexiones después de arranques en frío.
Particionamiento de datos y rendimiento
- Fragmenta (haz sharding) los esquemas grandes multitenant por cliente o región para reducir la contención. Mantén a los tenants con alta actividad aislados siempre que sea posible.
- Crea índices de cobertura con cuidado; un exceso de índices ralentiza las escrituras y aumenta el almacenamiento. Verifica la cardinalidad y la selectividad del predicado.
- Usa bloqueo optimista o SELECT FOR UPDATE para filas con alta contención; ajusta autovacuum (PostgreSQL) o la configuración de InnoDB (MySQL) para cargas de trabajo de escritura sostenidas.

Modos de fallo comunes y mitigaciones:

Estampidas (thundering herds) tras reinicios de VM/nodos: limita el tamaño de los pools y usa retroceso exponencial.
Retraso de la réplica (replica lag) para read-your-writes: fija las lecturas a la instancia principal cuando se requiera consistencia de sesión.
Failovers intermitentes (flaps) de HA debido a vecinos ruidosos o mantenimiento: implementa reintentos de conexión y transacción con idempotencia.

Datos Relacionales a Escala Planetaria en Cloud Spanner

Cloud Spanner ofrece escalabilidad horizontal con opciones de consistencia global.

Consistencia y transacciones
- Las lecturas fuertes (strong reads) y las transacciones de lectura-escritura proporcionan una consistencia externa estricta usando TrueTime; los commits esperan brevemente para asegurar la linealizabilidad.
- Las lecturas obsoletas y con obsolescencia acotada (stale and bounded-staleness reads) reducen la latencia y mejoran la disponibilidad para cargas de trabajo con mucha lectura cuando la frescura de los datos puede ser ligeramente relajada.
- Las transacciones de solo lectura abarcan múltiples lecturas en una marca de tiempo sin bloqueos; úsalas para instantáneas consistentes para analítica.
Regionalidad, disponibilidad y latencia
- Las instancias regionales proporcionan alta disponibilidad dentro de una región. Las configuraciones multirregionales (por ejemplo, nam-asia-eur1) ofrecen una disponibilidad muy alta y lecturas locales de baja latencia entre continentes con escrituras globalmente consistentes.
- Elige configuraciones de instancia alineadas con la geografía de tus usuarios; las latencias de escritura aumentan con el tamaño del quórum intercontinental.
Escalabilidad y diseño del esquema
- Spanner fragmenta los datos en splits por rangos de clave primaria, distribuidos entre los nodos. El hotspotting ocurre cuando las claves son monotónicamente crecientes. Evita claves como los ID autoincrementales o las marcas de tiempo siempre crecientes en la posición principal de la clave.
- Usa claves primarias compuestas que distribuyan las escrituras (por ejemplo, customer_hash, customer_id, reverse_timestamp).
- Las tablas intercaladas (interleaved tables) colocalizan las filas hijas con las padres para mejorar la localidad y la eficiencia de los joins. Úsalas cuando la cardinalidad y el acceso de las filas hijas se correlacionan fuertemente con la padre. Complementa con índices secundarios; considera usar cláusulas STORING para reducir las búsquedas en la tabla.
- Monitoriza la CPU, el almacenamiento y las operaciones de alta prioridad frente a las de mejor esfuerzo (best-effort); escala los nodos para mantener un margen de maniobra por debajo de las latencias P95.
Patrones operativos
- Los clientes usan pools de sesiones; ajusta el mínimo/máximo de sesiones para evitar tormentas de creación. Los reintentos deben ser limitados e idempotentes; en caso de ABORTED, reintenta las transacciones de lectura-escritura con retroceso (backoff).
- Las copias de seguridad son ligeras y consistentes; valida las restauraciones en instancias separadas. Los change streams y las integraciones de CDC pueden alimentar sistemas posteriores.

Contrapartidas:

Las escrituras globales fuertes (strong writes) añaden una espera de commit; usa lecturas obsoletas (stale reads) para rutas críticas para la experiencia de usuario (UX) que son mayoritariamente de lectura.
El intercalado (interleaving) mejora la localidad pero puede concentrar la presión de escritura; prueba con tráfico similar al de producción.

Almacenes operacionales NoSQL: Firestore y Bigtable

Elige el modelo NoSQL que se ajuste a los patrones de consulta y al perfil de rendimiento.

Firestore (documento)
- Modelo de datos: las colecciones contienen documentos; los documentos pueden tener subcolecciones. Modela en torno a los patrones de consulta; evita las escrituras de distribución profunda (fan-out) en documentos únicos “calientes” (hot).
- Acceso y transacciones: las lecturas de documentos y las consultas son fuertemente consistentes en modo Nativo. Usa escrituras por lotes (batched writes) para una atomicidad de como máximo una vez (at-most-once) en múltiples documentos, y transacciones para operaciones de leer-modificar-escribir con comprobaciones de contención.
- Índices: los índices de un solo campo son automáticos. Los índices compuestos de múltiples campos deben definirse al usar múltiples filtros de rango/desigualdad u órdenes de clasificación. La desnormalización es común para hacer que las consultas solo usen índices (index-only).
- Sincronización de clientes: los listeners en tiempo real transmiten (stream) los cambios; las cachés sin conexión se reconcilian con una semántica de “la última escritura gana” (last-write-wins). Protégete contra la distribución (fan-out) ilimitada de listeners; prefiere los cursores de consulta y los filtros.
- Límites y modos de fallo: la tasa de escritura en un único documento se serializa; las actualizaciones sostenidas con un alto QPS a un documento crean contención. Usa contadores distribuidos (sharded counters) con N subdocumentos y agrégalos en la lectura.
Cloud Bigtable (columna ancha)
- El diseño de la clave de fila (row-key) es primordial. Bigtable particiona las filas lexicográficamente; los segmentos iniciales de la clave determinan el hotspotting (puntos calientes). Evita claves secuenciales como marcas de tiempo al principio o ID de usuario sin particionar (unsharded).
- Patrones:
  - Marca de tiempo invertida dentro de la clave para lecturas de series temporales: key = device#hash(device_id)#reverse_ts.
  - Aplica un hash o agrupa en buckets el primer componente para distribuir las escrituras: bucket = crc32(user_id) % 128.
- Almacena celdas pequeñas con muchas columnas; evita filas grandes que abarquen varias tabletas (tablets). Aprovecha múltiples familias de columnas para el control de acceso y la separación de políticas de recolección de basura (GC).
- Rendimiento y servicio (serving):
  - Usa múltiples clústeres para la replicación y la proximidad de lectura regional; las escrituras entre clústeres se vuelven eventualmente consistentes.
  - Ajusta los perfiles de aplicación (app profiles) y el enrutamiento; mantén pools de hilos y pools de canales generosos en el lado del cliente.
- GC y TTL: la recolección de basura (GC) basada en versión y tiempo elimina las celdas antiguas de forma asíncrona; los datos persisten hasta la compactación, así que no confíes en la eliminación inmediata para plazos regulatorios.

Patrones de almacenamiento en caché y de objetos

Memorystore (Redis/Memcached)
- Estrategias de caché:
  - Lectura directa (Read-through): la aplicación obtiene los datos de la caché; en caso de fallo (miss), los carga desde la fuente y puebla la caché.
  - Escritura directa (Write-through): las escrituras se realizan en la caché y en la fuente de forma síncrona.
  - Escritura diferida (Write-behind): almacena en búfer las escrituras en la caché y las vuelca de forma asíncrona; úsalo con precaución debido al riesgo de pérdida.
- Expiración e invalidación:
  - Aplica TTL coherentes con la tolerancia a la obsolescencia de los datos. Invalida las claves cuando haya cambios en la fuente de verdad (source-of-truth); para cachés agregadas, usa claves con versiones para evitar estampidas (stampedes).
  - Usa un mutex o un mecanismo de vuelo único (single-flight) para prevenir estampidas de caché (cache stampedes) en claves populares.
- Sesiones: almacena datos de sesión efímeros con un TTL; cifra los valores o almacena solo tokens opacos si son sensibles.
- Limitación de velocidad (Rate limiting) con Redis:
  - Ventana fija (Fixed-window): INCR con EXPIRE en una clave por identidad.
  - Ventana deslizante (Sliding-window) o cubeta de tokens (token-bucket) para límites más suaves; considera usar scripts de Lua para la atomicidad.
- Disponibilidad: El nivel Básico (Basic) no tiene conmutación por error (failover); el nivel Estándar (Standard) proporciona alta disponibilidad (HA) regional. Trata la caché como volátil; nunca como almacenamiento autoritativo.
Ejemplo: limitación de velocidad simple de ventana fija
- Comandos:
  - INCR rate:login:USER123:20260903T1000
  - EXPIRE rate:login:USER123:20260903T1000 60
Cloud Storage
- Objetos y consistencia: consistencia fuerte y global para lecturas, escrituras, sobrescrituras, eliminaciones y listados. Los objetos son inmutables; las actualizaciones crean nuevas generaciones.
- URL firmadas: descarga las cargas/descargas grandes directamente entre los clientes y los buckets sin pasar por un proxy en tu aplicación. Establece expiraciones cortas; restringe el método, la ruta y las cabeceras de contenido.
- Cargas reanudables: úsalas para archivos de más de 5 MB y redes poco fiables; maneja los errores 5xx/429 con retirada exponencial truncada (truncated exponential backoff) y tokens de reanudación.
- Ciclo de vida: define reglas para cambiar entre clases de almacenamiento, eliminar versiones antiguas y forzar la retención. Combínalo con el control de versiones de objetos para mayor seguridad durante los despliegues (rollouts).
- Notificaciones: integra notificaciones de Pub/Sub para activar el procesamiento posterior (downstream) tras la finalización/eliminación de un objeto, e incluye precondiciones (ifGenerationMatch) para protegerte contra las condiciones de carrera (races).
Ejemplo: subir archivos locales
- gsutil cp ./data/*.parquet gs://my-bucket/ingest/

Migración, consistencia, particionamiento y protección de datos

Migración de bases de datos
- Elegir entre online y offline: online con Database Migration Service para un tiempo de inactividad mínimo; offline por simplicidad cuando las ventanas de mantenimiento son aceptables.
- Primero el esquema: conciliar tipos y restricciones; para Spanner, considerar herramientas para mapear esquemas y datos de MySQL/PostgreSQL, luego ajustar claves e índices para la distribución.
- Ejecución dual y transición (cutover): durante la migración online, realizar escritura dual o replicar los registros de cambios (changelogs). Validar recuentos de filas, checksums y el comportamiento de consultas críticas antes de la transición final.
Migraciones de esquema y reversión (rollback)
- Usar migraciones versionadas y automatizadas (por ejemplo, con una herramienta de migraciones) como parte de CI/CD. Diseñar cambios aditivos y retrocompatibles: agregar columnas e índices, rellenar datos (backfill), desplegar código que lee/escribe en ambos, y luego eliminar los artefactos obsoletos.
- Planificar la reversión con transformaciones de datos: si el despliegue de código falla, estar preparado para deshabilitar las nuevas escrituras y depender de feature flags; evitar migraciones destructivas que bloqueen la reversión.
Flujos de trabajo transaccionales vs. eventualmente consistentes
- Usar transacciones ACID cuando las invariantes deben mantenerse de forma síncrona (transferencias de fondos, decrementos de inventario).
- Preferir la consistencia eventual para funcionalidades orientadas al usuario y principalmente de lectura donde la latencia es dominante (feeds, búsquedas, contadores). Implementar claves de idempotencia, patrones outbox/Saga y reintentos con backoff.
- Combinar: confirmar el estado autoritativo en un almacén transaccional; publicar eventos para proyecciones eventualmente consistentes.
Particionamiento de datos y gestión de conexiones
- Particionar por tenant, geografía o tipo de carga de trabajo para aislar puntos calientes (hotspots). Para Bigtable y Spanner, codificar las claves de partición en las claves primarias; para Cloud SQL, usar un esquema por tenant o sharding de tablas con routers.
- Gestionar conexiones:
  - Cloud SQL: agrupar y reutilizar (pool); limitar la concurrencia; escalonar los arranques en frío.
  - Spanner: reutilizar sesiones; precalentar los pools al inicio; limitar los reintentos.
  - Memorystore: reutilizar conexiones TCP; evitar conexiones por solicitud.
Protección de datos, archivado, verificación de restauración y comportamiento de eliminación
- Copias de seguridad y archivado:
  - Cloud SQL: copias de seguridad automatizadas + PITR; probar restauraciones.
  - Spanner: copias de seguridad gestionadas; probar la restauración en un entorno no productivo.
  - Firestore: exportaciones programadas a Cloud Storage; verificar las importaciones.
  - Bigtable: copias de seguridad y snapshots; probar la clonación y restauración.
  - Cloud Storage: políticas de retención, retenciones de objetos (object holds) y acceso uniforme a nivel de bucket para la gobernanza; archivar a clases más frías mediante el ciclo de vida.
- Verificación de la restauración: restaurar periódicamente en entornos aislados y ejecutar consultas de validación y pruebas de humo (smoke tests) de la aplicación. Monitorear RTO/RPO frente a la política.
- Comportamiento de eliminación:
  - La recolección de basura (GC) y el ciclo de vida de Bigtable son asíncronos; no prometer un borrado inmediato.
  - El versionado de Cloud Storage retiene generaciones hasta que el ciclo de vida las elimina.
  - El TTL de Firestore y las eliminaciones basadas en exportación son asíncronas.
  - Para SLAs de eliminación definitiva (hard-deletion), diseñar procesos que marquen para eliminar, encolen y verifiquen la eliminación, con registros de auditoría.

Escenario de problema práctico

Aurora Outfitters está migrando una plataforma monolítica de comercio electrónico a Google Cloud. Deben: 1) hacer un lift-and-shift de MySQL para reducir el riesgo, 2) manejar cargas de archivos multimedia de productos de 500 MB sin sobrecargar la aplicación, 3) escalar el rendimiento de lectura para los catálogos de productos, y 4) aplicar límites de tasa por usuario durante las ventas pico.

Enfoque:

Migrar MySQL a Cloud SQL con IP privada y alta disponibilidad (HA) regional
- Justificación: La IP privada elimina la exposición pública y las listas de IP permitidas (allowlists), simplificando la conectividad segura desde GKE y Compute Engine. La HA regional protege contra fallos zonales; se esperan breves caídas de conexión durante la conmutación por error (failover), por lo que la aplicación implementará transacciones reintentables y lógica de reconexión.
Habilitar copias de seguridad automatizadas y PITR, y validar la restauración
- Justificación: Las copias de seguridad automatizadas y los registros de transacciones permiten la recuperación a un punto en el tiempo (point-in-time recovery) de errores de usuario o de la aplicación. Una restauración programada a una instancia no productiva cada semana verifica que las copias de seguridad sean utilizables y mide el RTO.
Añadir una réplica de lectura para las lecturas del catálogo
- Justificación: Mover las consultas del catálogo a una réplica de lectura reduce la contención en la instancia principal. La aplicación lee de la principal cuando se necesita consistencia de lectura tras escritura (write-after-read) (carrito/checkout), y de la réplica para la navegación del catálogo, entendiendo las compensaciones del retraso de la réplica (replica lag).
Introducir un pool de conexiones del lado de la aplicación y limitar la concurrencia
- Justificación: PgBouncer/HikariCP limita y reutiliza las conexiones, evitando tormentas de conexiones durante el autoescalado y las conmutaciones por error de HA. Los pools se dimensionan según los núcleos de CPU, no según el número máximo de pods, para prevenir la sobrecarga.
Descargar las subidas de archivos multimedia a Cloud Storage con URLs firmadas y subidas reanudables
- Justificación: La aplicación emite URLs firmadas de corta duración para que los clientes suban los archivos directamente. Las subidas reanudables se adaptan a redes poco fiables; el servicio de medios escucha las notificaciones de finalización de Pub/Sub para activar el procesamiento. Las cabeceras de precondición (ifGenerationMatch) protegen contra condiciones de carrera en la sobrescritura.
Implementar Memorystore for Redis para el almacenamiento en caché de páginas, sesiones y limitación de tasa
- Justificación: Las cachés de lectura directa (read-through caches) reducen la carga de la base de datos para las páginas de productos con TTLs alineados a la frecuencia de actualización. Los datos de sesión se mantienen efímeros en Redis con TTLs cortos; el estado de la aplicación permanece en Cloud SQL. Una estrategia de token de ventana fija utiliza INCR/EXPIRE para los límites de solicitudes por usuario. La caché se trata como no autoritativa; la aplicación tolera la pérdida de la caché y la repobla en caso de fallos (misses).
Preparar una ruta por fases hacia Cloud Bigtable para funcionalidades de navegación de catálogo de alto rendimiento
- Justificación: A medida que el tráfico crece, las vistas de catálogo desnormalizadas y optimizadas para lectura se mueven a Bigtable. Las claves de fila se diseñan como bucket#categoría#timestamp_inverso para distribuir las escrituras y soportar listados ordenados por tiempo sin generar puntos calientes (hotspotting).
Establecer procedimientos de migración de esquema y reversión (rollback)
- Justificación: Las migraciones son aditivas: añadir columnas/índices, rellenar datos (backfill) con trabajos idempotentes, desplegar código que lee/escribe en ambos, y luego eliminar los campos antiguos más tarde. Los feature flags protegen las nuevas rutas; la reversión deshabilita las escrituras en los nuevos campos sin DDL destructivo.
Establecer políticas de ciclo de vida y protección de datos
- Justificación: Los buckets de Cloud Storage utilizan reglas de ciclo de vida para transferir las miniaturas a almacenamiento más frío y eliminar subidas temporales obsoletas. Las copias de seguridad de Cloud SQL y las de Spanner/Bigtable (a medida que se adoptan) se restauran regularmente para su verificación. Los registros de auditoría capturan los flujos de trabajo de eliminación; la recolección de basura (GC) de Bigtable se reconoce como asíncrona en los documentos de cumplimiento.
Implementar reintentos en el cliente y el servidor con backoff exponencial truncado
- Justificación: Cloud Storage puede devolver errores 429/5xx durante los picos; el backoff suaviza la carga y reduce las tasas de error. Las operaciones de base de datos y caché utilizan claves de idempotencia para garantizar reintentos seguros, particularmente durante la conmutación por error y las interrupciones de red.

Este plan ofrece una reducción de riesgo inmediata a través de Cloud SQL con conectividad privada y HA, mantiene la aplicación responsiva y rentable con almacenamiento en caché y subidas con URL firmadas, y construye una ruta clara para escalar el rendimiento de lectura y la resiliencia de los datos a medida que crece el tráfico.

← Diseño de API · Todos los dominios · Identidad →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →