Operational Databases: Cloud SQL, Spanner and Bigtable

Resumen

Las bases de datos operacionales son el suelo sobre el que se ejecuta el negocio: registran una venta, autorizan un pago, dan de alta a un cliente, escriben la telemetría de una flota. A diferencia del data warehouse, que responde a preguntas sobre el histórico, estas bases de datos responden a escrituras concurrentes en milisegundos y son la fuente de verdad de la aplicación. Este tema recorre el catálogo de bases de datos operacionales de Google Cloud —Cloud SQL, AlloyDB, Cloud Spanner, Cloud Bigtable y Firestore— con el criterio que ordena todo lo demás: cada problema de negocio tiene una base de datos cuyo modelo de consistencia, patrón de escalado y forma de coste encajan, y elegir mal se paga en latencia, en complejidad y en factura.

El recorrido va desde el servicio relacional gestionado más sencillo (Cloud SQL, con sus motores MySQL, PostgreSQL y SQL Server y su alta disponibilidad por réplica síncrona) hasta el motor relacional global con consistencia fuerte (Spanner), pasando por la base de datos PostgreSQL de nueva generación con almacenamiento y cómputo separados (AlloyDB), la base de datos de columnas anchas para series de tiempo (Bigtable) y la base de datos de documentos para aplicaciones cliente y mobile-first (Firestore).

El bloque final del tema es el de la migración y la modernización: Database Migration Service como vía gestionada y de bajo riesgo, Dataflow y Datastream como herramientas de movimiento de datos a escala, y el marco rehost / replatform / refactor aplicado al plano de datos. La conclusión de negocio es que la migración de datos no es un proyecto de Copiar-y-restaurar, sino una decisión de plataforma que debe justificarse con requisitos: consistencia, escala, latencia, coste y complejidad operativa.

Objetivos de Aprendizaje

Diferenciar las bases de datos operacionales de Google Cloud (Cloud SQL, AlloyDB, Cloud Spanner, Cloud Bigtable y Firestore) por modelo de datos, modelo de consistencia, patrón de escalado y caso de uso.
Explicar qué ofrece Cloud SQL como servicio relacional gestionado: motores soportados, alta disponibilidad regional, backups, Point-in-Time Recovery, réplicas de lectura y conectividad privada con Private Service Connect.
Describir la propuesta de valor de AlloyDB frente a Cloud SQL PostgreSQL: compatibilidad con PostgreSQL, arquitectura de almacenamiento y cómputo separados, y qué significa en coste y en escalado.
Explicar cómo Cloud Spanner ofrece consistencia fuerte y escalado horizontal global, y en qué casos de uso —banca, pagos, inventario global— esa combinación es un requisito y no un lujo.
Identificar Bigtable como base de datos NoSQL de columnas anchas para series de tiempo y analítica operacional, y Firestore como base de datos de documentos para aplicaciones cliente con sincronización en tiempo real.
Describir las rutas de migración y modernización de bases de datos: Database Migration Service, Dataflow, Datastream y el marco rehost / replatform / refactor aplicado al dato.
Traducir requisitos de negocio (consistencia, escala, latencia, coste) en una recomendación de base de datos sobre Google Cloud, justificando la elección con argumentos de arquitectura.

Contenido Principal

Subtema 1: El mapa de las bases de datos operacionales en Google Cloud

Antes de mirar productos, conviene fijar el criterio con el que se comparan. Una base de datos operacional se distingue del almacén analítico en tres rasgos: escribe datos como efecto de una acción de negocio, necesita devolver respuestas en milisegundos y sostiene concurrencia de escrituras. BigQuery, que es el centro de gravedad del dominio anterior, no cumple la segunda ni la tercera con la misma rapidez: su modelo de bytes escaneados y su ausencia de índices secundarios lo hacen inadecuado para el camino crítico de un checkout. Esa es la razón por la que los dos mundos conviven: la base de datos operacional guarda el estado actual y BigQuery consulta el histórico de ese estado.

Los cinco servicios que se estudian en este tema se separan en dos familias por el modelo de datos. La familia relacional —Cloud SQL, AlloyDB y Cloud Spanner— habla SQL, usa tablas con esquema y resuelve operaciones ACID. La familia NoSQL —Cloud Bigtable y Firestore— renuncia al esquema relacional y resuelve la escala de otra forma: Bigtable con un modelo de columnas anchas orientado a claves e intervalos de tiempo, y Firestore con un modelo de documentos JSON orientado a objetos y a sincronización.

La segunda dimension es el modelo de consistencia. Cloud SQL y AlloyDB ofrecen consistencia transaccional por instancia, y en configuración de alta disponibilidad por réplica, con consistencia de lectura local en la réplica (el replication lag es pequeño pero no cero). Bigtable ofrece consistencias ajustables por lectura, con granularidad por celda o por fila, un rasgo poco habitual y muy relevante para series de tiempo. Spanner ofrece consistencia fuerte (serializable) con sincronización de reloj entre réplicas: cualquier lectura devuelve el último dato comprometido, sin ventana de stale. Firestore ofrece consistencias ajustables también, con la particularidad de que sus clientes offline se sincronizan al recuperar la conexión.

La tercera dimensión es el patrón de escalado, y aquí está la diferencia que más se nota en un escenario de examen. Cloud SQL escala verticalmente y, en horizontal, mediante réplicas de lectura: es un patrón de escala vertical con lectura distribuida, adecuado para una carga de OLTP moderada con crecimiento previsible. AlloyDB escala horizontalmente separando el cómputo en réplicas escalables e independientes que comparten la capa de almacenamiento. Spanner escala horizontalmente sin límite práctico de particionado y, sobre todo, escala geográficamente sin renunciar a la consistencia. Bigtable escala por asignación de particiones de tablets entre nodos, con capacidad casi ilimitada y una latencia de milisegundos. Firestore escala de forma transparente, sin dimensionado.

La cuarta dimensión, la que más cuesta a los equipos no familiarizados, es la forma de coste y la complejidad operativa. Cloud SQL y AlloyDB se cobran por la máquina y el almacenamiento, con un modelo de coste estable y predecible y una operación sencilla, heredada del on-premise. Spanner cobra por las unidades de cómputo consumidas y por el almacenamiento, con una optimización notable del throughput en particiones. Bigtable cobra por los nodos de datos por hora y por el almacenamiento. Firestore cobra por operaciones de lectura, escritura y eliminación, más por almacenamiento, lo que hace que el patrón de consulta impacte directamente en la factura. El examinador evalúa si el candidato sabe razonar sobre esta diferencia: un equipo que elige Spanner para un ERP de una sola región está pagando por capacidades que no usa.

La consecuencia estratégica es que la elección del motor es, en realidad, una decisión de arquitectura de aplicación. Migrar de MySQL a Spanner no es un cambio de configuración, es un rediseño del modelo de acceso a datos: aparecen Spanner Emulator para desarrollo local, y herramientas de cliente como el JDBC driver con reintento automático, y cambian las transacciones multi-partición. Por eso, en el marco de modernización, el rehost es barato y rápido, el replatform es más costoso pero conserva SQL, y el refactor es un proyecto de software. Esa progresión de coste es exactamente la que hay que razonar en las preguntas de examen.

Subtema 2: Cloud SQL, la base de datos relacional gestionada

Cloud SQL es el servicio de bases de datos relacionales gestionadas de Google Cloud. Aporta instancias gestionadas de MySQL, PostgreSQL y SQL Server, con las tres capacidades que un DBA consideraría imprescindibles en un servicio gestionado: alta disponibilidad, copias de seguridad automáticas y actualización del motor gestionada por Google. Es la respuesta por defecto para una organización que tiene cargas transaccionales relacionales y no tiene un requisito que obligue a ir más lejos.

La alta disponibilidad se configura a nivel de instancia. Al activarla, la instancia mantiene una réplica síncrona en otra zona de la misma región, de modo que un fallo de zona o un reinicio de la instancia primaria no deja el servicio sin respuesta. El failover lo ejecuta Google de forma automática. El punto importante para el negocio es que la alta disponibilidad no es gratuita en latencia: la réplica síncrona implica que la primaria espera la confirmación de la réplica antes de devolver el commit al cliente, lo que añade latencia a cada escritura. Esa latencia es la contrapartida de no perder un commit. En un escenario donde el negocio pregunta "cuánto cuesta la HA", la respuesta es latencia de escritura, no dinero.

Cloud SQL ofrece dos mecanismos de recuperación. El primero son las backups (copias de seguridad) automáticas y manuales, gestionadas por el servicio, con una ventana de retención configurable. El segundo es el Point-in-Time Recovery (PITR), que permite restaurar la instancia a un instante concreto dentro del periodo de retención, combinando los backups automáticos con el registro de logs (binlogs en MySQL, Write-Ahead Log en PostgreSQL, transaction log en SQL Server). Para el negocio, la diferencia es relevante: el backup protege contra la corrupción o el borrado accidental de datos con granularidad de día; el PITR protege contra el error de una persona que ejecutó un DROP TABLE hace dos horas. Sin PITR, ese segundo escenario exige restaurar un backup de la noche anterior y perder medio día de operación.

Las réplicas de lectura resuelven un problema distinto: la carga de lectura no se puede atender solo desde la primaria. Una réplica de lectura es una instancia que replica de forma asíncrona desde la primaria y sirve consultas de solo lectura. El patrón típico es el read/write split en el que la aplicación enruta las escrituras a la primaria y las lecturas analíticas o de listado a la réplica, quitando carga del camino crítico. La contrapartida es la consistencia: una réplica de lectura puede devolver datos ligeramente retrasados respecto de la primaria. Si el caso de uso tolera ese retraso —un informe, un listado de catálogo, un panel—, es una buena solución y mucho más barata que escalar la primaria.

Sobre el backups, Cloud SQL añade la relación con Cloud Storage y con la protección de datos. Las copias de seguridad se cifran en reposo, y la organización puede usar claves de cifrado gestionadas por el cliente (CMEK) a través de Cloud KMS para tener control sobre el ciclo de vida de la clave. Los backups también pueden exportarse a Cloud Storage, lo que es relevante en dos situaciones: para replicar la base de datos en otra región por política de residencia de datos, y para que el equipo de analítica trabaje sobre el backup con BigQuery, sin tocar la producción.

La conectividad es el otro eje de diseño, y tiene impacto directo en la seguridad. Las conexiones IP públicas son el modo por defecto y el más simple de razonar, pero exponen la instancia a internet y requieren reglas de red de firewall y la configuración de authorized networks. Las conexiones privadas (Private Service Access) reservan un rango de IPs de la red VPC y permiten que el tráfico llegue a la instancia por la red interna, sin exposición pública. Private Service Connect (PSC) da un paso más: en lugar de compartir un rango de direcciones de la red VPC, la instancia recibe su propia dirección privada gestionada, sin requisito de rango de IP para los clientes, lo que simplifica la conectividad con otras nubes y con entornos on-premise a través de Cloud Interconnect. Para el negocio, la conclusión es que la exposición a internet de una base de datos transaccional es un riesgo que no compensa la comodidad del acceso público, y que en entornos con datos sensibles la conexión privada no es opcional.

Subtema 3: AlloyDB, PostgreSQL con almacenamiento y cómputo separados

AlloyDB for PostgreSQL es el servicio gestionado de Google Cloud para cargas PostgreSQL que necesita más escala y más separación entre la capacidad de cómputo y la de almacenamiento. Su compatibilidad con PostgreSQL es alta: los comandos psql, las extensiones, el framework de replicación lógica y las herramientas de administración son los del propio PostgreSQL, lo que hace que la migración desde una instancia self-managed sea mayormente un ejercicio de configuración y no de reescritura.

La diferencia arquitectónica con Cloud SQL es el punto clave del producto. En una instancia tradicional —incluida una instancia Cloud SQL— el almacenamiento de datos vive en el disco de la máquina virtual, y ampliar el almacenamiento exige redimensionar el disco, y ampliar el cómputo exige migrar a una máquina más grande con la correspondiente parada o proceso. AlloyDB desacopla ambas cosas: el almacenamiento vive en una capa de red de almacenamiento independiente y el cómputo se ejecuta en nodos escalables que se pueden añadir o retirar sin mover los datos. Esta es la misma idea que sostiene la escalabilidad horizontal de AlloyDB, en la que las réplicas de lectura son nodos de cómputo independientes que comparten el almacenamiento común.

La consecuencia práctica se ve en tres operaciones que en el modelo tradicional son caras. La primera es el scale-out de lectura: añadir capacidad de lectura consiste en añadir nodos de cómputo, no en clonar el almacenamiento. La segunda es el mantenimiento: las actualizaciones de PostgreSQL, las operaciones de mantenimiento del sistema de archivos y las operaciones de failover se gestionan sin impacto en el rendimiento de la instancia, algo que el producto permite. La tercera es la alta disponibilidad: AlloyDB mantiene una réplica regional con failover automático y una réplica de lectura, y ambos mecanismos existen sin que la réplica deba "competir" por el mismo almacenamiento.

Sobre esta base, AlloyDB añade un acelerador de consultas que actúa como una caché en memoria de resultados de consultas, con invalidación automática cuando los datos de base cambian. Es útil en el patrón clásico de OLTP con hottest reads repetidos: un catálogo o un catálogo de productos que se consulta millones de veces al día y cambia pocas veces. El acelerador no sustituye a un índice bien diseñado, pero reduce la latencia de las consultas repetidas sin que la aplicación tenga que cambiar. Además, AlloyDB añade columnar store, un motor de almacenamiento columnar integrado que acelera las consultas analíticas sobre datos operacionales, lo que resulta útil para informes que antes obligaban a duplicar el dato en un warehouse.

El caso de uso de negocio de AlloyDB es, por tanto, específico: aplicaciones transaccionales sobre PostgreSQL con crecimiento sostenido, Reporting mixto sobre el mismo dato, y una organización que quiere conservar el modelo relacional y la compatibilidad con el ecosistema PostgreSQL, pero necesita una capa de cómputo que escale de forma independiente. No es un sustituto directo de Cloud SQL en el sentido de "más rápido en todo": es una arquitectura distinta que gana cuando el crecimiento es horizontal y la carga analítica se mixes con la transaccional.

Subtema 4: Cloud Spanner, el relacional global con consistencia fuerte

Cloud Spanner es una base de datos relacional de Google Cloud con dos propiedades que la define de forma casi única en el mercado: escalado horizontal prácticamente ilimitado y consistencia fuerte distribuida global. El modelo de datos es SQL, con dialecto GoogleSQL (y compatibilidad con PostgreSQL mediante dialectos), tablas con clave primaria, índices secundarios y transacciones ACID. Lo que cambia respecto a una base de datos relacional clásica es el particionado: Spanner particiona automáticamente los datos por rango de claves —por defecto mediante range partitioning, con particionado por hash opcional—, y reparte esos fragmentos entre los nodos del servicio, de forma que la capacidad total crece con el número de nodos.

El modelo de consistencia es el elemento que hay que explicar con precisión. En un despliegue multi-región, cada región tiene un líder con revisión propia del log de transacciones, y un commit timestamp asignado de forma global. Cuando un cliente escribe, la transacción se confirma con un timestamp global; las lecturas pueden exigir que ese timestamp ya haya sido aplicado en la región de lectura, lo que introduce una espera acotada, pero nunca una lectura "stale" en el sentido de devolver un estado antiguo que ya fue superado. Esa es la diferencia con una réplica asíncrona: la réplica asíncrona devuelve el último estado recibido, que puede ser anterior a un commit ya confirmado. En Spanner, la lectura fuerte espera a que el commit sea visible, con un coste de latencia pequeño y acotado, y a cambio no se pierde ni se duplica una transacción. El modelo es external consistency y es la base de las operaciones financieras.

El coste de esa propiedad es que Spanner no es la opción más barata para una carga relacional sencilla. La unidad de facturación son las unidades de cómputo (nodes y processing units) más el almacenamiento, y el modelo de coste premia el uso eficiente: un diseño con claves mal distribuidas produce hot spots en un partición y desperdicia capacidad. La consecuencia para el examen es que la elección de Spanner exige un trabajo previo de diseño de esquema y de patrón de acceso, y ese trabajo es parte del coste del proyecto, no un detalle técnico.

El caso de uso de negocio es donde Spanner brilla, y es un tipo muy concreto. La bipartite financial core banking: un libro de cuentas que debe registrar todas las operaciones de una entidad con consistencia estricta y con disponibilidad en varias regiones, porque una caída de región no puede detener la operativa de pago. Los sistemas de pagos y processing de transacciones, donde la duplicación o pérdida de una operación es un incidente de negocio grave. El inventario global multi-país, donde la misma referencia de stock se consulta desdeRegions con baja latencia y se actualiza con frecuencia. Y los directorios de identidad y sesión, donde la escala de lecturas es enorme y la latencia debe ser estable.

La alternativa a Spanner en estos casos es la arquitetura tradicional con solución de problemas: réplicas por región sincronizadas de forma asíncrona, con reconciliación de conflictos y lógica de negocio que asume la posibilidad de conflicto. Ese diseño funciona, pero traslada el problema al código de la aplicación. Spanner intercambia un coste de plataforma (latencia de commit y cómputo adicional) por la eliminación de esa categoría de bug. La respuesta de un Digital Leader a "tenemos una base de datos global con conflictos de réplica" es, por tanto, la de dimensionar el coste de los conflictos: su materiality (revisiones, conciliación, incidencias) frente al coste de un modelo de consistencia fuerte gestionado.

Es importante saber también qué es Spanner y qué no es. No es un sustituto de un warehouse analítico: las consultas de agregación sobre históricos massivos siguen siendo territorio de BigQuery. No es la base de datos de un catálogo con diez tablas y mil usuarios, donde Cloud SQL o AlloyDB bastan y salen más baratos. Y no exime de diseñar el esquema: las limitaciones de hot spots son reales y las tablas con una clave primaria mal elegida concentran todo el tráfico en un nodo.

Subtema 5: Cloud Bigtable y Firestore, el NoSQL gestionado

Cloud Bigtable es una base de datos NoSQL de columnas anchas, optimizada para cargas de trabajo de series de tiempo y analítica operacional a gran escala. El modelo de datos es una jerarquía de tablas, familias de columnas y filas ordenadas por clave, con acceso eficiente por rangos de claves. Bigtable se inspiró en el sistema Bigtable de Google, sobre el que se construyeron algunos de los productos históricos de la compañía, y su caso de uso es precisamente el de las tablas de gran tamaño con acceso por rango.

Las características técnicas que definen Bigtable son coherentes con ese caso: el orden lexicográfico de las claves permite consultas de rango muy eficientes, como las que necesita un sistema de telemetría que agrupa eventos por dispositivo y ventana temporal; el modelo de columnas anchas permite que cada familia de columnas tenga su propio tipo y su propia granularidad de ttl; el escalado es horizontal por asignación de tablets entre nodos, con una capacidad de dato prácticamente ilimitada; y la latencia se mantiene en el orden de milisegundos con un perfil de coste que se ajusta al volumen de datos y al número de nodos.

Los perfiles de replicación de Bigtable suelen ser multi-cluster o multi-región, con una réplica en cada zona o región, y son la base de la disponibilidad. Bigtable ofrece además una interfaz compatible con HBase, una interfaz SQL (compatible con un subconjunto de ANSI SQL) y su integración natural con el ecosistema de datos: BigQuery Streaming Storage, Dataflow y Dataplex catalogan el dato de Bigtable, y Bigtable ofrece replicación hacia Cloud Bigtable en otra región o hacia otro servicio. En el mundo real, Bigtable es la base de datos detrás de sistemas de monitorización de infraestructura, registro y observabilidad, y también de plataformas de telemetría industrial.

Firestore es otro servicio NoSQL, con un modelo completamente distinto: es una base de datos de documentos. El dato es un documento JSON con identificador, y las consultas son sobre campos del documento, con índices gestionados automáticamente y soporte de consultas de rango y geoespaciales. Su diferencia estructural es el modelo de consistencia client-side: el SDK para clientes web y móvil mantiene una caché local de los documentos a los que la aplicación ha accedido, y escribe de forma optimista en local cuando el dispositivo está sin conexión; cuando la conexión vuelve, los cambios se sincronizan con el servidor. Esa sincronización en tiempo real es la razón de ser de Firestore, y determina su encaje: aplicaciones de cliente, mobile-first, offline-capable, con notificación en vivo ante cambios.

Las implicaciones de negocio de Firestore son coherentes con ese encaje. Un marketplace de segunda mano en el que el usuario navega con mala cobertura, añade productos al carrrito sin conexión y sube la foto cuando tiene señal; una app de banca con estado local de operaciones; una app de mensajería con feed en vivo. El modelo de precio acompaña al patrón: se factura por operaciones (lecturas, escrituras, borrados) más por almacenamiento, de forma que un cliente que hace polling frecuente de un documento para detectar cambios encarece la factura; la respuesta es usar los listeners en tiempo real, que entregan el cambiopush desde el servidor en lugar de repetir la lectura.

Firestore también ofrece una capa de query en SQL mediante la extensión de BigQuery para Firestore, que permite analizar el contenido de la base de datos de documentos desde BigQuery sin ETL intermedio. Esto conecta este dominio con el anterior: la separación entre el plano operativo y el plano analítico no se rompe con Firestore, simplemente el camino de la analítica pasa por una extensión en lugar de por una ingesta programada.

La elección entre Bigtable y Firestore, cuando ambos son NoSQL gestionado, se resuelve casi siempre por el tipo de objeto: series de tiempo de alta volumen, consultas por rango, retención por columna y analítica operacional → Bigtable; objetos JSON con esquema variable, sincronización offline en clientes y consultas por campo → Firestore. Si la carga es de estado de sesión o de perfil de usuario en una app con millones de usuarios activos simultáneos, Firestore es la respuesta habitual; si es un histórico de métricas de flota con millones de puntos por dispositivo y consultas por ventana temporal, Bigtable.

Subtema 6: Migrar y modernizar bases de datos a Google Cloud

La migración de bases de datos es un problema de negocio antes de ser un problema técnico. La pregunta que hay que responder no es "cómo muevo las tablas", sino "qué hago con la plataforma de datos después de la migración", y ese es el motivo por el que el marco de modernización en la nube es rehost / replatform / refactor, también aplicado al plano de datos.

Rehost significa mover la carga de trabajo al servicio gestionado equivalente sin cambiar el modelo de datos ni la lógica de aplicación. Una base de datos MySQL on-premise se replica a Cloud SQL con el mismo esquema, el mismo código de conexión y los mismos parámetros; los cambios son de configuración, de red y de proceso operativo. Es la ruta más rápida y de menor riesgo, y funciona bien cuando el motor ya está soportado y la carga no exige más.

Replatform significa migrar a una variante gestionada más avanzada del mismo modelo. Un PostgreSQL on-premise pasa a AlloyDB, o MySQL a Cloud SQL for MySQL con réplicas de lectura y conectividad privada. Aquí ya se aprovechan las capacidades del servicio (alta disponibilidad, PITR, réplicas), pero el modelo de datos sigue siendo relacional. Es la ruta que produce el mayor valor inmediato sin reescribir software.

Refactor significa rediseñar la aplicación para explotar un modelo de datos distinto. Un sistema de pedidos monolítico reescrito sobre Spanner, con particionado por cuenta y por tiempo, y con lógica transaccional adaptada. Es la ruta cara: exige reescribir consultas, revisar la semántica de las transacciones, y añadir observabilidad y pruebas. Se justifica cuando el requisito de negocio que la motiva (consistencia global, escala horizontal, latencia) no se puede cubrir con el modelo existente.

La herramienta que hace que el rehost y el replatform sean seguros es Database Migration Service (DMS), el servicio gestionado de migración de bases de datos de Google Cloud. DMS replica las bases de datos desde un origen on-premise o desde otra nube hacia un destino en Google Cloud, con soporte de migración homogénea (mismo motor, por ejemplo MySQL a Cloud SQL for MySQL) y migración heterogénea (motor distinto, por ejemplo MySQL a Cloud SQL PostgreSQL o a AlloyDB, con traducción de esquema y de DDL). La replicación usa un proceso continuo: el log binario o el WAL se replica desde el origen al destino, de modo que el cambio de cutover es un punto de control y no una ventana larga de inactividad. El cliente puede decidir hacer un corte abrupto, en el que la aplicación pasa a apuntar al destino de una vez, o un cutover con verificación previa, en el que el destino se replica en paralelo, se comparan los datos y luego se redirige el tráfico. Para el negocio, esto convierte una migración de semanas de inactividad en un cambio de configuración de DNS y un periodo de observación. DMS es, además, el camino que la propia documentación de Google Cloud recomienda cuando el destino es Cloud SQL, y hay una versión de DMS con Continuous Migration para escenarios de replicación continua.

Cuando la migración no es una copia de base de datos sino un movimiento de datos a escala o en tiempo real, las herramientas son otras. Dataflow es el framework de procesamiento de datos en streaming y batch de Google Cloud, basado en Apache Beam, que permite escribir jobs de ingesta y transformación en Java, Python o Go y ejecutarlos de forma gestionada. Es la herramienta cuando el dato hay que transformarlo: cleansing, normalización, deduplicación, enriquecimiento, o carga desde sistemas transaccionales hacia el warehouse con cambios incrementales. Datastream es un servicio de cambio data capture (CDC) gestionido que captura cambios de bases de datos de origen y los publica en tiempo real en destinos como BigQuery, Bigtable, Cloud Storage o Pub/Sub. Datastream es especialmente relevante en una arquitectura moderna: evita que los datos se copien por lotes, de modo que el histórico en el warehouse está siempre al día sin equipos que escrevan y mantengan scripts de extracción. La combinacióncharacteristic del patrón moderno es Database Migration Service para el plano transaccional, Datastream para la captura de cambios hacia el plano analítico, y Dataflow cuando hace falta transformar y enrichir. Sobre este marco se añade una decisión de gobierno que no es técnica: los datos que no deben salir del perímetro se pueden enmascarar con Cloud DLP antes de entrar en la ruta analítica.

Ejemplo Práctico: dimensionar y modernizar un workload transaccional

El siguiente guion gcloud muestra el ciclo completo de decisión: descubrir la instancia origen, crear el destino gestionado con alta disponibilidad y backups automáticos, configurar conectividad privada y cifrado con clave gestionada por el cliente, y verificar la salud del servicio. Cada comando tiene un equivalente en la consola de Cloud, pero la CLI es la forma más rápida de documentar la configuración desired state de la infraestructura de datos.

# 1. Inventario del estate actual: qué bases de datos relacionales existen
gcloud sql instances list --format="table(name,databaseVersion,region,state,settings.tier)"
gcloud sql backups list --instance=orders-prod --limit=5

# 2. Crear la instancia destino en alta disponibilidad, con PITR y CMEK
gcloud sql instances create orders-prod-v2 \
  --database-version=POSTGRES_16 \
  --tier=db-custom-8-32 \
  --region=europe-west1 \
  --availability-type=REGIONAL \
  --backup-start-time=03:00 \
  --point-in-time-recovery-enable \
  --enable-cmek-encryption \
  --kms-key-name=projects/finops/locations/europe-west1/keyRings/orders/cryptoKeys/datalake \
  --no-assign-ip

# 3. Conectividad privada: la instancia recibe su propia dirección con PSC
gcloud sql instances patch orders-prod-v2 \
  --enable-private-service-connect \
  --allowed-psc-projects=prod-platform

# 4. Crear la réplica de lectura para absorber el reporting
gcloud sql instances create orders-prod-v2-replica \
  --master-instance-name=orders-prod-v2 \
  --region=europe-west1 \
  --no-assign-ip

# 5. Crear el usuario de aplicación con la política de contraseñas adecuada
gcloud sql users create app_runtime \
  --instance=orders-prod-v2 \
  --password=SEGURO_DE_ALMACENAR_EN_SECRET_MANAGER \
  --type=built-in

# 6. Verificar el estado operativo antes de cortar el tráfico
gcloud sql operations list --instance=orders-prod-v2 --limit=10
gcloud sql instances describe orders-prod-v2 \
  --format="yaml(settings.availabilityType,settings.backupConfiguration,ipAddresses)"

La lectura de negocio de esta salida es directa. availabilityType: REGIONAL significa que la instancia tiene una réplica síncrona en otra zona y que un fallo de zona no interrumpe el servicio, con el coste de latencia de commit que implica. pointInTimeRecoveryEnabled: true con backupStartTime: 03:00 significa que la organización puede recuperar no solo el backup de las tres de la mañana, sino cualquier instante dentro del periodo de retención, lo que es la diferencia entre perder una noche de operación y perder una hora. no-assign-ip más --enable-private-service-connect significa que la base de datos transaccional que contiene datos de clientes no está expuesta a internet en ningún momento, y que el acceso desde la red interna se produce por una dirección privada dedicada, sin depender de un rango de IP compartido de la VPC. La réplica de lectura existe para que el reporting consumes desde una instancia secundaria, quitando las consultas analíticas del camino crítico de la compra. El kms-key-name con --enable-cmek-encryption significa que la organización conserva el control sobre el ciclo de vida de la clave de cifrado de los datos y de los backups, un requisito habitual en entornos financieros o con datos regulados.

La fase de corte, que en Database Migration Service se realiza desde el servicio o desde la consola de migraciones, es donde la verificación se vuelve crítica: la buena práctica es ejecutar el "replication verification" —comparar el número de filas y el checksum de las tablas entre origen y destino— antes de redirigir el tráfico de la aplicación. Ese paso es la diferencia entre una migración con plan de reversión y una migración sin red de seguridad.

Conceptos Clave

Concepto	Descripción	Cuándo usarlo
Base de datos operacional	Almacén que sostiene las escrituras y lecturas en el camino crítico de una acción de negocio	Cuando el sistema registra una operación y debe devolver respuesta en milisegundos
Consistencia fuerte (serializable)	Toda lectura devuelve el último estado comprometido, sin ventana de dato desactualizado	Banca, pagos, libro de cuentas, inventario global donde la duplicación es un incidente
Consistencia eventual	Una réplica puede devolver un estado anterior al último commit recibido	Reporting, listados de catálogo, cachés donde el retraso de milisegundos es aceptable
Alta disponibilidad regional	Instancia con réplica síncrona en otra zona y failover automático	Servicio crítico que no puede tolerar interrupciones por fallo de zona
Point-in-Time Recovery	Restauración a un instante arbitrario dentro de la ventana de retención	Protección frente a errores humanos como un `DROP TABLE` reciente
Réplica de lectura	Copia asíncrona que absorbe consultas de solo lectura	Reporting mixto, listados y consultas de alta frecuencia sobre el mismo dato
Private Service Connect	Dirección privada dedicada para la instancia, sin rango de IP compartido	Exposición mínima de datos sensibles, conectividad con otras nubes y on-premise
AlloyDB: almacenamiento y cómputo separados	Capa de datos desacoplada de nodos de cómputo escalables de forma independiente	PostgreSQL en crecimiento horizontal con reporting analítico sobre el mismo dato
Spanner: particionado y replicación multi-región	Datos fragmentados por rango de claves y réplicas con commit timestamp global	Aplicaciones transaccionales globales, core banking, pagos, identidad
Bigtable: columnas anchas y acceso por rango	Modelo orientado a clave con familias de columnas y ttl por columna	Telemetría, series de tiempo, analítica operacional de gran volumen
Firestore: documentos y sincronización offline	Modelo JSON con caché local en el cliente y reconciliación al reconectar	Aplicaciones mobile-first, marketplaces, apps con uso sin cobertura
Database Migration Service	Replicación gestionada de bases de datos con verificación y cutover controlado	Rehost o replatform con downtime mínimo y posibilidad de reversión
Datastream y Dataflow	CDC gestionado y procesamiento en streaming o batch	Captura de cambios hacia el plano analítico y transformaciones de ingesta

Comparaciones

Cloud SQL frente a AlloyDB

Criterio	Cloud SQL for PostgreSQL	AlloyDB for PostgreSQL
Arquitectura	Máquina virtual con almacenamiento en su disco	Almacenamiento y cómputo desacoplados, nodos independientes
Escalado	Vertical; horizontal mediante réplicas de lectura	Horizontal en lectura con nodos de cómputo adicionales sin mover datos
Mantenimiento	Actualizaciones gestionadas con ventana de impacto	Operaciones de mantenimiento sin impacto en el rendimiento
Capacidad diferencial	Simplicidad operativa y compatibilidad total con el motor	Acelerador de consultas y columnar store integrado
Encaje	Carga OLTP estable y de escala previsible	PostgreSQL en crecimiento sostenido con reporting mixto

Cloud Spanner frente a las alternativas

Criterio	Spanner	Réplica regional asíncrona (Cloud SQL/AlloyDB)	Base de datos local con particionado
Consistencia	Fuerte, serializable, global	Eventual en las réplicas	Local fuerte, sin réplica global
Escalado	Horizontal y geográfico	Limitada al plan de la instancia	Vertical y manual
Coste	Mayor por unidad de cómputo	Menor, con coste de la reconciliación de conflictos	Coste de infraestructura y de operación
Complejidad de aplicación	Baja: sin lógica de conflicto	Alta: la aplicación asume conflictos	Nula, pero sin resiliencia global
Encaje	Core banking, pagos, inventario global	Cargas regionales con tolerancia a retraso	Departamental, sin requisito de HA

Cloud Bigtable frente a Firestore

Criterio	Bigtable	Firestore
Modelo de datos	Filas, familias de columnas y claves ordenadas	Documentos JSON con campos indexados
Acceso característico	Rango de claves y series temporales	Consulta por campo y geoespacial
Sincronización offline	No es el caso de uso	Sí, con caché local en el cliente y reconciliación
Retención	TTL por familia de columnas	TTL por documento
Cobro principal	Nodos y almacenamiento	Operaciones de lectura y escritura más almacenamiento
Encaje	Telemetría, IoT, observabilidad, analítica operacional	Apps cliente, mobile-first, tiempo real

Opciones de migración de bases de datos

Enfoque	Herramienta	Downtime	Riesgo	Momento de la decisión
Rehost	Database Migration Service con motor equivalente	Minutos o cero	Bajo	Siempre es el primer paso
Rehost manual	Export/import con `pg_dump` o `mysqldump`	Ventana de inactividad	Medio	Entornos pequeños, una sola vez
Replatform	Database Migration Service heterogéneo o Dataflow para transformación	Minutos con verificación	Medio	Cuando el destino ofrece capacidades que el origen no tenía
Refactor	Rediseño de la aplicación sobre Spanner, Firestore o Bigtable	Semanas de release, con periodos de canary	Alto	Solo con un requisito de negocio que lo justifique
CDC continuo	Datastream hacia BigQuery o Bigtable	Cero	Bajo	Cuando el plano analítico no puede depender de lotes nocturnos

Vías de captura de datos hacia el plano analítico

Vía	Latencia	Carga en la aplicación	Caso típico
Exportación por lotes	Horas	Media	Reporting tradicional tolerante al retraso
Database Migration Service	Minutos	Baja	Replicación near-real-time de una base concreta
Datastream (CDC)	Segundos a minutos	Nula	Evento de cambio capturado desde el log transaccional
Dataflow (batch o streaming)	Variable	Nula	Transformación, enriquecimiento y carga al warehouse
BigQuery Streaming Storage	Cerca de tiempo real	Nula	Ingesta continua de eventos hacia el warehouse

Errores Comunes

Error: Elegir Cloud Spanner para toda base de datos relacional porque "es el producto más potente", y descubrir después que el coste por unidad de cómputo y la latencia de commit no compensan en una aplicación regional de tráfico moderado. → Solución: Empezar por el criterio de necesidad. Spanner se justifica cuando hay un requisito no negociable de consistencia fuerte global o de escalado horizontal geográfico. Para una carga OLTP regional con requisitos previsibles, Cloud SQL o AlloyDB ofrecen la misma semántica transaccional con un coste menor y menos complejidad de diseño. La regla práctica es que la sofisticación del motor debe estar respaldada por un requisito explícito, y no por una preferencia tecnológica.
Error: Confundir el backup automático con la recuperación del dato. Se restaura el backup más reciente y se descubre que el error se produjo dos horas después de ese backup. → Solución: Diferenciar el backup (punto de recuperación diario) del Point-in-Time Recovery (cualquier instante dentro de la ventana de retención, a costa del almacenamiento de logs). Habilitar PITR en toda instancia que contenga datos de producción y definir la retención en función del peor tiempo de detección del negocio. En el mismo marco, conviene ensayar la restauración periódicamente: un backup que nunca se ha restaurado no es un backup, es una hipótesis.
Error: Asumir que una réplica de lectura devuelve siempre el dato más reciente y construir encima lecturas que dependen de la frescura, por ejemplo mostrar el saldo de una cuenta justo después de una transferencia. → Solución: Documentar explícitamente la tolerancia de retraso por cada lectura. Las réplicas de lectura son asíncronas: su retraso es pequeño pero no cero, y crece con la carga de escritura. La arquitectura correcta enruta las lecturas que exigen frescura a la primaria y deja la réplica para listados, informes y consultas de alta frecuencia tolerantes al retraso. Es un requisito de diseño, no un ajuste de configuración.
Error: Planear la migración como una operación de fin de semana con un pg_dump y un restore, sin verificación de datos ni plan de reversión, en una base de datos de producción con millones de registros. → Solución: Usar Database Migration Service, que replica de forma continua desde el log transaccional, y ejecutar la verificación de replicación —comparación de recuento de filas y checksums por tabla— antes del corte. Definir el criterio de reversión antes de cortar y mantener el origen intacto hasta confirmar la operación del destino. El downtime debe ser el resultado de una decisión controlada, no el tamaño de la ventana de mantenimiento que el calendario permita.
Error: Dejar la base de datos transaccional con IP pública y reglas de firewall de amplio espectro "porque es más rápido de configurar", y trasladar a la nube sin revisar el modelo de exposición. → Solución: Diseñar la conectividad desde el principio con Private Service Connect o Private Service Access, con --no-assign-ip en las instancias de producción. La exposición pública de un almacén con datos de clientes es un riesgo que no se compensa con la comodidad del acceso directo, y su corrección posterior —activar PSC, rotar credenciales, revisar logs de acceso— es mucho más costosa que configurarlo bien durante la migración.

Puntos para el Examen

🎯 Punto clave 1: Las bases de datos operacionales de Google Cloud se distinguen por modelo de datos, consistencia, escalado y coste. Cloud SQL y AlloyDB son relacionales y se orientan a un motor existente; Spanner es relacional con consistencia fuerte global; Bigtable es NoSQL de columnas anchas para series de tiempo; Firestore es NoSQL de documentos con sincronización offline. La respuesta esperada a un escenario es siempre el servicio cuyo modelo encaja con el requisito citado en el enunciado, no el más potente.

🎯 Punto clave 2: Cloud SQL aporta alta disponibilidad regional con réplica síncrona (que implica latencia de commit), backups automáticos y Point-in-Time Recovery para restaurar a cualquier instante dentro de la ventana de retención, réplicas de lectura asíncronas para descargar consultas, y conectividad privada con Private Service Connect. AlloyDB va un paso allá con la separación entre almacenamiento y cómputo, que permite escalar la lectura sin mover datos y reduce el impacto del mantenimiento.

🎯 Punto clave 3: Spanner aporta lo que ninguna base de datos relacional clásica ofrece con facilidad: escalado horizontal y replicación multi-región con consistencia fuerte. Su caso de uso es el core banking, los pagos y el inventario global, donde una lectura desactualizada o una transacción duplicada son incidentes de negocio. Su contrapartida es un coste mayor por unidad de cómputo y la exigencia de un buen diseño de clave primaria para evitar hot spots.

🎯 Punto clave 4: La migración de datos sigue el marco rehost / replatform / refactor. Database Migration Service habilita rehost y replatform con replicación continua, verificación y cutover controlado; Datastream captura cambios en tiempo real hacia el plano analítico; Dataflow transforma y enriquece. El argumento de negocio que hay que dar es la reducción del downtime y del riesgo frente a una exportación manual, y la posibilidad de revertir el corte.

🎯 Punto clave 5: La selección de la base de datos se deriva de los requisitos, no de la moda tecnológica: consistencia (¿necesito serializable global o basta asíncrono regional?), escala (¿crece de forma horizontal o vertical?), latencia (¿la lectura tiene que ser inmediata o tolera retraso?), coste (¿qué modelo de facturación encaja con un patrón de uso irregular?) y complejidad operativa (¿el equipo sabe administrar lo que elige?). En un escenario con varias respuestas plausibles, la que gana es la que justifica su coste con el requisito explícito del enunciado.

Recursos Externos

Cloud SQL: overview del producto — Qué ofrece Cloud SQL como servicio relacional gestionado y qué motores admite.
AlloyDB for PostgreSQL: overview — Arquitectura con almacenamiento y cómputo separados, acelerador de consultas y columnar store.
Cloud Spanner: overview y arquitectura — Modelo de datos relacional, particionado, réplicas multi-región y modelo de consistencia.
Cloud Bigtable: overview del producto — Base de datos de columnas anchas para series de tiempo y analítica operacional.
Database Migration Service: overview — Migración heterogénea y homogenous, replicación continua y cutover controlado.

Autoevaluación Rápida

Pregunta: Una aseguradora tiene su libro de cuentas y su registro de siniestros en dos bases de datos relacionales separadas, y necesita que un equipo en otra región consulte saldos en tiempo real sin perder consistencia con la matriz contable. ¿Qué se recomienda y por qué no basta con una réplica de lectura? Respuesta: La recomendación es Cloud Spanner para el registro financiero y contable, por dos razones que hay que decir explícitamente. La primera es la consistencia fuerte con commit timestamp global: una consulta desde la otra región ve el último estado comprometido, sin la ventana de dato desactualizado que tiene una réplica asíncrona. La segunda es la disponibilidad multi-región sin pérdida de servicio ante un fallo de región. Una réplica de lectura no resuelve ninguno de los dos: es asíncrona, por lo que puede devolver saldos anteriores a un commit ya confirmado, y su failover regional es más artesanal. El coste de Spanner, mayor por unidad de cómputo, se compensa si el negocio pierde dinero con saldos incorrectos o con indisponibilidad; si la carga de consultas contables fuera muy baja y la latencia tolerable, una base con réplicas síncronas podría bastar, y eso también es una respuesta defendible siempre que se justifique con el criterio.
Pregunta: Un equipo tiene una base MySQL con 400 GB, un reporting semanal y un dashboard que consulta tablas con agregaciones de varios millones de filas, y el dashboard ha estado ralentizando las escrituras en picos. ¿Qué se hace con Cloud SQL? Respuesta: Separar la carga de lectura de la de escritura con réplicas de lectura. La instancia primaria queda dedicada a las escrituras del camino crítico y las consultas del dashboard y del reporting se enrutan a una réplica de lectura asíncrona, con el backend de la aplicación jugando con una configuración de enrutamiento. El punto que debe acompañar a la respuesta es que la réplica es asíncrona y que, por tanto, el retraso debe ser aceptable para las consultas que se dirigen a ella: un informe semanal y un dashboard lo toleran; el saldo de una cuenta en el momento de una transferencia, no. Si además el volumen de reporting creciera o la aplicación usara PostgreSQL, la alternativa a evaluar sería AlloyDB por su columnar store y su escalado horizontal de lectura. Conviene además activar PITR y backups automáticos, y la instancia en modo de alta disponibilidad regional.
Pregunta: Un fabricante quiere pasar sus 50 TB de telemetría de flota (dispositivo, timestamp, valor) de un Cassandra on-premise a Google Cloud, con consultas del tipo "todos los sensores del dispositivo X entre las 10:00 y las 12:00 del martes pasado". ¿Qué servicio y por qué no una base de datos de documentos? Respuesta: Cloud Bigtable. El patrón de la consulta es un acceso por rango de claves y por intervalo temporal sobre filas ordenadas lexicográficamente, con muchísimos puntos por dispositivo y ttl por familia de columnas para la retención, que es exactamente el terreno de un modelo de columnas anchas. Bigtable escala por asignación de tablets entre nodos, mantiene latencia de milisegundos y ofrece perfiles de replicación multi-cluster o multi-región para la disponibilidad. Un modelo de documentos como Firestore no encaja: la consulta por rango temporal sobre un volumen así y la retención por columna no son su fuerte, y el coste por operación de Firestore con ese patrón de acceso sería muy superior. Bigtable es además el destino natural de Datastream si se quiere además analítica en BigQuery sobre la misma telemetría.
Pregunta: Un retail tiene 12 TB en un SQL Server on-premise y decide migrar a Google Cloud. El negocio pide cero inactividad y que el sistema de origen siga disponible como reversión. ¿Qué ruta se elige y cómo se ejecuta? Respuesta: La ruta es rehost o replatform gestionado con Database Migration Service. Como el destino natural para SQL Server es Cloud SQL for SQL Server, se trata de una migración homogénea: DMS replica de forma continua usando el log de transacciones, de modo que el destino está al día casi en tiempo real mientras el origen sigue sirviendo tráfico. Antes del corte se ejecuta la verificación de replicación (comparación de recuento de filas y checksums por tabla) y se define el criterio de reversión. El corte consiste en redirigir la configuración de la aplicación y el DNS al destino, con un downtime mínimo en lugar de una ventana de fin de semana. El origen se mantiene intacto y sin decommissionar hasta que la operación en el destino esté confirmada, porque el plan de reversión solo existe si el sistema anterior sigue disponible. Si el destino fuera AlloyDB, la ruta sería replatform heterogéneo con traducción de esquema.
Pregunta: En un proyecto de modernización de datos, el negocio quiere que "la base de datos de pedidos sea más rápida" sin cambiar su modelo de datos, y además análisis en tiempo casi real en el warehouse. ¿Qué se propone y qué se descarta? Respuesta: Se propone una migración en dos carriles. En el plano transaccional, rehost o replatform hacia Cloud SQL o AlloyDB con Database Migration Service, conservando el modelo relacional, habilitando alta disponibilidad, PITR y réplica de lectura, y reduciendo el coste operativo de la administración del motor. En el plano analítico, CDC con Datastream desde la base de datos hacia BigQuery, que elimina los scripts de extracción nocturnos y mantiene el warehouse al día sin carga sobre la aplicación, con Dataflow solo si hace falta transformar o enriquecer. Se descarta el refactor sobre Spanner o Bigtable salvo que exista un requisito explícito que lo exija, porque su coste es de software y de riesgo, no de infraestructura, y aquí el problema descrito es de rendimiento y de retraso analítico. También se descarta el enfoque de copiar el histórico a mano cada noche, que es la causa directa del desfase del reporting.

Temas relacionados: Google Cloud Data Databases, BigQuery: Analytics Warehouse, Data Governance and Visualization, Cloud Modernization and Migration, Encryption and Key Management