Uma das primeiras sensações de confusão ao estudar o GCP é perceber quantos serviços de dados existem — e como todos soam parecidos na superfície. Cloud Storage, Cloud SQL, Spanner, Firestore, Bigtable, BigQuery, Memorystore. Cada um tem um propósito de design distinto, e escolher o errado pode significar uma arquitetura incorreta ou uma questão de prova errada. O objetivo deste guia não é te dar uma lista para memorizar, mas desenvolver reconhecimento de padrões: quando você identificar certas palavras-chave em um cenário, o serviço correto deve vir à mente automaticamente.
---
Cloud Storage: Quatro classes de armazenamento e automação do ciclo de vida
Cloud Storage é o serviço central de armazenamento de objetos do GCP. Ele armazena dados não estruturados — imagens, vídeos, arquivos de log, dados de origem de pipelines, backups — em escala ilimitada, sem necessidade de gerenciar servidores ou provisionar capacidade antecipadamente. Você paga pelo que usa, e o custo varia significativamente com base na frequência com que precisa acessar seus dados.
A decisão de design mais importante no Cloud Storage é escolher a classe de armazenamento correta. O modelo de preços recompensa o acesso infrequente com custos de armazenamento por GB mais baixos, mas cobra taxas de recuperação quando você extrai os dados.
| Classe | Uso principal | Duração mínima | Custo de armazenamento | Taxa de recuperação | |--------|--------------|----------------|----------------------|---------------------| | Standard | Dados quentes, acesso frequente | Nenhuma | Mais alto (~$0,020/GB/mês) | Nenhuma | | Nearline | Menos de uma vez por mês | 30 dias | ~$0,010/GB/mês | Sim | | Coldline | Menos de uma vez por trimestre | 90 dias | ~$0,004/GB/mês | Sim | | Archive | Uma vez por ano ou menos, retenção de longo prazo | 365 dias | Mais baixo (~$0,0012/GB/mês) | Mais alta |
Na prova, frequência de acesso e requisitos de retenção sempre aparecem juntos. Se o cenário diz "reter por 7 anos, acessado apenas em caso de litígio legal," Archive é a resposta. Se o cenário descreve simulações de recuperação de desastre trimestrais com restauração de backups, Coldline é a opção adequada. Violar a duração mínima de armazenamento gera uma cobrança por exclusão antecipada.
As políticas de ciclo de vida permitem automatizar as transições de classe sem intervenção manual. Uma única regra que indique "transicionar para Nearline após 30 dias, Coldline após 90 dias, Archive após 365 dias" gerencia a otimização de custos automaticamente uma vez configurada. Esse é exatamente o tipo de padrão de eficiência operacional que a prova valoriza.
---
Tipos de armazenamento comparados: Objeto vs. Bloco vs. Arquivo
Cloud Storage é armazenamento de objetos, mas o GCP também oferece armazenamento em bloco e armazenamento de arquivos. Essas três categorias representam arquiteturas de armazenamento fundamentalmente diferentes e atendem a cargas de trabalho completamente distintas.
| Tipo de armazenamento | Serviço GCP | Método de acesso | Caso de uso principal | |----------------------|------------|-----------------|---------------------| | Armazenamento de objetos | Cloud Storage | HTTP/HTTPS (REST API) | Imagens, vídeo, backups, dados de origem de pipeline | | Armazenamento em bloco | Persistent Disk | Nível de bloco (montado na VM) | Disco do SO da VM, servidores de banco de dados | | Armazenamento de arquivos | Filestore | NFS (montagem compartilhada entre VMs) | Sistemas de arquivos compartilhados, migração de NAS |
Persistent Disk é conectado às VMs do Compute Engine e funciona como um disco rígido tradicional. O Regional Persistent Disk replica de forma síncrona em duas zonas dentro da mesma região, habilitando failover sem perda de dados em caso de falha de zona. Esta é a opção recomendada para cargas de trabalho com estado que precisam de resiliência a nível de zona.
Filestore fornece compartilhamentos NFS gerenciados que múltiplas VMs podem montar simultaneamente. Quando você está migrando cargas de trabalho NAS locais para o GCP e a aplicação espera uma interface de sistema de arquivos padrão, Filestore é a escolha natural. Ele elimina a complexidade de executar seu próprio servidor NFS em uma VM.
!Armazenamento de Objetos vs de Blocos vs de Arquivos
Cloud SQL: O lugar dos bancos de dados relacionais gerenciados
Cloud SQL é o serviço de banco de dados relacional totalmente gerenciado do GCP, com suporte a MySQL, PostgreSQL e SQL Server. Por manter compatibilidade em nível de protocolo com cada motor, migrar um banco de dados local geralmente requer apenas atualizar a string de conexão. Você obtém o mesmo dialeto SQL, os mesmos drivers e o mesmo comportamento de consultas — mas sem a sobrecarga operacional de gerenciar a infraestrutura subjacente.
| Recurso | Cloud SQL | |---------|-----------| | Motores suportados | MySQL 8.0, PostgreSQL 15, SQL Server 2019 | | Alta disponibilidade | Primary + Standby automático em zona diferente, mesma região | | Failover automático | Standby promovido em ~60 segundos após falha de zona | | Réplicas de leitura | Réplicas na mesma região e entre regiões para escalar leituras | | PITR | Recuperação para um ponto no tempo de até 7 dias atrás | | Armazenamento máximo | 64 TB |
A limitação arquitetural do Cloud SQL é seu caminho de escrita de instância única. As réplicas de leitura podem distribuir o tráfego de leitura, mas todas as escritas passam por uma única instância Primary. Quando o conjunto de dados ultrapassa dezenas de terabytes ou o throughput de escrita se aproxima dos limites de uma única instância, esse é o sinal para avaliar o Cloud Spanner. Cloud SQL é a ferramenta certa para aplicações web convencionais, sistemas corporativos internos e qualquer carga de trabalho que caiba confortavelmente em uma única região e um único servidor primário.
---
Spanner: Uma nova categoria chamada consistência forte global
Cloud Spanner ocupa uma categoria que não existia antes de o Google construí-la: um banco de dados relacional que suporta SQL completo e transações ACID enquanto escala horizontalmente em múltiplas regiões. Nenhum outro serviço do GCP combina essas três propriedades simultaneamente.
| Propriedade | Cloud SQL | Cloud Spanner | |------------|-----------|---------------| | Modelo de escalamento | Vertical (redimensionar instância) | Horizontal (adicionar nós, fragmentação automática) | | Escala máxima | ~64 TB | Ilimitada (multi-petabyte) | | Escopo regional | Região única | Região única ou multi-região | | SLA de disponibilidade | 99,95% (config HA) | 99,999% (multi-região) | | Escalamento de escrita | Primary único | Distribuído entre nós automaticamente | | Custo | Baixo | Alto (preço por nó) |
A tecnologia que torna o Spanner possível é o TrueTime. O Google usa receptores GPS e relógios atômicos para sincronizar o tempo entre nós distribuídos globalmente, permitindo consistência externa — uma garantia mais forte que o isolamento serializável — mesmo entre regiões geograficamente separadas. A replicação usa consenso Paxos, e a eleição de líder é automática quando uma região falha. Isso confere ao Spanner um RPO de zero e um RTO medido em segundos de um único dígito.
Reconhecimento de padrões para a prova: quando uma única frase de um cenário contém as palavras "global," "consistência forte," "transações ACID," "tolerância a falha de região" e "escalamento horizontal de escrita" juntas, Cloud Spanner multi-região é a resposta. Qualquer serviço que atenda apenas um ou dois desses requisitos é um distrator.
---
Firestore e Bigtable: Duas faces do NoSQL
O panorama NoSQL do GCP está dividido entre dois serviços com filosofias de design muito diferentes. Firestore é um banco de dados NoSQL orientado a documentos. Bigtable é um banco de dados NoSQL de colunas largas. A escolha entre eles depende inteiramente das características da carga de trabalho, não de uma preferência por um estilo NoSQL em detrimento de outro.
| Propriedade | Firestore | Bigtable | |------------|-----------|----------| | Modelo de dados | Coleções → Documentos (similar a JSON) | Chave de linha + famílias de colunas (colunas largas) | | Throughput | Auto-escalamento sem servidor | Milhões de operações por segundo, latência em milissegundos | | Carga de trabalho ideal | Apps móveis/web, perfis de usuário | Séries temporais IoT, gaming, ad tech, pipelines analíticos | | Suporte offline | Sim (sincronização automática) | Não | | Transações | Atomicidade de documento único | Apenas atomicidade de linha única | | Compatível com HBase | Não | Sim |
Firestore inclui listeners em tempo real e sincronização offline integrados em seus SDKs de cliente. Isso o torna a escolha natural para backends de aplicações móveis onde o cliente precisa manter-se sincronizado com o estado do servidor mesmo durante interrupções de rede. O modo Firestore Native suporta SDKs móveis e atualizações em tempo real; o modo Datastore existe para equipes migrando aplicações da antiga API do Cloud Datastore.
O desempenho do Cloud Bigtable é determinado quase inteiramente pelo design da chave de linha. Para dados de séries temporais IoT, o padrão recomendado é — colocar os dados mais recentes no início do intervalo de linhas torna as buscas rápidas. Se você usar uma marca de tempo direta, cada escrita cai no final da tabela, criando um hotspot de escrita que degrada o throughput em todo o cluster.
---
BigQuery: O padrão para cargas de trabalho analíticas
BigQuery é o data warehouse sem servidor do GCP. Você executa consultas SQL contra petabytes de dados sem provisionar clusters, gerenciar infraestrutura ou pré-aquecer caches. A arquitetura desacopla completamente o armazenamento da computação, o que torna possível o modelo de preços sob demanda — você paga pelo armazenamento continuamente, e paga pela computação apenas quando uma consulta é executada.
| Propriedade | Detalhes | |------------|----------| | Arquitetura | A