Considerações da plataforma de dados para cargas de trabalho críticas no Azure

A seleção de uma plataforma de dados de aplicativo eficaz é mais uma área de decisão crucial, que tem implicações de longo alcance em outras áreas de design. O Azure finalmente oferece uma infinidade de plataformas de dados relacionais, não relacionais e analíticas, que diferem muito na funcionalidade. Portanto, é essencial que os principais requisitos não funcionais sejam totalmente considerados juntamente com outros fatores de decisão, como consistência, operabilidade, custo e complexidade. Por exemplo, a capacidade de operar em uma configuração de escrita em várias regiões terá uma influência crítica sobre a adequação a uma plataforma globalmente disponível.

Essa área de design se expande no design do aplicativo, fornecendo considerações e recomendações importantes para informar a seleção de uma plataforma de dados ideal.

Importante

Este artigo faz parte da série de cargas de trabalho de missão crítica do Azure Well-Architected . Se você não estiver familiarizado com esta série, recomendamos começar com o que é uma carga de trabalho crítica?

Os Quatro Vs de Big Data

Os 'Quatro Vs do Big Data' fornecem uma estrutura para entender melhor as características necessárias para uma plataforma de dados com alta disponibilidade e como os dados podem ser usados para maximizar o valor comercial. Esta seção explorará, portanto, como as características de Volume, Velocidade, Variedade e Veracity podem ser aplicadas em um nível conceitual para ajudar a criar uma plataforma de dados usando tecnologias de dados apropriadas.

• Volume: quanto de dados está entrando para informar a capacidade de armazenamento e os requisitos de hierarquização - isso é o tamanho do conjunto de dados.
• Velocidade: a rapidez com que os dados são processados, seja em lotes ou fluxos contínuos - essa é a taxa de fluxo.
• Variety: a organização e o formato de dados, capturando formatos estruturados, semiestruturados e não estruturados - ou seja, dados em vários repositórios ou tipos.
• Veracidade: inclui a procedência e a curadoria de conjuntos de dados considerados para governança e garantia de qualidade de dados, ou seja, a precisão dos dados.

Considerações sobre design

Volume

• Volumes de dados futuros existentes (se houver) e esperados com base nas taxas de crescimento de dados previstas alinhadas com os objetivos e planos de negócios.

  • O volume de dados deve abranger os próprios dados e índices, logs, telemetria e outros conjuntos de dados aplicáveis.
  • Aplicativos críticos para negócios de grande porte e para missões críticas normalmente geram e armazenam grandes volumes (GB e TB) diariamente.
  • Pode haver implicações significativas de custo associadas à expansão de dados.

• O volume de dados pode flutuar devido à alteração de circunstâncias comerciais ou procedimentos de manutenção.

• O volume de dados pode ter um impacto profundo no desempenho da consulta da plataforma de dados.

• Pode haver um impacto profundo associado ao alcance dos limites de volume da plataforma de dados.

  • Isso resultará em tempo de inatividade? e se sim, por quanto tempo?
  • Quais são os procedimentos de mitigação? e a mitigação exigirá alterações no aplicativo?
  • Haverá um risco de perda de dados?

• Recursos como o TTL (Time to Live) podem ser usados para gerenciar o crescimento de dados excluindo automaticamente registros após um tempo decorrido, usando a criação ou modificação de registro.

  • Por exemplo, o Azure Cosmos DB fornece uma funcionalidade de TTL interna.

Velocity

• A velocidade com que os dados são emitidos de vários componentes do aplicativo e os requisitos de taxa de transferência para a rapidez com que os dados precisam ser confirmados e recuperados são essenciais para determinar uma tecnologia de dados ideal para os principais cenários de carga de trabalho.

  • A natureza dos requisitos de taxa de transferência varia conforme o cenário de carga de trabalho, como aqueles que são intensivos em leitura ou em gravação.
    • Por exemplo, as cargas de trabalho analíticas normalmente precisarão atender a uma alta taxa de leitura.
  • Qual é a taxa de transferência necessária? E como a vazão é esperada para crescer?
  • Quais são os requisitos de latência de dados em P50/P99 em níveis de carga de referência?

• Recursos como suporte a um design sem bloqueio, ajuste de índice e políticas de consistência são essenciais para alcançar a alta taxa de transferência.

  • Otimizar a configuração para alto rendimento envolve concessões, que devem ser totalmente compreendidas.
  • Os padrões de persistência e de mensagens para nivelamento de carga, como CQRS e Event Sourcing, podem ser usados para otimizar ainda mais a taxa de transferência.

• Os níveis de carga flutuarão naturalmente para muitos cenários de aplicativo, com picos naturais exigindo um grau suficiente de elasticidade para lidar com a demanda variável, mantendo a taxa de transferência e a latência.

  • A escalabilidade agile é fundamental para dar suporte efetivamente a níveis de taxa de transferência e carga variáveis sem superprovisionar os níveis de capacidade.
    • A taxa de transferência de leitura e gravação deve ser dimensionada de acordo com os requisitos do aplicativo e a carga.
    • As operações de escala vertical e horizontal podem ser aplicadas para responder à alteração dos níveis de carga.

• O impacto das quedas de taxa de transferência pode variar com base no cenário de carga de trabalho.

  • Haverá interrupção de conectividade?
  • As operações individuais retornarão códigos de falha enquanto o plano de controle continuar operando?
  • A plataforma de dados ativará o controle de fluxo e, em caso afirmativo, por quanto tempo?

• A recomendação fundamental de projeto de aplicação para usar uma distribuição geográfica ativa-ativa apresenta desafios em relação à consistência de dados.

  • Há uma compensação entre consistência e desempenho em relação à semântica transacional ACID completa e ao comportamento de bloqueio tradicional.
    • Minimizar a latência de gravação virá ao custo da consistência de dados.

• Em uma configuração de gravação de várias regiões, as alterações precisarão ser sincronizadas e mescladas entre todas as réplicas, com a resolução de conflitos quando necessário, e isso pode afetar os níveis de desempenho e a escalabilidade.

• Réplicas somente leitura (intra-região e entre-regiões) podem ser usadas para minimizar a latência de ida e volta e distribuir o tráfego, aumentando assim o desempenho, a taxa de transferência, a disponibilidade e a escalabilidade.

• Uma camada de cache pode ser usada para aumentar a taxa de transferência de leitura para melhorar a experiência do usuário e os tempos de resposta do cliente de ponta a ponta.

  • Os tempos de expiração e as políticas de cache precisam ser considerados para otimizar a recenteidade dos dados.

Variedade

• O modelo de dados, os tipos de dados, as relações de dados e o modelo de consulta pretendido afetarão fortemente as decisões da plataforma de dados.

  • O aplicativo requer um modelo de dados relacional ou pode dar suporte a um modelo de dados de variável ou não relacional?
  • Como o aplicativo consultará dados? E as consultas dependerão de conceitos de camada de banco de dados, como junções relacionais? Ou o aplicativo fornece essa semântica?

• A natureza dos conjuntos de dados considerados pelo aplicativo pode ser variada, desde conteúdo não estruturado, como imagens e vídeos, ou arquivos mais estruturados, como CSV e Parquet.

  • Normalmente, as cargas de trabalho do aplicativo composto terão conjuntos de dados distintos e requisitos associados.

• Além de plataformas de dados relacionais ou não relacionais, as plataformas de dados de grafo ou chave-valor também podem ser adequadas para determinadas cargas de trabalho de dados.

  • Algumas tecnologias atendem a modelos de dados de esquema variável, em que os itens de dados são semanticamente semelhantes e/ou armazenados e consultados juntos, mas diferem estruturalmente.

• Em uma arquitetura de microsserviço, os serviços de aplicativos individuais podem ser criados com armazenamentos de dados distintos com otimização de cenário, em vez de depender de um único armazenamento de dados monolítico.

  • Padrões de design, como o SAGA , podem ser aplicados para gerenciar a consistência e as dependências entre diferentes armazenamentos de dados.
    • Consultas diretas entre bancos de dados podem impor restrições de co-localização.
  • O uso de várias tecnologias de dados adicionará um grau de sobrecarga de gerenciamento para manter tecnologias englobadas.

• Os conjuntos de recursos para cada serviço do Azure diferem entre idiomas, SDKs e APIs, o que pode afetar muito o nível de ajuste de configuração que pode ser aplicado.

• Os recursos de alinhamento otimizado com o modelo de dados e os tipos de dados englobados influenciarão fortemente as decisões da plataforma de dados.

  • Consultar camadas como procedimentos armazenados e mapeadores relacionais de objeto.
  • Funcionalidade de consulta neutra em linguagem, como uma camada de API REST protegida.
  • Recursos de continuidade de negócios, como backup e restauração.

• Os armazenamentos de dados analíticos normalmente dão suporte ao armazenamento poliglota para vários tipos de estruturas de dados.

  • Ambientes de runtime analítico, como o Apache Spark, podem ter restrições de integração para analisar estruturas de dados poliglotas.

• Em um contexto empresarial, o uso de processos e ferramentas existentes e a continuidade das habilidades podem ter uma influência significativa no design da plataforma de dados e na seleção de tecnologias de dados.

Veracidade

• Vários fatores devem ser considerados para validar a precisão dos dados em um aplicativo, e o gerenciamento desses fatores pode ter uma influência significativa no design da plataforma de dados.

  • Consistência de dados.
  • Recursos de segurança da plataforma.
  • Governança de dados.
  • Gerenciamento de alterações e evolução do esquema.
  • Dependências entre conjuntos de dados.

• Em qualquer aplicativo distribuído com várias réplicas de dados, há uma compensação entre consistência e latência, conforme expresso nos teoremas CAP e PACELC .

  • Quando leitores e gravadores são distribuídos de forma distinta, um aplicativo deve optar por retornar a versão mais rápida disponível de um item de dados, mesmo que esteja desatualizada em comparação com uma gravação completa (atualização) desse item de dados em outra réplica ou a versão mais up-todata do item de dados, que pode incorrer em latência adicional para determinar e obter o estado mais recente.
  • A consistência e a disponibilidade podem ser configuradas no nível da plataforma ou no nível de solicitação de dados individual.
  • Qual é a experiência do usuário se os dados devem ser atendidos de uma réplica mais próxima do usuário, o que não reflete o estado mais recente de uma réplica diferente? Ou seja, o aplicativo pode dar suporte possivelmente ao fornecimento de dados desatualizados?

• Em um contexto de gravação de várias regiões, quando o mesmo item de dados é alterado em duas réplicas de gravação separadas antes que qualquer alteração possa ser replicada, é criado um conflito que deve ser resolvido.

  • Políticas de resolução de conflitos padronizadas, como "Last Write Wins", ou uma estratégia personalizada com lógica personalizada podem ser aplicadas.

• A implementação de requisitos de segurança pode afetar negativamente a taxa de transferência ou o desempenho.

• A criptografia em repouso pode ser implementada na camada do aplicativo usando a criptografia do lado do cliente e/ou a camada de dados usando a criptografia do lado do servidor, se necessário.

• O Azure dá suporte a vários modelos de criptografia, incluindo criptografia do lado do servidor que usa chaves gerenciadas pelo serviço, chaves gerenciadas pelo cliente no Key Vault ou chaves gerenciadas pelo cliente em hardware controlado pelo cliente.

  • Com a criptografia do lado do cliente, as chaves podem ser gerenciadas no Key Vault ou em outro local seguro.

• A criptografia de link de dados do MACsec (IEEE 802.1AE MAC) é usada para proteger todo o tráfego que se move entre datacenters do Azure na rede de backbone da Microsoft.

  • Os pacotes são criptografados e descriptografados nos dispositivos antes de serem enviados, impedindo ataques físicos de "homem no meio" ou espionagem/escuta telefônica.

• Autenticação e autorização para o plano de dados e o plano de controle.

  • Como a plataforma de dados autenticará e autorizará o acesso ao aplicativo e o acesso operacional?

• Observabilidade por meio do monitoramento da integridade da plataforma e do acesso a dados.

  • Como o alerta será aplicado a condições fora dos limites operacionais aceitáveis?

Recomendações de design

Volume

• Verifique se os volumes de dados futuros associados ao crescimento orgânico não devem exceder os recursos da plataforma de dados.

  • Prever taxas de crescimento de dados alinhadas aos planos de negócios e usar taxas estabelecidas para informar os requisitos de capacidade contínuos.
  • Compare os volumes agregados e por registro de dados com os limites da plataforma de dados.
  • Se houver um risco de limites serem atingidos em circunstâncias excepcionais, verifique se as mitigações operacionais estão em vigor para evitar o tempo de inatividade e a perda de dados.

• Monitore o volume de dados e valide-o em relação a um modelo de capacidade, considerando os limites de escala e as taxas de crescimento de dados esperadas.

  • Verifique se as operações de escala estão alinhadas com os requisitos de armazenamento, desempenho e consistência.
  • Quando uma nova unidade de escala é introduzida, os dados subjacentes podem precisar ser replicados, o que levará tempo e provavelmente introduzirá uma penalidade de desempenho durante a replicação. Portanto, verifique se essas operações são executadas fora do horário comercial crítico, se possível.

• Defina as camadas de dados do aplicativo para classificar conjuntos de dados com base no uso e na criticidade para facilitar a remoção ou descarregamento de dados mais antigos.

  • Considere classificar conjuntos de dados em camadas "quentes", "mornos" e "frios" ("arquivo").
    • Por exemplo, as implementações de referência fundamental usam o Azure Cosmos DB para armazenar dados 'quentes' usados ativamente pelo aplicativo, enquanto o Armazenamento do Azure é usado para dados de operações 'frios' para fins analíticos.

• Configure procedimentos de manutenção para otimizar o crescimento de dados e aumentar a eficiência dos dados, como o desempenho de consultas e o gerenciamento da expansão de dados.

  • Configure a expiração de TTL (Time-To-Live) para dados que não são mais necessários e não têm valor analítico de longo prazo.
    • Valide se os dados antigos podem ser colocados em camadas com segurança no armazenamento secundário ou excluídos sem um impacto adverso no aplicativo.
  • Descarregar dados não críticos para o armazenamento a frio secundário, mas mantê-los para valor analítico e para atender aos requisitos de auditoria.
  • Colete dados de telemetria e estatísticas de uso da plataforma para permitir que as equipes de DevOps avaliem continuamente os requisitos de manutenção e o dimensionamento adequado dos bancos de dados.

• Em linha com um design de aplicativo de microsserviço, considere o uso de várias tecnologias de dados diferentes em paralelo, com soluções de dados otimizadas para cenários de carga de trabalho específicos e requisitos de volume.

  • Evite criar um único armazenamento de dados monolítico em que o volume de dados da expansão possa ser difícil de gerenciar.

Velocity

• A plataforma de dados deve ser inerentemente projetada e configurada para dar suporte à alta taxa de transferência, com cargas de trabalho separadas em contextos diferentes para maximizar o desempenho usando soluções de dados otimizadas para cenário.

  • Verifique se a taxa de transferência de leitura e gravação para cada cenário de dados pode ser dimensionada de acordo com os padrões de carga esperados, com tolerância suficiente para variação inesperada.
  • Separe cargas de trabalho de dados diferentes, como operações transacionais e analíticas, em contextos de desempenho distintos.

• Carregar o nível por meio do uso de mensagens assíncronas sem bloqueio, por exemplo, usando os padrões CQRS ou Fornecimento de Eventos .

  • Pode haver latência entre solicitações de gravação e quando novos dados ficam disponíveis para leitura, o que pode ter um impacto na experiência do usuário.
    • Esse impacto deve ser compreendido e aceitável no contexto dos principais requisitos de negócios.

• Verifique a escalabilidade ágil para dar suporte a níveis de carga e taxa de transferência variável.

  • Se os níveis de carga forem altamente voláteis, considere o excesso de provisionamento dos níveis de capacidade para garantir que a taxa de transferência e o desempenho sejam mantidos.
  • Teste e valide o impacto nas cargas de trabalho do aplicativo composto quando a taxa de transferência não puder ser mantida.

• Priorize os serviços de dados nativos do Azure com operações de escala automatizadas para facilitar uma resposta rápida à volatilidade no nível de carga.

  • Configure o dimensionamento automático com base nos limites do serviço interno e do conjunto de aplicativos.
  • O escalonamento deve iniciar e concluir em intervalos de tempo consistentes com as necessidades empresariais.
  • Para cenários em que a interação manual é necessária, estabeleça playbooks operacionais automatizados que podem ser acionados em vez de executar ações operacionais manuais.
    • Considere se os gatilhos automatizados podem ser aplicados como parte dos investimentos subsequentes de engenharia.

• Monitore a taxa de transferência de leitura e gravação de dados do aplicativo em relação aos requisitos de latência P50/P99 e alinhe-se a um modelo de capacidade do aplicativo.

• O excesso de taxa de transferência deve ser tratado de forma adequada pela plataforma de dados ou camada de aplicativo e capturado pelo modelo de saúde para fins de representação operacional.

• Implemente o cache para cenários de dados 'frequentes' para minimizar os tempos de resposta.

  • Aplique políticas apropriadas para expiração de cache e tarefas de limpeza para evitar o crescimento de dados descontrolado.
    • Expire os itens de cache quando os dados de backup forem alterados.
    • Se a expiração do cache for estritamente baseada em Time-To-Live (TTL), é necessário compreender o impacto e a experiência do cliente ao fornecer dados desatualizados.

Variedade

• Em alinhamento com o princípio de um design nativo da nuvem e do Azure, é altamente recomendável priorizar os serviços gerenciados do Azure para reduzir a complexidade operacional e de gerenciamento e aproveitar os futuros investimentos de plataforma da Microsoft.

• Em alinhamento com o princípio de design do aplicativo de arquiteturas de microsserviços flexívelmente acopladas, permita que serviços individuais usem armazenamentos de dados distintos e tecnologias de dados otimizadas para cenários.

  • Identifique os tipos de estrutura de dados que o aplicativo manipulará para cenários específicos de carga de trabalho.
  • Evite criar uma dependência em um único armazenamento de dados monolítico.
    • Considere o padrão de design SAGA em que as dependências entre armazenamentos de dados existem.

• Valide se os recursos necessários estão disponíveis para tecnologias de dados selecionadas.

  • Verifique o suporte para idiomas necessários e recursos do SDK. Nem todas as funcionalidades estão disponíveis para cada idioma/SDK da mesma forma.

Veracidade

• Adote um design de plataforma de dados de várias regiões e distribua réplicas entre regiões para obter a máxima confiabilidade, disponibilidade e desempenho, aproximando os dados dos pontos de extremidade do aplicativo.

  • Distribua réplicas de dados entre AZs (Zonas de Disponibilidade) em uma região (ou use camadas de serviço com redundância de zona) para maximizar a disponibilidade intra-região.

• Quando os requisitos de consistência permitirem, utilize um design de plataforma de dados com capacidade de gravação em várias regiões para maximizar a disponibilidade e a confiabilidade globais.

  • Considere os requisitos de negócios para a resolução de conflitos quando o mesmo item de dados é alterado em duas réplicas de gravação diferentes antes de qualquer alteração ser replicada, criando assim um conflito.
    • Use políticas padronizadas de resolução de conflitos, como "Última vitória" sempre que possível
      • Se uma estratégia personalizada com lógica personalizada for necessária, verifique se as práticas de CI/CD DevOps são aplicadas para gerenciar a lógica personalizada.

• Teste e valide os recursos de backup e restauração e operações de failover por meio de testes de caos em processos de entrega contínuos.

• Execute parâmetros de comparação de desempenho para garantir que os requisitos de desempenho e taxa de transferência não sejam afetados pela inclusão de recursos de segurança necessários, como criptografia.

  • Verifique se os processos de entrega contínua consideram o teste de carga em relação a parâmetros de desempenho conhecidos.

• Ao aplicar criptografia, é altamente recomendável usar chaves de criptografia gerenciadas pelo serviço como uma forma de reduzir a complexidade de gerenciamento.

  • Se houver um requisito de segurança específico para chaves gerenciadas pelo cliente, verifique se os procedimentos de gerenciamento de chaves apropriados são aplicados para garantir a disponibilidade, o backup e a rotação de todas as chaves consideradas.

Observação

Ao integrar com uma implementação organizacional mais ampla, é fundamental que uma abordagem centrada no aplicativo seja aplicada ao provisionamento e à operação de componentes da plataforma de dados em um design de aplicativo.

Mais especificamente, para maximizar a confiabilidade, é fundamental que os componentes individuais da plataforma de dados respondam adequadamente à integridade do aplicativo por meio de ações operacionais que podem incluir outros componentes do aplicativo. Por exemplo, em um cenário em que recursos adicionais da plataforma de dados são necessários, o dimensionamento da plataforma de dados junto com outros componentes de aplicativo de acordo com um modelo de capacidade provavelmente será necessário, potencialmente por meio do provisionamento de unidades de escala adicionais. Essa abordagem será restringida, em última análise, se houver uma dependência rígida de uma equipe de operações centralizada para resolver problemas relacionados à plataforma de dados isoladamente.

Em última análise, o uso de serviços de dados centralizados (ou seja, DBaaS central de TI) introduz gargalos operacionais que dificultam significativamente a agilidade por meio de uma experiência de gerenciamento em grande parte não contextualizada e devem ser evitados em um contexto de missão crítica ou crítico para os negócios.

Referências adicionais

Diretrizes adicionais de plataforma de dados estão disponíveis no Guia de Arquitetura de Aplicativo do Azure.

• Árvore de decisão do Repositório de Dados do Azure
• Critérios para escolher um Armazenamento de Dados
• Armazenamentos de dados não relacionais
• Armazenamentos de dados OLTP relacionais

Banco de dados com capacidade de gravação em várias regiões distribuído globalmente

Para acomodar plenamente as aspirações de design ativo-ativo distribuídas globalmente de um aplicativo, é altamente recomendável considerar uma plataforma de dados de gravação multirregional distribuída, onde as alterações em réplicas independentes graváveis sejam sincronizadas e integradas entre todas as réplicas, com resolução de conflitos quando necessário.

Importante

Os microsserviços podem não exigir um armazenamento de dados de gravação distribuído de várias regiões, portanto, deve-se considerar o contexto arquitetônico e os requisitos de negócios de cada cenário de carga de trabalho.

O Azure Cosmos DB fornece um armazenamento de dados NoSQL distribuído globalmente e altamente disponível, oferecendo escritas em várias regiões e consistência ajustável de forma nativa. As considerações e recomendações de design nesta seção se concentrarão, portanto, no uso ideal do Azure Cosmos DB.

Considerações sobre o design

Azure Cosmos DB

• O Azure Cosmos DB armazena dados em contêineres, que são repositórios transacionais indexados baseados em linha projetados para permitir leituras e gravações transacionais rápidas com tempos de resposta na ordem dos milissegundos.

• O Azure Cosmos DB dá suporte a várias APIs diferentes com conjuntos de recursos diferentes, como SQL, Cassandra e MongoDB.

  • O Azure Cosmos DB de primeira parte para NoSQL fornece o conjunto de recursos mais avançado e normalmente é a API em que os novos recursos ficarão disponíveis primeiro.

• O Azure Cosmos DB dá suporte aos modos de conectividade Gateway e Direct, em que o modo Direct facilita a conectividade por TCP com os nós de réplica do backend do Azure Cosmos DB para melhorar o desempenho com menos saltos de rede, enquanto o modo Gateway fornece conectividade HTTPS para os nós de gateway de front-end.

  • O modo direto só está disponível ao usar o Azure Cosmos DB para NoSQL e atualmente só tem suporte em plataformas SDK .NET e Java.

• Dentro das regiões habilitadas para Zona de Disponibilidade, o Azure Cosmos DB oferece suporte à redundância da Zona de Disponibilidade (AZ) para alta disponibilidade e resiliência a falhas zonais em uma região.

• O Azure Cosmos DB mantém quatro réplicas de dados em uma única região e, quando a redundância da Zona de Disponibilidade (AZ) está habilitada, o Azure Cosmos DB garante que as réplicas de dados sejam colocadas em vários AZs para proteger contra falhas zonais.

  • O protocolo de consenso Paxos é aplicado para obter quorum entre réplicas em uma região.

• Uma conta do Azure Cosmos DB pode ser facilmente configurada para replicar dados em várias regiões para reduzir o risco de uma única região ficar indisponível.

  • A replicação pode ser configurada com gravações de região única ou gravações de várias regiões.
    • Com gravações de região única, uma região de "hub" primária é usada para atender a todas as gravações e, se essa região de "hub" ficar indisponível, uma operação de failover deverá ocorrer para promover outra região como gravável.
    • Com gravações de várias regiões, os aplicativos podem gravar em qualquer região de implantação configurada, o que replicará as alterações entre todas as outras regiões. Se uma região não estiver disponível, as regiões restantes serão usadas para atender ao tráfego de escrita.

• Em uma configuração de gravação em várias regiões, podem ocorrer conflitos de atualização (inserir, substituir, excluir) quando os gravadores atualizam simultaneamente o mesmo item em diversas regiões.

• O Azure Cosmos DB fornece duas políticas de resolução de conflitos, que podem ser aplicadas para resolver conflitos automaticamente.

  • O LWW (Last Write Wins) aplica um protocolo de relógio sincronizado usando uma propriedade de carimbo de data/hora definida pelo sistema como caminho para resolução de conflitos. Se de um conflito o item com o valor mais alto para o caminho de resolução de conflitos se tornar o vencedor e se vários itens tiverem o mesmo valor numérico, o sistema selecionará um vencedor para que todas as regiões possam convergir para a mesma versão do item confirmado.
    • Com conflitos de exclusão, a versão excluída sempre vence os conflitos de inserção ou substituição, independentemente do valor do caminho de resolução de conflitos.
    • Last Write Wins é a política de resolução de conflitos padrão.
    • Ao usar o Azure Cosmos DB para NoSQL, uma propriedade numérica personalizada, como uma definição de carimbo de data/hora personalizada, pode ser usada para resolução de conflitos.
  • As políticas de resolução personalizada permitem que a semântica definida pelo aplicativo reconcilie conflitos usando um procedimento armazenado de mesclagem registrado que é automaticamente invocado quando conflitos são detectados.
    • O sistema fornece exatamente uma garantia única para a execução de um procedimento de mesclagem como parte do protocolo de compromisso.
    • Uma política personalizada de resolução de conflitos só está disponível com o Azure Cosmos DB para NoSQL e só pode ser definida no momento da criação do contêiner.

• Em uma configuração de gravação de várias regiões, há uma dependência de uma única região central ('hub') do Azure Cosmos DB para executar todas as resoluções de conflitos, com o protocolo de consenso Paxos aplicado para obter quorum entre réplicas dentro da região central.

  • A plataforma fornece um buffer de mensagens para gerenciar conflitos de gravação dentro da região do hub, a fim de equilibrar a carga e fornecer redundância para falhas transitórias.
    • O buffer é capaz de armazenar alguns minutos de atualizações de gravação que exigem consenso.

A direção estratégica da plataforma Azure Cosmos DB é remover a dependência de uma única região para resolução de conflitos em uma configuração de gravação em múltiplas regiões, utilizando uma abordagem Paxos de duas fases para obter quórum tanto em um nível global quanto dentro de uma região.

• A região de 'hub' primária é determinada pela primeira região na qual o Azure Cosmos DB está configurado.

  • Uma ordenação de prioridade é configurada para regiões adicionais de implantação de satélites para fins de failover.

• O modelo de dados e o particionamento entre partições lógicas e físicas desempenham um papel importante na obtenção do desempenho e da disponibilidade ideais.

• Quando implantado com uma única região de gravação, o Azure Cosmos DB pode ser configurado para failover automático com base em uma prioridade de failover definida, levando em conta todas as réplicas das regiões de leitura.

• A plataforma do Azure Cosmos DB fornece um RTO de aproximadamente 10 a 15 minutos, representando o tempo necessário para executar um failover regional do serviço do Azure Cosmos DB, caso um desastre catastrófico afete a região central.

  • Esse RTO também é relevante em um contexto de gravação em várias regiões, considerando a dependência de uma única região central para a resolução de conflitos.
    • Se a região 'hub' ficar indisponível, as gravações feitas em outras regiões falharão após o preenchimento do buffer de mensagens, pois a resolução de conflitos não poderá ocorrer até que o serviço falhe e uma nova região do hub seja estabelecida.

A direção estratégica da plataforma do Azure Cosmos DB é reduzir o RTO para cerca de 5 minutos, permitindo failovers no nível da partição.

• RPO (Objetivos de Ponto de Recuperação) e RTO (Objetivos de Tempo de Recuperação) são configuráveis por meio de níveis de consistência, com uma compensação entre durabilidade e taxa de transferência de dados.

  • O Azure Cosmos DB fornece um RTO mínimo de 0 para um nível de consistência relaxado com gravações de várias regiões ou um RPO de 0 para consistência forte com a região de gravação única.

• O Azure Cosmos DB oferece um SLA de 99,999% para disponibilidade de leitura e gravação em contas de banco de dados configuradas com várias regiões do Azure como graváveis.

  • O SLA é representado pelo Percentual de Tempo de Atividade Mensal, que é calculado como 100% – Taxa média de erro.
  • A Taxa média de erro é definida como a soma das Taxas de Erro para cada hora no mês de cobrança dividida pelo número total de horas no mês de cobrança, em que a Taxa de Erro é o número total de Solicitações Com Falha divididas pelo Total de Solicitações durante um determinado intervalo de uma hora.

• O Azure Cosmos DB oferece um SLA de 99,99% para taxa de transferência, consistência, disponibilidade e latência para contas de banco de dados com escopo para uma única região do Azure quando configurado com qualquer um dos cinco Níveis de Consistência.

  • Um SLA 99.99% também se aplica a contas de banco de dados que abrangem várias regiões do Azure configuradas com qualquer um dos quatro Níveis de Consistência relaxados.

• Há dois tipos de taxa de transferência que podem ser provisionados no Azure Cosmos DB: padrão e dimensionamento automático, que são medidos usando Unidades de Solicitação por segundo (RU/s).

  • A taxa de transferência padrão aloca os recursos necessários para garantir um valor de RU/s especificado.
    • Standard é cobrado por hora pelo throughput provisionado.
  • O dimensionamento automático define um valor máximo de taxa de transferência e o Azure Cosmos DB aumentará ou reduzirá automaticamente dependendo da carga do aplicativo, entre o valor máximo da taxa de transferência e um mínimo de 10% do valor máximo da taxa de transferência.
    • O Autoscale é cobrado por hora pelo throughput máximo consumido.

• A taxa de transferência provisionada estática com uma carga de trabalho variável pode resultar em erros de limitação, o que afetará a disponibilidade do aplicativo percebida.

  • O dimensionamento automático protege contra erros de limitação de taxa, permitindo que o Azure Cosmos DB escale conforme necessário, enquanto mantém a proteção de custo reduzindo a escala quando a carga diminuir.

• Quando o Azure Cosmos DB é replicado em várias regiões, as RUs (Unidades de Solicitação) provisionadas são cobradas por região.

• Há uma diferença de custo significativa entre uma configuração de gravação em várias regiões e uma configuração de gravação em uma única região que, em muitos casos, pode tornar proibitivo o custo de uma plataforma de dados no Azure Cosmos DB com multi-mestre.

Leitura/Gravação de Região Única	Escrita de Região Única – Leitura de Região Dupla	Leitura e gravação em dupla região
1 RU	2 RU	4 RU

O delta entre gravação de região única e gravação de várias regiões é, na verdade, menor que a razão de 1:2 mostrada na tabela acima. Mais especificamente, há uma taxa de transferência de dados entre regiões associada a atualizações de gravação em uma configuração de gravação única, que não está incluída nos custos de UR como ocorre com a configuração de gravação em várias regiões.

• O armazenamento consumido é cobrado como uma taxa fixa para a quantidade total de armazenamento (GB) consumida para hospedar dados e índices por uma determinada hora.

• Session é o nível de consistência padrão e mais amplamente utilizado, já que os dados são recebidos na mesma ordem que as gravações.

• O Azure Cosmos DB dá suporte à autenticação por meio de uma identidade do Microsoft Entra ou de chaves do Azure Cosmos DB e tokens de recurso, que fornecem capacidades sobrepostas.

• É possível desabilitar operações de gerenciamento de recursos através do uso de chaves ou tokens de recurso, limitando-as apenas a operações de dados, permitindo assim um controle refinado de acesso a recursos por meio do controle de acesso baseado em função (RBAC) do Microsoft Entra.

  • Restringir o acesso ao plano de controle por meio de chaves ou tokens de recurso desabilitará as operações do plano de controle para clientes que usam SDKs do Azure Cosmos DB e, portanto, devem ser avaliados e testados minuciosamente.
  • A disableKeyBasedMetadataWriteAccess configuração pode ser definida por meio de definições de IaC de ARM Template ou por meio de uma Built-In Azure Policy.

• O suporte ao RBAC do Microsoft Entra no Azure Cosmos DB se aplica às operações de gerenciamento de plano de controle de recursos e contas.

  • Os administradores de aplicativos podem criar atribuições de função para usuários, grupos, entidades de serviço ou identidades gerenciadas para conceder ou negar acesso a recursos e operações em recursos do Azure Cosmos DB.
  • Há várias Funções RBAC internas disponíveis para atribuição de função e funções RBAC personalizadas também podem ser usadas para formar combinações de privilégios específicas.
    • O Leitor de Conta do Cosmos DB habilita o acesso somente leitura ao recurso do Azure Cosmos DB.
    • O Colaborador de Conta do DocumentDB habilita o gerenciamento de contas do Azure Cosmos DB, incluindo chaves e atribuições de função, mas não habilita o acesso ao plano de dados.
    • Operador do Cosmos DB, que é semelhante ao Colaborador da Conta do DocumentDB, mas não fornece a capacidade de gerenciar chaves ou atribuições de função.

• Os recursos do Azure Cosmos DB (contas, bancos de dados e contêineres) podem ser protegidos contra modificações ou exclusões incorretas usando bloqueios de recursos.

  • Os bloqueios de recursos podem ser definidos no nível da conta, do banco de dados ou do contêiner.
  • Um bloqueio de recurso definido em um recurso será herdado por todos os recursos filho. Por exemplo, um Bloqueio de Recursos definido na conta do Azure Cosmos DB será herdado por todos os bancos de dados e contêineres dentro da conta.
  • Os Bloqueios de Recursos se aplicam apenas às operações do plano de controle e não impedem operações do plano de dados, como criar, alterar ou excluir dados.
  • Se o acesso ao plano de controle não for restrito com disableKeyBasedMetadataWriteAccess, os clientes poderão executar operações do plano de controle usando chaves de acesso à conta.

• O feed de alterações do Azure Cosmos DB fornece um feed ordenado por tempo de alterações nos dados em um contêiner do Azure Cosmos DB.

  • O feed de alterações inclui apenas operações de inserção e atualização no contêiner do Azure Cosmos DB de origem; ele não inclui exclusões.

• O feed de alterações pode ser usado para manter um armazenamento de dados separado do contêiner primário usado pelo aplicativo, com atualizações contínuas para o armazenamento de dados de destino alimentado pelo feed de alterações do contêiner de origem.

  • O feed de alterações pode ser usado para preencher um repositório secundário para redundância de plataforma de dados adicional ou para cenários analíticos subsequentes.

• Se as operações de exclusão afetarem rotineiramente os dados dentro do Contêiner de origem, o repositório alimentado pelo feed de alterações será impreciso e nãoflectivo dos dados excluídos.

  • Um padrão Soft Delete pode ser implementado para que os registros de dados sejam incluídos no feed de alterações.
    • Em vez de excluir explicitamente registros de dados, os registros de dados são atualizados definindo um sinalizador (por exemplo IsDeleted) para indicar que o item é considerado excluído.
    • Qualquer armazenamento de dados de destino alimentado pelo feed de alterações precisará detectar e processar itens com um sinalizador de exclusão definido como True; em vez de armazenar registros de dados com exclusão lógica, a versão existente do registro de dados no armazenamento de destino precisará ser excluída.
  • Um TTL (Time-To-Live) curto normalmente é usado com o padrão de exclusão suave para que o Azure Cosmos DB exclua automaticamente os dados expirados, mas somente depois que eles são refletidos no feed de alterações com o sinalizador 'excluído' definido como verdadeiro.
    • Realiza a intenção de exclusão original ao mesmo tempo em que propaga a exclusão por meio do feed de alterações.

• O Azure Cosmos DB pode ser configurado como um repositório analítico, que aplica um formato de coluna para consultas analíticas otimizadas para resolver os desafios de complexidade e latência que ocorrem com os pipelines de ETL tradicionais.

• O Azure Cosmos DB faz backup automático de dados em intervalos regulares sem afetar o desempenho ou a disponibilidade e sem consumir RU/s.

• O Azure Cosmos DB pode ser configurado de acordo com dois modos de backup distintos.

  • Periódico é o modo de backup padrão para todas as contas, em que os backups são feitos em um intervalo periódico e os dados são restaurados criando uma solicitação com a equipe de suporte.
    • O período de retenção de backup periódico padrão é de oito horas e o intervalo de backup padrão é de quatro horas, o que significa que apenas os dois últimos backups são armazenados por padrão.
    • O intervalo de backup e o período de retenção são configuráveis dentro da conta.
      • O período de retenção máximo se estende para um mês com um intervalo mínimo de backup de uma hora.
      • Uma atribuição de função para o "Cosmos DB Account Reader Role" do Azure é necessária para configurar a redundância de armazenamento de backup.
    • Duas cópias de backup são incluídas sem custo adicional, mas backups adicionais incorrem em custos adicionais.
    • Por padrão, os backups periódicos são armazenados em Armazenamento Redundante Geograficamente (GRS) separado, que não é diretamente acessível.
      • O armazenamento de backup existe na região primária do 'hub' e é replicado para a região emparelhada por meio da replicação de armazenamento subjacente.
      • A configuração de redundância da conta de armazenamento de backup subjacente é configurável para Armazenamento com Redundância de Zona ou Armazenamento com Redundância Local.
    • Executar uma operação de restauração requer uma Solicitação de Suporte , pois os clientes não podem executar uma restauração diretamente.
      • Antes de abrir um tíquete de suporte, o período de retenção de backup deve ser aumentado para pelo menos sete dias dentro de oito horas após o evento de perda de dados.
    • Uma operação de restauração cria uma nova conta do Azure Cosmos DB em que os dados são recuperados.
      • Uma conta existente do Azure Cosmos DB não pode ser usada para restauração
      • Por padrão, uma nova conta do Azure Cosmos DB nomeada <Azure_Cosmos_account_original_name>-restored<n> será usada.
        • Esse nome pode ser ajustado, como reutilizando o nome existente se a conta original tiver sido excluída.
    • Se a taxa de transferência for provisionada no nível do banco de dados, o backup e a restauração ocorrerão no nível do banco de dados
      • Não é possível selecionar um subconjunto de contêineres para restaurar.
  • O modo de backup contínuo permite uma restauração a qualquer ponto de tempo nos últimos 30 dias.
    • As operações de restauração podem ser executadas para retornar a um PITR (ponto específico no tempo) com uma granularidade de um segundo.
    • A janela disponível para operações de restauração é de até 30 dias.
      • Também é possível restaurar ao estado de instanciação do recurso.
    • Backups contínuos são feitos em todas as regiões do Azure em que a conta do Azure Cosmos DB existe.
      • Os backups contínuos são armazenados na mesma região do Azure que cada réplica do Azure Cosmos DB, usando Armazenamento Localmente Redundante (LRS) ou Armazenamento com Redundância de Zona (ZRS) em regiões que dão suporte a Zonas de Disponibilidade.
    • Uma restauração de autoatendimento pode ser executada usando o portal do Azure ou artefatos IaC, como modelos ARM.
    • Há várias limitações com o Backup Contínuo.
      • O modo de backup contínuo não está disponível atualmente em uma configuração de escrita em várias regiões.
      • Somente o Azure Cosmos DB para NoSQL e o Azure Cosmos DB para MongoDB podem ser configurados para backup contínuo no momento.
      • Se um contêiner tiver TTL configurado, os dados restaurados que excederam sua TTL poderão ser excluídos imediatamente
    • Uma operação de restauração cria uma nova conta do Azure Cosmos DB para a restauração pontual.
    • Há um custo de armazenamento adicional para backups contínuos e operações de restauração.

• As contas existentes do Azure Cosmos DB podem ser migradas de Periódico para Contínuo, mas não de Contínuo para Periódico, pois a migração é unidirecional e não reversível.

• Cada backup do Azure Cosmos DB é composto pelos próprios dados e detalhes de configuração para a taxa de transferência provisionada, as políticas de indexação, as regiões de implantação e as configurações de TTL do contêiner.

  • Os backups não contêm configurações de firewall, listas de controle de acesso de rede virtual, configurações de ponto de extremidade privado, configurações de consistência (uma conta é restaurada com consistência de sessão), procedimentos armazenados, gatilhos, UDFs ou configurações de várias regiões.
    • Os clientes são responsáveis por reimplantar recursos e configurações. Elas não são restauradas por meio do backup do Azure Cosmos DB.
  • Os dados do repositório analítico do Link do Azure Synapse também não estão incluídos nos backups do Azure Cosmos DB.

• É possível implementar uma funcionalidade personalizada de backup e restauração para cenários em que abordagens periódicas e contínuas não são uma boa opção.

  • Uma abordagem personalizada apresenta custos significativos e sobrecarga administrativa adicional, que devem ser compreendidos e avaliados cuidadosamente.
    • Cenários comuns de restauração devem ser modelados, como a corrupção ou exclusão de uma conta, banco de dados, contêiner ou item de dados.
    • Os procedimentos de manutenção devem ser implementados para evitar a proliferação do backup.
  • O Armazenamento do Azure ou uma tecnologia de dados alternativa podem ser usadas, como um contêiner alternativo do Azure Cosmos DB.
    • O Armazenamento do Azure e o Azure Cosmos DB fornecem integrações nativas com serviços do Azure, como o Azure Functions e o Azure Data Factory.

• A documentação do Azure Cosmos DB indica duas opções potenciais para implementar backups personalizados.

  • Feed de alterações do Azure Cosmos DB para gravar dados em uma instalação de armazenamento separada.
    • Uma função do Azure ou um processo de aplicativo equivalente usa o processador de feed de alterações para conectar-se ao feed de alterações e processar itens para o armazenamento.
  • Backups personalizados contínuos ou periódicos (em lote) podem ser implementados usando o feed de alterações.
  • O feed de alterações do Azure Cosmos DB ainda não reflete exclusões, portanto, um padrão de exclusão reversível deve ser aplicado usando uma propriedade booliana e TTL.
    • Esse padrão não será necessário quando o feed de alterações fornecer atualizações de fidelidade total.
  • Conector do Azure Data Factory para Azure Cosmos DB (conectores da API do Azure Cosmos DB para NoSQL ou MongoDB ) para copiar dados.
    • O ADF (Azure Data Factory) dá suporte à execução manual e aos gatilhos de agenda, de janela contínua e baseados em eventos.
      • Fornece suporte para armazenamento e a Event Grid.
    • O ADF é adequado principalmente para implementações de backup personalizadas periódicas devido à sua orquestração orientada em lote.
      • Ele é menos adequado para implementações de backup contínuo com eventos frequentes devido à sobrecarga na execução da orquestração.
    • O ADF dá suporte ao Link Privado do Azure para cenários de alta segurança de rede

O Azure Cosmos DB é usado no design de muitos serviços do Azure, portanto, uma interrupção regional significativa para o Azure Cosmos DB terá um efeito em cascata em vários serviços do Azure nessa região. O impacto preciso em um determinado serviço dependerá muito de como o design do serviço subjacente usa o Azure Cosmos DB.

Recomendações de design

Azure Cosmos DB

• Use o Azure Cosmos DB como a plataforma de dados primária em que os requisitos permitem.

• Para cenários de carga de trabalho críticos, configure o Azure Cosmos DB com uma réplica de gravação dentro de cada região de implantação para reduzir a latência e fornecer redundância máxima.

  • Configure o aplicativo para priorizar o uso da réplica local do Azure Cosmos DB para gravações e leituras para otimizar a carga do aplicativo, o desempenho e o consumo regional de RU/s.
  • A configuração de gravação de várias regiões tem um custo significativo e deve ser priorizada apenas para cenários de carga de trabalho que exigem confiabilidade máxima.

• Para cenários de carga de trabalho menos críticos, priorize o uso da configuração de gravação de região única (ao usar Zonas de Disponibilidade) com réplicas de leitura distribuídas globalmente, pois isso oferece um alto nível de confiabilidade da plataforma de dados (99.999% SLA para SLA de leitura, 99,995% para operações de gravação) em um preço mais atraente.

  • Configure o aplicativo para usar a réplica de leitura local do Azure Cosmos DB para otimizar o desempenho de leitura.

• Selecione uma região de implantação "hub" ideal onde a resolução de conflitos ocorrerá em uma configuração de gravação em várias regiões e todas as gravações serão realizadas em uma configuração de gravação em região única.

  • Considere a distância em relação a outras regiões de implantação e a latência associada na seleção de uma região primária e os recursos necessários, como suporte a Zonas de Disponibilidade.

• Configure o Azure Cosmos DB com redundância de Zona de Disponibilidade (AZ) em todas as regiões de implantação com suporte do AZ, para garantir a resiliência a falhas zonais em uma região.

• Use o Azure Cosmos DB para NoSQL, pois ele oferece o conjunto de recursos mais abrangente, especialmente no que diz respeito ao ajuste de desempenho.

  • APIs alternativas devem ser consideradas principalmente para cenários de migração ou compatibilidade.
    • Ao usar APIs alternativas, valide se os recursos necessários estão disponíveis com o idioma e o SDK selecionados para garantir a configuração e o desempenho ideais.

• Use o modo de conexão direta para otimizar o desempenho da rede através da conectividade TCP direta com os nós de back-end do Azure Cosmos DB, com um número reduzido de saltos de rede.

O SLA do Azure Cosmos DB é calculado com base na média de solicitações com falha, que podem não se alinhar diretamente ao orçamento de erro de uma camada de confiabilidade de 99,999%. Ao projetar para 99.999% SLO, é essencial planejar a indisponibilidade de gravação do Azure Cosmos DB em níveis regionais e multirregionais, garantindo que uma tecnologia de armazenamento reserva esteja posicionada em caso de falha, como uma fila de mensagens persistente para reprodução subsequente.

• Defina uma estratégia de particionamento em partições lógicas e físicas para otimizar a distribuição de dados de acordo com o modelo de dados.

  • Minimize consultas de partição cruzada.
  • Teste e valide iterativamente a estratégia de particionamento para garantir o desempenho ideal.

• Selecione uma chave de partição ideal.

  • A chave de partição não pode ser alterada depois de criada dentro da coleção.
  • A chave de partição deve ser um valor de propriedade que não é alterado.
  • Selecione uma chave de partição que tenha uma cardinalidade alta, com uma ampla gama de valores possíveis.
  • A chave de partição deve distribuir o consumo de RU e o armazenamento de dados de forma uniforme entre todas as partições lógicas, garantindo assim a distribuição equilibrada de consumo de RU e de armazenamento entre as partições físicas.
  • Execute consultas de leitura na coluna particionada para reduzir o consumo de RU e a latência.

• A indexação também é crucial para o desempenho, portanto, verifique se as exclusões de índice são usadas para reduzir as RU/s e os requisitos de armazenamento.

  • Indexe apenas os campos necessários para filtragem em consultas; projete índices para os predicados mais usados.

• Aproveite os recursos internos de manipulação de erros, novas tentativas e maior confiabilidade do SDK do Azure Cosmos DB.

  • Implemente a lógica de repetição dentro do SDK em clientes.

• Use chaves de criptografia gerenciadas pelo serviço para reduzir a complexidade do gerenciamento.

  • Se houver um requisito de segurança específico para chaves gerenciadas pelo cliente, verifique se os procedimentos de gerenciamento de chaves apropriados são aplicados, como backup e rotação.

• Desabilite o acesso de gravação de metadados baseados em chave do Azure Cosmos DB aplicando a Política integrada do Azure.

• Habilite o Azure Monitor para coletar as principais métricas e logs de diagnóstico, como RU/s (taxa de transferência provisionada).

  • Encaminhe dados operacionais do Azure Monitor para um workspace do Log Analytics dedicado ao Azure Cosmos DB e a outros recursos globais dentro da arquitetura do aplicativo.
  • Use as métricas do Azure Monitor para determinar se os padrões de tráfego do aplicativo são adequados para dimensionamento automático.

• Avalie os padrões de tráfego do aplicativo para selecionar uma opção ideal para tipos de taxa de transferência provisionados.

  • Considere o provisionamento automático de taxa de transferência para equilibrar automaticamente a demanda de carga de trabalho.

• Avalie as dicas de desempenho da Microsoft para o Azure Cosmos DB para otimizar a configuração do lado do cliente e do servidor para melhorar a latência e a taxa de transferência.

• Ao usar o AKS como plataforma de computação: para cargas de trabalho com uso intensivo de consulta, selecione um SKU de nó do AKS que tenha o acesso à rede acelerada habilitado para reduzir a latência e as variações de desempenho da CPU.

• Para implantações de região de gravação única, é altamente recomendável configurar o Azure Cosmos DB para failover automático.

• Equilibre a carga através do uso de mensagens não bloqueantes e assíncronas dentro dos fluxos do sistema, que gravam atualizações no Azure Cosmos DB.

  • Considere padrões como segregação de responsabilidade de comando e consulta e fornecimento de eventos.

• Configure a conta do Azure Cosmos DB para backups contínuos para obter uma granularidade fina dos pontos de recuperação nos últimos 30 dias.

  • Considere o uso de backups do Azure Cosmos DB em cenários em que os dados contidos ou a conta do Azure Cosmos DB é excluída ou corrompida.
  • Evite o uso de uma abordagem de backup personalizada, a menos que seja absolutamente necessário.

• É altamente recomendável praticar procedimentos de recuperação em dados e recursos de não produção, como parte da preparação padrão da operação de continuidade dos negócios.

• Defina artefatos IaC para restabelecer as configurações e os recursos de uma restauração de backup do Azure Cosmos DB.

• Avalie e aplique as diretrizes de controle de Linha de Base de Segurança do Azure para Backup e Recuperação do Azure Cosmos DB.

  • BR-1: garantir backups automatizados regulares
  • BR-3: validar todos os backups, incluindo chaves gerenciadas pelo cliente
  • BR-4, Atenuar o risco de chaves perdidas

• Para cargas de trabalho analíticas que exigem disponibilidade de várias regiões, use o Repositório Analítico do Azure Cosmos DB, que aplica um formato de coluna para consultas analíticas otimizadas.

Tecnologias de dados relacionais

Para cenários com um modelo de dados altamente relacional ou dependências em tecnologias relacionais existentes, o uso do Azure Cosmos DB em uma configuração de gravação de várias regiões pode não ser diretamente aplicável. Nesses casos, é vital que as tecnologias relacionais usadas sejam projetadas e configuradas para manter as aspirações ativas-ativas de várias regiões de um design de aplicativo.

O Azure fornece muitas plataformas de dados relacionais gerenciadas, incluindo o Banco de Dados SQL do Azure e o Banco de Dados do Azure para soluções relacionais comuns do OSS, incluindo MySQL, PostgreSQL e MariaDB. As considerações e recomendações de design nesta seção se concentrarão, portanto, no uso ideal dos sabores do Banco de Dados SQL do Azure e do OSS do Banco de Dados do Azure para maximizar a confiabilidade e a disponibilidade global.

Considerações sobre o design

• Embora as tecnologias de dados relacionais possam ser configuradas para dimensionar facilmente as operações de leitura, as gravações normalmente são restritas para passar por uma única instância primária, o que coloca uma restrição significativa na escalabilidade e no desempenho.

• A fragmentação pode ser aplicada para distribuir dados e processamento em vários bancos de dados estruturados idênticos, particionando bancos de dados horizontalmente para navegar em restrições de plataforma.

  • Por exemplo, a fragmentação geralmente é aplicada em plataformas SaaS multi-inquilinos para isolar grupos de inquilinos em estruturas distintas de plataforma de dados.

Banco de Dados SQL do Azure

• O Banco de Dados SQL do Azure fornece um mecanismo de banco de dados totalmente gerenciado que está sempre em execução na versão estável mais recente do mecanismo de banco de dados do SQL Server e no sistema operacional subjacente.

  • Fornece recursos inteligentes, como ajuste de desempenho, monitoramento de ameaças e avaliações de vulnerabilidade.

• O Banco de Dados SQL do Azure fornece alta disponibilidade regional embutida e replicação geográfica pronta para uso para distribuir réplicas de leitura entre regiões do Azure.

  • Com a replicação geográfica, as réplicas de banco de dados secundárias permanecem apenas para leitura até que um failover seja iniciado.
  • Há suporte para até quatro secundários nas mesmas regiões ou regiões diferentes.
  • Réplicas secundárias também podem ser usadas para acesso a consultas de leitura, otimizando o desempenho de leitura.
  • O failover deve ser iniciado manualmente, mas pode ser encapsulado em procedimentos operacionais automatizados.

• O Banco de Dados SQL do Azure fornece Grupos de Failover Automático, que replicam bancos de dados para um servidor secundário e permitem failover transparente se houver uma falha.

  • Os grupos de failover automático dão suporte à replicação geográfica de todos os bancos de dados no grupo para apenas um servidor ou instância secundária em uma região diferente.
  • Atualmente, não há suporte para grupos de failover automático na camada de serviço hiperescala.
  • Bancos de dados secundários podem ser usados para descarregar o tráfego de leitura.

• As réplicas de banco de dados da camada de serviço Premium ou Crítico para Negócios podem ser distribuídas entre Zonas de Disponibilidade sem custo adicional.

  • O anel de controle também é duplicado em várias zonas como três anéis de gateway (GW).
    • O roteamento para um anel de gateway específico é controlado pelo Gerenciador de Tráfego do Azure.
  • Ao usar a camada Crítico para Negócios, a configuração com redundância de zona só estará disponível quando o hardware de computação Gen5 for selecionado.

• O Banco de Dados SQL do Azure oferece um SLA de disponibilidade de 99,99% como linha de base em todas as suas camadas de serviço, mas fornece um SLA maior de 99,995% para as camadas Crítico para o Negócio ou Premium nas regiões que suportam zonas de disponibilidade.

  • As camadas Business Critical ou Premium do Banco de Dados SQL do Azure não configuradas para implantações com redundância de zona têm um SLA de disponibilidade de 99,99%.

• Quando configurada com replicação geográfica, a camada Comercialmente Crítica do Banco de Dados SQL do Azure fornece um RTO (Objetivo de Tempo de Recuperação) de 30 segundos por 100% de horas implantadas.

• Quando configurada com replicação geográfica, a camada Comercialmente Crítica do Banco de Dados SQL do Azure tem um RPO (Objetivo de Ponto de Recuperação) de 5 segundos por 100% de horas implantadas.

• A camada de Hiperescala do Banco de Dados SQL do Azure, quando configurada com pelo menos duas réplicas, tem um SLA de disponibilidade de 99,99%.

• Os custos de computação associados ao Banco de Dados SQL do Azure podem ser reduzidos usando um Desconto de Reserva.

  • Não é possível aplicar capacidade reservada a bancos de dados baseados em DTU.

• A restauração em um ponto no tempo pode ser usada para retornar um banco de dados e os dados a um ponto anterior no tempo.

• A restauração geográfica pode ser usada para recuperar um banco de dados de um backup com redundância geográfica.

Banco de Dados do Azure para PostgreSQL

• O Banco de Dados do Azure para PostgreSQL é oferecido em três opções de implantação diferentes:

  • Servidor único, SLA 99.99%
  • Servidor Flexível, que oferece redundância de Zona de Disponibilidade, SLA 99.99%
  • Hiperescala (Citus), SLA 99.95% quando o modo de Alta Disponibilidade está habilitado.

• A Hiperescala (Citus) fornece escalabilidade dinâmica por meio da fragmentação sem alterações de aplicativo.

  • Distribuir linhas de tabela em vários servidores PostgreSQL é fundamental para garantir consultas escalonáveis na Hiperescala (Citus).
  • Vários nós podem armazenar coletivamente mais dados do que um banco de dados tradicional e, em muitos casos, podem usar CPUs de trabalho em paralelo para otimizar os custos.

• O dimensionamento automático pode ser configurado por meio da automação de processos via Runbook para garantir a elasticidade em resposta à mudança nos padrões de tráfego.

• O servidor flexível fornece eficiências de custo para cargas de trabalho de não produção por meio da capacidade de parar/iniciar o servidor e uma camada de computação intermitível adequada para cargas de trabalho que não exigem capacidade de computação contínua.

• Não há nenhum custo adicional para o armazenamento de backup para até 100% do armazenamento total do servidor provisionado.

  • O consumo adicional do armazenamento de backup é cobrado de acordo com o GB/mês consumido.

• Os custos de computação associados ao Banco de Dados do Azure para PostgreSQL podem ser reduzidos usando um desconto de reserva de servidor único ou desconto de reserva de hiperescala (Citus).

Recomendações de design

• Considere a fragmentação de bancos de dados relacionais em partições com base em diferentes contextos de aplicativos e dados, ajudando a lidar com restrições da plataforma, maximizar a escalabilidade, a disponibilidade e o isolamento de falhas.

  • Essa recomendação é particularmente predominante quando o design do aplicativo considera três ou mais regiões do Azure, pois restrições de tecnologia relacional podem dificultar significativamente as plataformas de dados distribuídas globalmente.
  • A fragmentação não é apropriada para todos os cenários de aplicativo, portanto, uma avaliação contextualizada é necessária.

• Priorize o uso do Banco de Dados SQL do Azure onde existem requisitos relacionais devido à sua maturidade na plataforma do Azure e à ampla gama de recursos de confiabilidade.

Banco de Dados SQL do Azure

• Use a camada de serviço Business-Critical para maximizar a confiabilidade e a disponibilidade, incluindo o acesso a recursos críticos de resiliência.

• Use o modelo de consumo baseado em vCore para facilitar a seleção independente de recursos de computação e armazenamento, adaptados aos requisitos de volume e taxa de transferência da carga de trabalho.

  • Verifique se um modelo de capacidade definido é aplicado para informar os requisitos de recursos de computação e armazenamento.
    • Considere a Capacidade Reservada para fornecer otimizações de custo potenciais.

• Configure o modelo de implantação Zone-Redundant para espalhar réplicas de banco de dados Comercialmente Críticos na mesma região entre zonas de disponibilidade.

• Use a Replicação Geográfica Ativa para implantar réplicas legíveis em todas as regiões de implantação (até quatro).

• Utilize Grupos de Failover Automático para fornecer um failover transparente para uma região secundária, com replicação entre regiões aplicada para fornecer replicação a outras regiões de implantação para otimização de leitura e redundância para bancos de dados.

  • Para cenários de aplicativo limitados a apenas duas regiões de implantação, o uso de Grupos de Failover Automático deve ser priorizado.

• Considere gatilhos operacionais automatizados, com base em alertas alinhados ao modelo de integridade do aplicativo, para realizar automaticamente failovers em instâncias replicadas geograficamente, caso uma falha impacte tanto o primário quanto o secundário no Grupo de Failover Automático.

Importante

Para aplicativos que consideram mais de quatro regiões de implantação, deve-se considerar seriamente a fragmentação no escopo do aplicativo ou refatoração do aplicativo para dar suporte a tecnologias de gravação de várias regiões, como o Azure Cosmos DB. No entanto, se isso não for viável no cenário de carga de trabalho do aplicativo, é recomendável elevar uma região dentro de uma única geografia para um status primário que abrange uma instância replicada geograficamente para acesso de leitura mais uniformemente distribuído.

• Configure o aplicativo para consultar instâncias de réplica em consultas de leitura, otimizando o desempenho de leitura.

• Use o Azure Monitor e o Azure SQL Analytics para obter insights operacionais quase em tempo real no BD SQL do Azure para a detecção de incidentes de confiabilidade.

• Use o Azure Monitor para avaliar o uso de todos os bancos de dados para determinar se eles foram dimensionados adequadamente.

  • Assegure-se de que os pipelines de CD considerem o teste de carga em níveis de carga representativos para validar o comportamento adequado da plataforma de dados.

• Calcule uma métrica de integridade para os componentes de banco de dados observarem a integridade em relação aos requisitos de negócios e à utilização de recursos, usando monitoramento e alertas para conduzir a ação operacional automatizada quando apropriado.

  • Verifique se as principais métricas de desempenho de consulta são incorporadas para que uma ação rápida possa ser tomada quando ocorrer degradação do serviço.

• Otimize consultas, tabelas e bancos de dados usando o Query Performance Insights e recomendações comuns de desempenho fornecidas pela Microsoft.

• Implemente a lógica de repetição usando o SDK para atenuar erros transitórios que afetam a conectividade do Banco de Dados SQL do Azure.

• Priorize o uso de chaves gerenciadas pelo serviço ao aplicar TDE (Transparent Data Encryption) do lado do servidor para criptografia em repouso.

  • Se as chaves gerenciadas pelo cliente ou a criptografia do lado do cliente (AlwaysEncrypted) forem necessárias, verifique se as chaves são adequadamente resilientes com backups e instalações de rotação automatizadas.

• Considere o uso da restauração pontual no tempo como um manual operacional para se recuperar de erros graves de configuração.

Banco de Dados do Azure para PostgreSQL

• O Servidor Flexível é recomendado para usá-lo para cargas de trabalho comercialmente críticas devido ao suporte à Zona de Disponibilidade.

• Ao usar a Hiperescala (Citus) para cargas de trabalho comercialmente críticas, habilite o modo de alta disponibilidade para receber a garantia 99.95% SLA.

• Utilize a configuração de servidor Hiperescala (Citus) para otimizar a disponibilidade em vários nós.

• Defina um modelo de capacidade para o aplicativo informar os requisitos de recursos de computação e armazenamento na plataforma de dados.

  • Considere o Desconto de Reserva de Hiperescala (Citus) para fornecer possíveis otimizações de custo.

Cache para dados da Camada Quente

Uma camada de cache na memória pode ser aplicada para aprimorar uma plataforma de dados aumentando significativamente a taxa de transferência de leitura e melhorando os tempos de resposta do cliente de ponta a ponta para cenários de dados de camada quente.

O Azure fornece vários serviços com funcionalidades aplicáveis para armazenar em cache estruturas de dados principais, com o Azure Cache para Redis posicionado para abstrair e otimizar o acesso de leitura na plataforma de dados. Esta seção se concentrará, portanto, no uso ideal do Cache do Azure para Redis em cenários em que o desempenho de leitura adicional e a durabilidade do acesso a dados são necessários.

Considerações sobre design

• Uma camada de cache fornece durabilidade adicional de acesso a dados, pois mesmo que uma interrupção afete as tecnologias de dados subjacentes, um instantâneo de dados do aplicativo ainda poderá ser acessado por meio da camada de cache.

• Em determinados cenários de carga de trabalho, o cache na memória pode ser implementado dentro da própria plataforma de aplicativo.

Azure Cache para Redis

• O cache Redis é um sistema de armazenamento noSQL de chave-valor na memória de software livre.

• As camadas Enterprise e Enterprise Flash podem ser implantadas em uma configuração ativa-ativa entre zonas de disponibilidade dentro de uma região e regiões diferentes do Azure por meio da replicação geográfica.

  • Quando implantado em pelo menos três regiões do Azure e três ou mais Zonas de Disponibilidade em cada região, com replicação geográfica ativa habilitada para todas as instâncias de Cache, o Cache do Azure para Redis fornece um SLA de 99.999% para conectividade com um ponto de extremidade de cache regional.
  • Quando implantado em três Zonas de Disponibilidade em uma única região do Azure, um SLA de conectividade de% 99,99 é fornecido.

• A camada Enterprise Flash é executada em uma combinação de RAM e armazenamento de memória não volátil flash e, embora isso introduz uma pequena penalidade de desempenho, ela também permite tamanhos de cache muito grandes, até 13 TB com clustering.

• Com a replicação geográfica, os encargos de transferência de dados entre regiões também serão aplicáveis, além dos custos diretos associados às instâncias de cache.

• O recurso Atualizações Agendadas não inclui atualizações ou atualizações do Azure aplicadas ao sistema operacional de VM subjacente.

• Haverá um aumento na utilização da CPU durante uma operação de expansão enquanto os dados são migrados para novas instâncias.

Recomendações de design

• Considere uma camada de cache otimizada para cenários de dados 'quentes' para aumentar a taxa de transferência de leitura e melhorar os tempos de resposta.

• Aplique políticas apropriadas para expiração de cache e limpeza para evitar o crescimento de dados descontrolado.

  • Considere a expiração de itens de cache quando os dados de backup forem alterados.

Azure Cache para Redis

• Use o SKU Premium ou Enterprise para maximizar a confiabilidade e o desempenho.

  • Para cenários com volumes de dados extremamente grandes, a camada Enterprise Flash deve ser considerada.
  • Para cenários em que apenas a replicação geográfica passiva é necessária, a camada Premium também pode ser considerada.

• Implante instâncias de réplica usando replicação geográfica em uma configuração ativa em todas as regiões de implantação consideradas.

• Verifique se as instâncias de réplica são implantadas entre zonas de disponibilidade em cada região considerada do Azure.

• Use o Azure Monitor para avaliar o Cache do Azure para Redis.

  • Calcule uma pontuação de saúde para os componentes de cache regionais, a fim de observar a saúde em relação aos requisitos de negócios e à utilização de recursos.
  • Observe e alerte sobre as principais métricas, como alta CPU, alto uso de memória, alta carga do servidor e chaves removidas para obter insights ao dimensionar o cache.

• Otimize a resiliência da conexão implementando lógica de repetição, tempos limite e usando uma implementação singleton do multiplexer de conexão Redis.

• Configure atualizações agendadas para prescrever os dias e horas em que as atualizações do Redis Server são aplicadas ao cache.

Cenários analíticos

É cada vez mais comum que aplicativos críticos considerem cenários analíticos como um meio de gerar valor adicional de fluxos de dados englobados. Cenários analíticos de aplicativo e operacionais (AIOps) formam, portanto, um aspecto crucial da plataforma de dados altamente confiável.

Cargas de trabalho analíticas e transacionais exigem diferentes funcionalidades e otimizações de plataforma de dados para desempenho aceitável em seus respectivos contextos.

Description	Analítico	Transacional
Caso de Uso	Analisar volumes muito grandes de dados ("Big Data")	Processar volumes muito grandes de transações individuais
Otimizado para	Ler consultas e agregações sobre vários registros	Consultas quase em tempo real de Criação/Leitura/Atualização/Exclusão (CRUD) em um pequeno número de registros
Características principais	– Consolidar de fontes de dados de registro – Armazenamento baseado em coluna – Armazenamento distribuído – Processamento paralelo -Desnormalizada - Leituras e gravações de baixa simultaneidade - Otimizar o volume de armazenamento utilizando compactação	- Fonte de dados de registro para aplicativo – Armazenamento baseado em linha – Armazenamento contíguo – Processamento simétrico -Normalizado - Leituras e gravações de alta simultaneidade, atualizações de índice - Otimizar para acesso rápido a dados com armazenamento na memória

O Azure Synapse fornece uma plataforma analítica empresarial que reúne dados relacionais e não relacionais com tecnologias do Spark, usando a integração interna com serviços do Azure, como o Azure Cosmos DB, para facilitar a análise de Big Data. As considerações e recomendações de design nesta seção se concentrarão, portanto, no uso ideal do Azure Synapse e do Azure Cosmos DB para cenários analíticos.

Considerações sobre design

• Tradicionalmente, cenários analíticos em larga escala são facilitados pela extração de dados em uma plataforma de dados separada otimizada para consultas analíticas subsequentes.
  • Os pipelines de Extração, Transformação e Carga (ETL) são usados para extrair dados, o que consumirá a taxa de transferência e afetará o desempenho da carga de trabalho transacional.
  • Executar pipelines ETL com pouca frequência para reduzir a taxa de transferência e os impactos no desempenho resultará em dados analíticos menos atualizados.
  • O esforço de manutenção e desenvolvimento do pipeline de ETL aumenta à medida que as transformações de dados se tornam mais complexas.
    • Por exemplo, se os dados de origem são frequentemente alterados ou excluídos, os pipelines ETL devem considerar essas alterações nos dados de destino para consultas analíticas por meio de uma abordagem aditiva/com versão, exportação e recarga ou alterações diretas nos dados analíticos. Cada uma dessas abordagens terá impacto derivado, como recriação ou atualização de índice.

Azure Cosmos DB

• As consultas analíticas executadas nos dados transacionais do Azure Cosmos DB normalmente serão agregadas entre partições em grandes volumes de dados, consumindo uma taxa de transferência significativa da RU (Unidade de Solicitação), o que pode afetar o desempenho das cargas de trabalho transacionais ao redor.

• O Repositório Analítico do Azure Cosmos DB fornece um armazenamento de dados orientado a colunas totalmente isolado e esquematizado que permite análise em larga escala em dados do Azure Cosmos DB do Azure Synapse sem impacto nas cargas de trabalho transacionais do Azure Cosmos DB.

  • Quando um contêiner do Azure Cosmos DB é habilitado como um Repositório Analítico, um novo repositório de colunas é criado internamente a partir dos dados operacionais no Contêiner. Esse repositório de colunas é mantido separadamente do repositório de transações orientado a linhas para o contêiner.
  • As operações Criar, Atualizar e Excluir nos dados operacionais são sincronizadas automaticamente com o repositório analítico, portanto, nenhum feed de alterações ou processamento de ETL é necessário.
  • A sincronização de dados da loja operacional para o repositório analítico não consome Unidades de Solicitação (RUs) provisionadas no contêiner ou no banco de dados. Não há nenhum impacto no desempenho em cargas de trabalho transacionais. O Repositório Analítico não requer a alocação de RUs adicionais em um banco de dados ou contêiner do Azure Cosmos DB.
  • A Sincronização Automática é o processo em que as alterações de dados operacionais são sincronizadas automaticamente com o Repositório Analítico. A latência de Sincronização Automática geralmente é menor que dois (2) minutos.
    • A latência de Sincronização Automática pode ser de até cinco (5) minutos para um Banco de Dados com taxa de transferência compartilhada e um grande número de contêineres.
    • Assim que a Sincronização Automática for concluída, os dados mais recentes poderão ser consultados no Azure Synapse.
  • O armazenamento do Repositório Analítico usa um modelo de preço baseado em consumo que cobra pelo volume de dados e pelo número de operações de leitura e gravação. Os preços do repositório analítico são separados dos preços do repositório transacional.

• Usando o Link do Azure Synapse, o Repositório analítico do Azure Cosmos DB pode ser consultado diretamente do Azure Synapse. Isso habilita o HTAP (Processamento Híbrido Transacional-Analítico) sem ETL proveniente do Synapse, para que os dados do Azure Cosmos DB possam ser consultados junto com outras cargas de trabalho analíticas do Synapse quase em tempo real.

• O Repositório Analítico do Azure Cosmos DB não é particionado por padrão.

  • Para determinados cenários de consulta, o desempenho melhorará particionando dados do Repositório Analítico usando chaves que são frequentemente usadas em predicados de consulta.
  • O particionamento é disparado por um trabalho no Azure Synapse que executa um notebook Spark usando o Synapse Link, que carrega os dados do Armazenamento Analítico do Azure Cosmos DB e os grava no armazenamento particionado do Synapse na conta de armazenamento primária do workspace do Synapse.

• Os pools sem servidor do SQL do Azure Synapse Analytics podem consultar o Repositório Analítico por meio de exibições atualizadas automaticamente ou por meio de comandos SELECT / OPENROWSET.

• Os pools do Spark do Azure Synapse Analytics podem consultar o Repositório Analítico por meio de tabelas do Spark atualizadas automaticamente ou do comando spark.read.

• Os dados também podem ser copiados do Repositório Analítico do Azure Cosmos DB para um pool de SQL do Synapse dedicado usando o Spark, para que os recursos provisionados do pool de SQL do Azure Synapse possam ser usados.

• Os dados do Repositório Analítico do Azure Cosmos DB podem ser consultados com o Azure Synapse Spark.

  • Os notebooks Spark permitem que combinações de dataframe do Spark agreguem e transformem dados analíticos do Azure Cosmos DB com outros conjuntos de dados e usem outras funcionalidades avançadas do Spark do Synapse, incluindo a gravação de dados transformados em outros repositórios ou o treinamento de modelos do AIOps Machine Learning.

• O feed de alterações do Azure Cosmos DB também pode ser usado para manter um armazenamento de dados secundário separado para cenários analíticos.

Azure Synapse

• O Azure Synapse reúne recursos de análise, incluindo data warehousing do SQL, Spark Big Data e Data Explorer para análise de logs e séries temporais.

  • O Azure Synapse usa serviços vinculados para definir conexões com outros serviços, como o Armazenamento do Azure.
  • Os dados podem ser ingeridos no Synapse Analytics por meio da atividade de cópia de fontes suportadas. Isso permite a análise de dados no Synapse sem afetar o armazenamento de dados de origem, mas adiciona sobrecarga de tempo, custo e latência devido à transferência de dados.
  • Os dados também podem ser consultados in-loco em repositórios externos com suporte, evitando a sobrecarga de ingestão e movimentação de dados. O Armazenamento do Azure com Data Lake Gen2 é um repositório com suporte para o Synapse, e dados exportados do Log Analytics podem ser consultados por meio do Synapse Spark.

• O Azure Synapse Studio une tarefas de ingestão e consulta.

  • Os dados de origem, incluindo dados do Repositório Analítico do Azure Cosmos DB e dados de Exportação do Log Analytics, são consultados e processados para dar suporte a business intelligence e outros casos de uso analítico agregados.

Recomendações de design

• Verifique se as cargas de trabalho analíticas não afetam cargas de trabalho de aplicativos transacionais para manter o desempenho transacional.

Análise de Aplicativos

• Use o Link do Azure Synapse com o Repositório Analítico do Azure Cosmos DB para executar análises nos dados operacionais do Azure Cosmos DB criando um armazenamento de dados otimizado, o que não afetará o desempenho transacional.

  • Habilite o Link do Azure Synapse em contas do Azure Cosmos DB.
  • Crie um contêiner habilitado para o Repositório Analítico ou habilite um contêiner existente para o Repositório Analítico.
  • Conecte o workspace do Azure Synapse à loja analítica do Azure Cosmos DB para habilitar cargas de trabalho analíticas no Azure Synapse e consultar dados do Azure Cosmos DB. Use uma cadeia de conexão com uma chave somente leitura do Azure Cosmos DB.

• Priorize o Armazenamento Analítico do Azure Cosmos DB com o Azure Synapse Link em vez de usar o feed de alterações do Azure Cosmos DB para manter um repositório de dados analíticos.

  • O feed de alterações do Azure Cosmos DB pode ser adequado para cenários analíticos muito simples.

AIOps e Análise Operacional

• Crie um único workspace do Azure Synapse com serviços vinculados e conjuntos de dados para cada conta de armazenamento do Azure de origem para a qual os dados operacionais dos recursos são enviados.

• Crie uma conta dedicada do Armazenamento do Azure e use-a como a conta de armazenamento primário do workspace para armazenar os dados e os metadados do catálogo do workspace do Synapse. Configure-o com namespace hierárquico para habilitar o Azure Data Lake Gen2.

  • Mantenha a separação entre os dados analíticos de origem e os dados e metadados do workspace do Synapse.
    • Não use uma das contas regionais ou globais do Armazenamento do Azure para onde os dados operacionais são enviados.

Próxima etapa

Revise as considerações sobre o uso de redes.

Rede e conectividade