Considerações sobre a 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. Em última análise, o Azure oferece uma infinidade de plataformas de dados relacionais, não relacionais e analíticas, que diferem muito na capacidade. Portanto, é essencial que os principais requisitos não funcionais sejam totalmente considerados junto com outros fatores de decisão, como consistência, operabilidade, custo e complexidade. Por exemplo, a capacidade de operar em uma configuração de gravação de várias regiões terá uma influência crítica sobre a adequação para uma plataforma disponível globalmente.

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

Importante

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

Os Quatro Vs de Big Data

Os "Quatro Vs de Big Data" fornecem uma estrutura para entender melhor as características necessárias para uma plataforma de dados altamente disponível 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 Veracidade podem ser aplicadas em um nível conceitual para ajudar a projetar uma plataforma de dados usando tecnologias de dados apropriadas.

• Olume V: quantos dados estão chegando para informar a capacidade de armazenamento e os requisitos de camadas , que é o tamanho do conjunto de dados.
• Elocity V: a velocidade com que os dados são processados, seja como lotes ou fluxos contínuos , que é a taxa de fluxo.
• Ariety V: a organização e o formato de dados, capturando formatos estruturados, semiestruturados e não estruturados , que são dados em vários repositórios ou tipos.
• Eracity V: inclui a procedência e a curadoria de conjuntos de dados considerados para governança e garantia de qualidade de dados , que é a precisão dos dados.

Considerações de criação

Volume

• Volumes de dados futuros existentes (se houver) e esperados com base nas taxas de crescimento de dados previstas alinhadas aos 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.
  • Normalmente, os aplicativos comercialmente críticos e críticos geram e armazenam grandes volumes (GB e TB) diariamente.
  • Pode haver implicações de custo significativas associadas à expansão de dados.

• O volume de dados poderá flutuar devido à mudança das circunstâncias comerciais ou dos 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 TTL (vida útil) podem ser usados para gerenciar o crescimento dos dados excluindo registros automaticamente após um tempo decorrido, por meio da criação ou da modificação do registro.

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

Velocidade

• 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 será diferente por cenário de carga de trabalho, como aqueles que têm uso intenso de leitura ou gravação.
    • Por exemplo, as cargas de trabalho analíticas normalmente precisarão atender a uma grande taxa de transferência de leitura.
  • Qual é a taxa de transferência necessária? E como a taxa de transferência deve crescer?
  • Quais são os requisitos de latência de dados em P50/P99 nos 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.

  • A otimização da configuração para alta taxa de transferência gera compensações, que devem ser totalmente compreendidas.
  • Os padrões de persistência e mensagens de nivelamento de carga, como CQRS e Fornecimento de Eventos, podem ser usados para otimizar ainda mais a taxa de transferência.

• Os níveis de carga naturalmente flutuarão para muitos cenários de aplicativo, com picos naturais que exigem 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 efetivo aos níveis de taxa de transferência e de carga variáveis sem os níveis de capacidade de superprovisionamento.
    • A taxa de transferência de leitura e gravação precisa ser escalada de acordo com os requisitos e a carga do aplicativo.
    • As operações de escala vertical e horizontal podem ser aplicadas em resposta à alteração nos 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 painel de controle continuar operando?
  • A plataforma de dados ativará a limitação e, em caso afirmativo, por quanto tempo?

• A recomendação de design de aplicativo fundamental 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 dos 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 resolução de conflitos quando necessário, e isso pode afetar os níveis de desempenho e a escalabilidade.

• Réplicas somente leitura (dentro e entre regiões) podem ser usadas para minimizar a latência de ida e volta e distribuir o tráfego para aumentar 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 sobre a plataforma de dados.

  • O aplicativo requer um modelo de dados relacional ou pode dar suporte a um modelo de dados de esquema variável ou não relacional?
  • Como o aplicativo consultará os 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 de aplicativos compostos terão conjuntos de dados distintos e requisitos associados.

• Além das 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 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 colocalizaçã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 linguagens, 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.

  • Camadas de consulta, como procedimentos armazenados e mapeados relacionais de objeto.
  • Funcionalidade de consulta neutra em linguagem, como uma camada de API REST protegida.
  • Recursos de continuidade dos 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 precisam 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 concluída (atualização) desse item de dados em outro réplica ou a versão mais atualizada do item de dados, o 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 fornecidos de um réplica mais próximo do usuário, o que não reflete o estado mais recente de um réplica diferente? Ou seja, o aplicativo pode dar suporte a dados possivelmente 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 de 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 em Key Vault ou chaves gerenciadas pelo cliente em hardware controlado pelo cliente.

  • Com a criptografia do lado do cliente, as chaves podem ser gerenciadas em 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 "man-in-the-middle" ou de espionagem/escuta telefônica.

• Autenticação e autorização para o plano de dados e o painel 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 os alertas serão aplicados 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.

  • Preveja as taxas de crescimento de dados alinhadas aos planos de negócios e use as taxas estabelecidas para informar os requisitos contínuos de capacidade.
  • Compare os volumes de registro agregado e por 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 tempo de inatividade e 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 enquanto a replicação ocorre. 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 'quente', 'quente' e 'frio' ('archive').
    • Por exemplo, as implementações de referência básica usam o Azure Cosmos DB para armazenar dados 'frequentes' usados ativamente pelo aplicativo, enquanto o Armazenamento do Azure é usado para dados de operações 'frios' para fins analíticos.

• Configure procedimentos de limpeza para otimizar o crescimento de dados e gerar eficiências de dados, como o desempenho da consulta e o gerenciamento da expansão de dados.

  • Configure a expiração de TTL (Vida Útil) 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 imediatamente, sem um impacto adverso no aplicativo.
  • Descarregue dados não críticos para o armazenamento frio secundário, mas mantenha-os para valor analítico e para atender aos requisitos de auditoria.
  • Colete estatísticas de uso e telemetria da plataforma de dados para permitir que as equipes do DevOps avaliem continuamente os requisitos de limpeza e os armazenamentos de dados de "tamanho certo".

• 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 só armazenamento de dados monolítico em que o volume de dados da expansão possa ser difícil de ser gerenciado.

Velocidade

• 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ários.

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

• Nível de carga 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 aos níveis de taxa de transferência e carga variáveis.

  • Se os níveis de carga forem altamente voláteis, considere o excesso de níveis de capacidade de provisionamento 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 da carga.

  • Configure o dimensionamento automático com base nos limites internos do serviço e do conjunto de aplicativos.
  • O dimensionamento deve iniciar e concluir em quadros de tempo consistentes com os requisitos de negócios.
  • Para os cenários em que a interação manual é necessária, estabeleça 'guias estratégicos' operacionais automatizados que possam ser disparados em vez de realizar ações operacionais manuais.
    • Considere se os gatilhos automatizados podem ser aplicados como parte de investimentos subsequentes em 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 normalmente pela plataforma de dados ou camada de aplicativo e capturado pelo modelo de integridade para representação operacional.

• Implemente o cache para cenários de dados "quentes" para minimizar os tempos de resposta.

  • Aplique políticas apropriadas para expiração de cache e manutenção de casas para evitar o crescimento de dados descontrolado.
    • Expire itens de cache quando os dados de backup forem alterados.
    • Se a expiração do cache for estritamente baseada em TTL (Vida Útil), o impacto e a experiência do cliente de fornecer dados desatualizados precisarão ser compreendidos.

Variedade

• Em alinhamento com o princípio de um design nativo de 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 investimentos futuros da plataforma da Microsoft.

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

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

• Valide se as funcionalidades necessárias estão disponíveis para as tecnologias de dados selecionadas.

  • Verifique o suporte para os idiomas necessários e os recursos do SDK. Nem todos os recursos 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 as 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 Zonas de Disponibilidade (AZs) 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 isso, use um design de plataforma de dados de gravação de várias regiões para maximizar a disponibilidade global e a confiabilidade.

  • Considere os requisitos de negócios para resolução de conflitos quando o mesmo item de dados for alterado em duas réplicas de gravação separadas antes que qualquer alteração possa ser replicada e, portanto, criar um conflito.
    • Usar políticas de resolução de conflitos padronizadas, 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 DEvOps de CI/CD serão aplicadas para gerenciar a lógica personalizada.

• Teste e valide os recursos de backup e restauração e as operações de failover por meio do teste de caos nos processos de entrega contínua.

• 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 aos parâmetros de comparação de desempenho conhecidos.

• Durante a aplicação da criptografia, é altamente recomendável usar chaves de criptografia gerenciadas pelo serviço como uma forma de reduzir a complexidade do gerenciamento.

  • Se houver um requisito de segurança específico para as 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 para o provisionamento e a 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á restrita, 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 de TI Central) introduz gargalos operacionais que dificultam significativamente a agilidade por meio de uma experiência de gerenciamento em grande parte descontextualizada e devem ser evitados em um contexto crítico ou comercialmente crítico.

Referências adicionais

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

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

Armazenamento de dados de gravação de várias regiões distribuído globalmente

Para acomodar totalmente as aspirações ativas-ativas distribuídas globalmente de um design de aplicativo, é altamente recomendável considerar uma plataforma de dados de gravação de várias regiões distribuída, em que as alterações em réplicas graváveis separadas são sincronizadas e mescladas 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 gravações de várias regiões e consistência ajustável pronta para uso. 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 transacionais rápidas e gravações 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 for NoSQL de primeira parte fornece o conjunto de recursos mais avançado e normalmente é a API em que novos recursos ficarão disponíveis primeiro.

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

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

• Dentro das regiões habilitadas para Zona de Disponibilidade, o Azure Cosmos DB oferece suporte à redundância de 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 atenuar 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 gravação.

• Em uma configuração de gravação de várias regiões, os conflitos de atualização (inserir, substituir, excluir) podem ocorrer em que os gravadores atualizam simultaneamente o mesmo item em várias 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 de sincronização de tempo usando uma propriedade de carimbo de data/hora _ts definida pelo sistema como o caminho de 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.
    • O Last Writer Wins é o modo de resolução de conflitos padrão.
    • Ao usar o Azure Cosmos DB for 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 personalizadas permitem que a semântica definida pelo aplicativo reconcilie conflitos usando um procedimento armazenado de mesclagem registrado que é invocado automaticamente quando conflitos são detectados.
    • O sistema fornece exatamente uma garantia para a execução de um procedimento de mesclagem como parte do protocolo de confirmação.
    • Uma política de resolução de conflitos personalizada só está disponível com o Azure Cosmos DB for 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 "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 na região do hub.

  • A plataforma fornece um buffer de mensagens para conflitos de gravação na região do hub para carregar o nível 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 do Azure Cosmos DB é remover essa dependência de região única para resolução de conflitos em uma configuração de gravação de várias regiões, utilizando uma abordagem paxos de duas fases para obter quorum em um nível global e dentro de uma região.

• A região principal do "hub" é determinada pela primeira região na qual o Azure Cosmos DB está configurado.

  • Uma ordenação de prioridade é configurada para regiões de implantação satélite adicionais 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 considerando todas as réplicas de região de leitura.

• O RTO fornecido pela plataforma Azure Cosmos DB é de aproximadamente 10 a 15 minutos, capturando o tempo decorrido para executar um failover regional do serviço do Azure Cosmos DB se um desastre catastrófico afetar a região do hub.

  • Esse RTO também é relevante em um contexto de gravação de várias regiões, dada a dependência em uma única região de "hub" para 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 Azure Cosmos DB é reduzir o RTO para ~5 minutos, permitindo failovers no nível de 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 para 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 Erros é 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 de 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, no dimensionamento padrão e no dimensionamento automático, que são medidos usando RU/s (Unidades de Solicitação por segundo).

  • A taxa de transferência padrão aloca recursos necessários para garantir um valor de RU/s especificado.
    • Standard é cobrado por hora pela taxa de transferência provisionada.
  • 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 dimensionamento automático é cobrado por hora pela taxa de transferência máxima consumida.

• 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 percebida do aplicativo.

  • O dimensionamento automático protege contra erros de limitação, permitindo que o Azure Cosmos DB seja escalado verticalmente conforme necessário, mantendo a proteção de custo reduzindo verticalmente 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á um delta de custo significativo entre uma configuração de gravação de várias regiões e de gravação de região única que, em muitos casos, pode tornar proibitivo um custo de plataforma de dados do Azure Cosmos DB de várias master.

Leitura/gravação de região única	Gravação de região única – leitura de região dupla	Leitura/gravação de região dupla
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 taxa de 1:2 refletida 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 é capturada dentro dos custos de RU como na configuração de gravação de 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, pois 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 Microsoft Entra ou chaves e tokens de recurso do Azure Cosmos DB, que fornecem recursos sobrepostos.

• É possível desabilitar operações de gerenciamento de recursos usando chaves ou tokens de recurso para limitar chaves e tokens de recurso apenas a operações de dados, permitindo um controle de acesso de recursos refinado usando Microsoft Entra RBAC (controle de acesso baseado em função).

  • Restringir o acesso do painel de controle por meio de chaves ou tokens de recurso desabilitará as operações do painel de controle para clientes que usam SDKs do Azure Cosmos DB e, portanto, devem ser avaliados e testados detalhadamente.
  • A disableKeyBasedMetadataWriteAccess configuração pode ser configurada por meio de definições de IaC de Modelo do ARM ou por meio de uma Azure Policy Interna.

• Microsoft Entra suporte a RBAC no Azure Cosmos DB se aplica a 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 permite o acesso somente leitura ao recurso do Azure Cosmos DB.
    • O Colaborador da 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.
    • O Operador 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ção ou exclusão 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 em um recurso será herdado por todos os recursos filho. Por exemplo, um conjunto de Bloqueio de Recursos na conta do Azure Cosmos DB será herdado por todos os bancos de dados e contêineres dentro da conta.
  • Os Bloqueios de Recursos só se aplicam às operações do painel de controle e não impedem operações do plano de dados, como criar, alterar ou excluir dados.
  • Se o acesso ao painel de controle não for restrito com disableKeyBasedMetadataWriteAccess, os clientes poderão executar operações do painel de controle usando chaves de 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 para o contêiner de origem do Azure Cosmos DB; 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ão refletivo de dados excluídos.

  • Um padrão de Exclusão Reversível 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 excluído definido como True; em vez de armazenar registros de dados excluídos de forma reversível, a versão existente do registro de dados no repositório de destino precisará ser excluída.
  • Um curto TTL (Vida Útil) normalmente é usado com o padrão de exclusão reversível 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 True.
    • 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 backups mais recentes são armazenados por padrão.
    • O intervalo de backup e o período de retenção são configuráveis na conta.
      • O período máximo de retenção se estende para um mês com um intervalo mínimo de backup de uma hora.
      • Uma atribuição de função para a "Função de Leitor de Conta do Cosmos DB" 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 GRS (Armazenamento de Geo-Redundant) separados que não está diretamente acessível.
      • O armazenamento de backup existe na região principal 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 Locally-Redundant.
    • 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 chamada <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 para qualquer ponto de tempo nos últimos 30 dias.
    • As operações de restauração podem ser executadas para retornar a um pitr (ponto no tempo) específico 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 para o estado de instanciação do recurso.
    • Os 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 o LRS (Armazenamento Locally-Redundant) ou o ZRS (Armazenamento Com Redundância de Zona) em regiões que dão suporte a Zonas de Disponibilidade.
    • Uma restauração de autoatendimento pode ser executada usando os artefatos portal do Azure ou IaC, como modelos do ARM.
    • Há várias limitações com o Backup Contínuo.
      • No momento, o modo de backup contínuo não está disponível em uma configuração de gravação de várias regiões.
      • Somente o Azure Cosmos DB for NoSQL e o Azure Cosmos DB for MongoDB podem ser configurados para backup contínuo no momento.
      • Se um contêiner tiver TTL configurado, os dados restaurados que excederam seu 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 do Periódico para o Contínuo, mas não de Contínua para Periódica; 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 taxa de transferência provisionada, políticas de indexação, regiões de implantação e configurações de TTL de 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. Eles não são restaurados por meio do backup do Azure Cosmos DB.
  • Azure Synapse Vincular dados do repositório analítico também não está incluído nos backups do Azure Cosmos DB.

• É possível implementar um recurso personalizado de backup e restauração para cenários em que abordagens periódicas e contínuas não são adequadas.

  • Uma abordagem personalizada introduz custos significativos e sobrecarga administrativa adicional, que devem ser compreendidos e avaliados cuidadosamente.
    • Cenários comuns de restauração devem ser modelados, como corrupção ou exclusão de uma conta, banco de dados, contêiner, no item de dados.
    • Os procedimentos de limpeza devem ser implementados para evitar a expansã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 Azure Functions e 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 associar ao feed de alterações e processar itens no 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 as 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.
  • Azure Data Factory Conector do Azure Cosmos DB (conectores de API do Azure Cosmos DB para NoSQL ou MongoDB) para copiar dados.
    • Azure Data Factory (ADF) dá suporte à execução manual e a agenda, janela em cascata e gatilhos baseados em evento.
      • Fornece suporte para Armazenamento e Grade de Eventos.
    • O ADF é principalmente adequado para implementações periódicas de backup personalizado devido à orquestração orientada a lote.
      • Ele é menos adequado para implementações de backup contínuo com eventos frequentes devido à sobrecarga de execução de orquestração.
    • O ADF dá suporte a 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 de 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 do Azure Cosmos DB local réplica 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 (SLA de 99,999% para SLA de leitura, 99,995% para operações de gravação) em um preço mais atraente.

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

• Selecione uma região de implantação "hub" ideal em que a resolução de conflitos ocorrerá em uma configuração de gravação de várias regiões e todas as gravações serão executadas em uma configuração de gravação de 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 as funcionalidades necessárias, como Zonas de Disponibilidade suporte.

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

• Use o Azure Cosmos DB for 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 por meio da conectividade TCP direta para 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 uma média de solicitações com falha, que podem não estar diretamente alinhadas com um orçamento de erro da camada de confiabilidade de 99,999%. Ao projetar para o SLO de 99,999%, portanto, é vital planejar a indisponibilidade de gravação do Azure Cosmos DB regional e de várias regiões, garantindo que uma tecnologia de armazenamento de fallback seja posicionada se uma 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.

  • Minimizar consultas entre partições.
  • 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 ter sido 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 espalhar o consumo de RU e o armazenamento de dados uniformemente em todas as partições lógicas para garantir até mesmo o consumo de RU e a distribuição de armazenamento entre 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 os requisitos de RU/s e armazenamento.

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

• Aproveite as funcionalidades internas de manipulação de erros, repetição e confiabilidade mais amplas do SDK do Azure Cosmos DB.

  • Implemente a lógica de repetição no SDK nos 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 o Azure Policy interno.

• 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 do design 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 a taxa de transferência provisionada de dimensionamento automático para nivelar 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 lado 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 a rede acelerada habilitada para reduzir a latência e a tremulação da CPU.

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

• Nível de carga por meio do uso de mensagens assíncronas que não bloqueiam os 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 são excluídos ou corrompidos.
  • 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 de 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 da 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, Reduzir o risco de perda de chaves

• 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, é essencial que as tecnologias relacionais usadas sejam projetadas e configuradas para manter as aspirações ativa-ativa 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 tipos banco de dados SQL do Azure e 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 por restrições de plataforma.

  • Por exemplo, a fragmentação geralmente é aplicada em plataformas de SaaS multilocatário para isolar grupos de locatários em constructos distintos da 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 última versão estável do mecanismo de banco de dados do SQL Server e do sistema operacional subjacente.

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

• SQL do Azure Banco de Dados fornece alta disponibilidade regional interna e replicação geográfica turnkey 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 somente leitura até que um failover seja iniciado.
  • Há suporte para até quatro secundários nas mesmas regiões ou em regiões diferentes.
  • Réplicas secundárias também podem ser usadas para acesso de consulta somente leitura para otimizar o desempenho de leitura.
  • O failover deve ser iniciado manualmente, mas pode ser encapsulado em procedimentos operacionais automatizados.

• SQL do Azure Banco de Dados 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 secundário ou uma instância 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 Comercialmente Crítico 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 GW (anéis de gateway).
    • O roteamento para um anel de gateway específico é controlado pelo Gerenciador de Tráfego do Azure.
  • Ao usar o nível Comercialmente Crítico, a configuração com redundância de zona só estará disponível quando o hardware de computação Gen5 for selecionado.

• SQL do Azure Banco de Dados oferece um SLA de disponibilidade de 99,99% de linha de base em todas as suas camadas de serviço, mas fornece um SLA de 99,995% mais alto para as camadas Comercialmente Crítico ou Premium em regiões que dão suporte a zonas de disponibilidade.

  • SQL do Azure camadas de banco de dados Comercialmente Crítico ou Premium 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ítico do Banco de Dados SQL do Azure fornece um RTO (Objetivo de Tempo de Recuperação) de 30 segundos para 100% das horas implantadas.

• Quando configurada com replicação geográfica, a camada Comercialmente Crítico do Banco de Dados SQL do Azure tem um RPO (objetivo de ponto de recuperação) de 5 segundos para 100% das horas implantadas.

• SQL do Azure camada de Hiperescala de Banco de Dados, 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 a capacidade reservada para bancos de dados baseados em DTU.

• A restauração pontual pode ser usada para retornar um banco de dados e dados contidos para 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 de 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 runbook para garantir a elasticidade em resposta à alteração dos 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 a 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 para particionar os bancos de dados relacionais com base em diferentes contextos de dados e aplicativos, ajudando a superar as restrições da plataforma, maximizar a escalabilidade e a disponibilidade e o isolamento de falhas.

  • Essa recomendação é particularmente prevalente 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 e, portanto, uma avaliação contextualizada é necessária.

• Priorize o uso do Banco de Dados SQL do Azure quando houver requisitos relacionais devido à maturidade na plataforma Azure e uma ampla gama de funcionalidades de confiabilidade.

Banco de Dados SQL do Azure

• Use a camada de serviço Comercialmente crítico para maximizar a confiabilidade e a disponibilidade, incluindo o acesso a funcionalidades críticas 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ítico dentro da mesma região em 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).

• Use Grupos de Failover Automático para fornecer failover transparente para uma região secundária, com replicação geográfica aplicada para fornecer replicação a regiões de implantação adicionais para otimização de leitura e redundância de banco de dados.

  • Para os 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 failovers em instâncias replicadas geograficamente se uma falha afetar o primário e o secundário no Grupo de Failover Automático.

Importante

Para aplicativos que consideram mais de quatro regiões de implantação, uma consideração séria deve ser dada à 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 uma status primária que abrange uma instância replicada geograficamente para acesso de leitura distribuído de forma mais uniforme.

• Configure o aplicativo para consultar instâncias de réplica para consultas de leitura a fim de otimizar o desempenho de leitura.

• Use o Azure Monitor e o SQL do Azure 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 escalados de acordo.

  • Verifique se os pipelines de CD consideram o teste de carga em níveis de carga representativos para validar o comportamento apropriado da plataforma de dados.

• Calcule uma métrica de integridade para que os componentes de banco de dados observem a integridade em relação aos requisitos de negócios e à utilização de recursos, usando monitoramento e alertas para impulsionar 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 SQL do Azure conectividade do banco de dados.

• Priorize o uso de chaves gerenciadas pelo serviço ao aplicar a 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 automatizada.

• Considere o uso da restauração pontual como um guia estratégico operacional para se recuperar de erros graves de configuração.

Banco de Dados do Azure para PostgreSQL

• É recomendável usar o Servidor Flexível 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 de SLA de 99,95%.

• Use a configuração do servidor hiperescala (Citus) para maximizar 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 otimizações de custo potenciais.

Cache para dados de 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 recursos aplicáveis para armazenar em cache estruturas de dados de chave, com Cache do Azure para Redis posicionados para abstrair e otimizar o acesso de leitura da plataforma de dados. Portanto, esta seção se concentrará no uso ideal de Cache do Azure para Redis em cenários em que o desempenho de leitura adicional e a durabilidade de acesso a dados são necessários.

Considerações de criação

• 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.

Cache Redis do Azure

• O cache Redis é um sistema de armazenamento de chave-valor na memória código aberto NoSQL.

• As camadas Enterprise e Enterprise Flash podem ser implantadas em uma configuração ativa-ativa em Zonas de Disponibilidade dentro de uma região e diferentes regiões 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, 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 Agendado 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 aprimorar os tempos de resposta.

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

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

Cache Redis do Azure

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

  • Para os cenários com volumes de dados extremamente grandes, a camada Enterprise Flash deve ser considerada.
  • Para os 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 a replicação geográfica em uma configuração ativa em todas as regiões de implantação consideradas.

• Verifique se réplica instâncias são implantadas em Zonas de Disponibilidade dentro de cada região considerada do Azure.

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

  • Calcule uma pontuação de integridade para componentes de cache regionais observarem a integridade 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 quando 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 multiplexador 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. Os cenários analíticos de AIOps (aplicativo e operacional) 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.

Descrição	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 em vários registros	Consultas CRUD (Criação/Leitura/Atualização/Exclusão) quase em tempo real em poucos registros
Principais características	– 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 para o volume de armazenamento com compactação	- Fonte de dados de registro para o 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

Azure Synapse fornece uma plataforma analítica empresarial que reúne dados relacionais e não relacionais com tecnologias 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, portanto, se concentrarão no Azure Synapse ideal e no uso do Azure Cosmos DB para cenários analíticos.

Considerações de criação

• Tradicionalmente, os 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 posteriores.
  • Os pipelines etl (extração, transformação e carregamento) são usados para extrair dados que consumirão a taxa de transferência e afetarão o desempenho da carga de trabalho transacional.
  • Executar pipelines de ETL com pouca frequência para reduzir os impactos na taxa de transferência e no desempenho resultará em dados analíticos menos atualizados.
  • A sobrecarga de manutenção e desenvolvimento de pipeline de ETL aumenta à medida que as transformações de dados se tornam mais complexas.
    • Por exemplo, se os dados de origem forem frequentemente alterados ou excluídos, os pipelines de ETL deverão considerar essas alterações nos dados de destino para consultas analíticas por meio de uma abordagem aditiva/com controle de versão, despejo e recarregamento ou alterações in-loco nos dados analíticos. Cada uma dessas abordagens terá impacto derivado, como recriação ou atualização de índice.

Azure Cosmos DB

• Consultas analíticas executadas em 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 esquematizado e totalmente isolado que permite a análise em larga escala em dados do Azure Cosmos DB de 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 com base nos 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 do repositório operacional para o repositório analítico não consome RUs (Unidades de Solicitação de Taxa de Transferência) 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 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ços 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 Azure Synapse Link, o Repositório Analítico do Azure Cosmos DB pode ser consultado diretamente do Azure Synapse. Isso habilita o HTAP (Processamento de Transactional-Analytical Híbrido) sem ETL 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 usadas com frequência em predicados de consulta.
  • O particionamento é disparado por um trabalho no Azure Synapse que executa um notebook Spark usando Link do Synapse, que carrega os dados do Repositório Analítico do Azure Cosmos DB e os grava no repositório particionado do Synapse na conta de armazenamento principal do workspace do Synapse.

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

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

• 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 Azure Synapse pool de SQL possam ser usados.

• Os dados do Repositório Analítico do Azure Cosmos DB podem ser consultados com 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.

Repositório de do Repositório de

• 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

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

  • 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 de atividade Copy de fontes com suporte. 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 o Data Lake Gen2 é um repositório com suporte para o Synapse e os dados exportados do Log Analytics podem ser consultados por meio do Synapse Spark.

• 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 as cargas de trabalho de aplicativos transacionais para manter o desempenho transacional.

Análise de Aplicativos

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

  • Habilite Azure Synapse Link 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 Azure Synapse ao Repositório Analítico do Azure Cosmos DB para habilitar cargas de trabalho analíticas em Azure Synapse para consultar dados do Azure Cosmos DB. Use um cadeia de conexão com uma chave somente leitura do Azure Cosmos DB.

• Priorize o Repositório Analítico do Azure Cosmos DB com Azure Synapse Link em vez de usar o feed de alterações do Azure Cosmos DB para manter um armazenamento 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 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 metadados e os dados do catálogo do workspace do Synapse. Configure-o com o namespace hierárquico para habilitar o Azure Data Lake Gen2.

  • Mantenha a separação entre os dados analíticos de origem e os metadados e os dados 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

Examine as considerações para considerações de rede.

Rede e conectividade