Projete soluções de banco de dados com SQL do Azure e Azure Cosmos DB
Converta compatibilidade, escala, disponibilidade, segurança, gerenciamento e custo em uma arquitetura de banco de dados justificável no Azure.
Tempo de estudo sugerido: 82 minutos • Nível intermediário • Reescrita autoral completa com resumo conciso de cada tópico
Por João Ricardo Dutra••Conteúdo autoral completo
1. Comece pela carga de trabalho e pelo resultado de negócio
Muitas organizações estão substituindo plataformas de dados antigas ou subdimensionadas, reduzindo custos de e preparando aplicações para recursos de nuvem e IA. A arquitetura deve nascer do inventário das cargas e do resultado da migração, não de um produto favorito.
Considere a Tailwind Traders, varejista fictícia de materiais para reforma com atuação mundial. Seu SQL Server local guarda clientes, histórico de pedidos, catálogos e dados de um portal interno de treinamento. Como CTO, você precisa de um desenho econômico na nuvem, com baixa latência, alta disponibilidade, risco de migração controlado e proteção adequada.
Projetar para o .
Projetar para a .
Projetar para .
Recomendar escalabilidade e disponibilidade.
Proteger , em trânsito e em uso.
Projetar para e para Tabela.
São pré-requisitos úteis o conhecimento conceitual de SQL Server e a experiência prática com soluções de banco de dados. As decisões deste capítulo correspondem diretamente ao exame AZ-305.
Resumo do tópico
Converta resultado de negócio, compatibilidade, níveis de serviço, segurança e custo em requisitos antes de escolher o serviço.
2. O oferece um espectro de gerenciamento e compatibilidade
Dados relacionais seguem um esquema compartilhado de tabelas, linhas, colunas, chaves e relacionamentos. No , a principal troca de arquitetura é quanto do gerenciamento delegar à plataforma e quanta compatibilidade de instância e sistema operacional preservar.
Principais opções relacionais.
Opção
Limite de gerenciamento
Melhor adequação
A Microsoft gerencia plataforma, atualizações do mecanismo, backups e disponibilidade.
Aplicações modernas, bancos únicos, pools elásticos, sem servidor e .
A Microsoft gerencia uma instância compatível com SQL Server em rede virtual nativa.
Lift-and-shift que depende de recursos no escopo da instância.
O gerencia a infraestrutura física; o cliente gerencia sistema operacional e SQL Server.
Migração rápida, versão específica, acesso ao SO e controle completo.
Mais compatibilidade e controle também transferem mais responsabilidade operacional ao cliente.
Resumo do tópico
Escolha a alternativa mais gerenciada que ainda atenda à compatibilidade de mecanismo, instância, rede e sistema operacional.
3. é um totalmente gerenciado
O abstrai o sistema operacional e a instância do SQL Server. A Microsoft cuida de atualizações, correções, backups, saúde e alta disponibilidade integrada. A equipe se concentra em esquema, consultas, política de segurança e aplicação.
O serviço atende aplicações de nuvem e cargas estruturadas existentes por meio de banco único, pool elástico, computação sem servidor e camada . Isolamento, perfil de utilização, crescimento, latência e objetivos de recuperação orientam a escolha.
Resumo do tópico
O elimina a administração de servidor e instância sem abrir mão de uma plataforma SQL relacional.
4. Banco único, pool elástico e atendem perfis distintos
Formatos de recursos do .
Formato
Comportamento
Use quando
Banco único
Objetivo de serviço e limites isolados.
Um banco tem demanda previsível ou gerenciamento independente.
Pool elástico
Vários bancos compartilham computação e armazenamento, respeitando limites individuais.
Muitos bancos têm picos variáveis e alternados, com baixa média.
distribuído, snapshots rápidos, réplicas de leitura e até 128 TB.
Bancos muito grandes ou crescentes exigem escala independente.
está disponível para bancos únicos e pools elásticos no modelo vCore, não no modelo DTU. Tamanho não é o único motivo: backup e restauração rápidos, escala de leitura, réplicas configuráveis e mudança ágil de computação também pesam.
Isolamento, uso compartilhado e escala distribuída são padrões diferentes.
Resumo do tópico
Use banco único para isolamento, pool elástico para demanda variável compartilhada e para escala e operações distribuídas.
5. DTU e vCore são modelos de compra diferentes
Uma unidade de transação de banco de dados (DTU) agrega computação, memória, armazenamento e E/S em objetivos predefinidos. Ela simplifica o dimensionamento quando a equipe prefere uma medida combinada. DTU existe no , mas não na .
O modelo vCore expõe núcleos virtuais e permite raciocinar separadamente sobre computação, memória, armazenamento e E/S. Ele aceita Benefício Híbrido do para licenças qualificadas do SQL Server e capacidade reservada. A Microsoft o recomenda para a maioria dos projetos novos.
Escolha do modelo de compra.
Requisito
Prefira
Dimensionamento agregado e histórico já medido em DTU.
DTU.
Recursos independentes, sem servidor, , benefício de licença ou reserva.
vCore.
.
vCore; DTU não está disponível.
Resumo do tópico
DTU é um pacote simples; vCore oferece mais transparência e flexibilidade para arquitetura e otimização de custos.
6. Sem servidor e ofertas gratuitas atendem uso intermitente ou avaliação
A camada de computação sem servidor escala automaticamente dentro dos limites configurados e cobra por segundo de uso. A pausa automática reduz gasto ocioso, mas a primeira solicitação após a pausa sofre latência de retomada. Ela está disponível em configurações vCore compatíveis de Uso Geral e .
A oferta gratuita do permite atualmente até dez bancos de Uso Geral por assinatura. Cada um recebe mensalmente 100.000 segundos de vCore, 32 GB de dados e 32 GB de backup durante a vigência da assinatura. Ao atingir o limite, o banco pode pausar até o mês seguinte ou continuar com cobrança, conforme a configuração.
Resumo do tópico
Use sem servidor para demanda variável com ociosidade e a oferta gratuita para desenvolvimento, considerando retomada e limites publicados.
7. favorece equipes focadas em construir
A AccuWeather combinou , e para entregar aplicações internas de previsão sem administrar bancos. A lição é: quando a aplicação aceita recursos no escopo do banco e a prioridade é rapidez com operações automatizadas, esse serviço é um forte padrão inicial.
Validar recursos no escopo do banco.
Escolher banco único ou pool elástico.
Selecionar DTU ou vCore e computação provisionada ou sem servidor.
Escolher Uso Geral, Comercialmente Crítico ou por latência, disponibilidade, escala e custo.
Testar migração, desempenho, conectividade e recuperação.
Resumo do tópico
Selecione o quando houver compatibilidade e operações gerenciadas e escala no nível do banco forem prioritárias.
8. preserva semântica de instância como
A fornece uma instância amplamente compatível com SQL Server, removendo a maior parte da administração da máquina virtual. Ela pode ser implantada como instância única ou em um pool de instâncias e foi criada para migrações que exigiriam grande alteração da aplicação.
A integração nativa com rede virtual e a ampla superfície do SQL Server favorecem lift-and-shift. A Microsoft cuida de correções, atualizações do mecanismo, backups e disponibilidade; o cliente continua responsável por bancos, logons, permissões, consultas e desenho da carga.
Resumo do tópico
A Instância Gerenciada é a ponte para cargas que precisam do comportamento de instância do SQL Server sem operar uma VM.
9. Recursos no escopo da instância são o teste decisivo
SQL Server Agent, CLR, Database Mail, transações distribuídas, servidores vinculados, Service Broker e outros recursos de instância são motivos comuns para escolher Instância Gerenciada. A maioria dos recursos do mecanismo está disponível, mas a avaliação deve conferir versão e dependências exatas.
O modelo vCore define o envelope de computação e armazenamento compartilhado por todos os bancos da instância. Um pool de instâncias pré-provisiona infraestrutura para hospedar instâncias menores, acelerando posicionamento e melhorando economia em múltiplas migrações.
Bancos compartilham recursos da instância; instâncias compartilham infraestrutura pré-provisionada no pool.
Resumo do tópico
Escolha a Instância Gerenciada pelos recursos exigidos e então dimensione recursos compartilhados e o possível pool.
10. Capacidade e oferta de avaliação têm limites explícitos
A oferta gratuita da dura 12 meses e inclui atualmente uma instância de Uso Geral por assinatura, quatro vCores, 720 horas de vCore por mês, 64 GB de dados e backups automáticos retidos por até sete dias. É para avaliação e prova de conceito, não continuidade de produção.
Uso Geral de última geração pode aceitar até 500 bancos de usuário e 32 TB por instância, com opções independentes de computação, armazenamento e E/S. Uso Geral clássico e Comercialmente Crítico têm outros limites. Confirme região, hardware, camada e tabela atual de recursos antes de definir a densidade de consolidação.
Resumo do tópico
Trate ofertas e capacidades máximas como restrições a validar, não como densidade útil garantida para qualquer carga.
11. A Komatsu ilustra o valor de lift-and-shift da Instância Gerenciada
A Komatsu queria consolidar aplicações conectadas a mainframes e preservar muitos recursos do SQL Server. Migrou cerca de 1,5 TB e obteve correções, atualizações de versão, backups e disponibilidade automáticos, além de menos trabalho operacional. Esse padrão favorece Instância Gerenciada quando rearquitetar custa mais que modernizar imediatamente.
Ainda é necessário validar desempenho, rede, autenticação, incompatibilidades, manutenção, recuperação e custo total. Compatibilidade ampla não elimina ensaio de migração.
Resumo do tópico
A Instância Gerenciada reduz retrabalho em ambientes ricos em recursos, mas lift-and-shift ainda exige avaliação e ensaio.
12. maximiza o controle
entrega uma instalação completa do SQL Server em uma VM do . É possível escolher versões compatíveis de SQL Server e sistema operacional, acessar o SO, instalar agentes, personalizar arquivos e manter recursos ausentes no .
Esse controle mantém com o cliente as correções e atualizações do SO e do SQL Server, configuração da instância, disponibilidade, validação de backup e capacidade. O automatiza tarefas selecionadas, mas o limite de responsabilidade continua sendo .
Controle de sistema operacional vem acompanhado de responsabilidade operacional.
Resumo do tópico
Use quando compatibilidade exata ou acesso ao SO forem obrigatórios e houver capacidade operacional.
13. Velocidade de migração, automação e licenciamento influenciam a VM
A Allscripts usou para mover aplicações de saúde adquiridas, executadas em aproximadamente 1.000 VMs, em cerca de três semanas. O caso mostra como replicar infraestrutura acelera a migração de aplicações fortemente acopladas ao servidor.
Acesso ao servidor: preservar ferramentas, autenticação, versões e layouts de arquivos.
Gerenciamento automatizado: usar a extensão do agente de do SQL e serviços do , validando cada operação.
Benefício Híbrido do : aplicar licenças elegíveis de Windows Server e SQL Server.
Disponibilidade: projetar zonas, conjuntos de disponibilidade, , grupos de disponibilidade, armazenamento e recuperação.
Resumo do tópico
A VM SQL costuma ser o caminho mais rápido para compatibilidade, mas o caso econômico inclui operações, disponibilidade e licenças.
14. Compare explicitamente as três opções do
Comparação das opções.
Eixo
Cenário
Aplicações modernas, bancos únicos, pools, sem servidor e .
Lift-and-shift que precisa de recursos de instância.
Migração rápida ou acesso ao SO.
Gerenciamento
de banco totalmente gerenciado.
de instância totalmente gerenciado.
SQL Server e SO gerenciados pelo cliente.
Compatibilidade
Recursos no escopo do banco.
Ampla superfície SQL Server e rede virtual nativa.
Recursos completos do SQL Server e do SO compatível.
Unidade de escala
Banco ou pool elástico.
Instância ou instâncias em pool.
VM, discos e arquitetura do SQL Server.
Exemplos
, sem servidor, pools.
SQL Server Agent, CLR, Service Broker, servidores vinculados.
DTC, FILESTREAM, modelo de recuperação simples, SSIS, SSRS, SSAS e agentes personalizados.
Resumo do tópico
Evidencie compatibilidade e responsabilidade; não compare os serviços apenas por preço ou tamanho máximo.
15. Escalabilidade dinâmica muda recursos sem comprar hardware
O pode alterar CPU, memória, taxa de E/S e armazenamento por meio dos objetivos de serviço. Um banco único recebe DTUs ou vCores definidos; um pool recebe envelope compartilhado e limites mínimos e máximos por banco.
A operação é online, mas não isenta de impacto: conexões podem ser interrompidas e algumas mudanças movem dados. A aplicação precisa de repetição, janela de manutenção, monitoramento e testes em carga normal e de pico.
Resumo do tópico
Escala na nuvem é capacidade arquitetural online, não permissão para ignorar conexões transitórias e tempo de transição.
16. Escala vertical altera os recursos de um banco
Escala vertical, ou aumentar e reduzir verticalmente, modifica o tamanho de computação ou objetivo de serviço de um banco ou pool. É direta quando a carga cabe em um banco e um envelope maior atende à demanda.
Para muitos bancos com baixa média e picos ocasionais, o pool elástico oferece capacidade agregada. Se todos atingirem o pico juntos, o pool ainda precisa ser dimensionado para essa simultaneidade.
Resumo do tópico
Escale verticalmente quando um envelope maior resolve; use pool quando vários bancos puderem compartilhar picos não simultâneos.
17. Escala horizontal particiona carga ou descarrega leituras
Escala horizontal adiciona bancos ou réplicas. O sharding particiona registros por uma chave; o gerenciador de mapa de fragmentos ajuda a aplicação a localizar o banco certo. Ele atende separação geográfica e grandes volumes, mas adiciona roteamento e consultas entre fragmentos.
Escala de leitura direciona consultas somente leitura para réplicas compatíveis. Ela amplia leituras e isola cargas, mas não aumenta a escrita primária. O desenho deve definir consistência, disponibilidade e comportamento com atraso ou .
Aumentar muda um envelope; distribuir separa trabalho; o pool explora demanda alternada.
Resumo do tópico
Use sharding para dados e escrita particionáveis e réplicas para leitura; ambos exigem roteamento consciente na aplicação.
18. Ferramentas elásticas apoiam desenhos entre bancos
Pools elásticos reduzem custo e simplificam desempenho quando muitos bancos têm demanda variável. Ferramentas de banco elástico apoiam sharding, enquanto consulta elástica permite que T-SQL acesse tabelas remotas em vários bancos para agregação e relatórios.
O padrão pode alimentar Excel, , Tableau e ferramentas de integração. O módulo de origem destaca a consulta elástica na camada Padrão; como suporte e desempenho variam, valide camada, segurança, envio de predicados e limitações atuais.
Resumo do tópico
Pools compartilham recursos, ferramentas elásticas distribuem dados e consulta elástica agrega resultados.
19. Associe o padrão de escalabilidade ao cenário
Recomendações de escalabilidade.
Cenário
Padrão
Motivo
Bancos por local têm picos imprevisíveis e alternados.
Pool elástico e dimensionamento vertical.
Compartilham capacidade adquirida.
Dados precisam ficar em bancos geográficos separados.
Sharding horizontal e mapa de fragmentos.
Partições são posicionadas e escaladas independentemente.
Ferramentas de BI precisam de um resultado de vários bancos.
Consulta elástica e ferramentas compatíveis.
T-SQL remoto expõe resultado consolidado.
Banco crítico com muitas leituras.
Escala de leitura Comercialmente Crítico ou réplicas .
Leituras saem da réplica primária.
Resumo do tópico
Escolha pool, escala vertical, sharding, consulta distribuída ou réplica segundo simultaneidade, localização e consulta.
20. A camada de serviço determina a arquitetura de disponibilidade
A disponibilidade do não tem uma implementação única. Uso Geral separa computação de armazenamento remoto; Comercialmente Crítico mantém quórum de réplicas com SSD local; separa computação, , e servidores de páginas. Isso muda latência, , leitura, crescimento e preço.
Zonas de disponibilidade aumentam resiliência a falha de nas regiões compatíveis. A aplicação ainda exige repetição e, para continuidade regional, grupos de ou replicação geográfica com operação testada.
Resumo do tópico
Escolha a camada pela arquitetura e falhas; depois acrescente controles zonais e regionais exigidos.
21. Uso Geral separa computação sem estado do armazenamento durável
Em Uso Geral — próximo de Básico ou Padrão no modelo DTU — o encaminha conexões a um nó de computação. tempdb usa SSD local. A arquitetura didática identifica Premium com redundância local para dados e e Standard com RA-GRS por padrão para backups; implantações atuais oferecem redundância de backup configurável, que deve ser conferida.
Se o nó falhar, o inicia o mecanismo em outro local, anexa os arquivos, executa recuperação e atualiza o roteamento. É um padrão gerenciado semelhante a de , com custo equilibrado e latência maior que SSD local.
Resumo do tópico
Uso Geral equilibra custo por meio da separação de computação e armazenamento, aceitando latência remota e recuperação no .
22. Comercialmente Crítico usa quórum de réplicas em SSD local
Comercialmente Crítico — comparável a Premium no modelo DTU — coloca dados e em SSD local em uma réplica primária e três secundárias. Replicação síncrona e quórum permitem rápido. Uma secundária pode atender leitura sem cobrança adicional do banco.
A camada atende aplicações críticas que precisam de latência de E/S consistente, alta resiliência, recuperação rápida e escala de leitura. A redundância de zona distribui réplicas em regiões compatíveis.
Resumo do tópico
Comercialmente Crítico paga por computação replicada com SSD local para obter baixa latência, rápido e leitura secundária.
23. distribui armazenamento e centraliza snapshots
usa réplicas de computação, serviço de , servidores de páginas e . O armazenamento cresce até 128 TB independentemente da computação. Backup contínuo por snapshot torna o tempo praticamente independente do tamanho e a restauração costuma levar minutos.
Mudanças de computação são rápidas porque os dados não precisam ser copiados para o novo nó. O arquiteto configura de zero a quatro réplicas de alta disponibilidade e pode adicionar réplicas nomeadas para leitura independente. Pelo menos uma réplica de HA é necessária para resiliência automática da computação; réplicas adicionais têm custo.
A camada muda o caminho físico até os dados e, portanto, latência, escala e .
Resumo do tópico
reúne armazenamento distribuído, snapshots rápidos, escala ágil e réplicas configuráveis.
24. A camada de disponibilidade é uma troca de requisitos
Comparação orientada à disponibilidade.
Camada
Arquitetura
Selecione quando
Uso Geral / DTU Básico ou Padrão
Computação sem estado sobre armazenamento remoto.
Custo e desempenho equilibrados.
Comercialmente Crítico / DTU Premium
Primária e secundárias síncronas em SSD local.
Baixa latência, rápido, resiliência e leitura secundária.
/ somente vCore
Computação, , e páginas distribuídos.
Muito armazenamento, backup rápido, escala ágil e várias leituras.
, zonas, número de réplicas, redundância de backup, replicação geográfica e repetição da aplicação devem ser avaliados juntos. O nome da camada não satisfaz sozinho a meta ponta a ponta.
Resumo do tópico
Selecione por latência, armazenamento, , leitura, zonas, recuperação regional e custo, não por um único .
25. Segurança começa com descoberta, classificação e proteção
Bancos de clientes podem conter contatos, pedidos, credenciais e pagamentos. Descoberta localiza dados sensíveis, classificação registra significado e risco, e proteção aplica acesso, criptografia, mascaramento, monitoramento e governança adequados.
O desenho deve mapear controles ao ciclo de vida: onde os bytes ficam, como trafegam e onde são processados. Criptografia não substitui identidade, privilégio mínimo, rede, auditoria, proteção contra ameaças, retenção e código seguro.
Resumo do tópico
Classifique dados e ciclo de vida e então combine criptografia com identidade, rede, monitoramento e governança.
26. , em trânsito e em uso têm exposições diferentes
Estados e controles representativos.
Estado
Significado
Controles
Em repouso
Arquivos, e backups armazenados.
TDE, criptografia de armazenamento, chaves e proteção de backup.
Em trânsito
Tráfego entre clientes, serviços, réplicas ou regiões.
1.2 ou superior, certificados, conexão privada e drivers seguros.
Em uso
Valores consultados ou processados em memória ou aplicação.
Always Encrypted, enclaves seguros, controle de acesso e mascaramento de saída.
Resumo do tópico
Aplique um controle apropriado a cada estado; um único mecanismo não cobre armazenamento, rede e processamento.
27. TDE protege arquivos e backups em repouso
Transparent Data Encryption (TDE) criptografa e descriptografa em tempo real páginas, e backups. Protege , e contra acesso offline malicioso. Novos bancos já nascem com TDE ativado.
TDE não exige alteração da aplicação, mas não impede um principal autorizado de ler linhas. Chaves gerenciadas pela plataforma simplificam; chaves do cliente no dão controle e separação, criando também deveres de disponibilidade e rotação.
Resumo do tópico
TDE protege arquivos, e backups contra exposição offline; autorização e gerenciamento de chaves tratam outros riscos.
28. protege conexões de banco em trânsito
, e exigem 1.2 ou superior nas conexões compatíveis. criptografa o fluxo entre cliente e servidor e ajuda a autenticar o ponto de extremidade. 1.0 e 1.1 foram desativados.
Use drivers atuais, valide certificado e nome do servidor, desative fallback inseguro e combine com pontos de extremidade privados ou redes controladas quando necessário.
Resumo do tópico
1.2 ou superior criptografa a conexão; drivers, certificados e rede completam a proteção de transporte.
Mascaramento dinâmico altera a apresentação de colunas para usuários sem UNMASK, mantendo o dado armazenado. Pode mostrar só os últimos dígitos de um cartão ou ocultar parte de um e-mail. Reduz exposição acidental, mas não é criptografia nem defesa suficiente contra um usuário hostil capaz de consultar o banco.
Always Encrypted criptografa valores no cliente para que o mecanismo não receba as chaves em texto simples. Enclaves seguros permitem operações mais ricas nas configurações compatíveis. Use mascaramento para apresentação e Always Encrypted para proteção criptográfica de valores em uso.
Mascaramento e criptografia solucionam riscos diferentes.
Resumo do tópico
Mascare a saída para controlar exibição; use Always Encrypted quando valores sensíveis precisarem permanecer criptograficamente protegidos.
30. é uma plataforma gerenciada e global
é um banco totalmente gerenciado para aplicações modernas, inclusive IA. A plataforma cuida de infraestrutura, correções, backups e capacidade, com modelos sem servidor e escala automática. Oferece distribuição global, consistência ajustável, indexação automática e desempenho de milissegundos de um dígito em operações compatíveis.
para Tabela armazena entidades de chave-valor flexíveis identificadas por PartitionKey e RowKey e usa operações familiares do Tables. Aplicações de podem migrar com poucas mudanças, mas taxa de transferência, consistência, distribuição e cobrança precisam de desenho próprio.
Resumo do tópico
Escolha para global e elástico; a para Tabela preserva o modelo do Tables.
31. e Cosmos DB para Tabela trocam custo por garantias
Comparação atual dos serviços.
Recurso
para Tabela
Latência
Rápida, sem limite superior.
Leitura abaixo de 10 ms e escrita abaixo de 15 ms no percentil 99 nas condições do .
Taxa de transferência
Variável; meta de 20.000 operações/s por tabela.
Reservada, sem limite superior da conta e mais de 10 milhões de operações/s por tabela no modo provisionado.
Distribuição
Uma região primária e secundária legível opcional.
Uma a mais de 30 regiões, com gerenciado ou manual.
Indexação e consulta
Índice primário em PartitionKey e RowKey; demais consultas varrem.
Indexação automática de todas as propriedades.
Consistência
Forte na primária e eventual na secundária.
Cinco níveis ajustáveis.
Preço
Por consumo.
Sem servidor por consumo ou capacidade provisionada.
Disponibilidade
99,99%.
99,99% em contas elegíveis e até 99,999% de leitura em múltiplas regiões qualificadas.
favorece economia simples; Cosmos DB acrescenta distribuição, índices, consistência e garantias.
Resumo do tópico
Mantenha para chave-valor econômico; use Cosmos DB para Tabela quando escala global e garantias justificarem.
32. Verificação de conhecimento: escolha pelas restrições rígidas
Respostas da avaliação.
Cenário
Melhor resposta
Justificativa
Inventário exige autenticação do Windows, customização completa e acesso ao SO.
.
É a opção que fornece acesso ao sistema operacional e controle completo.
RH quer menos administração, mas depende de CLR e Service Broker.
.
Preserva recursos de instância em gerenciado.
Bancos locais têm entre 40 e 80 TB.
.
aceita até 128 TB com armazenamento distribuído.
No exame, identifique primeiro a restrição inegociável: SO, compatibilidade de instância ou escala. Só então otimize custo e gerenciamento entre os candidatos restantes.
Resumo do tópico
Compatibilidade e capacidade eliminam opções antes de preferências mais brandas como conveniência e preço.
33. Checklist de arquitetura e síntese do capítulo
Inventariar esquemas, tamanho, crescimento, dependências, autenticação, recursos de instância, integrações com SO e rede.
Escolher Banco de Dados SQL, Instância Gerenciada ou VM pela compatibilidade mínima exigida.
Escolher banco, pool elástico, pool de instâncias, sharding ou réplicas segundo utilização e escala.
Definir DTU ou vCore, provisionado ou sem servidor, benefícios de licença e reservas.
Associar Uso Geral, Comercialmente Crítico ou a latência, armazenamento, , leitura e custo.
Projetar repetição, zonas, continuidade regional, backup, restauração e testado.
Proteger repouso com TDE, trânsito com e valores em uso com Always Encrypted; usar mascaramento apenas para exibição.
Escolher ou Cosmos DB para Tabela por distribuição, latência, índice, consistência, taxa e preço.
Ensaiar migração, desempenho, recuperação, rotação de chaves, e retorno.
Para praticar, abra o Microsoft Copilot no Microsoft Edge ou em copilot.microsoft.com. Peça que compare serviços relacionais, dê exemplos de escala do , contraste e com prós e contras e liste limites de escalabilidade do Cosmos DB. Trate a resposta como hipótese e verifique no Microsoft Learn, preços, regiões e prova de conceito.
Resumo do tópico
Uma arquitetura defensável torna compatibilidade, gerenciamento, escala, disponibilidade, segurança, custo e recuperação rastreáveis.
