Distribuição de dados global com o Azure Cosmos DB – nos bastidores

APLICA-SE A: NoSQL MongoDB Cassandra Gremlin Tabela

O Azure Cosmos DB é um serviço básico do Azure, de modo que é implantado em todas as regiões do Azure em todo o mundo, incluindo nuvens públicas, soberanas, DoD (Departamento de Defesa) e governamentais.

Em um nível alto, os dados de contêiner do Azure Cosmos DB são particionados horizontalmente em vários conjuntos de réplicas que replicam as gravações em cada região. Os conjuntos de réplica confirmam gravações de forma duradoura usando um quórum majoritário.

Cada região contém todas as partições de dados de um contêiner do Azure Cosmos DB e pode fornecer leituras e gravações quando as gravações de várias regiões estiverem habilitadas. Se a conta do Azure Cosmos DB for distribuída entre N regiões do Azure, haverá pelo menos N x 4 cópias de todos os dados.

Dentro de um data center, implantamos e gerenciamos o Azure Cosmos DB em grandes conjuntos de máquinas, onde cada uma possui armazenamento local dedicado. Em um data center, o Azure Cosmos DB é implantado em vários clusters, cada um executando potencialmente várias gerações de hardware. Os computadores em um cluster normalmente são distribuídos entre 10 e 20 domínios de falha para permitir alta disponibilidade em uma região. A imagem a seguir mostra a topologia do sistema de distribuição global do Azure Cosmos DB:

A distribuição global no Azure Cosmos DB é pronta para uso: a qualquer momento, com alguns cliques ou programaticamente com uma única chamada à API, você pode adicionar ou remover as regiões geográficas associadas ao banco de dados do Azure Cosmos DB. Um banco de dados do Azure Cosmos DB, por sua vez, consiste em um conjunto de contêineres do Azure Cosmos DB. No Azure Cosmos DB, os contêineres servem como unidades lógicas de distribuição e escalabilidade. As coleções, as tabelas e os gráficos que você cria são (internamente) apenas contêineres do Azure Cosmos DB. Os contêineres são completamente independentes de esquema e fornecem um escopo para uma consulta. Os dados em um contêiner do Azure Cosmos DB são indexados automaticamente após a ingestão. A indexação automática permite aos usuários consultar os dados sem problemas de esquema ou de gerenciamento de índice, especialmente em uma instalação distribuída globalmente.

• Em uma determinada região, os dados dentro de um contêiner são distribuídos usando uma chave de partição, que você fornece e é gerenciada de modo transparente pelas partições físicas subjacentes (distribuição local).

• Cada partição física também é replicada em regiões geográficas (distribuição global).

Quando um aplicativo usando o Azure Cosmos DB dimensiona de modo elástico a taxa de transferência ou consome mais armazenamento em um contêiner do Azure Cosmos DB, o Azure Cosmos DB transparentemente manipula as operações de gerenciamento de partição (dividir, clonar, excluir) em todas as regiões. Independentemente da escala, da distribuição ou de falhas, o Azure Cosmos DB continua a fornecer uma única imagem do sistema dos dados dentro de contêineres, que são distribuídos globalmente em qualquer número de regiões.

Conforme mostrado na imagem a seguir, os dados dentro de um contêiner são distribuídos juntamente com duas dimensões: dentro de uma região e entre regiões, em todo o mundo.

Uma partição física é implementada por um grupo de réplicas, chamado de conjunto de réplicas. Cada computador hospeda centenas de réplicas correspondentes a várias partições físicas em um conjunto fixo de processos, conforme mostra a imagem acima. As réplicas correspondentes às partições físicas são distribuídas dinamicamente e com balanceamento de carga entre os computadores dentro de um cluster e os data centers dentro da mesma região.

Uma réplica pertence exclusivamente a um locatário do Azure Cosmos DB. Cada réplica hospeda uma instância do Mecanismo de Banco de Dados do Azure Cosmos DB, que gerencia os recursos, bem como os índices associados. O Mecanismo de Banco de Dados do Azure Cosmos DB opera em um sistema de tipos baseado em ARS (atom-record-sequence). O mecanismo é independente do conceito de um esquema, borrando a linha entre a estrutura e os valores de instância dos registros. O Azure Cosmos DB obtém total independência de esquema indexando tudo automaticamente no momento da ingestão de maneira eficiente, o que permite aos usuários consultar seus dados distribuídos globalmente sem precisarem lidar com gerenciamento de esquema ou índice.

O Mecanismo de Banco de Dados do Azure Cosmos DB consiste em componentes, incluindo a implementação de várias primitivas de coordenação, runtimes de linguagem, processador de consultas e subsistemas de armazenamento e indexação responsáveis pelo armazenamento transacional e pela indexação de dados, respectivamente. Para fornecer durabilidade e alta disponibilidade, o Mecanismo de Banco de Dados mantém os dados e o índice em SSDs e replica-os entre as instâncias do Mecanismo de Banco de Dados dentro dos conjuntos de réplica, respectivamente. Locatários maiores correspondem a uma escala maior de taxa de transferência e armazenamento e têm réplicas maiores, em maior número ou ambas. Cada componente do sistema é completamente assíncrono: nenhum thread jamais bloqueia e cada thread faz trabalho de curta duração sem incorrer em nenhuma alternância de thread desnecessária. A limitação de taxa e a contrapressão são inseridas em toda a pilha do controle de admissão para todos os caminhos de E/S. Nosso mecanismo de banco de dados do Azure Cosmos DB é projetado para explorar a simultaneidade de granularidade fina e entregar alta taxa de transferência enquanto opera com pequenas quantidades de recursos do sistema.

A distribuição global do Azure Cosmos DB se baseia em duas abstrações de chave: conjuntos de réplicas e conjuntos de partições. Um conjunto de réplicas é um bloco de construção modular para coordenação e um conjunto de partições é uma sobreposição dinâmica de uma ou mais partições físicas distribuídas geograficamente. Para entender como a distribuição global funciona, precisamos entender essas duas abstrações principais.

Conjuntos de réplicas

Uma partição física é materializada como um grupo autogerenciado e com balanceamento de carga dinâmico de réplicas distribuídas entre vários domínios de falha, chamados de conjunto de réplicas. Esse conjunto implementa coletivamente o protocolo de computador de estado replicado para tornar os dados na partição física altamente disponíveis, duráveis e consistentes. A associação de conjunto de réplicas N é dinâmica, ela fica flutuando entre Nmín e Nmáx com base em falhas, operações administrativas e o tempo para a regeneração/recuperação de réplicas com falha. Com base nas mudanças de membros, o protocolo de replicação também reconfigura o tamanho dos quóruns de leitura e escrita. Para distribuir de modo uniforme a taxa de transferência atribuída a uma determinada partição física, empregamos duas ideias:

• Primeiro, o custo para processar as solicitações de gravação no líder é maior do que o custo para aplicar as atualizações no seguidor. Do mesmo modo, o líder tem mais recursos de sistema orçados que os seguidores.

• Em segundo lugar, sempre que possível, o quórum de leitura para um nível de consistência específico é composto exclusivamente pelas réplicas de seguidores. Evitamos entrar em contato com o líder para atender às leituras, a menos que necessário. Podemos utilizar diversas ideias da pesquisa feita sobre a relação entre carga e capacidade nos sistemas baseados em quórum para os cinco modelos de consistência que o Azure Cosmos DB suporta.

Conjuntos de partições

Um grupo de partições físicas, uma de cada uma das regiões de banco de dados do Azure Cosmos DB configuradas, é composto para gerenciar o mesmo conjunto de chaves replicadas em todas as regiões configuradas. Essa primitiva de maior coordenação é chamada de conjunto de partições: uma sobreposição dinâmica distribuída geograficamente das partições físicas que gerenciam um determinado conjunto de chaves. Embora o escopo de uma dada partição física (um conjunto de réplicas) seja definido dentro de um cluster, um conjunto de partições pode abranger clusters, data centers e regiões geográficas, conforme mostra a imagem a seguir:

Você pode pensar em um conjunto de partições como um "superconjunto de réplicas" geograficamente disperso composto por vários conjuntos de réplicas com o mesmo conjunto de chaves. Semelhante a um conjunto de réplicas, a associação de um conjunto de partições também é dinâmica: ela varia com base nas operações implícitas de gerenciamento de partições físicas para adicionar/remover novas partições de/para um determinado conjunto de partições (por exemplo, quando você dimensiona a taxa de transferência em um contêiner, adiciona/remove uma região no banco de dados do Azure Cosmos DB ou quando ocorrem falhas). Como cada uma das partições (de um conjunto de partições) gerencia a associação do conjunto de partições em seu próprio conjunto de réplicas, a associação é totalmente descentralizada e altamente disponível. Durante a reconfiguração de um conjunto de partições, a topologia da sobreposição entre as partições físicas também é estabelecida. A topologia é selecionada dinamicamente com base no nível de coerência, na distância geográfica e na largura de banda de rede disponível entre a origem e as partições físicas de destino.

O serviço permite que você configure seus bancos de dados do Azure Cosmos DB com uma ou várias regiões de gravação e, dependendo da escolha, conjuntos de partições são configurados para aceitar as gravações em exatamente uma ou em todas as regiões. O sistema usa um protocolo de consenso aninhado de dois níveis – um nível opera dentro das réplicas de um conjunto de réplicas de uma partição física que aceita as gravações e o outro opera no nível de um conjunto de partições para fornecer garantias completas de ordenação para todas as gravações confirmadas no conjunto de partições. Esse consenso aninhado em várias camadas é crítico para a implementação de nossos contratos rigorosos de alta disponibilidade, bem como a implementação dos modelos de coerência, que o Azure Cosmos DB oferece a seus clientes.

Resolução de conflitos

Nosso design para propagação da atualização, resolução de conflitos e acompanhamento de causalidade é inspirado no trabalho anterior sobre algoritmos epidêmicos e no sistema Bayou. Embora os núcleos das ideias tenham sobrevivido e ofereçam um quadro de referência conveniente para comunicar o design do sistema do Azure Cosmos DB, eles também passaram por transformações significativas à medida que os aplicamos ao sistema do Azure Cosmos DB. Isso era necessário porque os sistemas anteriores não foram projetados com a governança de recursos nem com a escala em que o Azure Cosmos DB precisa operar, nem para fornecer as capacidades (por exemplo, consistência de obsolescência limitada) e os SLAs rigorosos e abrangentes que o Azure Cosmos DB oferece a seus clientes.

Lembre-se de que um conjunto de partições é distribuído em várias regiões e segue o protocolo de replicação (gravações de várias regiões) do Azure Cosmos DB para replicar os dados entre as partições físicas que compõem um determinado conjunto de partições. Cada partição física (de um conjunto de partições) aceita gravações e atende leituras, normalmente para os clientes que estão localizados naquela região. As gravações aceitas por uma partição física em uma região são confirmadas de forma durável e tornadas altamente disponíveis na partição física, antes de serem reconhecidas para o cliente. São gravações provisórias que são propagadas para outras partições físicas dentro do conjunto de partições usando um canal de anti-entropia. Os clientes podem solicitar gravações provisórias ou confirmadas passando um cabeçalho de solicitação. A propagação antientropia (incluindo a frequência da propagação) é dinâmica, baseada na topologia do conjunto de partições, na proximidade regional entre as partições físicas e no nível de coerência configurado. Em um conjunto de partições, o Azure Cosmos DB segue um esquema de confirmação primário com uma partição árbitro selecionada dinamicamente. A seleção do arbitrador é dinâmica e é parte integrante da reconfiguração do conjunto de partições com base na topologia da sobreposição. As gravações confirmadas (incluindo atualizações multilinha/em lote) têm garantia de ordenação.

Empregamos relógios de vetor codificados (contendo a ID da região e relógios lógicos correspondentes a cada nível de consenso no conjunto de réplicas e no conjunto de partições, respectivamente) para o acompanhamento de causalidade e vetores de versão, visando detectar e resolver conflitos de atualização. A topologia e o algoritmo de seleção de par são projetados para garantir os armazenamentos fixo e mínimo e a sobrecarga mínima de rede dos vetores de versão. O algoritmo garante a propriedade de convergência estrita.

Para os bancos de dados do Azure Cosmos DB configurados com várias regiões de gravação, o sistema oferece diversas políticas de resolução automática de conflitos para os desenvolvedores escolherem, incluindo:

• LWW (a última gravação vence) que, por padrão, usa uma propriedade de carimbo de data/hora definido pelo sistema (com base no protocolo de sincronização de hora do relógio). O Azure Cosmos DB também permite que você especifique qualquer outra propriedade numérica personalizada a ser usada para resolução de conflitos.
• Política de resolução de conflitos (Personalizada) definida pelo aplicativo (expressa por meio de procedimentos de mesclagem) projetada para reconciliação de conflitos de semântica definida pelo aplicativo. Esses procedimentos são invocados após a detecção de conflitos entre gravações sob a responsabilidade de uma transação de banco de dados no lado do servidor. O sistema fornece exatamente uma garantia para a execução de um procedimento de mesclagem como parte do protocolo de confirmação. Há várias amostras de resolução de conflitos para você experimentar.

Modelos de coerência

Se você configurar seu banco de dados do Azure Cosmos DB com uma ou várias regiões de gravação, poderá escolher entre cinco modelos de coerência bem definidos. Com as várias regiões de gravação, estes são alguns aspectos importantes dos níveis de consistência:

A coerência de desatualização limitada garante que todas as leituras estejam dentro de prefixos K ou segundos T da gravação mais recente em qualquer uma das regiões. Além disso, leituras com coerência de desatualização limitada são asseguradamente monotônicas e têm garantias de prefixo coerente. O protocolo antientropia opera de maneira limitada por taxa e garante que os prefixos não se acumulem e a contrapressão sobre as gravações não precisem ser aplicadas. A consistência de sessão garante, globalmente, leitura monotônica, gravação monotônica, leitura das suas próprias gravações, gravação após leitura e prefixo consistente. Para bancos de dados configurados com coerência forte, os benefícios de várias regiões de gravação (latência de gravação baixa, gravação de alta disponibilidade) não se aplicam devido à replicação síncrona entre regiões.

A semântica dos cinco modelos de coerência no Azure Cosmos DB é descrita aqui e matematicamente descrita usando especificações de alto nível de TLA+ aqui.

Próximas etapas

Em seguida, saiba como configurar a distribuição global usando os seguintes artigos:

• Adicionar ou remover regiões de sua conta de banco de dados
• Como criar uma política de resolução de conflitos personalizada
• Tentando fazer um planejamento de capacidade para uma migração para o Microsoft Azure Cosmos DB? Você pode usar informações sobre o seu cluster de banco de dados existente para planejamento de capacidade.
  • Se você sabe apenas o número de vCores e servidores no cluster de banco de dados existente, leia sobre como estimar unidades de solicitação com vCores ou vCPUs
  • Se souber as taxas de solicitação típicas da carga de trabalho do banco de dados atual, leia sobre como estimar unidades de solicitação usando o planejador de capacidade do Azure Cosmos DB