"Qual banco de dados se encaixa nesta situação?" é um dos tipos de questão mais comuns do Cloud Digital Leader. Na revisão de agosto de 2026 do guia do exame, o domínio 2 (cerca de 18%) pede que você escolha o produto certo para um caso de uso entre Cloud Storage, Spanner, Cloud SQL, AlloyDB, Bigtable, BigQuery e Firestore, diferencie as classes de armazenamento e o Autoclass por custo e frequência de acesso, e explique como migrar ou modernizar um banco de dados existente na nuvem. Desses, AlloyDB e Autoclass são nomes que aparecem pela primeira vez nesta revisão.
Este artigo define primeiro os termos que você precisa conhecer e depois percorre um fluxo de decisão que reduz a escolha com quatro perguntas, uma comparação produto a produto, o AlloyDB, as classes de armazenamento e o Autoclass, a migração de bancos de dados e os produtos de dados para ambientes híbridos e multicloud. Os fundamentos de cada serviço são tratados primeiro em Transformação de dados, e as diferenças conceituais entre bancos de dados, data warehouses e data lakes, em Fundamentos de dados.
---
Os termos que você precisa primeiro
Assim como cada prato tem o recipiente certo, cada tipo de dado tem o repositório certo. A sopa vai na tigela e o bolo vai no prato; quando você conhece o formato e o uso dos dados, o repositório vem naturalmente. O guia do exame verifica se você sabe definir estes termos.
| Termo | Significado | |------|------| | Banco de dados relacional | Guarda os dados em tabelas e nas relações entre elas; a estrutura é definida antes e a consistência é forte | | Banco de dados não relacional (NoSQL) | Guarda os dados em estruturas flexíveis como documentos, pares chave-valor ou colunas largas; forte para crescer em larga escala | | SQL | A linguagem padrão para consultar e alterar dados relacionais | | Armazenamento de objetos | Guarda arquivos como objetos que reúnem dados e metadados, com capacidade ilimitada e acesso por URL | | Transação | Uma unidade de trabalho em que várias operações são todas concluídas ou todas canceladas, para que os dados nunca fiquem inconsistentes (por exemplo, uma transferência bancária) | | Escalonamento vertical vs. horizontal | Deixar um servidor mais potente vs. adicionar mais servidores |
Dica para o exame: "Várias etapas, como uma transferência bancária, precisam dar certo ou falhar juntas" é uma transação de um banco de dados relacional. "Dados flexíveis cuja estrutura muda com frequência, em larga escala" é NoSQL.
---
Qual repositório? Quatro perguntas para decidir
São sete opções, mas fazer só quatro perguntas em ordem reduz a maioria dos casos a uma.
!Um fluxo que usa quatro perguntas para escolher entre Cloud Storage, BigQuery, três opções relacionais e duas opções NoSQL
É um objeto, como um arquivo, uma imagem, um vídeo ou um backup? Então, Cloud Storage O objetivo é análise em larga escala e relatórios de BI? Então, BigQuery Você precisa de estrutura relacional e transações? Então escolha entre Cloud SQL, AlloyDB e Spanner pela escala e pelo desempenho Se o que sobra é NoSQL, escolha pelo tipo de dado: grandes volumes como séries temporais e IoT vão para o Bigtable, e dados de documentos de aplicativos móveis e web vão para o Firestore
---
Comparação produto a produto
| Produto | Tipo | Quando se encaixa | Pistas na questão | |------|------|------|------| | Cloud Storage | Armazenamento de objetos | Imagens, vídeo, backups, data lakes | "Arquivos não estruturados", "sem limite de capacidade", "arquivamento" | | Cloud SQL | Relacional gerenciado | Aplicativos web e sistemas de negócio comuns em MySQL, PostgreSQL ou SQL Server | "Manter nosso MySQL do jeito que está", "reduzir o esforço de gerenciamento" | | AlloyDB | Relacional compatível com PostgreSQL de alto desempenho | Sistemas de negócio em que o desempenho é crítico, consultas analíticas direto nos dados transacionais | "Compatível com PostgreSQL", "transações e análise juntas", "alto desempenho" | | Spanner | Relacional distribuído globalmente | Serviços como finanças, estoque e jogos globais que precisam de consistência forte no mundo todo | "No mundo todo", "escalar horizontalmente", "disponibilidade de 99,999%" | | Bigtable | NoSQL de colunas largas | Sensores IoT, séries temporais, tecnologia de anúncios, personalização em larga escala | "Milhões de operações por segundo", "latência de milissegundos", "séries temporais" | | Firestore | NoSQL de documentos | Aplicativos móveis e web, colaboração em tempo real, sincronização offline | "Aplicativo móvel", "sincronização em tempo real", "serverless" | | BigQuery | Data warehouse serverless | Análise com SQL e BI em escala de petabytes | "Análise em larga escala", "SQL sem gerenciar servidores" |
Dica para o exame: Depois de saber que precisa de um banco relacional, a última etapa é escala e desempenho. Um aplicativo comum usa o Cloud SQL; compatibilidade com PostgreSQL com mais desempenho e também análise significa AlloyDB; e escalonamento horizontal em escala global significa Spanner.
---
AlloyDB: PostgreSQL mais rápido, com análise incluída
O AlloyDB para PostgreSQL é um banco de dados totalmente gerenciado e totalmente compatível com PostgreSQL. A marca registrada dele é que você continua usando as ferramentas (psql, pgAdmin) e o código de PostgreSQL que já tem enquanto ganha muito mais desempenho e recursos de análise.
Transações e análise juntas (HTAP): executar consultas analíticas complexas sobre dados transacionais ativos com menos impacto no desempenho e na disponibilidade Mecanismo colunar: mantém na memória, em formato colunar, os dados de que a análise precisa para acelerar as consultas analíticas Pools de leitura: adicionar instâncias somente leitura para dividir a carga de leitura Consultor de índices: sugere melhorias de esquema que aumentam o desempenho AlloyDB Omni: uma versão que você baixa e executa on-premises, em outras nuvens ou em ambientes Kubernetes
| Aspecto | Cloud SQL | AlloyDB | Spanner | |------|------|------|------| | Mecanismo | MySQL, PostgreSQL, SQL Server | Compatível com PostgreSQL | O banco de dados distribuído do Google | | Como escala | Principalmente com um servidor maior, mais réplicas de leitura | Uma instância principal de alto desempenho e pools de leitura | Escala horizontalmente leituras e gravações, distribuído entre regiões | | Análise | Usado junto com um sistema de análise separado | O mecanismo colunar acelera a análise em tempo real | Dados operacionais em larga escala integrados à análise | | Quando se encaixa | O caso comum de levar um aplicativo existente do jeito que está | Sistemas de negócio em que o desempenho é crítico, sair de bancos de dados comerciais | Você precisa de um único banco de dados consistente no mundo todo |
Dica para o exame: "Compatível com PostgreSQL, mais rápido que o PostgreSQL padrão e queremos analisar diretamente os dados transacionais" é o AlloyDB. "A regulamentação exige que rodemos o mesmo banco de dados também on-premises" é o AlloyDB Omni.
---
Classes de armazenamento do Cloud Storage e Autoclass
O Cloud Storage permite escolher uma classe de armazenamento conforme a frequência com que você tira os dados para usar. É como guardar as roupas que você usa sempre no guarda-roupa e as de outras estações em um depósito. Guardar no depósito sai mais barato, mas tirar de lá dá trabalho.
| Classe | Duração mínima de armazenamento | Taxas de recuperação | Frequência de acesso adequada | Exemplo | |------|------|------|------|------| | Standard | Nenhuma | Não | Acesso frequente | Imagens do site, dados em análise | | Nearline | 30 dias | Sim | Cerca de uma vez por mês ou menos | Backups mensais | | Coldline | 90 dias | Sim | Cerca de uma vez por trimestre ou menos | Cópias para recuperação de desastres | | Archive | 365 dias | Sim | Cerca de uma vez por ano ou menos | Registros guardados por motivos legais, arquivos de longo prazo |
Todas as classes têm a mesma durabilidade (99,999999999% ao ano), e a latência de recuperação também é a mesma, em milissegundos. As diferenças são o custo de armazenamento, as taxas de recuperação e a duração mínima de armazenamento. Se você excluir os dados antes da duração mínima, o tempo restante é cobrado.
Autoclass: um guarda-roupa que se arruma sozinho
Com o Autoclass ativado, o Cloud Storage observa o padrão de acesso real de cada objeto do bucket e muda a classe dele automaticamente.
Os objetos novos começam no Standard Os objetos que ficam um tempo sem ser lidos passam para classes cada vez mais frias (a classe final padrão é Nearline, ou Archive se você configurar) Os objetos lidos voltam para o Standard Não há taxas de recuperação nem de exclusão antecipada; em troca, há uma taxa de gerenciamento Os objetos com menos de 128 KiB ficam no Standard
Dica para o exame: "Os padrões de acesso são imprevisíveis e queremos reduzir o custo de armazenamento sem esforço de gerenciamento" é o Autoclass. Mudar de classe por uma regra fixa, como "passar para Coldline depois de 30 dias", é o gerenciamento do ciclo de vida de objetos (Object Lifecycle Management).
---
Formas de levar um banco de dados para a nuvem
Há várias formas de levar um banco de dados existente para a nuvem, conforme o esforço que você investe e o benefício que procura. É como decidir se você muda os móveis do jeito que estão, compra móveis novos ou reforma a casa.
| Abordagem | O que significa | Exemplo | Características | |------|------|------|------| | Levar do jeito que está (rehost) | Instalar o banco de dados do jeito que está em uma VM do Compute Engine | Um servidor de banco de dados existente levado para uma VM | O mais rápido, mas você continua cuidando de patches e backups | | Ir para um serviço gerenciado com o mesmo mecanismo | Migrar para um serviço gerenciado do mesmo mecanismo de banco de dados | MySQL → Cloud SQL para MySQL | O Google assume patches e backups | | Modernizar para outro mecanismo | Troc