Tema 6 de 11
Bases de datos en Google Cloud
El temario enumera Cloud SQL, AlloyDB, Spanner, Firestore, Bigtable y Memorystore entre los productos de datos que hay que saber elegir y desplegar, y añade mantener la redundancia multirregional. La clave del examen es asociar cada requisito (relacional o no, escala, latencia, disponibilidad) con su servicio. BigQuery, Pub/Sub, Dataflow y Kafka están en el siguiente artículo.
Contenido
Mapa de bases de datos
| Servicio | Modelo | Cuándo |
|---|---|---|
| Cloud SQL | Relacional (MySQL, PostgreSQL, SQL Server) | Apps tradicionales y migraciones sin cambios |
| AlloyDB | Relacional compatible con PostgreSQL | Cargas exigentes, HTAP, IA con búsqueda vectorial |
| Spanner | Relacional distribuido (GoogleSQL o PostgreSQL), también clave-valor y grafo | Escala horizontal y disponibilidad muy alta, global |
| Firestore | NoSQL documental | Apps web y móviles, serverless, también API compatible con MongoDB |
| Bigtable | NoSQL de columna ancha, clave-valor | Gran volumen, alto rendimiento y baja latencia: series temporales, IoT |
| Memorystore | En memoria (Redis, Valkey) | Cachés y sesiones con latencia de submilisegundos |
Cloud SQL
Base de datos relacional totalmente gestionada para MySQL, PostgreSQL y SQL Server. Se encarga de las copias de seguridad, la alta disponibilidad, la conectividad, la importación y exportación, el mantenimiento, la monitorización y los registros.
- Cada instancia es una VM con el motor de base de datos y un disco persistente, con una IP estática delante.
- Conectividad por IP pública o IP privada (solo desde una VPC), y autorización con el Cloud SQL Auth Proxy o los conectores de lenguaje.
- Crea bases de datos y usuarios, pero no es una herramienta de administración: se usan clientes como MySQL Workbench, pgAdmin o SQL Server Management Studio.
- El precio depende del almacenamiento, las CPU, la memoria, la ubicación, el tráfico de salida y las IP.
| Enterprise Plus | Enterprise | |
|---|---|---|
| SLA | 99,99 % (incluye mantenimiento) | 99,95 % (excluye mantenimiento) |
| Inactividad por operaciones planificadas | Menos de un segundo | Unos minutos |
| Retención de logs para PITR | Hasta 35 días | Hasta 7 días |
| Extras | Caché de datos, escrituras optimizadas, read pools, DR avanzada entre regiones, pooling de conexiones gestionado | Funciones básicas de Cloud SQL |
En MySQL 8.4 y 9.7 la edición por defecto es Enterprise Plus.
Cloud SQL: alta disponibilidad y réplicas
Alta disponibilidad (instancia regional)
- Instancia principal y standby en dos zonas de la misma región.
- Replicación síncrona: cada escritura llega a los discos de ambas zonas antes de confirmarse.
- Si falla la instancia o la zona, la standby pasa a ser la principal (failover). Después se puede hacer failback.
- Cuesta el doble que una instancia independiente.
Réplicas de lectura
- Copia de solo lectura actualizada casi en tiempo real para descargar consultas y analítica.
- No dan failover: para eso está la HA.
- Se recomiendan 10 réplicas directas como máximo; para más, réplicas en cascada.
- Pueden tener otro tamaño de máquina; si la principal crece en almacenamiento, ellas también.
| Tipo de réplica | Para qué |
|---|---|
| Entre regiones | Lecturas más cerca de la aplicación, recuperación ante la caída de una región y migración entre regiones (promocionándola) |
| En cascada | Réplicas de una réplica, para escalar lecturas |
| Externa | Réplica fuera de Cloud SQL |
| Desde un servidor externo | Migrar desde una base on-premises a Cloud SQL |
Buena práctica: con HA en la principal, coloca las réplicas en otra zona. Una réplica se puede promocionar a principal en un desastre regional o si la original se corrompe.
AlloyDB for PostgreSQL
Servicio totalmente gestionado y compatible con PostgreSQL, con un motor construido por Google y una arquitectura desagregada: el cómputo (nodos) y el almacenamiento (distribuido en varias zonas, crece solo) escalan por separado.
Clúster
Contenedor lógico de bases de datos y metadatos en una región.
Instancia principal
Lectura y escritura, una por clúster. HA (nodo activo y standby en zonas distintas) o básica (un nodo, para no producción).
Read pool
Instancias de solo lectura con balanceo automático, hasta 20 nodos en el clúster.
- Casos: HTAP (analítica sobre datos transaccionales vivos), IA de baja latencia con AlloyDB AI (búsqueda vectorial e invocación de modelos) y cargas críticas.
- Motor columnar en memoria para acelerar consultas analíticas, asesor de índices y autovacuum adaptativo.
- Copias bajo demanda y programadas, y recuperación a un momento dado.
- Cada instancia tiene una IP privada estática en tu VPC. Se administra con AlloyDB Studio en la consola o con clientes estándar como psql.
Spanner
Base de datos distribuida y totalmente gestionada con escala horizontal de lectura y escritura, sharding automático y consistencia fuerte. Admite los dialectos GoogleSQL y PostgreSQL, y modelos clave-valor, grafo (Spanner Graph), búsqueda de texto completo y vectorial. Al ser gestionada, no hay forma de detener o reiniciar una instancia.
Regional
Tres réplicas de lectura y escritura en tres zonas; quórum de escritura de dos de tres. SLA del 99,99 %.
Dual-region
Dos regiones del mismo país. 99,999 %. Solo en Enterprise Plus.
Multi-region
Más de dos regiones. 99,999 %. Solo en Enterprise Plus.
| Edición | Qué añade |
|---|---|
| Standard | Configuraciones regionales, copias programadas, PITR de 7 días, reverse ETL desde BigQuery |
| Enterprise | Spanner Graph, búsqueda de texto completo y vectorial, autoescalado gestionado, copias incrementales, réplicas de solo lectura opcionales |
| Enterprise Plus | Configuraciones dual-region y multi-region con hasta 99,999 %, geo-particionado |
- Capacidad de cómputo: en nodos o unidades de procesamiento (1 nodo = 1000 PU). Por debajo de un nodo hay que usar PU.
- Se puede mover una instancia de una configuración a otra (por ejemplo, de regional a multirregional) y crear configuraciones personalizadas con réplicas de solo lectura en otra región.
- Hay una instancia de prueba gratuita de 90 días.
Firestore
Base de datos documental NoSQL, totalmente gestionada y serverless: no se aprovisiona capacidad, escala sola y se paga por uso. Ofrece transacciones ACID, consultas con consistencia fuerte y latencia de lectura de un solo dígito en milisegundos.
Bibliotecas de Firestore
La opción recomendada para una base documental empresarial.
Compatibilidad con MongoDB
API compatible a nivel de protocolo para migrar apps de MongoDB tal cual, con mongosh, mongoimport o Compass.
Con Firebase
Backend como servicio para apps web y móviles, con los SDK y la consola de Firebase.
Disponibilidad: 99,99 % en ubicaciones regionales y 99,999 % en multirregionales, con replicación automática entre regiones.
Bigtable
Tabla dispersa que escala a miles de millones de filas y miles de columnas (terabytes o petabytes), ideal para grandes volúmenes de datos de una sola clave con baja latencia y mucho rendimiento de lectura y escritura. Compatible con la API de Apache HBase.
- Cada tabla es un mapa clave-valor ordenado. Solo se indexa la clave de fila; las columnas relacionadas se agrupan en familias de columnas.
- Datos típicos: series temporales, marketing, financieros, IoT, grafos. Cada valor suele ser de 10 MB como máximo.
- El rendimiento escala en proporción a los nodos; el clúster se redimensiona sin interrupción y puede autoescalar según la CPU.
- Para replicar, se añade un segundo clúster a la instancia y la replicación empieza sola.
- Ediciones Enterprise y Enterprise Plus. Prueba gratuita de 10 días ampliable a 90.
Memorystore
Servicio gestionado en memoria para cachés con acceso en submilisegundos: sesiones, consultas frecuentes, tablas de clasificación de juegos, analítica en tiempo real.
Memorystore for Redis
- Basic: instancia independiente. Standard: alta disponibilidad con hasta cinco réplicas en varias zonas y SLA del 99,9 %.
- Hasta 300 GB; lecturas escalables a cinco réplicas con el endpoint de lectura.
- Compatible con el protocolo de Redis: sin cambios de código.
- Solo IP privadas, IAM y cifrado en tránsito.
Memorystore for Valkey
- Valkey gestionado, con modo clúster activado (varios shards) o desactivado (un shard).
- Cada shard tiene un nodo principal y de 0 a 5 réplicas repartidas entre zonas.
- Admite un subconjunto de los comandos de Valkey.
Redundancia multirregional
El temario pide «maintaining multi-region redundancy across data solutions». Cada servicio lo resuelve de una forma:
| Servicio | Cómo protegerse de la caída de una región |
|---|---|
| Cloud SQL | Réplica de lectura entre regiones que se promociona; en Enterprise Plus, DR avanzada con replicación entre regiones |
| Spanner | Configuración dual-region o multi-region (Enterprise Plus) |
| Firestore | Ubicación multirregional, con replicación automática |
| Bigtable | Añadir clústeres en otras regiones a la instancia |
| Cloud Storage | Buckets en ubicaciones birregionales o multirregionales (artículo de almacenamiento) |
| BigQuery | Recuperación ante desastres gestionada: una multirregión no da redundancia entre regiones (siguiente artículo) |
Escenarios de examen
| Situación | Respuesta | Por qué |
|---|---|---|
| Migrar un MySQL on-premises sin cambiar la aplicación | Cloud SQL for MySQL | Relacional gestionado compatible. |
| PostgreSQL con consultas analíticas pesadas sobre datos transaccionales vivos | AlloyDB | HTAP con motor columnar. |
| Base relacional global con consistencia fuerte y 99,999 % | Spanner Enterprise Plus multirregional | Escala horizontal sin límites prácticos. |
| Backend de una app móvil con documentos JSON y sin aprovisionar capacidad | Firestore | Documental serverless con pago por uso. |
| Petabytes de series temporales de sensores IoT con latencia baja | Bigtable | Clave-valor de gran volumen. |
| Caché de sesiones con acceso en submilisegundos | Memorystore (Redis o Valkey) | Almacén en memoria gestionado. |
| Que Cloud SQL siga activo si cae una zona | Configuración de alta disponibilidad (regional) | Instancia standby en otra zona con failover. |
| Descargar consultas de informes de la instancia principal de Cloud SQL | Réplica de lectura | Copia de solo lectura casi en tiempo real. |
Trampas frecuentes del examen
❓ ¿Una réplica de lectura de Cloud SQL proporciona failover automático?
No. El failover lo da la configuración de alta disponibilidad. La réplica se puede promocionar a mano.
❓ ¿Cuánto cuesta una instancia de Cloud SQL con HA?
El doble que una instancia independiente.
❓ ¿Qué edición de Spanner necesitas para una configuración multirregional?
Enterprise Plus. Standard y Enterprise solo admiten configuraciones regionales.
❓ ¿Bigtable admite índices secundarios sobre cualquier columna?
No según su modelo: solo se indexa la clave de fila, por eso su diseño es clave.
❓ ¿Hay que aprovisionar capacidad en Firestore?
No. Es serverless y escala solo, con pago por uso.
❓ ¿Qué SLA tiene Memorystore for Redis Standard?
99,9 %, con réplicas en varias zonas. Basic no tiene alta disponibilidad.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una plataforma de pagos necesita una base de datos relacional con consistencia fuerte que acepte escrituras desde usuarios de varios continentes, escale horizontalmente y ofrezca la máxima disponibilidad posible. ¿Qué elige?
¿Listo para poner a prueba "Bases de datos en Google Cloud"?
Preguntas originales, cada una con su explicación.
Empezar un simulacro