Considerações sobre a plataforma de dados para cargas de trabalho de missão crítica no Azure

A seleção de uma plataforma de dados de aplicação eficaz é outra á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 em capacidade. 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 gravação de várias regiões terá um impacto crítico na adequação para uma plataforma disponível globalmente.

Esta área de design expande o design de aplicativos, 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 carga de trabalho de missão crítica do Azure Well-Architected. Se você não está familiarizado com esta série, recomendamos que comece com o que é uma carga de trabalho de missão crítica?

Os quatro Vs do Big Data

Os "Quatro Vs do 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 do negócio. Esta seção irá, portanto, explorar 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.

• Volume: a quantidade de dados que está chegando para informar a capacidade de armazenamento e os requisitos de hierarquização - esse é o tamanho do conjunto de dados.
• Velocidade: a velocidade com que os dados são processados, seja em lotes ou fluxos contínuos - que é a taxa de fluxo.
• Variety: a organização e o formato dos dados, capturando formatos estruturados, semi-estruturados e não estruturados - ou seja, dados em vários armazenamentos ou tipos.
• Veracidade: inclui a proveniência e curadoria de conjuntos de dados considerados para governança e garantia de qualidade de dados - ou seja, precisão dos dados.

Considerações de design

Volume

• Volumes de dados existentes (se houver) e futuros 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.
  • Grandes aplicativos críticos para os negócios e de missão crítica 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 à mudança das circunstâncias de negócios ou dos procedimentos de limpeza.

• 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, em caso afirmativo, durante quanto tempo?
  • Quais são os procedimentos de mitigação? e a mitigação exigirá alterações no aplicativo?
  • Haverá risco de perda de dados?

• Recursos como o Time to Live (TTL) 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 registros.

  • Por exemplo, o Azure Cosmos DB fornece um recurso TTL integrado.

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 de acordo com o cenário de carga de trabalho, como aqueles que são de leitura pesada ou gravação pesada.
    • 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 se espera que o rendimento cresça?
  • Quais são os requisitos de latência de dados em P50/P99 sob 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 uma taxa de transferência alta.

  • A otimização da configuração para alta taxa de transferência incorre em compensações, que devem ser totalmente compreendidas.
  • A persistência de nivelamento de carga e os padrões de mensagens, 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 aplicativos, 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 ágil é fundamental para oferecer suporte eficaz a níveis variáveis de taxa de transferência e carga sem provisionamento excessivo de níveis de capacidade.
    • A taxa de transferência de leitura e gravação deve ser dimensionada de acordo com os requisitos e a carga do aplicativo.
    • As operações de escala vertical e horizontal podem ser aplicadas para responder às mudanças 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 da conectividade?
  • As operações individuais devolverão códigos de avaria enquanto o avião de controlo continuar a operar?
  • A plataforma de dados ativará a limitação e, em caso afirmativo, por quanto tempo?

• A recomendação fundamental de design de aplicativo para usar uma distribuição geográfica ativa-ativa introduz desafios em torno da consistência de dados.

  • Há um compromisso 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 atualidade 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 suportar 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, até arquivos mais estruturados, como CSV e Parquet.

  • As cargas de trabalho de aplicativos compostos normalmente terão conjuntos de dados distintos e requisitos associados.

• Além das plataformas de dados relacionais ou não relacionais, as plataformas de dados gráficos 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, onde os itens de dados são semanticamente semelhantes e/ou armazenados e consultados juntos, mas diferem estruturalmente.

• Em uma arquitetura de microsserviços, os serviços de aplicativos individuais podem ser criados com armazenamentos de dados distintos otimizados para cenários, 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.
    • As 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 as 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 para alinhamento otimizado com o modelo de dados e tipos de dados englobados influenciarão fortemente as decisões da plataforma de dados.

  • Camadas de consulta, como procedimentos armazenados e mapeadores objeto-relacionais.
  • Capacidade de consulta com neutralidade de idioma, como uma camada de API REST segura.
  • Recursos de continuidade de negócios, como backup e restauração.

• Os armazenamentos de dados analíticos normalmente suportam armazenamento poliglota para vários tipos de estruturas de dados.

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

• Num contexto empresarial, a utilização de processos e ferramentas existentes, bem como a continuidade das competências, podem ter uma influência significativa na conceção 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 dentro de um aplicativo, e o gerenciamento desses fatores pode ter uma influência significativa no design da plataforma de dados.

  • Consistência dos dados.
  • Recursos de segurança da plataforma.
  • Governança de dados.
  • Gestão da mudança e evolução do esquema.
  • Dependências entre conjuntos de dados.

• Em qualquer aplicativo distribuído com várias réplicas de dados, há um compromisso entre consistência e latência, conforme expresso nos teoremas CAP e PACELAC .

  • Quando leitores e gravadores são distribuídos distintamente, 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 (atualização) recém-concluída desse item de dados em outra réplica, ou a versão mais atualizada 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 na solicitação de dados individuais.
  • Qual é a experiência do usuário se os dados forem servidos a partir de uma réplica mais próxima do usuário que não reflita o estado mais recente de uma réplica diferente? ou seja, o aplicativo pode oferecer suporte a fornecer 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 padronizadas de resolução de conflitos, 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 criptografia do lado do cliente e/ou na camada de dados usando 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 por serviço, chaves gerenciadas pelo cliente no Cofre da Chave ou chaves gerenciadas pelo cliente em hardware controlado pelo cliente.

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

• A criptografia de link de dados 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 encriptados e desencriptados nos dispositivos antes de serem enviados, evitando ataques físicos "man-in-the-middle" ou espionagem/escutas telefónicas.

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

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

• Observabilidade através da monitorização do estado da plataforma e do acesso aos dados.

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

Recomendações de design

Volume

• Garantir que os volumes de dados futuros associados ao crescimento orgânico não excedam os recursos da plataforma de dados.

  • Preveja taxas de crescimento de dados alinhadas aos planos de negócios e use as taxas estabelecidas para informar os requisitos de capacidade contínuos.
  • Compare os volumes de registros agregados e por dados com os limites da plataforma de dados.
  • Se houver o risco de os limites serem atingidos em circunstâncias excecionais, certifique-se de que as mitigações operacionais estejam 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 limites de escala e taxas de crescimento de dados esperadas.

  • Garanta que as operações de dimensionamento estejam 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, certifique-se de que essas operações sejam realizadas fora do horário comercial crítico, se possível.

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

  • Considere classificar os conjuntos de dados em níveis 'quente', 'quente' e 'frio' ('arquivo').
    • Por exemplo, as implementações de referência fundamentais usam o Azure Cosmos DB para armazenar dados 'quentes' que são usados ativamente pelo aplicativo, enquanto o Armazenamento do Azure é usado para dados de operações 'frias' para fins analíticos.

• Configure procedimentos de limpeza para otimizar o crescimento de dados e impulsionar a eficiência dos dados, como o desempenho de consultas e o gerenciamento de expansão de dados.

  • Configure a expiração 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 hierarquizados com segurança para armazenamento secundário ou excluídos, sem um impacto adverso para o aplicativo.
  • Descarregue dados não críticos para o armazenamento refrigerado secundário, mas mantenha-os para obter valor analítico e satisfazer os requisitos de auditoria.
  • Colete estatísticas de uso e telemetria da plataforma de dados para permitir que as equipes de DevOps avaliem continuamente os requisitos de limpeza e os armazenamentos de dados de "tamanho certo".

• Em linha com um projeto 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 onde o volume de dados da expansão pode ser difícil de gerenciar.

Velocidade

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

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

• Nível de carga através do uso de mensagens assíncronas sem bloqueio, por exemplo, usando os padrões CQRS ou Event Sourcing .

  • Pode haver latência entre as 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.

• Garanta escalabilidade ágil para suportar níveis variáveis de taxa de transferência e carga.

  • Se os níveis de carga forem altamente voláteis, considere o provisionamento excessivo 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 de aplicativos compostos quando a taxa de transferência não puder ser mantida.

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

  • Configure o dimensionamento automático com base nos limites internos do serviço e do conjunto de aplicativos.
  • O dimensionamento deve ser iniciado e concluído em prazos consistentes com os requisitos de negócios.
  • Para cenários em que a interação manual é necessária, estabeleça «playbooks» operacionais automatizados que possam ser acionados 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.

• A taxa de transferência excedente deve ser tratada normalmente pela plataforma de dados ou camada de aplicativo e capturada 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 doméstica para evitar o crescimento descontrolado de dados.
    • Expiram os itens de cache quando os dados de backup são alterados.
    • Se a expiração do cache for estritamente baseada em TTL (Time-To-Live), o impacto e a experiência do cliente de fornecer dados desatualizados precisam ser compreendidos.

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 em plataforma da Microsoft.

• Em alinhamento com o princípio de design de aplicativos de arquiteturas de microsserviços de acoplamento flexível, 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 de carga de trabalho específicos.
  • Evite criar uma dependência em um único armazenamento de dados monolítico.
    • Considere o padrão de design SAGA onde existem dependências entre armazenamentos de dados.

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

  • Garanta o suporte para os idiomas necessários e os recursos do SDK. Nem todos os recursos estão disponíveis para todos os idiomas/SDK da mesma maneira.

Veracidade

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

  • Distribua réplicas de dados entre zonas de disponibilidade (AZs) dentro de uma região (ou use camadas de serviço redundantes de zona) para maximizar a disponibilidade dentro da região.

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

  • Considere os requisitos de negócios para resolução de conflitos quando o mesmo item de dados é alterado em duas réplicas de gravação separadas antes que qualquer alteração possa ser replicada e, assim, criar um conflito.
    • Use políticas padronizadas de resolução de conflitos, como "Last one wins" sempre que possível
      • Se uma estratégia personalizada com lógica personalizada for necessária, certifique-se de que as práticas de DevOps de CI/CD sejam 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 de testes de caos em processos de entrega contínua.

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

  • Garanta que os processos de entrega contínua considerem o teste de carga em relação a benchmarks de desempenho conhecidos.

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

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

Nota

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 do aplicativo de acordo com um modelo de capacidade provavelmente será necessário, potencialmente por meio do fornecimento de unidades de escala adicionais. Essa abordagem acabará sendo restringida 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, o DBaaS de TI Central) introduz gargalos operacionais que prejudicam significativamente a agilidade por meio de uma experiência de gerenciamento amplamente descontextualizada 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 Azure Data Store
• 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 multi-região 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 distribuída em várias regiões, onde 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

Nem todos os microsserviços podem exigir um armazenamento de dados de gravação distribuído em 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 em várias regiões e consistência ajustável pronta para uso. Portanto, as considerações e recomendações de design nesta seção se concentrarão no uso ideal do Azure Cosmos DB.

Considerações de design

BD do Cosmos para o Azure

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

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

  • O Azure Cosmos DB para NoSQL de primeira parte fornece o conjunto de recursos mais avançado e normalmente é a API onde novos recursos serão disponibilizados primeiro.

• O Azure Cosmos DB suporta os modos de conectividade Gateway e Direct, em que o Direct facilita a conectividade através de TCP para back-end de nós de réplica do Azure Cosmos DB para melhorar o desempenho com menos saltos de rede, enquanto o Gateway fornece conectividade HTTPS para nós de gateway frontend.

  • O modo direto só está disponível ao usar o Azure Cosmos DB para NoSQL e, atualmente, só é suportado nas plataformas .NET e Java SDK.

• 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 dentro de 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árias AZs para proteger contra falhas zonais.

  • O protocolo de consenso Paxos é aplicado para alcançar quórum em réplicas dentro de 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 de várias regiões.
    • Com gravações de região única, uma região 'hub' primária é usada para atender todas as gravações e, se essa região 'hub' ficar indisponível, uma operação de failover deve ocorrer para promover outra região como gravável.
    • Com gravações em 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, conflitos de atualização (inserir, substituir, excluir) podem ocorrer quando 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.

  • Last Write Wins (LWW) 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 conflito torna-se o vencedor, e se vários itens tiverem o mesmo valor numérico, o sistema seleciona um vencedor para que todas as regiões possam convergir para a mesma versão do item comprometido.
    • 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 personalizadas permitem semântica definida pelo aplicativo para reconciliar conflitos usando um procedimento armazenado de mesclagem registrado que é invocado automaticamente quando conflitos são detetados.
    • O sistema fornece exatamente uma garantia única para a execução de um procedimento de fusão como parte do protocolo de compromisso.
    • Uma política de resolução de conflitos personalizada 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 em 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 atingir quórum entre réplicas dentro da região do hub.

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

A direção estratégica da plataforma 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 2 fases para atingir quórum em nível global e dentro de uma região.

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

  • Uma ordem de prioridade é configurada para regiões adicionais de implantação de satélite 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 de desempenho e 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 ~10 a 15 minutos, capturando o tempo decorrido para executar um failover regional do serviço Azure Cosmos DB se um desastre catastrófico afetar a região do hub.

  • Este RTO também é relevante em um contexto de escrita multirregião, dada a dependência de uma única região "hub" para a resolução de conflitos.
    • Se a região 'hub' ficar indisponível, as gravações feitas em outras regiões falharão depois que o buffer de mensagens for preenchido, pois a resolução de conflitos não poderá ocorrer até que o serviço faça failover e uma nova região de 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.

• Os RPO (Recovery Point Objetives, objetivos de ponto de recuperação) e os RTO (Recovery Time Objetives, 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 dos 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 forte consistência com 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 pela Porcentagem de Tempo de Atividade Mensal, que é calculada como 100% - Taxa de Erro Média.
  • A Taxa de Erro Média é definida como a soma das Taxas de Erro para cada hora no mês de faturação dividida pelo número total de horas no mês de faturação, em que a Taxa de Erro é o número total de Pedidos Falhados dividido pelo Total de Pedidos 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 abrangendo 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.
    • O padrão é 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 de taxa de transferência e um mínimo de 10% do valor máximo de 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 aumente a escala conforme necessário, mantendo a proteção de custos reduzindo a escala quando a carga diminui.

• Quando o Azure Cosmos DB é replicado em várias regiões, as Unidades de Solicitação (RUs) 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 uma configuração de gravação de região única que, em muitos casos, pode tornar proibitivo o custo de uma plataforma de dados do Azure Cosmos DB com vários mestres.

Leitura/gravação de região única	Gravação de região única - Leitura de região dupla	Leitura/gravação de duas regiões
1 RU	2 RU	4 RU

O delta entre single-region-write e multi-region-write é, na verdade, menor do que a proporção 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, uma vez 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 chaves e tokens de recursos do Azure Cosmos DB, que fornecem recursos sobrepostos.

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

  • Restringir o acesso ao plano de controle por meio de chaves ou tokens de recursos desabilitará as operações do plano de controle para clientes que usam SDKs do Azure Cosmos DB e, portanto, deve ser cuidadosamente avaliado e testado.
  • A disableKeyBasedMetadataWriteAccess definição pode ser definida através de definições de IAC de Modelo ARM ou através de uma Política do Azure Incorporada.

• O suporte do Microsoft Entra RBAC no Azure Cosmos DB aplica-se a operações de gerenciamento de plano de controle de conta e recursos.

  • 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 Cosmos DB Account Reader permite acesso somente leitura ao recurso do Azure Cosmos DB.
    • O Colaborador da Conta do Banco de Dados de Documentos permite 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 de Conta do Banco de Dados de Documentos, 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 Recursos 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 aplicam-se apenas às operações do plano de controlo e não impedem as operações do plano de dados, tais como criar, alterar ou eliminar dados.
  • Se o acesso ao plano de controle não for restrito com disableKeyBasedMetadataWriteAccesso , os clientes poderão executar operações do plano de controle usando chaves de conta.

• O feed de alterações do Azure Cosmos DB fornece um feed ordenado por tempo de alterações em 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 armazenamento 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 armazenamento alimentado pelo feed de alterações será impreciso e não refletirá os 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 os registros de dados, os registros de dados são atualizados definindo um sinalizador (por exemplo) IsDeletedpara indicar que o item é considerado excluído.
    • Qualquer armazenamento de dados de destino alimentado pelo feed de alterações precisará detetar e processar itens com um sinalizador excluído definido como True; Em vez de armazenar registros de dados excluídos por software, 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 soft-delete para que o Azure Cosmos DB exclua automaticamente os dados expirados, mas somente depois que eles forem refletidos no feed de alterações com o sinalizador excluído definido como True.
    • Realiza a intenção de exclusão original enquanto também propaga a exclusão através 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 abordar os desafios de complexidade e latência que ocorrem com os pipelines ETL tradicionais.

• O Azure Cosmos DB faz backup automático dos 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, onde 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 dentro da conta.
      • O período máximo de retenção estende-se a um mês com um intervalo mínimo de backup de uma hora.
      • Uma atribuição de função à "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 estão incluídas sem custo extra, mas backups adicionais incorrem em custos adicionais.
    • Por padrão, os backups periódicos são armazenados em GRS (Geo-Redundant Storage, armazenamento com redundância geográfica) separado que não é diretamente acessível.
      • O armazenamento de backup existe na região "hub" principal 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.
    • A execução de uma operação de restauração requer uma solicitação de suporte , pois os clientes não podem executar diretamente uma restauração.
      • 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 onde 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, por exemplo, 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 do tempo nos últimos 30 dias.
    • As operações de restauração podem ser executadas para retornar a um point-in-time específico (PITR) 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 de recursos.
    • Os backups contínuos são feitos em todas as regiões do Azure onde 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 com Redundância Local) ou o ZRS (Armazenamento com Redundância de Zona) em regiões que oferecem suporte a Zonas de Disponibilidade.
    • Uma restauração de autoatendimento pode ser executada usando o portal do Azure ou artefatos de 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 gravação de 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 o 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 point-in-time.
    • Há um custo adicional de armazenamento para backups contínuos e operações de restauração.

• As contas existentes do Azure Cosmos DB podem ser migradas de Periódica para Contínua, 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ão(õ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 à 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 pela reimplantação de recursos e definições de configuração. Eles não são restaurados por meio do backup do Azure Cosmos DB.
  • Os dados do repositório analítico do Azure Synapse Link também não estão incluídos nos backups do Azure Cosmos DB.

• É possível implementar um recurso de backup e restauração personalizado para cenários em que as abordagens Periódica e Contínua não são uma boa opção.

  • Uma abordagem personalizada introduz custos significativos e despesas administrativas adicionais, que devem ser compreendidos e cuidadosamente avaliados.
    • 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.
    • Procedimentos de limpeza devem ser implementados para evitar a expansão do backup.
  • O Armazenamento do Azure ou uma tecnologia de dados alternativa pode ser usada, 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.

  • O 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 vincular ao feed de alterações e processar itens no armazenamento.
  • Os 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 suave deve ser aplicado usando uma propriedade booleana 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 Connector para Azure Cosmos DB (Azure Cosmos DB para conectores de API NoSQL ou MongoDB) para copiar dados.
    • O Azure Data Factory (ADF) dá suporte à execução manual e aos gatilhos baseados em Agendamento, Janela de Tombamento e Eventos.
      • Fornece suporte para armazenamento e grade de eventos.
    • O ADF é adequado principalmente para implementações periódicas de backup personalizadas devido à sua orquestração orientada a lotes.
      • É menos adequado para implementações de backup contínuo com eventos frequentes devido à sobrecarga de execução de orquestração.
    • O ADF dá suporte ao Azure Private Link 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 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

BD do Cosmos para o Azure

• Use o Azure Cosmos DB como a plataforma de dados principal onde os requisitos permitem.

• Para cenários de carga de trabalho de missão crítica, 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 em 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 de 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 leitura, SLA de 99,995% para operações de gravação) a 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 de 'hub' ideal onde 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, além dos recursos necessários, como o 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 AZ, para garantir resiliência a falhas zonais dentro de 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 por meio da conectividade TCP direta para back-end de nós do Azure Cosmos DB, com um número reduzido de 'saltos' de rede.

O SLA do Azure Cosmos DB é calculado pela média de solicitações com falha, que podem não estar alinhadas diretamente com um orçamento de erro de camada de confiabilidade de 99,999%. Ao projetar para SLO de 99,999%, é vital planejar a indisponibilidade de gravação do Azure Cosmos DB regional e multirregional, garantindo que uma tecnologia de armazenamento de fallback seja 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.

  • Minimizar as 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 seja 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 uniformemente em todas as partições lógicas para garantir o consumo de RU uniforme e a distribuição de armazenamento entre partições físicas.
  • Execute consultas de leitura na coluna particionada para reduzir o consumo e a latência de RU.

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

  • Indexe apenas os campos necessários para filtrar as consultas; índices de design para os predicados mais utilizados.

• Aproveite os recursos internos de tratamento de erros, novas tentativas e confiabilidade mais ampla do SDK do Azure Cosmos DB.

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

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

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

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

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

  • Encaminhe os dados operacionais do Azure Monitor para um espaço de trabalho do Log Analytics dedicado ao Azure Cosmos DB e 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 provisionada.

  • Considere o dimensionamento automático da taxa de transferência provisionada 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 consultas, selecione um SKU de nó AKS que tenha a rede acelerada habilitada para reduzir a latência e o nervosismo 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 através do uso de mensagens assíncronas sem bloqueio dentro dos fluxos do sistema, que gravam atualizações no Azure Cosmos DB.

  • Considere padrões como Comando e Consulta, Responsabilidade, Segregação 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 recursos e dados que não sejam de produção, como parte da preparação padrão da operação de continuidade de negócios.

• Defina artefatos de IaC para restabelecer definições de configuração e 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 o Backup e Recuperação do Azure Cosmos DB.

  • BR-1: Garanta backups automatizados regulares
  • BR-3: Valide todos os backups, incluindo chaves gerenciadas pelo cliente
  • BR-4, Mitigar risco de perda de chaves

• Para cargas de trabalho analíticas que exigem disponibilidade em 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 de 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 geridas, incluindo a Base de Dados SQL do Azure e a Base de Dados do Azure para soluções relacionais OSS comuns, incluindo MySQL, PostgreSQL e MariaDB. Portanto, as considerações e recomendações de design nesta seção se concentrarão 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 de design

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

• O compartilhamento pode ser aplicado para distribuir dados e processamento em vários bancos de dados estruturados idênticos, particionando bancos de dados horizontalmente para navegar pelas restrições da plataforma.

  • Por exemplo, a fragmentação é frequentemente aplicada em plataformas SaaS multilocatárias para isolar grupos de locatários em construções de plataforma de dados distintas.

Base 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 do 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 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ário permanecem somente leitura até que um failover seja iniciado.
  • Até quatro secundários são suportados na mesma região ou em regiões diferentes.
  • As 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.

• 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 em caso de falha.

  • Os grupos de failover automático oferecem suporte à replicação geográfica de todos os bancos de dados do grupo para apenas um servidor secundário ou instância em uma região diferente.
  • Atualmente, não há suporte para grupos de failover automático na camada de serviço Hyperscale.
  • Os 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 Business Critical podem ser distribuídas entre zonas de disponibilidade sem custo extra.

  • 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ítica de Negócios, a configuração redundante de zona só está disponível quando o hardware de computação Gen5 é selecionado.

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

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

• Quando configurada com replicação geográfica, a camada Crítica de Negócios do Banco de Dados SQL do Azure fornece um RTO (Recovery Time Objetive, objetivo de tempo de recuperação) de 30 segundos para 100% das horas implantadas.

• Quando configurada com replicação geográfica, a camada Crítica de Negócios do Banco de Dados SQL do Azure tem um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) de 5 segundos para 100% das 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 para bancos de dados baseados em DTU.

• A restauração point-in-time pode ser usada para retornar um banco de dados e dados contidos para um point-in-time anterior.

• 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%
  • Hyperscale (Citus), SLA de 99,95% quando o modo de Alta Disponibilidade está ativado.

• O Hyperscale (Citus) fornece escalabilidade dinâmica por meio de fragmentação sem alterações no aplicativo.

  • Distribuir linhas de tabela em vários servidores PostgreSQL é fundamental para garantir consultas escaláveis em Hyperscale (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 custos.

• O dimensionamento automático pode ser configurado através da automação do runbook para garantir a elasticidade em resposta às mudanças nos padrões de tráfego.

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

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

  • O consumo adicional de 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 um Desconto de Reserva de Hiperescala (Citus).

Recomendações de design

• Considere fragmentar para particionar bancos de dados relacionais com base em diferentes contextos de aplicativos e dados, ajudando a navegar pelas 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, uma vez que as restrições de tecnologia relacional podem prejudicar significativamente as plataformas de dados distribuídas globalmente.
  • O compartilhamento não é apropriado para todos os cenários de aplicativos, 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 Azure e à ampla variedade de recursos de confiabilidade.

Base de Dados SQL do Azure

• Use a camada de serviço crítica para os negócios 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 de carga de trabalho e taxa de transferência.

  • Garantir que um modelo de capacidade definido seja aplicado para informar os requisitos de recursos de computação e armazenamento.
    • Considere a capacidade reservada para fornecer otimizações de custos potenciais.

• Configure o modelo de implantação com redundância de zona para espalhar réplicas de banco de dados críticas para os negócios 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 para regiões de implantação adicionais para otimização de leitura e redundância de banco de dados.

  • Para cenários de aplicativos 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 conduzir failovers para instâncias replicadas geograficamente se uma falha afetar o primário e o secundário dentro do 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 do escopo do aplicativo ou a 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, é aconselhável elevar uma região dentro de uma única geografia a um status primário que abranja 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 para otimizar o desempenho de leitura.

• Use o Azure Monitor e o Azure SQL Analytics para obter informações operacionais quase em tempo real no Banco de Dados SQL do Azure para a deteçã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.

  • Certifique-se de que os pipelines de CD considerem o teste de carga sob níveis de carga representativos para validar o comportamento apropriado da plataforma de dados.

• Calcule uma métrica de integridade para componentes de banco de dados para observar a integridade relativa aos requisitos de negócios e à utilização de recursos, usando monitoramento e alertas para impulsionar ações operacionais automatizadas, quando apropriado.

  • Certifique-se de que as principais métricas de desempenho da consulta sejam 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 mitigar erros transitórios que afetam a conectividade do Banco de Dados SQL do Azure.

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

  • Se chaves gerenciadas pelo cliente ou criptografia do lado do cliente (AlwaysEncrypted) forem necessárias, certifique-se de que as chaves sejam adequadamente resilientes com backups e recursos de rotação automatizados.

• Considere o uso da restauração point-in-time como um manual operacional para se recuperar de erros graves de configuração.

Banco de Dados do Azure para PostgreSQL

• Recomenda-se que o Servidor Flexível seja usado para cargas de trabalho críticas para os negócios devido ao seu suporte à Zona de Disponibilidade.

• Ao usar o Hyperscale (Citus) para cargas de trabalho críticas para os negócios, habilite o modo de Alta Disponibilidade para receber a garantia de SLA de 99,95%.

• Use a configuração do servidor Hyperscale (Citus) para maximizar a disponibilidade em vários nós.

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

  • Considere o desconto de reserva de hiperescala (Citus) para fornecer possíveis otimizações de custos.

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 importantes, com o Cache do Azure para Redis posicionado para abstrair e otimizar o acesso de leitura da plataforma de dados. Portanto, esta seção se concentrará no uso ideal do Cache Redis do Azure em cenários onde o desempenho de leitura adicional e a durabilidade do acesso a dados são necessários.

Considerações de 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 de aplicativo ainda pode 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 do aplicativo.

Cache do Azure para Redis

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

• 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 em 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 a replicação geográfica ativa habilitada para todas as instâncias de Cache, o Cache Redis do Azure 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 flash não volátil e, embora isso introduza uma pequena penalidade de desempenho, também permite tamanhos de cache muito grandes, de até 13 TB com clustering.

• Com a replicação geográfica, as cobranças pela 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 do Azure ou atualizações 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 e limpeza de cache para evitar o crescimento descontrolado de dados.

  • Considere expirar itens de cache quando os dados de backup forem alterados.

Cache do Azure 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.

• Certifique-se de que as instâncias de réplica sejam implantadas em Zonas de Disponibilidade dentro de cada região do Azure considerada.

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

  • Calcule uma pontuação de integridade para componentes de cache regionais para observar 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 informações sobre 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 as atualizações agendadas para prescrever os dias e horários em que as atualizações do Servidor Redis são aplicadas ao cache.

Cenários analíticos

É cada vez mais comum que aplicativos de missão crítica considerem cenários analíticos como um meio de gerar valor adicional a partir de fluxos de dados englobados. Os cenários analíticos de aplicação e operacionais (AIOps) formam, portanto, um aspeto crucial da plataforma de dados altamente confiável.

Cargas de trabalho analíticas e transacionais exigem diferentes recursos e otimizações da plataforma de dados para um desempenho aceitável dentro de seus respetivos contextos.

Description	Analítico	Transacional
Caso de Utilização	Analise grandes volumes de dados ("big data")	Processar grandes volumes de transações individuais
Otimizado para	Ler consultas e agregações em muitos registros	Consultas Create/Read/Update/Delete (CRUD) quase em tempo real em poucos registros
Características principais	- Consolidar a partir de fontes de dados de registro - Armazenamento baseado em colunas - Armazenamento distribuído - Processamento paralelo - Desnormalizado - Baixa simultaneidade lê e escreve - Otimizar para volume de armazenamento com compressão	- Fonte de dados de registo para aplicação - Armazenamento baseado em linha - Armazenagem contígua - Processamento simétrico - Normalizado - Leituras e gravações de alta simultaneidade, atualizações de índice - Otimize 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 Spark, utilizando a integração incorporada com serviços do Azure, como o Azure Cosmos DB, para facilitar a análise de big data. Portanto, as considerações e recomendações de design nesta seção se concentrarão no uso ideal do Azure Synapse e do Azure Cosmos DB para cenários analíticos.

Considerações de design

• Tradicionalmente, cenários analíticos de grande 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, consomem taxa de transferência e afetam o desempenho da carga de trabalho transacional.
  • A execução de pipelines de ETL com pouca frequência para reduzir a taxa de transferência e os impactos no desempenho resultará em dados analíticos menos atualizados.
  • A sobrecarga de desenvolvimento e manutenção do 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/versionada, despejo e recarga ou alterações in-loco nos dados analíticos. Cada uma dessas abordagens terá impacto derivado, como a recriação ou atualização do índice.

BD do Cosmos para o Azure

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

• O Repositório Analítico do Azure Cosmos DB fornece um armazenamento de dados esquematizado, totalmente isolado, orientado a colunas, que permite análises em larga escala nos 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 armazenamento de coluna é mantido separadamente do repositório de transações orientado a linha 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 armazenamento operacional para o analítico não consome unidades de solicitação (RUs) de taxa de transferência provisionadas no contêiner ou no banco de dados. Não há impacto no desempenho de 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 da Sincronização Automática é geralmente inferior a 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 a partir do Azure Synapse.
  • O armazenamento do Analytical Store usa um modelo de preços baseado no consumo que cobra pelo volume de dados e pelo número de operações de leitura e gravação. O preço analítico da loja é separado do preço da loja transacional.

• Usando o Azure Synapse Link, o Repositório Analítico do Azure Cosmos DB pode ser consultado diretamente do Azure Synapse. Isso habilita o Processamento Transacional-Analítico Híbrido (HTAP) sem ETL do Synapse, para que os dados do Azure Cosmos DB possam ser consultados juntamente 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 os dados do Repositório Analítico usando chaves que são usadas com freqüência em predicados de consulta.
  • O particionamento é acionado por um trabalho no Azure Synapse que executa um bloco de anotações do Spark usando o Synapse Link, que carrega os dados do Repositório Analítico do Azure Cosmos DB e os grava no repositório particionado Synapse na conta de armazenamento principal do espaço de trabalho Synapse.

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

• Os pools do Azure Synapse Analytics 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 SQL Synapse dedicado usando o Spark, para que os recursos provisionados do pool 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 blocos de anotações do Spark permitem combinações de dataframe do Spark para agregar e transformar dados analíticos do Azure Cosmos DB com outros conjuntos de dados e usar outras funcionalidades avançadas do Synapse Spark, incluindo a gravação de dados transformados em outros armazenamentos ou o treinamento de modelos 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 armazenamento de dados SQL, big data do Spark e Data Explorer para análises de log 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 tempo, custo e latência devido à transferência de dados.
  • Os dados também podem ser consultados in-loco em armazenamentos externos suportados, evitando a sobrecarga de ingestão e movimentação de dados. O Armazenamento do Azure com Data Lake Gen2 é um armazenamento suportado para Synapse e os dados exportados do Log Analytics podem ser consultados através 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íticos agregados.

Recomendações de design

• Garanta que as cargas de trabalho analíticas não afetem as cargas de trabalho de aplicativos transacionais para manter o desempenho transacional.

Análise de aplicativos

• Use o 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, que não afetará o desempenho transacional.

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

• Priorize o Repositório 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 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 espaço de trabalho do Azure Synapse com serviços vinculados e conjuntos de dados para cada conta de Armazenamento do Azure de origem para onde os dados operacionais dos recursos são enviados.

• Crie uma conta de Armazenamento do Azure dedicada e use-a como a conta de armazenamento principal do espaço de trabalho para armazenar os dados e metadados do catálogo do espaço de trabalho 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 espaço de trabalho Synapse.
    • Não use uma das contas regionais ou globais do Armazenamento do Azure para onde os dados operacionais são enviados.

Próximo passo

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

Rede e conectividade