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

A seleção de uma plataforma de dados de aplicação eficaz é uma área de decisão crucial adicional, que tem implicações de longo alcance noutras áreas de design. Em última análise, o Azure oferece uma multiplicidade de plataformas de dados relacionais, não relacionais e analíticas, que diferem muito na capacidade. Por conseguinte, é 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 numa configuração de escrita de várias regiões terá uma influência crítica na adequação de uma plataforma globalmente disponível.

Esta área de design expande-se na conceção de aplicações, fornecendo considerações e recomendações fundamentais 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 para a missão do Azure Well-Architected . Se não estiver familiarizado com esta série, recomendamos que comece com o que é uma carga de trabalho crítica para a missão?

Os Quatro Vs de Macrodados

Os "Quatro Vs de Macrodados" fornecem uma arquitetura para compreender melhor as características necessárias para uma plataforma de dados de elevada disponibilidade e como os dados podem ser utilizados para maximizar o valor empresarial. Desta forma, esta secção explorará a forma como as características de Volume, Velocidade, Variedade e Veracidade podem ser aplicadas a um nível conceptual para ajudar a conceber uma plataforma de dados com tecnologias de dados adequadas.

• Volume: a quantidade de dados que está a chegar para informar a capacidade de armazenamento e os requisitos de camadas , que é o tamanho do conjunto de dados.
• Elocidade V: a velocidade a que os dados são processados, quer como lotes, quer como fluxos contínuos, que é a taxa de fluxo.
• Propriedade V: a organização e o formato dos dados, capturando formatos estruturados, semiestruturados e não estruturados , que são dados em vários arquivos ou tipos.
• Eracidade V: inclui a proveniência e a cura de conjuntos de dados considerados para governação e garantia de qualidade de dados – que é a precisão dos dados.

Considerações sobre Design

Volume

• Volumes de dados futuros existentes (se existirem) e esperados com base nas taxas de crescimento de dados previstas alinhadas com os objetivos e planos empresariais.

  • O volume de dados deve abranger os próprios dados e índices, registos, telemetria e outros conjuntos de dados aplicáveis.
  • As grandes aplicações críticas para a empresa e críticas para a missão normalmente geram e armazenam volumes elevados (GB e TB) diariamente.
  • Podem existir implicações significativas nos custos associados à expansão de dados.

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

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

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

  • Resultará em tempo de inatividade? e se sim, por quanto tempo?
  • Quais são os procedimentos de mitigação? e a mitigação requer alterações à aplicação?
  • Existirá um risco de perda de dados?

• Funcionalidades como o Time to Live (TTL) podem ser utilizados para gerir o crescimento de dados ao eliminar automaticamente os registos após um tempo decorrido, utilizando a criação ou modificação de registos.

  • Por exemplo, o Azure Cosmos DB fornece uma capacidade TTL incorporada.

Velocidade

• A rapidez com que os dados são emitidos a partir de vários componentes da aplicação e os requisitos de débito para a rapidez com que os dados têm de ser consolidados e obtidos são fundamentais para determinar uma tecnologia de dados ideal para cenários de carga de trabalho principais.

  • A natureza dos requisitos de débito será diferente por cenário de carga de trabalho, como os que são pesados de leitura ou de escrita.
    • Por exemplo, normalmente, as cargas de trabalho analíticas terão de atender a um débito de leitura grande.
  • Qual é o débito necessário? E como se espera que o débito cresça?
  • Quais são os requisitos de latência de dados em P50/P99 em níveis de carga de referência?

• As capacidades como suportar uma estrutura sem bloqueio, otimização de índices e políticas de consistência são fundamentais para alcançar um débito elevado.

  • A otimização da configuração para débito elevado implica contrapartidas, que devem ser totalmente compreendidas.
  • Os padrões de persistência e mensagens de nivelamento de carga, como CQRS e Origem de Eventos, podem ser utilizados para otimizar ainda mais o débito.

• Os níveis de carga irão flutuar naturalmente para muitos cenários de aplicações, com picos naturais que requerem um grau suficiente de elasticidade para lidar com a procura variável, mantendo o débito e a latência.

  • A escalabilidade ágil é fundamental para suportar eficazmente níveis de débito e carga variáveis sem sobreaprovisionar os níveis de capacidade.
    • O débito de leitura e escrita tem de ser dimensionado de acordo com os requisitos e a carga da aplicação.
    • As operações de dimensionamento vertical e horizontal podem ser aplicadas para responder à alteração dos níveis de carga.

• O impacto das descidas de débito pode variar com base no cenário da carga de trabalho.

  • Haverá interrupção da conectividade?
  • As operações individuais devolverão códigos de falha enquanto o plano de controlo continuar a funcionar?
  • A plataforma de dados ativará a limitação e, em caso afirmativo, durante quanto tempo?

• A recomendação de conceção de aplicações fundamental para utilizar uma distribuição geográfica ativa-ativa apresenta desafios em torno da consistência dos dados.

  • Existe uma troca entre a consistência e o desempenho no que diz respeito à semântica transacional ACID completa e ao comportamento de bloqueio tradicional.
    • Minimizar a latência de escrita terá o custo da consistência dos dados.

• Numa configuração de escrita de várias regiões, as alterações terão de ser sincronizadas e intercaladas entre todas as réplicas, com a resolução de conflitos sempre que necessário, o que poderá afetar os níveis de desempenho e a escalabilidade.

• As réplicas só de leitura (intra-região e entre regiões) podem ser utilizadas para minimizar a latência de ida e volta e distribuir o tráfego para aumentar o desempenho, o débito, a disponibilidade e a escalabilidade.

• Uma camada de colocação em cache pode ser utilizada para aumentar o débito de leitura para melhorar a experiência do utilizador e os tempos de resposta do cliente ponto a ponto.

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

Variedade

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

  • A aplicação necessita de um modelo de dados relacionais ou pode suportar um modelo de dados variável ou não relacional?
  • Como é que a aplicação irá consultar os dados? E as consultas dependerão de conceitos de camada de base de dados, como associações relacionais? Ou a aplicação fornece essa semântica?

• A natureza dos conjuntos de dados considerados pela aplicação pode ser variada, desde conteúdos não estruturados, como imagens e vídeos, ou ficheiros mais estruturados, como CSV e Parquet.

  • Normalmente, as cargas de trabalho de aplicações compostas terão conjuntos de dados e requisitos associados distintos.

• Além das plataformas de dados relacionais ou não relacionais, as plataformas de dados de grafos ou de valor-chave 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 em conjunto, mas diferem estruturalmente.

• Numa arquitetura de microsserviços, os serviços de aplicações individuais podem ser criados com arquivos de dados otimizados para cenários distintos em vez de consoante um único arquivo de dados monolítico.

  • Os padrões de conceção, como o SAGA , podem ser aplicados para gerir a consistência e as dependências entre diferentes arquivos de dados.
    • As consultas diretas entre bases de dados podem impor restrições de co-localização.
  • A utilização de várias tecnologias de dados irá adicionar um grau de sobrecarga de gestão para manter tecnologias abrangentes.

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

• As capacidades 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 mapeadores relacionais com objetos.
  • Capacidade de consulta neutra em linguagem, como uma camada de API REST protegida.
  • Capacidades de continuidade de negócio, como cópia de segurança e restauro.

• Normalmente, os arquivos de dados analíticos suportam o armazenamento poliglota para vários tipos de estruturas de dados.

  • Os ambientes de runtime 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

• Têm de ser considerados vários fatores para validar a precisão dos dados numa aplicação e a gestão destes fatores pode ter uma influência significativa na conceção da plataforma de dados.

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

• Em qualquer aplicação distribuída com múltiplas réplicas de dados, existe uma troca entre consistência e latência, conforme expresso nos teoremas CAP e PACELC .

  • Quando os leitores e escritores são distribuídos de forma distinta, uma aplicação tem de optar por devolver a versão mais rápida disponível de um item de dados, mesmo que esteja desatualizada em comparação com uma escrita acabada de concluir (atualização) desse item de dados noutra 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 ao nível da plataforma ou ao nível dos pedidos de dados individuais.
  • Qual é a experiência do utilizador se os dados devem ser servidos a partir de uma réplica mais próxima do utilizador que não reflete o estado mais recente de uma réplica diferente? Ou seja, a aplicação pode suportar possivelmente a disponibilização de dados desatualizados?

• Num contexto de escrita de várias regiões, quando o mesmo item de dados é alterado em duas réplicas de escrita separadas antes de uma das alterações poder ser replicada, é criado um conflito que tem de ser resolvido.

  • Podem ser aplicadas políticas de resolução de conflitos padronizadas, como "Vitórias da Última Escrita" ou uma estratégia personalizada com lógica personalizada.

• A implementação de requisitos de segurança pode afetar negativamente o débito ou o desempenho.

• A encriptação inativa pode ser implementada na camada da aplicação através da encriptação do lado do cliente e/ou da camada de dados através da encriptação do lado do servidor, se necessário.

• O Azure suporta vários modelos de encriptação, incluindo a encriptação do lado do servidor que utiliza chaves geridas pelo serviço, chaves geridas pelo cliente em Key Vault ou chaves geridas pelo cliente em hardware controlado pelo cliente.

  • Com a encriptação do lado do cliente, as chaves podem ser geridas em Key Vault ou noutra localização segura.

• A encriptação de ligação de dados MACsec (IEEE 802.1AE MAC) é utilizada para proteger todo o tráfego que se desloca entre datacenters do Azure na rede principal da Microsoft.

  • Os pacotes são encriptados e desencriptados nos dispositivos antes de serem enviados, impedindo ataques físicos de "homem no meio" ou snooping/escutas telefónicas.

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

  • Como é que a plataforma de dados autenticará e autorizará o acesso operacional e o acesso operacional da aplicação?

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

  • Como é que os alertas serão aplicados a condições fora dos limites operacionais aceitáveis?

Recomendações de Estrutura

Volume

• Certifique-se de que os volumes de dados futuros associados ao crescimento orgânico não devem exceder as capacidades da plataforma de dados.

  • Prever taxas de crescimento de dados alinhadas com os planos de negócio e utilizar taxas estabelecidas para informar os requisitos de capacidade em curso.
  • Comparar volumes agregados e por registo de dados com os limites da plataforma de dados.
  • Se existir o risco de atingir limites em circunstâncias excecionais, confirme que estão em vigor mitigações operacionais para evitar tempo de inatividade e perda de dados.

• Monitorize o volume de dados e valide-o relativamente a um modelo de capacidade, tendo em conta os limites de dimensionamento e as taxas de crescimento de dados esperadas.

  • Confirme que as operações de dimensionamento estão alinhadas com os requisitos de armazenamento, desempenho e consistência.
  • Quando uma nova unidade de escala é introduzida, os dados subjacentes podem ter de ser replicados, o que levará tempo e provavelmente introduzirá uma penalização de desempenho enquanto ocorre a replicação. Por isso, certifique-se de que estas operações são executadas fora do horário comercial crítico, se possível.

• Defina as camadas de dados da aplicação para classificar conjuntos de dados com base na utilização e na criticidade para facilitar a remoção ou descarga de dados mais antigos.

  • Considere classificar conjuntos de dados em camadas "frequentes", "quentes" e "frias" ("arquivo").
    • Por exemplo, as implementações de referência fundamental utilizam o Azure Cosmos DB para armazenar dados "frequentes" que são utilizados ativamente pela aplicação, enquanto o Armazenamento do Azure é utilizado para dados de operações "a frio" para fins analíticos.

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

  • Configure a expiração do Time-To-Live (TTL) para dados que já não são necessários e que não têm um valor analítico a longo prazo.
    • Confirme que os dados antigos podem ser em camadas seguras para o armazenamento secundário ou eliminados de imediato, sem um impacto adverso na aplicação.
  • Descarregue dados não críticos para o armazenamento a frio secundário, mas mantenha-os para valores analíticos e para satisfazer os requisitos de auditoria.
  • Recolha estatísticas de telemetria e utilização da plataforma de dados para permitir que as equipas do DevOps avaliem continuamente os requisitos de limpeza e os arquivos de dados de "tamanho certo".

• Em linha com um design de aplicação de microsserviços, considere a utilização 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 arquivo de dados monolítico onde o volume de dados da expansão pode ser difícil de gerir.

Velocidade

• A plataforma de dados tem de ser inerentemente concebida e configurada para suportar um débito elevado, com cargas de trabalho separadas em diferentes contextos para maximizar o desempenho com soluções de dados otimizadas para cenários.

  • Confirme que o débito de leitura e escrita para cada cenário de dados pode ser dimensionado de acordo com os padrões de carga esperados, com tolerância suficiente para uma 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 através da utilização de mensagens assíncronas sem bloqueio, por exemplo, com os padrões CQRS ou Origem de Eventos .

  • Pode haver latência entre pedidos de escrita e quando novos dados ficam disponíveis para leitura, o que pode ter um impacto na experiência do utilizador.
    • Este impacto tem de ser compreendido e aceitável no contexto dos principais requisitos empresariais.

• Garanta a escalabilidade ágil para suportar níveis de débito e carga variáveis.

  • Se os níveis de carga forem altamente voláteis, considere o sobreaprovisionamento dos níveis de capacidade para garantir que o débito e o desempenho são mantidos.
  • Teste e valide o impacto nas cargas de trabalho de aplicações compostas quando não é possível manter o débito.

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

  • Configure o dimensionamento automático com base nos limiares internos do serviço e do conjunto de aplicações.
  • O dimensionamento deve ser iniciado e concluído em intervalos de tempo consistentes com os requisitos empresariais.
  • Para cenários em que a interação manual é necessária, estabeleça "manuais de procedimentos" operacionais automatizados que podem ser acionados em vez de realizar ações operacionais manuais.
    • Considere se os acionadores automatizados podem ser aplicados como parte de investimentos de engenharia subsequentes.

• Monitorize o débito de leitura e escrita dos dados da aplicação em relação aos requisitos de latência P50/P99 e alinhe-se com um modelo de capacidade de aplicação.

• O débito em excesso deve ser processado corretamente pela plataforma de dados ou camada da aplicação e capturado pelo modelo de estado de funcionamento para representação operacional.

• Implemente a colocação em cache para cenários de dados "frequentes" para minimizar os tempos de resposta.

  • Aplique políticas adequadas para expiração da cache e manutenção de casa para evitar o crescimento de dados em fuga.
    • Expirar itens de cache quando os dados de cópia de segurança forem alterados.
    • Se a expiração da cache for estritamente baseada no Time-To-Live (TTL), é necessário compreender o impacto e a experiência do cliente de servir dados desatualizados.

Variedade

• Em conformidade com o princípio de um design nativo da cloud e do Azure, recomenda-se vivamente que priorize os serviços geridos do Azure para reduzir a complexidade operacional e de gestão e tirar partido dos futuros investimentos da plataforma da Microsoft.

• Em linha com o princípio de conceção de aplicações de arquiteturas de microsserviços relativamente conjugadas, permita que os serviços individuais utilizem arquivos de dados distintos e tecnologias de dados otimizadas para cenários.

  • Identifique os tipos de estrutura de dados que a aplicação irá processar para cenários de carga de trabalho específicos.
  • Evite criar uma dependência num único arquivo de dados monolítico.
    • Considere o padrão de conceção SAGA em que existem dependências entre arquivos de dados.

• Confirme que as capacidades necessárias estão disponíveis para tecnologias de dados selecionadas.

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

Veracidade

• Adote uma estrutura de plataforma de dados de várias regiões e distribua réplicas entre regiões para obter a máxima fiabilidade, disponibilidade e desempenho ao aproximar os dados dos pontos finais da aplicação.

  • Distribua réplicas de dados por Zonas de Disponibilidade (AZ) numa região (ou utilize escalões de serviço com redundância entre zonas) para maximizar a disponibilidade na intra-região.

• Quando os requisitos de consistência o permitirem, utilize um design de plataforma de dados de escrita de várias regiões para maximizar a disponibilidade e fiabilidade globais globais.

  • Considere os requisitos empresariais para a resolução de conflitos quando o mesmo item de dados é alterado em duas réplicas de escrita separadas antes de uma das alterações poder ser replicada e, assim, criar um conflito.
    • Utilize políticas de resolução de conflitos padronizadas, como "Última vitória" sempre que possível
      • Se for necessária uma estratégia personalizada com lógica personalizada, confirme que as práticas de CI/CD DevOps são aplicadas para gerir a lógica personalizada.

• Teste e valide as capacidades de cópia de segurança e restauro e as operações de ativação pós-falha através de testes de caos em processos de entrega contínuos.

• Execute testes de referência de desempenho para garantir que os requisitos de desempenho e débito não são afetados pela inclusão de capacidades de segurança necessárias, como a encriptação.

  • Confirme que os processos de entrega contínua consideram o teste de carga em comparação com os testes de desempenho conhecidos.

• Ao aplicar a encriptação, é vivamente recomendado utilizar chaves de encriptação geridas pelo serviço como forma de reduzir a complexidade da gestão.

  • Se existir um requisito de segurança específico para chaves geridas pelo cliente, certifique-se de que são aplicados procedimentos de gestão de chaves adequados para garantir a disponibilidade, a cópia de segurança e a rotação de todas as chaves consideradas.

Nota

Ao integrar com uma implementação organizacional mais ampla, é fundamental que seja aplicada uma abordagem centrada na aplicação para o aprovisionamento e o funcionamento dos componentes da plataforma de dados numa conceção de aplicações.

Mais especificamente, para maximizar a fiabilidade, é fundamental que os componentes individuais da plataforma de dados respondam adequadamente ao estado de funcionamento da aplicação através de ações operacionais que possam incluir outros componentes da aplicação. Por exemplo, num cenário em que são necessários recursos adicionais da plataforma de dados, o dimensionamento da plataforma de dados juntamente com outros componentes da aplicação de acordo com um modelo de capacidade será provavelmente necessário, potencialmente através do aprovisionamento de unidades de escala adicionais. Esta abordagem será, em última análise, restrita se existir uma dependência rígida de uma equipa de operações centralizada para resolver problemas relacionados com a plataforma de dados isoladamente.

Em última análise, a utilização de serviços de dados centralizados (ou seja, DBaaS de TI Central) introduz estrangulamentos operacionais que dificultam significativamente a agilidade através de uma experiência de gestão não contextualizada e devem ser evitados num contexto crítico para a empresa ou crítico para a empresa.

Referências adicionais

Estão disponíveis orientações adicionais sobre a plataforma de dados no Guia de Arquitetura do Aplicação Azure.

• Árvore de Decisões do Arquivo de Dados do Azure
• Critérios para escolher um Arquivo de Dados
• Arquivos de Dados Não Relacionais
• Arquivos de Dados OLTP Relacionais

Arquivo de dados de escrita de várias regiões distribuído globalmente

Para acomodar totalmente as aspirações ativas-ativas distribuídas globalmente de um design de aplicação, recomenda-se vivamente que considere uma plataforma distribuída de dados de escrita de várias regiões, onde as alterações a réplicas graváveis separadas são sincronizadas e intercaladas entre todas as réplicas, com resolução de conflitos, sempre que necessário.

Importante

Os microsserviços podem não exigir todos um arquivo de dados de escrita distribuído de várias regiões, pelo que deve ter em consideração o contexto arquitetónico e os requisitos empresariais de cada cenário de carga de trabalho.

O Azure Cosmos DB fornece um arquivo de dados NoSQL distribuído globalmente e de elevada disponibilidade, que oferece escritas em várias regiões e consistência ajustável. Por conseguinte, as considerações e recomendações de conceção nesta secção irão focar-se na utilização ideal do Azure Cosmos DB.

Considerações de design

BD do Cosmos para o Azure

• O Azure Cosmos DB armazena dados em Contentores, que são arquivos transacionais indexados e baseados em linhas concebidos para permitir leituras e escritas transacionais rápidas com tempos de resposta na ordem dos milissegundos.

• O Azure Cosmos DB suporta várias APIs diferentes com diferentes conjuntos de funcionalidades, como SQL, Cassandra e MongoDB.

  • O Azure Cosmos DB para NoSQL é o conjunto de funcionalidades mais avançado e é normalmente a API onde as novas capacidades ficarão disponíveis primeiro.

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

  • O modo direto só está disponível quando utiliza o Azure Cosmos DB para NoSQL e atualmente só é suportado em plataformas .NET e Java SDK.

• Nas regiões ativadas para a Zona de Disponibilidade, o Azure Cosmos DB oferece suporte de redundância da Zona de Disponibilidade (AZ) para elevada disponibilidade e resiliência a falhas zonais numa região.

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

  • O protocolo de consenso Paxos é aplicado para alcançar o quórum entre réplicas numa região.

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

  • A replicação pode ser configurada com escritas de região única ou escritas em várias regiões.
    • Com as escritas numa única região, é utilizada uma região "hub" primária para servir todas as escritas e, se esta região do "hub" ficar indisponível, tem de ocorrer uma operação de ativação pós-falha para promover outra região como gravável.
    • Com as escritas em várias regiões, as aplicações podem escrever em qualquer região de implementação configurada, o que irá replicar as alterações entre todas as outras regiões. Se uma região não estiver disponível, as restantes regiões serão utilizadas para servir o tráfego de escrita.

• Numa configuração de escrita de várias regiões, podem ocorrer conflitos de atualização (inserir, substituir, eliminar) em que os escritores 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 automaticamente conflitos.

  • As Vitórias da Última Escrita (LWW) aplicam um protocolo de relógio de sincronização de tempo através de uma propriedade de carimbo de data _ts /hora definida pelo sistema como o caminho de resolução de conflitos. Se for um conflito, o item com o valor mais alto para o caminho de resolução de conflitos torna-se o vencedor e, se múltiplos 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 consolidado.
    • Com conflitos de eliminação, a versão eliminada ganha sempre por inserir ou substituir conflitos, independentemente do valor do caminho de resolução de conflitos.
    • A última escrita ganha é a política de resolução de conflitos predefinida.
    • Ao utilizar o Azure Cosmos DB para NoSQL, pode ser utilizada uma propriedade numérica personalizada, como uma definição de carimbo de data/hora personalizada, para resolução de conflitos.
  • As políticas de resolução personalizadas permitem que a semântica definida pela aplicação reconciliar conflitos com um procedimento armazenado de intercalação registado que é invocado automaticamente quando são detetados conflitos.
    • O sistema fornece exatamente uma garantia para a execução de um procedimento de intercalação como parte do protocolo de alocação.
    • 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 contentor.

• Numa configuração de escrita de várias regiões, existe uma dependência numa única região "hub" do Azure Cosmos DB para executar todas as resoluções de conflitos, com o protocolo de consenso Paxos aplicado para alcançar o quórum entre réplicas na região do hub.

  • A plataforma fornece uma memória intermédia de mensagens para conflitos de escrita na região do hub para o nível de carga e fornecer redundância para falhas transitórias.
    • A memória intermédia é capaz de armazenar alguns minutos de atualizações de escrita que requerem consenso.

A direção estratégica da plataforma do Azure Cosmos DB é remover esta dependência de região única para resolução de conflitos numa configuração de escrita de várias regiões, utilizando uma abordagem Paxos de 2 fases para alcançar o quórum a nível global e numa região.

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

  • É configurada uma ordenação prioritária para regiões de implementação por satélite adicionais para efeitos de ativação pós-falha.

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

• Quando implementado com uma única região de escrita, o Azure Cosmos DB pode ser configurado para ativação pós-falha automática com base numa prioridade de ativação pós-falha definida, tendo em conta todas as réplicas de região de leitura.

• O RTO fornecido pela plataforma do Azure Cosmos DB é de ~10 a 15 minutos, capturando o tempo decorrido para realizar uma ativação pós-falha regional do serviço Azure Cosmos DB se um desastre catastrófico afetar a região do hub.

  • Este RTO também é relevante num contexto de escrita de várias regiões, dada a dependência numa única região "hub" para a resolução de conflitos.
    • Se a região do "hub" ficar indisponível, as escritas efetuadas noutras regiões falharão após o preenchimento da memória intermédia da mensagem, uma vez que a resolução de conflitos não poderá ocorrer até que o serviço efetue a ativação pós-falha e seja estabelecida uma nova região do hub.

A direção estratégica da plataforma do Azure Cosmos DB é reduzir o RTO para ~5 minutos ao permitir ativações pós-falha ao nível da partição.

• Os Objetivos de Ponto de Recuperação (RPO) e os Objetivos de Tempo de Recuperação (RTO) são configuráveis através de níveis de consistência, com uma troca entre durabilidade de dados e débito.

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

• O Azure Cosmos DB oferece um SLA de 99,999% para disponibilidade de leitura e escrita para Contas de Base de Dados configuradas com várias regiões do Azure como gravável.

  • O SLA é representado pela Percentagem 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 débito, consistência, disponibilidade e latência para Contas de Base de Dados no âmbito de 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 às Contas de Base de Dados que abrangem várias regiões do Azure configuradas com qualquer um dos quatro Níveis de Consistência flexíveis.

• Existem dois tipos de débito que podem ser aprovisionados no Azure Cosmos DB, padrão e dimensionamento automático, que são medidos com Unidades de Pedido por segundo (RU/s).

  • O débito padrão aloca os recursos necessários para garantir um valor de RU/s especificado.
    • O padrão é faturado à hora para o débito aprovisionado.
  • O dimensionamento automático define um valor máximo de débito e o Azure Cosmos DB aumentará ou reduzirá verticalmente automaticamente consoante a carga da aplicação, entre o valor máximo de débito e um mínimo de 10% do valor máximo de débito.
    • O dimensionamento automático é faturado por hora para o débito máximo consumido.

• O débito aprovisionado estático com uma carga de trabalho variável pode resultar em erros de limitação, o que afetará a disponibilidade de aplicações percebida.

  • O dimensionamento automático protege contra erros de limitação ao permitir que o Azure Cosmos DB aumente verticalmente conforme necessário, mantendo a proteção de custos ao reduzir verticalmente quando a carga diminui.

• Quando o Azure Cosmos DB é replicado em várias regiões, as Unidades de Pedido (RUs) aprovisionadas são faturadas por região.

• Existe um diferença de custos significativo entre uma configuração de escrita de várias regiões e de escrita de região única que, em muitos casos, pode tornar proibitivos os custos de uma plataforma de dados do Azure Cosmos DB multimestre.

Leitura/Escrita da Região Única	Escrita de Região Única - Leitura da Região Dupla	Leitura/Escrita da Região Dupla
1 RU	2 RU	4 RU

O delta entre single-region-write e multi-region-write é, na verdade, inferior ao rácio 1:2 refletido na tabela acima. Mais especificamente, existe um custo de transferência de dados entre regiões associado às atualizações de escrita numa configuração de escrita única, que não é capturada nos custos de RUs, tal como acontece com a configuração de escrita de várias regiões.

• O armazenamento consumido é faturado como uma taxa fixa para a quantidade total de armazenamento (GB) consumido para alojar dados e índices durante uma determinada hora.

• Session é o nível de consistência predefinido e mais utilizado, uma vez que os dados são recebidos pela mesma ordem que as escritas.

• O Azure Cosmos DB suporta a autenticação através de uma identidade Microsoft Entra ou chaves e tokens de recursos do Azure Cosmos DB, que fornecem capacidades de sobreposição.

Capacidades de

• É possível desativar as operações de gestão de recursos através de chaves ou tokens de recursos para limitar chaves e tokens de recursos apenas a operações de dados, permitindo um controlo de acesso a recursos detalhado com Microsoft Entra controlo de acesso baseado em funções (RBAC).

  • Restringir o acesso ao plano de controlo através de chaves ou tokens de recursos irá desativar as operações do plano de controlo para clientes que utilizam SDKs do Azure Cosmos DB e, por conseguinte, deve ser cuidadosamente avaliado e testado.
  • A disableKeyBasedMetadataWriteAccess definição pode ser configurada através de definições IaC de Modelo do ARM ou através de um Azure Policy Incorporado.

• Microsoft Entra suporte RBAC no Azure Cosmos DB aplica-se às operações de gestão do plano de controlo de contas e recursos.

  • Os administradores de aplicações podem criar atribuições de funções para utilizadores, grupos, principais de serviço ou identidades geridas para conceder ou negar o acesso a recursos e operações nos recursos do Azure Cosmos DB.
  • Existem várias Funções RBAC Incorporadas disponíveis para atribuição de funções e as funções RBAC personalizadas também podem ser utilizadas para formar combinações de privilégios específicas.
    • O Leitor de Conta do Cosmos DB permite o acesso só de leitura ao recurso do Azure Cosmos DB.
    • O Contribuidor de Conta do DocumentDB permite a gestão de contas do Azure Cosmos DB, incluindo chaves e atribuições de funções, mas não permite o acesso ao plano de dados.
    • Operador do Cosmos DB, que é semelhante ao Contribuidor de Conta do DocumentDB, mas não fornece a capacidade de gerir chaves ou atribuições de funções.

• Os recursos do Azure Cosmos DB (contas, bases de dados e contentores) podem ser protegidos contra modificações ou eliminações incorretas com Bloqueios de Recursos.

  • Os Bloqueios de Recursos podem ser definidos ao nível da conta, da base de dados ou do contentor.
  • Um Bloqueio de Recurso definido em num recurso será herdado por todos os recursos subordinados. Por exemplo, um Conjunto de Bloqueio de Recursos na conta do Azure Cosmos DB será herdado por todas as bases de dados e contentores na conta.
  • Os Bloqueios de Recursos aplicam-se apenas às operações do plano de controlo e não impedem operações do plano de dados, como criar, alterar ou eliminar dados.
  • Se o acesso ao plano de controlo não for restringido com disableKeyBasedMetadataWriteAccesso , os clientes poderão realizar operações do plano de controlo com chaves de conta.

• O feed de alterações do Azure Cosmos DB fornece um feed ordenado pelo tempo de alterações aos dados num contentor do Azure Cosmos DB.

  • O feed de alterações inclui apenas operações de inserção e atualização para o contentor do Azure Cosmos DB de origem; não inclui eliminações.

• O feed de alterações pode ser utilizado para manter um arquivo de dados separado do Contentor primário utilizado pela aplicação, com atualizações em curso para o arquivo de dados de destino alimentados pelo feed de alterações do Contentor de origem.

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

• Se as operações de eliminação afetarem rotineiramente os dados no Contentor de origem, o arquivo alimentado pelo feed de alterações será impreciso e não será elegível para os dados eliminados.

  • Um padrão de Eliminação Recuperável pode ser implementado para que os registos de dados sejam incluídos no feed de alterações.
    • Em vez de eliminar explicitamente os registos de dados, os registos de dados são atualizados ao definir um sinalizador (por exemplo, IsDeleted) para indicar que o item é considerado eliminado.
    • Qualquer arquivo de dados de destino fornecido pelo feed de alterações terá de detetar e processar itens com um sinalizador eliminado definido como Verdadeiro; em vez de armazenar registos de dados eliminados de forma recuperável, a versão existente do registo de dados no arquivo de destino terá de ser eliminada.
  • Normalmente, é utilizado um TTL (Time-To-Live) curto com o padrão de eliminação recuperável para que o Azure Cosmos DB elimine automaticamente os dados expirados, mas apenas depois de se refletir no feed de alterações com o sinalizador eliminado definido como Verdadeiro.
    • Realiza a intenção de eliminação original ao propagar também a eliminação através do feed de alterações.

• O Azure Cosmos DB pode ser configurado como um arquivo 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 de ETL tradicionais.

• O Azure Cosmos DB cria automaticamente cópias de segurança 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 cópia de segurança distintos.

  • Periodic é o modo de cópia de segurança predefinido para todas as contas, em que as cópias de segurança são feitas num intervalo periódico e os dados são restaurados através da criação de um pedido junto da equipa de suporte.
    • O período de retenção da cópia de segurança periódica predefinido é de oito horas e o intervalo de cópia de segurança predefinido é de quatro horas, o que significa que apenas as duas cópias de segurança mais recentes são armazenadas por predefinição.
    • O intervalo de cópia de segurança e o período de retenção são configuráveis na conta.
      • O período de retenção máximo prolonga-se por um mês com um intervalo mínimo de cópia de segurança de uma hora.
      • É necessária uma atribuição de função para a "Função de Leitor de Conta" do Azure Cosmos DB para configurar a redundância do armazenamento de cópias de segurança.
    • Duas cópias de segurança são incluídas sem custos adicionais, mas as cópias de segurança adicionais incorrem em custos adicionais.
    • Por predefinição, as cópias de segurança periódicas são armazenadas em Geo-Redundant Armazenamento (GRS) separados que não estão diretamente acessíveis.
      • O armazenamento de cópias de segurança existe na região principal do "hub" e é replicado para a região emparelhada através da replicação de armazenamento subjacente.
      • A configuração de redundância da conta de armazenamento de cópias de segurança subjacente é configurável para Armazenamento Com Redundância Entre Zonas ou Armazenamento Locally-Redundant.
    • A execução de uma operação de restauro requer um Pedido de Suporte, uma vez que os clientes não podem efetuar diretamente um restauro.
      • Antes de abrir um pedido de suporte, o período de retenção da cópia de segurança deve ser aumentado para, pelo menos, sete dias no prazo de oito horas após o evento de perda de dados.
    • Uma operação de restauro cria uma nova conta do Azure Cosmos DB onde os dados são recuperados.
      • Não é possível utilizar uma conta existente do Azure Cosmos DB para Restaurar
      • Por predefinição, será utilizada uma nova conta do Azure Cosmos DB com o nome <Azure_Cosmos_account_original_name>-restored<n> .
        • Este nome pode ser ajustado, tal como ao reutilizar o nome existente se a conta original tiver sido eliminada.
    • Se o débito for aprovisionado ao nível da base de dados, a cópia de segurança e o restauro ocorrerão ao nível da base de dados
      • Não é possível selecionar um subconjunto de contentores para restaurar.
  • O modo de cópia de segurança contínua permite um restauro para qualquer ponto do tempo nos últimos 30 dias.
    • As operações de restauro podem ser realizadas para regressar a um ponto específico no tempo (PITR) com uma granularidade de um segundo.
    • A janela disponível para operações de restauro é de até 30 dias.
      • Também é possível restaurar para o estado de instanciação de recursos.
    • As cópias de segurança contínuas são efetuadas em todas as regiões do Azure onde a conta do Azure Cosmos DB existe.
      • As cópias de segurança contínuas são armazenadas na mesma região do Azure que cada réplica do Azure Cosmos DB, com o Armazenamento Locally-Redundant (LRS) ou o Armazenamento Com Redundância entre Zonas (ZRS) em regiões que suportam Zonas de Disponibilidade.
    • Um restauro self-service pode ser efetuado com os artefactos portal do Azure ou IaC, como modelos arm.
    • Existem várias limitações com a Cópia de Segurança Contínua.
      • O modo de cópia de segurança contínua não está atualmente disponível numa configuração de escrita em várias regiões.
      • Neste momento, apenas o Azure Cosmos DB para NoSQL e o Azure Cosmos DB para MongoDB podem ser configurados para cópia de segurança contínua.
      • Se um contentor tiver o TTL configurado, os dados restaurados que excederam o TTL podem ser imediatamente eliminados
    • Uma operação de restauro cria uma nova conta do Azure Cosmos DB para o restauro para um ponto anterior no tempo.
    • Existe um custo de armazenamento adicional para cópias de segurança contínuas e operações de restauro.

• 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 cópia de segurança do Azure Cosmos DB é composta pelos próprios dados e detalhes de configuração para o débito aprovisionado, políticas de indexação, regiões de implementação e definições de TTL de contentor.

  • As cópias de segurança não contêm definições de firewall, listas de controlo de acesso à rede virtual, definições de ponto final privado, definições de consistência (uma conta é restaurada com consistência de sessão), procedimentos armazenados, acionadores, UDFs ou definições de várias regiões.
    • Os clientes são responsáveis pela reimplementação de capacidades e definições de configuração. Estes não são restaurados através da cópia de segurança do Azure Cosmos DB.
  • Azure Synapse os dados do arquivo analítico link também não estão incluídos nas cópias de segurança do Azure Cosmos DB.

• É possível implementar uma capacidade de cópia de segurança e restauro personalizada para cenários em que as abordagens Periódicas e Contínuas não são uma boa opção.

  • Uma abordagem personalizada introduz custos significativos e custos administrativos adicionais, que devem ser compreendidos e cuidadosamente avaliados.
    • Os cenários de restauro comuns devem ser modelados, como danos ou eliminação de uma conta, base de dados, contentor, no item de dados.
    • Devem ser implementados procedimentos de limpeza para evitar a expansão das cópias de segurança.
  • O Armazenamento do Azure ou uma tecnologia de dados alternativa pode ser utilizada, como um contentor alternativo do Azure Cosmos DB.
    • O Armazenamento do Azure e o Azure Cosmos DB fornecem integrações nativas com serviços do Azure, como Funções do Azure e Azure Data Factory.

• A documentação do Azure Cosmos DB indica duas opções potenciais para implementar cópias de segurança personalizadas.

  • Feed de alterações do Azure Cosmos DB para escrever dados numa instalação de armazenamento separada.
    • Uma função do Azure ou um processo de aplicação equivalente utiliza o processador do feed de alterações para vincular ao feed de alterações e processar itens no armazenamento.
  • As cópias de segurança personalizadas contínuas ou periódicas (em lotes) podem ser implementadas com o feed de alterações.
  • O feed de alterações do Azure Cosmos DB ainda não reflete as eliminações, pelo que tem de ser aplicado um padrão de eliminação recuperável com uma propriedade booleana e TTL.
    • Este 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 (Azure Cosmos DB para conectores da API NoSQL ou MongoDB) para copiar dados.
    • Azure Data Factory (ADF) suporta a execução manual e acionadores De agendamento, janela em cascata e baseados em eventos.
      • Fornece suporte para o Armazenamento e o Event Grid.
    • O ADF é principalmente adequado para implementações de cópias de segurança personalizadas periódicas devido à orquestração orientada para lotes.
      • É menos adequado para implementações de cópias de segurança contínuas com eventos frequentes devido à sobrecarga de execução da orquestração.
    • O ADF suporta Azure Private Link para cenários de alta segurança de rede

O Azure Cosmos DB é utilizado na conceção de muitos serviços do Azure, pelo que uma falha 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 num determinado serviço dependerá bastante da forma como o design do serviço subjacente utiliza o Azure Cosmos DB.

Recomendações de Estrutura

BD do Cosmos para o Azure

• Utilize o Azure Cosmos DB como a plataforma de dados primária onde os requisitos o permitem.

• Para cenários de cargas de trabalho fundamentais para a missão, configure o Azure Cosmos DB com uma réplica de escrita dentro de cada região de implementação para reduzir a latência e fornecer a redundância máxima.

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

• Para cenários de cargas de trabalho menos críticas, priorize a utilização da configuração de escrita de região única (ao utilizar Zonas de Disponibilidade) com réplicas de leitura distribuídas globalmente, uma vez que esta opção oferece um elevado nível de fiabilidade da plataforma de dados (SLA de 99,999% para leitura, 99,995% para operações de escrita) num ponto de preço mais apelativo.

  • Configure a aplicação para utilizar a réplica de leitura local do Azure Cosmos DB para otimizar o desempenho de leitura.

• Selecione uma região de implementação "hub" ideal onde ocorrerá a resolução de conflitos numa configuração de escrita em várias regiões e todas as escritas serão efetuadas numa configuração de escrita de região única.

  • Considere a distância relativamente a outras regiões de implementação e a latência associada na seleção de uma região primária e as capacidades necessárias, como Zonas de Disponibilidade suporte.

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

• Utilize o Azure Cosmos DB para NoSQL, uma vez que oferece o conjunto de funcionalidades mais abrangente, especialmente no que diz respeito à otimização do desempenho.

  • As APIs alternativas devem ser consideradas principalmente para cenários de migração ou compatibilidade.
    • Ao utilizar APIs alternativas, confirme que as capacidades necessárias estão disponíveis com o idioma e o SDK selecionados para garantir a configuração e o desempenho ideais.

• Utilize o Modo de ligação direta para otimizar o desempenho da rede através da conectividade TCP direta aos nós do Azure Cosmos DB de back-end, com um número reduzido de "saltos" de rede.

O SLA do Azure Cosmos DB é calculado com uma média de pedidos falhados, que podem não estar diretamente alinhados com um orçamento de erros de escalão de fiabilidade de 99,999%. Ao conceber um SLO de 99,999%, é, portanto, vital planear a indisponibilidade de escrita do Azure Cosmos DB regional e de várias regiões, garantindo que uma tecnologia de armazenamento de contingência é posicionada se ocorrer uma falha, como uma fila de mensagens persistente para repetição subsequente.

• Defina uma estratégia de criação de partições 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 criação de partições para garantir um desempenho ideal.

• Selecione uma chave de partição ideal.

  • A chave de partição não pode ser alterada depois de ter sido criada na 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 elevada, com uma vasta gama de valores possíveis.
  • A chave de partição deve distribuir o consumo de RUs e o armazenamento de dados uniformemente em todas as partições lógicas para garantir até o consumo de RUs 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 RUs.

• A indexação também é crucial para o desempenho, pelo que deve garantir que as exclusões de índice são utilizadas para reduzir as RU/s e os requisitos de armazenamento.

  • Indexar apenas os campos necessários para filtragem nas consultas; criar índices para os predicados mais utilizados.

• Tire partido das capacidades de processamento, repetição e fiabilidade incorporadas do SDK do Azure Cosmos DB.

  • Implemente a lógica de repetição no SDK nos clientes.

• Utilize chaves de encriptação geridas pelo serviço para reduzir a complexidade da gestão.

  • Se existir um requisito de segurança específico para chaves geridas pelo cliente, certifique-se de que são aplicados os procedimentos de gestão de chaves adequados, como a cópia de segurança e a rotação.

• Desative o acesso de escrita de metadados baseados em chaves do Azure Cosmos DB ao aplicar o Azure Policy incorporado.

• Ative o Azure Monitor para recolher métricas principais e registos de diagnósticos, como débito aprovisionado (RU/s).

  • Encaminhe os dados operacionais do Azure Monitor para uma área de trabalho do Log Analytics dedicada ao Azure Cosmos DB e a outros recursos globais na estrutura da aplicação.
  • Utilize as métricas do Azure Monitor para determinar se os padrões de tráfego da aplicação são adequados para o dimensionamento automático.

• Avalie os padrões de tráfego da aplicação para selecionar uma opção ideal para tipos de débito aprovisionados.

  • Considere o débito aprovisionado de dimensionamento automático para redistribuir automaticamente a procura de cargas de trabalho.

• Avalie as sugestões de desempenho da Microsoft para o Azure Cosmos DB para otimizar a configuração do lado do cliente e do lado do servidor para uma maior latência e débito.

• Ao utilizar o AKS como a plataforma de computação: para cargas de trabalho intensivas em consultas, selecione um SKU de nó do AKS que tenha a rede acelerada ativada para reduzir a latência e o nervosismo da CPU.

• Para implementações de regiões de escrita única, é vivamente recomendado configurar o Azure Cosmos DB para ativação pós-falha automática.

• Nível de carga através da utilização de mensagens assíncronas sem bloqueio nos fluxos do sistema, que escrevem atualizações para o Azure Cosmos DB.

  • Considere padrões como Segregação de Responsabilidade de Comandos e Consultas e Origem de Eventos.

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

  • Considere a utilização de cópias de segurança do Azure Cosmos DB em cenários em que os dados contidos ou a conta do Azure Cosmos DB são eliminados ou danificados.
  • Evite a utilização de uma abordagem de cópia de segurança personalizada, a menos que seja absolutamente necessário.

• Recomenda-se vivamente que pratique procedimentos de recuperação em recursos e dados de não produção, como parte da preparação padrão da operação de continuidade de negócio.

• Defina artefactos IaC para restabelecer as definições de configuração e as capacidades de um restauro de cópia de segurança do Azure Cosmos DB.

• Avalie e aplique a documentação de orientação de controlo da Linha de Base de Segurança do Azure para Cópia de Segurança e Recuperação do Azure Cosmos DB.

  • BR-1: Garantir cópias de segurança automatizadas regulares
  • BR-3: Validar todas as cópias de segurança, incluindo as chaves geridas pelo cliente
  • BR-4, Mitigar o risco de chaves perdidas

• Para cargas de trabalho analíticas que requerem disponibilidade em várias regiões, utilize o Arquivo 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, a utilização do Azure Cosmos DB numa configuração de escrita de várias regiões pode não ser diretamente aplicável. Nestes casos, é vital que as tecnologias relacionais utilizadas sejam concebidas e configuradas para manter as aspirações ativas e ativas de várias regiões de um design de aplicação.

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 comuns de OSS, incluindo MySQL, PostgreSQL e MariaDB. Por conseguinte, as considerações e recomendações de conceção nesta secção irão focar-se na utilização ideal dos sabores da Base de Dados do SQL do Azure e dos OSS da Base de Dados do Azure para maximizar a fiabilidade e a disponibilidade global.

Considerações de design

• Embora as tecnologias de dados relacionais possam ser configuradas para dimensionar facilmente operações de leitura, as escritas são normalmente limitadas a 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 por várias bases de dados estruturadas idênticas, criando partições de bases de dados horizontalmente para navegar nas restrições da plataforma.

  • Por exemplo, a fragmentação é frequentemente aplicada em plataformas SaaS multi-inquilino para isolar grupos de inquilinos em construções de plataformas de dados distintas.

Base de Dados SQL do Azure

• SQL do Azure Database fornece um motor de base de dados totalmente gerido que está sempre em execução na versão estável mais recente do motor de base de dados SQL Server e do Sistema Operativo subjacente.

  • Fornece funcionalidades inteligentes, como otimização do desempenho, monitorização de ameaças e avaliações de vulnerabilidades.

• SQL do Azure Database fornece elevada disponibilidade regional incorporada e georreplicação chave na mão para distribuir réplicas de leitura pelas regiões do Azure.

  • Com a georreplicação, as réplicas secundárias da base de dados permanecem só de leitura até que seja iniciada uma ativação pós-falha.
  • São suportados até quatro secundários nas mesmas regiões ou em regiões diferentes.
  • As réplicas secundárias também podem ser utilizadas para acesso a consultas só de leitura para otimizar o desempenho de leitura.
  • A ativação pós-falha tem de ser iniciada manualmente, mas pode ser encapsulada em procedimentos operacionais automatizados.

• SQL do Azure Base de Dados fornece Grupos de Ativação Pós-falha Automática, que replica bases de dados para um servidor secundário e permite a ativação pós-falha transparente se ocorrer uma falha.

  • Os grupos de ativação pós-falha automática suportam a georreplicação de todas as bases de dados no grupo para apenas um servidor secundário ou instância numa região diferente.
  • Atualmente, os grupos de ativação pós-falha automática não são suportados no escalão de serviço Hyperscale.
  • As bases de dados secundárias podem ser utilizadas para descarregar tráfego de leitura.

• As réplicas de base de dados do escalão de serviço Premium ou Crítico para a Empresa podem ser distribuídas por Zonas de Disponibilidade sem custos adicionais.

  • O anel de controlo também é duplicado em várias zonas como três anéis de gateway (GW).
    • O encaminhamento para uma cadência de gateway específica é controlado pelo Gestor de Tráfego do Azure.
  • Ao utilizar o escalão Crítico para a Empresa, a configuração com redundância entre zonas só está disponível quando o hardware de computação Gen5 estiver selecionado.

• SQL do Azure Base de Dados oferece um SLA de disponibilidade de 99,99% de base em todos os escalões de serviço, mas fornece um SLA de 99,995% mais elevado para os escalões Crítico para a Empresa ou Premium em regiões que suportam zonas de disponibilidade.

  • SQL do Azure escalões Crítico para a Empresa de Base de Dados ou Premium não configurados para Implementações Com Redundância entre Zonas tem um SLA de disponibilidade de 99,99%.

• Quando configurado com georreplicação, o escalão de Crítico para a Empresa da Base de Dados SQL do Azure fornece um Objetivo de Tempo de Recuperação (RTO) de 30 segundos durante 100% das horas implementadas.

• Quando configurado com georreplicação, o escalão Crítico para a Empresa da Base de Dados SQL do Azure tem um Objetivo de Ponto de recuperação (RPO) de 5 segundos durante 100% das horas implementadas.

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

• Os custos de computação associados à Base de Dados SQL do Azure podem ser reduzidos com um Desconto de Reserva.

  • Não é possível aplicar capacidade reservada para bases de dados baseadas em DTU.

• O restauro para um ponto anterior no tempo pode ser utilizado para devolver uma base de dados e dados contidos para um ponto anterior no tempo.

• O restauro geográfico pode ser utilizado para recuperar uma base de dados a partir de uma cópia de segurança georredundante.

Base de Dados do Azure para PostgreSQL

• A Base de Dados do Azure para PostgreSQL é disponibilizada em três opções de implementação diferentes:

  • Servidor Único, SLA 99,99%
  • Servidor Flexível, que oferece redundância da Zona de Disponibilidade, SLA 99,99%
  • Hyperscale (Citus), SLA 99,95% quando o modo de Elevada Disponibilidade está ativado.

• O Hyperscale (Citus) proporciona escalabilidade dinâmica através da fragmentação sem alterações de aplicações.

  • Distribuir linhas de tabela em vários servidores PostgreSQL é fundamental para garantir consultas dimensionáveis no Hyperscale (Citus).
  • Vários nós podem armazenar coletivamente mais dados do que uma base de dados tradicional e, em muitos casos, podem utilizar CPUs de trabalho em paralelo para otimizar os custos.

• O dimensionamento automático pode ser configurado através da automatização de runbooks para garantir a elasticidade em resposta à alteração dos padrões de tráfego.

• O servidor flexível fornece eficiências de custos para cargas de trabalho não de produção através da capacidade de parar/iniciar o servidor e de um escalão de computação expansível adequado para cargas de trabalho que não necessitam de capacidade de computação contínua.

• Não existe nenhum custo adicional para o armazenamento de cópias de segurança até 100% do armazenamento total do servidor aprovisionado.

  • O consumo adicional do armazenamento de cópias de segurança é cobrado de acordo com GB/mês consumido.

• Os custos de computação associados a Base de Dados do Azure para PostgreSQL podem ser reduzidos com um Desconto de Reserva de Servidor Único ou Um Desconto de Reserva do Hyperscale (Citus).

Recomendações de Estrutura

• Considere a fragmentação para particionar bases de dados relacionais com base em diferentes contextos de aplicação e dados, ajudando a navegar nas restrições da plataforma, maximizar a escalabilidade e a disponibilidade e o isolamento de falhas.

  • Esta recomendação é particularmente predominante quando a conceção da aplicação considera três ou mais regiões do Azure, uma vez que as restrições de tecnologia relacional podem dificultar significativamente as plataformas de dados distribuídas globalmente.
  • A fragmentação não é adequada para todos os cenários da aplicação, pelo que é necessária uma avaliação contextualizada.

• Priorize a utilização da Base de Dados SQL do Azure onde existem requisitos relacionais devido à sua maturidade na plataforma do Azure e a uma vasta gama de capacidades de fiabilidade.

Base de Dados SQL do Azure

• Utilize o escalão de serviço Business-Critical para maximizar a fiabilidade e a disponibilidade, incluindo o acesso a capacidades de resiliência críticas.

• Utilize o modelo de consumo baseado em vCore para facilitar a seleção independente de recursos de computação e armazenamento, adaptado aos requisitos de volume e débito da carga de trabalho.

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

• Configure o modelo de implementação Zone-Redundant para distribuir Crítico para a Empresa réplicas de base de dados na mesma região Zonas de Disponibilidade.

• Utilize a Georreplicação Ativa para implementar réplicas legíveis em todas as regiões de implementação (até quatro).

• Utilize Grupos de Ativação Pós-falha Automática para fornecer ativação pós-falha transparente para uma região secundária, com georreplicação aplicada para fornecer replicação a regiões de implementação adicionais para otimização de leitura e redundância de bases de dados.

  • Para cenários de aplicação limitados a apenas duas regiões de implementação, a utilização de Grupos de Ativação Pós-falha Automática deve ser priorizada.

• Considere acionadores operacionais automatizados, com base em alertas alinhados com o modelo de estado de funcionamento da aplicação, para realizar ativações pós-falha em instâncias georreplicadas se uma falha afetar o principal e secundário no Grupo de Ativação Pós-falha Automática.

Importante

Para aplicações que considerem mais de quatro regiões de implementação, deve ter em consideração a fragmentação no âmbito da aplicação ou refatorizar a aplicação para suportar tecnologias de escrita de várias regiões, como o Azure Cosmos DB. No entanto, se isto não for viável no cenário de carga de trabalho da aplicação, recomendamos que eleve uma região numa única geografia para um estado primário que abranja uma instância georreplicada para um acesso de leitura mais uniformemente distribuído.

• Configure a aplicação para consultar instâncias de réplica para consultas de leitura para otimizar o desempenho de leitura.

• Utilize o Azure Monitor e o SQL do Azure Analytics para obter informações operacionais quase em tempo real no SQL do Azure DB para detetar incidentes de fiabilidade.

• Utilize o Azure Monitor para avaliar a utilização de todas as bases de dados para determinar se foram dimensionadas adequadamente.

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

• Calcule uma métrica de estado de funcionamento para os componentes da base de dados observarem o estado de funcionamento em relação aos requisitos empresariais e à utilização de recursos, utilizando a monitorização e alertas para impulsionar a ação operacional automatizada, sempre que adequado.

  • Certifique-se de que as principais métricas de desempenho das consultas são incorporadas para que possam ser tomadas medidas rápidas quando ocorre a degradação do serviço.

• Otimizar consultas, tabelas e bases de dados com o Query Performance Insights e recomendações de desempenho comuns fornecidas pela Microsoft.

• Implemente a lógica de repetição com o SDK para mitigar erros transitórios que afetam a conectividade da Base de Dados SQL do Azure.

• Priorize a utilização de chaves geridas pelo serviço ao aplicar a Encriptação de Dados Transparente (TDE) do lado do servidor para encriptação inativa.

  • Se forem necessárias chaves geridas pelo cliente ou encriptação do lado do cliente (AlwaysEncrypted), certifique-se de que as chaves são adequadamente resilientes com cópias de segurança e instalações de rotação automatizadas.

• Considere a utilização do restauro para um ponto anterior no tempo como um manual de procedimentos operacional para recuperar de erros de configuração graves.

Base de Dados do Azure para PostgreSQL

• Recomenda-se que o Servidor Flexível o utilize para cargas de trabalho críticas para a empresa devido ao suporte da Zona de Disponibilidade.

• Ao utilizar o Hyperscale (Citus) para cargas de trabalho críticas para empresas, ative o modo de Elevada Disponibilidade para receber a garantia de SLA de 99,95%.

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

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

  • Considere o Desconto de Reserva do Hyperscale (Citus) para fornecer potenciais otimizações de custos.

Colocação em cache de Dados de Camada Frequente

Uma camada de colocação em cache na memória pode ser aplicada para melhorar uma plataforma de dados, aumentando significativamente o débito de leitura e melhorando os tempos de resposta do cliente ponto a ponto para cenários de dados de camada frequente.

O Azure fornece vários serviços com capacidades aplicáveis para colocar em cache as principais estruturas de dados, com Cache do Azure para Redis posicionados para abstrair e otimizar o acesso de leitura da plataforma de dados. Por conseguinte, esta secção irá focar-se na utilização ideal de Cache do Azure para Redis em cenários em que é necessário um desempenho de leitura adicional e a durabilidade do acesso a dados.

Considerações sobre Design

• Uma camada de colocação em cache fornece durabilidade de acesso a dados adicionais, uma vez que, mesmo que uma falha tenha impacto nas tecnologias de dados subjacentes, um instantâneo de dados da aplicação ainda pode ser acedido através da camada de colocação em cache.

• Em determinados cenários de carga de trabalho, a colocação em cache na memória pode ser implementada na própria plataforma da aplicação.

Cache do Azure para Redis

• A cache de Redis é uma open source sistema de armazenamento de chave-valor noSQL na memória.

• Os escalões Enterprise e Enterprise Flash podem ser implementados numa configuração ativa-ativa em Zonas de Disponibilidade numa região e em diferentes regiões do Azure através da georreplicação.

  • Quando implementado em pelo menos três regiões do Azure e três ou mais Zonas de Disponibilidade em cada região, com a georreplicação ativa ativa ativa para todas as instâncias de Cache, Cache do Azure para Redis fornece um SLA de 99,999% para conectividade a um ponto final de cache regional.
  • Quando implementado em três Zonas de Disponibilidade numa única região do Azure, é fornecido um SLA de conectividade de 99,99%.

• O escalão Flash de Empresa é executado numa combinação de armazenamento de memória não volátil de RAM e flash e, embora isto introduza uma pequena penalização de desempenho, também permite tamanhos de cache muito grandes, até 13 TB com clustering.

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

• A funcionalidade Atualizações Agendada não inclui atualizações ou atualizações do Azure aplicadas ao sistema operativo de VM subjacente.

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

Recomendações de Estrutura

• Considere uma camada de colocação em cache otimizada para cenários de dados "frequentes" para aumentar o débito de leitura e melhorar os tempos de resposta.

• Aplique políticas adequadas para a expiração e manutenção da cache para evitar o crescimento de dados em fuga.

  • Considere expirar itens de cache quando os dados de cópia de segurança forem alterados.

Cache do Azure para Redis

• Utilize o SKU Premium ou Enterprise para maximizar a fiabilidade e o desempenho.

  • Para cenários com volumes de dados extremamente grandes, o escalão Flash de Empresa deve ser considerado.
  • Para cenários em que apenas é necessária georreplicação passiva, o escalão Premium também pode ser considerado.

• Implemente instâncias de réplica com a georreplicação numa configuração ativa em todas as regiões de implementação consideradas.

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

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

  • Calcule uma classificação de estado de funcionamento para os componentes regionais da cache para observar o estado de funcionamento em relação aos requisitos empresariais e à utilização de recursos.
  • Observe e alerte sobre as principais métricas, tais como CPU elevada, utilização elevada da memória, carga elevada do servidor e chaves expulsas para obter informações quando dimensionar a cache.

• Otimize a resiliência da ligação ao implementar a lógica de repetição, tempos limite e utilizar uma implementação singleton do multiplexer de ligação redis.

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

Cenários Analíticos

É cada vez mais comum as aplicações críticas para a missão considerarem os cenários analíticos como um meio para impulsionar o valor adicional de fluxos de dados abrangentes. Por conseguinte, os cenários analíticos de aplicações e operacionais (AIOps) formam um aspeto crucial da plataforma de dados altamente fiável.

As cargas de trabalho analíticas e transacionais requerem diferentes capacidades e otimizações da plataforma de dados para um desempenho aceitável nos respetivos contextos.

Description	Analítico	Transacional
Caso de Utilização	Analisar grandes volumes de dados ("macrodados")	Processar volumes muito grandes de transações individuais
Otimizado para	Ler consultas e agregações em vários registos	Consultas De Criação/Leitura/Atualização/Eliminação (CRUD) quase em tempo real ao longo de poucos registos
Características Principais	- Consolidar a partir de origens de dados de registo - Armazenamento baseado em colunas - Armazenamento distribuído - Processamento paralelo - Desnormalizado - Leituras e escritas de baixa simultaneidade - Otimizar para o volume de armazenamento com compressão	- Origem de dados do registo para a aplicação - Armazenamento baseado em linhas - Armazenamento contíguo - Processamento simétrico - Normalizado - Leituras e escritas de elevada simultaneidade, atualizações de índice - Otimizar o acesso rápido a dados com armazenamento na memória

Azure Synapse fornece uma plataforma de análise empresarial que reúne dados relacionais e não relacionais com tecnologias do Spark, utilizando a integração incorporada com serviços do Azure, como o Azure Cosmos DB, para facilitar a análise de macrodados. Por conseguinte, as considerações e recomendações de conceção nesta secção irão focar-se no Azure Synapse ideal e na utilização do Azure Cosmos DB para cenários analíticos.

Considerações sobre Design

• Tradicionalmente, os cenários analíticos em grande escala são facilitados ao extrair dados para uma plataforma de dados separada otimizada para consultas analíticas subsequentes.
  • Os pipelines de Extração, Transformação e Carga (ETL) são utilizados para extrair dados que consumirão débito e afetarão o desempenho da carga de trabalho transacional.
  • Executar pipelines ETL com pouca frequência para reduzir o débito e os impactos no desempenho resultarão em dados analíticos menos atualizados.
  • A sobrecarga de desenvolvimento e manutenção do pipeline ETL aumenta à medida que as transformações de dados se tornam mais complexas.
    • Por exemplo, se os dados de origem forem frequentemente alterados ou eliminados, os pipelines ETL têm de ter em conta essas alterações nos dados de destino das consultas analíticas através de uma abordagem aditiva/versão, captura e recarregamento ou alterações no local nos dados analíticos. Cada uma destas abordagens terá um impacto derivado, como a recriação ou atualização de índices.

BD do Cosmos para o Azure

• Normalmente, as consultas analíticas executadas em dados transacionais do Azure Cosmos DB serão agregadas entre partições em grandes volumes de dados, consumindo débito significativo da Unidade de Pedido (RU), o que pode afetar o desempenho das cargas de trabalho transacionais circundantes.

• O Arquivo Analítico do Azure Cosmos DB fornece um arquivo de dados totalmente isolado e orientado para colunas que permite análises em grande escala em dados do Azure Cosmos DB a partir de Azure Synapse sem impacto nas cargas de trabalho transacionais do Azure Cosmos DB.

  • Quando um Contentor do Azure Cosmos DB é ativado como um Arquivo Analítico, é criado internamente um novo arquivo de colunas a partir dos dados operacionais no Contentor. Este arquivo de colunas é mantido separadamente do arquivo de transações orientado para linhas do contentor.
  • As operações Criar, Atualizar e Eliminar nos dados operacionais são sincronizadas automaticamente com o arquivo analítico, pelo que não é necessário nenhum feed de alterações ou processamento de ETL.
  • A sincronização de dados da operacional para o arquivo analítico não consome unidades de pedido de débito (RUs) aprovisionadas no Contentor ou na Base de Dados. Não existe nenhum impacto no desempenho nas cargas de trabalho transacionais. O Arquivo Analítico não requer a alocação de RUs adicionais numa Base de Dados ou Contentor 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 Arquivo Analítico. Normalmente, a latência de Sincronização Automática é inferior a dois (2) minutos.
    • A latência de Sincronização Automática pode ter até cinco (5) minutos para uma Base de Dados com débito partilhado e um grande número de Contentores.
    • Assim que a Sincronização Automática for concluída, os dados mais recentes podem ser consultados a partir de Azure Synapse.
  • O armazenamento do Arquivo Analítico utiliza um modelo de preços baseado no consumo que cobra o volume de dados e o número de operações de leitura e escrita. Os preços do arquivo analítico são separados dos preços do arquivo transacional.

• Com Azure Synapse Link, o Arquivo Analítico do Azure Cosmos DB pode ser consultado diretamente a partir de Azure Synapse. Isto permite o Processamento de Transactional-Analytical Híbrido (HTAP) sem ETL a partir do Synapse, para que os dados do Azure Cosmos DB possam ser consultados em conjunto com outras cargas de trabalho analíticas do Synapse em tempo quase real.

• O Arquivo Analítico do Azure Cosmos DB não está particionado por predefinição.

  • Para determinados cenários de consulta, o desempenho melhorará ao criar partições de dados do Arquivo Analítico através de chaves que são frequentemente utilizadas em predicados de consulta.
  • A criação de partições é acionada por uma tarefa no Azure Synapse que executa um bloco de notas do Spark com Synapse Link, que carrega os dados do Arquivo Analítico do Azure Cosmos DB e os escreve no arquivo particionado do Synapse na conta de armazenamento primária da área de trabalho do Synapse.

• Azure Synapse Conjuntos sem SERVIDOR DO SQL do Analytics podem consultar o Arquivo Analítico através de vistas atualizadas automaticamente ou através de SELECT / OPENROWSET comandos.

• Azure Synapse conjuntos do Spark de Análise podem consultar o Arquivo Analítico através da atualização automática de tabelas do Spark ou do spark.read comando.

• Os dados também podem ser copiados do Arquivo Analítico do Azure Cosmos DB para um conjunto de SQL do Synapse dedicado com o Spark, para que possam ser utilizados recursos do conjunto de SQL Azure Synapse aprovisionados.

• Os dados do Arquivo Analítico do Azure Cosmos DB podem ser consultados com Azure Synapse Spark.

  • Os blocos de notas do Spark permitem que as combinações de dataframe do Spark agreguem e transformem dados analíticos do Azure Cosmos DB com outros conjuntos de dados e utilizem outras funcionalidades avançadas do Synapse Spark, incluindo escrever dados transformados noutros arquivos ou preparar modelos do AIOps Machine Learning.

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

Azure Synapse

• Azure Synapse reúne capacidades de análise, incluindo armazenamento de dados SQL, macrodados do Spark e Data Explorer para análise de séries de registos e tempo.

  • Azure Synapse utiliza serviços ligados para definir ligações a outros serviços, como o Armazenamento do Azure.
  • Os dados podem ser ingeridos no Synapse Analytics através de atividade Copy de origens suportadas. Isto permite a análise de dados no Synapse sem afetar o arquivo 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 no local em arquivos externos suportados, evitando a sobrecarga da ingestão e movimento de dados. O Armazenamento do Azure com o Data Lake Gen2 é um arquivo suportado para dados exportados do Synapse e o Log Analytics pode ser consultado através do Synapse Spark.

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

  • Os dados de origem, incluindo os dados do Arquivo Analítico do Azure Cosmos DB e os dados de Exportação do Log Analytics, são consultados e processados para suportar informações empresariais e outros casos de utilização analítica agregados.

Recomendações de Estrutura

• Confirme que as cargas de trabalho analíticas não afetam as cargas de trabalho das aplicações transacionais para manter o desempenho transacional.

Application Analytics

• Utilize Azure Synapse Ligação com o Arquivo Analítico do Azure Cosmos DB para realizar análises em dados operacionais do Azure Cosmos DB ao criar um arquivo de dados otimizado, o que não afetará o desempenho transacional.

  • Ative Azure Synapse Ligação nas contas do Azure Cosmos DB.
  • Crie um contentor ativado para o Arquivo Analítico ou ative um Contentor existente para o Arquivo Analítico.
  • Ligue a área de trabalho Azure Synapse ao Arquivo Analítico do Azure Cosmos DB para permitir cargas de trabalho analíticas no Azure Synapse para consultar dados do Azure Cosmos DB. Utilize um cadeia de ligação com uma chave do Azure Cosmos DB só de leitura.

• Priorize o Arquivo Analítico do Azure Cosmos DB com Azure Synapse Link em vez de utilizar o feed de alterações do Azure Cosmos DB para manter um arquivo de dados analítico.

  • 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 uma única área de trabalho Azure Synapse com serviços ligados 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 de Armazenamento do Azure dedicada e utilize-a como a conta de armazenamento principal da área de trabalho para armazenar os dados e metadados do catálogo da área de trabalho do Synapse. Configure-o com o espaço de nomes hierárquico para ativar o Azure Data Lake Gen2.

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

Passo seguinte

Reveja as considerações relativas às considerações de rede.

Rede e conectividade