Compartilhar via

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

  • Artigo

APLICA-SE AO: NoSQL MongoDB Cassandra Gremlin Table

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

Em um data center, podemos implantar o Azure Cosmos DB em grandes carimbos de computadores, cada um com 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:

Topologia do sistema

A distribuição global no Azure Cosmos DB é turnkey: 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. 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.

partições físicas

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 colocadas dinamicamente e com balanceamento de carga entre os computadores dentro de um cluster e os data centers dentro de uma 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 tipo baseado em ARS (atom-record-sequence). O mecanismo é independente do conceito de um esquema, desfocando o limite entre os valores de instância e de estrutura de 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 ou 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 Lego modular para coordenação, enquanto que 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 em alterações de associação, a replicação de protocolo também reconfigura o tamanho de leitura e os quóruns de gravação. 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 coerê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 empregar diversas ideias da pesquisa feita sobre o relacionamento carga e capacidade nos sistemas baseados em quórum para a coerência de cinco modelos aos quais o Azure Cosmos DB dá suporte.

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:

Conjuntos de partição

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 kernels de ideias tenham sobrevivido e apresentem um quadro de referência conveniente para comunicação com o design do sistema do Azure Cosmos DB, eles também foram submetidos a transformações significativas ao serem aplicados ao sistema do Cosmos DB. Isso era necessário porque os sistemas anteriores foram projetados sem a governança de recursos nem a escala com que o Azure Cosmos DB precisa operar ou fornecer os recursos (por exemplo, coerência de desatualização limitada) e SLAs rígidos 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 do Azure Cosmos DB (gravações de várias regiões) 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 prepara leituras tipicamente para os clientes que são locais dessa região. As gravações aceitas por uma partição física em uma região são confirmadas permanentemente e altamente disponibilizadas na partição física, antes de serem reconhecidas para o cliente. São gravações provisórias e propagadas para outras partições físicas dentro do conjunto de partições usando um canal antientropia. 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 de arbitrador 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 serem pedidas.

Podemos empregar os relógios de vetor codificados (contendo a ID da região e relógios lógicos correspondendo a cada nível de consenso no conjunto de réplicas e no conjunto de partições, respectivamente) para vetores de versão e acompanhamento de causalidade detectarem e resolverem 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 de entre gravações sob 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 coerê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 acumulam e a contrapressão sobre as gravações não precisem ser aplicadas. A coerência de sessão assegura garantias de leitura monotônica, gravação monotônica, ler suas próprias gravações, gravação segue a leitura e prefixo coerente em todo o mundo. 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: