Una de las primeras sensaciones de desconcierto al estudiar GCP es darse cuenta de la cantidad de servicios de datos que existen y lo similares que suenan entre sí. Cloud Storage, Cloud SQL, Spanner, Firestore, Bigtable, BigQuery, Memorystore. Cada uno tiene un propósito de diseño distinto, y elegir el equivocado puede significar una arquitectura incorrecta o una respuesta fallida en el examen. El objetivo de esta guía no es darte una lista para memorizar, sino ayudarte a desarrollar reconocimiento de patrones: cuando aparezcan ciertas palabras clave en un escenario, el servicio correcto debe surgir de forma automática.
---
Cloud Storage: Cuatro clases de almacenamiento y automatización del ciclo de vida
Cloud Storage es el servicio central de almacenamiento de objetos de GCP. Almacena datos no estructurados — imágenes, videos, archivos de log, datos de origen de pipelines, respaldos — a escala ilimitada, sin necesidad de gestionar servidores ni aprovisionar capacidad por anticipado. Pagas por lo que usas, y el costo varía considerablemente según la frecuencia con que necesitas acceder a los datos.
La decisión de diseño más importante en Cloud Storage es elegir la clase de almacenamiento correcta. El modelo de precios recompensa el acceso infrecuente con costos de almacenamiento por GB más bajos, pero cobra tarifas de recuperación cuando extraes los datos.
| Clase | Uso principal | Duración mínima | Costo de almacenamiento | Tarifa de recuperación | |-------|--------------|-----------------|------------------------|------------------------| | Standard | Datos calientes, acceso frecuente | Ninguna | Más alto (~$0.020/GB/mes) | Ninguna | | Nearline | Menos de una vez al mes | 30 días | ~$0.010/GB/mes | Sí | | Coldline | Menos de una vez al trimestre | 90 días | ~$0.004/GB/mes | Sí | | Archive | Una vez al año o menos, retención a largo plazo | 365 días | Más bajo (~$0.0012/GB/mes) | Más alta |
En el examen, la frecuencia de acceso y los requisitos de retención siempre aparecen juntos. Si el escenario dice "retener durante 7 años, acceder únicamente en caso de litigio legal," Archive es la respuesta. Si el escenario describe simulacros de recuperación ante desastres trimestrales con restauración de respaldos, Coldline es la opción adecuada. Violar la duración mínima de almacenamiento genera un cargo por eliminación anticipada.
Las políticas de ciclo de vida permiten automatizar las transiciones de clase sin intervención manual. Una sola regla que indique "transicionar a Nearline después de 30 días, a Coldline después de 90 días, a Archive después de 365 días" gestiona la optimización de costos automáticamente una vez configurada. Este es exactamente el tipo de patrón de eficiencia operativa que el examen premia.
---
Tipos de almacenamiento comparados: Objeto vs. Bloque vs. Archivo
Cloud Storage es almacenamiento de objetos, pero GCP también ofrece almacenamiento en bloque y almacenamiento de archivos. Estas tres categorías representan arquitecturas de almacenamiento fundamentalmente diferentes y sirven a cargas de trabajo completamente distintas.
| Tipo de almacenamiento | Servicio GCP | Método de acceso | Caso de uso principal | |----------------------|-------------|------------------|----------------------| | Almacenamiento de objetos | Cloud Storage | HTTP/HTTPS (REST API) | Imágenes, video, respaldos, datos de origen de pipeline | | Almacenamiento en bloque | Persistent Disk | A nivel de bloque (montado en VM) | Disco del SO de la VM, servidores de base de datos | | Almacenamiento de archivos | Filestore | NFS (montaje compartido entre VMs) | Sistemas de archivos compartidos, migración de NAS |
Persistent Disk se adjunta a las VMs de Compute Engine y funciona como un disco duro tradicional. El Regional Persistent Disk replica de forma síncrona en dos zonas dentro de la misma región, habilitando la conmutación por error sin pérdida de datos en caso de falla de zona. Esta es la opción recomendada para cargas de trabajo con estado que necesitan resiliencia a nivel de zona.
Filestore proporciona recursos compartidos NFS administrados que múltiples VMs pueden montar simultáneamente. Cuando estás migrando cargas de trabajo NAS locales a GCP y la aplicación espera una interfaz de sistema de archivos estándar, Filestore es la opción natural. Elimina la complejidad de ejecutar tu propio servidor NFS en una VM.
!Almacenamiento de Objetos vs de Bloques vs de Archivos
Cloud SQL: El lugar de las bases de datos relacionales administradas
Cloud SQL es el servicio de base de datos relacional completamente administrado de GCP, compatible con MySQL, PostgreSQL y SQL Server. Dado que mantiene compatibilidad a nivel de protocolo de conexión con cada motor, migrar una base de datos local generalmente no requiere más que actualizar la cadena de conexión. Obtienes el mismo dialecto SQL, los mismos controladores y el mismo comportamiento de consultas, pero sin la carga operativa de gestionar la infraestructura subyacente.
| Característica | Cloud SQL | |---------------|-----------| | Motores compatibles | MySQL 8.0, PostgreSQL 15, SQL Server 2019 | | Alta disponibilidad | Primary + Standby automático en zona diferente, misma región | | Conmutación automática | Standby promovido en ~60 segundos tras falla de zona | | Réplicas de lectura | Réplicas en la misma región y entre regiones para escalar lecturas | | PITR | Recuperación a un punto en el tiempo hasta 7 días atrás | | Almacenamiento máximo | 64 TB |
La limitación arquitectónica de Cloud SQL es su ruta de escritura de instancia única. Las réplicas de lectura pueden distribuir el tráfico de lectura, pero todas las escrituras pasan por una única instancia Primary. Cuando el conjunto de datos supera varias decenas de TB o el rendimiento de escritura se acerca a los límites de una sola instancia, esa es la señal para evaluar Cloud Spanner. Cloud SQL es la herramienta correcta para aplicaciones web convencionales, sistemas empresariales internos y cualquier carga de trabajo que encaje cómodamente en una sola región y un único servidor primario.
---
Spanner: Una nueva categoría llamada consistencia fuerte global
Cloud Spanner ocupa una categoría que no existía antes de que Google la construyera: una base de datos relacional que admite SQL completo y transacciones ACID mientras escala horizontalmente en múltiples regiones. Ningún otro servicio de GCP combina esas tres propiedades simultáneamente.
| Propiedad | Cloud SQL | Cloud Spanner | |-----------|-----------|---------------| | Modelo de escalado | Vertical (redimensionar instancia) | Horizontal (agregar nodos, fragmentación automática) | | Escala máxima | ~64 TB | Ilimitada (multi-petabyte) | | Alcance regional | Región única | Región única o multi-región | | SLA de disponibilidad | 99.95% (config HA) | 99.999% (multi-región) | | Escalado de escritura | Primary único | Distribuido en nodos automáticamente | | Costo | Bajo | Alto (precio por nodo) |
La tecnología que hace posible Spanner es TrueTime. Google utiliza receptores GPS y relojes atómicos para sincronizar el tiempo entre nodos distribuidos globalmente, lo que permite la consistencia externa — una garantía más fuerte que el aislamiento serializable — incluso entre regiones geográficamente separadas. La replicación utiliza consenso Paxos, y la elección de líder es automática cuando falla una región. Esto le otorga a Spanner un RPO de cero y un RTO medido en segundos de un solo dígito.
Reconocimiento de patrones para el examen: cuando una sola oración de un escenario contiene las palabras "global," "consistencia fuerte," "transacciones ACID," "tolerancia a falla de región" y "escalado horizontal de escritura" juntas, Cloud Spanner multi-región es la respuesta. Cualquier servicio que maneje solo uno o dos de esos requisitos es un distractor.
---
Firestore y Bigtable: Dos caras del NoSQL
El panorama NoSQL de GCP está dividido entre dos servicios con filosofías de diseño muy diferentes. Firestore es una base de datos NoSQL orientada a documentos. Bigtable es una base de datos NoSQL de columnas anchas. Elegir entre ellas depende completamente de las características de la carga de trabajo, no de una preferencia por un estilo NoSQL sobre otro.
| Propiedad | Firestore | Bigtable | |-----------|-----------|----------| | Modelo de datos | Colecciones → Documentos (similar a JSON) | Clave de fila + familias de columnas (columnas anchas) | | Rendimiento | Auto-escalado sin servidor | Millones de operaciones por segundo, latencia en milisegundos | | Carga de trabajo óptima | Apps móviles/web, perfiles de usuario | Series de tiempo IoT, gaming, publicidad, pipelines analíticos | | Soporte offline | Sí (sincronización automática) | No | | Transacciones | Atomicidad de documento único | Solo atomicidad de fila única | | Compatible con HBase | No | Sí |
Firestore incluye listeners en tiempo real y sincronización offline integrados en sus SDKs de cliente. Esto lo convierte en la elección natural para backends de aplicaciones móviles donde el cliente necesita mantenerse sincronizado con el estado del servidor incluso durante interrupciones de red. El modo Firestore Native admite SDKs móviles y actualizaciones en tiempo real; el modo Datastore existe para equipos que migran aplicaciones desde la antigua API de Cloud Datastore.
El rendimiento de Cloud Bigtable está determinado casi en su totalidad por el diseño de la clave de fila. Para datos de series de tiempo IoT, el patrón recomendado es — colocar los datos más recientes al inicio del rango de filas hace que las búsquedas sean rápidas. Si usas una marca de tiempo directa, cada escritura cae al final de la tabla, creando un hotspot de escritura que degrada el rendimiento en todo el clúster.
---
BigQuery: El estándar para cargas de trabajo analíticas
BigQuery es el data warehouse sin servidor de GCP. Ejecutas consultas SQL contra petabytes de datos sin aprovisionar clús