Google Cloud Data and Databases Solutions

Resumen

Google Cloud no ofrece "una base de datos", sino una familia de servicios de gestión de datos que resuelven problemas distintos y, en algunos casos, complementarios: almacenamiento de objetos, bases de datos relacionales gestionadas, bases de datos relacionales globales, bases de datos NoSQL de documentos y NoSQL de columnas anchas, y data warehouse serverless para analítica. Elegir bien entre ellos no es una cuestión de gusto técnico sino de encaje entre el tipo de dato, el patrón de acceso, el perfil de consistencia requerido y la forma en que se factura el servicio.

Este contenido recorre los servicios del dominio de datos de Google Cloud con el enfoque del examen Google Cloud Digital Leader: no se trata de memorizar parámetros de configuración, sino de ser capaz de reconocer en un escenario de negocio qué servicio corresponde, por qué, y qué consecuencia de negocio tiene cada decisión. Se cubren los cuatro moldes de almacenamiento (objeto, relacional, NoSQL y analítico), el detalle de clases de almacenamiento de Cloud Storage y su relación con el coste y la frecuencia de acceso, el ciclo de vida del dato, y el encaje de Cloud SQL, AlloyDB, Cloud Spanner, Cloud Bigtable, Firestore y BigQuery.

También se explica por qué la nube cambia la economía del dato: al separar almacenamiento y cómputo, al facturar por uso y al ofrecer capacidad elástica sin aprovisionamiento, el coste marginal de explorar el histórico completo o de analizar datos no estructurados baja lo suficiente para que "preguntar cosas nuevas al dato" pase a ser una práctica habitual y no un proyecto. El resultado de negocio es un ciclo de decisión más corto, más informado y, sobre todo, más barato de repetir.

Objetivos de Aprendizaje

Diferenciar los cuatro moldes de almacenamiento de datos en Google Cloud —objeto, relacional, NoSQL clave-valor/documento/columna ancha y analítico— y explicar qué modelo de datos, latencia y consistencia ofrece cada uno.
Describir las cuatro clases de almacenamiento de Cloud Storage (Standard, Nearline, Coldline, Archive), su duración mínima, su frecuencia de acceso objetivo y el efecto directo que tienen en el coste.
Explicar cómo funciona el ciclo de vida (lifecycle management) en Cloud Storage y por qué es la palanca principal para reducir el coste del dato retenido sin perder la información.
Identificar el problema de negocio que resuelve cada servicio: Cloud SQL y AlloyDB como relacionales gestionados, Spanner como relacional global consistente, Bigtable como NoSQL de columnas anchas, Firestore como base de datos de documentos en tiempo real y BigQuery como analítica serverless.
Reconocer cuándo un servicio NoSQL es preferible a uno relacional y qué compromisos implica (renunciar a joins, asumir consistencia eventual, aceptar duplicación de datos).
Explicar cómo la nube desbloquea valor con datos estructurados y no estructurados, conectando servicios de almacenamiento, analítica y machine learning.
Resolver un escenario de negocio seleccionando el servicio adecuado y justificando la elección en términos de latencia, consistencia, coste y agilidad operativa.

Contenido Principal

Subtema 1: Los moldes de almacenamiento y la lógica de selección

El primer error que hay que evitar al recomendar un servicio de datos es tratar "Google Cloud" como un catálogo plano de alternativas intercambiables. Los servicios de datos de la plataforma no compiten entre sí por una misma cuota de mercado funcional: ocupan posiciones distintas en el espacio de diseño de un sistema, y la pregunta correcta nunca es "cuál es mejor", sino "cuál resuelve el patrón de acceso que tengo".

La forma más limpia de razonar es identificar cuatro moldes de almacenamiento, cada uno con su modelo de datos, su manera de organizar el acceso y su perfil de coste.

Almacenamiento de objetos (object storage). Guarda la información como objetos opacos dentro de contenedores lógicos llamados buckets. Un objeto es una secuencia de bytes más metadatos: no tiene esquema, no se consulta con SQL y no se actualiza parcialmente; se escribe, se lee o se borra como una unidad. Su interfaz es HTTP (o gsutil/gcloud storage), lo que significa que cualquier lenguaje, cualquier entorno y cualquier persona con permiso puede acceder. Es el molde adecuado para datos no estructurados (vídeo, imágenes, logs, binarios, archivos de audio) y, en general, para el histórico que se quiere conservar sin imponer un modelo. Cloud Storage es su implementación en Google Cloud.

Relacional (SQL). Almacena la información en tablas con esquema declarado: columnas tipadas, claves primarias, claves foráneas, restricciones de integridad y transacciones ACID. Su fortaleza es la consistencia y la capacidad de responder preguntas que requieren unir datos de varias entidades (un cliente, sus pedidos, sus facturas) mediante joins. Su coste es la rigidez: cambiar el esquema significa una migración, y el escalado vertical tiene un techo. En Google Cloud, Cloud SQL (MySQL, PostgreSQL, SQL Server), AlloyDB (PostgreSQL compatible con motor columnar) y Cloud Spanner son las tres opciones relacionales, y se diferencian por el perfil de escalado y consistencia.

NoSQL. Agrupa varios submodelos que comparten la idea de abandonar el esquema fijo y el join en favor del escalado horizontal. El submodelo clave-valor almacena un valor opaco bajo una clave y resuelve lecturas por clave en milisegundos. El submodelo de documento (Firestore) organiza la información en documentos JSON jerárquicos con campos indexados, que es el formato natural para contenido generado por aplicaciones móviles y web. El submodelo de columnas anchas (Bigtable) organiza los datos en filas ordenadas por clave y familias de columnas, donde solo se materializan los datos que realmente existen, lo que resulta muy eficiente para series temporales, telemetría y perfiles de usuario con atributos dispersos.

Analítico (data warehouse serverless). No es una base de datos de aplicación sino un motor pensado para leer muchos registros y devolver agregados. BigQuery es su implementación: separa almacenamiento y cómputo, factura por bytes escaneados en el modelo bajo demanda y por slots en el modelo de capacidad reservada, y no requiere administrar clústeres. Su caso de uso son las preguntas de negocio sobre histórico: ventas por región, cohortes de retención, margen por producto.

De los cuatro moldes, los tres primeros almacenan; el cuarto calcula sobre lo almacenado. Una arquitectura sana de datos usa los cuatro a la vez: el almacenamiento de objetos conserva el histórico bruto, la base de datos operacional sostiene el proceso en curso, y el motor analítico responde preguntas que ninguno de los dos anteriores debe atender.

Molde	Ejemplo en Google Cloud	Pregunta que responde	Estructura de acceso	Coste dominante
Almacenamiento de objetos	Cloud Storage	¿Qué tengo guardado y a qué coste puedo conservarlo?	Por clave y prefijo, vía API HTTP	Por GB/mes y por operaciones
Relacional gestionado	Cloud SQL, AlloyDB	¿Cuál es el estado actual y es coherente?	SQL sobre esquema fijo	Por instancia, IOPS y almacenamiento
Relacional global	Cloud Spanner	¿Cómo mantengo la coherencia entre regiones?	SQL con particionado horizontal	Por instancia, por nodo y por uso
NoSQL documento	Firestore	¿Cómo comparto datos en tiempo real con clientes?	Por documento y por colección	Por operaciones y por almacenamiento
NoSQL columnas anchas	Cloud Bigtable	¿Cómo sirvo acceso de baja latencia a alto volumen?	Por clave de fila y familia de columnas	Por nodo y por rendimiento
Analítico serverless	BigQuery	¿Cómo responde el histórico a preguntas de negocio?	SQL sobre columnas agregables	Por bytes escaneados o por slot

Subtema 2: Cloud Storage, clases de almacenamiento y ciclo de vida

Cloud Storage es, con diferencia, el servicio de datos más transversal de Google Cloud: aparece detrás de archivos de usuario, copias de seguridad, data lakes, exports, entregas de contenido y también como capa de almacenamiento de BigQuery cuando se usan tablas externas. Entender sus clases de almacenamiento no es un detalle de costes: es la forma en que una organización decide cuánto paga por conservar un dato que todavía no ha encontrado su consumidor.

El modelo de objetos. Un bucket es un contenedor global con nombre único dentro de su proyecto; los objetos se organizan con prefijo jerárquico en el nombre, y el "directorio" no es una entidad real sino una convención de nombres. Cada objeto tiene un nombre, un tamaño, una clase de almacenamiento, unos metadatos (content-type, fecha de creación, custom metadata), y un control de acceso propio heredado o sobrescrito. El acceso se hace con la API JSON de Cloud Storage o con gcloud storage, y la autorización se resuelve con IAM (roles como roles/storage.objectViewer o roles/storage.admin) más, en los casos de acceso desde aplicaciones, con claves HMAC o signed URLs. Las operaciones de listado de objetos son fuertemente consistentes desde 2022: crear, sobrescribir o borrar un objeto y listarlo inmediatamente después ya no tiene la ventana de inconsistencia que existía antes.

Las cuatro clases de almacenamiento. La clase no cambia el contenido del objeto, sino su precio y sus condiciones de permanencia y de recuperación. La elección se hace en función de con qué frecuencia se va a leer el dato.

Standard. Sin duración mínima de almacenamiento y sin cargos por eliminación anticipada. Es la clase por defecto y la indicada para datos que se leen con frecuencia: contenido activo, archivos de la aplicación, datos de una landing zone que se consulta a diario.
Nearline. Pensada para datos a los que se accede como máximo una vez al mes. Implica una duración mínima de almacenamiento de 30 días y un cargo por eliminación anticipada si se borra antes. A cambio, el precio por GB/mes es sensiblemente menor. El caso típico son los logs y las trazas que se conservan unos meses para diagnóstico o auditoría y que no se vuelven a tocar.
Coldline. Para datos con acceso como máximo una vez al año. Duración mínima de 90 días, con cargo por eliminación anticipada. Es la clase habitual de un data lake: histórico de eventos, exports de negocio, copias de datasets analíticos que se consultan en materiales de campaña o en auditorías puntuales.
Archive. Para datos que se consultan una vez al año o con menor frecuencia. Duración mínima de 365 días, la más restrictiva, y el precio por GB/mes más bajo. La recuperación tiene un coste por GB adicional y un tiempo mínimo de procesamiento más largo que en el resto de clases, lo que la hace inviable para consultas interactivas.

Los tres valores de disponibilidad mensual publicados son distintos por clase (99,99 % en Standard, 95 % en Nearline, 99 % en Coldline y Archive) y la durabilidad es de once nueves en todas ellas, es decir, la misma garantía de no perder el objeto. La consecuencia práctica: al bajar de clase no se arriesga la pérdida del dato, se arriesga la disponibilidad en la ventana de lectura y se asume un coste de recuperación.

Ciclo de vida (lifecycle management). Es la automatización que evita tener que decidir, objeto a objeto, en qué momento un archivo deja de merecer su precio. Se define por regla dentro de la configuración del bucket y opera de forma continua: cada objeto se evalúa contra las reglas y, cuando cumple las condiciones de edad, se transiciona a otra clase o se elimina. Las condiciones que se pueden combinar incluyen la antigüedad del objeto (age), la fecha de creación (createdBefore), el número de versiones más recientes (numNewerVersions) y prefijos de nombre (matchesPrefix), y las acciones disponibles son cambiar la clase de almacenamiento o borrar el objeto.

El patrón canónico de una empresa bien gobernada tiene tres reglas: mover a Nearline los objetos al mes de antigüedad, mover a Coldline al año y borrar a los cinco años, con una excepción por prefijo para el material que exige retención legal. La regla de borrado es tan importante como las de transición: un bucket sin regla de expiración se convierte en un archivo de coste creciente donde nadie sabe qué contiene, y es una de las fuentes más comunes de gasto no justificado en un entorno de datos.

Autoclass y control fino. Dos mecanismos complementan a las reglas por edad. El primero es Autoclass, que asigna automáticamente la clase de almacenamiento de cada objeto según sus patrones de acceso reales, sin que el equipo tenga que mantener las reglas: el bucket con Autoclass activado es la respuesta directa al caso en que la frecuencia de lectura de un objeto cambia de forma impredecible. El segundo es retention policy (con Bucket Lock), que impide borrar o sobrescribir objetos antes de un plazo determinado y que hace del bucket un repositorio apto para normativa de conservación; es lo que convierte un bucket de facturas en un archivo defendible ante una auditoría. Las legal holds permiten congelar objetos concretos de forma indefinida.

Clase	Duración mínima	Frecuencia de acceso objetivo	Disponibilidad mensual	Coste relativo de almacenamiento	Coste en lectura
Standard	Ninguna	Frecuente (diaria)	99,99 %	El más alto	Incluido
Nearline	30 días	Mensual	95 %	Alto	Cargo por GB recuperado, con mínimo de tiempo
Coldline	90 días	Anual	99 %	Bajo	Cargo por GB recuperado, con mínimo de tiempo
Archive	365 días	Anual o menor	99 %	El más bajo	Cargo por GB recuperado y tiempo mínimo más largo

Ejemplo Práctico

Este bloque sirve para auditar el coste dormido en un bucket y para dejar instaladas las reglas que lo corrigen. No sustituye a un diseño de retención, pero muestra los comandos reales con los que se inspecciona y se corrige.

# 1. Ver qué buckets existen y cuánto dato contiene cada uno
gcloud storage buckets list --project=PROJECT_ID

# 2. Inventario por clase de almacenamiento: aquí se ve el coste dormido
gcloud storage buckets gs://DATA_BUCKET list \
  --long --format="csv[no-heading]"

# 3. Consultar la configuración de lifecycle existente en el bucket
gcloud storage buckets describe gs://DATA_BUCKET \
  --format="yaml(lifecycle, retentionPolicy, autoclass)"

# 4. Aplicar reglas: Nearline a los 30 días, Coldline a los 90, borrado a los 1825
gcloud storage buckets update gs://DATA_BUCKET \
  --lifecycle-file=lifecycle.json

# 5. Punto de partida habitual del fichero de reglas
cat <<'EOF' > lifecycle.json
{
  "rule": [
    {
      "action": { "type": "SetStorageClass", "storageClass": "NEARLINE" },
      "condition": { "age": 30, "matchesPrefix": ["logs/"] }
    },
    {
      "action": { "type": "SetStorageClass", "storageClass": "COLDLINE" },
      "condition": { "age": 90 }
    },
    {
      "action": { "type": "Delete" },
      "condition": { "age": 1825 }
    }
  ]
}
EOF

# 6. Comprobar qué objetos siguen en una clase cara pese a su antigüedad
gcloud storage ls gs://DATA_BUCKET --recursive \
  --format="value(name,size,storage_class)" | sort -k2 -n

Lectura de la salida en términos de negocio. Si el paso 2 devuelve una mayoría de objetos en STANDARD con timeCreated de hace más de un año, la organización está pagando el precio de acceso frecuente por datos que nadie consulta: es gasto dormido, y la corrección no es "borrar" (eso es una decisión de negocio) sino "clasificar" con reglas de lifecycle. Si el paso 3 no devuelve ninguna regla lifecycle, no existe política de retención y el bucket crecerá sin control hasta que alguien detecte la factura. El detalle de matchesPrefix en la primera regla es lo que separa un dato que sí se consulta (los logs de una aplicación activa pueden necesitarlos para Support) de un histórico que solo se conserva por política. Y si el paso 6 revela objetos de gran tamaño en STANDARD que nunca se han descargado, la conversación con el negocio no es "¿lo borramos?", sino "¿qué proceso depende de que esto exista y por cuánto tiempo?".

Subtema 3: Bases de datos relacionales gestionadas: Cloud SQL y AlloyDB

El requisito que cubre esta familia es simple y frecuente: el negocio ya tiene una aplicación con una base de datos relacional y quiere dejar de operar la infraestructura, pero no quiere reescribir el modelo de datos. Aquí la pregunta no es qué motor es mejor, sino qué nivel de gestión se quiere y qué escala se espera.

Cloud SQL es el servicio gestionado de bases de datos relacionales para MySQL, PostgreSQL y SQL Server. Aporta la operación gestionada: alta disponibilidad regional con réplica síncrona, réplicas de lectura, copias de seguridad automáticas y recuperación a un momento dado (PITR), mantenimiento de la instancia, aplicación de parches y monitorización. Es el camino de menor fricción para migrar una carga existente, y su valor de negocio es directo: convierte un ticket de infraestructura ("hay que reiniciar el servidor por las 3 de la mañana") en un ticket de aplicación ("hay que ajustar un índice"). Las opciones Enterprise Plus añaden mayor capacidad de RAM y CPU por instancia, una ventana de mantenimiento más amplia para evitar interrupciones y un acuerdo de nivel de servicio más exigente; las réplicas entre regiones permiten recuperación ante desastres geográficos, un requisito habitual en la banca, el seguro y la salud.

AlloyDB es la alternativa de Google Cloud para PostgreSQL cuando el problema es de escala de lectura o de analítica sobre datos operacionales. Mantiene compatibilidad con PostgreSQL, lo que permite migrar desde Cloud SQL o desde bases autogestionadas sin cambios en la capa de aplicación, pero separa el almacenamiento (columnar) del cómputo, lo que permite escalar la memoria y la CPU de forma independiente del volumen almacenado. Sobre esa base añade un motor columnar para consultas analíticas sobre datos operativos, funciones de machine learning integradas y la edición Omni, que combina el almacenamiento columnar con un almacén de filas para las cargas mixtas. El argumento de negocio es que una misma base de datos puede servir a la aplicación transaccional y a los equipos de análisis sin obligar a copiar los datos a un warehouse y sin que esa copia quede obsoleta al día siguiente.

Cuándo usar cada una. El criterio se resume en cuatro preguntas: ¿existe ya una carga PostgreSQL que hay que mover sin reescribirla? (Cloud SQL); ¿la carga es PostgreSQL y el problema es que las lecturas analíticas degradan la aplicación? (AlloyDB); ¿la base es MySQL o SQL Server? (Cloud SQL, sin alternativas comparables); ¿hace falta consistencia global entre regiones? (Cloud Spanner, que se trata en el siguiente subtema).

El error de diseño más caro en esta familia es el intento de "usar la base de datos operativa como almacén analítico". Consultas que recorren millones de filas, Informes que agrupan por histórico completo y trabajos de ETL mal acotados compiten por los mismos recursos que las transacciones de producción. El síntoma es característico: latencia de consulta de la aplicación degradada de forma intermitente, con un pico de CPU que coincide con la ejecución nocturna de un informe. La respuesta no es "el servidor de base de datos es pequeño", sino separar los caminos: la base de datos sigue siendo la fuente de verdad, y el histórico se replica a BigQuery o se consulta con AlloyDB.

Capacidad	Cloud SQL	AlloyDB	Cloud Spanner
Motores	MySQL, PostgreSQL, SQL Server	PostgreSQL	SQL propietario sobre Spanner API
Escalado de cómputo	Vertical (más RAM/CPU por instancia)	Vertical e independiente del almacenamiento	Horizontal (aumenta el número de nodos)
Escalado de almacenamiento	Limitado por tipo de instancia y disco	Separado del cómputo, motor columnar	Automático, particionado por rango de claves
Coherencia	Regional (réplica síncrona en HA)	Regional	Strong y global, sin ventana de inconsistencia
Modo serverless	No (instancia siempre activa)	No	Opción de auto-scaling
Analítica sobre datos operativos	No es su propósito	Motor columnar integrado	No es su propósito
Casos de uso dominantes	Migración de cargas relacionales existentes	PostgreSQL a escala con lectura analítica	Sistemas globales multi-región

Subtema 4: Cloud Spanner: relacional, global y consistente

Cloud Spanner es el servicio que resuelve un problema que ninguna base de datos relacional tradicional resuelve sin renunciar a algo importante: cómo mantener una única fuente de verdad, transaccional y fuertemente consistente, repartida entre regiones de todo el mundo. Antes de la nube, esa combinación se resolvía con más de una base de datos y lógica de reconciliación, con el correspondiente coste en complejidad y en incoherencias aceptadas.

La clave técnica de Spanner es que no reparte los datos por disponibilidad sino por rango de claves. El esquema define una clave primaria, y Spanner la divide en rangos que se asignan a servidores (splits) que pueden estar en regiones distintas; las transacciones que tocan el mismo rango se serializan de forma natural, mientras que las que tocan rangos distintos se ejecutan en paralelo. Esto es lo que permite escalar horizontalmente sin renunciar al modelo relacional ni a las transacciones ACID. Además, Spanner usa su propio servicio de tiempo, TrueTime, para resolver el problema del reloj en un sistema distribuido: la marca temporal que devuelve TrueTime es precisa dentro de un intervalo conocido, lo que permite al sistema ordenar eventos sin depender de la sincronización de relojes entre máquinas. En la práctica, esto se traduce en que una escritura confirmada por Spanner es visible de inmediato en cualquier región, sin ventana de inconsistencia y sin depender de la asincronía de la replicación.

La consecuencia de negocio es la eliminación de un compromiso histórico. Una aplicación global —una plataforma con usuarios en Europa, América y Asia— que antes necesitaba bases de datos regionales más una capa de reconciliación puede tener una sola base de datos transaccional. Eso simplifica el modelo operativo, reduce el número de sistemas que hay que respaldar y auditar, y permite que una transacción que afecta datos de varias regiones se resuelva en una sola operación atómica, algo que en el diseño fragmentado era imposible o muy costoso.

Los casos de uso canónicos son coherentes con esa capacidad: libros contables y sistemas financieros, donde la consistencia transaccional entre centros de cálculo es un requisito regulatorio y no una preferencia; juegos y rankings de clasificación, donde el ranking global debe actualizarse de forma consistente para todos los jugadores a la vez; perfiles de usuario globales y catálogos de producto de grandes marketplaces; sistemas de inventario o de reservas donde no puede existir sobreventa por desincronización regional; y reemplazo de varios sistemas de bases de datos regionales por una arquitectura unificada.

También es importante reconocer los límites, porque la elección incorrecta de Spanner se paga en coste y en complejidad. Spanner no es el lugar adecuado para guardar archivos binarios (eso es Cloud Storage), ni para una aplicación CRUD pequeña y estable que se quedaría más barata en Cloud SQL, ni para cargas analíticas masivas sobre histórico (eso es BigQuery). Su modelo de coste —por instancias, por nodos y por unidades de procesamiento— es significativamente más caro que el de una instancia de Cloud SQL equivalente, y su curva de aprendizaje en el diseño de esquemas (interleaving, elección de la clave primaria, distribución del tráfico entre splits) es real. En un examen, un escenario con "aplicación global que necesita consistencia estricta en varias regiones" apunta a Spanner; un escenario con "app web con usuarios en un país y un ERP" apunta a Cloud SQL.

Ejemplo práctico para verificar encaje de servicio. Antes de recomendar Spanner, Cloud Bigtable o Firestore, conviene comprobar qué instancia el equipo tiene ya desplegada y con qué patrón de uso, porque el histórico de la organización suele ser la mejor evidencia:

# Bases de datos ya presentes en el proyecto: qué motor se usa hoy
gcloud sql instances list --project=PROJECT_ID \
  --format="table(name,databaseVersion,region,state)"

# Instancias de Spanner existentes y su estado
gcloud spanner instances list --project=PROJECT_ID \
  --format="table(name,config,state,nodeCount)"

# Instancias de Bigtable (NoSQL de columnas anchas)
gcloud bigtable instances list --project=PROJECT_ID \
  --format="table(name,state)"

# Bases de datos de Firestore (NoSQL de documentos)
gcloud firestore databases list --project=PROJECT_ID \
  --format="table(name,type,locationId,state)"

Lectura de la salida en términos de negocio. Si gcloud sql instances list muestra una instancia POSTGRES_14 en una sola región y el negocio pide "escalar para soportar una campaña en tres continentes", la salida es el punto de partida de la conversación: no se empieza por Spanner, se empieza por medir si el problema es de lectura (AlloyDB resuelve) o de consistencia global (Spanner resuelve). Si gcloud spanner instances list ya devuelve una instancia con nodeCount alto y en varias configs regionales, la organización ya hizo la inversión en globalidad, y la conversación pasa a ser sobre optimización de esquema y de claves. Y si no hay ninguna instancia en absoluto pero sí hay un bucket de Cloud Storage con exports, el problema de negocio típico es que la organización tiene los datos pero no un sistema operativo que los sirva: ahí la recomendación es Cloud SQL para una primera carga transaccional con esquema conocido, que es el camino de menor riesgo y de menor coste de entrada.

Subtema 5: NoSQL en la nube: Cloud Bigtable y Firestore

Cuando el modelo relacional se queda corto no siempre es por la técnica: es por el patrón de acceso. Los dos servicios NoSQL principales de Google Cloud cubren áreas distintas del espacio de diseño, y confundirlos es un error frecuente en el examen.

Cloud Bigtable es una base de datos de columnas anchas (wide-column) optimizada para cargas de muy alto volumen y baja latencia. El modelo es el siguiente: las filas se ordenan por una clave de fila, los datos se agrupan en familias de columnas y solo se materializa lo que realmente se ha escrito. No hay joins, ni índices secundarios, ni un esquema con columnas fijas: la estructura emerge del propio dato. Esa sparseza es su virtud: un perfil de usuario con mil atributos dinámicos ocupa lo que ocupa, y un conjunto de series temporales con millones de puntos se almacena sin penalización por columnas vacías.

Sus fortalezas técnicas son la latencia en el percentil 99 (decenas de milisegundos, con un diseño orientado a la previsibilidad), el escalado horizontal casi lineal y una capacidad de caudal (throughput) muy alta. Bigtable es la base sobre la que se construyen cargas como la telemetría de IoT, los logs y la monitorización de infraestructura, los perfiles de usuario de sistemas de recomendación, el historial de eventos de aplicaciones de alta concurrencia y las series temporales de precios o de sensores. Es también la base técnica habitual de los pipelines en streaming: Dataflow escribe en Bigtable y el consumo se hace desde ahí.

Sus límites son explícitos y hay que conocerlos: sin joins (el modelo de datos se desnormaliza por adelantado), sin índices secundarios (el acceso se hace por clave de fila, y los patrones de acceso se diseñan en consecuencia, con prefijos de clave y tablas de lookup), sin funciones analíticas. Bigtable no sustituye a un warehouse ni a una base relacional; convive con ellas. Bigtable interactúa con el resto de la plataforma a través de clientes, una API compatible con HBase para herramientas existentes, y un soporte de machine learning integrado.

Firestore es una base de datos de documentos serverless, con un modelo de datos de documentos JSON anidados y jerárquicos (colecciones que contienen documentos, que a su vez pueden contener subcolecciones). Su rasgo diferencial no está en el modelo, sino en la experiencia de consumo: el SDK para web, iOS y Android ofrece sincronización en tiempo real, resolución de conflictos, funcionamiento offline y listeners en vivo, de modo que una aplicación móvil mantiene su estado local y se sincroniza con la nube sin que el equipo implemente su propio protocolo de sincronización. Es el almacén natural para perfiles de usuario, contenido generado por el cliente, carritos, chats, progreso de partida, listas de Favoritos y cualquier aplicación con usuarios finales móviles.

Firestore tiene dos modos de operación, y la diferencia importa en la decisión: el modo Native ofrece consultas compuestas, la semántica transaccional completa y un modelo de seguridad basado en reglas; el modo Datastore es el modo heredado, con consultas no relacionales heredadas del producto anterior, pensado para aplicaciones de altísimo volumen que ya funcionaban con ese modelo. Firestore se factura por operaciones y por almacenamiento, no por instancia gestionada, lo que lo hace especialmente adecuado para aplicaciones con tráfico irregular: no hay que dimensionar un servidor para el pico.

La diferencia práctica entre Bigtable y Firestore puede resumirse así: Bigtable es para máquinas y para volumen (telemetría, series temporales, historial masivo, pipelines de streaming, acceso programático); Firestore es para personas y para apps (sincronización con dispositivos, datos poco relacionales, experiencias de usuario en tiempo real). Un escenario de examen que menciona "datos de sensores de 50.000 dispositivos con consultas de baja latencia sobre el histórico reciente" apunta a Bigtable; uno que menciona "sincronización offline en una app móvil con datos de perfil y lista de tareas compartida" apunta a Firestore.

Eje	Bigtable	Firestore	Cloud SQL
Modelo de datos	Filas ordenadas por clave, familias de columnas	Documentos JSON anidados	Tablas con esquema fijo
Acceso típico	Por clave de fila y prefijo de clave	Por documento, colección y campo indexado	SQL con joins e índices
Consumidor típico	Pipelines de streaming, telemetría, IoT	SDKs de web, iOS y Android	Aplicación de negocio y reporting transaccional
Latencia	Milisegundos en percentiles altos	Milisegundos en camino de la escritura	Milisegundos en OLTP
Modo de operación	Instancia administrada (nodos)	Serverless, escala automática	Instancia administrada
Capacidad diferenciada	Volumen muy alto y sparseza	Sincronización offline y tiempo real	Integridad referencial y transacciones ACID
No ofrece	Joins, índices secundarios, analítica	Joins, datos fuertemente relacionales	Sincronización offline nativa

Subtema 6: BigQuery y el valor de negocio de la nube para los datos

BigQuery es el data warehouse serverless de Google Cloud, y su llegada al mercado cambió la ecuación económica del análisis de datos. Antes, un warehouse exigía un clúster que había que dimensionar, presupuestar y mantener, y la consecuencia organizativa era que solo los equipos de datos podían responder preguntas: el acceso estaba reservado a quienes sabían escribir SQL y tenían permisos. BigQuery elimina el clúster y elimina la barrera de entrada.

El diseño serverless se apoya en dos decisiones: el almacenamiento vive en columnas comprimidas, con precio por GB y sin coste por servidor, y el cómputo se factura por el volumen de datos que la consulta necesita escanear (modelo bajo demanda) o se reserva como capacidad por slots (modelo de Slots, orientado a cargas sostenidas con SLA). Esa separación explica por qué BigQuery es la opción natural para una organización que quiere "hacer una pregunta nueva" sin justificar la inversión en infraestructura: si la pregunta se hace una vez al mes, el modelo bajo demanda cobra por esa ejecución; si la carga es continua, se reserva capacidad y el coste por unidad de trabajo baja.

La técnica de rendimiento se apoya en dos palancas que conviene nombrar porque aparecen en cualquier conversación sobre coste de BigQuery: el particionado (por fecha de ingestión, de forma que la consulta solo toca las particiones necesarias) y el clustering (por columnas frecuentemente filtradas, que reduce el número de bloques leídos). Ambas cosas son, en el fondo, medidas de coste: una consulta mal planteada que escanea la tabla completa es un problema de factura, no un problema de servidor.

Además, BigQuery se integra con el resto de la plataforma: BigLake permite consultar datos directamente en Cloud Storage sin moverlos y con control de acceso unificado; las tablas externas admiten datos en otra nube o en sistemas de bases de datos relacionales; Dataflow ejecuta pipelines de ingesta y transformación; Pub/Sub aporta la captura de eventos en tiempo real; Vertex AI permite aplicar machine learning sobre los datos sin exportar el dataset; y Data Catalog da a los equipos un punto de descubrimiento con linaje y metadatos.

Cómo la nube desbloquea valor con datos estructurados y no estructurados. El argumento de negocio tiene cuatro partes. Primero, elasticidad sin aprovisionamiento: no hay que anticipar el volumen ni comprar capacidad por adelantado, así que una campaña estacional, un producto nuevo o una nueva línea de negocio se pueden atender sin dimensionar infraestructura permanente. Segundo, coste marginal decreciente del análisis: preguntar al histórico completo cuesta lo que cuesta esa consulta, y como los datos estructurados y no estructurados conviven en almacenamiento de objetos barato, la analítica exploratoria se vuelve una rutina y no un proyecto; una organización que responde veinte preguntas al mes en lugar de dos aprende veinte veces más sobre su negocio. Tercero, servicios especializados que antes no eran viables: servicios como Vision AI, Video Intelligence, Natural Language o Translation convierten un activo no estructurado —un vídeo de inspección de calidad, una factura escaneada, millones de reseñas— en datos consultables, y su coste por unidad hace viable analizarlo masivamente. Cuarto, desacoplamiento entre el sistema que captura y el que consume: con Pub/Sub, Dataflow y las tablas externas, el dato puede llegar al warehouse sin que la aplicación de origen tenga que saber quién lo va a consumir.

El mapa de encaje que hay que memorizar para el examen, resumiendo en una frase cada servicio:

Tipo de dato	Caso de uso	Servicio	Razón de la elección
Archivos, backups, vídeo, imágenes, logs	Conservar y recuperar sin esquema	Cloud Storage (Standard, Nearline, Coldline, Archive)	Object storage serverless con clases que ajustan el coste a la frecuencia de acceso
Transacciones con esquema fijo (ERP, CRM, e-commerce)	Fuente de verdad de la aplicación	Cloud SQL (MySQL, PostgreSQL, SQL Server)	Relacional gestionado con HA, backups y PITR, mínima fricción de migración
PostgreSQL a escala con lectura analítica	Alta concurrencia de lectura sobre datos operativos	AlloyDB	Separación cómputo/almacenamiento y motor columnar, sin salir de PostgreSQL
Sistema global multi-región con consistencia estricta	Libro contable, ranking de juego, reservas	Cloud Spanner	Relacional con particionado horizontal global y coherencia fuerte
Series temporales, IoT, telemetría, historial de eventos	Alto volumen, baja latencia, clave de fila	Cloud Bigtable	Wide-column, sparse y escalable, con acceso por clave
Perfiles, contenido de usuario, sincronización en dispositivos	App móvil/web con datos en tiempo real	Firestore	Documentos serverless con SDK de sincronización offline y realtime
Histórico y preguntas de negocio agregadas	Reporting, KPIs, BI, analítica exploratoria	BigQuery	Data warehouse serverless con SQL y facturación por uso

Temas relacionados: Data-Driven Business and Transformation · BigQuery and Enterprise Data Warehousing · Operational Databases and Cloud Migration · Data Governance, BI and Visualization with Looker · Cloud Modernization and Migration Strategies

Conceptos Clave

Concepto	Descripción	Cuándo usarlo
Object storage	Almacenamiento de objetos opacos con metadatos, accesible por API HTTP, sin esquema ni actualización parcial	Archivos, backups, vídeos, logs, data lake y cualquier dato cuya forma no se conoce de antemano
Clase de almacenamiento	Nivel de precio, permanencia y disponibilidad de un objeto en Cloud Storage	Elegir por frecuencia de acceso real del dato: Standard, Nearline, Coldline o Archive
Lifecycle management	Reglas automáticas que transicionan o borran objetos según su edad, fecha o prefijo	Reducir el coste del dato retenido y hacer efectiva la política de retención de la organización
Autoclass	Asignación automática de clase de almacenamiento según los patrones de acceso observados	Buckets cuyo acceso es impredecible y donde mantener reglas por edad es costoso
Retention policy	Bloqueo de borrado o sobrescritura hasta una fecha, con Bucket Lock	Repositorios de facturas, contratos o registros sujetos a conservación legal
Relacional (SQL)	Modelo con esquema declarado, tablas, claves, integridad referencial, joins y transacciones ACID	La fuente de verdad de una aplicación de negocio con entidades relacionadas
NoSQL	Familia de modelos sin esquema fijo, optimizado para el escalado horizontal y la latencia constante	Volumen alto, atributos dispersos, series temporales o sincronización cliente
Wide-column (Bigtable)	Filas ordenadas por clave con familias de columnas, materializadas solo si existen	IoT, telemetría, monitorización, historial de eventos y perfiles con atributos dinámicos
Documento (Firestore)	Unidades JSON jerárquicas con campos indexados, agrupadas en colecciones y subcolecciones	Apps móviles y web con datos de usuario y sincronización en tiempo real
Consistencia fuerte	Garantía de que una escritura confirmada es visible de inmediato en todas las regiones	Spanner, para sistemas globales donde la incoherencia no es aceptable
Escalado horizontal	Aumento de capacidad añadiendo nodos o particiones en lugar de agrandar una instancia	Cuando el cuello de botella es el volumen o la distribución geográfica, no la capacidad de una máquina
Data warehouse serverless	Motor analítico sin clúster, con almacenamiento y cómputo separados y facturación por uso	Reporting, KPIs y analítica exploratoria sin gestionar infraestructura de datos
Particionado y clustering	Técnicas de disposición física de los datos en BigQuery que reducen los bytes escaneados	Control del coste de consulta y de los tiempos de respuesta en tablas de gran volumen
BigLake	Capacidad de consultar y gobernar datos en Cloud Storage directamente desde BigQuery	Cuando el histórico vive en almacenamiento de objetos y el volumen o la retención lo justifican

Comparaciones

Los servicios de datos de Google Cloud, cara a cara

Servicio	Modelo de datos	Tipo de dato principal	Caso de uso principal	Modo de escalado	Consistencia	Eje de precio
Cloud Storage	Objetos y buckets	No estructurado, semiestructurado y cualquier tipo de archivo	Conservación, data lake, backups, entrega de contenido	Automático, sin capacidad que aprovisionar	Consistencia fuerte y durabilidad	Por GB/mes, clase y operaciones
Cloud SQL	Tablas SQL con esquema fijo	Estructurado y transaccional	Fuente de verdad de ERP, CRM, e-commerce y apps	Vertical (más vCPU/RAM)	ACID en la instancia, replicación regional en HA	Por instancia, almacenamiento y IOPS
AlloyDB	PostgreSQL con motor columnar	Estructurado transaccional más columnas	PostgreSQL a escala con lectura analítica integrada	Vertical e independiente del almacenamiento	ACID, replicación regional	Por instancia y capacidad columnar
Cloud Spanner	Tablas particionadas por rango de clave	Estructurado, relacional, global	Libros contables, juegos, reservas, perfiles globales	Horizontal y geográfico	Strong y global	Por instancias, nodos y unidades de cómputo
Cloud Bigtable	Filas por clave con familias de columnas	Semiestructurado y de alta cardinalidad	Series temporales, IoT, telemetría, historial	Horizontal casi lineal	Consistencia por clave	Por nodo y por rendimiento
Firestore	Documentos JSON anidados	Semiestructurado orientado a documentos	Sincronización offline y datos en tiempo real para apps	Automático y serverless	Strong con resolución de conflictos	Por operaciones y almacenamiento
BigQuery	Tablas columnales con esquema flexible en la lectura	Estructurado y analítico sobre histórico	Reporting, KPIs, BI y analítica exploratoria	Serverless, por demanda o por slots	Consistencia de lectura fuerte por tabla	Por bytes escaneados o por slot reservado

Relacional frente a NoSQL: qué se gana y qué se cede

Eje	Relacional	NoSQL
Esquema	Declarado por adelantado y validado	Flexible, definido por el dato escrito
Integridad	Restricciones, claves foráneas, ACID	Validación en la capa de aplicación
Relaciones	Joins nativos entre entidades	Desnormalización y consultas precalculadas
Escalado	Vertical por defecto, con límites	Horizontal por diseño
Latencia a alto volumen	Degrada con la concurrencia	Se mantiene estable
Operativa	Planos y estabilidad de requisitos	Flexibilidad con coste en consistencia y modelado

Clases de almacenamiento de Cloud Storage frente a la decisión de acceso

Criterio	Standard	Nearline	Coldline	Archive
Frecuencia de lectura	Continua	Al menos mensual	Anual o menos	Anual o menos
Duración mínima	Ninguna	30 días	90 días	365 días
Cargo por eliminación anticipada	No	Sí	Sí	Sí, el más alto
Interactividad de la lectura	Inmediata	Interactiva	Interactiva	No interactiva, con retardo adicional
Uso recomendado	Datos activos	Logs y trazas	Histórico y data lake	Copias de archivo y conservación legal

Errores Comunes

Error: Tratar Cloud Storage como "un disco grande" y dejar todos los objetos en la clase Standard, olvidando Nearline, Coldline, Archive y el lifecycle. → Solución: Definir desde el primer día la política de retención por antigüedad y por tipo de dato, e instalarla como reglas de lifecycle en el bucket, con Autoclass como respaldo cuando el patrón de acceso sea irregular. Revisar además qué parte del bucket es histórico de sistema frente a dato con dueño y caso de uso. Un bucket sin reglas de expiración convierte la retención de datos en un problema de factura en lugar de un problema de gobierno.
Error: Usar la base de datos relacional (Cloud SQL o AlloyDB) para el reporting y para el histórico, saturando la instancia de producción y degradando la aplicación. → Solución: Mantener la base de datos como fuente de verdad transaccional y enviar el histórico a BigQuery, por extracción por lotes o por streaming con Dataflow y Pub/Sub. Cuando el reporting relacional es intenso pero la carga es PostgreSQL, AlloyDB con motor columnar es la alternativa intermedia; el criterio de diseño sigue siendo que el camino analítico no compita con el camino transaccional.
Error: Recomendar Cloud Spanner para cualquier aplicación relacional "porque es global y moderno", o Bigtable/Firestore indistintamente como "NoSQL". → Solución: Anclar la recomendación en el patrón de acceso y el requisito de consistencia. Spanner se reserva para sistemas multi-región con consistencia estricta (libros contables, rankings, reservas) donde el coste de la distribución global está justificado; un CRUD regional se resuelve mejor y más barato en Cloud SQL. Bigtable responde a volumen alto con acceso por clave (IoT, series temporales, streaming); Firestore responde a aplicaciones con usuarios finales y sincronización offline. Confundir los dos NoSQL lleva a elegir un modelo de datos que no encaja con el patrón de lectura de la aplicación.
Error: Asumir que mover un sistema a la nube es una simple migración de lift-and-shift, ignorando la elección del modelo de datos. → Solución: Tratar la migración como una decisión de modelo de datos, no de infraestructura: identificar qué parte de la carga es transaccional, qué parte es analítica y qué parte es archivo, y asignar a cada una el servicio que corresponde (Cloud SQL/AlloyDB, BigQuery y Cloud Storage). Empezar por replicar el modelo relacional tal cual es una decisión legítima y de bajo riesgo, pero solo si se acompaña de un plan para la analítica y para el histórico; de lo contrario, el coste de la base de datos operativa crece sin que nadie lo haya decidido.
Error: Confundir la disponibilidad de una clase de almacenamiento con su usabilidad, o usar Archive como si fuera una clase de "archivo barato y consultable". → Solución: Vincular cada clase a una expectativa operativa: Standard para el dato activo, Nearline para lo que se consulta cada mes, Coldline para el histórico de lectura anual y Archive solo para lo que se conserva con una periodicidad de un año o más. Un dato en Archive no se abre por curiosidad: su recuperación tiene coste por GB y un retardo de procesamiento que lo hace inviable para una consulta interactiva, y borrarlo antes del año tiene penalización. Si la organización necesita "abrir el histórico a demanda", debe diseñar la retención en Coldline, no en Archive.

Puntos para el Examen

🎯 Punto clave 1: La lógica de selección de servicio de datos se resuelve por molde de almacenamiento, no por marca. Object storage (Cloud Storage) para archivos y dato sin esquema; relacional (Cloud SQL, AlloyDB, Spanner) para datos estructurados con integridad y transacciones; NoSQL (Bigtable de columnas anchas, Firestore de documentos) para volumen alto o sincronización en tiempo real; analítico serverless (BigQuery) para el histórico y las preguntas de negocio agregadas. Ante un escenario con cinco servicios de Google Cloud sobre la mesa, identifica primero el tipo de dato y el patrón de acceso, y después el nombre del servicio.

🎯 Punto clave 2: Las clases de almacenamiento de Cloud Storage son una decisión de negocio disfrazada de configuración técnica. Standard sin duración mínima para dato de acceso frecuente; Nearline con 30 días y acceso mensual; Coldline con 90 días y acceso anual; Archive con 365 días y el precio más bajo pero con retardo de recuperación. La retención efectiva se implementa con lifecycle management y con retention policy para lo que exige conservación legal. En el examen, la respuesta que identifica la clase correcta, la duración mínima y el mecanismo de lifecycle es la que diferencia un candidato preparado de uno que memorizó nombres.

🎯 Punto clave 3: Cada servicio resuelve un problema distinto y el error más caro es el solapamiento indebido. Cloud SQL: relacional gestionado con mínima fricción de migración. AlloyDB: PostgreSQL con motor columnar y cómputo desacoplado del almacenamiento, para escala de lectura. Spanner: relacional global con particionado horizontal y consistencia fuerte, para sistemas multi-región. Bigtable: NoSQL de columnas anchas para volumen alto y series temporales. Firestore: NoSQL de documentos serverless con sincronización offline y realtime para aplicaciones de usuario final. BigQuery: analítica serverless. Entiende qué problema resuelve cada uno y qué NO resuelve: no uses Bigtable para reporting, ni Firestore para modelo fuertemente relacional, ni Spanner para guardar archivos.

🎯 Punto clave 4: El argumento de valor de la nube con datos es económico antes que técnico: separación entre almacenamiento y cómputo, facturación por uso, capacidad elástica sin aprovisionamiento y coste marginal decreciente del análisis exploratorio. Eso reduce el coste de preguntar cosas nuevas y, en particular, habilita el valor de los datos no estructurados mediante servicios de machine learning sobre almacenamiento de objetos barato. En un escenario de negocio, la respuesta esperada conecta el servicio elegido con un efecto medible: coste de almacenamiento reducido, latencia de decisión mejorada, cobertura de analítica ampliada o coste de inicialización reducido.

🎯 Punto clave 5: El error de arquitectura más frecuente en estos escenarios es llevar el reporting a la base de datos operativa, degradando la aplicación. La respuesta esperada separa siempre los caminos: la base de datos operativa es la fuente de verdad, Cloud Storage conserva el histórico y BigQuery (o el motor columnar de AlloyDB) responde las preguntas analíticas. Reconocer ese patrón en el enunciado y proponer la separación, justificándola en latencia y coste, es lo que suele decidir la pregunta.

Recursos Externos

Cloud Storage: overview y clases de almacenamiento — Referencia de las clases Standard, Nearline, Coldline y Archive, con duraciones mínimas, disponibilidad y costes de recuperación.
Cloud Storage: lifecycle management — Cómo se configuran las reglas de transición y borrado por edad, prefijo o versión, y cómo se combinan con las políticas de retención.
Cloud Spanner: overview de la base de datos relacional global — Modelo de particionado horizontal, TrueTime, consistencia fuerte y casos de uso del servicio.
Cloud Bigtable: documentación del producto — Modelo de filas por clave, familias de columnas, throughput y latencia del servicio NoSQL de columnas anchas.
Cloud SQL: overview de bases de datos relacionales gestionadas — Alta disponibilidad, réplicas, copias de seguridad y recuperación a un momento dado en un servicio gestionado.
Firestore: overview de la base de datos de documentos — Modelo de documentos, SDKs de cliente, sincronización offline y operaciones en tiempo real.

Autoevaluación Rápida

Pregunta: Una compañía conserva 40 TB de exports de su ERP en un bucket de Cloud Storage, todos en clase Standard, y que no se actualiza desde hace más de dos años. El CFO pide una reducción de coste sin perder la información. ¿Qué propones? Respuesta: Aplicar lifecycle management en tres niveles: mover a Nearline a los 30 días, a Coldline a los 90 y definir una regla de borrado a los cinco años para lo que no tenga dueño ni caso de uso. El ahorro viene de la diferencia de precio por GB/mes entre Standard y Coldline aplicada a los 40 TB, y el borrado evita el crecimiento indefinido. Antes de borrar, hay que verificar con el negocio qué obligaciones de conservación tiene; lo que deba conservarse por normativa se protege con una retention policy y Bucket Lock, y lo demás se archiva en la clase que corresponda a su frecuencia de consulta. Añadir más capacidad no es la respuesta: el problema es la clasificación del dato que ya existe.
Pregunta: Una app de juego multijugador necesita un ranking global que todos los jugadores vean igual en todo momento, con millones de usuarios simultáneos. ¿Qué servicio recomiendas y por qué no los otros? Respuesta: Cloud Spanner, porque el requisito no es solo volumen sino consistencia estricta entre regiones: un ranking que un jugador ve y otro no, de forma transitoria, produce exactamente el tipo de inconsistencia que destruye la confianza en un producto competitivo. Spanner resuelve eso con particionado horizontal por rango de clave y con el servicio de tiempo real de Spanner. No recomiendo Bigtable, porque su modelo de clave no encaja con el patrón de escritura y lectura del ranking, ni Firestore, porque su modelo documental encaja mal con las agregaciones y no ofrece el modelo relacional que el dominio del juego necesita. Cloud SQL tendría el problema de que no hay una única fuente de verdad global sin reconciliación manual. Sí usaría Cloud Storage para los assets y Bigtable o BigQuery para telemetría y analítica del comportamiento de juego.
Pregunta: El equipo de logística tiene sensores en 30.000 vehículos que envían posición cada 10 segundos y consulta el histórico de los últimos siete días con latencia de lectura muy baja. ¿Cloud Bigtable o Firestore, y por qué? Respuesta: Cloud Bigtable. El patrón es la definición del servicio: un volumen muy alto de escrituras, datos de series temporales con atributos dispersos, y consultas por rango de clave con latencia estable, sin necesidad de joins ni de índices secundarios. Firestore funcionaría, pero su modelo de operaciones por documento y su enfoque en documentos sincronizables no aportan nada aquí, y su coste por operación es menos conveniente a esta escala. BigQuery sería el complemento natural para la analítica histórica sobre el conjunto de telemetría, no el almacén de la ruta crítica de escritura.
Pregunta: Un hospital tiene su aplicación de citas en MySQL con patrones de SQL y un equipo de análisis que pide cada mes informes que recorrían datos de tres años y degradan la base de producción. ¿Qué recomiendas y por qué no enlarger la instancia? Respuesta: Separar los caminos: Cloud SQL sigue siendo la fuente de verdad de las citas, y el histórico se replica a BigQuery, desde donde el equipo de análisis trabaja sin tocar producción. Enlargear la instancia no resuelve el problema de fondo: no es un problema de capacidad de hardware sino de que dos perfiles de carga incompatibles (OLTP y reporting masivo) comparten los mismos recursos; el coste se dispara y el problema reaparece en el siguiente informe. Si además el hospital quiere consultas analíticas sobre datos operativos con mucha concurrencia de lectura y ya está en PostgreSQL, la alternativa es AlloyDB con su motor columnar; con MySQL, la vía natural es la replicación hacia BigQuery.
Pregunta: En un cuestionario te piden: "empresa necesita fuente de verdad transaccional global, con particionado y consistencia estricta". ¿Qué servicio nombras y qué dos servicios NO nombrarías y por qué? Respuesta: Cloud Spanner. No sería BigQuery, porque es un motor analítico y no la fuente de verdad transaccional de una aplicación con escritura en tiempo real, ni Cloud Storage, porque no ofrece transacciones ni consultas sobre el dato. Tampoco Cloud SQL, porque una instancia gestionada es regional y la consistencia global exigiría reconciliación manual. La justificación que hay que dar en el examen es la conjunción: "transaccional y relacional" descarta a los NoSQL y a BigQuery, "global" descarta a Cloud SQL y a una instancia regional, y "consistencia estricta" descarta a los servicios de consistencia eventual. Esa reducción por eliminación es la forma más rápida de acertar.