Google PCD: Dados de Aplicação, Estado e Padrões de Armazenamento — Guia de estudos

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Faz parte do Google Professional Cloud Developer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Aplicações modernas no Google Cloud rotineiramente combinam múltiplos armazenamentos de dados para equilibrar latência, consistência, escalabilidade, custo e complexidade operacional. Selecionar serviços e padrões adequados à finalidade — e entender seus modos de falha — é central para um design resiliente. Esta seção resume orientações práticas para Cloud SQL, Cloud Spanner, Firestore, Bigtable, Memorystore e Cloud Storage, e aborda migrações, particionamento e proteção de dados.

Dados Relacionais no Cloud SQL

O Cloud SQL fornece MySQL, PostgreSQL e SQL Server gerenciados com a semântica familiar de um RDBMS.

Conectividade privada
- Use IP privado para manter o tráfego do banco de dados em sua VPC. Isso elimina regras de entrada (ingress) públicas e listas de permissão de IP (allowlists), e evita a complexidade de saída (egress) com NAT.
- Garanta que as rotas e regras de firewall permitam o tráfego da VPC para a instância. A resolução de nomes para IP privado é tratada automaticamente quando o IP privado está habilitado.
- Para ambientes serverless (Cloud Run, App Engine, Cloud Functions), prefira os conectores do Cloud SQL, que lidam com autenticação IAM e TLS, mesmo com IP privado.
Alta disponibilidade e réplicas
- A HA Regional posiciona a instância primária e a de standby em zonas diferentes com replicação síncrona de disco. Espere uma breve queda de conexão no failover; as aplicações devem tentar novamente em caso de erros transitórios e se reconectar.
- As réplicas de leitura são assíncronas e descarregam o tráfego de leitura. Use réplicas entre regiões (cross-region) para DR e proximidade de leitura, entendendo que as réplicas são eventualmente consistentes.
- Promova uma réplica de leitura para recuperação ou para trocas de função planejadas. Teste os procedimentos de promoção regularmente.
Backups e recuperação point-in-time
- Habilite backups automatizados e logs de transação/PITR. Agende backups para fora do horário de pico para reduzir a contenção de I/O.
- Mantenha múltiplas cópias e valide periodicamente as restaurações para uma instância separada. Um backup que você não consegue restaurar é operacionalmente equivalente a não ter backup algum.
Pools de conexão e limites
- O Cloud SQL impõe um número máximo de conexões; um excesso de conexões de curta duração causa sobrecarga de CPU (thrash) e latência. Use pooling no lado da aplicação (ex: HikariCP, PgBouncer, ProxySQL).
- Dimensione os pools com base nos núcleos de CPU e na concorrência da carga de trabalho, não apenas na memória da instância. Comece com um valor baixo e aumente empiricamente.
- Para computação efêmera/serverless, o conector do Cloud SQL específico da linguagem mantém um pool por revisão; ainda assim, limite a concorrência para evitar tempestades de conexão após cold starts.
Particionamento de dados e desempenho
- Faça o sharding de esquemas multi-tenant grandes por cliente ou região para reduzir a contenção. Mantenha tenants com alto tráfego (hot) isolados sempre que possível.
- Crie índices de cobertura (covering indexes) com cuidado; o excesso de índices (over-indexing) torna as escritas mais lentas e aumenta o armazenamento. Verifique a cardinalidade e a seletividade do predicado.
- Use locking otimista ou

undefined

para linhas com alta concorrência (hot rows); ajuste o autovacuum (PostgreSQL) ou as configurações do InnoDB (MySQL) para cargas de trabalho de escrita sustentada.

Modos de falha comuns e mitigações:

Thundering herds após reinicializações de VM/nó: limite o tamanho dos pools e use exponential backoff.
Atraso na réplica (replica lag) para consistência read-your-writes: fixe as leituras na instância primária quando a consistência de sessão for necessária.
Instabilidade no failover de HA (flaps) devido a vizinhos barulhentos (noisy neighbors) ou manutenção: implemente novas tentativas (retries) de conexão e transação com idempotência.

Relacional em Escala Planetária no Cloud Spanner

O Cloud Spanner oferece escalabilidade horizontal com opções de consistência global.

Consistência e transações
- Leituras fortes (strong reads) e transações de leitura e escrita fornecem consistência externa estrita usando TrueTime; os commits aguardam brevemente para garantir a linearizabilidade.
- Leituras desatualizadas (stale) e com desatualização limitada (bounded-staleness) diminuem a latência e melhoram a disponibilidade para cargas de trabalho com muita leitura, quando a atualidade dos dados pode ser um pouco relaxada.
- Transações somente leitura abrangem múltiplas leituras em um timestamp sem locks; use para snapshots consistentes para análise.
Regionalidade, disponibilidade e latência
- Instâncias regionais fornecem alta disponibilidade dentro de uma região. Configurações multirregionais (por exemplo,

undefined

) entregam altíssima disponibilidade e leituras locais de baixa latência entre continentes, com escritas globalmente consistentes.

Escolha configurações de instância alinhadas com a geografia de seus usuários; as latências de escrita aumentam com o tamanho do quórum intercontinental.
Escalabilidade e design de schema
- O Spanner divide (shards) os dados em divisões (splits) por intervalos de chave primária, distribuídos entre os nós. Ocorre hotspotting quando as chaves são monotonamente crescentes. Evite chaves como IDs de autoincremento ou timestamps sempre crescentes na posição principal.
- Use chaves primárias compostas que distribuem as escritas (por exemplo,

undefined

Tabelas intercaladas (interleaved) colocam linhas filhas junto com as pais para localidade e joins eficientes. Use quando a cardinalidade e o acesso dos filhos estão fortemente correlacionados com o pai. Complemente com índices secundários; considere usar cláusulas

undefined

para reduzir as buscas na tabela (table lookups).

Monitore CPU, armazenamento e operações de alta prioridade vs. best-effort; escale os nós para manter uma folga (headroom) sob as latências P95.
Padrões operacionais
- Os clientes usam pools de sessão; ajuste o mínimo/máximo de sessões para evitar tempestades de criação. As novas tentativas (retries) devem ser limitadas e idempotentes; em caso de

undefined

, tente novamente as transações de leitura e escrita com backoff.

Os backups são leves (lightweight) e consistentes; valide as restaurações para instâncias separadas. Change streams e integrações de CDC podem alimentar sistemas downstream.

Trade-offs:

Escritas globais fortes (strong) adicionam espera de commit (commit-wait); use leituras desatualizadas (stale) para caminhos críticos para a UX e majoritariamente de leitura.
A intercalação (interleaving) melhora a localidade, mas pode concentrar a pressão de escrita; teste com tráfego semelhante ao de produção.

Armazenamentos Operacionais NoSQL: Firestore e Bigtable

Escolha o modelo NoSQL que corresponda aos padrões de consulta e ao perfil de throughput.

Firestore (documento)
- Modelo de dados: coleções contêm documentos; documentos podem ter subcoleções. Modele em torno dos padrões de consulta; evite escritas com fan-out profundo em documentos únicos “quentes” (hot).
- Acesso e transações: leituras e consultas de documentos são fortemente consistentes no modo Nativo. Use escritas em lote (batched writes) para atomicidade do tipo at-most-once em múltiplos documentos, e transações para operações de leitura-modificação-escrita (read-modify-write) com verificação de contenção.
- Índices: índices de campo único são automáticos. Índices compostos de múltiplos campos devem ser definidos ao usar múltiplos filtros de intervalo/desigualdade ou ordens de classificação. A desnormalização é comum para tornar as consultas do tipo index-only (somente de índice).
- Sincronização de cliente: listeners em tempo real transmitem alterações; caches offline reconciliam com a semântica de last-write-wins (a última escrita vence). Proteja-se contra fan-out de listeners ilimitado; prefira cursores de consulta e filtros.
- Limites e modos de falha: a taxa de escrita em um único documento é serializada; atualizações com QPS alto e sustentado em um único documento criam contenção. Use contadores fragmentados (sharded counters) com N subdocumentos e agregue na leitura.
Cloud Bigtable (coluna larga)
- O design da chave de linha (row-key) é primordial. O Bigtable particiona as linhas lexicograficamente; os segmentos iniciais da chave determinam o hotspotting. Evite chaves sequenciais como aquelas com timestamps no início ou IDs de usuário não fragmentados (unsharded).
- Padrões:
  - Timestamp reverso dentro da chave para leituras de séries temporais: key = device#hash(device_id)#reverse_ts.
  - Aplique hash ou bucketize o primeiro componente para distribuir as escritas: bucket = crc32(user_id) % 128.
- Armazene células pequenas com muitas colunas; evite linhas grandes que se estendem por múltiplos tablets. Utilize múltiplas famílias de colunas (column families) para controle de acesso e separação de políticas de GC (Garbage Collection).
- Throughput e serviço (serving):
  - Use múltiplos clusters para replicação e proximidade de leitura regional; escritas entre clusters tornam-se eventualmente consistentes.
  - Ajuste os perfis de aplicação (app profiles) e o roteamento; mantenha pools de threads e pools de canais generosos no lado do cliente.
- GC e TTL: o GC baseado em versão e tempo remove células antigas de forma assíncrona; os dados persistem até a compactação, portanto, não confie na exclusão imediata para cumprir prazos regulatórios.

Padrões de Caching e Armazenamento de Objetos

Memorystore (Redis/Memcached)
- Estratégias de caching:
  - Read-through: a aplicação busca no cache; em caso de falha (miss), carrega da fonte e preenche o cache.
  - Write-through: as escritas vão para o cache e para a fonte de forma síncrona.
  - Write-behind: armazena as escritas em buffer no cache e as descarrega (flush) de forma assíncrona; use com cautela devido ao risco de perda de dados.
- Expiração e invalidação:
  - Aplique TTLs consistentes com a tolerância à desatualização dos dados (staleness). Invalide chaves quando houver alterações na fonte da verdade (source-of-truth); para caches agregados, use chaves versionadas para evitar estampidas (stampedes).
  - Use mutex ou single-flight para prevenir estampidas de cache (cache stampedes) em chaves populares.
- Sessões: armazene dados de sessão efêmeros com TTL; criptografe os valores ou armazene apenas tokens opacos se forem sensíveis.
- Rate limiting (limitação de taxa) com Redis:
  - Janela fixa (Fixed-window): INCR com EXPIRE em uma chave por identidade.
  - Janela deslizante (Sliding-window) ou token-bucket para limites mais suaves; considere scripts Lua para garantir atomicidade.
- Disponibilidade: o nível Basic não tem failover; o nível Standard oferece alta disponibilidade (HA) regional. Trate o cache como volátil; nunca como um armazenamento autoritativo.
Exemplo: rate limit simples de janela fixa
- Comandos:

undefined

Cloud Storage
- Objetos e consistência: consistência forte e global para leituras, escritas, sobrescritas, exclusões e listagens. Objetos são imutáveis; atualizações criam novas gerações.
- Signed URLs: descarregue uploads/downloads grandes diretamente entre clientes e buckets sem passar por um proxy na sua aplicação. Defina expirações curtas; restrinja o método, o caminho e os cabeçalhos de conteúdo.
- Uploads retomáveis (Resumable uploads): use para arquivos >5 MB e em redes não confiáveis; trate erros 5xx/429 com backoff exponencial truncado e tokens de retomada.
- Ciclo de vida (Lifecycle): defina regras para transicionar classes de armazenamento, excluir versões antigas e impor retenção. Combine com o versionamento de objetos para segurança durante rollouts.
- Notificações: integre notificações do Pub/Sub para acionar processamento downstream na finalização/exclusão de um objeto, e inclua pré-condições (ifGenerationMatch) para proteger contra condições de corrida (race conditions).
Exemplo: fazer upload de arquivos locais

undefined

Migração, Consistência, Particionamento e Proteção de Dados

Migração de banco de dados
- Escolha entre online e offline: online com o Database Migration Service para tempo de inatividade mínimo; offline para simplicidade quando janelas de manutenção são aceitáveis.
- Primeiro o schema: reconcilie tipos e restrições; para o Spanner, considere ferramentas para mapear schemas e dados do MySQL/PostgreSQL, depois ajuste chaves e índices para distribuição.
- Execução dupla e transição (cutover): durante a migração online, faça escrita dupla ou replique changelogs. Valide contagens de linhas, checksums e o comportamento de consultas críticas antes da transição final.
Migrações de schema e rollback
- Use migrações versionadas e automatizadas (por exemplo, com uma ferramenta de migrações) como parte do CI/CD. Projete alterações aditivas e retrocompatíveis: adicione colunas e índices, preencha os dados (backfill), implante o código que lê/escreve em ambos e, em seguida, remova os artefatos obsoletos.
- Planeje o rollback com transformações de dados: se a implantação do código falhar, esteja preparado para desativar novas escritas e depender de feature flags; evite migrações destrutivas que bloqueiam o rollback.
Workflows transacionais vs. eventualmente consistentes
- Use transações ACID quando invariantes devem ser mantidas de forma síncrona (transferências de fundos, decrementos de inventário).
- Prefira consistência eventual para recursos voltados ao usuário, principalmente de leitura, onde a latência domina (feeds, busca, contadores). Implemente chaves de idempotência, padrões outbox/Saga e novas tentativas (retries) com backoff.
- Combine: confirme o estado autoritativo em um armazenamento transacional; publique eventos para projeções eventualmente consistentes.
Particionamento de dados e gerenciamento de conexões
- Particione por locatário (tenant), geografia ou tipo de carga de trabalho para isolar hotspots. Para Bigtable e Spanner, codifique as chaves de partição nas chaves primárias; para o Cloud SQL, use um schema por locatário ou sharding de tabelas com roteadores.
- Gerencie conexões:
  - Cloud SQL: faça pooling e reutilize; limite a concorrência; escalone as inicializações a frio (cold starts).
  - Spanner: reutilize sessões; aqueça os pools na inicialização; limite as novas tentativas.
  - Memorystore: reutilize conexões TCP; evite conexões por requisição.
Proteção de dados, arquivamento, verificação de restauração e comportamento de exclusão
- Backups e arquivamento:
  - Cloud SQL: backups automatizados + PITR; teste as restaurações.
  - Spanner: backups gerenciados; teste a restauração em ambiente de não produção.
  - Firestore: exportações agendadas para o Cloud Storage; verifique as importações.
  - Bigtable: backups e snapshots; teste a clonagem e restauração.
  - Cloud Storage: políticas de retenção, bloqueios de objeto (object holds) e acesso uniforme no nível do bucket para governança; arquive para classes mais frias (colder classes) via ciclo de vida (lifecycle).
- Verificação de restauração: restaure periodicamente para ambientes isolados e execute consultas de validação e testes de fumaça (smoke tests) da aplicação. Monitore o RTO/RPO em relação à política.
- Comportamento de exclusão:
  - O GC e o ciclo de vida do Bigtable são assíncronos — não prometa exclusão imediata.
  - O versionamento do Cloud Storage retém gerações até que o ciclo de vida as remova.
  - O TTL do Firestore e as exclusões baseadas em exportação são assíncronas.
  - Para SLAs de exclusão definitiva (hard-deletion), projete processos que marcam para exclusão, enfileiram e verificam a remoção, com logs de auditoria.

Cenário de Problema Prático

A Aurora Outfitters está migrando uma plataforma monolítica de ecommerce para o Google Cloud. Eles precisam: 1) fazer o lift-and-shift do MySQL para reduzir o risco, 2) lidar com uploads de mídia de produtos de 500 MB sem sobrecarregar a aplicação, 3) escalar a taxa de transferência de leitura (read throughput) para catálogos de produtos e 4) impor limites de taxa (rate limits) por usuário durante picos de vendas.

Abordagem:

Migrar o MySQL para o Cloud SQL com IP privado e alta disponibilidade (HA) regional
- Justificativa: O IP privado remove a exposição pública e as listas de permissão de IP (allowlists), simplificando a conectividade segura a partir do GKE e do Compute Engine. A HA regional protege contra falhas zonais; espere breves quedas de conexão durante o failover, então a aplicação implementará transações com novas tentativas (retryable) e lógica de reconexão.
Habilitar backups automatizados e PITR, e validar a restauração
- Justificativa: Backups automatizados e logs de transação permitem a recuperação para um ponto no tempo (point-in-time recovery) de erros de usuário ou de aplicação. Uma restauração agendada para uma instância de não produção a cada semana verifica se os backups são utilizáveis e mede o RTO.
Adicionar uma réplica de leitura (read replica) para as leituras do catálogo
- Justificativa: Mover as consultas do catálogo para uma réplica de leitura reduz a contenção na instância primária. A aplicação lê da primária quando a consistência de leitura após escrita (write-after-read) é necessária (carrinho/checkout) e da réplica para a navegação no catálogo, compreendendo as desvantagens do atraso da réplica (replica lag).
Introduzir pooling de conexões no lado da aplicação e limitar a concorrência
- Justificativa: O PgBouncer/HikariCP limita e reutiliza conexões, evitando tempestades de conexões (connection storms) durante o autoscaling e failovers de HA. Os pools são dimensionados de acordo com os núcleos de CPU, não com o número máximo de pods, prevenindo sobrecarga.
Descarregar uploads de mídia para o Cloud Storage com URLs assinadas e uploads retomáveis
- Justificativa: A aplicação emite URLs assinadas de curta duração para que os clientes façam o upload diretamente. Uploads retomáveis acomodam redes não confiáveis; o serviço de mídia escuta as notificações de finalização do Pub/Sub para acionar o processamento. Cabeçalhos de pré-condição (ifGenerationMatch) protegem contra corridas de sobrescrita (overwrite races).
Implementar o Memorystore for Redis para cache de página, sessões e limitação de taxa (rate limiting)
- Justificativa: Caches read-through reduzem a carga no banco de dados para páginas de produtos com TTLs alinhados à frequência de atualização. Os dados da sessão são mantidos efêmeros no Redis com TTLs curtos; o estado da aplicação permanece no Cloud SQL. Uma estratégia de token de janela fixa (fixed-window) usa INCR/EXPIRE para limites de requisição por usuário. O cache é tratado como não autoritativo; a aplicação tolera a perda do cache e o repopula em caso de falha (cache miss).
Preparar um caminho em fases para o Cloud Bigtable para recursos de navegação de catálogo de alta taxa de transferência
- Justificativa: À medida que o tráfego cresce, as visualizações de catálogo desnormalizadas e otimizadas para leitura são movidas para o Bigtable. As chaves de linha (row keys) são projetadas como bucket#categoria#timestamp_reverso para distribuir as escritas e suportar listagens ordenadas por tempo sem criar hotspots.
Estabelecer procedimentos de migração de schema e rollback
- Justificativa: As migrações são aditivas: adicione colunas/índices, preencha os dados (backfill) com jobs idempotentes, implante o código que lê/escreve em ambos e, em seguida, remova os campos antigos posteriormente. Feature flags protegem os novos caminhos; o rollback desativa as escritas nos novos campos sem DDL destrutivo.
Definir políticas de ciclo de vida e proteção de dados
- Justificativa: Os buckets do Cloud Storage usam regras de ciclo de vida para transicionar miniaturas para armazenamento mais frio (colder storage) e excluir uploads temporários desatualizados. Os backups do Cloud SQL e do Spanner/Bigtable (conforme adotados) são restaurados regularmente para verificação. Logs de auditoria capturam os fluxos de trabalho de exclusão; o GC do Bigtable é reconhecido como assíncrono nos documentos de conformidade.
Implementar novas tentativas (retries) no cliente e no servidor com backoff exponencial truncado
- Justificativa: O Cloud Storage pode retornar 429/5xx durante picos; o backoff suaviza a carga e reduz as taxas de erro. As operações de banco de dados e cache usam chaves de idempotência para garantir novas tentativas seguras, especialmente durante failover e instabilidades de rede.

Este plano oferece redução de risco imediata através do Cloud SQL com conectividade privada e HA, mantém a aplicação responsiva e com custo-benefício com cache e uploads por URL assinada, e constrói um caminho claro para escalar a taxa de transferência de leitura e a resiliência dos dados à medida que o tráfego cresce.

← Design de API · Todos os domínios · Identidade →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →